concrete syntax problems in arch spec and views

[Frederic.Voisin@lri.fr]

Dear CoFI-tools members,

Here is a short list of the current problems with the concrete syntax
for Casl. I did not have the opportunity to check with Christophe the
completeness of the list below, but for basic items it seems to work...
The major problem comes with the proposed syntax for architectural
specs and views. A message from Christophe in July mentioned many problems
brought by the new proposal and the solution proposed by Peter and
Michel (restricting in various places specification to named specifications
or "bracketed" specifications) does not solve all of them, mainly some
problems related to symbol maps... I'm currently investigating what
can be done.. (about 60 shift-reduce conflicts come from the new
features...)

There are also problems with the syntax of PATHs when naming specifications.
By being more restrictive (i.e. using a lexical convention...). Maybe
we can live without that feature for the current version ??


Frederic
------------------------------------------------------

Micro-problems/ambiguities in the current document

- In a definition by extension, spaces are needed around the '.'
  NO: 	Odd = {n:Nat.odd n}  %% Note that ".odd" is a valid token
  Yes:	Odd = {n:Nat . odd n}

- <Sort> is defined as <TokenId>. Probably it should be a <SimpleId>

- Are both ->? and -> ? needed ? Or which form is the right one ?

- The "display annotations" must probably be allowed also for symbols
  declared in renamings, not only in "declarations"

- the tokens -> and ->? are not described as being complete reserved tokens

- Is the operator {{ __ }} allowed, since in an application like
  {{ ( a ) }}, from a grammatical point of view we have different IDs
  "{{" and "}}" and the reference manual aks each ID to have balanced
  occurrences of {.. } (or [... ]).

- I have doubts about the possibility of allowing [ and ] in IDs since
  the symbols are also used for marking compound ids.