[CoFI] CASL Concrete Syntax (comments)

[Frederic.Voisin@lri.fr (Frederic Voisin)]

Dear members,

Some personal ideas about the look and feel of the concrete syntax:

- I do not like the notation for constants but will live with it if it is
  important for higher-order.

- I do not like the "predicate" notation, too verbose even for me :-)

- I still prefer using "f:S*S->S" for naming operators in case of
  ambiguity over (f: S*S-> S). As a user I feel simpler to have a
  special (lexical) notation for saying "here I need to name an object
  more precisely, but nothing special is involved", rather than using
  parentheses for function applications, grouping and naming... Note
  that with (f: S*S -> S), it is only when we reach the arrow that we
  know what is involved since (f:S * S) can also be valid input. I
  understand that if we later want to add string literals we probably
  want to use "..." for that purpose. Any other idea ?

  I think this question may occur again when dealing with structuring stuff
  (describing morphisms)

- We need abbreviations (for headers and operation attributes),
  singular forms of keywords

- I prefer using \/, /\ =>, <=> over their verbose forms, except for the
  negation (I assume being sometimes un-coherent). I do not like
  having both if and implies (personal taste).

- In "constructs" we use commas, where in declarations we use * in the domain.
  Couldn't we find something more uniform...

- I regret "in" now being a keyword...

- I would add "{" and "}" in the list of SIGNS, but with the restriction that
  they must always be well balanced (This restriction is needed for subsort
  declaration S = { x:A . P(x) } to work when the syntax of P uses { and }.

  Note that this cannot be extended to "[" and "]" since these symbols are
  currently being used for compound identifiers. In arbitrary terms we would
  not always be sure to know in any every case which meaning was intended.

- We still need experiments with the precedence levels and I hope to find
  examples in other people's mail. We should ask them to write those examples
  with as few parentheses as possible to see what people understand. This is
  why I've done that in the examples I sent, even if I would have added
  additional parentheses for readability.

frederic