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 describe this. 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 panacea. > 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 calculus. 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. Sandro _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
