Re: Discriminated record question

["Randy Brukardt" <randy@rrsoftware.com>]

Robert Dewar wrote in message
<5ee5b646.0205081852.4e2c20dc@posting.google.com>...
>"Randy Brukardt" <randy@rrsoftware.com> wrote in message
news:<udga38i7bj1g89@corp.supernews.com>...
>> Janus/Ada does that (in both Ada 83 and Ada 95). I used
>> to think that that was the only reasonable model, but it
>> is clear that the implicit heap use is a bad thing in
>> certain environments.
>
>Alsys used to do this as well in Ada 83. Did anyone get
>it quite right? Alsys did not allow such beasts to be
>nested in full generality, since this leads to complex
>non-contiguous representations.
>
>At least one other Ada 83 compiler trying this (Janus?)
>had storage leaks, and was so nice as to warn you that
>declaring the type would cause a storage leak.
>
>(it is non-trivial to avoid storage leaks, if you allow
>these implicit heap pointers to nest).


Right, Janus/Ada 83 had significant storage leaks in a few cases. The
primary problem was that the code at runtime did not know which heap the
implicit data was allocated from, so it couldn't know the correct way to
deallocate it.

This is solved (I think) in Ada 95 with storage pools. Since every
object has an associated storage pool (usually its implicit) anyway, and
the thunks have to pass them around anyway, the deallocations can be
done safely. (Tuck as recently convinced me that the storage pool
implementation is wrong for nested scopes, but that's unrelated to the
deallocation problem.)

We still give the non-contiguous type warning, though, because it says
that taking 'Address on the object may not be a good idea, etc.

>It is definitely a bad idea for a compiler. If you want pointers and
dynamic allocation,
>write it that way.

The job of a compiler is to make programming as easy as possible for a
given language. Putting arbitrary limits on a language feature doesn't
meet that goal IMHO.

>As far as I am concerned, for a language at the level of Ada, it is a
>bad idea in *all* cases to do implicit heap allocations for a type
declaration of this kind.

You may be right, but then I would argue that the language is
incorrectly designed. Because it suggests that you can create an object
without determining the size until runtime, but that is not really true.
(Not that I have a better idea for the language.) The current situation
requires an arbitrary maximum size to be determined ahead of time, and
incorrectly choosing that size breaks the portability of your code.

            Randy.