Re: Proposal: require spaces around the dot operator
I support requiring spaces around the dot operator, *even if* we don't ever end up using it for anything else. It helps a bit in mentally parsing code, so I try to write that way anyway. So I don't mind making this change. This change helps us community-wise, having one less issue for us to concurrently agonize about as a community while talking about records (whether or not we decide to use dot, it makes the conversation less complicated). -Isaac ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Proposal: require spaces around the dot operator
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 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 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 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
Re: Proposal: require spaces around the dot operator
> ... 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. Dan/all, I think yous should backtrack to SPJ's SORF and TDNR proposals, and the Yesod/Reddit discussion that triggered the latest 'Records in Haskell' threads. http://hackage.haskell.org/trac/ghc/wiki/Records SORF: "It is critical to support dot-notation." TDNR: "Exploting the power of the dot" TDNR: "a feature that has a _cultural_ connection to OO, but that turns out to be fully compatible with a functional language." TDNR: "I have deliberately used dot ..." "It's standard practice, and that counts for a lot." "Selecting a field from a record is a particularly convenient special case, ..." "... is doing the same job as Haskell's existing qualified names, ..." I guess the 'clincher' for me is that if we're going to ask SPJ to implement anything (and there's no-one else who's capable) we'd better have very powerful reasons to go against his so clearly expressed views. Remember GHC/Haskell Prime is not run as a democracy, it's a benevolent meritocracy. We've probaly only got one shot: if we don't include dot notation with whatever happens for 'Records in Haskell', we'll probably never get dot notation. SPJ has made it clear Records is not a priority. If it contues to be an area for hot dispute, it'll just die a death (again). I do, however, agree with you questioning the effort going into surface syntax vs. deep semantics. (The relative effort is confirming Wadler's rule.) Because what's not getting enough 'airtime' is how we address even the "narrow issue: namespacing for record field names." What we are tending to get (apart from the hatchet-job on the dot) is another bundle of half-baked suggestions for the impossibily difficult "broad issue: first class record types". I'm working towards a proposal for the narrow issue. I'm trying to make the changes to Haskell as minimal as possible. So far, I've built a prototype in GHC v 7.2.1 (with many record-oriented extensions), which gives me hope I'm mostly asking for syntactic sugar. It's been somewhat helpful with the design to 'test the water' through the discussion lists. It's also been distracting. I've only had one response that was really, really helpful and on-topic -- and that was from SPJ, who (heck knows) is a very busy person. I don't want the response to my proposal (if/when I get time to write it up convincingly) to focus on the dot. Luckily, under my design, the dot is very much syntactic sugar. (So actually, it would be absurdly simple to implement, and even simpler to leave out. That is, simple compared to implementing the semantics.) I don't need it. I'm in two minds whether even to mention it. AntC ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Proposal: require spaces around the dot operator
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 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 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
Re: Proposal: require spaces around the dot operator
There is also '~' which has no use in expressions right now. I am still undecided on the utility of TLDR, bogarting already contested syntax seems premature. I question the value of looking too much like other languages, in some sense it hurts us, new programmers are constantly trying to define classes first thing because they have the same name as a somewhat related thing from whatever language they are coming from. Even though they are rarely the correct solution for anything you would encounter in basic haskels programming. I don't know whether using '.' will exacerbate this or not, but it is far from clear that it is a good thing. John On Thu, Feb 9, 2012 at 6:27 PM, Daniel Peebles 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 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
Re: Proposal: require spaces around the dot operator
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 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
Proposal: require spaces around the dot operator
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
