CASL v.1.0: UNIT-SPEC-NAMEs

[Andrzej Tarlecki <tarlecki@mimuw.edu.pl>]

Dear Peter,

Unfortunately, it seems that I have hopelessly failed to meet the
deadline for comments on draft v.1.0 with careful reading through this
version of the summary. Sorry! I will do my best to read through it as
soon as possible and comment; perhaps I will still manage before the
final touches are made...

So now only one point within the design of architectural specification
part which I have noticed and want to object to:

Due to the context-free parsing considerations (I understand), the
following clause has disappeared:

        UNIT-SPEC ::= UNIT-SPEC-NAME

First, the category of UNIT-SPEC-NAMEs has been removed and replaced
by SPEC-NAMEs --- this is no problem for me.

Then the trouble was, as I recall, a potential ambiguity (in parsing
of the concrete syntax) between
        SIMPLE-ID qua SPEC-NAME qua UNIT-SPEC
and 
        (unit-type () (SIMPLE-ID qua SPEC-NAME qua SPEC))
                                        qua UNIT-TYPE qua UNIT-SPEC

(both are actually written simply as the underlying simple identifier).

I understand that the intention now is to replace the uses of a
SPEC-NAME bound to a UNIT-SPEC in a global environment by the latter
form
        (unit-type () (SPEC-NAME qua SPEC)) qua UNIT-TYPE qua UNIT-SPEC

However, this is quite ugly, since in this case,

        SPEC-NAME qua SPEC

can be given no semantic meaning (since UNIT-SPEC is not a SPEC in
general).

The current design would lead to the expected semantics for unit
typec, specs etc, with an extra clause that is a SIMPLE-ID is bound to
a UNIT-SPEC in the global environment, then the abstract syntax phrase
        (unit-type () (SIMPLE-ID qua SPEC-NAME qua SPEC))
                                        qua UNIT-TYPE qua UNIT-SPEC
is treated as a UNIT-SPEC with the appropriate semantics.

I find this rather ugly and certainly not clear from the language
design point of view.

As far as i can see there are three possible ways out:

1. Restore UNIT-SPEC ::= SPEC-NAME and allow for a bit of
context-dependend parsing: if a SIMPLE-ID is declared in the global
environment as a UNIT-SPEC, then when SIMPLE-ID qua UNIT-SPEC is
required, it is parsed as
        SIMPLE-ID qua SPEC-NAME qua UNIT-SPEC
Otherwise the parsing 
        (unit-type () (SIMPLE-ID qua SPEC-NAME qua SPEC))
                                        qua UNIT-TYPE qua UNIT-SPEC
is attempted.

2. Restore UNIT-SPEC ::= SPEC-NAME (or even UNIT-SPEC ::=
UNIT-SPEC-NAME in this case, I guess) and introduce some extra
keyword(s) or decoration(s) to the conrete syntax to remove ambiguity
(similarly as it is done now for the use of ARCH-SPEC-NAMEs). For
instance, we could require that a UNIT-TYPE comes always with some
keyword, even in the case when there is no genericity and it reduces
to the result specification.

3. Restore UNIT-SPEC ::= SPEC-NAME and and resolve the ambiguity by
giving the priority to the parsing 
        SIMPLE-ID qua SPEC-NAME qua UNIT-SPEC
over
        (unit-type () (SIMPLE-ID qua SPEC-NAME qua SPEC))
                                        qua UNIT-TYPE qua UNIT-SPEC
(This is perhaps standard enough...)

Then the semantics will cope correctly with two cases: SPEC-NAME being
a SIMPLE-ID bound in the global environment to a UNIT-SPEC, as well as
SPEC-NAME being a SIMPLE-ID bound in the global environment to a SPEC.

Would (any of) the above work?

My personal preference would be 1 above, but this may be unacceptable
to the parsing people. Then perhaps 3 would do?

Once more: apology for not having done my homework regarding the rest
of the proposal yet...

Best regards

Andrzej

PS. A tiny thing (typo?) I just noticed when looking at the concrete
syntax in the current summary: I think braces are missing in the
clause GROUPED-UNIT-TERM ::=  UNIT-TERM (or is it just my display?).
And perhaps the order of the clauses for GROUPED-UNIT-TERM should be
the same as for GROUPED-SPEC?

Best,

Andrzej