[bitc-dev] Bitc -> Polymorphic

[Jonathan S. Shapiro]

On Sat, 2005-01-29 at 15:27 +0100, Jørgen Hermanrud Fjeld wrote:
> But this is a problem with universal quantification, not with
> overloading.
> 
> Extensional polymorphism would allow overloading for g, depending on the
> type of x and the return type of g. (I'm not into BitC syntax)
> 
> (extern (g1 x:int):int)
> (define (g2 x:float):int ... body ...)
> 
> (generic g (int->int,g1) (float->int,g2)
> 
> g 1 ; invokes g1
> g 1.0 ; invokes g2
> g "1" ; type error

I believe you may have misunderstood our objective.

It has never been a goal to allow user-specified overloading of the type
that you are describing above. Rather, we were using template-like
expansion to resolve what we (mistakenly) perceived as a polymorphism
problem.

We are, however, aware of the O'Caml problem of + vs. "+." and friends,
and it strikes us as unnecessarily ugly. Still, it's something that we
are willing to defer for the non-builtin procedures.

> One of the things that has dawned upon me
> during this work is that the type system of the O'Caml language is
> really good, not just a good solution, but the most efficient solution I
> have encountered, both with regard to the functional and object oriented
> parts of their type system. Had I understood then what I know now, and
> wanted to create a language, I would just start with the O'Caml type
> system, as it is theoretically sound and everything can be statically
> type checked.

I think that we agree. In fact, with polymorphism restored, the
differences between BitC and O'Caml are basically the following:

  Explicitly declarable boxed/unboxed types
  Greater range of fixed-precision integer types.

shap