World: r3wp

I expect that Carl added it to be able to write more concise code. 
I prefer COMMENT too though.

I tend to just write code in micro-optimized form in the first place

And do you consider that premature optimization, or not?

It is just as easy in theory to write the code in micro-optimized 
form as it is to not, so why not? In practice though, in R2 it is 
harder to write micro-optimized code (for various reasons). In R3 
it is *easier* to write micro-optimized code than it is to not, because 
we have been deliberately been optimizing the language for just that 
effect for a couple years now.

in R2 I use none of the mezz loops(they really slow down code), now 
that they're all native, I have much more options in R3.

What's more, we have been working to make the behavior of the language 
much more consistent between datatypes, so it is now easier to make 
macro-optimizations like changing datatypes without needing to change 
the code that uses them. This is why the SELECT trick for objects 
works the same as it does for blocks, for instance.

Pity I can't use any of it, because I still need to run on Cheyenne

I ran into the same problem, which is why I made R2/Forward.

Yes, that helps

One side effect of "premature optimization" is that micro-optimized 
code patterns in the R3 mezzanines that looked bad or required explanation 
to Carl often led to improvements in the language to make those micro-optimizations 
unnecessary. Lots of ease-of-use improvements in R3 came about because 
of this.

I don't know if you can call that premature, after thirteen years 
:-)

In this case, I wrote most of those micro-optimizations in the last 
three years :)

I understand, but at the start of that, REBOL was a ten years old 
project, and a thirty years old design

Yes indeed. A lot of the improvements in R3 came from insight gained 
from many years of REBOL use.

By many people in the community, not just the R3 team.

It is just as easy in theory to write the code in micro-optimized 
form as it is to not, so why not?

So that's a "Yes" to my question then? ;-)

>> a: [a 1]
== [a 1]
>> a/:b
** Script error: :b has no value
>> select a 'b
== none

Brian, Are you kidding ? Could you avoid stupid code ? :-)

>> a: [a 1]
== [a 1]

>> b: 'c
== c

>> a/c
== none

>> a/:b
== none

Exactly the same behavior than SELECT, not more not less.

But I prefer the compact form, more readable IMHO.

Another old Idioms.
first serie
vs 
serie/1

I see that everywhere (even Ladislav use it too much ;-))
serie/1 is a lot faster though

Carl used to advise it was slower. Was that so in R2?

It's true, path notation slower with R2, not anymore with R3

A/1 is 2 time faster than FIRST A, on my config.

Actually, first calls pick

That's nice, I like that much better, and certainly more robust path 
evaluation

It's highly annoying to have paths bomb out instead of return NONE

We don't have that anymore since a while, both in R2 and R3.

>> b: []
== []
>> b/1
== none
>> b/a
** Script Error: Invalid path value: a
** Near: b/a

Was talking about the first form only (with the index)

but yeah

R3 is more lenient

Hasn't the first form always been like that?

Don't think so, but my memory is not that good :-)

Don't think so, but my memory is not that good :-)

I Remember something like: 
Hey ! You past the end !

At one point in R2, it was something like this:
>> X: [1 2]
== [1 2]
>> X/2
== 2
>> X/3
== none
>> X/4
!Error

(...well, for some reason I remember it that way, at least.  There's 
a chance I have it confused with something else...)

Steeve, you are right, I missed that :(

Gregg, my answer to your question is that writing micro-optimal code 
in the first place is usually not premature optimization; it is instead 
just avoiding having to rewrite as much of the code later. So it's 
still optimization, just not premature. Making macro-optimizations 
before you have the overall design done is usually premature optimization, 
but if your code style is consistent then you can make them later 
without having to rewrite too much, in my experience :)

Re "premature optimization" - I do not think I ever did have any 
feeling I used that. For example, I would never want to write O(n 
*n) code when O(n) is available, no matter how would anybody want 
to call my approach.

I posted a note on Geany as a possible linux rebol tool in IDE as 
Carl's Rebol Blog is no place for running notes - but altme cannot 
tag a topic ?  And trying to select a group here on linux as ALTme 
1.2.25 is loading is just a crap shoot - highlight and click and 
close yore eyes or is it the reverse?

Probably because AltME resorts the groups as you are trying to click 
the one you want, thus getting the wrong one.

We might want to change groups on the opimization topic. How about 
Performance?

Do we have NaN (Not A Number) defined in R3?

I don't think so. Is it needed?

This page suggests that the "internals" of R3 does have NaN defined 
http://www.rebol.net/wiki/Decimals-64but it doesn't appear to be 
accessible.

Related topic, Jerry: INFs (see comment from Carl, which perhaps 
offers some hope that the situation will be normalised one day):
    http://www.curecode.org/rebol3/ticket.rsp?id=1717

This page suggests that the 

internals" of R3 does have NaN defined" - how does the text suggest 
it? I, as a coauthor will try to correct the text, if it does.

Certainly, IEEE754 defines NaN, but Rebol does not need to use/define 
it in any way.

So, for Rebol decimals, NaN is not defined/supported at present, 
nor are there any plans to use it in the future.

Thanks for the answer, Ladislave.

(but, of course, if such a wish exists, there is always the possibility 
to put it as a wish to CureCode)