World: r3wp

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

well, we don't have the source code to 'sort to know whether the 
sort creates a new copy or whether it sorts in situ ... so no idea 
whether there is a penalty or not

BTW, the term set function is confusing .. perhaps use the term sets 
function

Hence the quotes.

This isn't a serious question.  Devil's advocacy, or what you might 
call it.  But given Rebol's insistence that "/only" is a somewhat 
opaque modifier speaking about whether the routine in question does 
its "extra" thing or not... wouldn't "unique/only" be a way of saying 
"sort the array in place only, don't do the make copy step"?

series: unique series

Carl says it has to make a new series anyway

I prefer the symmetry 

series: sort series

instead of one doing one , and not the other

If one could turn back time, I wonder if {!} for types would be better 
served by some other symbol like {^} , and Rebol could have UNIQUE! 
(modifying) vs. UNIQUE (make a copy) in the style of Ruby and company. 
 "Verbs modify" isn't consistent, since REDUCE or COMPOSE don't modify 
while SORT and REVERSE do.

(In my currently-still-very-limited Ruby tinkering, I have liked 
this convention--and in fact, sort of wished there were some way 
of it being more than just a convention, but reflected in a contract 
which generated both the modifying and non-modifying variant of an 
operation.)

The learnability of consistency vs. the beauty of making the common 
cases and idioms look elegant.   But are those looks deceiving?  
English sure is a mess... but people find it effective.

Why not follow your INTO convention?  Couldn't you make UNIQUE/INTO?

consistency leads to a lower cognitive load for the programmer

the argument that sort modifies because you can always copy first 
is met by the retort that you can always assign afterwards

I think that Rebol already has the "i before e but not after q and 
sometimes z" philosophy, in that there are forces driving it that 
are something of the nature of what drives natural language design. 
 Purely consistent  languages which have no special adaptations to 
the "messy" world don't really need to be designed, they exist mathematically 
already.  They are more discovered than made.

Hence the catch-phrase "Inspired by theory, driven by practice." 
 Of course, then the question comes up of "whose practice?" when 
releases are being timed to Amiga announcements etc.

So, tell me .. sort in place is more expensive than not, so another 
series is already created somewhere ...

so, modifying the original series is likely to be a convention and 
not an optimization

Whether sort in place is more expensive or not depends on the fundamental 
operations upon which sort is built.  (This makes interview questions 
fun when people "know" the answers, because you say "oh.  well let's 
say you're on an architecture where a memory allocation costs 1000 
times more than a swap"... :P)

Anyway, the issue is about the program expressing the intent of the 
programmer and letting the system do the smartest thing under the 
hood given the understanding of what the programmer wanted, for the 
common cases.

Some thought process in Rebol design didn't make "ARITHMETICATE" 
or some variant of REDUCE which is modifying on its value target. 
 Instead, it was decided that REDUCE/INTO would be more interesting. 
 I'm just wondering what optimization logic makes DEDUPLICATE more 
interesting than UNIQUE/INTO... ?

perhaps it's a feeling that refinements should be used for passing 
new arguments than modifying behaviour?

Does anyone else have trouble calling a file that has parentheses 
in it?

eg. ?

call %/d/something with (parentheses).mp3

and what happens for you?