World: r3wp

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

Ladislav: I don't remember, I guess Anton is right. I wrote that 
rather quickly, mostly as a PARSE example. I haven't really used 
that script after that, so I've never had a good reason to improve 
/ complete it.

No problem, sure, I was just curious

:-) it would be nice to write a proper, complete compiler (including 
optimization etc.). your script may be already be close enough?

I hope it is simpler to start with, since it uses USE-RULE ;-)

...and it already describes more variants, so it shows how one can 
adjust it

nevertheless, it was originally meant as a "teaching code", so I 
do not claim completeness, or fitness for other purposes

But, as Gregg mentioned, I think that one of its advantages is that 
it shows how to implement different priority/associativity rule sets

Thanks to all for your "path related" thought..

Anton... did you CC your idea of lit word in paths?

Maxim, yes.  [now I can sleep].

;-)

Something to consider:

blk/'a/b
is a valid path today:

>> blk: ['a [b 0]]
>> blk/'a/b
== 0


If ' is made to be an escape, when followed by an integer, then it 
might be a bit confusing. On the other hand, I see lit-paren! as 
an usable new datatype, and in that case, it's kinda like an escape, 
when used in path notation. Something like:

>> blk [(a b) 0]
>> blk/'(a b)

which isn't valid today.

It should have been with a colon:
>> blk: [(a b) 0]

Remember you can always do:

>> blk: [1 a 2 b]
== [1 a 2 b]
>> second find blk 2
== b

But of course that's way more than just writing: blk/'2

why do you say blk/'1/is confusing?  it means use the integer litterally, 
not as an index.

or should I say, not as an ordinal index

It can be a bit confusing, because blk/'a mean: search for lit-word 
'a in blk. So I would guess, blk/'1 mean: search for lit-integer 
'1 in blk. That would be my initial though, when I saw this the first 
time.

*thought*

Or not lit-integer, but lit-word '1 (assuming '1 would be a valid 
lit-word).

When reconsidering all this again, I would like to question, how 
blk/'a works today. Why not evaluate 'a to a? Parens are evaluated 
in paths:

>> blk: [1 a 2 b]
== [1 a 2 b]
>> blk/(1 + 1)
== a

The reason, I would expect  'a to be evaluated in a path, is because 
it is when standing alone:

>> type? 'a
== word!

Like parens are:

>> (1 + 1)
== 2


It can be argued, that different behaviour, when used in a path, 
is a bad thing.

Geomol:

>> blk: [(a b) 0]
== [(a b) 0]

>> blk/(quote (a b))
== 0

:-) Yeah, you've pointed me to QUOTE several times in the past. I 
haven't learned to use it yet though.

:-D

My argument is the same as (I think) with e.g. Anton's proporsal 
for ' as escape in path: We like to write less to achieve things.

There has to be a limit somewhere