Re: concrete syntax problems in arch spec and views

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

> From owner-cofi-tools@brics.dk  Mon Oct  5 08:49:44 1998
> Date: Mon, 5 Oct 1998 08:41:16 +0200 (MET DST)
> From: Peter Mosses <mosses@csl.sri.com>
> Subject: Re: concrete syntax problems in arch spec and views

> (I seem to recall that Bjarke discovered that Christophe's parser was
> indeed a bit too eager in this respect, always recognizing f(x) as an
> application even when f and (x) might be the arguments of a mixfix op
> such as "__ __"; I thought that he'd already pointed this out to
> the others developing parsers - otherwise, sorry for the lateness...)
> 
> Anyway, surely languages (e.g. SML) that allow users to declare the
> precedence of infix operators can be parsed using standard technology,
> so at least annotations should be able to influence the parsing!
> 


Two quick reactions:

Are you sure that Christophe's approach is wrong ?? The current set
of precedence rules for terms are to be applied whatever the current
local environment is, and ordinary function application has the highest
priority, higher than the one of mixfix application.

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 ?
If you want to use ""__ __" upon "f" and "x" I think that you will have to
write it "f x" or "(f) (x)".

Do I miss something ?

I also agree with Don that systems that allow uers to define
operator precedence do not use standard technology (although I never
look inside SML). Languages that allow overloading of infix operators
(Ada, C++,...) does not allow to change their precedence and associativity,
or to add new infix operators.

Frederic