On Sat, 14 Oct 2006, Jim Apple wrote: > On 10/14/06, Brian Hulley <[EMAIL PROTECTED]> wrote: > > User defined fixities are an enormous problem for > > an interactive editor > > This is the second or third time you've proposed a language change > based on the editor you're writing. I don't think this is a fruitful > avenue.
I assume that editor developers, compiler writers and language tool writers (documentation extraction, source code formatting) get much more insight into syntactic issues than other users. Finding some problem when implementing one of these tools often reveals weak points in the language syntax. 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. 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! You may argue that difficult language syntaxes like that of C++ push the parser technique forward. However this seems to me like Windows pushes memory development. Concerning the automatic precedence assigment according to the characters in an infix operator, I think that it is difficult to find a reasonable algorithm, because that algorithm would also limit the kind of operator schemes that can be used. If the operations can be associated with basic mathematical operations like +, *, =, then it would work, but what about different structures? How would you translate lattice operations "up" and "down", how operations like "parallel" and "serial" composition? Summed up, I think infix handling must be somehow improved, but I don't know how. _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
