World: r3wp

error with swaping
a: also b b: a

Hm, a SWAP command could be a good idea, maybe. Or just do:
set [a b] reduce [b a]


About freeing local variables, why would you do that? Don't you call 
your function several times? You give garbage collector more to do 
this way. If it's often the case, that locals should be freed, then 
maybe we need a new function type, that does that?


(I'm asking all this, because I never understood the reason for having 
ALSO.)

When I think about it, much of this is based on assumption how memory 
is handled in REBOL. We don't really know, because it's not documented. 
When is it good to free a local, and when not? There may be something 
wrong, if this should be handled by the programmer (also when it's 
not documented).

In fact i use ALSO in functions to save the use of temporay variables.

Instead of doing  that:
func  [.. /local result][
	....
	result: ... 	;*** compute result
	... do something before returning the result
	:result    ;** return the result
]

I do:

func  [.. /local result][
	....
	 also (compute the result)
	.(do something before returning the result)
]

It saves the declaration of the result local var

Ok, your last func should have the /local result, right?

shouldn't have, right

Then it kinda makes sense. But then I think about all the internal 
sub-results, REBOL have to handle, and which I guess is freed by 
garbage collection. Is the problem, that REBOL keep locals, also 
when the funciton is finished?

In R3 it's not only to avoid the use of temporary vars, it's also 
faster (ALSO is native)

If I have a simple local in a language like C, I wouldn't allocate 
and free it every time, I call my function.

A local in C is just a value stored in some memory. I guess, it's 
the same in REBOL? Again we don't really know.

REBOL must have a look-up table for the known words in the context, 
but after that it should just end up at a memory address.

If you free the local every time, REBOL have to allocate that memory 
every time.

anyway ALSO is faster than using vars

ok

in R3

Hi John, I free locals all the time.

I use also function a lot.

Have you tested performance when you free locals and if you don't?

I also use this clear-locals function which is very similiar to what 
Gabriele made:

    clear-locals: make function! [word][
        word: bind? word 
        set word none
        set in word first first word none
    ]

in R3 we don't need to free locals

John, I haven't done a lot of performance checking but I know the 
clear-locals function is working to free memory.

I wish we could supress the garbabe collection and had the tools 
to handle that task ourselves.

As I see it, it's the garbage collectors job. When I use large series, 
I declare them like this in my functions:
some-series: clear []

Then I reuse the same memory, every time I call my function. I have 
never used ALSO.

yes, it is the garbage collectors job but any garbage collector has 
to make assumptions about the data that may not be to optimal to 
your application.

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...