From: Rick DeNatale <rick.denatale@...>
Date: 2006-08-31T03:01:26+09:00
Subject: Re: and and or priority

On 8/30/06, J�rgen Strobel <strobel@secure.at> wrote:
> On Tue, Aug 29, 2006 at 08:55:09AM +0900, Michael W. Ryder wrote:

> > Smalltalk evaluates and and or operators the same way.  Most evaluation
> > is done from left to right with only a few different priorities.

> Yes, and this is consistant behaviour for Smalltalk, as Smalltalk uses
> left to right evaluation even for +, * arithmetic.

Smalltalk only prioritizes between
    unary selectors which bind the tightest
    binary selectors which are next  (so a negated + b is (a negated) + b
    keyword selectors which are last

    object jump: x + y * z towards: fred location

is interpreted as
    object jump: ((x + y) * z) towards: (fred location)

> I wouldn't say it is wrong the way ruby does it, but not exactly
> intuitive either. Choosing to follow english language rather than
> widespread convention *and* similiar constructs in ruby itself (&&,
> ||, +, *, ...) may seem a bit ... anti POLS.

A perl programmer would be very surprised if AND, OR, && and || worked
any other way.  Probably the most common perl idiom here is:

     "some long complicated expression" or die

> I feel this is a true case of POLS violation, not one of those "I
> don't know shit, and I was surprised" examples. I do know about
> operator precedence in ruby in general, and was surprised by this
> special case. Never ran into it myself though, probably because of
> luck or spurious parentheses.

It's often pointed out that it's impossible to minimize EVERYONE's surprise.


> It's not a major deal. It certainly can't be changed in 1.8 without
> breaking code. Who feels this is worth changing in 1.9?

Not I.


-- 
Rick DeNatale

My blog on Ruby
http://talklikeaduck.denhaven2.com/