On 17 nov 2010, at 16:21, Ben Millwood wrote: On Wed, Nov 17, 2010 at 8:52 AM, Yitzchak Gale wrote:

...

Reading this proposal I think it clearly states my point made earlier: allowing infix specifications everywhere provides unneeded flexibility and unnecessary complexity.

Ideally I would like to see them even before the module keyword: they state how to read the text that follows, and thus fall in the category of:

- LANGUAGE pragma's which add sometimes extra syntax - import's, which extend the name space

Restricting them to occur only directly after the imports is something I cannot see anyone to object to, and would enable the immediate correct parsing of all expressions to follow.

Doaitse

This is an interesting idea! It would certainly solve a fair few issues with fixity parsing, but I worry that we'd lose a lot of consistency, and/or gain a lot of redundancy - we want operators to associate the same way in every file, but people will have different ideas about which way to associate what (I like associating $ to the left, but I generally don't for the sake of my readers' sanity). Plus, like explicit import lists, I suspect that a list of all operators used in the program, potentially some distance away from their usage site, is going to invite subtle errors when people forget to add one, redundancy when people forget to remove one, and noise in patch files when people do the right thing. So as much as I want to see Haskell's infix syntax simplified, I'm not sure this is a practical way to do so. I once had the idea of having fixity determined in some sense by the name of the operator - long operators binding more tightly/loosely than short ones, or an angle bracket in the right place changing the associativity - but I don't think there's any satisfactory way of doing that either.

That is why I refined the proposal in my last sentence to only allowing them after the import's. It is also the only way I see programming environments ever becoming "priority aware". Doaitse _______________________________________________ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime