Proposal: require spaces around the dot operator

[Malcolm Wallace]

-1.

I agree with John.  There is no point in fiddling with the dots, until we have real experience with a new records proposal (which can be implemented entirely without using dot, at least initially).

Regards,
    Malcolm


On 10 Feb 2012, at 03:14, John Meacham wrote:

> 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
> 
> _______________________________________________
> Haskell-prime mailing list
> Haskell-prime at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-prime