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 <[EMAIL PROTECTED]> 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@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
