[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[CoFI] Concrete + Abstract Syntax: minor comments
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]