4 ms·

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

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.

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.