4 ms·
>There's only one possible thing this function can do! That's not at all true... it can do all sorts of transformations on the first value of the tuple. I supp
by GeneralMayhem 13y ago
>There's only one possible thing this function can do!
That's not at all true... it can do all sorts of transformations on the first value of the tuple. I suppose without type restrictions on the parameters it can't do too much because there are relatively few functions defined on all types, but then, how often are you going to see a function signature that vague?
More likely, you'd see
`foo :: MyClass a => (a, b) -> a`
or
`foo :: (MyType, b) -> MyType`
which opens up the possibilities considerably, because you don't know which of MyType's behaviors is being invoked.
- tel 13y agoThat's exactly it: (a) there are no functions at all defined on all types except id (of type (a -> a)) and (b) you end up seeing signatures close to that vague all the time. This is exactly the power of parametricity.
- eru 13y ago> [...] you end up seeing signatures close to that vague all the time. That's not an accident. Factoring out little helper functions like this is considered a virtue in Haskell (and acording to Paul Graham, also in Lisp). Even if you only use them once---because they make reasoning easier.
- tel 13y agoAgreed! I think the tendency to highly parametric functions comes from several sources. First, good programming practice allows for decomposing entities and leading to more flexible functions. Second, once you have higher kinded types you realize that 90% of programming is wiring between contexts and is more parametric than people think. Finally, HM typing auto generalizes all of your let bindings which means your compiler can inform you of opportunities for genericity that you weren't even aware of... so long as you ask.