I get it now.
There is no run-time polymorphism in the type system in Haskell. Type inference nails everything down at compile-time. Hence:
-- This doesn't compile because there's no way for the
-- compiler to infer the concrete return type from read.
reparse :: String -> String
reparse = show . read
Because of the type inference system, this turns out to be basically as flexible as run-time polymorphism in most cases. It might occasionally require the introduction of "container" data types that have constructors which take values of several other types, which allow explicit runtime pattern matching.
It is a different axis of flexibility than object oriented languages use, in terms of how it causes code to be arranged. Different points of growing pain... Really, the typical distinction between objects and algebraic data types. Each is good at one thing the other is bad at, and mostly in terms of code organization, and how hard certain maintenance tasks are.
I really think programming languages based on textual representations aren't flexible enough. I remember Prof. Young telling me about a project at one of IBM's labs that stored code in a format that could assume different textual representations and organizations depending on the view you desired. Old unix programmers would fight such a system tooth & nail, but I think it's the direction that provides the best potential code maintainability in the long haul.
Software engineering has been around maybe 75 years now? It's still in its infancy. Our tools are primitive. We need to recognize that, and be open to shifts in viewpoint that allow growth in terms of reliability and maintainability.
-- This doesn't compile because there's no way for the
-- compiler to infer the concrete return type from read.
reparse :: String -> String
reparse = show . read
Because of the type inference system, this turns out to be basically as flexible as run-time polymorphism in most cases. It might occasionally require the introduction of "container" data types that have constructors which take values of several other types, which allow explicit runtime pattern matching.
It is a different axis of flexibility than object oriented languages use, in terms of how it causes code to be arranged. Different points of growing pain... Really, the typical distinction between objects and algebraic data types. Each is good at one thing the other is bad at, and mostly in terms of code organization, and how hard certain maintenance tasks are.
I really think programming languages based on textual representations aren't flexible enough. I remember Prof. Young telling me about a project at one of IBM's labs that stored code in a format that could assume different textual representations and organizations depending on the view you desired. Old unix programmers would fight such a system tooth & nail, but I think it's the direction that provides the best potential code maintainability in the long haul.
Software engineering has been around maybe 75 years now? It's still in its infancy. Our tools are primitive. We need to recognize that, and be open to shifts in viewpoint that allow growth in terms of reliability and maintainability.