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
