Hacker News Reader

You are missing the point, which is that if you can blindly follow the type hints of the compiler and still get a non-stupid function when you're joking around like the author is, then in real-life coding situations the type hints will be all the more relevant and reliable.

By the way, this is literally the most common foldr implementation in functional languages, so I have no idea why you would want to do a code review of it, or talk about performances in such a trivial setting, or pretend that you're confused by it so much that you have to refer to a library...

> then in real-life coding situations the type hints will be all the more relevant and reliable

That was exactly my point about the foldr example: in real-world code, you may need a function that perfectly matches foldr's type signature. But following the author's methodology, you'll write out a new implementation of foldr, when what you should actually be doing is calling foldr in that type hole.

This ties back in to my comment about code review. Think about how a patch from someone who applied the author's method would look like: it would contain a lot of in-place implementations that they sort of stumbled into, when in fact they should have reused well-known functions. Someone should then try to review that code to see if some implementation is not actually a well-known function.

Even ghc suggested at some point that he should use maxBound or minBound instead of writing his own thing.

Edit: I should also add that there is no reason to think that foldr is the right implementation of zoop without more context. For example, zoop could be a function just like foldr but that works on the reversed list of `as`. Or one that skips every second element of `as`. If we're just guessing based on type, and don't know what the code is supposed to do, it's easy to mess up.

> If I knew you write code like this, I would feel compelled during code review to squeeze my brain to try to see whether there is some library function that does what you just did.

That's because the author didn't put a type hole before declaring arguments.

  zoop :: (a -> b -> b) -> b -> [a] -> b 
  zoop = _
  <interactive>:10:8: error:
    • Found hole: _ :: (a -> b -> b) -> b -> [a] -> b
      Where: ‘a’, ‘b’ are rigid type variables bound by
               the type signature for:
                 zoop :: forall a b. (a -> b -> b) -> b -> [a] -> b
               at <interactive>:9:1-38
    • In the expression: _
      In an equation for ‘zoop’: zoop = _
    • Relevant bindings include
        zoop :: (a -> b -> b) -> b -> [a] -> b
          (bound at <interactive>:10:1)
      Valid hole fits include
        zoop :: (a -> b -> b) -> b -> [a] -> b
          (bound at <interactive>:10:1)
        foldr :: forall (t :: * -> *) a b.
                 Foldable t =>
                 (a -> b -> b) -> b -> t a -> b
          with foldr @[] @a @b
          (imported from ‘Prelude’
           (and originally defined in ‘Data.Foldable’))

Here, GHC has figured out that, yes, `zoop` is in fact directly equivalent to `foldr`. And it'll do this with all other holes involved in the iterative type hole development process. So, you don't have to worry about whether there is some library function that does what the author did. GHC will do that for you.

> Instead of just using foldr, you've reimplemented it, and don't even know that!

This completely misses the point of the article...

The author demonstrates a general concept (type holes) on a simple piece of code, to explain and motivate how he used it the exact same methodology on a much more complex piece of code, `hoistStateIntoStateT`.

It doesn't. That bit of the article shows that maybe his implementation of hoistStateIntoStateT could be replaced with an already existing function, or a composition thereof.

Also, his entire method breaks down the moment you add an [a] among your parameters (or even return values, possibly), and probably other types as well, and he doesn't even mention anything about that.

I think, it's a means of fighting the eventual complexity of Haskell types. When you cannot write your boilerplate code yourself any longer. But then the solution is also a cause of your problem.

I don't really agree with the article to any extreme, but imo, its a really useful pedagogical tool to "follow the types". The book "functional programming in Scala" uses it a lot, and it really is easy to do in some cases. Like implementing map or flatmap is really demystified by looking at the type signature first and then realizing, given how abstract it is, that there aren't really meaningful alternative implementations for the type signature.

In a more general sense, by utilizing nominal types and defensive programming, you can get a lot of mileage by making there one obvious way to do something. A canonical example being a validation function that takes User and returns ValidUser. If theres only a single function in your codebase that can do that transformation, you can actually use a (debatably simpler) principle of following the types to guide implementation, and in fact, actively prevent the wrong implementation from being written in the first place.

These things are certainly possible to varying degrees with dynamically typed languages, or statically typed OOP languages, but Ive never encountered a paradigm that makes representing invalid program states impossible to the degree that statically typed FP makes possible.

> a->a

Even there, it's not true, right? It's been a while since I learned / used Haskell, but I think something that transforms a { name: 'bob' } to a { name: 'sally' } would fit that bill, right? So, there are many implementations which meet the type signature, but you'd be pretty surprised if your `identity` function did this.

  f :: a -> a

can only be satisfied by the function identity because there are no constraints on the type (a). identity is the lowest common denominator function that can transform an object of any type to another object of the same type.

If you added a constraint on a, for instance:

  f :: Num a => a -> a

Now f can be almost any function which can transform a numeric type back to the same numeric type. [0] describes class Num. So f, with this constraint, can now be negate, abs, signum, or something which combined the first parameter with itself using one of the operators, and so on.

By removing constraints on the type itself, Haskell necessarily restricts the set of operations that can be performed.

[0] https://hackage.haskell.org/package/base-4.12.0.0/docs/Prelu...

The key point making `a -> a` have only a single implementation is that the type `a` is a wildcard that's determined by the caller - it must be possible for the implementation to accept any value of any type. The identity function is the only thing that can do that for all possible values.

If the type were `Int -> Int`, it could do a lot more.

changing a record requires a more specific type than `forall a. a`

the type `forall a . a -> a` does truly have one single (non exception throwing) implementation since there is no information you can glean about your argument other than the fact that it exists.

Once you have more structure, for example in `Person -> Person` or even `forall a . [a] -> [a]`, you have more possible implementations than just the identity function.

That function wouldn't have type a -> a. It would have type MyRecord -> MyRecord.

no, that's a function from `named -> named`. `a -> a` is a function that takes any object, calls its type `a`, and returns an object of the same type.