On Sun, Feb 12, 2012 at 2:42 AM, Isaac Dupree <ml@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.