I403%DMAFHT1.BITNET@CUNYVM.CUNY.EDU (Marc Wachowitz) (01/30/91)
Note: Since I have no curly braces here, I use "(." and ".)" instead.
1) Behaviour of NEW on lack of dynamic memory
The behaviour of NEW when there is insufficient memory available should
be specified. The SRC-Compiler (1.5) gives a runtime error.
I feel the following solution would be more practical:
INTERFACE New;
EXCEPTION NoMemory;
(* Exception raised by NEW when there is not enough memory *)
TYPE NoMemoryAction = (. ReturnNIL, RaiseException, AbortProgram .);
(* Action taken when NEW cannot perform its task:
ReturnNIL : Just return NIL
RaiseException: Raise NoMemory
AbortProgram : Abort program execution (current behaviour) *)
PROCEDURE GetNoMemoryAction() : NoMemoryAction;
PROCEDURE SetNoMemoryAction( action: NoMemoryAction );
(* Get/set bahaviour of NEW on lack of memory.
The default behaviour should be AbortProgram, since this does not
require the attention by "innocent" programns *)
END New;
This point might not be that important on machines with large virtual
memory, but I think it should be possible to implement the language
even on small systems (e.g. only a few MB non-virtual memory). It would
definitely not be acceptable for an application program to crash just
because it cannot allocate a buffer for a file to be opened :-(
2) UNTRACED types
It would be useful to allow the following, which is syntactically
illegal:
TYPE ObjectType = OBJECT (* ... *) END;
UntracedObjectType = UNTRACED ObjectType;
(The desired meaning should be obvious.) Currently one must repeat the
entire object type definition, preceded by UNTRACED. Though this is of
course no problem (given a reasonable editor), it seems error prone when
ObjectType comes from a different interface and changes are made in the
original type definition. Allowing the given form (and defining it as
shorthand for the now required expanded form) should not cause any
problems. Similar arguments apply to reference types and BRANDED types,
though the latter seems not that important.
3) Information on the Olivetti implementation
I would like to get information about the Olivetti implementation of
Modula-3: legal status, availability, required hard-/software, form of
compilation (e.g. Modula-3 to C like the DEC implementation ?) etc.chased@rbbb.Eng.Sun.COM (David Chase) (01/30/91)
I403%DMAFHT1.BITNET@CUNYVM.CUNY.EDU (Marc Wachowitz) writes: >2) UNTRACED types >It would be useful to allow the following, which is syntactically >illegal: > >TYPE ObjectType = OBJECT (* ... *) END; > UntracedObjectType = UNTRACED ObjectType; > >(The desired meaning should be obvious.) It's sort of obvious. Presumably, you would be rewriting all of the code (e.g., procedures bound to methods) referenced by this shorthand declaration? The old code almost certainly would not be correct because... It's unlikely that the old (traced) code would contain the bookkeeping necessary to manually maintain the storage. In my experience, interfaces in a garbage-collected world look "sloppy" to people not accustomed to working with a garbage collector (because the interfaces don't contain the extra gunk needed to manage resources between modules and users of the module). It is painful to rewrite code for untraced use, but if you really take advantage of the garbage collector in the traced world, then a port to the untraced world won't be trivial (and if you don't take advantage of the garbage collector, you're throwing away a useful tool). >3) Information on the Olivetti implementation >I would like to get information about the Olivetti implementation of >Modula-3: legal status, availability, required hard-/software, form of >compilation (e.g. Modula-3 to C like the DEC implementation ?) etc. Mick Jordan has the latest word on the legal status. I think it could become available if someone thought it was worth their time. It requires a C compiler, and has been ported to a number of 32-bit machines. The compiler generates (very ugly looking) C. The back-end, which generates that C, is no longer supported, unless someone else wishes to take on the job. It should be cleaned up and rewritten in Modula-3; the current code shows signs of haste, porting, and multiple language changes. I should know; I wrote it. David Chase Sun
mjordan@src.dec.com (Mick Jordan) (01/30/91)
The Olivetti implementation has been cleared for distribution with a simple copyright notice and no licence. However, there is no virtue in distributing the original system since it offers no advantages over the DEC SRC implementation at the level of the generated code. The value of the Olivetti system is the AST-based compiler front-end and other tools that are based on ASTs. This part of the system (somewhat enhanced from the original distribution) will be made available with the SRC distribution sometime during the first half of this year. You will need SRC Modula-3 V1.6 or later to compile it. Mick Jordan
gnelson (Greg Nelson) (02/06/91)
Marc Wachowitz suggests that "UNTRACED" should be a function from types to types; where "UNTRACED T" is like T, but not traced by the garbage collector. For example, TYPE T = OBJECT n: INTEGER END; UT = UNTRACED T; This would be useful if T was very long or defined in a different interface. Unfortunately, this doesn't work. Consider TYPE T = OBJECT METHODS p := P END; PROCEDURE P(self: T); TYPE U = UNTRACED T; What is the p method of U? It can't be P, since the type of the first argument is wrong. So it cannot be true that "UNTRACED T" is like T except that it is not traced by the garbage collector. When this simple definition failed, the committee gave up on the idea that UNTRACED was a function from types to types.