[Haskell-cafe] Automatic fixity allocation for symbolic operators

[Nicolas Frisby]

Regarding latticess and locality...

This idea probably won't help with editors, but the OP's question has
sparked a  discussion here and some thinking in my head--thanks Brian.

What if operator precedences were specified as a partial order instead
of using numbers? Using numbers implies a potentially deceptive sense
of completeness: "well I've given @+@ a precedence 5 and let that be
written in stone forever so that all conflicts are resolved
henceforth."

Most fixities I've dealt with are put into play only amongst related
operators in a project  (@+@ or @*@ in MySpecialLib) or amongst
operators from a related library. If the syntax were like:

infixr @+@
infixr @+@
prec @+@ > @*@

then the programmer gets to specify as much as they have decided and no more.

5 @+@ 3 * 7 would simply be under defined and would require parens.

Perhaps Brian's original idea of systematically determining
unspecified operator precedences could be recast in this system.
Consider (woefully under contemplated) precedence specifiers such as:

precInherit <*> -> @*@
precAll ?+? > ?*?

Regarding precAll: I'm not a regular expressions/glob for semantics
fan, but you get the idea.

The idea is to define a partial order on operators and let undecided
operator relationships remain undefined. Composition remains an open
issue, but perhaps someone else will have a light bulb about that.

Nick

On 10/16/06, Arie Peterson <ariep at xs4all.nl> wrote:
> Hello,
>
>
> Henning Thielemann wrote:
>
> > [...] I repeat my example of a source code formatting tool which must
> > decide whether to format
> >
> >  a +
> >    b * c
> >
> > or
> >
> >  a + b *
> >    c
> >
> >  It needs to know the precedences of the used operators, which, as Brian
> > pointed out, is possibly not even defined somewhere. Alternatively
> > consider a compiler which must have a parser that must adapt the grammar
> > to the module contents (infix statements) in order to parse the module
> > correctly.  Even worse: The same symbol can have different precedences,
> > because infix operators can be declared locally.
>
> I would suggest to first parse modulo fixity and precedence (keep all
> operator applications in flat lists) and only later, if/when precedence
> and fixity information is available, parse those operator lists.
>
> >                                                  The same problem for a
> > human: In order to analyse the meaning of an expression with infix
> > operators he must know the precedences. That is, problems with infix
> > operators are by far not bound to a text editor!
>
> Quite so. I wouldn't consider it a problem though. The meaning of the
> expression also depends on the meaning (definition) of the operators
> involved, and of other functions used in the expression. That information
> may also be located elsewhere or even not yet available, just as
> precedence declarations. Locality has been wittingly sacrificed for
> flexibility.
>
>
> Regards,
>
> Arie
>
> --
>
> Mr. Pelican Shit may be Willy.
>
>   ^
>  /e\
>  ---
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>