comp.lang.ada
 help / color / mirror / Atom feed
* Abnormal objects - how they can become normal again?
@ 2005-12-21 13:01 Maciej Sobczak
  2005-12-21 21:47 ` Robert A Duff
  0 siblings, 1 reply; 4+ messages in thread
From: Maciej Sobczak @ 2005-12-21 13:01 UTC (permalink / raw)


Hi,

If an object is abnormal, it can become normal again after a successful 
completion of an assignment to this object.
The problem is that during the assignment, the finalization of the 
(still abnormal) object should take place. How it can happen, if at the 
same time evaluation of the abnormal object is erroneous?

 From the programmers perspective, there are two cases:
- "simple" types (like Integer), with basically empty finalizers; 
nothing bad can happen there, so assignment to an uninitialized variable 
is harmless,
- controlled types; but there, finalizers come bundled with initializers 
so that there's no way to make an object abnormal by just forgetting to 
initialize it - the only way to make an object abnormal would be to 
abort a previous assignment, which is a no-no anyway.

I understand the issue from the implementation point of view, but the 
wording in AARM (13.9.1) seems to be a bit fragile. From the 
language-lawyer's point of view: how to assign to an abnormal object, if 
its evaluation is erroneous?
Is the object evaluated before it's assigned to or as part of the 
assignment process (especially finalization)?


-- 
Maciej Sobczak : http://www.msobczak.com/
Programming    : http://www.msobczak.com/prog/



^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Abnormal objects - how they can become normal again?
  2005-12-21 13:01 Abnormal objects - how they can become normal again? Maciej Sobczak
@ 2005-12-21 21:47 ` Robert A Duff
  2005-12-22 10:50   ` Alex R. Mosteo
  0 siblings, 1 reply; 4+ messages in thread
From: Robert A Duff @ 2005-12-21 21:47 UTC (permalink / raw)


Maciej Sobczak <no.spam@no.spam.com> writes:

> Hi,
> 
> If an object is abnormal, it can become normal again after a successful
> completion of an assignment to this object.
> The problem is that during the assignment, the finalization of the
> (still abnormal) object should take place. How it can happen, if at the
> same time evaluation of the abnormal object is erroneous?
> 
>  From the programmers perspective, there are two cases:
> - "simple" types (like Integer), with basically empty finalizers;
> nothing bad can happen there, so assignment to an uninitialized variable
> is harmless,
> - controlled types; but there, finalizers come bundled with initializers
> so that there's no way to make an object abnormal by just forgetting to
> initialize it - the only way to make an object abnormal would be to
> abort a previous assignment, which is a no-no anyway.
> 
> I understand the issue from the implementation point of view, but the
> wording in AARM (13.9.1) seems to be a bit fragile. From the
> language-lawyer's point of view: how to assign to an abnormal object, if
> its evaluation is erroneous?
> Is the object evaluated before it's assigned to or as part of the
> assignment process (especially finalization)?

If the abnormal object is not controlled, then you can just do a whole
object assignment to repair it; there's no read of the object in that
case.

Controlled objects require special care.

Abnormal objects can be caused by aborts, and by exceptions.

In the case of aborts, you can take advantage of the fact that certain
operations are abort deferred (finalization, for example -- look up
"abort deferred" in the RM index for a complete list).  In the case of
exceptions, you can write code that doesn't raise exceptions.  Note that
11.6 says that the exceptions can appear to move around.  For example:

    X := Y;
    Z := W;

If "Z := W;" raises Constraint_Error, then this can cause X to become
abnormal!

One case I know of that can't be dealt with properly (while relying only
on portable rules in the RM) is Storage_Error.  It's like abort, in that
it can happen pretty much anywhere, but unlike abort, there's no way to
prevent S_E from happening in a certain region of code.

Another way to deal with abnormal (possibly controlled) objects is to
add a level of indirection.  I believe you can Unchecked_Deallocate an
abnormal object (not sure).  Assignment of access values does not
involve finalization.  So when you have a possibly-abnormal object, you
could simply throw it away and create a new one.

- Bob



^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Abnormal objects - how they can become normal again?
  2005-12-21 21:47 ` Robert A Duff
@ 2005-12-22 10:50   ` Alex R. Mosteo
  2005-12-22 15:57     ` Robert A Duff
  0 siblings, 1 reply; 4+ messages in thread
From: Alex R. Mosteo @ 2005-12-22 10:50 UTC (permalink / raw)


Robert A Duff wrote:
> (snip)
> 
> Another way to deal with abnormal (possibly controlled) objects is to
> add a level of indirection.  I believe you can Unchecked_Deallocate an
> abnormal object (not sure).  Assignment of access values does not
> involve finalization.  So when you have a possibly-abnormal object, you
> could simply throw it away and create a new one.

I guess you can indeed free abnormal controlled objects, but this will 
trigger finalization, and I think the OP wanted to avoid this (as this 
happens too when overwriting the abnormal object during asignation).



^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Abnormal objects - how they can become normal again?
  2005-12-22 10:50   ` Alex R. Mosteo
@ 2005-12-22 15:57     ` Robert A Duff
  0 siblings, 0 replies; 4+ messages in thread
From: Robert A Duff @ 2005-12-22 15:57 UTC (permalink / raw)


"Alex R. Mosteo" <devnull@mailinator.com> writes:

> Robert A Duff wrote:
> > (snip)
> > Another way to deal with abnormal (possibly controlled) objects is to
> > add a level of indirection.  I believe you can Unchecked_Deallocate an
> > abnormal object (not sure).  Assignment of access values does not
> > involve finalization.  So when you have a possibly-abnormal object, you
> > could simply throw it away and create a new one.
> 
> I guess you can indeed free abnormal controlled objects, but this will
> trigger finalization, and I think the OP wanted to avoid this (as this
> happens too when overwriting the abnormal object during asignation).

Good point.

So I guess the answer is, "never allow controlled objects to become
abnormal (if you wish to use them ever again)".  And as I said, abort
deferral can help you program this.  It's not easy.

- Bob



^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2005-12-22 15:57 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2005-12-21 13:01 Abnormal objects - how they can become normal again? Maciej Sobczak
2005-12-21 21:47 ` Robert A Duff
2005-12-22 10:50   ` Alex R. Mosteo
2005-12-22 15:57     ` Robert A Duff

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox