Re: How to get Ada to ?cross the chasm??

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

"Paul Rubin" <no.email@nospam.invalid> wrote in message 
news:87h8no1nli.fsf@nightsong.com...
...
> What the function is really generating is a tree structure, with nodes
> that can be expanded into further nodes or to sentences.  So you should
> really represent those sentences as trees, where you print a sentence by
> traversing the tree recursively.

Surely, and you can use the tree container to represent such a tree. No GC, 
no explicit memory management, no fuss, no muss.

And similarly in the original code, presuming that it is fast enough. The 
compiler does any needed memory managment. The cost of doing that is rarely 
an issue (see the many threads here on premature optimization).

...
> There are various ways you can deal with this storage management issue.
> So you can think up a workable approach, implement and debug it, write
> regression tests and monitoring for it, etc.  Or you can just not think
> about it at all, allocate new data whenever you want, and let GC take
> care of freeing it.

Or you can just use the built-in facilities of Ada to do the storage 
management and not think about it. The original code above did that and 
somehow you managed to decide that it wasn't good enough unless it had to 
use GC somehow.

> I vote for GC :).

Desire for GC is a good way to tell people who want to build quality 
software from those who just want to throw software at the wall. :-)

In any event, why are you here? There is no realistic chance that Ada will 
ever be changed enough to make it amenable to GC. I proposed such changes 
multiple times in the past and got nowhere with them. (The problem being 
that the location of finalization of most objects is too late for any useful 
GC to be possible -- it's generally associated with the access type, which 
is usually declared at the library level. Thus GC can't clean up most 
objects until the type goes away -- which is usually when the program 
exits.) The compatibility issues have only gotten worse in the mean time --  
we've tied down the finalization rules more in the intervening years, so 
there is likely to be more code that depends upon them.

                                    Randy.