[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[CoFI] comments on concrete syntax
Dear Peter,
happy New Year! looking forward to seeing you all soon!
let me state first that I am generally quite happy about the (almost)
final outcome of the syntax battle; we all have to thank you for the
energy you expended in smoothing things out!
[Thanks for your careful reading of the documents, and positive
reactions! --PDM]
I also approve of your decisions on the controversial issues (except for
very few things below). So my comments are not intended as bickering but
rather perhaps material for the final discussion. Some are purely
cosmetic in the presentation of the document [these are proposals and
need not be discussed further] and come at the end.
Data Type Declarations
----------------------
I am not at all happy with the outcome here. I see the logic behind it,
but the fact is that the standard case (for my taste anyway since this
is the normal situation in programming languages) is now punished by the
string of keywords
freely generated sort Color ::= red | green | blue
Moreover (and this I think is perhaps even more serious) the case where
later extension of alternatives is possible is now the short one
sort ExtendableColor ::= red | green
This looks error prone to me for the uninitiated user, and encourages
the wrong case by being short.
My proposal is to use ">" (or ">:=" or such like) for the extensible
case and "::=" for the "freely generated" case, and to express the
"generated" case with constraints by structured specifications only;
these show the resp. grouping of the items together much better anyway.
Union
-----
While I like all the "in the large" notation now, I do not see the need
for the keyword "use" at all; on the contrary, I find it confusing for
the user that it is required in
use A and B then C
but not in
A then C
where, presumably, A is "used" as well in the sense that it is "imported
by name from the environment".
My proposal: eliminate "use".
[Would you then give "A and B" higher precedence than "B then C", or
require explicit grouping braces? --PDM]
Grouping in Structured Specifications
-------------------------------------
Looking at the examples, I am a little unhappy that there are no
braces required (although possible) around BASIC-SPEC. I would be much
happier, if braces were required (and parentheses were used for
grouping; why not as anywhere else?). [The use of braces for grouping
larger constructs is familiar from both programming languages (C,
Java) and specification languages (CafeOBJ). It assists error
recovery when a parenthesis is omitted. If one uses parentheses
everywhere, one ends up with something looking like Lisp... --PDM]
Then the distinction between the "in the large" and the "in the small"
parts would become clearer for my taste. In any case, I find the
optional "end" quite clumsy. Either it is necessary for parsing or
not; or it is a good idea to delimit by grouping or {}, then [see
above].
Disambiguation
--------------
The generalised cases for MIX-ID are the wrong way around for postfix
and prefix. [You're right, sorry! --PDM]
I assume you still want postfix to bind stronger; then there is the
problem with HO application (which is like generalised prefix) being
weaker than postfix; this is not mentioned anywhere. [Please give an
example illustrating the problem, or refer us to where to look in a
previous note or message. I'm don't have your previous explanations
of this issue to hand (and I suspect that other readers may have the
same problem...) --PDM]
I presume that the need for the presence of grouping parentheses in the
abstract syntax is only necessary INITIALLY (i.e. before
context-sensitive disambiguation) and not in the final AS; otherwise
this is a serious issue for discussion in the tools group.
[Right - there is indeed no AS construct merely for grouping. But
note that tools may keep the information about where grouping
parentheses were originally as annotations on nodes (it may be needed
when formatting). --PDM]
[cosmetic] final paragraph: "use prefix" should read "use ordinary
function".
I am opposed to anonymous ("invisible") operators from a readability
/understandability point of view (apart from parsing problems and HO
application); I think this warrants some more discussion or perhaps a
users response.
[Under "Controversial Issues for Discussion", App. A of
CASL/SyntaxIssues, we appealed for comments on this issue from users.
Although we can't conclude much from the current lack of comments
about this from others, the current design does follow the experience
of an existing language, OBJ3, and will persist unless someone
actually illustrates the claimed problems with allowing e.g. "__ __"
as an op symbol. --PDM]
Lexical Syntax
--------------
There should only be one place for the brackets of compound identifiers,
thus it is not appropriate at the MIX-ID level as there could be several
interspersed in an ID then. [Then for an INFIX, should it be in the
middle or at the end? --PDM]
I am still against ".WORD" since it precludes dot notation in extensions
and I do not see the need for it.
"==" must go in the list of complete SIGNS. [Sorry, this was a
formatting mistake: there is actually a raised dot between the "="s in
the source, but LaTeX ignored it. There was no intention to prohibit
the use of "==" as an op symbol. --PDM]
I quite like the solution with all the restrictions etc. However, I
would make a special case for {} and [], deleting them from SIGNS, or
including them both; in any case, asking for them not to occur as single
characters, i.e. "[|...|]" is allowed, but "[...]" is not.
--- cosmetic only below ------
[cosmetic]
- make single quotes around "::=" etc. , i.e. `"::="´
- include `"|->"´ (see below)
[cosmetic]
ARG-DECL ::= VAR-DECL;...;VAR-DECL
[cosmetic]
I would prefer if EMPTY could be avoided (preferably altogether).
Candidates for expansion (and elimination) are
FUN-ATTRS, PRED-HEAD AND OPT-FITTING.
I would, in any case, expand OPT-FREELY since it is clumsy and the
resulting definition is clearer (for my taste):
SORT-GEN-ITEMS ::= generated SIG-DECL-GROUP
| freely generated SIG-DECL-GROUP
similarly
EXTENSION ::= SPEC then SPEC
| SPEC then conservatively SPEC
similarly
GEN-EXTENSION ::= PARAMS = SPEC
| PARAMS conservatively = SPEC
and then replace GEN-SPEC by GEN-EXTENSION
[cosmetic]
replace "|"-> by "|->"
label annotations: BASIC-ITEM does not exist any more; I suppose labels
occur AFTER the reps. keywords; so the wording has to be a bit careful.
________________________________________________________________
Prof. Dr. Bernd Krieg-Brueckner courier mail only:
FB3 Mathematik und Informatik MZH 8071, FB3
Universitaet Bremen Universitaet Bremen
Postfach 330 440 Bibliothekstr. 1
D-28334 Bremen D-28359 Bremen
Telefon: (+49) 421-218-3660 telefax: (+49) 421-218-3054
bkb@Informatik.Uni-Bremen.DE privat: (+49) 421-25-1024
http://www.informatik.uni-bremen.de/~bkb
http://www.uni-bremen.de/~sppraum