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