Re: concrete syntax problems in arch spec and views

[Frederic Voisin <Frederic.Voisin@lri.fr>]

Well : Peter now inclines on one way, Bjarke on the other. Honestly, I do
not know fo myself (probably differently as a user or as a parser
implementer).

> From: "Bjarke Wedemeijer" <wedemeij@wins.uva.nl> (edited !!)
> Cristophe's approach is wrong since (sub)terms of the following
> form "f(x)" are always recognized as possible function application. I
> tested his parser in june. Maybe he made a new version already?

I didn't check but probably not, but this is not the problem: do we consider
it as a bug or as the normal behavior ! Currently I do like Christophe
for "f(x)" on purpose... I can revert the choice but we have to choose the
desired behavior.
The problem was evoked in Christophe's mail (March 11) with the following
example and constraint:

- we want to make life as easy as possible for people/parsers who use only
ordinary functional application, and to recognize it as a special case

- however things are not that easy since with
    t gt s (x + y)  , s is probably  a function
    f xx * (x + y)  , * is probably a binary operator not a unary function.
here we rather need to know the whole signature before choosing what to
accept.

The same is true for f(x) as noted in the current thread of messages.

> > Therefore, I would say that "f(x)" is to be recognized at parsing time as
> a potential function application, the fact that "f" does exist or not (with
> > the adequate signature) being checked during "static semantics" checks ?
> 
> I fully disagree. It is possible to do a correct recognisition at parsting
> time (see my mixfix parser in ASF+SDF). As far as I recall  the problem 
> in Chris. parser is that he favours "f(x)" to much as an function
> application. As you have shown are there some situations where "f(x)" is a
single constant f and a parenthesized constant x.

I know that it is possible to do differently and I did that in 
Asspegique's parser long time ago. But what is "parsing time" ? "Context-free"
parsing ? For "parsing" do we need to know the full signature ?

What is the meaning of precedence levels:

Choice A: If, given the current global signature, there is only one structure
for terms with appropriate sort checking, then use it (the structure depends
on the environement) . If there are more than one, use the precedence levels
to discard some of them.

Choice B: First use the precedence level to structure the terms. Then use
the computed structure as the starting point for the rest.

For terms, A and B make difference only for parenthesis since one cannot
distinguish "context-freely" between prefix/postfix/misfix for instance.


The current document does not clearly say (in my view) what choice has been
made.
For the structuring operations, this is clearly B. For Formulae, I think there
is no choice. For terms ? The explanations is given like
for the other items, but it is also written at the start of C.3
"the exact applicative structure fo these constructs is left unspecified
here, since it is inherently context-dependent".


Let's have a last chance to all agreed upon what we want.

Depending on the answer, some work I have to do will move from the
"yacc" side to a later tool (not context free) side, or the reverse.

Frederic