
On Sun, Feb 12, 2012 at 3:51 PM, Ben Millwood
On Sun, Feb 12, 2012 at 2:42 AM, Isaac Dupree
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.
[...]
On reflection I take this back, it would be a real nuisance to have to do this. The rest of what I said stands independently of that, of course. -1 to spaces around dot. I could be persuaded regarding spaces around all operators: a quick survey of code I write suggests minimal changes would be necessary. What about the comma, though? Spaces around that would be pretty unnatural; it's already not /quite/ a real operator, but I think that's a shame, and maybe it ought to be. So I'm not voting on that proposal yet, although my instinct is I don't like it.