4 ms·

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

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?

jasperry 3y ago
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.
munchler 3y ago
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#members.pipe2 https://www.quanttec.com/fparsec/reference/primitives.html#m... [1]: https://github.com/stephan-tolksdorf/fparsec/blob/master/FParsec/Primitives.fs https://github.com/stephan-tolksdorf/fparsec/blob/master/FPa... [2]: https://hoogle.haskell.org/?hoogle=liftA2 https://hoogle.haskell.org/?hoogle=liftA2

jasperry 3y ago

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.

munchler 3y ago

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#members.pipe2 https://www.quanttec.com/fparsec/reference/primitives.html#m... [1]: https://github.com/stephan-tolksdorf/fparsec/blob/master/FParsec/Primitives.fs https://github.com/stephan-tolksdorf/fparsec/blob/master/FPa... [2]: https://hoogle.haskell.org/?hoogle=liftA2 https://hoogle.haskell.org/?hoogle=liftA2