Re: [CoFI] CASL Concrete Syntax - addendum!

[pdmosses@brics.dk]

[Sorry, but what with concentrating on forwarding all the other
 messages, I'd forgotten to send one of my own - promised to Frederic
 Voisin last week, following some discussions.  I discovered it only just
 now, while checking through my archives.  So I hope the proposal below
 won't turn out to be terribly controversial...  If I've neglected to
 forward any other messages, please let me know straight away!
--PDM]

Frederic wrote:

> I have trouble with the "free" keyword being used both at the BASIC-ITEM
> level and at the Structured Spec level:
> 
> What is the meaning of "free" in sentences like:
> 
> spec S = free type T ::= a | b ; sort S
> 
> Is it
>     free (type T ::= a | b  ; sort S) -- free spec with two basic items
> or
>    (free type T ::= a | b) ; sort S   -- spec with two basic items.
> ????

It was intended to be the latter.

> Note that in sentences like 
>    sort s1 ; free type T ::= a | b ;
> the only possible way is to glue the "free" with "type". Hence, in the
> conflicts related to the above ambiguity, I will have to privilege the
> second of the two possibilities and get a basic-item that should be
> embeddable in any surrounding context. 
> Maybe I could live with that conflict and solve it in the above way,
> but I find it potentially dangerous for the user.

I guess the user would realize any mistake when seeing a pretty-printed
formatted display, where the grouping should be emphasized by the
indentation.  

However, it might be more prudent to REQUIRE braces with "free"
whenever it is used at the structured level:

  free { type T ::= a | b  ; sort S ; ...}

I'm also worried by the possibility of unexpected grouping in:

  free ...  hiding ...

where in practice i suppose one would usually want the hiding to take
place AFTER the free extension, i.e.,

  { free ... } hiding ...

- in contrast to what the current disambiguation rules determine!
Note that the extent of "free" may affect the semantics of the
specification, so this is NOT generally a harmless ambiguity...

It seems that all these problems could be eliminated by changing the
concrete grammar to:

  SPEC            ::= BASIC-SPEC 
                    | SPEC RENAMING
                    | SPEC RESTRICTION
                    | SPEC and SPEC and...and SPEC
                    | SPEC then SPEC then...then SPEC
!                   | free GROUPED-SPEC
                    | local SPEC within SPEC
!		    | GROUPED-SPEC

! GROUPED-SPEC    ::= SPEC-NAME
                    | GEN-SPEC-NAME [ FITTING-ARG ]...[ FITTING-ARG ]
!                   | { SPEC }

(The abstract syntax would remain unchanged.)

The only effect of this change on examples is that one generally 
has to write "free { ... }" whenever a FREE-SPEC is intended;
a FREE-DATATYPE in a BASIC-SPEC would still be written without the
braces: "free type/types ...".  There is admittedly a slight
non-uniformity here in relation to SORT-GEN, as adding braces in
"generated { ... }" does not provide a structured specification; 
but this seems inherent in the different treatment of freeness and
generatedness constraints in CASL.

Peter
_________________________________________________________________
=========   Peter D. MOSSES              Associate Professor, PhD
==== ====   BRICS                        mailto:pdmosses@brics.dk
=========   Dept. of Computer Science    == pdmosses@daimi.aau.dk
==== ====   University of Aarhus         http://www.brics.dk/~pdm
==== ====   Ny Munkegade, bldg. 540      Telephone: +45 8942 3364 
==== ====   DK-8000 Aarhus C, Denmark    Telefax:   +45 8942 3255