Proposal: require spaces around the dot operator

[Ben Millwood]

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