MOSS@cs.umass.edu ("Eliot Moss, GRC A351B, x5-4206 12-Jul-1989 0839") (07/12/89)
In response to Tynor's recent message, my research group is currently developing a Modula 3 (not 2!) compiler based on gcc. This naturally involves a lot of front end work, but since the semantics of Modula 3 go rather beyond those of C, the back end will also need considerable work. Nature of Modula 3: Modula 3 cleans up and extends Modula 2 (and for that matter, Pascal). It has a Pascal-like syntax, and has the familiar data types of Pascal/Modula (integers, cardinals, reals, enumrations (including characters and booleans), sets (over discrete ranges as in Pascal), arrays, records, pointers). To these it adds: open arrays (whose size is determined when they are allocated (some restrictions about where they can be used so the language is reasonably implementable and efficient)) and objects (which have fields and methods). Object types can be extended with new fields and/or methods, giving a single inheritance scheme with dynamic lookup of methods (restrictions make dynamic calls only slightly more expensive than ordinary calls (an indirection and fixed index to obtain the address of the code to call)). There is also a way to make types opaque and thus encapsulated. Because the object facility removes the need for variant records (and indeed meets the need more elegantly), variant records do not appear in Modula 3 (a Pascal wart finally removed!). Other interesting features of the language include: separation of interfaces and implementations, separate (yet safe) compilation of modules, support for automatic storage management (garbage collection), lightweight processes (better than coroutines), and exception handling. My opinion is that with a few important additions the language would be an improvement over Ada. (It lacks pragmas, generics (or parameterized modules/types/whatever), or any sort of macro facility (some kind of "If I am on this system" feature is needed for portable systems programs).) A word about garbage collection: in addition to the automatically managed area, there is a separate "untraced" area to be used in allocate/free style. Various type restrictions keep the areas safely distinct (i.e., untraced objects (whose contents and interpretation are "unreliable" as far as the garbage collector is concerned) may not contain pointers to objects in the gc'ed area). Our objective: is to explore the addition to (relatively) transparent persistence to the language -- that is, direct access to a "heap" that is actually stored within a distributed collection of object servers, is shared, crash resilient, and outlives the execution of any single program. To do this, though we need a good implementation of the rest of the language, so a Modula 3 compiler will be a spin off result. Initial plans: our current goal is to have an interesting subset working all the way through the compiler within a couple of months. This would basically be whatever features the back end already knows how to deal with. The next phase will work on adding the features that require a lot more front end work (modules and separate compilation) and/or back end work (exceptions, gc, nested procedures, sets, objects, persistence). As/when we have something ready we will announce it through the appropriate Gnu bulletin board facilities. Prof. Eliot Moss Object Oriented Systems Laboratory Dept. of Comp. and Info. Sci. Univ. of Mass. Amherst, MA 01003 Moss@cs.umass.edu