Static analysis of non-local transfers: a proposal

[John Longley]

Thanks to all for the interesting replies.

It's true that my proposal depends on function types and closure types  
being distinguished at an early stage of processing. However, once my  
proposed conditions have been checked, the types can of course be  
identified.

The concurrency examples are very interesting. Mark wrote:

> I interpreted John's proposal as really being targeted at the 'late
> transfer' rather than 'wrong thread' form, and as such the
> restrictions shouldn't prevent the deliberate use of  UnmatchedTransfer
> for the creation of APIs like 'for eachConcurrently'.

Yes, that's how I see it. One possible approach might be simply to  
accept that my proposal doesn't exclude UnmatchedTransfer in  
concurrent situations. This mightn't seem so bad if the idea is that  
the clever concurrent stuff is written once-for-all by an expert who  
knows what they're doing and then stuck in an API.

The crucial lines of code for handling these transfers (taken from  
Mark's blog) are

       if (throwable instanceof UnmatchedTransfer)
            throw ((UnmatchedTransfer) throwable).transfer();

Although I don't understand exactly how this works, I imagine that  
returning control to the correct thread is pretty much *always* what  
one wants to do in practice. So perhaps there is also a more  
sophisticated approach which would build in this behaviour somehow -  
e.g. any concurrent code involving closures is treated as implicitly  
having a handler like the above, so that it's still guaranteed that  
the programmer never sees an UnmatchedTransfer? (I haven't thought  
this through in detail.)

As a further point, I'd also like to describe how I think my proposal  
can simplify the tracking of exceptions, but I'll save this for  
another message.

Cheers, John


-- 
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.