World: r3wp

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.

I would never do the first, because there is no close to be seen 
for every open.

So you don't really need to copy the port? It's just for a test, 
like:

port: open ....
while [port] [
....
]
close port

sorry, the content.

I give up. :-) gotta get back to coding.

:-) I need to see bigger examples to understand you guys.

ask Carl on Chat. I think that's best. It was his idea anyway.

Geomol: I wonder why you have a problem with 'also now. It was discussed 
on 10-Aug-2007 on r3-alpha in new-functions group - and you were 
one of the people who were in this discussion

Yes, I then said, I didn't see the need for it, but I suggested a 
good name. Now 1.5 years later, I still don't use it. I'm asking, 
if people use it, because if I see good use of it, I hope to use 
it myself.

I'm not using it.. I'm not coding in R3 yet. Also when I test 'also 
now, it looks that there is no speed gain.

Huh..  I didn't know there was an 'also - I defined my own function 
long ago that does what it does

I've used it in a couple places, almost always having to do with 
ports - it is much nicer than spanning 3 lines for the same thing

Do you have any code, I can see? To see how you use it.

John, consider if you have a local variable in a function.  Then 
calling also can clear that local variable.  This is what I use 'ALSO 
for the most and why it is way cool.

It is way cool when the item your returning is the very item you 
want to clear.

And why do you want to clear it? To save resources? But what then 
with the version, you return?

Yes to save resources.  For example, what if I just read an MP3 file 
into a word? I want to free that word so that it no longer is allocated 
to that data.

If you want to load more MP3s, it would be a good idea to reuse the 
same memory area. An example:

>> f: func [/local blk] [blk: []]   
>> a: f
== []
>> insert a 42
== []
>> a
== [42]
>> source f
f: func [/local blk][blk: [42]]
>> clear a
== []
>> source f
f: func [/local blk][blk: []]


You see, A and BLK inside F points to the same memory. Next time 
you call F, you can put some more stuff in BLK (read another MP3).

If you want to be able to completely remove BLK, I would do that 
using an object. Build the MP3 player as an object, instead of just 
a function. Makes sense?

Sure, John, but what if you don't want to load more mp3s?

Of if between loading mp3s you have other functions that are operating 
and you want to ensure that your keeping memory use at optimal levels?

I see no alternative to having the functionality of ALSO in those 
cases.