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