Mailing List Archive: 49091 messages

# order of evaluating expressions..

### [1/13] from: eric:ehrichweiss at: 23-Dec-2004 12:22

From the /Core documentation: The way mathematical expressions are evaluated from left to right regardless of the operator is different than many other computer languages. Many languages have rules of precedence that you must remember that determine the order of evaluation of operators. For example, a multiply is done before an add. Some languages have 10 or more such rules. **************************** Correct me if I'm wrong but I was always under the impression we evaluated the way we do because that's how *math* required them to be evaluated. I mean I don't evaluate 1 + 2 * 3 as 9 but as 7 because that's how I was taught in school for math in general, not just computer languages. Now my question, does anyone find Rebol's order of evaluating to be helpful?

### [2/13] from: gabriele:colellachiara at: 23-Dec-2004 18:32

Hi Eric, On Thursday, December 23, 2004, 6:22:25 PM, you wrote: EH> Now my question, does anyone find Rebol's order of evaluating to be EH> helpful? None of the two ways is actually more "helpful" than the other. REBOL is just using the simplest one; and this is mainly because doing it differently was quite problematic. BTW, maybe someone still has my EVAL function that can evaluate math expressions with the usual rules? I don't have it at hand. Regards, Gabriele. -- Gabriele Santilli <[g--santilli--tiscalinet--it]> -- REBOL Programmer Amiga Group Italia sez. L'Aquila --- SOON: http://www.rebol.it/

### [3/13] from: brianwisti:yaho:o at: 23-Dec-2004 10:10

Hi Eric, Order of evaluation doesn't really bug me, because computer languages are not bound to operate by the same precedence rules as mathematics. Rebol doesn't seem that odd to me, especially after getting the hang of languages like Lisp. Those syntax rules are there for a reason - probably something to do with making execution faster, but it's not like I know. Besides, I can always use parentheses whenever I need to make precedence more explicit, same as I always do in languages with algebraic notation :-) Kind Regards, Brian Wisti http://coolnamehere.com/ --- Eric Haddix <[eric--ehrichweiss--com]> wrote:

### [4/13] from: SunandaDH::aol::com at: 23-Dec-2004 14:32

Eric:
> Correct me if I'm wrong but I was always under the impression we > evaluated the way we do because that's how *math* required them to be > evaluated.
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.

### [5/13] from: rotenca::telvia::it at: 23-Dec-2004 22:45

>Now my question, does anyone find Rebol's order of evaluating to be >helpful? >
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

### [6/13] from: pwawood:mango:my at: 24-Dec-2004 6:09

Hi Gabriele I just came across it as I was tagging messages at Rebol.org in the ML archive. It can be found in the Topic index under "Maths Expression Evaluator". Regards Peter

### [7/13] from: berniegs:prodigy at: 23-Dec-2004 18:11

Hi, Back around 1967 or so, when I was just learning to program in Fortran II, I made the decision that I would never try to memorize precedence rules for expression evaluation. I just used parentheses to get the precedence I intended in Fortran, Perl, Rexx, VB, etc., and I've been doing it all along. Never had a problem with errors due to precedence rules. So I don't have any problem with Rebol's unusual precedence rules. I just look at it as being forced by Rebol to continue doing what I've been doing for the last 35+ years or so anyway. :-) I think it's a pretty good programming practice, and it works well for me. Bernie Schneider The individual has always had to struggle to keep from being overwhelmed by the tribe. To be your own man is a hard business. If you try it, you will be lonely often and sometimes frightened. But no price is too high to pay for the privilege of owning yourself. -- Friedrich Nietzsche --

### [8/13] from: rotenca::telvia::it at: 24-Dec-2004 1:09

Bernie Schneider wrote:
>Hi, >Back around 1967 or so, when I was just learning to program in
<<quoted lines omitted: 9>>
>I think it's a pretty good programming practice, and it works >well for me.
The problem is that parens slow down Rebol. -- Ciao Romano Paolo Tenca

### [9/13] from: pwawood::mango::net::my at: 24-Dec-2004 19:16

Hi Romano
> The problem is that parens slow down Rebol.
Is it really a significant slow down?
>> do [
[ 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

### [10/13] from: rotenca:telvia:it at: 24-Dec-2004 13:34

Peter WA Wood wrote:
>Is it really a significant slow down? >
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

### [11/13] from: greggirwin::mindspring::com at: 24-Dec-2004 9:59

Hi Romano,
>>Is it really a significant slow down? >>
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

### [12/13] from: pwawood:mango:my at: 24-Dec-2004 21:49

Romano Thanks for taking the time to send such a detailed and helpful reply at this time of year. Regards Peter

### [13/13] from: AJMartin:orcon at: 6-Mar-2005 11:49

Bernie wrote:
> I just used parentheses to get the precedence I intended... > I think it's a pretty good programming practice, and it works well for me.
Agreed. :) I'm fairly sure I've seen this technique used in the Software Construction book and on XP sites. --- Andrew Martin Merry Christmas!

Notes
• Quoted lines have been omitted from some messages.
View the message alone to see the lines that have been omitted