Re: newbie Q: storage management

[jsa@alexandria (Jon S Anthony)]

In article <336A065B.41C6@magellan.bgm.link.com> "Samuel A. Mize" <smize@magellan.bgm.link.com> writes:

> (2) the requirement for upward compatibility, and (3) inertia.  (See

I think your point (3) is very apropos.


> > How can this be the responsibility of the application programmer?
> 
> The same way it's the programmer's responsibility to make sure
> that the implementation supports the Distributed Annex when writing
> code that requires it.
...
> The point is just that there isn't an onus on all implementations
> to reclaim memory when it's freed.

Just like for DSA, et.al.  Sounds familiar.


> So, we two and the standard agree that a non-reclaiming implementation
> would be marginal at best.  But, it could validate, and would be useful
> -- even critical -- to a small minority.

Check.


> > I suppose you would really be against GC.
> 
> No, not at all.  The poster asked about the reasons for a decision,

That's good to hear!


> and I explained them as best I understood the reasoning of the
> language designer (I don't see Mr. Ichbiah posting here, or I'd
> let him speak for himself).

;^)


> The specialized needs annexes are a great boon, and there are
> several I'd like to see defined.  Maybe there could be created a
> working group for interim/proposed annexes.  They need to be
> written down, debated, and tested out, just like Ada 95 was.

I agree and as I've said before, I think this sort of idea is very
good.  Others strongly disagree.


> The only decent argument I've seen against a GC annex is that it
> would have to either select a single approach and denigrate all
> others, or else provide such a generalized interface as to be a
> pointless standard.  I DON'T AGREE OR DISAGREE WITH THIS, since
> I know too little about garbage collection research.  The best
> refutation would be a strawman of the package(s) and/or the
> rules that the annex would provide.

The "single approach" argument is definitely wrong.  The "too general"
argument is in error too as this can be handled with a subsystem
approach (similar to Interfaces).  I am working on this _sort_ of
thing now, which would support working versions now within the
language (i.e., w/o compiler support).  OTOH, any reasonable
description for an annex here would have to assume compiler support
and that changes what the stuff looks like.


> I suspect it mostly didn't get an annex because the pro-GC forces
> were sociologically unable to force the issue.

I'm pretty sure something like this is true.


> > I know Robert
> > thinks this is "gratuitous rubbish",
> 
> Hi, my name is Samuel Mize.  I work for Hughes Training, Inc.  I

I was not refering to you by "Robert" here! :-) Though I can see how
you would think that given the way it was written...  I was actually
refering to what Robert wrote in another thread a while back.


> If I unintentionally hit buttons on you that are sensitive
> from discussions with him, I apologize.

Nope.  Not at all.  I just have a different perspective.


> Well, connotations always depend, to some extent, on the reader.

Definitely true.  A good point to bring out.


> To me, the connotation is "be careful."  It's the difference
> between a fellow professional warning you to be careful, and a
> mother screaming at a four-year-old to be careful.  (Some of the
> language committee are real mothers. :-)

So to speak  :-) :-)


> > I'm working on a set of GC subsystems providing a range of generic GC
> > variants which will allow you to create various collectors (various
> > versions of mark-sweep, mark-compact, copying, generational,
> > concurrent, treadmill, etc.) for your supplied type(s).
> > ...
> > I can't say for sure when all this will be ready, but probably some
> > time this summer.
> 
> I very much look forward to seeing it.  Is this going to be freely
> available (perhaps copyleft), shareware, a product, or what?

Excellent.  That's a very good question.  In general I think it would
be good if this stuff were widely and readily available, and that it
is seen as usable in other products.  That eliminates "standard" GPL
and indicates that it should also be supported.  I'm not sure yet what
the "right" thing to do is.


/Jon

-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com