Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.csd.uwm.edu!gem.mps.ohio-state.edu!ginosko!uunet!kddlab!titcca!sragwa!wsgw!socslgw!diamond
From: diamond@csl.sony.co.jp (Norman Diamond)
Newsgroups: comp.lang.eiffel
Subject: Re: a < b < c
Message-ID: <10791@riks.csl.sony.co.jp>
Date: 4 Sep 89 07:23:19 GMT
References: <182@enea.se> <192@eiffel.UUCP> <1300@cheops.eecs.unsw.oz>
Reply-To: diamond@riks. (Norman Diamond)
Organization: Sony Computer Science Laboratory Inc., Tokyo, Japan
Lines: 26

In article <1300@cheops.eecs.unsw.oz> marku@cheops.eecs.unsw.oz (Mark Utting) writes:

>I like this abbreviated notation, with one slight reservation.

>"a < b <= c" is fine, but "d < e > f" seems to me to be less readable
>than using an explicit `and'.  I agree that it is not ambiguous given
>the above semantics, but it makes me wonder what the relationship between
>"d" and "f" is.

If you find "d < e > f" confusing, then vote against it at your
employer's style meeting.  Or forbid your subordinates to do it.

>The specification language Z allows any boolean relational operators
>to be abbreviated in this way, but published specifications seem to
>keep to the convention mentioned above.

This seems rather suitable.  Keep the rules simple so they can be
understood.  Bad programmers will be able to write bad programs, but
not everyone will have to.

--
-- 
Norman Diamond, Sony Corporation (diamond@ws.sony.junet)
  The above opinions are inherited by your machine's init process (pid 1),
  after being disowned and orphaned.  However, if you see this at Waterloo or
  Anterior, then their administrators must have approved of these opinions.