Re: Parenthesized Target Notation

Richard A. O'Keefe wrote:
> Ian Elliott <[email protected]> wrote:
> 	So no one appears to like the (|..|) parentheses (they remind me
> 	a little of hamburger buns) that the ECMA Eiffel standard
> 	specifies but I cannot help feeling that the attempt to remove
> 	special cases from the language by reducing a rule from "A
> 	semicolon is optional, except..." to "A semicolon is optional."
> 	is a laudable aim:  special cases complicate things - just look
> 	at the number of postings the pesky little ";" has generated.
> 
> I agree that trying to remove special cases from a language is a laudable.
> But a failed attempt to do so is still a *failed* attempt, and it is not
> laudable to adopt a failed attempt in a standard.
> 
I suspect that the simplicity of ECMA Eiffel's Semicolon Optionality rule, which 
can be summarized as "A semicolon is optional.", has an appeal that will urge 
the ECMA committee to work on fixing the language definition so that the rule is 
(always) satisfied.

Examples of the failure of the rule within an assertion have been posted. I 
suggested in an earlier posting that an amendment that could fix this would be 
to insist that every assertion clause has a tag (strictly speaking I should have 
used the term 'Tag_mark'). The current syntax is:

    Assertion                  = {Assertion_clause ";" ...}*
    Assertion_clause           = [Tag_mark] Unlabeled_assertion_clause
    Unlabeled_assertion_clause = Boolean_expression | Comment
    Tag_mark                   = Tag ":"
    Tag                        = Identifier

This would be amended to:

    Assertion                  = {Assertion_clause ";" ...}*
    Assertion_clause           = Tag_mark Unlabeled_assertion_clause
    Unlabeled_assertion_clause = Boolean_expression | Comment
    Tag_mark                   = Tag ":"
    Tag                        = Identifier

Does this amended syntax remove the requirement of sometimes having to use a 
semicolon to disambiguate? As I indicated in an earlier posting the problem is 
that the removal of a semicolon can result in the assertion being parsed so that 
it contains different assertion clauses. For this to happen two or more 
assertion clauses would have to lose their separate identity and be parsed as a 
sequence of different assertion clauses. For this to happen the division between 
the original assertion clauses would have to shift. No 
'Unlabeled_assertion_clause' ('Boolean_expression' or 'Comment') contains a ":" 
token, so ":" tokens would have to remain within 'Tag_mark's. Each 'Tag_mark' 
therefore retains its identity and as a result they continue to separate the 
original 'Unlabeled_assertion_clause's. The original assertion clauses therefore 
retain their identity, so all semicolons can be safely disposed of.

Substantiating the statement "No 'Unlabeled_assertion_clause' 
('Boolean_expression' or 'Comment') contains a ":" token" could be done by 
examining the right hand side of the 'Boolean_expression' production and the 
right hand sides of productions it contains and so on. I think no ":" token
would be found.

Okay, I admit the argument above is somewhat involved, may be better expressed, 
and may even contain an error, but I think it shows how it may be possible to 
construct an argument that demonstrates that Semicolon Optionality is sound in a 
particular case. The construction of similar arguments could be attempted for 
other occurrences of the semicolon. The one dealing with the compound construct 
(the list of instructions) could well be the trickiest!

And of course any future amendment to the language definition would have to be 
checked to ensure such arguments are not invalidated.

Arguments like the one above are hard work - perhaps there are simpler ways to 
establish the Semicolon Optionality goal. Whichever way, I think that the lure 
of stamping out the "may be optional but may not be optional" semicolon for good 
is such a strong one that I suspect an attempt will be made to fix the ECMA 
Eiffel language definition so as to correctly include the Semicolon Optionality 
rule.

  - Ian Elliott