World: r3wp

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

It does in this case, your point is irrelevant, since it you are 
trying to call "a hole in the design" something, that provably *is 
the design*

Not being able to use my radio frequency tuner for TV broadcasting 
may be disliked by me, but I have no right to call such a property 
"a hole in the design" regardless how many other people would want 
to agree with me

And, your "integer problem" is easy to solve. I guess, that you are 
so experienced, that you actually *are* able to do it.

Just do not use a hammer instead of a screwdriver

Lad, the only thing I can see from my side of the fence, is that 
you are closed to an idea... simple as that.

you don't like it so its irrelevant.  how can I even start to argue. 
 


All I can say is that I would have used it often in the past, and 
that I support Anton's idea.   


there might be other, better notations, but there should be something 
*native* in path evaluation which allows us to search for integers, 
just like we can search for other datatypes.


something like /a/:1/b  wouldn't be too bad either and it might match 
better the idea of getting the value of 1 but that doesn't work ATM.

>> :1
== 0:01
>> type? :1
== time!

That's occupied.

I know, but I've never like that :xx is a time... its totally undefined 
...  reading  :1  I don't get any sense of time. 


my guess is that its just a side-effect of how the loader sees : 
and digits .  requiring a number before :  wouldn't invalidate any 
script or dataset that I can think of.

lexicall it realy doesn't make much sense... or does it?

but again, that was just a slight spin on the idea... there are probably 
other notations we aren't thinking about.