World: r3wp

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?  :)

yep

Maxim about remove-each, what do you mean by: 
- "it only re-creates the series once, when its done".

what I have been explained is that it makes a new series and only 
copies when remove is false.  then replaces the pointer within the 
series to the new one.

Steeve, removal of one object from a block is an O(n) operation, 
where n is the length of the series. That would make a naive implementation 
O(n ** 2), while REMOVE-EACH is just O(n)

...but, actually, no re-creation of series happens anyway

ah yes.. true.. it just copies over itself.

Ladislav, one question I've always wondered and I'm sure you know.

does CLEAR only set the soft size of a series or does it actually 
truncate the internal buffer of a series?

the former

CLEAR is just O(1)

although,maybe, that in some cases, the GC is able to reassign a 
smaller part of memory to the series, but I doubt it

Are you sure about that ?
I don't tink remove-each create any temporary buffer.

when I compare the footprint of foreach and remove-each, they are 
the same

(which means nothing, because i don't see why foreach need to create 
so much temporary blocks)

Sure about what? I did not tell, that REMOVE-EACH was creating any 
memory buffer

I prefer the actual "two in one" behavior of forall , it allows to 
retrospect where an error happened.

Anton: how?

and to continue from that point

did you check whether your approach is usable in R3?

seems to work
>> a: [ 1 2 3 4]
== [1 2 3 4]

>> forall a [if a/1 = 3 [a/1 / 0] print a]
1 2 3 4
2 3 4
** Math error: attempt to divide by zero
** Where: / if forall
** Near: / 0

>> a
== [3 4]

(i was aiming Maxim)

Aha, then it was an error on my part (the behaviour of FORALL). I 
thought, that its behaviour changed.

Using 'forall with 'remove will skip the element after a removed 
one (in R2 at least, don't know if it changed in R3)

>> X: [1 1 2 2 3 3 4 4 5 5 6 6 7 7]
== [1 1 2 2 3 3 4 4 5 5 6 6 7 7]
>> forall X [if odd? X/1 [remove X]]
== [7]
>> X
== [1 2 2 3 4 4 5 6 6 7]

which is one reason why I use until   ;-)

Gregg, I should make it clear that my alternate suggestion was *not* 
to add a new datatype, but to extend the path syntax with an escape 
char (which, if it would be ^, would also unfortunately reduce the 
syntax of words a little bit).


Perhaps ' is a better path escape char, because '1 is currently not 
any valid rebol datatype, so adding it would not require reducing 
the syntax of any existing datatype, as using ^ would. So,  values/'1/dos/new 
 would not contain any new datatype, it would simply extend the path 
syntax with an escape char which must be followed by an integer.


This escape mechanism should also work when followed by a paren, 
allowing evaluation of any expression (as long as the evaluation 
of the paren results in an integer). eg.
	n: 3
	values/'(n - 2)/dos/new

it nicely follows the use of lit words too.  I really like this idea.

and as you say, its a simple added case in the run-time evaluation 
of paths, as well as an additional variation to add in the lexical 
parsing of paths.

overall, not such a big deal to implement.

with the recent change of issue  to word base type, this becomes 
even more usefull.

Everyone using FORALL to remove more elements deserves what he gets 
(sloooow performance, and complications)

there should be a note in the 'FORALL help ...   

** do not use this function  **  all the alternatives are better 

;-D

Anton, sorry if I misspoke. I think it was Steeve that followed up 
your idea with lit-integer!

Actually, if you want to remove more elements from a block, then 
you either need to know what you are doing, or you should use the 
REMOVE-EACH function, eitherwise you quite likely get O(n ** 2) time, 
which is sloooow

I disagree. Alternatives are not always better.

If I traverse a series and depending of the data, I change an element 
or remove it, then I regard forall as appropriate.

You can do whatever you like, but removal of N elements from a block 
of length N is O(N * N) usually, if not done cleverly.

(this has been discussed at length on the ML)

I do not dispute, that there a faster methods for removal.
But removal is not the only way to deal with series.

Gabriele, having a look at

http://www.rebol.org/ml-display-message.r?m=rmlXHTS


, I wonder, whether it can handle equivalents of such expressions 
as [3 ** 3 ** 3], which my

http://www.fm.tul.cz/~ladislav/rebol/evaluate.r

handles as follows:

>> std [3 ** 3 ** 3] translate
== [power 3 power 3 3]

It doesn't, unless you use parens.
>> eval [3 ^ 3 ^ 3] ;== none
>> eval [3 ^ (3 ^ 3)] ;== 7625597484987.0