Hacker News Reader

Comment by ed25519FUUU | Hacker News Reader

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

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`.

> 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?

From 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.

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.

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?"

(.g) us a field selector, is (. g) then a function :: (a -> b) -> c -> b?

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.)

I'm just pointing out that the difference between (.g) and (. g) is potentially easy to miss.

It's worth pointing out that Haskell has always overloaded the dot. It is used for module namespace disambiguation, e.g Set.fromList

But you've got the module there to disambiguate the ., which you don't have in records.

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.

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.

Reply on news.ycombinator.com