[Prev][Next][Index][Thread]

Re: precedence of | and &

In article <wkog8gfu22.fsf@double.co.nz>, Chris Double
<chris@double.co.nz> wrote:

> brucehoult@pobox.com (Bruce Hoult) writes:
> 
> > The folly of relying on precedence in complicated expressions aside,
> > does anyone else think that it would really be better if | had lower
> > precedence than &, as in practicaly every other language in common
> > use?
> 
> What are the advantages of & having lower precedence than |? What are
> the disadvantages of them both being the same precedence?

I think that as a practical matter, if you're using both & and | in the
same expression, the vast majority of the time what you want is ORing of
groups of ANDs -- you want to say...

if (this & this & this & this
 | that & that & that & that
 | the-other & the-other).

... and so this form is the one that should be expressable without
brackets.  There are lots of examples of this structure in the source code
to d2c -- all nicely surrounded with parens, of course. Which is a good
safe way to wrote it.

A conjunction of disjunctions is the most common form in logic.
A sum (or) of products (and) is the most common form in binary circuit design.


It's quite rare to say  (a | b) & (c | d) & (e | f).  It's much more
likely that someone would write ~( (~a & ~b) | (~c & ~d) | (~e & ~f)). 
Which could of course be written as ~(~a & ~b  |  ~c & ~d  |  ~e & ~f)  if
| was lower precedence than &.  I think it's just easier for most people
to get their heads around the meaning this way.

It's also what people coming from most other programming languages (that
have infix operators) expect.  Why upset them?


The other common use of mixing & and | in the same expression is the Perl
habit of saying:  this & that & the-other | die.  This works fine if
either & and | are the same priority and left-associative, or if | is
lower priority than &.


This whole issue isn't a real biggie -- if you're mixing | and & in the
same expression then it's not a bad idea to use () anyway -- but it's
gratuituously incompatable with most other programming language for no
good reason that I can see.


I only found one place that would be potentially affected -- used both &
and |, and not forced using ()'s -- by the proposed change in 167,000
lines of Dylan source code.  And that turned out to be a Perl-style error
bail-out that will actually work correctly with either the status quo or
the proposed change.

define method find-slot
    (decl :: <structured-type-declaration>, name :: <string>)
 => (result :: <declaration>);
  decl.members
    & any?(method (member) member.simple-name = name & member end method,
           decl.members)
    | error("No such slot: %s", name);
end method find-slot;

So the bottom line is that the net recoding required in d2c/Mindy, the
common libraries, the tests ... everything is: zero.


I don't know if you're reading gd-hackers, Chris, but Carl L. Gay wrote today:
> There was serious discussion about doing this for Harlequin
> Dylan before the group tanked, but it was deemed too 
> incompatible at the time.  Now might be a good time to
> raise the issue again on the newsgroup.  I guess as it 
> stands Dylan is incompatible with C and Java on this 
> issue, which seems unnecessary in this case.


-- Bruce
References: