[gclist] Finalization, collection, etc.

[David Bruce]

bobduff@world.std.com (Robert A Duff) wrote:
(   Right.  But you seem to be drawing a disctinction between stack/non-gc
 )  languages, and heap-only/pure-gc languages.  But there's no reason why a
(   language can't have stack-like variables, and *also* have a
 )  garbage-collected heap.  In fact, that's what *I* want in a language.

You can of course have this.  What we don't want, however, is to have
to distinguish stack-variables and heap-pointers (choosing terminology
arbitrarily) at the language level, except perhaps at their point of
declaration -- unless for some reason you want to.  Notice that this
means that it must be possible to manipulate either at a common type,
allowing them to be given indistinguishably as arguments to functions, etc.

One way of achieving this is via an effect system a la Lucassen.
In his thesis he shows how one can identify those variables (and in a
subsequent paper, continuations) that can be safely stack allocated,
and how to declare that they must be.  (In the latter case, you get a
compile-time effect error when they can't.)  This holds true even when
these values are passed to (potentially unknown) functions, etc.

GC-triggered finalization suffices in such a context, as leaving the
scope of such stack-allocable values would cause their immediate
collection and hence finalization.  (If you nest scopes one variable
at a time, I don't think that finalizers could become circular without
losing stack-allocability; if cyclic declarations were permitted, I
imagine that they could -- though it would be pretty blatant.)

Would this be sufficient?
 

    David Bruce
----
post:  DRA Malvern, St Andrews Road, Malvern, Worcestershire WR14 3PS, ENGLAND
email: dib@dra.hmg.gb   **  WWW[tmp]: http://siwg.dra.hmg.gb/commerce/malvern
phone: +44 1684 895112  **  fax: +44 1684 894389 or 894540  **  telex: 339747