Discussion on flattening

[cerioli@disi.unige.it (Maura Cerioli)]

Dear Bernd,
I'm getting more and more confused,
Are we discussing
1 the language described by the grammar (ie CASL AS),
2 the grammar used to describe it or
3 the notation used to write such a grammar?
I'm mostly interested in 1, don't care *at this moment* about 3 at all, and
think that 2 is untimely (and has probably many answers), while from your
answer I got the feeling that your main concern is 2.

I wrote:
>...omissis...
>Therefore, summarizing, I would leave the grammar as it is in the summary,
>possibly producing more concise grammar(s) for the tools to work on and/or
>for getting a grammar that is easier to grab at first glance (??maybe I'm a
>bit overoptimistic, here :-) ) only when we have produced a final version.
You answered
>Indeed, my comments are a lot w.r.t. interchange format, but I think it
>would be very good if we only had one and not several formats; note that
>implementors would perhaps want to use the Semantics as guidelines (!!)
Actually, I hope so, too! It would be unfair that we take the pain of
giving a semantics and then the implementors disregard it and implement
something else ;-)
But this does not mean that they must use the parse trees of the current
grammar as internal representation of the language terms.
The only relevant point is that their internal format unambiguously
represents the element of the language and not the way we choose to build
them in our grammar (or not? maybe here is the problem of my
non-understanding).
I expect that we will have more than one grammar, even when we will have a
final version of the language abstract syntax.
Indeed, consider for instance the grammar as it is now and look at the
example you give
    UNIT-SPEC ::= SPEC-NAME | UNIT-TYPE
that is, I suppose, one of the cases described by Andrzej as
>One is a true inclusion, were not semantic coercion is required, and the
>meaning of a phrase in a subclass is exactly the same as the meaning
>of this phrase in a superclass.

This classification is useful, because it helps the presentation of the
language to a human user, and it is harmful, because it introduces a
distinction, and hence a complication, useless from a programming point of
view.
(Actually imho I think that Andrzej's comments about the "distinction" lead
to have a simplified grammar for the description of the semantics.
Unfortunately, the definition of the semantics is affecting the language
design and obviously we cannot give the semantics if we don't fix the
language, so we are looping. But I expect that the final version of the
semantics will be presented on a simplified grammar.)

The same happens, for instance, in the productions for BASIC-ITEM.
Why should we distinguish among SIG-DECL and VAR-DECL, AXIOM...? Why not to
group all the declarations and all the property requirements and have
BASIC-ITEM::=DECL | PROPERTY
DECL::=SORT-DECL |...|VAR-DECL
PROPERTY::= AXIOM | SORT-GEN
or no distinction at all, all kinds of basic-items flattened at one level?
I suppose that the "best" classifying depends on the use we want to make of
the grammar.
For this reason I would like to reach a firm definition of CASL AS (in the
sense of the language described) and only at that point propose alternative
grammars for different aims.
I hope that the implementors wont start working now, before we have a fixed
language, so the issue of the best grammar to present the interchange
format may wait a bit.

>Distinction between FUN and PRED
......
>
>OK, that's it, and it is *a lot* in the concrete syntax. Context-free
>parsers will have to restructure/copy the whole tree for formulae/terms
>during context analysis (more reason for flattening :-)
Isn't it possible to have in the concrete grammar one non-terminal for both
function and predicates (or better for their names and concrete
applications) and use it in both cases? Maybe this is a stupid idea,
suggested by my lack of familiarity with language design, but I don't see
the need for a 1-1 correspondance between AS and CS.

Best regards
Maura