World: r3wp

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

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?