[Grace-core] Minutes of Teleconference 23-24.8.12

[Andrew P. Black]

Hi Bart,

Thanks very much for this.  I took a quick look at your slides on Failboxes, but have not yet read the paper.  (I put a copy in "Background Papers").   I certainly agree that this highlights a real problem.

I also like the distinction that you make between checked and unchecked exceptions.  I think (although we may not agree on this) that in Grace, exceptions will not be used as a control structure (Java's checked exceptions) but only in case of failure (Java's unchecked exceptions).  So the point of failboxes — ensuring that failed objects are really dead — is highly appropriate to us.  OS6 did something similar, but strictly less powerful, since "mailboxes" (what it called the run-giveUp mechanism) was strictly stack based, and a failing computation could have damaging effects of objects allocated in a surrounding scope.  

As an aside, yesterday we talked about using the word "raise" to initiate a non-local transfer of control with an associated exception value.  I'm now thinking that the word "giveUp" might be better, and that we should consider having a refinement hierarchy of 'failures' rather than of 'exceptions'.  Hence

	def keyNotFound = SubscriptBoundsFailure.refine

	table at (k) ifAbsent { giveUp(keyNotFound "key {k} not found in {table}" ) }

Maybe I'm pre-occupied by finding the best names for things.  I hope that the names that we use in Grace will have an effect on students, and that calling these things failure will help to ensure that they are used for handing failures, not as a control structure.    

I did not understand the interaction of Failboxes with objects.  In particular, what happens if there are inter-object invariants that are manipulated by a failing computation?  Each of the objects, in its own Failbox, may be consistent, but the program as a whole is not.  This sounds like the problem that transactions were designed to solve.  


On 24 Aug 2012, at 3:05, Bart Jacobs wrote:

> 
> - there should be a mechanism to (asynchronously) run code in another thread. I.e., there should be a method runCode(code) on Thread objects. (This method should probably not be available for general use!)
> 
> 

Can you explain a bit more why one needs this and when one would use it?  This is different from theBlock.fork, right, in that theBlock runs in a particular existing thread, rather than a new thread.

	Andrew