I would like to point out that the problem here is orthogonal to extensional polymorphism, which also uses the value polymorphism restriction.
On Fri, Jan 28, 2005 at 12:38:57PM -0500, Jonathan S. Shapiro wrote: > [...] > So: BitC is once again polymorphic, and now adopts the ML value-type > polymorphism restriction. This puts us back into the well-understood ML > type system, This sounds reasonable. > but it has implications for calling convention. > > Consider a procedure > > (define (g x:'a) ... body ...) > > If the received parameter x does not have a single size, then we would > need to polyinstantiate the implementation of g, because the code would > need to embed (for example) different parameter offsets. The difficulty > with this is that polyinstantiation of this sort drives you back into > Swaroop's sample problem above. > 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 would like to stress that Furuse defines flow analysis such that g is approximately compiled into an array of the functions it uses, and then the application g 1 can be compiled to an array lookup to the correct index for that application. Notice that at the call site this index is statically known, there is no interpretation. A program that values speed, such that one array lookup is to expensive, could use g1 and g2 directly. The other programs can use the overloaded function g. I don't think BitC should adopt extensional polymorphism right away, but I strongly suggest you consider what it would provide you with. I would just like to note that I'm finishing my master thesis in computer science know, writing a high level compiler for an object oriented language Creol. 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. The most cumbersome part about the O'Caml type system is the lack of overloading, such that one must write print_int and print_float, and have + for ints and +. for floats. Since you seem to move towards an ML or O'Caml like type system, the work on extensional polymorphism intergrates cleanly and provides overloading with very little overhead. -- Sincerely | Homepage: J�rgen | http://www.hex.no/jhf | Public GPG key: | http://www.hex.no/jhf/key.txt
signature.asc
Description: Digital signature
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
