Re: CASL v.1.0: UNIT-SPEC-NAMEs

[Peter Mosses<mosses@csl.sri.com>]

Dear Andrzej,

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

OK.  I'm in the process of incorporating the proposed amendments into
the new version 1.0, but I have other urgent (non-CoFI) things to do
too at the moment, so further comments sent by MONDAY evening
(EU-time) should still be in time - assuming that they won't be
controversial...  :-)

> 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

Thanks for your detailed analysis of this point.  Let me simply agree
with you that those implementing parsers would probably not like:

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

The following would be OK, but probably too tedious in examples:

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

I'm inclined to go with:

> 3. Restore UNIT-SPEC ::= SPEC-NAME 

in the abstract syntax - but not in the concrete syntax!

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

All that is needed, I think, is to indicate which abstract syntax tree
the parsers should produce, without changing the concrete grammar from
v1.0-DRAFT.

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

Right.  (We'll need to do something similar regarding the ambiguity
that I failed to fix in symbol maps, reported by Till earlier on 
Oct 15.)

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

Just the backslashes before the braces` in the LaTeX source... :-(

> And perhaps the order of the clauses for GROUPED-UNIT-TERM should be
> the same as for GROUPED-SPEC?

OK

Many thanks,

-- Peter
_________________________________________________________
Dr. Peter D. Mosses             International Fellow  (*)

Computer Science Laboratory     mailto:mosses@csl.sri.com
SRI International               phone: +1 (650)  859-2200 ! CHANGED
333 Ravenswood Avenue           fax:   +1 (650)  859-2844
Menlo Park, CA 94025, USA       http://www.brics.dk/~pdm/

(*) on leave from DAIMI & BRICS, University of Aarhus, DK
    also affiliated to CS Department, Stanford University
_________________________________________________________