World: r3wp

but I think too, that SELECT and FIND should be able to process paths 
to look for nested structures.
via a refinement maybe.
Like select/path and find/path

I saw this request several times in the past, far far away...

My reasoning is that the effort to implement a lit-integer! type 
is not worth the value the notation provides, at least not right 
now. Once R3 is out, stable, and complete, ask me again. ;-)

In any case, write up a proposal, and RT will make the call. It's 
always good to write things down so we don't forget.

Don't know, I don't feel confident about the: "It has been requested 
many times in the past"
:-)

(And it's time to go to the chinese restaurant session of the week)

Is this a bug ?

>> a: make object! [ b: [ 1 2 3 4 5 ]]
>> probe a
make object! [
    b: [1 2 3 4 5]
]
>> forall a/b [ print a/b/1 ]
** Script Error: forall expected word argument of type: word
** Near: forall a/b [print a/b/1]
>> forall word: a/b [ print word/1 ]
** Script Error: forall expected word argument of type: word
** Near: forall word: a/b [print word/1]
>> word: a/b
== [1 2 3 4 5]
>> forall word [ print word/1 ]
1
2
3
4
5

no its always been like this... foreach needs to bind the word to 
the block

look closely

yes, you need to specify a word ... not a set-word.

it should be fixed

How can it be a bug, when it is documented?

statement: skip post -2
change find statement 'fixed 'changed

?

>> forall (in a 'b) [print a/b/1]
1
2
3
4
5

Looks more than sufficient for me.

The above is R3, though

The evaluation of these "partially evaluated arguments" has changed 
this way

Nevertheless, I do not like the header of the FORALL function, since 
the WORD argument is actually used to supply two values to the function, 
which is not a KISS strategy

(if this "two in one" method were that good, why it is not used by 
FOREACH, etc.?)

cause that's how they differ?

Cetera censeo, the "two in one" argument passing method is improper, 
and should not be used

#1653

would we be just using 

forall word word [print word/1] 

all the time ?

woudn't

<arghh>    wouldn't

all the time
?

isn't it more frequent, that you actually do:

my-word: [1 2 3]
forall my-word [do something...]

?

That should properly look this way:

forall my-word [1 2 3] [do something...]

Not using FORALL, I actually do not mind, I just wanted to point 
out what is wrong about it

this is one of the reasons I don't use FORALL very often, but resort 
to repeat i length? <something>

when I have used forall (and its really rare, cause until is much 
better, usually) I never use litteral data directly, its always some 
data which is already setup elsewhere.

I am pretty sure, that *if* FORALL was defined properly from the 
start, everybody would perceive a change to the "two in one argument 
passing method" inappropriate. But, since it is a backward compatibility 
issue, you do not see what is wrong about it. Nevertheless: the WORD 
argument is an independent word, which is used to "define" a local 
in the BODY argument, that is why it actually does not make sense 
to use it as a "series container" on entry

(where it is "nonlocal")

To make it absurd, even REPEAT could be modified to use the "two 
in one argument passing method". Would you find it proper?

...and if not, why?

...and I don't think, that an argument "because that is how REPEAT 
differs from FORALL" makes any sense as an argument

well repeat already uses 2 arguments.

ah sorry... read your statement the wrong way.

In my opinion, different functions are defined not because we like 
to have different functions, but because they do different things 
for us

Assuming (hypothetically), that FORALL did not use the "two in one" 
method, the Graham's example would look as follows:

forall b a/b [print a/b/1]


, which is preferable, since it clearly suggests, that the word 'b 
in the BODY is actually not the same word as in a 'b

Aha, it seems, that I noticed one more strangeness in this. Why actually 
the expression:

forall (in a 'b) [print a/b/1]

prints what it does in R3?

the reason I use 'forall is so I can remove elements of a series 
as I traverse it.

so

forall series [ if series/1 = something [ remove series ]]


which 'foreach doesn't allow because you don't have a reference to 
where you are in the series

use remove-each its MUCH faster.

using your example it becoms.

remove-each [if series/1 = something]

actually... its:
remove-each [series/1 = something]

remove-each is indeed much faster and it's a native.

argh... I'm reallly tire.

Only because Carl made it native!

remove-each item series [item = something]

not just because its native... its in the way it actually manages 
the removal... it only re-creates the series once, when its done.


using other methods, you are tampering with the series at each change, 
and it has to copy the series over and over.

remove-each mistake maxs-mistakes [ true ] ?

Is that the syntax?  :)