Re: concrete syntax problems in arch spec and views

[Peter Mosses <mosses@csl.sri.com>]

It would be really nice if we could conclude the discussion concerning
parsing issues that affect the CASL Summary during this next 7 days,
by 15 October, so that App C of v1.0 may provide a stable reference
for concrete syntax, and be the basis for validating the forthcoming
parsers and mixfix analysers.

*** ALL: PLEASE DRAW ATTENTION TO ANY REMAINING PROBLEMS CONCERNING
         CONCRETE SYNTAX AND PARSING OF CASL AS SOON AS POSSIBLE!

I wrote:

> > (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!

Frederic responded:

> 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 ?

Your interpretation is indeed more reasonable than the one I had
assumed - as well as more consistent with what is written in the
Summary.  So fine, I agree with what you say; thanks for clarifying
that issue for me.

> I also agree with Don that systems that allow users 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.

But in CASL we allow general mixfix notation, and of course there is
no way of recognizing the proper grouping during context-free parsing,
regardless of associativity and precedence issues, in the absence of
the knowledge of which symbols have been declared (e.g. `a b' might be
an application of a__ to b, or of __b to a, or of __ __ to (a,b), or
even ambiguous).  Precedence and associativity annotations are thus
rightly ignored by the "standard technology" parsers that are being
developed; but surely they should affect the subsequent mixfix
analysis of terms and formulae!  (BTW, they may affect the output of
pretty-printers too.)

I suppose that the "standard technology" for mixfix grouping analysis
is the algorithms used in systems like OBJ3, Maude, ELAN; Bjarke
implemented something along those lines while he was in Aarhus (using
ASF+SDF - but without using the standard ASF+SDF technology for mixfix
analysis, which involves generating a general context-free parser from
the declarations of symbols).  The CASL mixfix analysis is simplified
by not depending at all on sorts of terms and overloading resolution;
the built-in relative precedence between infix, prefix, and postfix
symbols is a minor complication.  

I expect that it is best to regard mixfix analysis as a separate
phase, taking as input what the "standard technology" parsers produce
as output.  The final properly-grouped abstract syntax that the mixfix
analysis produces is then the input for subsequent static analysis.

Please indicate any disagreement with the above understanding of
mixfix analysis for CASL as soon as possible, as time is so short!

-- Peter
_________________________________________________________
Dr. Peter D. Mosses             International Fellow  (*)

Computer Science Laboratory     mailto:mosses@csl.sri.com
SRI International               phone: +1 (650)  859-2200 ! CHANGED
333 Ravenswood Avenue           fax:   +1 (650)  859-2844
Menlo Park, CA 94025, USA       http://www.brics.dk/~pdm/

(*) on leave from DAIMI & BRICS, University of Aarhus, DK
    also affiliated to CS Department, Stanford University
_________________________________________________________