[Prev][Next][Index]
Puzzling syntax

To: larchinterest

Subject: Puzzling syntax

From: davidg@oracorp.com

Date: Wed, 8 Dec 93 17:52:31 EST

DeliveryDate: Thu, 09 Dec 93 06:47:07 0800
I've been looking at the LSL 2.3 Reference Grammar and I'm puzzled by
the syntax for a "consequences":
consequences ::= IMPLIES
{ traitRef*, genPartition* eqPart
 [traitRef+, genPartition+] eqSeq }
conversion*
As I read this the consequences clause
1. implies
Container
a == b
is syntactically illegal  because after a traitRef the "equals"
keyword cannot be omitted unless there also occurs at least one
genPartition. The situation could be repaired by omitting the
traitRef
2. implies
a == b
or by adding the "equations" keyword
3. implies
Container
equations
a == b
or by sticking in a genPartition
4. implies
Container
S generated by f,g
a == b
This rule strikes me as peculiar and unnatural. Would anything useful
be lost by simplifying the syntax to
consequences ::= IMPLIES
traitRef*, genPartition* eqPart
conversion*
After this simplification only 3 would be legal and the user who
wanted to express the meaning of 2 would have to use, instead
2'. implies
equations
a == b
It's hard to claim that this is unnacceptably prolix, given that the
same maneuver is required in a propPart:
asserts
equations
a == b
The simplification would make the syntax of consequences a natural
generalization of that for propPart:
propPart ::= ASSERTS
genPartition* eqPart
The current rules strike me as so odd that I figure there must be some
good reason for it that I'm missing.
 David Guaspari
davidg@oracorp.com