[gclist] Language behaviour wrt GC

[Henry G. Baker]

> On Thu, 5 Dec 1996 06:56:34 -0800 (PST), Henry G. Baker wrote:
> >If you do a search of the Ada repository, you will find that most, if not
> >all, of the 'pretty-printers' for Ada use a C-based parser, so Ada cannot
> >even parse itself!
> 
> First, there is a high-quality Ada95-compiler written in Ada. Obviously the
> compiler parses Ada code. You can download binaries and sources from 
> ftp://cs.nyu.edu/pub/gnat. It is free, although you have to pay for support.

I haven't looked at the source code for gnat, so I don't know what
language its parser is written in.  Obviously, you _can_ write an Ada
parser in Ada, as many of the early Ada compilers did exactly that.
However, those that were written in Ada took about 10X the time and
10X the space of other parsers, so I imagine that people putting code
into the Ada code repository found that it was cheaper/faster/easier
to build their parsers in C.

> If people get upset about me asking questions about implementing GC for
> Ada and Modula, I might as well stop using this list as I'm not really 
> interested in language wars. I'm interested in discussing language behaviour
> with respect to garbage collection.
> 
> When I suggested creating a garbage collection specific newsgroup/mailinglist 
> in comp.compilers, I really hoped that it would be possible to discuss
> things like these.
>    Geert
> -- e-mail: geert@sun3.iaf.nl

If you check, you will find that I submitted requests to the Ada95
'process' arguing to include GC.  It was in response to those requests
that I learned how remote GC was from anyone's mind in the US DoD Ada
community.  Most of these guys don't even believe in dynamic storage
allocation (even _stack_ allocation), much less GC, so we were not
even in the same universe.  (Curiously, they don't mind using COTS
(Commercial, Off-The-Shelf) software written in C that is far more
sophisticated, and also far more buggy; they obviously use a double
standard for evaluating different languages.)

[BTW, If you check the comp.risks archives, you will find discussions
of one of the German subway/train systems failing due to stack
overflows.  Examples like these tend to make people shy about storage
management.]

-- 
Henry Baker
www/ftp directory:
ftp.netcom.com:/pub/hb/hbaker/home.html