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.
Consider the following example (adapted from one of the
examples in Wright's paper)
(define count (mutable 0))
(define f1
(lambda f
(local
((define x (mutable 0))
(define f2
(lambda y
(begin
(set! x (+ x 1))
(set! count x)
(f y)
)
)
)
)
f2
) ; local
)
)
Type of f1 is (fn (fn 'a 'b) (fn 'a 'b)), and is hence Overloaded.
(define f3 (f1 (lambda x x)))
//f3: (fn 'a 'a)
Actually what this produces is the closure f3 = {fn = f2, env = {x}}
Now,
(define temp
(begin
(f3 1:int) ; count = 1
(f3 2:int) ; count = 2
(f3 3:int) ; count = 3
(f3 true) ; count = 0 !!!
count
)
)
The value of count after the 4th application is 0 because it was a
different function created from a *different* overload of f1 which
gave it a *different* x in its closure.
That is, the different overloaded functions of f3 are *visible* to the
programmer
unlike a single polymorphic function. This is similar to eta-expansion of
polymorphic
functions in ML.
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.
_______________________________________________
bitc-dev mailing list
[EMAIL PROTECTED]
http://www.coyotos.org/mailman/listinfo/bitc-dev
