Hi, I just wondered if you have considered the work on extensional polymorphism by Furuse [1] as a framework for overloading?
As far as I understand that would give the programmer explicit control over overload resolution, as well as provide static type safety. Also I wondered work on multi-staging [2] and macros [3] would be relevant? Especially since multi-staging researched fro O'Caml can be statically type checked. [1] http://pauillac.inria.fr/~furuse/thesis/ [2] http://www.metaocaml.org/ [3] http://www.cs.rice.edu/~taha/publications/conference/icfp01a.pdf On Fri, Jan 28, 2005 at 02:08:06AM -0500, Swaroop Sridhar wrote: > I was actually thinking for a while as to how overloaded functions in BitC > seem to have the power (of apparent polymorphism) that polymorphic > functions in ML do not. But after reading Wright's paper[*], it became > clear that they can do so only at the cost of transparency. > [...] > We can take two views about transparency here: > i) Transparent (meaning of visible): Unlike a eta-expanded-polymorphic > function, we canmake it clear to the programmer that a function that > has a polymorphic type actually represents a set of overloaded functions. > It is now the programmer's responsibility to write correct code. > > ii) Transparent (meaning invisible): Or, we may decide that the above > decision may result in bugs that are too subtle, and that it is not > feasible to rely on the programmers to get it right. > If so, we will have to impose the value restrictions as in ML. > > However, the saving grace is that Wright's paper also made the following > observations: > "1. Realistic ML code seldom computes polymorphic procedures or data > structures. > Furthermore, > 2. When polymorphic procedures are computed, the computation is almost > always functional." > > [*] A. K. Wright. Simple imperative polymorphism. LISP and Symbolic > Computation, 8(4), December 1995. > > Thanks, > Swaroop. -- 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
