World: r3wp

but the other example is the same

I think you may have a typo........My example was 1:0:5000 (two colons). 
I see identical behavior in R2 and R3

you are right, sorry.

Where did the action PATH come from? Write in the console:
? path
I can't see it documented anywhere.

I guess it should not be visible if it's not documented... some internal 
function probably.

Ask on R3 chat so Carl can see it.

>> blk: [a b c d e]
== [a b c d e]
>> foo: [bar 5]
== [bar 5]
>> path blk foo/bar
>> blk
== [a b c d]
>> foo/bar: 1
== 1
>> path blk foo/bar
>> blk             
== []
>> foo
== [bar 1]

Returns an unset!, clears the block from given index...

So, beside the unset! returned, PATH is like CLEAR AT ?

Anyone using ALSO?

everywhere

Can you give examples?

The primary example use was in functions, to return the contents 
of a variable and also free the variable. eg, this:

	add-one: func [value][1 +  also value value: none]

replaces older code such as this:

	add-one: func [value][1 + first reduce [value value: none]]

Is that a good example? Why would you set value to none, if it's 
a number? It doesn't matter.

use cases: 
1/ swaping a with b
a: also b a: b
2/ in a function, returning a value after cleaning local vars
func [x /local tmp][
	tmp: a * 2
	also tmp tmp: none
]

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.