On 17 nov 2010, at 16:21, Ben Millwood wrote: On Wed, Nov 17, 2010 at 8:52 AM, Yitzchak Gale <g...@sefer.org> 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 _______________________________________________ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
