World: r3wp

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

also geomol, PLEASE don't suggest to auto-downgrade lit-words to 
words... it prevents us from using lit-words as browsable components.

I wouldn't call it a gaping hole, I would call it "the intended design". 
:-)

well...  can I not agree with the design, cause "there's a GAPING 
hole in the design"  ;-)

you guys didn't solve the "how do we use an integer as a key instead 
of an index" - you *can* use integer as a key without using it as 
an index, if you like. Nevertheless, the path-access does not work 
like that. You should either get used to it, or use a different access 
method, that is all. Anyway, you have got no right to call it a "GAPING 
hole in the path evaluation", taking into account, that it is by 
design. The fact, that your design preferences differ is irrelevant.

no not irrelevent.  we are all users, and some of us agree that this 
is a hole in the design.

Carl isn't all knowing and he has seen the light on many user ideas 
too.

using integers is often the only way get access to huge datasets 
and being able to provide keys.

we are all users, and some of us agree that this is a hole in the 
design.
 - so what? some don't, which proves my point

not being able to use paths to access these datasets is quite annoying 
since we can practically do all the rest.

but the fact that you don't agree doesn't make other's points irrelevant 
Lad.  :-)