Hacker News Reader

Comment by munchler | Hacker News Reader

As you get more comfortable with functional programming, the type signatures tend to get more complex for sophisticated code. Those "nasty generics" become reliable friends.

For example, since functions are first-class objects, they are often passed around as parameters to other "higher-order" functions. Explicitly declaring the types of all these functions is tedious at best, and confusing at worst.

View on HN

I'm not convinced that these type signatures have to be that bad. You could probably make them pretty tenable, especially with a good code formatter.

Also, I'm confused. We're using type driven development and writing the type signatures as part of the documentation, we should be thinking in terms of types, why would they be difficult to write?

They're not bad. They're just a pain to type out in detail every time. Here's an example signature from an F# library I like called FParsec:

    pipe2: Parser<'a,'u> -> Parser<'b,'u> -> ('a -> 'b -> 'c) -> Parser<'c,'u>

That's fine for documentation, but I'm glad it's not cluttering up the actual implementation, which starts like this:

    let pipe2 (p1: Parser<'a,'u>) (p2: Parser<'b,'u>) f =
        ...

You can see how the code does explicitly specify the types of `p1` and `p2`, but doesn't bother spelling out the type of `f` or the return type. Although we are thinking in types the whole time, this sort of flexibility in the implementation is important for real-world functional code.

(For anyone wondering, this function takes two parsers and a function as input. It sends the output of each parser to the function, and the result is itself a parser. This is equivalent to a well-known abstract function called `liftA2` in a language that supports typeclasses, like Haskell.)

[0]: https://www.quanttec.com/fparsec/reference/primitives.html#m...

[1]: https://github.com/stephan-tolksdorf/fparsec/blob/master/FPa...

[2]: https://hoogle.haskell.org/?hoogle=liftA2

This is a really good question. When you write generic code in a language with higher-order functions, type signatures can get pretty hairy with type variables and quantifiers flying around (forall a. a -> foo a). In a functional language with type inference, it's mostly managing those for you, and you can (usually) just write code in a natural way and it automatically is polymorphic, but in a safer way than dynamically-typed languages.

Reply on news.ycombinator.com