Re: concrete syntax problems in arch spec and views

[pdmosses@brics.dk (Peter D. Mosses)]

At 11:58 19/6/98, Christophe Tronche wrote:
>Hello, CASL people.
>
>Since it seems we're not in advance, I post this to both cofi-tools
>and cofi-language. My apologies to those of you who get the message twice.

Perhaps we could keep this to cofi-tools for now, and send a summary of the
conclusions/recommendations to cofi-language later.  (We should perhaps
have created a cofi-concrete-syntax list, but it's a bit late for that
now...)

>Here are some ambiguities we found in our effort to raise the Cachan
>parser to the 0.99 level. This effort is now complete, but not yet
>extensively checked.

It seems that the problems that you report below are essentially concerned
only with architectural specs and views.  The situation with both of these
is that the concrete syntax is still quite tentative, and adjustment
concerning precedence has still to be made.  We have had to delay complete
the prototyping of the concrete syntax grammar using ASF+SDF until examples
of arch specs were provided; fortunately, the release of an update of Note
M-4 on arch specs WITH examples is imminent, so I hope that we'll be able
to finish the design of the concrete syntax in this respect sometime next
week.  Sorry that I wasn't more explicit in the v0.99 Summary (App C) about
the precedence issues for arch specs and views not having been settled yet.

Moreover, although I haven't yet had time to check it with ASF+SDF, it
looks as if most of the problems reported with grouping would disappear
altogether if one insisted that a SPEC used in a UNIT-SPEC or ARCH-SPEC
should always be a GROUPED-SPEC, so that the {...} around lists of
basic-items prevent confusion between the different uses of :, ->, etc.  In
practice I suspect that the SPEC would usually be a SPEC-NAME or
instantiation, so a restriction to a GROUPED-SPEC should be acceptable.

Anyway, thanks for pin-pointing the problems!  I've indicated below how I
personally would like to see them resolved, but of course others may have
different prefererences (and they should then please say so straight away).

Cheers

Peter

>======================================================================
>
>Whom does the -> sort belongs to ?
>
>
>          UNIT-SPEC                UNIT-SPEC
>             |                         |
>      +------+-+---+                   |
>      |        |   |                   |
>     SPEC      |   |                 SPEC
>      |        |   |                   |
>     ...       |   |                  ...
>      |        |   |                   |
>   OP-TYPE     |   |                OP-TYPE

I assume that you meant OP-ITEM rather than OP-TYPE above?

>      |        |   |                   |
> +----+----+   | SPEC-NAME        +----+----+---+---+
> |         |   |   |              |         |   |   |
>op NAME : SORT -> ID             op NAME : SORT -> SORT

The former ought to be written { op NAME : SORT } -> ID ,
the latter ought to be written { op NAME : SORT -> SORT }
and there is no ambiguity.

>Idem with SORT *...* SORT -> SORT and SPEC *...* SPEC -> SPEC

{...} are always to be required when the BASIC-SPEC is intended.

>UNIT-SPEC: axioms x = y * z -> ID
>Does this mean (axioms x = y) * z -> ID or (axioms x = y * z) -> ID

No, one should write { axioms ... } when it occurs in a UNIT-SPEC.

>etc, etc, etc...
>
>We can't have together ; optionnal, * as a function, * in OP-TYPE and
>* in UNIT-SPEC

- except when explicit grouping of basic-specs by { ... } is required
(as in structured specs), I hope!

>======================================================================
>
>Every ; introduced in the architectural specifications conflicts with
>those already existing (to solve the problem, I had to make all of
>them mandatory, including the ones at the end of basic items).

I hope that replacing SPEC by GROUPED-SPEC in arch specs will make these
conflicts regarding ";" disappear...

>======================================================================
>
>
>UNIT-DECL: UNIT-NAME : UNIT-SPEC given UNIT_NAME hide ID1, ID2
>
>is this
>
>UNIT-DECL: UNIT-NAME : UNIT-SPEC given (UNIT_NAME hide ID1), ID2
>or
>UNIT-DECL: UNIT-NAME : UNIT-SPEC given (UNIT_NAME hide ID1, ID2)

It is not allowed, as explicit grouping is required.

>======================================================================
>
>consider view V : A -> sort B; C = D
>
>                 SIG-ITEMS
>                    |
>               +-----------+
>               |           |
>               |        ISO-DECL
>               |           |
>               |      +----+----+
>               |      |         |
>view V : A -> sort B; C       = D
>
>
>              SIG-ITEMS    SYMB-MAP-ITEMS
>                  |             |
>               +--+---+         |
>               |      |         |
>view V : A -> sort B; C       = D
>
>(there are many variation by putting a formula with a "=" at the end of
>a PRED-ITEM in place of C, etc...)

One should allow only GROUPED-SPECs in views too.

>--
>Christophe Tronche              tronche@lsv.ens-cachan.fr
>Tel: (33) 01 47 40 28 48        Fax: (33) 01 47 40 28 65