_My_ ideas for current research!

Some people have been asking about areas of current research, and
we've started to digress into a discussion of OO programming. Before we
get any further off-track, let me point out some of the areas _I_ think
are interesting and currently being explored. Let me point out that these
are my personal interests; just because something is not here doesn't mean
I don't think it's worthwhile:


1) Functional Program Compilation. The basic notions of functional
programming are well understood from a _language_ point of view, but
problems still remain with their implementation. Most functional
languages permit nested function declarations; these are usually
implemented as closures in the heap, with activation's return points kept
on a stack. Is this the right way to go? It is possible to eliminate the
run-time stack altogether using _continuations_. This may, or may not,
turn out to be a better approach in the long run.


2) Garbage Collection. Garbage collection remains a major issue in
functional language implementation. There have been many attempts to
manage garbage, but they usually fall into two camps, the "reduce" camp
and the "recycle" camp. The first attempts, through tricky optimizations
and such things as reference counts to keep the amount of garbage in the
heap as little as possible. This slows down execution, however. The
second camp generates garbage furiously, but uses the extra time to allow
for longer, more frequent, garbage collections. Is either approach
better?


3) Correctness. Most programming languages in use today have, at best,
only an informal language semantics. This means that there's no objective
criteria for testing the correctness of a compiler, or, for that matter,
deciding what a program even means. (Witness the difficulties in porting
code between platforms.) Recently there is a movement afoot to give
formal semantics to real programming languages, and to use these to
generate compilers that are correct "by design," usually revolving around
some sort of program-transformation compiler. Is this feasible?


4) Run-Time Environments. Traditionally, language designers ignored the
run-time environment and considered their programs in isolation. Grubby
stuff like I/O was sort of tacked-on later. Is there a better approach?
How should one formalize the interaction between a program and its
environment? What does this mean for operating system design?


5) Abstract Data Types. Abstract data types are a very powerful tool for
data abstaction and program control, and it's time that they moved into
production languages. But some lingering issues remain. How does the
idea of abstract data types relate to the OO notions of classes. Does it
make sense to have an interitence scheme for ADT's? Multiple Inheritance?
Abstract data types with inheritence will give you a strictly greater
expressiblity than classes, as one could futz with the methods on a
instance-by-instance basis, rather than having objects within a class
share the same method code. Is this a good way of thinking about OO
programming?


6) Separate Compilation and Modules. ML has the most advanced module
system of any language I've yet seen. What more can be done?


--

Return to the comp.compilers page.
Search the comp.compilers archives again.