[bitc-dev] BitC Overloading

[Jørgen Hermanrud Fjeld]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://www.coyotos.org/pipermail/bitc-dev/attachments/20050128/38663685/attachment.bin