World: r3wp

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.

and the parens around this are redundant, for maps:
>> m/2
== "a"
>> m/5
== "b"

(In R3, at least.)

That is one of the better reasons to use map! values for key-value 
behavior in R3.

I think, that solved the problem althogether. Use map! instead of 
block! for this behaviour. Makes sense to me too. block! is just 
an array, and blk/1, blk/2, ... means 1st, 2nd, ... item in the array. 
For key lookup behaviour, use map!. (Doesn't help in R2 though.)

Maybe if the map! behaviour was implemented for the hash! datatype 
in R2!?

Let me just make absolutely clear, once and for all; I did not propose 
to add any new datatypes (not lit-integer!, not get-integer! or anything 
else) to Rebol.

First, the only reason for such a new datatype would be for path 
evaluation.

Second, any new datatype with special meaning during path evaluation 
would then suffer the same problem that integer! currently has, ie. 
not being SELECTable; so this would solve a problem only to create 
an identical problem.


So what did I actually suggest? To extend the syntax of paths to 
allow a different evaluation for number values (actually to switch 
off the special treatment they currently get).

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


We can. Of course we can. However, it would be much more convenient 
to use a path in many cases.

Using SELECT:
- Requires temporary variables, breaking up the expression, or
- Requires the complexity of composing a path and evaluating it.
- Either of the above bloats out the code.

The map! behaviour looks like it would probably be good for many 
situations (and probably could have been used nicely in DideC's situation, 
were he not using R2).

However, it would not be convenient to create maps instead of blocks 
in other situations.

Instead of "[...]" you would need at least "make map! [...]", which 
means more code, something I would like to avoid.

You can always use TO-MAP:)