Date: Mon, 03 Dec 90 13:24:56 PST From: Eric Muller Subject: November m3 mailing list archive available The mail archive for the messages sent to the m3 mailing list during the month of November is available via anonymous ftp from gatekeeper.dec.com, in pub/DEC/Modula-3/m3-mail.11-90.Z. Previous months can be found in the same directory. Eric Muller. ------------------------------------------------------------------------------ System Research Center - 130 Lytton Av. - Palo Alto, CA 94301 - (415) 853 2193 ------------------------------------------------------------------------------ Date: Thu, 6 Dec 90 18:46:05 PST From: David Goldberg Subject: Modula-3 activities I'm trying to determine how much momentum Modula-3 has going for it. Thus, if you are doing something with Modula-3 (such as using it in a real project, writing or book or article about it, creating some new M3 tools, or porting to a new machine), I'd appreciate it if you'd drop me a line. For example, here at Xerox PARC we are writing part of an experimental mail system in Modula-3, and we use our own version of m3ld that runs on Sun's and uses SunOS shared libraries. David Goldberg goldberg@parc.xerox.com ------------------------------------------------------------------------------ Date: 6 Dec 1990 2240-PST (Thursday) From: Subject: Re: Modula-3 activities if you are doing something with Modula-3 , I'd appreciate it if you'd drop me a line. I have an experimental ray tracing program written in Modula-3 (see "Rendering CSG models with a ZZ-buffer" by Salesin and Stolfi, in SIGGRAPH'90). Ther are about 10K lines of code in the rendering program proper, plus 10K lines in general-purpose libraries (linear algebra, image manipulation, interval arithmetic, S-expression parsing, etc.) Most of that code was converted semi-mechanically from Modula-2+, so it is not something that I dare to show in public. However, I am slowly cleaning up some of the libraries, and hopefully they will be included in future releases of the compiler. --Jorge Stolfi DEC Systems Research Center stolfi@src.dec.com ------------------------------------------------------------------------------ Date: Fri, 07 Dec 90 10:44 From: "H.Ludwig Hausen +49-2241142426" Subject: SRC Modula-3 syntax and semantics Hello, we would be very happy if some has syntax and semantics available on file and could e-mail them (or at least the syntax). Thanks a lot in advance, ease H. LUDWIG HAUSEN . Telephone +49-2241-14-2440 or -2426 GMD Schloss Birlinghoven . Telefax +49-2241-14-2618 or -2889 D-5205 Sankt Augustin 1 . Teletex 2627-224135=GMD VV GERMANY . Telex 8 89 469 gmd d . E-MAIL: HAUSEN@DBNGMD21.BITNET . . . . . . . . . . . . . . . . . or: HAUSEN@MVS.GMD.DBP.de . GMD Gesellschaft fuer Mathematik und Datenverarbeitung . German National Research Institute for Computer Science ------------------------------------------------------------------------------ Date: 7 Dec 90 19:27 +0100 From: "(Mats Weber)" Subject: RE: Modula-3 activities Hello, I am currently working on extensions to the Ada language and I find Modula-3 very interesting. I have studied the language from the viewpoint of a language designer and it has inspired me very much. I think the most important features it lacks are generics and overloading of procedures and operators. On the other hand, its very interesting features are the ability to implement multiple specifications in a single module (more generally revelations), the typecase and structural type equivalence (I am not saying that I encourage structural equivalence, but it is very interesting to see it in an actual language design). I think it is very good that people work on languages like Modula-3 instead of falling into the C/C++ black hole. I was very impressed by the ease of installation of the compiler, that I installed on a machine on which it was not even known to work on. Mats Weber Swiss Federal Institute of Technology EPFL DI LGL 1015 Lausanne Switzerland E-mail : madmats@elcgl.epfl.ch phone : +41 21 693 52 92 fax : +41 21 693 39 09 ------------------------------------------------------------------------------ Date: Fri, 7 Dec 90 15:53:37 EST From: Norman Ramsey Subject: using typecodes for subtyping Is there a way to implement ISTYPE using type codes? I want to implement a function PROCEDURE Check(r:REFANY; T:TYPE) = BEGIN IF NOT ISTYPE(r,T) THEN RAISE Error(Typecheck) END; END Check; but of course I can't actually pass a type to a function, only a type code. Any ideas? Norman Ramsey ------------------------------------------------------------------------------ Date: Fri, 07 Dec 90 15:11:57 PST From: Eric Muller Subject: Re: using typecodes for subtyping > Is there a way to implement ISTYPE using type codes? I want to implement > a function > PROCEDURE Check(r:REFANY; T:TYPE) = > BEGIN > IF NOT ISTYPE(r,T) THEN RAISE Error(Typecheck) END; > END Check; > but of course I can't actually pass a type to a function, only a type code. > Any ideas? 1.6 will introduce a bunch of interfaces to the runtime system. Although these (or similar interfaces) are not part of the language definition, they are likely to be present, at least in part, in every implementation, and are needed for things like pickles. The RTType interface provides: TYPE Typecode = CARDINAL; (* Each object and traced reference type is assigned a unique typecode. A typecode is "proper" if it lies in the range [0..MaxTypecode()]. The proper typecodes include all those that correspond to types. Other typecodes are used internally by the runtime system and garbage collector. *) CONST NoSuchType : Typecode = LAST (Typecode); (* a reserved typecode that represents unknown types *) PROCEDURE MaxTypeCode (): Typecode; (* returns the largest proper typecode *) PROCEDURE IsSubtype (tc1, tc2: Typecode): BOOLEAN; (* returns TRUE iff the type corresponding to tc1 is a subtype of the type corresponding to tc2. It is a checked runtime error to pass improper typecodes. *) ------------------------------------------------------------------------------ Date: Fri, 7 Dec 90 16:40:18 PST From: chased@Eng.Sun.COM (David Chase) Subject: Re: using typecodes for subtyping You can't use typecodes for ISTYPE portably, no. At Olivetti "ISTYPE" had secret knowledge about types. There's some interesting ways to implement ISTYPE, NARROW, and TYPECASE if you have the freedom to tinker with the implementation. It goes like this: Build a subtype tree, with REFANY at the root, and "A parent of B" equivalent to "B <: A, B # A, there exists no X satisfying ( B <: X, X <: A, X # B, X # A) " (i.e., B is a direct subtype of A). Pick a left-to-right ordering for the children of each node in the tree, and stick to it. Walk the tree from left-to-right, and annotate each node with pre-visit and post-visit numbers. Thus, PRE(REFANY) = 1 and POST(REFANY) = |reftypes|. Given two types S (subtype) and R (root), S <: R if and only if PRE(S) >= PRE(R) AND POST(S) <= POST(R). This gives you a constant-time narrow operation. Using this same numbering, TYPECASE exp OF END can be implemented so that it runs in O(log N) time with O(N) extra storage, after O(N log N) time spent pre-processing. Details later -- I tried writing it out once in e-mail, and it turned into a total botch. David Chase ------------------------------------------------------------------------------ Date: Fri, 07 Dec 90 17:56:38 PST From: Eric Muller Subject: Re: using typecodes for subtyping > There's some interesting ways to implement ISTYPE, > NARROW, and TYPECASE if you have the freedom to tinker > with the implementation. > > This gives you a constant-time narrow operation. This the way it is implemented in the development version of SRC Modula-3. On top of that, POST (R) is the typecode of R. Of course, the case of NULL has to be handled separately (who said Modula-3 does not have multiple inheritance ?) Eric Muller. ------------------------------------------------------------------------------ System Research Center - 130 Lytton Av. - Palo Alto, CA 94301 - (415) 853 2193 ------------------------------------------------------------------------------ Date: Tue, 11 Dec 90 21:55:14 PST From: Eric Muller Subject: Re: m3 functionality > It would be nice if m3 included a -S option to produce assembly code instead > of an object file. Done for the next release; the next extensions are .is, .ms, and .s, similar to .ic, .mc, .c. Eric Muller. ------------------------------------------------------------------------------ System Research Center - 130 Lytton Av. - Palo Alto, CA 94301 - (415) 853 2193 ------------------------------------------------------------------------------ Date: 12 Dec 90 17:25 +0100 From: "(Mats Weber)" Subject: Modula-3 1.4 still available ? Hello, I used to run Modula-3 1.4 on a Sun-3 with very few problems. I tried to install release 1.5 but that didn't work (I read the messages on the mailing list and don't want to install the compiler by hand). Does anyone still have the release 1.4 distribution ? thank you Mats Weber Swiss Federal Institute of Technology EPFL DI LGL 1015 Lausanne Switzerland E-mail : madmats@elcgl.epfl.ch phone : +41 21 693 52 92 fax : +41 21 693 39 09 ------------------------------------------------------------------------------ Date: Wed, 12 Dec 90 15:26:30 PST From: David Goldberg Subject: anonymous enums A while back in the discussion of anonymous enums, Greg Nelson suggested writing VAR enum: {a,b,c,d,e}; enum := {a,b,c,d,e}.a (* is this legal? *) However, the grammar doesn't seem to allow this. Expr = E8 { Selector} Selector = "." Ident E8 = Constructor Constructor = Type "{" ..... Since Type can't be empty, it would seem that the program fragment above is illegal (the SRC compiler accepts it, the Olivetti compiler rejects it). Who's right? David Goldberg goldberg@parc.xerox.com ------------------------------------------------------------------------------ Date: Thu, 13 Dec 90 09:42:47 EST From: hudson@yough.ucc.umass.edu (Rick Hudson) Subject: anonymous enums David Goldberg states: VAR enum: {a,b,c,d,e}; enum := {a,b,c,d,e}.a (* is this legal? *) However, the grammar doesn't seem to allow this. Expr = E8 { Selector} Selector = "." Ident E8 = Constructor Constructor = Type "{" ..... As David noted the grammer outlaws this. One should also note that constructors are allowed only on sets, records, and arrays, not on enumerations. - Rick ------------------------------------------------------------------------------ Date: Fri, 14 Dec 90 09:30:56 +0100 From: buschman@tubsibr.uucp (Andreas Buschmann) Subject: m3 + gnu C compiler Hallo, I have build the M3 compiler with option -O, but on a Sun3. I have run the test files, and got no unexpected errors, so the compiler got installed. I havn't compiled any big programs, but am using it as a reference compiler, to see how something works in this implementation. (Not everything is fully described in the report) Andreas ------------------------------------------------------------------------------ Date: Fri, 14 Dec 90 09:36:56 +0100 From: buschman@tubsibr.uucp (Andreas Buschmann) Subject: Modula-3 1.4 still available ? Hallo, Ich hab 1.5 bei uns auf der Sun3 installiert, und irgendwo ein Band mit den geaenderten files. Geht aber nicht automatisch, immer wieder von Hand eingreifen. Ausserdem braucht man entweder eine Maschine, die unterstuetzt wird, oder der gnu C compiler muss gepatcht werden (Alignment fuer alles in Strukturen auf 32 Bit). Tschuess Andreas ------------------------------------------------------------------------------ Date: Tue, 18 Dec 90 18:15:00 +0100 From: buschman@tubsibr.uucp (Andreas Buschmann) Subject: Modula-3 report: recursive declarations Hi! About recursive declarations: Report, page 32, last example of illegal declarations: VAR v := P(); PROCEDURE P() : ARRAY [0..NUMBER(v)] OF INTEGER I understand that it is impossible to determine the number of elements of `v' from this, but I don't see hob this (beeing an illegal recursive declaration) is covered by the report. Recursive declarations A constant, type, or procedure declaration N = E, a variable declaration N : E, an exception declaration N(E), or a revelation N = E is recursive if N occeurs in any partial expansion of E. A variable declaration N := I where the type is omitted is recursive if N occeurs in any partial expansion of the type E of I. Such declarations are allowed if every occurrence of N in any partial expansion of E is (1) within some occurence of the type constructor REF or PROCEDURE, (2) within a field or method type of the type constructor OBJECT, or (3) within a procedure body. Tschuess Andreas p.s. is TYPE strange = REF strange; a legal declaration? With this definition, it should be. Is it? ------------------------------------------------------------------------------ Date: Sun, 16 Dec 90 17:17:34 +0100 From: buschman@tubsibr.uucp (Andreas Buschmann) Subject: Modula-3 syntax and semantics for constants Hello! About constant declarations and constant expressions: How are constant expressions to be handled, what can be seen in a constant declaration. As an example let's have the following program MODULE Main; IMPORT Stdio, Wr, Fmt; CONST i = j; CONST j = 10; BEGIN Wr.PutText (Stdio.stdout, Fmt.Int (i) & "\n"); END Main. Compiled with SRC Modula3 the program prints 10. In the report (21.10.89) it is said: "Expressions whose values can be determined statically are called constant expressions; ..." (p.2). But what is really allowed in constant expressions? In the report at least procedural operators are used in examples. What else would be ok? VAR a : INTEGER := 10; CONST b : INTEGER = a; is rejected by the compiler, but the value of b could be determined statically to be 10. Also PROCEDURE p (x : INTEGER) : INTEGER = BEGIN RETURN x + 1; END p; CONST b : INTEGER = p (1); is rejected. A related question: what can be used in a constant expression? I need some enlightment. Tschuess Andreas p.s. I don't need to know how one or more compiler may handle this stuff, but how it is intended to be. ------------------------------------------------------------------------------ Date: 19 Dec 1990 1606-PST (Wednesday) From: Subject: Re: Modula-3 report: recursive declarations Andreas Buschmann asks several questions. (1) How does the wording of the Modula-3 report prohibit the declaration: VAR v := P(); PROCEDURE P() : ARRAY [0..NUMBER(v)] OF INTEGER The reason is that the words "a variable declaration N := I where the type is omitted is recursive if N occurs in any partial expansion of the type E of I" apply to the declaration of v, since the type of P() is "ARRAY [0..NUMBER(v)]", which contains v. Since the occurrence of v is not within REF or PROCEDURE or withing a field or method type of OBJECT or within a procedure body, the recusion is illegal. (2) Is TYPE T = REF T legal. Yes, it is legal. It is pretty pointless, but it would be even more pointless to prohibit it. (3) What is the exact definition of a constant expression? The answer is at the end of the Expressions section, where there is an explicit list of what operations are forbidden in constant expressions. ------------------------------------------------------------------------------ Date: 19 Dec 1990 1646-PST (Wednesday) From: Subject: Twelve changes to Modula-3 Twelve Changes to Modula-3 19 Dec 90 "Systems Programming with Modula-3" will be appearing in a few months at a bookstore near you. To prepare for this gala event, the Modula-3 committee has made twelve final adjustments to the language definition, described in this message. On behalf of the Modula-3 committee I would like to thank Bob Ayers, Michel Gangnet, David Goldberg, Sam Harbison, Christian Jacobi, Nick Maclaren, Eric Muller, and Thomas Roemke for their helpful comments on these changes. ---Greg Nelson Contents Section 1 List of changes Section 2 Rationale Section 3 Details of generics Section 4 Details of floating-point Section 1. List of changes 1.1 The language will be extended to support generic interfaces and modules. The detailed semantics of generics are in Section 3, below. 1.2 In addition to REAL and LONGREAL the language will support the new floating point type EXTENDED. New required interfaces will allow clients to use IEEE floating point if the implementation supports it. The behavior of the interfaces is also defined for non-IEEE implementations. Listing of these interfaces, and other details, are in Section 4, below. 1.3 The default raises clause will be the empty set instead of the set of all exceptions. RAISES ANY will be used to indicate that a procedure can raise any exception. 1.4 The sentence: The declaration of an object type has the form TYPE T = ST OBJECT FieldList METHODS MethodList END where ST is an optional supertype, FieldList is a list of field declarations, exactly as in a record type, and MethodList is a list of "method declarations" and "method overrides". will be changed to The declaration of an object type has the form TYPE T = ST OBJECT Fields METHODS Methods OVERRIDES Overrides END where ST is an optional supertype, Fields is a list of field declarations, exactly as in a record type, Methods is a list of "method declarations" and Overrides is a list of "method overrides". The syntax for individual method declarations and individual method overrides remains the same. 1.5 The semantics of method overrides supplied at NEW time will be defined by the following rewriting: NEW( T, m := P ) is sugar for NEW( T OBJECT OVERRIDES m := P END ). As a consequence, the method overrides are restricted to procedure constants, and the methods of an object are determined by its allocated type. It is no longer necessary to refer to "T's default m method", you can just say "T's m method". 1.6 On page 48, the last sentence in the section "Constant Expressions" will be changed from "All literals are legal in constant expressions; procedure constants are not" to "Literals and top-level procedure constants are legal in constant expressions" Procedure application remains illegal in constant expressions, except for the required procedures in the Word interface. 1.7 The word "not" will be removed from the sentence "T.m is not a procedure constant" on page 39, and the grammar will be changed to allow the syntax T.m as a method default. 1.8 The prohibition against NEWing an opaque object type will be removed. The procedures Thread.NewMutex and Thread.NewCondition will be removed from the Thread interface and replaced by comments to the effect that a newly-allocated Mutex is in the unlocked state and a newly-allocated Condition has no threads waiting on it. 1.9 The following sentence will be added to the "revelations" section: In any scope, the revealed supertypes of an opaque type must be totally ordered by the subtype relation. For example, in a scope where it is revealed that T <: S1 and that T <: S2, it must also be revealed either that S1 <: S2 or that S2 <: S1. 1.10 The sentence The pragma <*EXTERNAL L*> precedes a procedure declaration to indicate that the procedure is implemented in the language L, or precedes an interface to indicate that the entire interface is implemented in the language L. will be changed to The pragma <* EXTERNAL N:L *> precedes an interface or a declaration in an interface to indicate that the entity it precedes is implemented by the language L, where it has the name N. If ":L" is omitted, then the implementation's default external language is assumed. If "N" is omitted, then the external name is determined from the Modula-3 name in some implementation-dependent way. 1.11 The result type of the built-in function TYPECODE will be changed from INTEGER to CARDINAL. 1.12 Changes to the syntax of text, character, and integer literals, as follows: On page 59, "Token Productions", the lines CharLiteral = "'" ( PrintingChar | Escape ) "'" TextLiteral = DQUOTE { PrintingChar | Escape } DQUOTE will be changed to CharLiteral = "'" ( PrintingChar | Escape | DQUOTE ) "'" TextLiteral = DQUOTE { PrintingChar | Escape | "'" } DQUOTE The effect is to allow "Don't" instead of "Don\'t" and '"' instead of '\"'. In the section on integer literals, we will add the words If no base is present, the value of the literal must be at most LAST(INTEGER); if an explicit base is present, the value of the literal must be less than 2^Word.Size, and its interpretation as a signed integer is implementation-dependent. For example, on a sixteen-bit two's complement machine, 16_ffff and -1 represent the same value. Section 2. Rationale 2.1 In regard to generics: several programmers have invented ad-hoc schemes for working around the absence of generics. We have found a simple design that seems to be in the Modula spirit, is easy to implement, and has essentially no impact on the rest of the language. 2.2 In regard to floating-point revisions: Jorge Stolfi and Stephen Harrison have reported on their use of Modula-3 for floating-point graphics computations, and David Goldberg has given us a critique of Modula-3 from the point of view of a numerical analyst. We have used this feedback to try to make Modula-3 better for floating-point computations, an issue that was not taken too seriously in the original design. 2.3 In regard to the default raises clause, RAISES {} is far more frequent than RAISES ANY, so it should be the default. This change is not backward-compatible: conversion will require Finding occurrences of RAISES {} and deleting them. This is easy to do, and is not essential, since RAISES {} is still meaningful and legal, although now redundant. Finding procedures without raises clauses and adding RAISES ANY (or, more likely, noticing that they were incorrectly annotated and that the correct clause is RAISES {} in which case they can be left alone). Since RAISES ANY is rare, this change should be necessary in very few places, e.g., for mapping functions. 2.4 In regard to the explicit OVERRIDES keyword: several programmers have accidentally declared a new method when they meant to override an existing one, strongly suggesting that the current syntax does not distinguish between methods and overrides strongly enough. This change is not backwards compatible, but existing programs can be converted easily, by sorting the method declarations in front of the method overrides and adding the word "OVERRIDES" between the two groups. 2.5 In regard to defining the semantics of method overriding at NEW time by syntactic sugar: the advantage of this change is that the method suite becomes a constant function of the type. That is, we no longer have to talk about "T's default m method", we can just say "T's m method". For example, this is convenient for the implementation of type-safe persistent storage (pickles), which can recreate an object's method suite trivially, by asking the runtime system for the method suite associated with the type. (This is in fact what is done by both the Olivetti and the SRC pickles packages: adopting the rewriting semantics above will make both packages correct.) The obvious cost of the change is that a procedure variable can no longer be used as a method override. However, no programs are known to use this facility. Furthermore, a strong argument can be made that this facility is not useful. For example, consider the following program, which does use a procedure variable as a method override: PROCEDURE New( h: PROCEDURE(t: Table.T, k: Key.T): INTEGER) : Table.T = BEGIN ... NEW(Table.T, hashMethod := h) END New. This is poor code: it would be better to make the hash method a procedure-valued field in the table, since the usual argument for making something a method rather than a procedure data field doesn't apply here: New cannot be used to construct a subtype of Table.T with a hash method specific to that subtype, because New's signature requires that h accept any Table.T as an argument. Consequently there is no flexibility gained by using a method. Furthermore, if the hash procedure is stored in the data part of the object, hash tables with different hash procedures can share method suites, and thus save space. This change is not strictly backwards-compatible, but as no programs are known to override methods at NEW time with non-constant procedures, it is expected to be backwards compatible in practice. 2.6 In regard to the change that allows procedure constants in constant expressions: this allows procedure constants as default parameters, which is a convenience. And it does not seem to be difficult for implementations, or any less principled to allow procedure constants in constant expressions than to allow TEXT literals. 2.7 In regard to allowing "T.m" as a procedure constant: you could already write T.m to denote the m method of type T, but because this expression was not considered a procedure constant, it couldn't be used as a method default. That usually meant that an interface exporting T would also have to export each of T's methods by name, since somebody defining a related class might reuse some of the methods. Thus this change allows less cluttered interfaces. Allowing T.m as a procedure constant raises the following question: Are U and V the same after TYPE T = OBJECT METHODS m() := P END TYPE U = T OBJECT METHODS m := P END; V = T OBJECT METHODS m := T.m END; Answering "yes" would be hard on the implementation, since although in this case the identity of T.m with P is manifest, this would not be true in general. So we will define U and V to be different, on the grounds that the expanded form of U contains "P" where the expanded form of V contains "(expanded form of T).m". With respect to structural equivalence, the implementation should treat the occurrence of "T.m" the same as it would treat a record field "m: T". 2.8 In regard to NEW(T) for opaque types T: If an opaque type requires initializations over and above what can be done with default field values, then the implementor of the type must provide a procedure for doing the initialization. He might provide a New procedure that allocates, initializes, and returns a value of the type, but this New procedure couldn't be used by anybody implementing a subtypes of the opaque type, since it allocates the wrong type of object. Thus when you declare an opaque type that is intended to be subclassed, you owe it to your clients to provide an init routine that takes an object that has already been allocated, or to comment that no initialization in necessary beyond what is automatically provided by default field values. In either case, the effect of NEWing the opaque type will be well-specified in the interface, and the old rule against it is revealed as an attempt to legislate style. In fact, the old rule interfered with a style that seems attractive: for each object type T, define a method T.init that initializes the object and returns it. Then the call NEW(T).init(args) allocates, initializes, and returns an object of type T. If T is an subtype of some type S, and the implementer of S uses the same style, then within T.init(self, ...) there will be a call of the form EVAL S.init(self, ...) to initialize the supertype part of the object. Note that this style involves NEWing the opaque object type T. 2.9 In regard to the requirement that the revealed supertypes of an opaque type must be totally ordered by the subtype relation: this rule was present in the original version of the report, and somehow got deleted from the revised version, probably by an editing error, without the committee ever deliberately rescinding it. The advantage of the rule is that the information about an opaque type in a scope is determined by a single type, its "<:-least upper bound", rather than by a set of types. This simplifies the compiler; in fact, both the SRC and Olivetti compilers depend on this rule. Theoretically this is not a backwards-compatible change, but since it is bringing the language into conformance with the two compilers that are in use, obviously it won't require conversion by clients. 2.10 In regard to the EXTERNAL pragma: in producing the Modula-3 interfaces to the X library the need for renaming as part of the external declaration was acute. 2.11 Changing the result type of TYPECODE to CARDINAL is no burden on the implementation, and the guarantee that negative integers cannot be confused with typecodes is often convenient. 2.12 Allowing "Don't" instead of "Don\'t" makes programs more readable. Allowing integer literals whose high-order bit is set is useful both in graphics applications, where masks are being constructed, and in low-level systems code, where integers are being loopholed into addresses that may be in the high half of memory. Section 3. Details of generics Before describing the generics proposal proper, we describe two minor changes that are associated with generics: allowing renamed imports, and allowing text constants to be brands. 3.1 Allowing renamed imports. IMPORT I AS N means "import the interface I and give it the local name N". The name I is not introduced into the importing scope. The imported interfaces are all looked up before any of the local names are bound; thus IMPORT I AS J, J AS I; imports the two interfaces I and J, perversely giving them the local names J and I respectively. It is illegal to use the same local name twice: IMPORT J AS I, K AS I; is a static error, and would be even if J and K were the same. The old form IMPORT I is short for IMPORT I AS I. FROM I IMPORT X introduces X as the local name for the entity named X in the interface I. A local binding for I takes precedence over a global binding for I. For example, IMPORT I AS J, J AS I; FROM I IMPORT X; simultaneously introduces local names I, J, and X for the entities whose global names are J, I, and J.X, respectively. 3.2 Allowing text constants as brands. The words from the section on Reference types: ... can optionally be preceded by "BRANDED b", where b is a text literal called the "brand". will be changed to ... can optionally be preceded by "BRANDED b", where b is a text constant called the "brand". This allows generic modules to use an imported text constant as the brand. 3.3 Generics proper. In a generic interface or module, some of the imported or exported interface names are treated as formal parameters, to be bound to actual interfaces when the generic is instantiated. A generic interface has the form GENERIC INTERFACE G(F_1, ..., F_n); Body END G. where G is an identifier that names the generic, F_1, ..., F_n is a list of identifiers, called the formal imports of G, and Body is a sequence of imports followed by a sequence of declarations, exactly as in a non-generic interface. An instance of G has the form INTERFACE I = G(A_1, ..., A_n) END I. where I is the name of the instance and A_1, ..., A_n is a list of "actual" interfaces to which the formal imports of G are bound. The semantics are defined precisely by the following rewriting: INTERFACE I; IMPORT A_1 AS F_1, ..., A_n AS F_n; Body END I. A generic module has the form GENERIC MODULE G(F_1, ..., F_n); Body END G. where G is an identifier that names the generic, F_1, ..., F_n is a list of identifiers, called the formal imports of G, and Body is a sequence of imports followed by a block, exactly as in a non-generic module. An instance of a G has the form MODULE I EXPORTS E = G(A_1, ..., A_n) END I. where I is the name of the instance, E is a list of interfaces exported by I, and A_1, ..., A_n is a list of actual interfaces to which the formal imports of G are bound. "EXPORTS E" can be omitted, in which case it defaults to "EXPORTS I". The semantics are defined precisely by the following rewriting: MODULE I EXPORTS E; IMPORT A_1 AS F_1, ..., A_n AS F_n; Body END I. Notice that the generic module itself has no exports or UNSAFE indication; they can be supplied only when it is instantiated. For example, consider GENERIC INTERFACE Dynarray(Elem); (* Extendible arrays of Elem.T, which can be any type except an open array type. *) TYPE T = REF ARRAY OF Elem.T; PROCEDURE Extend(VAR v: T); (* Extend v's length, preserving its current contents. *) END Dynarray. GENERIC MODULE Dynarray(Elem); PROCEDURE Extend(VAR v: T) = VAR w: T; BEGIN IF v = NIL OR NUMBER(v^) = 0 THEN w := NEW(T, 5) ELSE w := NEW(T, NUMBER(v^) * 2); FOR i := 0 TO LAST(v^) DO w[i] := v[i] END END; v := w END Extend; END Dynarray. To instantiate these generics to produce dynamic arrays of integers: INTERFACE Integer; TYPE T = INTEGER END Integer. INTERFACE IntArray = Dynarray(Integer) END IntArray. MODULE IntArray = Dynarray(Integer) END IntArray. Implementations are not expected to share code between different instances of a generic module, since this will not be possible in general. There is no typechecking associated with generics: implementations are expected to expand the instantiation and typecheck the result. For example, if one made the following mistake: INTERFACE String; TYPE T = ARRAY OF CHAR END String. INTERFACE StringArray = Dynarray(String) END StringArray. MODULE StringArray = Dynarray(String) END StringArray. everything would go well until the last line, when the compiler would attempt to compile a version of Dynarray in which the element type was an open array. It would then complain that the "NEW" call in Extend does not have enough parameters. Section 4. Details of floating-point The new built-in floating-point type EXTENDED will be added. The character "x" will be used in place of "d" or "e" to denote EXTENDED constants. FIRST(T) and LAST(T) will be defined for the floating point types. In IEEE implementations, these are minus and plus infinity, respectively. MOD will be extended to floating point types by the rule x MOD y = x - y * FLOOR(x / y). Implementations may compute this as a Modula-3 expression, or by a method that avoids overflow if x is much greater than y. All the built-in operations that take REAL and LONGREAL will take EXTENDED arguments as well. (To make the language specification shorter and more readable, we will use the type class "Float" to represent any floating point type. For example: + (x,y: INTEGER) : INTEGER (x,y: Float) : Float The sum of x and y. If x and y are floats, they must have the same type, and the result is the same type as both. LONGFLOAT will be removed and FLOAT will be changed to: FLOAT(x: INTEGER; T: Type := REAL): T FLOAT(x: Float; T: Type := REAL): T Convert x to have type T, which must be a floating-point type. Thus FLOAT(x) means the same thing it means today; FLOAT(x, LONGREAL) means what LONGFLOAT(x) means today. We will add to the expressions chapter a note that the rounding behavior of floating-point operations is specified in the required interface FloatMode, as well as a note that implementations are only allowed to rearrange computations if the rearrangement has no effect on the semantics; e.g., (x+y)+z should not in general be changed to x+(y+z), since addition is not associative. The arithmetic operators are left-associative; thus x+y+z is short for (x+y)+z. The behavior of overflows and other exceptional numeric conditions will also be determined by the interface FloatMode. Finally, we will change the definition of the built-in equality operation on floating-point numbers so that it is implementation-dependent, adding a note that in IEEE implementations, +0 equals -0 and Nan does not equal Nan. Modula-3 systems will be required to implement the following interfaces related to floating-point numbers. The interfaces give clients access to the power of IEEE floating point if the implementation has it, but can also be implemented with other floating point systems. For definitions of the terms used in the comments, see the IEEE Standard for Binary Floating-Point Arithmetic (ANSI/IEEE Std. 754-1985). INTERFACE Real; TYPE T = REAL; CONST Base: INTEGER = ...; (* The radix of the floating-point representation for T *) Precision: INTEGER; (* The number of digits of precision in the given Base for T. *) MaxFinite: T = ...; (* The maximum finite value in T. For non-IEEE implementations, this is the same as LAST(T). *) MinPos: T = ...; (* The minimum positive value in T. *) MinPosNormal: T = ...; (* The minimum positive "normal" value in T; differs from MinPos only for implementations with denormalized numbers. *) END Real. INTERFACE LongReal; TYPE T = LONGREAL; CONST Base: INTEGER = ...; Precision: INTEGER = ...; MaxFinite: T = ...; MinPos: T = ...; MinPosNormal: T = ...; (* Like the corresponding constants in Real. *) END LongReal. INTERFACE Extended; TYPE T = EXTENDED; CONST Base: INTEGER = ...; Precision: INTEGER = ...; MaxFinite: T = ...; MinPos: T = ...; MinPosNormal: T = ...; (* Like the corresponding constants in Real. *) END Extended. INTERFACE RealFloat = Float(Real) END RealFloat. INTERFACE LongFloat = Float(LongReal) END LongFloat. INTERFACE ExtendedFloat = Float(Extended) END ExtendedFloat. GENERIC INTERFACE Float(Real); TYPE T = Real.T; (* The purpose of the interface is to provide access to the floating-point operations required or recommended by the IEEE floating-point standard. Consult the standard for the precise specifications of the procedures, including when their arguments are NaNs, infinities, and signed zeros, and including what exceptions they can raise. Our comments specify their effect when the arguments are ordinary numbers and no exception is raised. Implementations on non-IEEE machines that have values similar to NaNs and infinities should explain how those values behave for IsNaN, Finite, etc. in an implementation guide *) PROCEDURE Scalb(x: T; n: INTEGER): T; (* Return x * (2 ** n). *) PROCEDURE Logb(x: T): T; (* Return the exponent of x. More precisely, return the unique n such that ABS(x) / Base ** n is in the range [1..Base-1], unless x is denormalized, in which case return MinExp-1, where MinExp is the minimum exponent value for T. *) PROCEDURE ILogb(x: T): INTEGER; (* Like Logb, but returns an integer, never raises an exception, and always returns the n such that ABS(x)/Base**N is in [1..Base-1] even for denormalized numbers. *) PROCEDURE NextAfter(x, y: T): T; (* Return the next representable neighbor of x in the direction towards y. If x = y, return x *) PROCEDURE CopySign(x, y: T): T; (* Return x with the sign of y. *) PROCEDURE Finite(x: T): BOOLEAN; (* Return TRUE if x is strictly between -infinity and +infinity. This always returns TRUE on non-IEEE machines. *) PROCEDURE IsNaN(x: T): BOOLEAN; (* Return FALSE if x represents a numerical (possibly infinite) value, and TRUE if x does not represent a numerical value. For example, on IEEE implementations, returns TRUE if x is a NaN, FALSE otherwise; on Vaxes, returns TRUE of x is a reserved operand, FALSE otherwise. *) PROCEDURE Sign(x: T): [0..1]; (* Return the sign bit x. For non-IEEE implementations, this is the same as ORD(x >= 0); for IEEE implementations, Sign(-0) = 1, Sign(+0) = 0. *) PROCEDURE Differs(x, y: T): BOOLEAN; (* RETURN (x < y OR y < x). Thus, for IEEE implementations, Differs(NaN, x) is always FALSE; for non-IEEE implementations, Differs(x,y) is the same as x # y. *) PROCEDURE Unordered(x, y: T): BOOLEAN; (* Return NOT (x <= y OR y <= x). For non-IEEE implementations, this always returns FALSE. *) PROCEDURE Sqrt(x: T): T; (* Return the square root of T. Must be correctly rounded if FloatMode.IEEE is TRUE. *) TYPE IEEEClass = {SignalingNaN, QuietNaN, Infinity, Normal, Denormal, Zero}; PROCEDURE Class(x: T): IEEEClass; (* Return the IEEE number class containing x. On non-IEEE systems, the result will be Normal or Zero. *) END Float. INTERFACE FloatMode; (* This interface allows you to test the behavior of rounding and of numerical exceptions. On some implementations it also allows you to change the behavior, on a per-thread basis. *) CONST IEEE: BOOLEAN = ...; (* TRUE for full IEEE implementations. *) EXCEPTION Failure; TYPE RoundingMode = {MinusInfinity, PlusInfinity, Zero, Nearest, Vax, IBM370, Other}; (* Mode for rounding operations. The first four are the IEEE modes. *) CONST RoundDefault: RoundingMode = ...; (* Implementation-dependent: the default mode for rounding arithmetic operations, used by a newly forked thread. This also specifies the behavior of the ROUND operation in half-way cases. *) PROCEDURE SetRounding(md: RoundingMode) RAISES {Failure}; (* Change the rounding mode for the calling thread to md, or raise the exception if this cannot be done. This affects the implicit rounding in floating-point operations. Generally this is possible only on IEEE implementations and only if md is an IEEE mode. *) PROCEDURE GetRounding(): RoundingMode; (* Return the rounding mode for the calling thread. *) TYPE Flag = {Invalid, Inexact, Overflow, Underflow, DivByZero, IntOverflow, IntDivByZero}; (* Associated with each thread is a set of boolean status flag recording whether the condition represented by the flag has occurred in the thread since the flag has last been reset. The meaning of the first five flags is defined precisely in the IEEE floating point standard; roughly they mean: Invalid = invalid argument to an operation. Inexact = an operation produced an inexact result. Overflow = a floating-point operation produced a result whose absolute value is too large to be represented. Underflow = a floating-point operation produced a result whose absolute value is too small to be represented. DivByZero = floating-point division by zero. The meaning of the last two flags is: IntOverflow = an integer operation produced a result whose absolute value is too large to be represented. IntDivByZero = integer DIV or MOD by zero. *) CONST NoFlags = SET OF Flags {}; PROCEDURE GetFlags(): SET OF Flag; (* Return the set of flags for the current thread *) PROCEDURE SetFlags(s: SET OF Flag): SET OF Flag; (* Set the flags for the current thread to s, and return their previous values. *) PROCEDURE ClearFlag(f: Flag); (* Turn off the flag f for the current thread. *) EXCEPTION Trap(Flag); TYPE Behavior = {Trap, SetFlag, Ignore}; (* The behavior of an operation that causes one of the flag conditions is either Ignore = return some result and do nothing. SetFlag = return some result and set the condition flag. For IEEE implementations, the result will be what the standard requires. Trap = possibly set the condition flag; in any case raise the Trap exception with the appropriate flag as the argument. *) PROCEDURE SetBehavior(f: Flag; b: Behavior) RAISES {Failure}; (* Set the behavior of the current thread for the flag f to be b, or raise Failure if this cannot be done. *) PROCEDURE GetBehavior(f: Flag): Behavior; (* Return the behavior of the current thread for the flag f. *) END FloatMode. ------------------------------------------------------------------------------ Date: Tue, 18 Dec 90 23:45:27 PST From: muller@src.dec.com (Eric Muller) Subject: Welcome to comp.lang.modula3 Here is a reminder about the charter of this newsgroup. NAME: comp.lang.modula3 STATUS: unmoderated CHARTER: Modula-3 is a new programming language (see below for a short description). This newsgroup would serve to discuss all aspects of the language, such as use of language, good style, availability of implementations, implementation techniques. SHORT DESCRIPTION OF MODULA-3: Modula-3 is a new programming language. The goals of its design are best encapsulated in the preface to the "The Modula-3 Report (Revised)", (L. Cardelli, J. Dohnaue, L. Glassman, M. Jordan, B. Kalsow, G. Nelson, DEC Systems Research Center, Palo Alto, CA and Olivetti Research Center, Menlo Park, CA, Nov 89.): The goal of Modula-3 is to be as simple and safe as it can be while meeting the needs of modern systems programmers. Instead of exploring new features, we studied the features of the Modula family of languages that have proven themselves in practice and tried to simplify them into a harmonious language. We found that most of the successful features were aimed at one of two main goals: greater robustness, and a simpler, more systematic type system. Modula-3 descends from Mesa, Modula-2, Cedar, and Modula-2+. It also resembles its cousins Object Pascal, Oberon, and Euclid. Modula-3 retains one of Modula-2's most successful features, the provision for explicit interfaces between modules. It adds objects and classes, exception handling, garbage collection, lightweight processes (or threads), and the isolation of unsafe features. Eric Muller. ------------------------------------------------------------------------------ System Research Center - 130 Lytton Av. - Palo Alto, CA 94301 - (415) 853 2193 ------------------------------------------------------------------------------ Date: Tue, 18 Dec 90 23:46:39 PST From: muller@src.dec.com (Eric Muller) Subject: m3@src.dec.com mailing list Since the first public release of SRC Modula-3, we have maintained a mailing list (m3@src.dec.com) to connect the people interested by SRC Modula-3 and more generally by Modula-3. The newsgroup comp.lang.modula3 will provide an additional distribution mechanism. We will install a relay between this newsgroup and the list. Maintaining the m3 mailing list is a time-consuming task. Therefore, if you can read comp.lang.modula3, please do not register on the list, or send us a message (m3-request@src.dec.com) if you are already on the list. Also, post directly to comp.lang.modula3 if you can. comp.lang.modula3 will be archived, just as the m3 mailing list has been. Messages for the past months are available via anonymous ftp on gatekeeper.dec.com in pub/DEC/Modula-3/m3-mail.-.Z. Eric Muller. ------------------------------------------------------------------------------ System Research Center - 130 Lytton Av. - Palo Alto, CA 94301 - (415) 853 2193 ------------------------------------------------------------------------------ Date: Tue, 18 Dec 90 23:48:16 PST From: muller@src.dec.com (Eric Muller) Subject: Modula-3 bibliography There are currently three bibliographic references related to Modula-3. We welcome additions, of course ! I will maintain this list and make it available for anonymous ftp. @techreport (CDG*89, author = "Luca Cardelli and James Donahue and Lucille Glassman and Mick Jordan and Bill Kalsow and Greg Nelson" title = "Modula-3 Report (revised)" number = "52", type = "SRC report", institution = "System Research Center, Digital Equipment Corporation" address = "Palo Alto", month = nov, year = 1989, howtoget = "Via anonymous ftp on gatekeeper.dec.com, in pub/DEC/Modula-3/Report.ps. This file has been formatted for an Apple Laserwriter. The files Report{1,2,3}.ps are also the report, in three postscript files, to accomodate small printers. On paper, by sending a mail to src-report@src.dec.com." what = "This report is {\em the} definition of the language." ) @techreport (BN89, author = "Mark R. Brown and Greg Nelson" title = "{IO} Streams: Abstract Types, Real Programs", number = "53", type = "SRC report", institution = "System Research Center, Digital Equipment Corporation" address = "Palo Alto", month = nov, year = 1989, howtoget = "On paper, by sending a mail to src-report@src.dec.com." what = "Shows how to use objects in a real program. Also defines the de facto standard input/output functions." ) @article (Har90, author = "Sam Harbison", title = "Modula-3", journal = "Byte", volume = 15, number = 12, pages = 385--392, month = nov, year = 1990, what = "A survey article." ) Eric Muller. ------------------------------------------------------------------------------ System Research Center - 130 Lytton Av. - Palo Alto, CA 94301 - (415) 853 2193 ------------------------------------------------------------------------------ Date: Tue, 18 Dec 90 23:49:16 PST From: muller@src.dec.com (Eric Muller) Subject: Getting SRC Modula-3 SRC Modula-3 is one of the two freely available implementations of Modula-3. It has been developped by the System Research Center, a Digital Equipment Corporation research lab in Palo Alto, California. The currently available release, 1.5, is rather old now, and we have received a fair number of bug reports. We are in the process of building the 1.6 beta release, which should be available before the end of the year. SRC Modula-3 is available via anonymous ftp and anonymous uucp. We do not have the resources to make tapes in any format, but the licence agreement lets anybody do that. Below are the messages that indicate where to get the release. We can be reached at m3-request@src.dec.com. Eric Muller. ------------------------------------------------------------------------------ System Research Center - 130 Lytton Av. - Palo Alto, CA 94301 - (415) 853 2193 SRC Modula-3 ------------ A new release, version 1.5, of the SRC Modula-3 compiler and runtime are available now. This is the third public release of SRC Modula-3. The system was developed at the DEC Systems Research Center. It is being distributed in source form (mostly Modula-3) and is available for public ftp. You must have a C compiler to build and install the system. The primary changes since version 1.4 are: - many bugs are fixed - the libraries have been reorganized - demos and games have been added - the system was ported to: Apollo DN4500 running Domain/OS, IBM PC running AIX/PS2, IBM RT running IBM/4.3, IBM R6000 running AIX 3.1, HP 9000/300 running HP-UX 8.0 in addition to the previous ports: VAX running Ultrix 3.1 DECstation 3100 and 5100 running Ultrix 3.1 SPARCstation running SunOS 4.0.3 - the installation on multiple platforms is easier - ports are easier SRC Modula-3 is available without signing any license agreements. If you chose to sign the commercial license, you will be able to use SRC Modula-3 commercially. Modula-3 is a new language. The goals of its design are best encapsulated in the preface to the Modula-3 Report [1]: The goal of Modula-3 is to be as simple and safe as it can be while meeting the needs of modern systems programmers. Instead of exploring new features, we studied the features of the Modula family of languages that have proven themselves in practice and tried to simplify them into a harmonious language. We found that most of the successful features were aimed at one of two main goals: greater robustness, and a simpler, more systematic type system. Modula-3 descends from Mesa, Modula-2, Cedar, and Modula-2+. It also resembles its cousins Object Pascal, Oberon, and Euclid. Modula-3 retains one of Modula-2's most successful features, the provision for explicit interfaces between modules. It adds objects and classes, exception handling, garbage collection, lightweight processes (or threads), and the isolation of unsafe features. SRC Modula-3 includes a user manual, compiler, runtime library, core library, pretty-printer, and a few other goodies. The libraries include interfaces for X11R4, I/O streams, string functions, access to command line arguments, random numbers, and operating system access. The compiler generates C as an intermediate language and should be fairly easy to port. Except for the garbage collector and the very lowest levels of the thread implementation, the entire system is written in Modula-3. The system is available for anonymous ftp from 'gatekeeper.dec.com' [16.1.0.2]. The SRC Modula-3 files are in '/pub/DEC/Modula-3'. Those files include: m3-1.5.tar.Z the system m3-1.5.tar.Z-{01,...,12} same, in pieces Report.ps the revised language report Report{1,2,3}.ps same, in pieces Release-1.5.ps the user manual (PostScript) m3-mail..Z archive of mail sent to m3@src.dec.com The compressed tar files are about 6.0Mbytes after compression. The entire system requires about 35Mbytes of disk space to build and install. Enjoy, Bill Kalsow and Eric Muller References ---------- [1] The Modula-3 Report (Revised), L. Cardelli, J. Dohnaue, L. Glassman, M. Jordan, B. Kalsow, G. Nelson, DEC Systems Research Center, Palo Alto, CA and Olivetti Research Center, Menlo Park, CA, Nov 89. VAX, DECstation and ULTRIX are registered trademarks of Digital Equipment Corporation. Unix is a registered trademark of AT&T Corporation. SPARC and SunOS are trademarks of Sun MicroSystems. Apollo and Domain/OS are trademarks of Apollo. IBM and AIX are registered trademarks of International Business Machines Corporation. RT and PS/2 are trademarks of International Business Machines Corporation. HP, HP9000 and HP9000/300 are trademarks of Hewlett-Packard Company. HP-UX is Hewlett-Packard's implementation of the Unix operating system. PostScript is a registered trademark of Adobe Systems Incorporated. ------------------------------------------------------------------------------- From: George M. Jones Subject: SRC Modula-3 1.5 available Date: Wed, 25 Jul 90 13:42:42 -0400 I have FTPed the 1.5 files and made them available for anonymous UUCP on osu-cis. The following is an extract from our general instructions about how to pick up software from osu-cis ==============================GNU.how-to-get============================== This file (osu-cis!~/GNU.how-to-get) describes how to get the following software from osu-cis via semi-anonymous UUCP: C++ Test Suite Compress Deliver 2.0 GNU Binary Utilities GNU Assembler GNU Awk GNU Bash GNU Bison GNU C++ Compiler GNU C++ Library GNU C Compiler GNU Chess GNU COFF hacks GNU CPIO GNU DBM GNU Debugger GNU Diff GNU Emacs GNU Emacs Ada support GNU Emacs Franz interface GNU Emacs Lisp Manual GNU File Utils GNU Find GNU Finger GNU Go GNU Gperf & Cperf GNU Grep GNU Indent GNU Lex GNU Make GNU Pins & Art GNU Plot & Plot2PS GNU Roff GNU Sed GNU Tar GNUS Ghostscript Gnews Ispell KA9Q Kermit M3 MIT C Scheme Mg2a NNTP News Oops PCRRN Patch Pathalias Protoize Proxy ARP RCS RFCs & IDEAS RN SB Prolog STDWIN Sendmail Smail Smalltalk Tcsh VM There's a lot of other available miscellany that isn't explicitly listed here. You can find out about it in the file osu-cis!~/ls-lR.Z The Computer and Information Science Department of the Ohio State University provides Free Software Foundation GNU products (and others) via UUCP only as a redistribution service. Anything found here is only and exactly as it would be found on the indicated Internet hosts, were one to acquire it via anonymous FTP (like we did); or else saved it as it flowed past on the Usenet source distribution newsgroups. OSU CIS takes no responsibility for the contents of any of the distributions described in this message. See the Distribution document (emacs/etc/DISTRIB when you unpack and build Emacs) and the GNU Emacs General Public License (emacs/etc/COPYING, similarly). Much of the GNU software is in beta-test. For a list of the current statuses (stati?), ask gnu@prep.ai.mit.edu for a copy of the latest FSF order form. How to reach osu-cis via uucp =============================== Here is a set of L.sys or Systems file lines suitable for osu-cis: # # Direct Trailblazer # osu-cis Any ACU 19200 1-614-292-5112 in:--in:--in: Uanon # # Direct V.32 (MNP 4) # dead, dead, dead...sigh. # #osu-cis Any ACU 9600 1-614-292-1153 in:--in:--in: Uanon # # Micom port selector, at 1200, 2400, or 9600 bps. # Replace ##'s below with 12, 24, or 96 (both speed and phone number). # osu-cis Any ACU ##00 1-614-292-31## "" \r\c Name? osu-cis nected \c GO \d\r\d\r \d\r in:--in:--in: Uanon Modify as appropriate for your site, of course, to deal with your local telephone system. There are no limitations concerning the hours of the day you may call. We are deeply grateful to Philips Components of Eindhoven, the Netherlands for the donation of a Trailblazer Plus and a Codex 2264 for use by the community at large. Where the files are =================== Most items exist on osu-cis for distribution purposes in compressed tar form, exactly what you find on the indicated hosts in the specified origin files. Most items are cut into pieces for the sake of uucp sanity. This separation helps if your uucp session fails midway through a conversation; you need restart only with the part that failed, rather than the whole beast. The pieces are typically named with a root word, followed by letter pairs like "aa" and "bj," meaning that the pieces are all named with the root word, followed by a dash and the suffixes indicated, using the letters inclusive between the two limits. All pieces but the last are 100,000 bytes long, and the fragmentary last piece has some smaller size. The instruction listings below are alphabetized as in the summary block above. . . . m3 - DEC/Olivetti Modula 3 Compiler -- Source is gatkeeper.dec.com. Root is ~/m3/. Files are: README 3970 bytes m3-1.5.tar.Z the system 5845892 bytes m3-1.5.tar.Z-{01,...,12} same, in pieces 524288 bytes each (part 1-11) 78724 bytes (part 12) Report.ps the revised language report 258305 bytes Report{1,2,3}.ps same, in pieces 103558 bytes (part 1) 109352 bytes (part 2) 105183 bytes (part 3) Release-1.5.ps the user manual (PostScript) 237915 bytes README is the message that was posted by DEC announcing the 1.5 release. It describes briefly what Modula 3 is and the particular files are. . . . ------------------------------------------------------------------------------ Date: Tue, 18 Dec 90 18:15:00 +0100 From: buschman@tubsibr.uucp (Andreas Buschmann) Subject: Modula-3 report: recursive declarations Hi! About recursive declarations: Report, page 32, last example of illegal declarations: VAR v := P(); PROCEDURE P() : ARRAY [0..NUMBER(v)] OF INTEGER I understand that it is impossible to determine the number of elements of `v' from this, but I don't see hob this (beeing an illegal recursive declaration) is covered by the report. Recursive declarations A constant, type, or procedure declaration N = E, a variable declaration N : E, an exception declaration N(E), or a revelation N = E is recursive if N occeurs in any partial expansion of E. A variable declaration N := I where the type is omitted is recursive if N occeurs in any partial expansion of the type E of I. Such declarations are allowed if every occurrence of N in any partial expansion of E is (1) within some occurence of the type constructor REF or PROCEDURE, (2) within a field or method type of the type constructor OBJECT, or (3) within a procedure body. Tschuess Andreas p.s. is TYPE strange = REF strange; a legal declaration? With this definition, it should be. Is it? ------------------------------------------------------------------------------ Date: Thu, 20 Dec 90 09:08:50 EST From: moss%ibis@cs.umass.edu (Eliot Moss) Subject: Modula-3 syntax and semantics for constants >>>>> On Sun, 16 Dec 90 17:17:34 +0100, buschman@tubsibr said: buschman> In the report (21.10.89) it is said: "Expressions whose values can be buschman> determined statically are called constant expressions; ..." (p.2). buschman> But what is really allowed in constant expressions? In the report at buschman> least procedural operators are used in examples. What else would be buschman> ok? I don't know what you mean by "procedural operators", but certain built-in functions and infix/prefix operators are allowed if their values can be determined at compile time. User defined procedures are not. buschman> VAR a : INTEGER := 10; buschman> CONST b : INTEGER = a; buschman> is rejected by the compiler, but the value of b could be determined buschman> statically to be 10. It is always hard to be precise, but perhaps it would help to say "Expressions whose values can be determined statically without applying optimization techniques (such as data flow analysis or inline expansion) are called constant expressions." You are quite right that with advancing compiler technology it is harder ot make these definitions precise, though I suspect most language implementors would interpret the report the same way. It's roughly: it's a constant expression if we can determine its value statically by constant folding, i.e., it is an expression built from literals, constant definitions, and applications of certain functions and operators. (Some operators give a constant expression even when the expression they're applied to is not constant; again, that could all be handled.) It could be, and has been, done; it is just tedious. Hope this helps; I would tend to agree that Report wording should be reconsidered if it is not clear ..... J. Eliot B. Moss, Assistant Professor Department of Computer and Information Science Lederle Graduate Research Center University of Massachusetts Amherst, MA 01003 (413) 545-4206; Moss@cs.umass.edu ------------------------------------------------------------------------------ Date: 20 Dec 1990 0940-PST (Thursday) From: Subject: Re: Twelve changes to Modula-3 Jorge Stolfi asks several questions about the twelve changes to Modula-3 described in my previous message. First he mentions: (*1*) TYPE A = OBJECT METHODS m() END; B = OBJECT METHODS p() := A.m END; and correctly infers that this makes B.m be NIL. (*2*) TYPE A <: OBJECT METHODS m() END; B = OBJECT METHODS p() := A.m END; This is legal; the value of B.m is the same as A.m, but this value is unknown in the scope. (*3*) TYPE A = OBJECT METHODS m() := M; p() := A.m END; This is an illegal recursion, since the occurrence of A is not "within a field or method type of the type constructor OBJECT", to quote from the language definition. Of course in this case the recursion is harmless, but in the very similar A = OBJECT METHODS m() := A.m END the recursion is nonsensical. (*4*) TYPE P = OBJECT METHODS m(); p() := A.m END; A <: P; This is legal (or not illegal) as it stands, but I don't see any way to write a complete revelation that will make it into a legal program. For example, if you completed it by REVEAL A = P BRANDED OBJECT END; then the expanded definition of P would contain an illegal occurrence of A. (I have altered Jorge's example by introducing the name P, to make the revelation clearer to read.) Jorge also asks Also, is it true that after the Twelve Changes I will be able to write INTERFACE Foo; IMPORT Wr; CONST Put = Wr.PutChar; END Foo. or INTERFACE Foo; IMPORT Wr; VAR Put: PROCEDURE (wr: Wr.T; char: CHAR) RAISES {...} := Wr.PutChar END Foo. but not INTERFACE Foo; IMPORT Wr; PROCEDURE Put(wr: Wr.T; char: CHAR) RAISES {...}; END Foo. MODULE Foo; IMPORT Wr; PROCEDURE Put(wr: Wr.T; char: CHAR) RAISES {...} = Wr.PutChar; BEGIN END Foo. He is correct in all three cases. ------------------------------------------------------------------------------ Date: 19 Dec 1990 1606-PST (Wednesday) From: Subject: Re: Modula-3 report: recursive declarations Andreas Buschmann asks several questions. (1) How does the wording of the Modula-3 report prohibit the declaration: VAR v := P(); PROCEDURE P() : ARRAY [0..NUMBER(v)] OF INTEGER The reason is that the words "a variable declaration N := I where the type is omitted is recursive if N occurs in any partial expansion of the type E of I" apply to the declaration of v, since the type of P() is "ARRAY [0..NUMBER(v)]", which contains v. Since the occurrence of v is not within REF or PROCEDURE or withing a field or method type of OBJECT or within a procedure body, the recusion is illegal. (2) Is TYPE T = REF T legal. Yes, it is legal. It is pretty pointless, but it would be even more pointless to prohibit it. (3) What is the exact definition of a constant expression? The answer is at the end of the Expressions section, where there is an explicit list of what operations are forbidden in constant expressions. ------------------------------------------------------------------------------ Date: Sun, 16 Dec 90 17:17:34 +0100 From: buschman@tubsibr.uucp (Andreas Buschmann) Subject: Modula-3 syntax and semantics for constants Hello! About constant declarations and constant expressions: How are constant expressions to be handled, what can be seen in a constant declaration. As an example let's have the following program MODULE Main; IMPORT Stdio, Wr, Fmt; CONST i = j; CONST j = 10; BEGIN Wr.PutText (Stdio.stdout, Fmt.Int (i) & "\n"); END Main. Compiled with SRC Modula3 the program prints 10. In the report (21.10.89) it is said: "Expressions whose values can be determined statically are called constant expressions; ..." (p.2). But what is really allowed in constant expressions? In the report at least procedural operators are used in examples. What else would be ok? VAR a : INTEGER := 10; CONST b : INTEGER = a; is rejected by the compiler, but the value of b could be determined statically to be 10. Also PROCEDURE p (x : INTEGER) : INTEGER = BEGIN RETURN x + 1; END p; CONST b : INTEGER = p (1); is rejected. A related question: what can be used in a constant expression? I need some enlightment. Tschuess Andreas p.s. I don't need to know how one or more compiler may handle this stuff, but how it is intended to be. ------------------------------------------------------------------------------ Date: Fri, 21 Dec 90 16:16:33 EST From: moss%ibis@cs.umass.edu (Eliot Moss) Subject: Stolfi's illegal code >>>>> On 20 Dec 1990 0940-PST (Thursday), gnelson@src.dec.COM said: gnelson> Jorge also asks gnelson> Also, is it true that after the Twelve Changes I will be able to w rite gnelson> gnelson> INTERFACE Foo; gnelson> IMPORT Wr; gnelson> CONST Put = Wr.PutChar; gnelson> END Foo. gnelson> gnelson> or gnelson> gnelson> INTERFACE Foo; gnelson> IMPORT Wr; gnelson> VAR Put: PROCEDURE (wr: Wr.T; char: CHAR) RAISES {...} := Wr .PutChar gnelson> END Foo. gnelson> gnelson> but not gnelson> gnelson> INTERFACE Foo; gnelson> IMPORT Wr; gnelson> PROCEDURE Put(wr: Wr.T; char: CHAR) RAISES {...}; gnelson> END Foo. gnelson> gnelson> MODULE Foo; gnelson> IMPORT Wr; gnelson> PROCEDURE Put(wr: Wr.T; char: CHAR) RAISES {...} = Wr.PutCha r; gnelson> BEGIN gnelson> END Foo. gnelson> He is correct in all three cases. I don't see what's wrong with the last case. Could somebody explain it, please? J. Eliot B. Moss, Assistant Professor Department of Computer and Information Science Lederle Graduate Research Center University of Massachusetts Amherst, MA 01003 (413) 545-4206; Moss@cs.umass.edu ------------------------------------------------------------------------------ Date: 22 Dec 1990 1746-PST (Saturday) From: Subject: Re: Stolfi's illegal code I don't see what's wrong with the last case. Could somebody explain it, please? In the implementation file, the body of "Put" is syntactically illegal: PROCEDURE Put(wr: Wr.T; char: CHAR) RAISES {...} = Wr.PutChar; I wish the above were legal, but the body has to be a real body, e.g. PROCEDURE Put(wr: Wr.T; char: CHAR) RAISES {...} = BEGIN Wr.PutChar(wr, char) END Put; --stolfi ------------------------------------------------------------------------------ Date: 24 Dec 90 02:10:53 GMT From: templon@copper.ucs.indiana.edu (jeffrey templon) Subject: Questions about M3 (User-Oriented Doc and Macintosh) I have two questions about Modula-3. The first concerns the documentation. I have read through the gatekeeper files Release-1.5.ps and have browsed Report1.ps. The first seems mainly concerned (by definition) with how to get and setup Modula-3. The second seems to be a "definition" of Modula-3. As far as I can tell it is written by programming-language-designers for programming-language-designers. I am a potential *user* - is there some documentation aimed at me? Perhaps I did not read far enough into the 'report'. To be more specific about what I'm looking for, I would like to find something which is structured and paced along the lines of 'The GAWK Manual' that comes with GNU Awk. It explains the various components and features by using lots of small, working example programs that deal with concrete, familiar situations so someone gets an idea of how to actually USE the features. The second concerns implementations - I would like to know if there is one that will run on a Macintosh SE, or if someone is working on such a beast. Thanks for any information. Jeff Templon ------------------------------------------------------------------------------ Date: 21 Dec 90 00:26:52 GMT From: danforth@riacs.edu (Douglas G. Danforth) Subject: Re: Welcome to comp.lang.modula3 In <1990Dec18.234527.15456@src.dec.com> muller@src.dec.com (Eric Muller) writes : >Here is a reminder about the charter of this newsgroup. >NAME: > comp.lang.modula3 >STATUS: > unmoderated ... > Modula-3 retains one of Modula-2's most successful features, the > provision for explicit interfaces between modules. It adds objects > and classes, exception handling, garbage collection, lightweight > processes (or threads), and the isolation of unsafe features. >Eric Muller. >------------------------------------------------------------------------------ >System Research Center - 130 Lytton Av. - Palo Alto, CA 94301 - (415) 853 2193 Hey, Come on you guys. I'm continually appalled at the number of languages that keep appearing. Hasn't anyone heard of MAINSAIL? All these features have been available commercially in MAINSAIL for 10 years. MAINSAIL stands for Machine Independent SAIL. Where SAIL stands for Stanford Artificial Intelligence Language (actually the L stands for memo L from the AI lab). History: Stanford AI Lab => Feigenbaum's Heuristic programming project => XIDAK (formed to market MAINSAIL). For more information, contact: XIDAK, Inc. 3475 Deer Creek road Building C Palo Alto, CA 94304 (415) 855-9271 (I'm just a user. Since 1972). -- Douglas G. Danforth (danforth@riacs.edu) Research Institute for Advanced Computer Science (RIACS) M/S 230-5, NASA Ames Research Center Moffett Field, CA 94035 ------------------------------------------------------------------------------ Date: 21 Dec 90 18:52:18 GMT From: ml3q+@andrew.cmu.edu (Michael H. Lambert) Subject: Re: Twelve changes to Modula-3 I see from Greg Nelson's message that operator overloading is still not included in the language definition. I don't really see a conceptual difference between operator and procedure overloading. Can we expect this to be included in the language at some time? Michael H. Lambert Pittsburgh Supercomputing Center ------------------------------------------------------------------------------ Date: 24 Dec 90 20:03:22 GMT From: guenter@prism.gatech.EDU (Brian Guenter) Subject: Request for more readable modula3 document I also found the Modula3 report somewhat terse and unhelpful. Is there a document out there which describes the language from a user's point of view? -- Brian Guenter College of Computing Georgia Institute of Technology, Atlanta Georgia, 30332-0280 Internet: guenter@cc.gatech.edu ------------------------------------------------------------------------------ Date: Sun, 30 Dec 90 15:30:04 -0500 From: fkz@cs.brown.edu (Kenneth Zadeck) Subject: Twelve changes to Modula-3 In section 3.1 of the 12 changes, are all IMPORTs done before the IMPORT FROMs or are doen in order. Another way of asking the question: is this IMPORT I AS J, J AS I; FROM I IMPORT X; the same as this? FROM I IMPORT X; IMPORT I AS J, J AS I; kenny ------------------------------------------------------------------------------ Date: 28 Dec 90 19:04:16 GMT From: idilber@ephesus.ncsa.uiuc.edu (Ilhan Dilber) Subject: Translator to C I am looking for the source code for a translator from Modula-3 to C. I heard it was available from DEC via anonymous ftp. I downloaded some stuff from their modula3 directory, but it looks like it is more than just a translator ( and I don't know if the translation routine is part of that). Does anyone know if there is such a translator and where to find the source? Ilhan Dilber ------------------------------------------------------------------------------ Date: 31 Dec 90 20:32:40 GMT From: system@syzzle.UUCP (SYSTEM 0PERATOR) Subject: Modula-3 implementations I have been programming in modula-2 under DOS for a while now, and afte r reading the article in BYTE magazine, was looking forward to checking out modula-3. I then read the message saying that Modula-3 required 35M of disk space to implement? I understand that there is another implementation available, is this also as LARGE? Are there any plans to port modula-3 to MSDOS? Thanks for any answers you may have! Al ------------------------------------------------------------------------------