World: r3wp

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

(how would you search for lit-parens, etc?)

Using quote maybe? ;)

Not to mention, that it is illogical to have lit-parens, since we 
already have them. They are named blocks ;-)

:) Well, we can also today do something like:

>> blk: reduce [1 'a to lit-word! "2" 'b]
== [1 a '2 b]
>> blk/(to lit-word! "2")
== b

But I will consider such for rubbish.

>> to lit-word! "2"
** Syntax error: invalid character in: "2"
** Where: to
** Near: to lit-word! "2"

I'm using R2 core as "always" in this group.

The goal when constructing new languages must be to find the best 
simple ground rules and stick with them. Then new programmers don't 
have to learn all kinds of side-rules and "unless" behaviour.

I do agree with you, and introducing new quoted datatypes you would 
introduce too many such side rules into the language, which I disagree 
with.

Not to mention, that it is illogical to have lit-parens, since we 
already have them. They are named blocks

Hm, then I would expect this path notation to work:

>> blk: [[a b] 0]
== [[a b] 0]
>> blk/[a b]
** Syntax Error: Invalid path -- blk/

Same in R3.

Yes, it simply does not work, the funny thing about it is, that this 
does:

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

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

wow!

>> p: to path! [blk [a b]]
== blk/[a b]
>> do p
== 0

wow wow!

So, it is a problem of the language parser, which does not accept 
some data, that the interpreter can process

Right!

you guys didn't solve the "how do we use an integer as a key instead 
of an index"


this is a GAPING hole in path evaluation.  using integers isn't some 
fancy side datatype.


we are not adding a new datatype, its not a complex system like using 
parens (which is also very slow) and it doesn't require advanced 
binding tricks.