Re: BKB's comments on AS

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

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.

SORT <--> TYPE
---------------
In the presentation by Berndt I'm not getting the point, I'm afraid.
Indeed, it seems to me that leaving things as they are now and adding new
productions for the non terminal SORT in the HO extension (if any) gives
equivalent grammars.
A different issue is whether it is not better to call "types" what are now
called "sorts", following programming language, instead than algebraic
tradition.
However, this is a minor point wrt AS and could be discussed at the level
of concrete syntax.

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

"loose" and "tight" data type definitions
------------------------------------------
I had the impression that in Paris we reached the agreement that only
"loose" data-type definitions had to be regarded as basic items, while
"tight" data-type definitions had to be expressed as "persistent
extensions", interrupting in this way the non-linear visibility.
I think that this was due to problems in giving the semantics in case
several different "tight" data-types where mutually defined in terms of
each other (that's possible with non-linear visibility).
But maybe I'm confused, because the discussions about linear/non-linear
visibility, what is basic-item*, how we define the body of a generic-spec
where so intertwined.

Just my two cents
Maura



=============================================================================
 Maura Cerioli        | ph.:   +39-10-353 6731
 DISI                 | fax:   +39-10-353 6699
 Univ. di Genova      | email: cerioli@disi.unige.it
 via Dodecaneso 35    | ftp:   ftp.disi.unige.it/person/CerioliM
 16146 Genova, ITALY  | http:  www.disi.unige.it/person/CerioliM
=============================================================================