5 ms·

Simon Peyton Jones: "One possible reaction to a diversity of opinion is to do nothing and wait for clarity to emerge. That is often the right choice, but not (I

Simon Peyton Jones: "One possible reaction to a diversity of opinion is to do nothing and wait for clarity to emerge. That is often the right choice, but not (I believe strongly) in this case. We have waited a long time already -- I have been engaged in debate about this topic for over two decades -- and I think it's time to decide something."

ed25519FUUU 6y ago
Not a Haskell programmer so I didn’t know about this issue, but to me this change is night and day better.
- dmkolobov 6y ago
  It's a nuanced issue, because Haskell extensively uses the dot (.) infix operator to mean function composition. Currently, the expression `f.g` will attempt to compose the function bound to `f` with the function bound to `g`.
  - runeks 6y ago
    > Currently, the expression `f.g` will attempt to compose the function bound to `f` with the function bound to `g`. So what will this mean now? Will function composition require a space between the dot, or how will a “record dot” be disambiguated?
    - duijf 6y ago
      From https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0282-record-dot-syntax.rst#lexer https://github.com/ghc-proposals/ghc-proposals/blob/master/p... .g is a field selector. f.g is field selection of a record. f . g is function composition. f. g is function composition.
      - moomin 6y ago
        Whilst I'm not going to argue the proposal is a bad thing, I think you've just summarized why some are giving it the side eye pretty well.
        ben509 6y ago
        To me it's just, "the dot hugs a field, dot by itself is composition, and module names are capitalized." While I wouldn't write f. g, if I see it, it's not hugging the field name so it's composition. I don't think I'd have trouble reading it. But... it will probably trip up newbies and people with odd spacing styles. Hopefully GHC can give a useful error like "In the field selection expression f.g, g is a function defined on XX. Did you mean f . g?"
      - thomasahle 6y ago
        (.g) us a field selector, is (. g) then a function :: (a -> b) -> c -> b?
        giraj 6y ago
        Yep! You could check this in GHCi (the repl), for example: > :t (. id) > (. id) :: (b -> c) -> b -> c (:t prints the type of an expression, and id is the "identity function" that's b -> b here.) (EDIT: Maybe you know the above and you're asking if it's being changed in the proposal. It doesn't seem so to me.)
        thomasahle 6y ago
        I'm just pointing out that the difference between (.g) and (. g) is potentially easy to miss.
  - willtim 6y ago
    It's worth pointing out that Haskell has always overloaded the dot. It is used for module namespace disambiguation, e.g Set.fromList
    - srtjstjsj 6y ago
      But you've got the module there to disambiguate the ., which you don't have in records.
      - runeks 6y ago
        I don't think this is true. The presence of a qualified import of "Data.Set as Set" does not change how the following is parsed. import Data.Set (fromList) import qualified Data.Set as Set data Set a = Set (Set.Set a) f :: Ord a => [a] -> Set a f = Set . fromList g :: Ord a => [a] -> Set a g = Set .fromList h :: Ord a => [a] -> Set a h = Set. fromList i :: Ord a => [a] -> Set.Set a i = Set.fromList In other words, the . is interpreted as a "module dot" if and only if there is no whitespace either preceding or following the dot.
    - runeks 6y ago
      Great point! I hadn't thought of this. It looks like the "record dot" follows the same parsing rules as the "module dot": the presence of whitespace turns the . into function composition.
ilyagr 6y ago
Simon's [entire post](https://github.com/ghc-proposals/ghc-proposals/pull/282#issuecomment-608329102 https://github.com/ghc-proposals/ghc-proposals/pull/282#issu...) that the parent comment quotes from is worth a read, as an example of a high concentration of sanity.
- deleted 6y ago
  [deleted]
- eru 6y ago
  There's lots of Haskell fanboys (like me ;) who can become a bit annoying, but the people usually recognised as leaders in the community, like Simon Peyton Jones, are all rather sane and pretty pragmatic.

ed25519FUUU 6y ago

Not a Haskell programmer so I didn’t know about this issue, but to me this change is night and day better.

dmkolobov 6y ago
It's a nuanced issue, because Haskell extensively uses the dot (.) infix operator to mean function composition. Currently, the expression `f.g` will attempt to compose the function bound to `f` with the function bound to `g`.
- runeks 6y ago
  > Currently, the expression `f.g` will attempt to compose the function bound to `f` with the function bound to `g`. So what will this mean now? Will function composition require a space between the dot, or how will a “record dot” be disambiguated?
  - duijf 6y ago
    From https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0282-record-dot-syntax.rst#lexer https://github.com/ghc-proposals/ghc-proposals/blob/master/p... .g is a field selector. f.g is field selection of a record. f . g is function composition. f. g is function composition.
    - moomin 6y ago
      Whilst I'm not going to argue the proposal is a bad thing, I think you've just summarized why some are giving it the side eye pretty well.
      - ben509 6y ago
        To me it's just, "the dot hugs a field, dot by itself is composition, and module names are capitalized." While I wouldn't write f. g, if I see it, it's not hugging the field name so it's composition. I don't think I'd have trouble reading it. But... it will probably trip up newbies and people with odd spacing styles. Hopefully GHC can give a useful error like "In the field selection expression f.g, g is a function defined on XX. Did you mean f . g?"
    - thomasahle 6y ago
      (.g) us a field selector, is (. g) then a function :: (a -> b) -> c -> b?
      - giraj 6y ago
        Yep! You could check this in GHCi (the repl), for example: > :t (. id) > (. id) :: (b -> c) -> b -> c (:t prints the type of an expression, and id is the "identity function" that's b -> b here.) (EDIT: Maybe you know the above and you're asking if it's being changed in the proposal. It doesn't seem so to me.)
        thomasahle 6y ago
        I'm just pointing out that the difference between (.g) and (. g) is potentially easy to miss.
- willtim 6y ago
  It's worth pointing out that Haskell has always overloaded the dot. It is used for module namespace disambiguation, e.g Set.fromList
  - srtjstjsj 6y ago
    But you've got the module there to disambiguate the ., which you don't have in records.
    - runeks 6y ago
      I don't think this is true. The presence of a qualified import of "Data.Set as Set" does not change how the following is parsed. import Data.Set (fromList) import qualified Data.Set as Set data Set a = Set (Set.Set a) f :: Ord a => [a] -> Set a f = Set . fromList g :: Ord a => [a] -> Set a g = Set .fromList h :: Ord a => [a] -> Set a h = Set. fromList i :: Ord a => [a] -> Set.Set a i = Set.fromList In other words, the . is interpreted as a "module dot" if and only if there is no whitespace either preceding or following the dot.
  - runeks 6y ago
    Great point! I hadn't thought of this. It looks like the "record dot" follows the same parsing rules as the "module dot": the presence of whitespace turns the . into function composition.

ilyagr 6y ago

Simon's [entire post](https://github.com/ghc-proposals/ghc-proposals/pull/282#issuecomment-608329102 https://github.com/ghc-proposals/ghc-proposals/pull/282#issu...) that the parent comment quotes from is worth a read, as an example of a high concentration of sanity.

deleted 6y ago
[deleted]
eru 6y ago
There's lots of Haskell fanboys (like me ;) who can become a bit annoying, but the people usually recognised as leaders in the community, like Simon Peyton Jones, are all rather sane and pretty pragmatic.