[bitc-dev] Type Classes for BitC

[Jonathan S. Shapiro]

On Fri, 2005-07-22 at 13:52 -0400, Swaroop Sridhar wrote:
> But, if I have a function defined as in:
> 
> (define myplus2 (let (x (mutable 0)) +))
> 
> this myplus2 is restricted due to the value restriction (as expected)...

I think the example is mistaken, because it does not capture the "x".
The instantiation is dead code, the program has unambiguous meaning, and
therefore the problem you are trying to construct need not arise.

However, I agree that it should be treated as an error, and there appear
to be several ways that we might handle this:

1. Notice that x is not captured and declare victory.

   This is bad because it suppresses an obvious error.

2. Perform an ad-hoc resolution of the literal type,
   leading to a concrete type for 'x' and eliminating the
   problem.

   Mark Jones has suggested that this may not be a wise
   approach.

3. Notice that the type of "0" cannot be resolved. Declare
   that the procedure is therefore non-instantiable and
   issue an error diagnostic.

4. Assign "x" a non-instantiable alpha type and issue an
   error diagnostic because the resulting procedure is not
   instantiable.

Actually, I think that the correct solution for this example is *both*
(3) and (4), and we issue an error diagnostic.


> (myplus2 10:int16 20:int16)
> (myplus2 10:int32 20:int32)
> 
> So, I wanted to bring up this topic ask whether this is something that 
> we should be concerned about in practice, considering heavy use of 
> stateful procedures.

In a word: no.

I *can* think of some examples where we might want something like a
"template procedure". Perhaps something like:

   (defeweda (proc-maker 'a)
      (lambda (x)
        (let ((v:(mutable 'a) 0))
          ...))

But I can't see any urgent use case.

Before someone asks: a fully instantiated ewe is a lamb, therefore a
fully instantiated eweda must be a lambda...



Baaaaaa.


shap