[CoFI] Concrete + Abstract Syntax: minor comments

[Bernd Krieg-Brueckner <bkb@informatik.uni-bremen.de>]

Dear Peter et al.,

here are some last comments, mostly minor.

Concrete Syntax
---------------

Sorry to belabour it (but I did not have any reaction so far):
I would really like "lambda" in lambda expressions to be written (in the
input!) as "\" as in Haskell. In HO, when using continuations or monads,
lambda expressions are often "strung together" and compact notation is
important.

[The whole issue of concrete syntax for architectural specifications
 is still at the tentative stage, pending the appearance of examples...
 It's good to get comments on it; however, your motivation for the
 proposed change seems to presume that (i) CASL should use the same
 notation for functions both between algebras and within algebras, and
 (ii) it is possible to use continuation-passing or monadic styles of
 function composition within architectural specifications.  Surely
 both these issues are somewhat debatable?

 Moreover, using "\" for this purpose would prevent the same character
 being recognized as a complete TOKEN - perhaps a bit annoying for
 those wanting to use it for set difference, or for restriction in CCS?
 although display annotations should allow e.g. the input token "\\" to
 be formatted as "\".  My own suggestion would be to use "fun" instead
 of "lambda", now that its previous use has been taken over by "op".

 Anyway, it'd be useful to get an impression of the amount of support
 for "\" - just send comments to cofi-language and I'll summarize.
--PDM]

Why does the equivalence have two "==" in "<==>" all of a sudden? is
this intentional (as it does not appear in section 3)? I liked "<=>"
better.

[Sorry - this mistake crept in when the new concrete grammar was
derived anew from the optimized (rather than "collected") abstract
syntax grammar.  No change was intended, we stick to "<=>"!  --PDM]

Lexical Syntax
--------------

"[]" should appear in SIGNS.  [Right, thanks! --PDM]

Does "balanced" mean that only "{|__|}" is allowed, or also "{|__}|" ?

[Also the latter - but not "{[__}]", presumably! --PDM]

You may wish to include "{|" as an example of a complete token.

imports
-------

I seem to remember from some email that
        imports SP
        spec S [PAR1] [Par2] = ...
was regarded (more?) favourably by someone.

[I.e., instead of "spec S [PAR1] [Par2] imports SP = ..." --PDM]

Abstract Syntax
---------------

I think an extra constructor for
        gen-datatype DATATYPE-ITEMS
is needed

[Isn't is merely a special case of sort-gen SIG-ITEMS+, both regarding
syntax and semantics?  --PDM]

whereas SYMB-MAPS seems to be superfluous and could be replaced by 
        SYMB-MAP*

[As it seems that there will be no need to allow a RENAMING to be the
target of a VIEW, both RENAMING and SYMB-MAPS can be eliminated -
although I'd prefer to use SYMB-MAP+ rather than SYMB-MAP* unless
there is a need for the empty translation.  --PDM]

UNIT-IMPORT is missing 

[...in the "collected" grammar - right, sorry, although it can be
found in the optimized grammar: UNIT-IMPORT ::= unit-import UNIT-TERM*
--PDM]

Best regards

Bernd

[Thanks - and I hope you don't mind the extent of the comments that
I've inserted above, both as moderator and as editor of the CASL
grammar... --PDM]

[comments on morphisms will come separately]