[e-lang] Consequences of transactional E?

[David Hopwood]

Kevin Reid wrote:
> On Jan 30, 2007, at 1:13, David Hopwood wrote:
>> Kevin Reid wrote:
>>
>>>    - Allow only Selfless objects to be carried by nonlocal exits.
>>
>> That is the solution I had intended [for exception objects].
>>
>>> I believe this is too restrictive, as otherwise exception objects
>>> cannot carry information useful for debugging without expensive
>>> printing at throw time, when it is not known if the information will
>>> ever be looked at.
>>
>> I don't think this is too restrictive, or too inefficient. Exceptions
>> are rare; the cost of printing debugging information is not significant.

In support of this, the current E implementation logs debugging information
for all exceptions to a file, by default.

> Besides the resource cost, it also prevents this kind of feature:
> 
> http://www.eros-os.org/pipermail/e-lang/2007-January/011809.html

The exception object doesn't have to specify precisely what will be
displayed to the user; it can be any Selfless description of the exception.

If you mean that the exception object could refer to a Selfish object, I
don't see how this could be given a safe and understandable semantics in
a transactional model:

 - the Selfish object might no longer exist, because its creation has been
   rolled back;

 - even if the object does exist, it is not safe to allow access to it after
   the rollback, because its authority may have been granted only based on
   conditions holding before the rollback that are no longer true.
   (TOCTTOU with a vengeance -- the use is in a different "universe" to the
   check.)

Referring to a Selfless object is OK because such an object grants no authority,
and is equivalent to a deep copy of itself. (Depending on the implementation,
a deep copy *might* actually be needed, so there is also an implementability
issue.)

-- 
David Hopwood <david.nospam.hopwood at blueyonder.co.uk>