World: r3wp

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

btw.. in many case using temporaly variables is not so bad and may 
have better results than multiple deep path queries.

going via the variable disturbes your smooth flow of thoughts :-) 
we want as much of function chaining, as possible :-)

as for me - I hate SELECT :-)

I'm not interested in all the possible cases where using temporary 
variables isn't so bad (or even where it's better). I'm interested 
in those cases, which do come up from time to time, where using temporary 
variables is uncomfortable, and using a path directly to get to what 
I want would be much better (indeed, smoother).

(and faster)

As long as you are careful about your build process (or don't use 
one) you can use serialized syntax for literal maps: #[map! [a 1]]

Hmm, isn't it the other way around? paths need to start with a word, 
so you need a temporary variable; select's arguments have no limitation, 
so you don't need temporary variables.


Also, what about people who use the current way paths work with integer? 
It's bad to use select instead of path, but it is good to use pick 
instead of path? why?

When I talk about temp var usage, I mean this:
>> a: context [b: context [c: context [d: context [e: 1]]]]
>> tm 1 [loop 1000000 [a/b/c/d/e: a/b/c/d/e + 1]]
== 0:00:00.829
>> tm 1 [t: a/b/c/d loop 1000000 [t/e: t/e + 1]]
== 0:00:00.578

But if Carl will agree with the lit-integer, proposal I'm not agains 
that.

Anton, you may not have proposed a new datatype, but I think, the 
consequence of your proporsal would be a new datatype. I think so, 
because everything the REBOL parser knows, are datatypes. Some datatypes 
are series of datatypes, like blocks, parens and paths. I feel, it's 
a ground rule, that everything separated by slashes in a path, are 
by themselves datatypes.

Oldes, if it's about speed, this is going to be even faster:

loop 1000000 bind [e: e + 1] a/b/c/d

Do you know if it's better

Sorry wrong groupe.

BrianH, that cuts it down a little bit. (But would I be happy with 
that? I'm not sure...)

Gabriele;

About the temporary variables; if you go back to 17-Sep, in DideC's 
original question, his inc-counter function took a path as argument, 
but he had to introduce a temporary variable 'p so he could SELECT 
the integer path member. (And a few other people suggested functions 
doing the same thing.)


Also, note once again -> I did not propose to change the way paths 
currently work with integers. I proposed to *add* a new way to process 
integer path members. This new way does not subtract from any current 
functionality of any significance (that I've yet noticed, anyway).

Geomol, you have not explained why you think the rule you mention 
is a "ground rule" (by which I suppose you mean a fixed rule). I 
read your comment simply as saying that you are resistent to changing 
a rule, but you don't explain why.

Of course, once you accept that the rule cannot be changed, the first 
part of your comment flows logically from it. That's not good enough 
for me, though.

The only argument that I can imagine you might be putting forward 
here is that it's better to keep things simple, rather than add any 
complexity. I am proposing to add some complexity to the language 
implementation which can simplify the use of the language, and, for 
me, it appears to be worth it.

Rebol internals have made themselves visible (eg. end! == first first 
system/words) which I think is used to terminate blocks or lists 
or some other container datatype (perhaps path!), and also there 
are the hidden new-line markers in blocks and lists (but not in hash!).

So, ok, a new "path-escape marker" datatype may need be created to 
implement my proposal, but it doesn't have to be exposed to user 
space.

Anton: DideC's question requires a temporary variable because paths 
require a temporary variable (first element must be word), not because 
select does. If paths could start with a paren, for example, you 
could write:

(select values 1)/x/y: 10


But this is only a problem because we like the syntactic sugar, if 
you write that as functions all problems go away. I'm not sure if 
it's worth adding more syntactic sugar or not at this point...

Gabriele, ahh for syntactic sugar...

Why does sort modify the source ?  What's the rationale for making 
a function that acts to transform data also modify the source?

... bla bla bla ... speed ... bla bla bla

has anyone done any testing on whether the speed is that much different?

Because you can easily COPY if you want, but it's hard to go the 
other way. That's the general thinking as I understand it (and agree 
with most of the time).

There are many functions like that in REBOL, which act that way for 
the same reason. Most of the functions with a /copy option are like 
that.

So, why does 'unique not modify the original series?

Wherein lies the rhyme or reason?

The exception is the "set" functions that are supposed to make series 
act like unique sets. Most of the time people need copies when working 
with set functions. We had a big discussdion about this earlier.

and 'unique is  .. ?

A function to change a series to a "set".

Most of the time
 .. from where were these metrics derived?

Check here for a proposal for a modifying counterpart for UNIQUE: 
http://curecode.org/rebol3/ticket.rsp?id=1573

The recently created word DEDUPLICATE is the closest single English 
word for the concept. Note that it will still copy internally, because 
the UNIQUE algorithm requires a copy to work (it makes a hashed copy 
to determine uniqueness).

All the set functions have to allocate a new series internally for 
hashing, at least for large series (cutoff not documented). This 
would also be the case for modifying versions of all of the set functions 
- you wouldn't save a copy.

I think i'd prefer consistent behaviour and not have any modifying 
function of the ones discussed

so that all act like one would expect a pipe function would work 
.. least suprise here