Re: [CoFI] CASL Concrete Syntax

["Don Sannella" <dts@dcs.ed.ac.uk>]

This is just a quick response to two things in Till's comments:

> page 7, conjunction and disjunction:
> Isn't it common to give conjunction a higher precedence than disjunction?
> [Among logicians, certainly.  But some of us have argued that software
>  engineers do not have such a strong tradition for this. --PDM]
> 
> page 7, implication:
> It is quite standard that implication associates to the right,
> i.e. A => B => C is parsed as A => (B => C)
> (see eg. Shoenfield, Mathematical logic, 1967).
> [Ditto.  --PDM]

I agree with Till concerning conjunction and disjunction although I
see the point about a lack of SE tradition.

In the case of =>, I agree strongly with Till and disagree strongly
with Peter's response.  The absence of an SE tradition here is no
doubt due to the absence of an infix "implies" operator in most if not
all programming languages.  Maybe there are a few I don't know about
that have => as syntax for if_then_(else_); I would bet that if there
are any such languages then they take implication to be right
associative because that is what makes sense in examples.  The same
goes for right-associativity of -> in languages with higher-order
functions.

[Logic programming languages, and specification languages allowing
 conditional equations, do tend to use infix notation for implication -
 but it seems to me that they generally do not allow it to be
 iterated/nested, even though (with nesting to the right) this could be
 regarded as a simple abbreviation.  Anyway, I suspect that in
 practice, rather few specifications would make extensive use of nested
 implications, and the burden of inserting the parentheses should be
 outweighed by the elimination of a possible source of misinterpretation.  
 If requiring these explicit parentheses in formulae turns out to be
 sufficiently annoying, one might later allow their omission by use of
 precedence annotations (as for omitting parentheses in terms).  --PDM]

Best regards, Don 

[BTW, it's OK to question ALL syntax issues now, before we freeze the
 design - even those that been stable since the first proposal of 4 Sep
 1997.  But unless it is quite clear (at least to the authors of the
 concrete syntax proposal) that a proposed change would definitely
 improve the design, it won't be adopted at this late stage.  --PDM]