World: r3wp

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.

I tend to agree with that. But then we need a new datatype for :1, 
the get-integer! datatype. All such examples points me to actually 
making get-paren! and lit-paren! datatypes, but some see those as 
maybe strange. With get-paren! the path problem could maybe be solved 
as:

blk/:(1)

yeah, that was the other idea I didn't post....

Why you just don't use SELECT where you need to select something?

but I don't see the problem with a lit integer.  how is it any strange. 
 its a label that represents one.  if you evaluate '1 you get 1. 
 


it just allows (programatic) differentiation between a value and 
a number.

Oldes, becuase the path might be deep: blk/1/a/2/b

yes Oldes, but that is not the point of the idea... I often use path 
notation to browse datasets, its VERY effective at simulating just 
about all of what xpath does, natively.

when I talk to XML-minded people and tell them that we've got paths 
embeded in the language they always *really* like the idea... and 
I understand them.

I've had to handle datasets that where 10 levels deep.   having to 
stop mid-way... use a select and then start again, breaks the whole 
idea of using paths to begin with.

And it so usual in your datasets that you need integer keys?

it has also forced me to use unfeasible types like issues or tags 
to simulate keys.  but then it requires a *lot* more CPU and RAM.

get-paren is not without problem too, because what should this mean:

:(1 2)

parens return the last part of their evaluation... the 1 here is 
just superflous

anyway.. why you simply do add a wish to CC and see what Carl thinks 
about it.

Oldes, its just strikes me as very odd that we cannot use the most 
efficient key in the book.   a single, simple, integer.  :-)

yep... anton already did.  :-)

But then you assume, the paren is evaluated. get- datatypes normally 
mean: don't evaluate.

the path evaluation is responsible for what it does with any type. 
 just like a parser.   for path notation is only serves the purpose 
of identifying a label vs an index (in the case of integer results 
specifically)

Anton suggested: blk/'1
Maybe it's a new datatype, the lit-integer! '1
I'm not sure, what to mean about it.

its a number... not a value.

(though its stored as a value, lets be pragmatic about it  ;-)

btw... is this what you want:
>> m: make map! [2 "a" 5 "b"]
== make map! [
    2 "a"
    5 "b"
]
>> m/(2)
== "a"
>> m/(5)
== "b"

It does, for the map specifically.