Re: memory management in Ada: tedious without GC?

[Robert A Duff <bobduff@shell01.TheWorld.com>]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> Yes, this why it is safe to assume that the program may not rely on it.

Such assumptions are never safe, because programmers make mistakes.

> Yes, this is the same dilemma as with re-ordering operands in expressions.

I don't like the permission to reorder operands, either.
But at least for that, there's a legitimate efficiency concern.
For finalization, I seriously doubt that the permission
to reorder has any significant efficiency benefit.

> I understand your argument, but I think that the solution is wrong. I'd
> prefer a better control over the side effects in order to make such
> (erroneous) programs illegal. It is especially important for modern
> pipelined, multi-core architectures. Why not to perform initialization of
> components concurrently?

Sure, if the compiler can prove there are no side effects,
it can reorder, intersperse, and/or do things in parallel.
In that case, "in declaration order" and "in implementation-defined
order" are equivalent rules.

But this is a much bigger change to Ada.

>> Consider two finalization actions -- one flushes a buffer to disk,
>> and the other closes the file handle.
>
> It is a wrong design to handle this from components and from different
> actions of finalization. Buffer cannot be flushed without knowing the file
> handle. Thus with right design the buffer component will have no access to
> the file handle. Hence flushing could only be put into the finalization of
> the composite object, which would automatically enforce proper order.

I admit my example is weak.

>>>... Consider a statically constrained discriminant as an
>>> example. If the compiler could remove it, we would have the problem of
>>> measurement units solved!
>> 
>> Yes.  I've always wanted to do that optimization.
>> 
>> The strange thing is that most compilers do exactly that for array
>> bounds, but not for discriminants.  Array bounds are really
>> discriminants, deep down!  ;-)
>
> Yes, and don't forget type tags. They are discriminants too!

Right.

- Bob