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