Dynamic closure vs static closure

[KennyTM~]

KennyTM~ wrote:
> Bill Baxter wrote:

-- snip --

> 
> OK. Then both the call site and the function need the "scope", since the 
> function signature alone is surely insufficient to determine if the 
> delegate is closure or not.
> 
> Since filling the parameter is just a cloning process, this can be 
> reduced to asking if
> 
>    <delegate-type> f = g;
> 
> will produce something weird, when one side is a closure, etc.
> 
> The simple solution is to make the delegates on stack a super type of 
> delegates on heap.
> 
> (Don't mind the "static" keyword yet. I followed the name "static 
> closure" described somewhere else. I agree "static" is too overloaded.)
> 
> 
> 
> --------
> 

-- snip --

> 
>   // Oops, cos_pi is on stack, but the func sig requires on heap.
>   // should generate error.
>   //store(cos_pi);
> }
> 
> // sin_pi already on heap, although the func sig said can be on stack.
> // should _not_ generate error.
> writefln(evaluate_at(sin_pi, 0.4f));
> 

-- snip --

Oops I caught myself. According to this type system store(cos_pi) should 
be correct while evaluate_at(sin_pi, 0.4f) will generate an error. It's 
ridiculous. This can be fixed by switching the role of inheritance of 
delegates and closures, i.e.

  Delegate dg = Closure // Valid.

  Closure cl = Delegate // Invalid.

Along with (let's get rid of all of them all together...):

  StaticDelegate dg = FuncPtr // Valid.
  Closure cl = FuncPtr // Valid.

  FuncPtr fp = Delegate // Invalid.
  FuncPtr fp = Closure // Invalid.

i.e.

  FuncPtr ---safe-assign---> Closure ---safe-assign---> Delegate.

(Delegate = Static closure, Closure = Dynamic closure)

I'll post my reasoning later, if one finds it unclear...