On Sun, Feb 12, 2012 at 2:42 AM, Isaac Dupree <m...@isaac.cedarswampstudios.org> wrote: > On 02/11/2012 09:21 PM, Roman Leshchinskiy wrote: >> >> On 12/02/2012, at 02:04, Greg Weber wrote: >> >>> I am sorry that I made the huge mistake in referencing future possible >>> proposals. If this proposal passes, that has no bearing on whether the >>> other proposals would pass, it just makes them possible. >>> >>> Please help me fix my error by stopping all discussions of future >>> proposals and focusing solely on the one at hand. >> >> >> But if we don't consider those future proposals, then what is the >> justification for this one? It does break existing code so there must be >> some fairly compelling arguments for it. I don't think it can be considered >> in isolation. > > > Does it help your concern about breaking existing code to make sure this > proposal has a LANGUAGE flag? ("-XDotSpaces" or such) > > (I'm guessing that helps somewhat but not very satisfactorily; the more > default and standard it becomes, the more often it tends to break code > anyway.) > > -Isaac
Anything is allowed to happen if you have a LANGUAGE flag, but we're discussing what ought to be standardised. I think "existing code breaks" is not a great argument since we can just compile it with Haskell98 (or 2010) switches, although updating code is going to be a nuisance. However, I would really like people to keep their hands off the composition operator :) In my opinion its use in the module system was already a mistake, and I'd be happy to revisit that decision (although I imagine it has too much inertia now). But composition is fundamental to Haskell, /way/ more fundamental than the module system or records, not only practically but to some degree conceptually as well. So I consider natural syntax for it to be of highest priority. The dot is a very good choice, I can't think of a satisfactory alternative, and I don't think that any further overloading of it is a good idea. To relate to this specific proposal, changing the rules for a single specific operator is just too weird and surprising. I want to be able to change "f<<<g" to "f.g" without worrying about special cases. If we're genuinely seeking to prevent ambiguity, we ought to worry (at least in addition to this proposal) about the [x..] syntax for lists used with x a value constructor. I could have /some/ sympathy for "whitespace around all operators", although I think it's needlessly restrictive. But enforced whitespace around /some/ operators is entirely silly, in my opinion. To those wanting to use -> for record access, make sure it doesn't interfere with case branches. => might be a better option, but honestly I don't find record syntax that awkward to use, personally, especially with GHC's NamedFieldPuns. _______________________________________________ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime