Re: BKB's comments on AS

[Bernd Krieg-Brueckner <bkb@informatik.uni-bremen.de>]

Dear Maura,
a quick answer after a superficial reading of your comments;
regards and thanks
Bernd

At 21:01 Uhr +0100 22.4.97, Maura Cerioli wrote:
>If I correctly understood Bernd's remarks, the more relevants points are
>the following.
>
>Flattening of the grammar
>-------------------------
>Here I see three separate issues:
>1 We adopted a concise presentation for the productions of our grammar,
>  so that we use the symbol ? to represent optionality (and * to represent
>  possibly empty lists) and hence we are grouping in one "meta-production"
>  the two actual productions with and without the optional part (the empty
>  list).
>  Thus in this respect, flattening is changing the meta-conventions, but
>  is not affecting the resulting grammar
>2 Since we decided to have no more than one terminal in each production we
>have
>  many non-terminals that are in some sense superfluous, as they appear
>  exactly once on the rhs of one production and once on the lhs of another
>  production.
>  There are other non-terminals satisfying the same property, that have
>  been introduced to make the grammar more readable.
>  All those non-terminals are redundant, from a parsing viewpoint and
>  should be avoided in the grammar defining the internal representation
>  (interchange format?). But they are harmless in the current grammar
>  and their elimination gives a grammar defining the same language (plus
>  some "useless" types).
>  However, I would be in favour of dropping the redundant ones, once we have
>  a final grammar and are producing the user manuals.
>  But now I would focus on the changes that affects the usability and
>  semantics of the language.
>3 We tried to capture through the grammar as many errors as possible,
>  as far as it was possible keeping the grammar readable (as I think
>  it is now).
>  Having less syntactical categories but much more static restrictions does
>  not sound sensible to me for the grammar used to explain the language
>  and to define its semantics.
>  I could be convinced that it is a reasonable choice for the grammar
>  describing the parsing trees of some sort of internal representation
>  (interchange format?).
>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.

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 (!!)

Indeed, you seem to have missed the point about avoiding extra *constructors*
(in the same way as it is possible to have just a sort name as an
alternative in a type definition in CASL). This has nothing to do with
having just one constructor per nonterminal, there is *no* harm introducing
extra nonterminals at all; eliminating them is *not* what I meant by
flattening. (I was just sometimes lazy in writing by not introducing extra
nonterminals for more clarity in the description).
As an example for what I want, cf. (in the present AS!):
      UNIT-SPEC ::= SPEC-NAME | UNIT-TYPE
where *no* extra constructor is used for UNIT-SPEC.
>
>Distinction between FUN and PRED
>---------------------------------
>I completely missed the point here, sorry.
>Unless you are saying that the freedom we are asking on the concrete
>representation of terms (captured at the fun-definition moment) is the same
>we would like to have on the concrete representation of atomic formulae
>(captured at the pred-definition moment) and hence similar rules have to be
>given for the two situations. In which case I don't see where is the
>trouble (I'm shortsighted not only in the real life, perhaps).

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 :-)

>Small proposals
>---------------
>>| SORT-GEN      ::=     sort-gen FUN-SYMB+ SORT
>>[order; why more than one SORT?]
>The order is immaterial to me.
>We need more than one because we can have mutually recoursive domains, I
>think.

OK

___________________________________________________________________
Prof. Dr. Bernd Krieg-Brueckner    courier mail only:
FB3 Mathematik und Informatik      MZH 8071, FB3
Universitaet Bremen                Universitaet Bremen
Postfach 330 440                   Bibliothekstr. 1
D-28334 Bremen                     D-28359 Bremen

Telefon: (+49) 421-218-3660        telefax: (+49) 421-218-3054
bkb@Informatik.Uni-Bremen.DE       privat:  (+49) 421-25-1024
http://www.informatik.uni-bremen.de/~bkb/