order of evaluating expressions..

That's true. But there may be more items in a computer language than you learned in school. And the order of precedence of them may not be so intuitive. What is the "correct" order of precedence for? 5 or 7 * 6 and 3 The C language, for example, solves this by having a dozen levels of precedence (In C AND is above OR. Times is above both of them. At least, I think that's right -- and that's one of the problems of having a dozen levels: you need a good memory) REBOL solves that problem in a different way -- by just doing things left to right. That creates its own problems at times too -- a naturalistic line like this is tripped by that rule, meaning parentheses are needed: if length? "aa" = length? "bbb" [print 'true] Sunanda.

Rebol does the simplest thing, it can do: simple infix with no precedence. Every other thing would require a more complex internal algorithm. It is not the best for humans, but it works. -- Ciao Romano Paolo Tenca

The problem is that parens slow down Rebol. -- Ciao Romano Paolo Tenca

Is it really a significant slow down?

[ st: now/time/precise [ loop 100000 [ 2 * 3 + 1] [ print now/time/precise - st [ st: now/time/precise [ loop 100000 [ 1 + (2 * 3)] [ print now/time/precise - st [ ] 0:00:00.268024 0:00:00.303339 Regards Peter PS I ran the above test on my iBook G3 900mhz , surprisingly the difference was less on my Thinkpad Pentium 1000mhz which returned 00.109 & 00.125 for the same test

Yes. I often read this question about Rebol, my answer is always Yes. Rebol is slow by itself, if you slow it with an avoidable programming style, you are not doing the right thing. There are many of this cases in Rebol, the combinations of them can lead to a slow program. Often i see program which can become 30-50% faster only using the right syntax. This is a 50-60% gain example with the combination of 4 "Is it really a significant slow down?" cases: 0:00:00.375 [out: copy [] insert tail out to string! 4 * 5 + 3 * 6] 0:00:00.578 [append out: copy [] to-string ((4 * 5) + 3) * 6] Sometime this difference is negligible, sometime is the difference between an usable and an unusable program. And what is negligible today, will be not negligible tomorrow, when you'll add other features and functions to your program. There is an important difference between the syntax of compiled language and interpreted one: in the first case, the compiler can do many optimizations at compile time and you can write code in a more relaxed way; in the second case, all you write will be read and executed "as is" at run time. The programmer is also the optimizer. -- Ciao Romano Paolo Tenca

RPT> Yes. OTOH, premature optimization is one of the primary evils in software development (IMO). APPEND, and other functions, are there for a reason: usability. That said, I do have some places in my code where using a more efficient syntax has made a BIG difference in execution speed. Sometimes those places are obvious (inner loops), but sometimes they aren't (PARSE rules). So, most of the time you probably don't have to worry about it, but people absolutely do need to be aware of what is expensive and know how to fix things if they do have speed issues. It would be great to collect these things in a document. If people want to send their optimizations to me I'll do the organization and collection. We should come up with a good format for entries before they start rolling in though. Anyone else think that's a worthwhile idea? Now, what else can we do? Hmmmmm, REBOL is really good at parsing... what if we wrote an analyzer that looked for speed-killing syntax in scripts? It could start out very simple, looking for things like TO-* calls, APPEND in loops, FOR, etc. If people have tricky scripts, we'll worry about that later. :) -- Gregg

Agreed. :) I'm fairly sure I've seen this technique used in the Software Construction book and on XP sites. --- Andrew Martin Merry Christmas!