Syntax error: I believe you meant to write (lambda (y) ...)
In response to the issue you raise, I do not agree that the problem here
is loss of transparency. What the programmer intended simply isn't what
they wrote. I think that the correct handling of this problem is with a
warning when a polyinstantiated procedure captures a polyinstantiated
closure with an unboxed ref type. In truth, this is no different from a
templated procedure in C++.
There is actually a more subtle problem here. Suppose we modify your
example to restrict the parameter to the inner lambda to
(lambda (y : (boxed 'a))
...)
the nice thing about this is that the overload expander is able to
detect that nothing actually dereferences this pointer, and ignoring the
closure problem it would be able to use the same implementation for all
overload expansions of f2. The real problem here is to determine when
this optimization is okay.
Arrgh. Yes, I see the problem, and I'm increasingly tempted to wonder
whether we shouldn't just go back to Wright's style of polymorphism, but
I'm not convinced that with the introduction of explicitly unboxed types
it remains viable.
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
