World: r3wp

it's a differrent use case when dealing with series.
even in R3 you need to clear the series

Has anyone done anything with REBOL and UNC (looks to me like UNC 
is M$ way of keeping networks and drives from being compatible, just 
like Paul Allen's backslash trick from long ago) http://technet.microsoft.com/en-us/library/cc939978.aspx
where \\servername\sharepoint\subdirectory\filename.


Almost looks like Microsoft took the "Refinement" concept of / and 
unrefined it with \

so, if I am on a M$ network, what is the best way to reach a \\blah\blah\blah\file.blah?

I think it is:
read %/blah/blah/blah/file.blah

I know you can do it but just forget the syntax.

I don't have access to an open microsoft network currently.

wow, thanks Paul.  I think I freaked momenarily.  If I have to do 
it through Windoze I figure I could do a call (as a backup plan)

A link to where Gab answered this, and yes, your example looks correct, 
http://www.rebol.org/ml-display-thread.r?m=rmlJZJQ

Is this a bug?

>> first [:a/b]
== :a/b
>> type? first [:a/b]
== path!

Shouldn't it be get-path! ?

R3 responds get-path!, so it might be a bug

There's no get-path! datatype in R2 AFAICT.

I think, you are right! Just a bit confusing, what :a/b mean then. 
It doesn't give an error.

Maybe a combined get-word! and path! ?

It isn't a path either

This is why I made my as-lit-word function.

I think it's being interpreted as a get-word! with a refinement:

>> type? :a/b
** Script Error: a has no value
** Where: halt-view
** Near: type? :a/b
>> type? :a /b
** Script Error: a has no value
** Where: halt-view
** Near: type? :a /b
>>

and inside the block, it can be interpreted as a path. basically 
get-path! is a good idea. :-)

>> as-lit-word? first [:a/b]
== false
>> as-lit-word? first [:a]
== true

I'm not sure what that means...

Tells me if an item acts as a lit-word.

acts
 is the key word.

http://www.tretbase.com/forum/viewtopic.php?f=8&t=30&start=10#p141

I could test the value with the as-lit-word? function to determine 
if I want to set the word to a value.

It seems that there's no specific semantic rule in R2 for a get-word! 
as first item of a path! value. So, it's just treated as word!.

>> a: [b 123]
== [b 123]
>> :a/b
== 123
>> a/b
== 123

Geomol: the best exaple is:    also copy port close port

but it's so useful in so many cases...

If you do:

my-port: also copy part close port

then why not just do:

my-port: copy port
close port

part -> port

I'm wondering, if your need for ALSO is because you structure your 
programs differently than I do?

I think it was to get rid of 'my-port. ALSO is useful when returning, 
so you don't need to assign another word for results that would otherwise 
be temporary. I use ALSO in a couple of places here.

process-port: func [port] [
	also copy port close port
]

versus:

process-port: func [port /local p] [
	p: copy port
	close port
	return p
]

What happens, where you call process-port? Don't you have a variable 
there?

That depends on the structure of the program, I guess.

In R2, it's still fairly elegant:

>> source also
also: func [
    {Returns the first value, but also evaluates the second.}
    value1 [any-type!]
    value2 [any-type!]
][
    get/any 'value1
]

So you have this process-port function, and you need ALSO to not 
have an extra variable. I would just write:
... copy port
close port

without calling some function to do it.

I don't see ALSO as elegant, if there is no need for it. It's bloat 
in my eyes. (I may change my mind sometime, when I see good use of 
it. I haven't seen that yet.)

As said, it's about the return value:

1. maybe you need the function in 50 places
2. maybe you need the return value from the function

It does really untie a small knot there and I've bumped into that 
quite often. It was discussed heavily a year ago in the r3-alpha 
world and Carl wanted it in. I remember the discussion was mostly 
what to name it. :-)

Yes, I read that discussion again yesterday. I remember, that I also 
didn't see the great use of it back then. :-)

I guess you've not bumped into that knot.

Maybe if I see a bit larger program, that use ALSO!?

anway, I would be sad to see it go, so I want it to stay.

I learned a program structure more than 20 years ago called "program 
95%". It's a structure, you use 95% of the time when programming 
COBOL (and probably also in most other langauges). Maybe the need 
for ALSO is related to how we structure our programs?

The structure is basically:
init get-input loop [handle input get-input until end] cleanup

I'm not sure it is. For the port example above, there's no way to 
return without ALSO or assigning a temporary variable. If you are 
using it inside another function, like process-port, it will only 
reduce overhead, not create more.

and you really want functions like that to be simple.

What is the overhead for calling a function compared to not call 
it? And by having the close down in a function mean, it may not be 
on the same level as the open, which may be seen as bad programming 
style.

as said, if you use the function in 50 places...

So you have
port: open .....
my-port: process-port port

many places, where I suggest:

port: open ...
my-port: copy port
close port

no, you may exactly _not_ have 'my-port. you may be doing a test 
on the port which does not require an extra word.