This example simply cannot be correct. f2 is infinitely recursive. Can
you clean it up, get the parens correct on the lambdas, and retransmit?
On Fri, 2005-01-28 at 02:08 -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.
>
> 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
_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev
