gjc@batserver.cs.uq.oz (Cumming) (09/09/89)
Again with respect to the call for suggested changes to the language, may I suggest the following 1. The unwieldy not P or Q not P or else Q be supplemented by P implies Q P limplies Q where limplies is a "lazy" implies, i.e. Q is not executed if P is false, as per not P or else Q. Maybe not a great change, but certainly makes reading an assertion a bit easier. These queries have arisen out of my attempts to formalise the translation of specifications written in the Z specification language into Eiffel. G.J.Cumming
bertrand@eiffel.UUCP (Bertrand Meyer) (10/07/89)
In article <1473@moondance.cs.uq.oz>, gjc@batserver.cs.uq.oz (G.J. Cumming) suggests two new operators, implies and limplies, such that P implies Q means not P or Q P limplies Q means not P or else Q In fact, version 2.2 includes the implies operator, with the semantics he suggests for limplies (or else). It was not felt necessary to include two versions, and the most useful semantics seemed to be the non-strict one (``non-strict'' operators being those such as `and then', `or else' and the new `implies' which may yield a result even when one of their operands is not defined). As a minor syntactic comment, no Eiffel keyword is an abbreviation, so that a different name would have had to be found for `limplies' had two operators been retained. > Maybe not a great change, but certainly makes reading an > assertion a bit easier. Indeed, `implies' has so far been used essentially in assertions, and many assertions of the Data Structure Library have been made simpler through its introduction. -- Bertrand Meyer bertrand@eiffel.com
wsmith@mdbs.UUCP (Bill Smith) (10/18/89)
>In article <202@eiffel.UUCP>, bertrand@eiffel.UUCP (Bertrand Meyer) writes: > As a minor syntactic comment, no Eiffel keyword is an abbreviation, so > that a different name would have had to be found for `limplies' had > two operators been retained. "elsif" is an abbreviation. (So much for dogma.) Bill Smith pur-ee!mdbs!wsmith (my opinions only)