Proposal: require spaces around the dot operator

[John Meacham]

I mean, it is not worth worrying about the syntax until the extension has been
 implemented, used, and proven useful to begin with. Monads were in use
well before the 'do' notation. Shaking out what the base primitives that make
up a monad took a while to figure out.

Even discussing syntax feels a little like a garage band discussing what
the lighting of their  stage show will look like before they learned to play
their instruments.

If we can implement it and test it without breaking existing code, why
wouldn't we? It would mean more people can experiment with the
feature because they wouldn't have to modify existing code much. So
we will have more feedback and experience with how it interacts with
other aspects of the language.

    John

On Thu, Feb 9, 2012 at 6:41 PM, Greg Weber <greg at gregweber.info> wrote:
> There are 2 compelling reasons I know of to prefer dot for record access
> 1) follows an almost universal convention in modern programming languages
> 2) is consistent with using the dot to select functions from module name-spaces
>
> We can have a lot of fun bike-shedding about what operator we would
> prefer were these constraints not present. Personally I wouldn't care.
> However, I find either one of these 2 points reason enough to use the
> dot for record field access, and even without a better record system
> the second point is reason enough to not use dot for function
> composition.
>
> It is somewhat convenient to argue that it is too much work and
> discussion for something one is discussing against. The only point
> that should matter is how existing Haskell code is effected.
>
> On Thu, Feb 9, 2012 at 8:27 PM, Daniel Peebles <pumpkingod at gmail.com> wrote:
>> I'm very happy to see all the work you're putting into the record
>> discussion, but I'm struggling to see why people are fighting so hard to get
>> the dot character in particular for field access. It seems like a huge
>> amount of work and discussion for a tiny bit of syntactic convenience that
>> we've only come to expect because of exposure to other very different
>> languages.
>>
>> Is there some fundamental reason we couldn't settle for something like # (a
>> valid operator, but we've already shown we're willing to throw that away in
>> the MagicHash extension) or @ (only allowed in patterns for now)? Or we
>> could even keep (#) as a valid operator and just have it mean category/lens
>> composition.
>>
>> Thanks,
>> Dan
>>
>> On Thu, Feb 9, 2012 at 9:11 PM, Greg Weber <greg at gregweber.info> wrote:
>>>
>>> Similar to proposal #20, which wants to remove it, but immediately
>>> less drastic, even though the long-term goal is the same.
>>> This helps clear the way for the usage of the unspaced dot as a record
>>> field selector as shown in proposal #129.
>>>
>>> After this proposal shows clear signs of moving forward I will add a
>>> proposal to support a unicode dot for function composition.
>>> After that we can all have a lively discussion about how to fully
>>> replace the ascii dot with an ascii alternative such as <~ or <<<
>>> After that we can make the dot operator illegal by default.
>>>
>>> This has already been discussed as part of a records solution on the
>>> ghc-users mail list and documented here:
>>> http://hackage.haskell.org/trac/ghc/wiki/Records/DotOperator
>>>
>>> _______________________________________________
>>> Haskell-prime mailing list
>>> Haskell-prime at haskell.org
>>> http://www.haskell.org/mailman/listinfo/haskell-prime
>>
>>
>
> _______________________________________________
> Haskell-prime mailing list
> Haskell-prime at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-prime