Argumentation is the Father of Invention (was "Third Party Suicide?")

[Mark S. Miller <mark>]

(Or maybe that's the midwife?)

Boy do I feel silly.  In that mail message last night the weak link in
the chain that got us into trouble was staring us in the face.  In
retrospect it's hard to believe I wrote all that and missed it.  We
have a fall back position that is really quite good.  Articulating
ones premises sure are a good first step to rethinking them.
Argumentation in a written medium sure is a good way to facilitate
this articulation.

Ok.  Enough suspense.  The fall back position is...  But first, I
would like to point out that it is *only* a fall back.  Hopefully
things will work out with AT&T and Nat.

The envelope please.  The fall back position is...  The front-end
specifically can make do with a *conservative* collector!  Our
front-end code could still be non-conservative collector compatable
(by avoiding all those nasty &&s), but it would be up to our
developers whether they were will willing to give up so much of the C
language in exchange for sweeping up every last shred of garbage.
Based on the experience of others with conservative collectors, a
front-end that only needs to be up for hours and not months would do
fine.  Given a conservative collector, our PtrVars wouldn't need a
destructor, because they wouldn't be stringing and unstringing
themselves on a linked list.

By recommending (and providing) a conservative collector to our
developers instead of no collector, our own fe library code would not
have to be leak free.  Also, we could use Wjr's IntegerVars freely,
because they wouldn't need destructors either!

Note that this would create a lot of work: engineering both a
non-conservative collector (for the backend), and a conservative one
(for the frontend), such that code written for the first is compatable
with the second (so the backend and frontend can share libraries).  It
would still mean *we* would have to give up many nice C language
features, but at least we wouldn't have to ask our developers to.
While a conservative collector is *mostly* portable, there is a
significant non-portable kernal that would have to be ported every
time (the stack examiner and alleged pointer checker).

Under a conservative collector, strong-pointers could just expand to C
style "*" pointers.  By retaining checked pointers (which need no
destructors btw) for pointers in objects, it should still be possible
to do an incremental portable collector!  I was worried about this,
because a non-incremental collector would be death for the front-end
(having an interactive program sieze up o... (whew, emacs came back)
...n you is no fun).  The normal "conservative" assumption is that you
don't know where pointers are in either stack or heap.  Therefore I
expressed fear yesterday about portable incremental conseravtive
collection.  (Weiser's technique for conservative collection depends
on the garbage collector being able to write protect individual pages
and intercept write faults.  How many platforms would this be
available on?)  Today I realize that incremental collection requires
only keeping track of pointers in the heap, and these are causing us
no problems.

Once again, I'd much rather that things work out with cfront 2.1.