[e-lang] Reentrancy via Recursion

[Toby Murray]

On Thu, 2009-02-26 at 13:01 +0000, David-Sarah Hopwood wrote:
> Toby Murray wrote:
> [...]
> > Would the addition of another invocation operator (on top of "." and
> > "<-") to E that means
> > "immediate-call-to-untrusted-object-that-shouldn't-be-able-to-recursively-call-me"
> > be fair? Being able to use such an operator would enable the programmer
> > not to have to worry about these kinds of bugs.
> 
> I think I'd prefer an annotation per object (i.e. 'this object cannot be
> reentered'), rather than per call.
> 
> DeepFrozen objects can be safely reentered. I think there's a good case
> for almost all other objects being non-reentrant. Stateful objects don't
> accidentally work correctly when reentered; they have to be designed to
> work correctly in that case.
> 

I like this. I think you've hit the nail on the head with the assertion
that non-deepfrozen (or "non functionally pure" if you like) objects
need to be designed very carefully to be safe under reentrancy.

David Wagner's attacks on "well known" code prove just how careful one
needs to be. I'd argue, more careful that even the experience OCap
programmer is accustomed to being. OCap programming is supposed to make
writing safe code easy. recursive reentrancy seems to be an area that it
doesn't (yet) help much with.

Would implementing the restriction that non-DeepFrozen objects cannot be
recursively called in E be difficult? I'd be curious to know how much
code would break under this restriction. Ordinary programs would need to
be annoted, e.g.

def factorial(n) :any {
    if (n > 1) {
        return n*factorial(n-1)
    } else {
        return 1
    }
}

would break here. Perhaps making a "Pure" guard (that is a synonym for
deepfrozen) would be helpful in such cases where one wants to write
recursive pure functions.

Cheers

Toby