[bitc-dev] Retrospective: The Issues with Type Classes

Jonathan S. Shapiro shap at eros-os.org
Mon Apr 9 10:28:23 PDT 2012


On Sun, Apr 8, 2012 at 8:27 PM, Sandro Magi <naasking at higherlogics.com>wrote:

> 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.
>

I'm not going to dignify that with a response.


> 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.
>

Why? Orderings and types don't have an inherent 1:1 relationship.

In any case, it wasn't a use of a different natural (in the human sense)
ordering. It was merely a case of a different ordering (note absence of the
word "natural" here) for the sort.


> >     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.


You can't point all you want, but it doesn't validate your argument. The
existing open source ecosystem relies heavily on dynamic libraries, which
means that source code is *not* known at compile time in general. This is a
technical issue, not a political one. The use of closed vs. open source
doesn't alter the conditions under which compilation occurs in any
particular programming language.

What *is* true is that existing languages that use template-like mechanisms
have moved to a space in which the *library* source (the part that must be
specialized) is exposed. The situation in CLI is conceptually similar,
differing slightly in that the code is exposed in a lower-level, common
intermediate form.


> 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.
>

Actually, they can't. The problem is analogous to the template
specialization problem in C++. You would need to state explicitly which
specializations should be pre-built in the libraries. The problem with this
is that you don't know in advance which type class instances you will be
invoked with, so it's hard to know what to hand-instantiate.


> This leaves the boundaries between dynamically linked modules as the
> only costly transition. Why is this a huge problem?
>

Huh? I don't think you are thinking this through. I write a library
function:

   def faux-add(a, b) = { a + b }

which is typed as

  Arith 'a => 'a x 'a -> 'a

and I put that in a library. I basically can't compile this function at all
until I know the instance of Arith, which isn't known until dynamic compile
time.

This means that I need the entire optimizer built into the dynamic linker.
The non-robustness implications of that are quite frightening.


> >     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.


Yes, but this had nothing to do with layout per se. It was confirmation of
a label's bindability within a record. The fact that this could *later* be
turned into a concrete offset at a much lower level of abstraction was a
pleasant side effect, but it wasn't the purpose of the mechanism.

Because BitC specifies layout, the fields of a record cannot usually be
viewed as unordered. In particular, subtyping by subsetting is frought with
peril.


> >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.


Actually it's very, very easy. A field name, by its very nature, is merely
a syntactic shorthand for an offset.


shap
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.coyotos.org/pipermail/bitc-dev/attachments/20120409/aa5d29a0/attachment.html 


More information about the bitc-dev mailing list