Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!elroy.jpl.nasa.gov!decwrl!pa.dec.com!src.dec.com!Marc Wachowitz <I403%DMAFHT1.BITNET@CUNYVM.CUNY.EDU>
From: I403%DMAFHT1.BITNET@CUNYVM.CUNY.EDU (Marc Wachowitz)
Newsgroups: comp.lang.modula3
Subject: language change wishes / Olivetti Modula-3 info needed
Message-ID: <9101291633.AA07621@decpa.pa.dec.com>
Date: 29 Jan 91 16:03:57 GMT
Lines: 52
To: m3

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.