[bitc-dev] Issues for s-block surface syntax

[Kevin Reid]

On Jan 23, 2008, at 16:30, Jonathan S. Shapiro wrote:
> On Wed, 2008-01-23 at 16:08 -0500, Kevin Reid wrote:
>> It most certainly does. Ordinary identifiers and 'operator
>> symbols' (to use the language of the Haskell 98 Report) are identical
>> except in parsing; the semantics do not vary, and each can be used in
>> place of the other with appropriate markers.
>
> So if I introduce a left-associative operator with priority N, when  
> does
> that *priority* go out of scope? Particularly if type classes over  
> that
> operator are in effect (because type class instances don't obey  
> scoping
> rules in general).

Fixity (as the Report calls it, and I'll use henceforth for brevity)  
is also lexically scoped. Class instances may not change fixity, as  
they do not introduce new operators.

The Report says:
> A fixity declaration may appear anywhere that a type signature  
> appears and, like a type signature, declares a property of a  
> particular operator. Also like a type signature, a fixity  
> declaration can only occur in the same sequence of declarations as  
> the declaration of the operator itself, and at most one fixity  
> declaration may be given for any operator. (Class methods are a  
> minor exception; their fixity declarations can occur either in the  
> class declaration itself or at top level.)
>


I imagine specifying that using operators in 'ambiguous' positions  
(a !! b # c, as opposed to a !! (b # c)) is prohibited unless a  
fixity declaration is present /in the same source text as the use of  
the operator/; furthermore, modules exporting operators may also  
declare fixities, which are not used except to /restrict/ what  
fixities a client may declare; this is to ensure that all uses of a  
module use the same parsing rules if they use any.

However, this would not solve the problem you mention of two  
different operator sets using the same names but different fixities;  
it would just make slightly more obvious that the examined sources  
use different rules.


I think what I would do to support human auditing is allow infix  
operators, but prohibit precedence and associativity; that is,  
parentheses must be used around any operand of an infix operator  
which is itself an infix operation. This seems to me a simple and  
strong solution; source is always understandable without context, and  
yet infix syntax is not limited to the traditional arithmetic operators.


On the other hand, stick with s-expressions; elaborate syntax is a  
tarpit for design.

-- 
Kevin Reid                            <http://homepage.mac.com/kpreid/>