[CoFI] CASL concrete syntax

[pdmosses@brics.dk]

The concrete syntax proposal has been updated, and can be found at:

  http://www.brics.dk/Projects/CoFI/Documents/CASL/SyntaxIssues/
  ftp://ftp.brics.dk/Projects/CoFI/Documents/CASL/SyntaxIssues/

The following extract is provided as an appetizer!

Peter

----   --------------------------------------------
\  /  | Peter D Mosses         <pdmosses@brics.dk> |
CoFI  | Common Framework Initiative  - Coordinator |
/  \  | WWW URL: http://www.brics.dk/Projects/CoFI |
----   --------------------------------------------


                          Concrete Syntax for CASL
                     Basic and Structured Specifications

                               Michel Bidoit
                              Christine Choppy
                            Bernd Krieg-Brückner
                              Peter D. Mosses
                               Frédéric Voisin

                              18 December 1997

Abstract

     This proposal for the concrete syntax of (basic and structured)
     specifications in CASL has been developed from the earlier
     proposals from Bremen [KB97] and Paris [VBC97]. Much of it is
     supported by all the authors. However, there are still some points
     where they have not yet been able to reach agreement on the design
     of the concrete syntax, despite protracted discussions. These
     points are listed in Appendix A. All comments on these or other
     points are very welcome, and should be sent to the CoFI Language
     Design mailing list, cofi-language@brics.dk.

          Deadline for comments: Thursday 8 January, 1998!

     Any adjustments to present proposal are to be decided at the
     meetings to be held in Bremen, 9-11 January, 1998. Those who are
     not able to attend the meetings are requested to use the mailing
     list to make known whatever objections or suggestions they might
     have.

          N.B. The authors believe that they have now produced a
          usable proposal, and that further discussions between
          themselves would probably not lead to significant
          improvements. Moreover, this task of concrete syntax
          design has already taken far too long!

     An extension of this proposal to architectural specifications is
     to follow as soon as possible. Version 0.99 of the CASL Summary is
     to incorporate named morphisms and the push-out semantics for
     generic specifications, both involving additional abstract syntax;
     the concrete syntax will then be extended accordingly.

     After that, further changes are envisaged only when motivated by
     parser implementation issues, or by examples of (useful)
     specifications that clearly demonstrate infelicities of the
     proposal.

     Examples of specifications illustrating the proposed concrete
     syntax are available as a separate document [BCKB+97]. Readers are
     encouraged to test the proposal on their own specifications.


Appendix A:

CONTROVERSIAL ISSUES FOR DISCUSSION

The issues still regarded as controversial are listed below, roughly in the
order in which the corresponding constructs are presented in the concrete
grammar.

Datatype declarations:

     A last-minute change has been made here! The usefulness of partial
     constructor functions, and for explicit indication of whether selectors
     are total or partial, was realized very recently, and has only been
     briefly discussed between some of the authors of this proposal. The
     coordinator was encouraged to make such a change at this late stage
     partly because this had the benefit of eliminating several other
     outstanding issues. Indicating totality or partiality of constructors
     and selectors requires an extra component in the abstract syntax--but
     this then simplifies the intended semantics, it seems, as well as
     providing extra generality.

Operation declarations and predicate types:

     Acceptable alternatives to the `pred(...)' notation for predicate types
     have not been found.

     The use of `pred' in predicate types, however, seems to rule out the
     possibility of replacing the keyword `op' by `fun' and `pred', which at
     least one of the authors would like to see (despite the fact that the
     use of `op' was agreed at the meeting in Amsterdam).

Function declarations and attributes:

     No agreement for making the concrete syntax of attributes look like
     higher-order axioms has been reached--nor have examples of practical
     examples that exploit the extra generality of separating attributes
     from declarations been found. The coordinator has therefore chosen to
     adopt the conservative proposal of listing attributes in function
     declarations, essentially as in OBJ3. However, since functions may be
     redeclared in CASL, it is still possible to introduce attributes for
     previously-declared functions in an extension specification.

Existential equations:

     Is the proposed input syntax `T=.=T', displaying as $T \doteq T$,
     acceptable? Previous proposals have included `T=e=T' and `T=d=T' (which
     is more mnemonic of definedness'). Admittedly this use of $T \doteq T$
     is unconventional, and there is also the problem that readers may not
     notice the raised dot at all, unless it is made bolder. Anyway, this is
     an isolated issue, and the symbol to use here can be changed without
     much bother if a consensus can be found for that. The present proposal
     seems at least to be aesthetically pleasing.

Precedence in terms and mixfix notation:

     The acceptance of ungrouped iterations such as `a+b+c' now depends on
     the declaration of the associativity attribute for (supersorts of) the
     sorts of the arguments. It needs to be clarified whether this gives
     significant difficulties for the implementation of parsers. The issue
     of parsers taking account of so-called precedence annotations to allow
     the omission of grouping parentheses needs further investigation, but
     might provide the convenience requested by some of us--without
     complicating matters for those who find the current proposal for
     disambiguation adequate.

     The current proposal is to allow (but not require all parsers to
     implement!) full mixfix notation. One of us objects to this, claiming
     that use of `symbols' such as `__ __' confuses OBJ3 users. The
     coordinator is perhaps not the typical OBJ3 user, but has not himself
     experienced confusion (from this cause!) when reading such
     specifications. Comments on this issue from other users of OBJ3 (or of
     other languages supporting full mixfix notation, such as ASF+SDF) are
     particularly welcome.

Structured specifications:

     The current proposal needs public discussion. The keywords for UNION
     and EXTENSION seem to be a reasonable compromise between the various
     alternatives. The concrete syntax grammar proposed here suggests
     simplifying the abstract syntax grammar to make EXTENSION and CONS-EXTN
     binary, and to generalize the abstract syntax for REVEALING to allow
     SYMB-MAPs there as well as in TRANSLATION.
_____