|[11 earlier articles]|
|Re: Dangling else firstname.lastname@example.org (Russ Cox) (2006-03-06)|
|Re: Dangling else email@example.com (Marco van de Voort) (2006-03-11)|
|Re: Dangling else Brian.Inglis@SystematicSW.ab.ca (Brian Inglis) (2006-03-11)|
|Re: Dangling else firstname.lastname@example.org (2006-03-14)|
|Re: Dangling else email@example.com (Karsten Nyblad) (2006-03-15)|
|Re: Dangling else DrDiettrich@compuserve.de (Hans-Peter Diettrich) (2006-03-15)|
|Re: Dangling else firstname.lastname@example.org (Marco van de Voort) (2006-03-15)|
|Re: Dangling else email@example.com (2006-03-16)|
|From:||Marco van de Voort <firstname.lastname@example.org>|
|Date:||15 Mar 2006 22:11:19 -0500|
|Organization:||Stack Usenet News Service|
|References:||06-02-154 06-02-168 06-03-008 06-03-023 06-03-041|
|Posted-Date:||15 Mar 2006 22:11:19 EST|
On 2006-03-14, Henry Spencer <email@example.com> wrote:
> No, I'm thinking of things like `(x < y) and (q > 4)', where the
> parentheses are mandatory because the Boolean-condition operators
> share the precedence levels of the arithmetic operators rather than
> having their own.
> Wirth himself, in his 1975 Pascal retrospective ("An assessment of the
> programming language Pascal", IEEE TransSoftEng 1.2, June 1975), said:
> "In retrospect... the decision to break with a widely used tradition seems
Well, I had no formal boolean math classes before being exposed to
Pascal, so I can't fully judge that.
However I think a case could be made for consistency as much as for
legacy. Specially since in practice hordes of programmers just choose
to avoid these problems, parenthese each ambiguous case anyway, in any
language. (and by that "ambiguous" I mean as decided in a split
second, no thorough analysis of typing, scope and expression).
This shows that the field of software engineering and mathematics are
simply not fully equivalent. YMMV depending on personal history of
Return to the
Search the comp.compilers archives again.