[gclist] Resource Management & Meta-Level Encapsulation (was: Finalization & OO)

[Fare Rideau]

There is a recurrent debate in gclist about
whether finalization should matter or not to "the program".
Recent messages have suggested that ideally,
resource management should be encapsulated into abstract objects,
so that you could manipulate these abstractions without having to care.
Only resource-management is a global property of programs,
that you can't efficiently implement by mere local chunks of code,
while efficiency is precisely what motivates it to begin with.
We end up with system that statically establish
a precarious balance between various tradeoffs,
that can satisfy only people using precisely the type of application
intended during design of the resource manager.
   Usual ground OO encapsulation cannot help much here.
The problem here is lack of meta-level encapsulation.
See my recent posts in comp.compilers.

It seems to me that this problem like many others
stems from the confusion of meta-levels:
paradoxically, the fear of Godel's ghost (among other factors)
make people refuse to face meta-problems,
and try to do everything in one-level systems
that Godel-type arguments precisely point out as insufficient.
This is kind of the ostrich way of solving meta-problems.
   As a result, current languages are irreflective,
and the programmer must write one-level programs
in which all meta-concepts and semantic layers must be folded.
The only way such programs could have a clean encapsulation would be
to build them in an exponentially inefficient stack of interpreters;
in the other case, we end up with a semantic mess,
and it is no more computer runtime but programmer development-time
that becomes exponentially inefficient.
   Resource management is a typical meta-programming feature
that everyone finds desirable to automatize,
if only it could be controlled at the same time.
Only by not providing clean access to meta-levels,
current programming languages make that impossible, but by kluges.

In a reflective language,
you could isolate meta-parts of the program
to which resource-allocation and finalization matter
from abstract-parts to which where they don't;
you could build abstract objects and refine their operational semantics
without having to contort your design to fit
the unique "absolute meta-level" granted by a non-reflective language.
Folding meta-levels to achieve efficiency would be the task
of the (human-aided) computer, not that of the (computer-aided) human.

BTW, I'm always taker for a meta-GC project,
though in my current schedule, it doesn't feature before 1999;
I must first develop a reflective architecture.
Or perhaps there already exists one somewhere? Hints welcome...

== Fare' -- rideau@ens.fr -- Franc,ois-Rene' Rideau -- DDa(.ng-Vu~ Ba^n ==
Join the TUNES project for a computing system based on computing freedom !
                TUNES is a Useful, Not Expedient System