Re: Problems and questions about CASL concrete syntax

[Till Mossakowski <till@Informatik.Uni-Bremen.DE>]

Dear Peter,

> > - SYMB-ITEMS are used in a comma-separated list in RESTRICTION.
> > SYMB-ITEMS internally can contain a list of comma-separated SYMBs at
> > the end as well.  So basically the grammar allows
> > 
> > 	hide x, op y, z
> > 
> > to be grouped as in (curly braces are meta-symbols)
> > 
> > 	hide x, {op y}, z    or    hide x, {op y, z}
> > 
> > Obviously, the second is the intended grouping, but the grammar does
> > not reflect this.  (This can be handled by forcing the context free
> > parser to use the first grouping consistently and then massaging the
> > AST later to get the second grouping.  I haven't found a way yet to
> > force the second straight away with my tools.)
> 
> The intention here was that all groupings should be semantically
> equivalent, so the parser is free to choose any of them.

Are you sure?
If z is the name of both a predicate and an operation symbol,
the groupings are not semantically equivalent: with the first
grouping, both the operation and the predicate z are hidden,
while with the second grouping, only the operation is hidden.
Thus, the parser always should deliver the second grouping.

> > For bison one needs
> > 
> > 	SOME-SORTS ::= SORT | SORT star SOME-SORTS
> > 
> > where star is distinct from anything else but a single star.  If this
> > lexeme is acceptable in other places as well it has to be mentioned
> > there explicitly.  So there is a rule saying that
> > 
> > 	TOKEN ::= ... | `<' | `*' | ... 
> > 
> > This might not be an issue for other parser technologies, it took me
> > quite some time to figure this out, however, no matter how obvious it
> > looks to me now I have found it.
>
> I'm afraid that this complication arising from the double usage of
> symbols such as `<' is something we have to accept.

We also had to solve this problem, in the same way.
 
> > - The disambiguation rules say that `=>' groups to the right and `if'
> > groups to the left.  Also `A => B if C' is not allowed. This does not
> > go together with the way in which precedence and association is
> > specified in bison: Each keyword (like %left or %right) introduces a
> > new precedence level.  The order in which the declarations appear
> > determine which one binds tighter.  So I wouldn't know how one could
> > get the intended behaviour of `=>' and `if' in the context free
> > parsing stage.  
> 
> I wonder how this is achieved in the other generated parsers?
> Frederic, Till & Markus, Mark: would you please let Axel know
> (if you haven't already done so).

Indeed, this is a bit tricky, but can be achieved by introducing
new non-terminal symbols in the grammar. I will send you our grammar.
 
> Good - but perhaps the difficulty you had lends support to Markus's
> proposal to make the semicolon always legal at the end of a list of
> VAR-DECLs?  Would it give problems for the other parsers to generalize
> the language this way?

For the Bremen parser, I do not think so.

> > - I have found the abstract syntax confusing at first because it
> > conveys two relations with the same notation: On the one hand it
> > defines a subsort relation on tree sorts (e.g. AXIOM is-a FORMULA).
> > On the other hand it defines a representation of these trees
> > (PRED-NAME is-part-of PRED-DEFN).  I found it difficult to read from
> > the abstract syntax the intended representation of the trees using a
> > type system like, e.g, ML's.
> 
> I think that the (somewhat longer) grammar in App. A of the Summary
> has the property that each production can easily be identified as of
> one type or the other.  App. B is more concise, but not so good in
> that respect.

We have follow App. B. But the general problem is that programming
languages rarely support subsorts.

Greetings,
Till