World: r3wp

Another old R2 idiom:
all [in object 'property object/property]
vs
select object 'property

var: either cond [...][none]
vs
var: if cond [...]

hmm... yes, that is old

But you know, We all are in the same trend, It will take a while 
before we loose old habits

Today, I saw something horrific in an old script of mine.
>> 8 * to-integer v1 + v2 / 8

V1 and V2 are actually integers

(not related specificaly to R3)

I let you think about this coding horror ;-)

Was that R1 semantics? ;-)

I wouldn't always use the IF version in place of EITHER. I generally 
prefer to be explicit.

We use that IF or UNLESS returning none trick a lot. It is used so 
much that it might as well be considered explicit. It is good to 
remember that REBOL doesn't have an optimizer; we have to optimize 
by hand, and the IF trick is faster than the explicit EITHER.

It is used so much that it might as well be considered explicit.

As is my preference for avoiding premature optimization. ;-)

On that note: Steeve...

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

It's the same thing as the SELECT object word trick.

Gregg, don't avoid optimization altogether in the name of avoiding 
"premature" optimization :)

A better aphorism to use here would be to avoid being "penny wise 
but pound foolish" - it makes your point better :)

Agreed on optimization being required at times. Not loading lots 
of data? Yes. Using a hash instead of a block? Yes. I have even avoided 
the mezz loop constructs at times, though more often for clarity 
than performance. 


Maybe I'm a special case, but I have rarely found the need to optimize 
my REBOL code for performance at this level. And I can safely say 
I have never ever, ever optimized out EITHER for IF. Since you said 
it's used a lot, what code should I look at to see how and why? I'm 
always happy to see what I've been missing.

It's used in mezzanines, for instance. I tend to just write code 
in micro-optimized form in the first place, since it is easy to do 
and saves you the trouble of doing it later. Even if you are macro-optimizing 
the code (refactoring and such) you tend to use the same micro-optimizations 
in the new code. For that matter, many of the changes and enhancements 
in R3 were done to make micro-optimized code cleaner to read and 
write than they are in R2. But I mostly write library and mezzannine 
code nowadays, so micro-optimization has greater impact than it would 
for user-level code.

Two notes:

- I optimize for code size, using IF, or UNLESS

- the average speed-up looks like being about 27%, though, which 
is worth considering

Interesting: That's the same speedup that referencing words from 
object contexts gives you, relative to function contexts.

Agreed: Less code means less code to maintain and debug :)

I wonder, what is the purpose of the --- function, did not suceed 
to find that out.

>> same? :--- :comment
== true

aha, thanks

I hope, though, that everyone will use the word COMMENT.

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