> And at that point, all the power you get from saying things like there's only one possible implementation of a function f :: a -> a immediately go out of the window, because you don't have a value of type a, you have a value of type SomeConcreteTypeThatIKnowThingsAbout.
Not if your logic is primarily in terms of domain types, invariants encoded in those domain types as is necessary and economical.
> And at that point, all the power you get from saying things like there's only one possible implementation of a function f :: a -> a immediately go out of the window, because you don't have a value of type a, you have a value of type SomeConcreteTypeThatIKnowThingsAbout.
Can you give an example? I can only see this being the case if your logic is done at the concrete type level.
I wonder if we're talking at cross-purposes here. While it is certainly useful to write abstractions of common algorithms and access patterns for data structures generically, any useful program ultimately has to deal with data of known types. Those might come from the domain model, or they might be implementation tools like file handles or database queries, but they are something specific, some concrete type that is relevant to the problem at hand.
Not if your logic is primarily in terms of domain types, invariants encoded in those domain types as is necessary and economical.
> And at that point, all the power you get from saying things like there's only one possible implementation of a function f :: a -> a immediately go out of the window, because you don't have a value of type a, you have a value of type SomeConcreteTypeThatIKnowThingsAbout.
Can you give an example? I can only see this being the case if your logic is done at the concrete type level.