[bitc-dev] Retrospective: The Issues with Type Classes
naasking at higherlogics.com
Sun Apr 8 20:27:58 PDT 2012
On 08/04/2012 10:25 PM, Jonathan S. Shapiro wrote:
> That is /not/ a workable solution in the large.
One line per sum case/type, and wrap/unwrap at every overload boundary
is not a high cost at all when compared to the other costs of a large
project. A bandaid and a nuisance it may be, but it's not a huge burden.
The use of a different natural ordering also implies a different type,
although I agree in principle that there must be some better way to
Empirically, there have been quite a few large Haskell projects that
would have been much more difficult were this really a problem in the
field. They'd be clamoring to get this fixed. I agree a better solution
would be preferable, but is it really so much higher of a burden than
C++'s pitfalls with multiple inheritance and such? There is currently no
> The obvious solution seems to simply provide a single guarantee:
> efficient code generation/inlining of these overloads only when whole
> program compilation is possible.
> So it's okay, in your view, to achieve performance only for a set of
> programs of size zero?
I can point trivially to the entire open source ecosystem as a
counterexample. Closed source programs are at the edges of the where
virtually everything higher in the dependency tree has open source code.
That's pretty common these days, as even Microsoft has open sourced
their software stacks. Perhaps it's less common in the embedded space.
You have to start somewhere though, and at least you can achieve your
technical goals with that initial compromise. All prelude types could
automatically specialize where desired, so that's already a big win.
This leaves the boundaries between dynamically linked modules as the
only costly transition. Why is this a huge problem?
> Perhaps the problem was really trying to co-opt type classes for laying
> out record structures....
> No, no. It had absolutely nothing to do with layout, and we didn't
> introduce it for that reason in any case.
IIRC, has-field was introduced because you wanted to ensure that a
record has a field with a certain label. This is within the purview of a
record calculus. Type classes would give you a function representing a
field accessor, ie. one additional level of indirection above the record
Perhaps "layout" was a bad choice of word. I didn't mean a particular
ordering of fields, I just meant the declarative structure of a record
as a product, ie. abstracting completely from the record and treating it
as an unordered set of labels. That wasn't what you were after was it?
>From your description, you wanted enough information to resolve real
field offsets. A record calculus will get you that, but it'd be tough
for type classes to get you there.
More information about the bitc-dev