======================================================================== 1 === Date: Fri, 1 Nov 91 08:27:50 PST From: Subject: troubles with opaque types Attached below is a short exchange between Bert Laverman (laverman@cs.rug.nl) and myself on the problems of compiling opaque types. - Bill Kalsow ---- Laverman -> Kalsow ------------------------------------------------------ I am a PhD student at Groningen University, the Netherlands, and currently working on a small paper concerning generic types, and the (im)possibilities for doing static checks on their usage. I contacted Sam Harbison in connection with the Modula-3 report, since I thought I had reasoned out a way for the example Queue routines (pp 14-15) to be compiled without needing runtime type checks. This was ofcourse based on a small extension, namely that of type parameters. I will not go into that right now (though ever at your service if you are interested ;-)). A second part of my message to him was a request for related subjects for my research. One of his answers concerned the link-time resolving of opaque types. He gave me your email addresses for reference. I have ordered the book (SPwM3), but it may take a while before it arrives. Could you give me a more specific description of the problem involved. Since you are involved in writing a compiler for Modula-3, perhaps you can give me a more detailed description of the problem. ---- Kalsow -> Laverman ------------------------------------------------------ The general problem with opaque types is that the full information needed to generate high quality code isn't available until the entire program is available (e.g. link time). For example: INTEFACE A; TYPE T <: ROOT; END A. INTERFACE B; IMPORT A; TYPE T <: A.T OBJECT x: INTEGER END; END B. A client of B.T knows that there's an integer-valued 'x' field, but doesn't know it's offset. INTERFACE C; IMPORT A; TYPE T <: ROOT; REVEAL A.T = T BRANDED OBJECT y: INTEGER END; END C. And even a client of C who sees the "full" revelation of A.T doesn't know the offsets since they depend on C.T. Finally, the truth might be hidden in an arbitrary piece of the system: MODULE FooBar; IMPORT C; REVEAL C.T = BRANDED OBJECT z: INTEGER END; .... The kinds of information that a compiler would like at compile time, but aren't available until later include: 1) offsets of fields & methods 2) the total size of the object 3) the default values of the fields & methods 4) which fields must be traced by the garbage collector 5) the full inheritance hierarchy I hope this helps. ---- Laverman -> Kalsow ------------------------------------------------------ I would like to continue on your example. I tried some m3 minimal tests with SRC m3. Appearently circular dependecies are not allowed. I don't know if this is the same for the current m3 standard (book hasn't arrived yet), but at least this means that a compilation order can be determined. SRC-m3 seems to translate the interfaces separately from the modules, and I suppose this is the cause of the problem. Such a separate compilation serves a relaxation in the development order, but I wonder if actual _real_ compilation is needed at that stage. A simple checker (say up to, but not including intermediate code generation) would suffice. For the real compilation the dependency graph can be followed, in which case the interface itself is at most needed for - again - error checks. The exported information can maybe be generated from the _module_, rather than the interface. In this way all the wanted bits of information can be supplied to those importing the module. A strategy might be to generate this export file directly after all the declarations have been processed, using the interface as a guide for what information is needed. A way of looking at it might be to merge the interface with the module, using a special notation for those items that need exporting. When thinking about that situation, the automatic generation of a detailed export file comes as a natural consequence. There is no reason to suddenly discard the implementation details when you're only dropping textual details. Then again, since I only now start on this, there may be something I overlooked. Please attack me (verbally, please ;-)) at will. ---- Kalsow -> Laverman ------------------------------------------------------ I'm not sure I understand your message, but let me try to answer anyway. Modula-3 does not allow cycles in the import graph of interfaces. Modula-3 does allow some recursions in declarations. SRC Modula-3 compiles interfaces. Yes, if you defer the "_real_ compilation" until all the interfaces and modules are present, the problems I mentioned are easy. I think I said as much: The general problem with opaque types is that the full information needed to generate high quality code isn't available until the entire program is available. Yes, separating the interfaces and implementations relaxes the dependencies in compilation order. This is not just a convenience. In large systems developed concurrently by many programmers it's a necessity. Ask anyone writing software for the phone company, aerospace industry or military complex. Both Oberon and Eiffel merge the interface and implementation. Eiffel at least has a tool to extract the interface. Note that Modula-3 does not require a 1-1 correspondence between interfaces and implementations. An interface may be implemented by more than one module and a module may implement parts of more than one interface. In this context merging is more troublesome, but probably still possible. The problems with opaque types are not solved by merging interfaces and implementations. The full revelation for an opaque type exported by an interface A is not required to be in any of the modules that implement A, although it usually is. Modula-3 requires only that every opaque type have a full revelation somewhere in the program. ======================================================================== 2 === Date: Fri, 1 Nov 91 14:56:21 PST From: muller@src.dec.com (Eric Muller) Subject: Modula-3 Frequently Asked Questions (FAQ) [ Last modified on Fri Nov 1 14:55:38 PST 1991 by muller ] MODULA-3 FAQ ============ What is Modula-3 ? 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. There is an overview article "Modula-3", by Sam Harbison, in Byte, Vol. 15, Number 12, October 1990, p 385. Is Modula-3 a superset of Modula-2 ? No; valid Modula-2 programs are not valid Modula-3 programs. Where can I get a definition of Modula-3 ? The definition of Modula-3 is contained in: System Programming with Modula-3 Edited by Greg Nelson Prentice Hall Series in Innovative Technology ISBN 0-13-590464-1 L.C. QA76.66.S87 1991 Previous definitions were published as SRC Reports # 31 and 52 and can be obtained on paper from SRC by sending a message to src-report@src.dec.com. Report # 52 is also available in PostScript format via anonymous ftp from gatekeeper.dec.com in pub/DEC/Modula-3/report. Where can I get information on Modula-3 ? There is a Usenet newsgroup, comp.lang.modula3. The archives of that group are available via anonymous ftp from gatekeeper.dec.com in pub/DEC/Modula-3/comp.lang.modula3. The messages sent to comp.lang.modula3 are relayed to a mailing list; send a message to m3-request@src.dec.com to be added to it. Also, Pine Creek Software publishes a free newsletter and various announcements about Modula-3 products and activities. To be added to their mailing list, send email or US mail to: Pine Creek Software Suite 300 305 South Craig Street Pittsburgh, PA 15213 Phone & Fax: [1] (412) 681 9811 Email: modula3@bert.pinecreek.com Where can I get an implementation ? There is only one implementation available today. It has been built by SRC and is available via anonymous ftp from gatekeeper.dec.com in pub/DEC/Modula-3/m3-1.6. The current version, 1.6, implements the language defined in the SRC report # 52. Version 2.0 is in the works and will implement the latest definition. Version 1.6 runs on: Acorn R260 running RISC iX 1.21 Apollo DN4500 running Domain/OS, DECstation 3100 and 5000 running Ultrix 4.0 and 4.2 Encore Multimax running UMAX 4.3 (R4.1.1) HP 9000/300 running HP-UX 8.0 IBM PC running AIX/PS2, IBM RT running IBM/4.3, IBM R6000 running AIX 3.1, VAX running Ultrix 3.1 SPARCstation running SunOS 4.1.x SUN3 running SunOS 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 very lowest levels of the thread implementation, the entire system is written in Modula-3. What if I don't have ftp access ? You can contact Pine Creek Software (see the address above). -- Eric. ======================================================================== 3 === Date: Fri, 1 Nov 91 15:08:01 PST From: muller@src.dec.com (Eric Muller) Subject: archive of comp.lang.modula3 The archive of the messages sent to comp.lang.modula3 in September and October 1991 are now available in gatekeeper.dec.com:pub/DEC/Modula-3/comp.lang.modula3/91-{09,10}.Z Enjoy, Eric. ======================================================================== 4 === Date: 4 Nov 91 14:05:01 GMT From: collberg@dna.lth.se (Christian S. Collberg) Subject: Re: troubles with opaque types I am in the process of writing up my thesis which describes an experimental modular language (Zuse) and its implementation. Basically, Zuse is Modula[23]/Ada-like but allows several levels of information hiding. In order to support this the implementation employs intermediate code linking. Currently there is a Zuse compiler, a sequential "paster" (intermediate code linker), and a distributed paster which runs on a network of Sun-3:s. The following rather lengthy blurb gives an informal description of the language and its implementation. If someone is interested I can send a copy of a preliminary version of a more detailed paper which has been submitted for publication. I will email if you can handle a compressed, uuencoded, postscript file. Regards, Christian Christian.Collberg@dna.lth.se Department of Computer Science, Lund University, BOX 118, S-221 00 LUND, Sweden ------------------------------------------------------------------------------ In Zuse there are three ways to export a type, constant, or procedure: Concrete export, semi-abstract export, and abstract export. A concrete type, for example, reveals its entire realization in the specification part of the exporting module, whereas an abstract type defers the realization to the implementation unit. A semi-abstract type reveals some of its realization in the specification and defers the rest to the implementation. Similarly, a concrete procedure reveals its body and inline-status in the specification, whereas an abstract procedure hides these in the implementation. A semi-abstract procedure hides its code but reveals whether it is inline or not. Concrete export --------------- The Zuse type-system includes all the types of Modula-2 (equivalence, subrange, enumeration, record, array, procedure, set, and pointer types), an object type similar to the one found in Modula-3, and a UNIQUE type similar to Ada's NEW type. An object type comes in four parts: an optional super type (preceded by the keyword 'WITH'), a sequence of fields (the first set of brackets), a sequence of methods (second set of brackets), and a sequence of method overrides (third set of brackets). Constants may be scalar or structured. Procedures may be inline. Concrete export is indicated by the symbol '=='. Here are some examples: SPECIFICATION Concrete; TYPE RangeT == RANGE INTEGER [0..20]; TYPE SetT == SET S; TYPE EnumT == ENUM [blue, green]; TYPE RecordT == RECORD [a, b : INTEGER]; TYPE ArrayT == ARRAY CHAR OF INTEGER; TYPE PointerT == REF RecordT; TYPE ProcT == (a : EnumT; b : REAL); TYPE FunT == (a : EnumT; b : REAL) RETURN CHAR; TYPE EquivT == ArrayT; TYPE UniqueT == UNIQUE INTEGER; TYPE ObjectT == OBJECT [a : INTEGER; x : CHAR] [p : (x : INTEGER) RETURN INTEGER := Proc1] [ ]; TYPE SubT == WITH ObjectT OBJECT [r : REAL] [v : (x : REAL) RETURN REAL := Proc2] [p := Proc3]; CONSTANT C1 : INTEGER == 10; CONSTANT C2 : RecordT == RECORD [a := 5; b := 6]; PROCEDURE Proc1 : (T : ObjectT; a : INTEGER) RETURN INTEGER == BEGIN ... END Proc1; PROCEDURE Proc2 : (T : SubT; a : REAL) RETURN REAL == BEGIN ... END Proc2; PROCEDURE Proc3 : (T : ObjectT; a : INTEGER) RETURN INTEGER == BEGIN ... END Proc3; INLINE PROCEDURE P : (a : INTEGER) == BEGIN ... END P; END Concrete. IMPLEMENTATION Concrete; END Concrete. Abstract export --------------- Abstract export is indicated by the symbol '='. The realization of an abstract item is declared using the '+=' symbol. There are no restrictions on the realization of an abstract type. The type of an abstract constant may be either abstract or concrete. Abstract procedures hide their body as well as their inline status. Examples: SPECIFICATION Abstract; (* An abstract type: *) TYPE T = ; (* An abstract constant of an abstract type: *) CONSTANT D : T = ; (* An abstract constant of a concrete type: *) CONSTANT C : INTEGER = ; (* An abstract procedure: *) PROCEDURE P : (a : INTEGER) = END Abstract. IMPLEMENTATION Abstract; TYPE T += RECORD [a, b : INTEGER]; CONSTANT D : T += RECORD [a :=10; b := 5]; (* OR *) TYPE T += INTEGER; CONSTANT D : T += 6; (* OR *) TYPE T += ARRAY CARDINAL [0..100] OF CHAR; CONSTANT D : T += ARRAY [[0]="h"; [1]="i"; [2]="!"]; CONSTANT C : INTEGER += 100; PROCEDURE P : (a : INTEGER) += BEGIN ... END P; (* OR *) INLINE PROCEDURE P : (a : INTEGER) += BEGIN ... END P; END Abstract. Semi-abstract export: --------------------- Zuse supports semi-abstract constants and procedures, and two kinds of semi-abstract types. The realization of a semi-abstract item comes in two parts: the visible part which is given in the specification unit, and the hidden part which is deferred to the implementation unit. Semi-abstract types come in two flavors: semi-hidden and extensible. A semi-hidden type reveals its type-class in the specification unit and must be redeclared in the implementation. An extensible type, on the other hand, reveals part of its realization in the specification and may be extended in the implementation. There are four semi-hidden types: hidden pointer, subrange, object, and enumerable types. A hidden pointer type (which is equivalent to Modula-2's and Mesa's opaque type and Ada's deferred access type) may only be realized by a pointer or address type. A hidden subrange type reveals its type in the specification unit but defers its range to the implementation. A hidden object type (similar to Modula-3's opaque object type) must be realized as an object type. A hidden enumerable type may be realized by any ordinal type, i.e. by any of the built-in enumerable types (integer, character, boolean, etc), by enumeration types, or by subranges of these types. Examples: SPECIFICATION SemiHidden; TYPE S = RANGE INTEGER; (* Hidden subrange type *) TYPE E = <>; (* Hidden enumerable type *) TYPE P = REF; (* Hidden pointer type *) TYPE O = OBJECT; (* Hidden object type *) END SemiHidden. IMPLEMENTATION SemiHidden; IMPORT SYSTEM; TYPE S += RANGE INTEGER [10 .. 20]; (* Any of the following implementations of E are possible: *) TYPE E += INTEGER; TYPE E += CHAR; TYPE E += ENUM [mon, tue, wed, thu, fir, sat, sun]; TYPE E += RANGE INTEGER [0..10]; TYPE P += REF RECORD [a, b : REAL]; TYPE P += SYSTEM`ADDRESS; TYPE O += OBJECT [a : INTEGER] [] []; END SemiHidden. An importer of SemiHidden can, for example, declare arrays with SemiHidden`E as an index type without any knowledge of how E is realized: VARIABLE A : ARRAY CHAR, SemiHidden`E OF INTEGER; VARIABLE S : SET SemiHidden`E; There are four extensible types: extensible record, enumeration, object, and subrange types. An extensible record may reveal some fields in the specification unit and may extend these with additional fields in the implementation unit. Similarly, an implementation unit may add identifiers to an extensible enumeration type, or widen the range of an extensible subrange type. The extensible record type is similar to Oberon-1's public projection type, only in Zuse it is not necessary to reveal the maximum size of the realization in the specification unit of the exporting module. The fields, methods, method initializations, method overrides, and the super type of an extensible object type may all either be revealed or hidden. Note, however, an object may be given a super type either in the specification or the implementation part of a module, but not both. Furthermore, a method may only be initialized in the specification or the implementation, but not both. The value of Zuse structured constants may be arbitrarily divided between the specification and implementation units. The type of an extensible constant may itself be extensible or concrete. SPECIFICATION Extension; (* An extensible record type and a constant of this type. *) TYPE T = RECORD [a : INTEGER]; CONSTANT D : T = RECORD [a := 10]; (* A concrete record type and an extensible constant of this type. * ) TYPE R == RECORD [b : INTEGER; c : CHAR]; CONSTANT C : R = RECORD [b := 10]; (* Extensible subrange type *) TYPE S = RANGE INTEGER [0..10]; (* Extensible object type *) TYPE O = OBJECT [a : INTEGER] [p : (x : CHAR) RETURN INTEGER] []; (* Extensible enumeration type *) TYPE E = ENUM [red, blue, green]; END Extension. IMPLEMENTATION Extension; IMPORT SemiHidden; (* T now has both fields a and b *) TYPE T += RECORD [b : REAL]; CONSTANT D : T += RECORD [b := 6.3]; CONSTANT C : R += RECORD [c := "x"]; (* S will really go up to 300 although a client *) (* may only use the values 0..10. *) TYPE S += RANGE INTEGER [0..300]; (* O now has all the fields and methods of SemiHidden`O, *) (* the fields a and b, and the methods p and q. p is *) (* initialized to Proc2 and q to Proc1. *) TYPE O += WITH SemiHidden`O OBJECT [b : REAL] [q : (x : INTEGER) RETURN CHAR := Proc1] [p := Proc2]; (* E has one hidden value -- yellow -- in addition to the *) (* public values red, blue, and green. *) TYPE E += ENUM [yellow]; END Extension. A semi-abstract procedure is one whose body is hidden but whose inline status is revealed. Examples: SPECIFICATION SemiProc; INLINE PROCEDURE P : (a : INTEGER) = NOT INLINE PROCEDURE Q : (a : INTEGER) = END SemiProc. IMPLEMENTATION SemiProc; INLINE PROCEDURE P : (a : INTEGER) += BEGIN ... END P; PROCEDURE Q : (a : INTEGER) += BEGIN ... END Q; END SemiProc. Type protection ---------------- In Zuse an exported type may be coupled with a protection clause which lists the operations a particular importer may perform on objects of the type. Examples of operations which may be part of a protection clause are assignment, component selection, and type coercion. All Zuse types may be protected, including abstract- and semi-abstract types, allowing for very fine grained control over the way a client of a module may manipulate the module's exported items. Although types are the only items which may receive an explicit protection, other exported items (variables, constants, and procedures) may be implicitly protected by protecting the items's type. SPECIFICATION Protection; (* A protected abstract type. Only modules M and N may *) (* manipulate objects of type Abstract, and the only *) (* operation available to M and N is assignment. *) TYPE Abstract = {(M,N):{:=, =:}}; (* Assignment, addition, subtraction, and test for *) (* equality are the only operations available on objects *) (* of type Address. "*:" indicates that all modules may *) (* import and use the type. *) TYPE Address == {*:{:=,=:,+,-,=}} UNIQUE CARDINAL; (* All clients may assign and read variables of type *) (* Open, but the field b is not accessible for *) (* manipulation. *) TYPE Open == {*:{:=,=:}} RECORD [b : REAL]; (* Variables of type Extensible are not assignable. The *) (* field b is accessible for manipulation, whereas a can*) (* only be read, not assigned to. *) TYPE Extensible = {*:{.,=:}} RECORD [a : {=:} CHAR; b : REAL]; (* A readonly variable. *) VARIABLE V : {*:{=:}} CARDINAL; END Protection. IMPLEMENTATION Protection; (* The exporting module is given permission to *) (* access the fields of Abstract and to perform *) (* type coercions involving Abstract. *) TYPE Abstract += {{., <<>>}} RECORD [a : INTEGER; b : REAL]; (* The exporting module is given permission to *) (* access the fields of type Open. *) TYPE Open {{.}}; TYPE Extensible += {{., <<>>}} RECORD [a : INTEGER]; END Protection. Implementation -------------- The Zuse translating system consists of a compiler and a paster, a high-level linker. The Zuse compiler performs the same tasks as a traditional compiler, checking syntactic and static semantic correctness of the input program and generating code for the target machine. The one difference is that the compiler may defer some of the static semantic checking and some of the code generation to the paster. We list some of the circumstances under which such deferral will be necessary: * The compiler will not always know the size of a type which is defined in terms of imported abstract or semi-abstract types or constants. Hence it will be unable to generate (optimal) code for any routine which allocates or references a variable of such a type. * The compiler cannot generate code for a call to an imported abstract or inline semi-abstract procedure. * The compiler cannot always check whether the declaration of an abstract type, constant, or inline procedure which is defined in terms of imported abstract items is part of an illegal recursive declaration. * The compiler cannot check the legality of a constant range (as used in the label-section of a case-statement or in the declaration of a subrange type) if either of the bounds is defined in terms of an abstract constant. The Zuse compiler does not generate code for procedures which contain references to unknown quantities. Such quantities include calls to imported inline procedures, the sizes of imported abstract types, the values of imported abstract constants, etc. Procedures which reference unknown quantities are instead kept in their intermediate code form and code generation is deferred to the pasting stage. Static semantic checks which cannot be resolved during compilation, allocation of global variables of unknown size, and creation of method templates for object types are also left to the paster. There currently exists two pasters, a sequential (the s-paster), and a distributed (d-paster). The d-paster achieves faster link times than the s-paster by distributing the work (chiefly inline expansion and code generation) over a network of workstations. I am also working on an incremental (i-paster) and a hierarchical (h-paster) paster. The i-paster will speed up linking by modifying the result of the previous link instead of relinking the entire program. The h-paster will be able to combine a set of modules into a library which can take part in later links. The current implementation runs on and produces code for Sun-3 workstations. ------------------------------------------------------------------------------- - -- Christian.Collberg@dna.lth.se Department of Computer Science, Lund University, BOX 118, S-221 00 LUND, Sweden ======================================================================== 5 === Date: 4 Nov 91 19:20:41 GMT From: harbison@bert.pinecreek.com (Sam Harbison) Subject: Call for articles, M3 News #2 I am beginning to put together issue #2 of the Modula-3 News, with focus items on Teaching Modula-3 and on SRC Modula-3 2.0. If you have any Modula-3 experiences you'd like to share, or if you would like to hear about some particular topic, drop me a note. Please include your phone number, in case I need verification or more information. By the way, I now have 367 people on the Modula-3 mailing list. Many don't have net access and therefore don't follow this newsgroup. 66% are in the USA. Here is the breakdown by country. Australia 10 Japan 1 Austria 1 New Zealand 1 Belgium 1 Norway 1 Brazil 2 P.R.China 1 Bulgaria 1 Portugal 1 Canada 15 St. Lucia 1 Denmark 4 Scotland 1 England 29 South Africa 2 Finland 1 Sweden 3 France 7 Switzerland 6 Germany 16 The Netherlands 8 Hong Kong 2 USA 244 Ireland 2 USSR 1 Italy 4 Yugoslavia 1 Are you there? You are if you got Modula-3 News #1 from me or if you contacted me to get on the list. If not, drop me a note with your postal address. The text-only version of the newsletter will be posted on gatekeeper.dec.com, but I've ordered an Apple OneScanner and I might just go crazy in the printed version of Issue 2... Sam Harbison Pine Creek Software; Suite 300; 305 South Craig Street; Pittsburgh, PA 15213; USA. Phone&FAX: +1 412 681 9811. E-mail: harbison@bert.pinecreek.com. ======================================================================== 6 === Date: Mon, 04 Nov 91 21:45:11 -0800 From: Paul A Vixie Subject: SRC M3 1.6 question: Time.Pause() a no-op? this program prints "+pause+" followed by "-pause-" with no delay. MODULE Main; IMPORT Stdio, Wr, Time; BEGIN LOOP Wr.PutText(Stdio.stdout, "+pause+\n"); Wr.Flush(Stdio.stdout); Time.Pause(22); Wr.PutText(Stdio.stdout, "-pause-\n"); Wr.Flush(Stdio.stdout); END; END Main. ======================================================================== 7 === Date: Mon, 04 Nov 91 22:59:01 -0800 From: Paul A Vixie Subject: SRC M3 1.6 stupid question my ears are burning. microseconds. it says so right in the .i3 file. thanks, mark. ======================================================================== 8 === Date: 6 Nov 91 01:21:57 GMT From: ehrlich@bucknell.edu (david ehrlich `92) Subject: Oberon Question I am looking for some sample programs to test an Oberon compiler. If you have any short Oberon sources which are fairly representative of the language, I would appreciate them. I am not able to monitor this newsgroup, so please send them e-mail. Thanks, David ---------------------------------------------------------------------- David Ehrlich | All comments are my own -- subject to Box C-0888 | verification, clarification, reiteration, Bucknell University | and quite possibly, complete denial. Lewisburg, PA 17837 | 717-523-4294 | Ehrlich auf Deutsch == Honest ---------------------------------------------------------------------- ======================================================================== 9 === Date: Thu, 7 Nov 1991 06:03:55 GMT From: luket@michelangelo.ee.adfa.oz.au (Luke Tarantello) Subject: problem accessing supplied libraries... I recently compiled m3 1.6 on a SPARC without any problems other than an inability to access any libraries other than the one in the core directory (libm3core.a is it's name I think). For example, if I import Math into a module the following occurs : m3 -? -o program RealPolar.mo Fourier.io Fourier.mo pass0 = /usr/local/lib/m3/m3compiler pass0 options = defpath = /usr/local/lib/m3/Xaw /usr/local/lib/m3/Xt /usr/local/lib/m3/X11 /usr/ local/lib/m3/io /usr/local/lib/m3/data /usr/local/lib/m3/math /usr/local/lib/m3/ misc /usr/local/lib/m3/ultrix-3-1 /usr/local/lib/m3/core . pass1 = /bin/cc incl = /usr/local/lib/m3 pass1 options = pass2 = /bin/cc pass2 options = pass3 = nm -op pass3 options = lib path = /usr/local/lib/m3/Xaw /usr/local/lib/m3/Xt /usr/local/lib/m3/X11 /usr/local/lib/m3/io /usr/local/lib/m3/data /usr/local/lib/m3/math /usr/local/l ib/m3/misc /usr/local/lib/m3/ultrix-3-1 /usr/local/lib/m3/core interface Math needed but not found Notice that the path (/usr/local/lib/m3/math) is correct and that the syntax check phase finds Math.i3 as it does not complain, but that pass 3 seems to fall over. Should I be setting some compiler switch? Once this problem is solved I will be using the X libraries; will I have to set any compiler switches then? Thanks luke ======================================================================== 10 === Date: Thu, 7 Nov 91 11:40:14 PST From: muller@src.dec.com (Eric Muller) Subject: Re: problem accessing supplied libraries... In article <1991Nov7.060355.17333@sserve.cc.adfa.oz.au>, luket@michelangelo.ee. adfa.oz.au (Luke Tarantello) writes: > I recently compiled m3 1.6 on a SPARC without any problems other than an > inability to access any libraries other than the one in the core directory > (libm3core.a is it's name I think). For example, if I import Math into a > module the following occurs : > > m3 -? -o program RealPolar.mo Fourier.io Fourier.mo > ... > interface Math needed but not found > > Notice that the path (/usr/local/lib/m3/math) is correct and that the > syntax check phase finds Math.i3 as it does not complain, but that pass 3 > seems to fall over. The message "interface Math needed but not found" is indeed a bit confusing. Here is what happens: the driver (hence the compiler) knows about the location of all the source interfaces of all libraries (cf. "defpath = ..."). So the compiler does not complain when compiling "IMPORT Math;". The driver also knows the locations of all the libraries. However, the driver will not link your program will all the libraries as this would be too expensive; you have to explicitly mention the ones you need, using the -l option. The only libraries that will linked automatically in your program are the core library, the "real" math librarie and the "real" C librarie (i.e. there is an implicit -lm3core -lm -lc added to your link command) If you compile with: m3 -o program RealPolar.mo Fourier.io Fourier.mo -lm3math you should be the desired result. The same is true for the X11R4 binding libraries and the X11R4 libraries: you need (some of) the switches: -lm3Xaw -lm3Xt -lm3X11 -lXaw -lXt -lX11 You will also need some -Ldir switches if the Xaw, Xt and X11 libraries are not on the standard search path of ld; e.g.: -lm3Xaw -lm3Xt -lm3X11 -L/usr/lib/X11 -lXaw -lXt -lX11 -- Eric. ======================================================================== 11 === Date: 8 Nov 91 10:15:42 GMT From: usatoday@daimi.aau.dk (Peter Dalsgaard) Subject: Oberon on Amiga ?? Hello ! I know that Oberon exists on the Amiga, but is it an english version, is there more than 1 Oberon compiler for the Amiga ?, and how good is it ?. Any answers will be greatly appreciated -- *** Peter Dalsgaard *** *** usatoday@daimi.aau.dk *** *** University of Aarhus, Denmark *** ======================================================================== 12 === Date: Fri, 8 Nov 91 16:51:19 GMT From: deyhle@peanuts.name.fmi.uni-passau.de Subject: Need help on installation of SRC Modula3 I trie to install SRC Modula-3 1.6 on a SPARC-SUN or a SUN3. Following the installation procedure I copy util/config.dist-SPARC to util/config. I set PREFIX to my home-directory and then call make system. But I allways get an error. So could someone please mail me what s going wrong: > $ make system > --- > --- <<< stuff without errors deleted >>> > --- > --- ultrix-3-1 starting on Fri Nov 8 16:48:50 MET 1991 > ------ os starting on Fri Nov 8 16:48:52 MET 1991 > .ROOT/system/driver/m3.local -D../Interfaces -g -c Unix.i3 > M3 runtime error: Segmentation violation - possible attempt to dereference NIL > Program .ROOT/system/compiler/m3compiler got fatal signal 3. > *** Error code 1 > make: Fatal error: Command failed for target `Unix.io' > Current working directory xxx/Modula-3/dist-1.6/libs/ultrix-3-1/os > .ROOT/util/imake: Exit code 1. Stop. > *** Error code 1 > make: Fatal error: Command failed for target `all' > Current working directory xxx/Modula-3/dist-1.6/libs/ultrix-3-1 > .ROOT/util/imake: Exit code 1. Stop. > *** Error code 1 > make: Fatal error: Command failed for target `all' > Current working directory xxx/Modula-3/dist-1.6/libs > .ROOT/util/imake: Exit code 1. Stop. > *** Error code 1 > make: Fatal error: Command failed for target `system' > $ -- Bernd Deyhle deyhle@peanuts.fmi.uni-passau.de ======================================================================== 13 === Date: 10 Nov 91 15:20:03 GMT From: dme@cl.cam.ac.uk (David Evers) Subject: Re: Need help on installation of SRC Modula3 In article <1991Nov8.165119.25119@forwiss.uni-passau.de> deyhle@peanuts.name.fm i.uni-passau.de writes: > >I trie to install SRC Modula-3 1.6 on a SPARC-SUN or a SUN3. >Following the installation procedure I copy util/config.dist-SPARC >to util/config. I set PREFIX to my home-directory and then call >make system. But I allways get an error. So could someone please >mail me what s going wrong: > >> $ make system >> --- >> --- <<< stuff without errors deleted >>> >> --- >> --- ultrix-3-1 starting on Fri Nov 8 16:48:50 MET 1991 >> ------ os starting on Fri Nov 8 16:48:52 MET 1991 >> .ROOT/system/driver/m3.local -D../Interfaces -g -c Unix.i3 >> M3 runtime error: Segmentation violation - possible attempt to > dereference NIL I've seen what looks like this problem when building dist-1.6 for SPARCs. In my case what had happened was that the `configuration' stage of the build, when architecture-specific diffs are applied to the .mc and .ic files before the bootstrap compile (C->.o), had not been completed. Thus things like the thread support code were using MIPS Ultrix jmpbuf definitions instead of SPARC ones, and when the newly built m3compiler was first run, it segv'd in the Thread module initialisation procedure. It turned out that the reason the `config' phase had not completed was that we had a broken version of /usr/bin/xargs which didn't understand the `-l' option used by the top-level makefile's `config' target. So I just borrowed the sources for a working version from another system, built a working xargs in .ROOT/util, pointed the makefile at that, and it all worked. So: I think that your `config' has failed, and it might be because of a broken xargs. If your logs contain a line like `-l: no such file', then it would seem very likely. ---- Dave [David Evers Janet: dme@uk.ac.cam.cl Computer Laboratory (T76) Inet: dme%cl.cam.ac.uk@nsfnet-relay.ac.uk University of Cambridge UUnet: ...!uunet!mcvax!ukc!cam-cl!dme Corn Exchange Street Cambridge CB2 3QG U.K. Phone: +44 223 334639 ] [David Evers Janet: dme@uk.ac.cam.cl Computer Laboratory (T76) Inet: dme%cl.cam.ac.uk@nsfnet-relay.ac.uk University of Cambridge UUnet: ...!uunet!mcvax!ukc!cam-cl!dme Corn Exchange Street ======================================================================== 14 === Date: Mon, 11 Nov 91 14:36:03 PST From: Pat.Lashley@Eng.Sun.COM (Pat Lashley [MtV NeWStech Eng.]) Subject: :? link-compiler missing? [ Third try - my newsreader crashed twice while trying to post this to [ comp.lang.modula3, so I'm trying mail. Appologies if any of you [ recieve multiple copies. I finally have time and disk space to try to build Modula-3 on my Sun 4/110 (SunOS 4.1.1), but the top-level makefile complains that it doesn't know how to make `link-compile'. A grep through the source tree shows only one other occurrance of the string `link-' and that is in an expression in libs/io/pickles/FastPkl.m3. I recently ftp'd pub/DEC/Modula-3/m3-1.6/dist-1.6.tar.Z from gatekeeper.dec.com, so the release should be up-to-date. Any ideas? -Pat ======================================================================== 15 === Date: 12 Nov 91 10:29:52 GMT From: laverman@cs.rug.nl (Bert Laverman) Subject: Modula-3 opaque types and how to compile them Hello all, Sorry to keep silent so long after causing a (new) thread of discussion. I'm back now, and ready to run. > [From the summary] > The kinds of information that a compiler would like at compile > time, but aren't available until later include: > > 1) offsets of fields & methods > 2) the total size of the object > 3) the default values of the fields & methods > 4) which fields must be traced by the garbage collector > 5) the full inheritance hierarchy It seems to me that 1 and 2 (and sometimes possebly 3) could be solved with a l inker that knows how to resolve expressions containing external values. However, I ca n imagine that e.g. packed types will force even that small task to become possebly compl ex. The offsets of fields and methods are not completely unknown, unless they are . ;-) Let me explain what I try to say: A module that doesn't know the fields in ques tion, because it has neither the declaration, nor a revelation, really doesn't need t heir offsets, since he can't use them anyway. A modula that _does_, knows the fields of one entire inheritance level - I hope. Can you reveal only some fields? some thing like: `This object has these fields, but not necessarily in that order'? - whic h is at least something to start with. When considering multiple inheritance (ouch, ow! stop it! just imagine that you do, you don't have to in reality... ;-)) the idea of a descriptor containing pointers to the start of the different hiearchy levels an d branches comes as natural. Something like that could help here also, were it no t that we have (or rather: don't have) point 5. However, if we think of the descriptor as a record with fields at (yet) unkno wn offsets, it reduces to something comparable to 1. If the storing of values in fields at unknown positions is solved, 3 is not r eally a problem anymore, unless you want to optimize the allocation of new objects. Hmmm, I suppose for every object type some kind of data structure needs to be b uilt to assist with the (a) allocation of a new object, (b) tracing of traceble fiel ds at destruction time. How is this done in SRC-m3? Greetings, Bert -- #include Bert Laverman, Dept. of Computing Science, Groningen University Friendly mail to: laverman@cs.rug.nl The rest to: /dev/null ======================================================================== 16 === Date: 14 Nov 91 18:45:29 GMT From: harbison@bert.pinecreek.com (Sam Harbison) Subject: Pine Creek M3 Library - FieldList Do you wish someone would publish interesting and useful Modula-3 libraries and software? Me, too. So, I am pleased to announce the establishment of the Pine Creek Modula-3 Library and its first module, FieldList. From time to time I will be adding software to this library. The software is available on gatekeeper.dec.com in directory pub/DEC/Modula-3/pinecreek/library. (FYI, the newsletter on-line copy has been mored to directory pinecreek/newsletter.) Here is the release announcement for the first module in the library. I welcome any feedback. THE PINE CREEK MODULA-3 LIBRARY FieldList, v. 1.0 (archived as file fl-1.0.tar.Z) November 13, 1991 Breaks text strings into fields, which can be processed as strings, characters, or numbers (integer and floating-point). Provides a quick and efficient way to parse input lines and allow free-form input of text and numbers. The FieldList interface allows you to declare objects called field lists. You can place a text string into a field list, or read a line into it from a reader, and the text will be divided into whitespace- separated fields. The fields can then be processed in any order, as text or numbers. You can use the same field list many times; each new input line replaces the previous one. INSTALLATION The distribution consists of a single compressed tar file, fl-1.0.tar.Z. To unpack the distribution, type > uncompress -c fl-1.0.tar.Z | tar xvf - This will create a directory named fl-1.0 containing the two library source files (FieldList.i3 and FieldList.m3), two sample programs (Sum.m3 and Test.m3), this README file, a Makefile, and a 7-page document in PostScript format (FieldList.ps). Printed copies of the documentation are available if you cannot print the PostScript file. Send a note to modula3@bert.pinecreek.com. As an example of how FieldList might be used, here is a simple program that reads in two numbers and prints their sum: MODULE Sum EXPORTS Main; IMPORT FieldList, Wr, Stdio, Fmt; PROCEDURE Put(t: TEXT) = BEGIN Wr.PutText(Stdio.stdout, t); END Put; VAR fl := NEW(FieldList.T).init(); BEGIN LOOP Put("Type two numbers: "); fl.getLine(); IF fl.number() # 2 THEN Put("Exactly two, please!\n"); ELSE Put(Fmt.F("The sum of %s and %s is %s\n", fl.text(0), fl.text(1), Fmt.LongReal(fl.real(0) + fl.real(1)))); END; END; END Sum. Here is some sample output from the program: Type two numbers: 3, 56.8 The sum of 3 and 56.8 is 59.8 Enjoy! ======================================================================== 17 === Date: Fri, 15 Nov 91 01:09:18 GMT From: mkh2704@ultb.rit.edu (M.K. Harry) Subject: Compiling Modula3 on SUN 3 While trying to compile the latest version of modula3 retrieved from gatekeeper.dec.com for a SUN 3, I've encountered this error. If anyone has any idea on how to remedy this problem or even how to attempt debugging it, I would greatly appreciate any suggestions. Mike --- ultrix-3-1 starting on Thu Nov 14 19:21:59 EST 1991 ------ os starting on Thu Nov 14 19:22:07 EST 1991 .ROOT/system/driver/m3.local -D../Interfaces -O -c Unix.i3 M3 runtime error: Segmentation violation - possible attempt to dereference NIL Program .ROOT/system/compiler/m3compiler got fatal signal 3. *** Error code 1 make: Fatal error: Command failed for target `Unix.io' Current working directory /usr/local/src/modula3/dist-1.6/libs/ultrix-3-1/os .ROOT/util/imake: Exit code 1. Stop. *** Error code 1 make: Fatal error: Command failed for target `all' Current working directory /usr/local/src/modula3/dist-1.6/libs/ultrix-3-1 .ROOT/util/imake: Exit code 1. Stop. *** Error code 1 make: Fatal error: Command failed for target `all' Current working directory /usr/local/src/modula3/dist-1.6/libs .ROOT/util/imake: Exit code 1. Stop. *** Error code 1 make: Fatal error: Command failed for target `system' ---------------------------------------------------------------------------- mkh2704@ultb.isc.rit.edu OR mikeh@nick.csh.rit.edu ---------------------------------------------------------------------------- ======================================================================== 18 === Date: Thu, 14 Nov 1991 22:42:05 GMT From: mgallo@zeus.calpoly.edu (M. Gallo) Subject: Oberon-2 documentation Many thanks to Pfister@cs.inf.ethz.ch (Cuno Pfister), who just sent me this information. I think others on this news group may be interested. >The new issue of "Structured Programming" should be out now, although >I still haven't seen it. There are mainly two papers in it about Oberon-2: >"The Programming Language Oberon-2" by Hanspeter Moessenboeck and Niklaus >Wirth, and "Differences between Oberon and Oberon-2", by the same authors. >The latter is on pages 175-177, the former on pages 179-195. -- IMHO, as always _ /| Miguel \'o.O' mgallo@ares.calpoly.edu =(___)= "C is its own virus." U ======================================================================== 19 === Date: 18 Nov 91 14:44:30 GMT From: S.A.Taylor@newcastle.ac.uk (Steve Taylor) Subject: Micro/Macro Benchmarking of OOPLs I am attempting to benchmark several OOPLs, including C++, Modula-3, Eiffel, Sather and Simula, in order to assess the impact of different language features and implementation techniques on performance. I will be running a fairly full set of micro-benchmarks to test the performance of individual language constructs, but I also hope to run several macro-benchmarks to test the behaviour of `real' programs. I have obtained the Dhrystone benchmark, but would also like to get hold of some more object-oriented macro-benchmarks. If anyone knows of the existence of such benchmarks or would like to suggest a suitable benchmark, please mail me and I'll summarise to the net. (I am aware of the recent controversy surrounding the Eiffel/C++ benchmark comparison) S.A.Taylor@newcastle.ac.uk ( Steve Taylor ) ======================================================================== 20 === Date: 18 Nov 91 20:25:49 GMT From: chambers@klamath.cs.washington.edu (Craig Chambers) Subject: Re: Micro/Macro Benchmarking of OOPLs As part of the Self language implementation project, we have collected about 20 (relatively small) benchmark programs. We have written versions of these benchmarks in Self, C/C++, Smalltalk-80, T, and (Allegro) Common Lisp. The source code for these benchmarks is freely available via anonymous ftp from self.stanford.edu, in the benchmarks subdirectory. If you port these benchmarks to other languages (M3 and Sather sound like excellent choices, especially since both are freely available on a wide variety of platforms; Eiffel would also be interesting to measure), please let me or someone else in the Self group know so that we can add your versions to our collection. We'd also be interested in adding any new benchmarks you create to our collection. Finally, if you get any interesting performance results, please let me know. I'd also suggest that you get a copy of Self and benchmark it in addition to your other more traditional platforms, if you have access to a Sun-4. You might also want to look at Smalltalk-80. -- Craig Chambers ======================================================================== 21 === Date: 18 Nov 91 01:58:38 GMT From: nr@atomic.Princeton.EDU (Norman Ramsey) Subject: Re: Modula-3 opaque types and how to compile them In <1991Nov12.102952.1022@cs.rug.nl>, Bert Laverman (who would be well advised to format his messages better) writes: > It seems to me that [offsets of fields and methods] could be > solved with a linker that knows how to resolve expressions containing > external values. This is an odd kind of relocation, where the linker has to adjust the size of displacement fields in some instruction. The compiler has to be sure to select an instruction with a displacement field large enough to hold the adjusted value. Perhaps this is a non-problem on modern RISC architectures, which have whopping displacement fields, but perhaps not. In any case, it looks tricky. If you're willing to defer instruction selection until link time, this problem goes away. I don't know what impact that might have on linker performance... ======================================================================== 22 === Date: 18 Nov 91 10:53:28 GMT From: laverman@cs.rug.nl (Bert Laverman) Subject: Generics, why are they in Modula-3? Hi all, Well, this weekend the SPwM3 book arrived. Indeed there are some changes as compared to the language report I found at gatekeeper, but apart from the Generics I haven't been able to find anything remarkable. Those generics... I am a bit disappointed there. My initial impression of Modula-3 was that - by introducing interfaces - import-by-name had at last been conquered: what a module needs from the outside world could be specified in an interface, and how that interface would be met would be an external matter. i.e.: I was expecting to find references to a kind of module interconnection method, that would specify things like: 'This module's imported interface Y will be fulfilled by actual module X', and so on. Appearently this is not the case. Sure, there is a sense of freedom in module composition, but the kind of freedom I expected as being a basic feature... shows up as something special called 'generics'. Components in a library. They export things, they import things. When you build a program, you write the missing parts, and compose your program from library components and newly written ones. Components that use the aspect of an imported interface, are written to be combined with any other component that exports an interface covering the imported interface. In fact; different combinations of components make up new components. This seems to me a natural way of building programs, and I thougth this is the Modula-3 method. Appearently this combinational aspect, choosing from available components, and combining them to create a new component, is what is _introduced_ by generics. This has me confused. Appearently generics are nothing more than a way of getting the module interconnection layout into the language itself. I'm not sure I agree with that. As I argue above, I think the importing and exporting of interfaces im- mediately leads to this compositional approach of building programs. So why introduce generics at all? ? To show that, when importing a certain interface, you are actually importin g a whole hierarchy of modules? - Nah! Can't be, 'cause that is obvious anyway. ? To give some kind of requirements list for the parameter interfaces? - Nope, because there's no word even breathed about specifying requirements to imported interfaces. ? To be able to use the information imported from those parameters? - Not even that. Actually, the book states that an instantiation of a generic interface is equivalent to an interface specification with renamed imports. I can only conclude that Generics in Modula-3 seem to have been introduced to specify just that which I thought the language featured anyway: The ability to write a new component independent of what actual components are going to be used to satisfy its import interface(s). So, the big question becomes: - What can I do with a parameter interface to a generic, that I cannot do with a interface imported in the normal way? Lets run down some possibilities: An interface exports any of the following: 1) constants 2) types 3) variables 4) procedures 1) Constants have a type and a value. To use them, you must be able to use their type. If the type is fixed beforehand, the difference between a generic and a normal interface seems to be ... zilch. (sidestepping the missed oppportunaties for optimization) If their type is imported from the same interface, skip to pt 2. 2) Whew. This seems to be the biggy. If you don't know in advance what a certain type is, you can't do much with it. Actually, what _can_ you do at all with an item of an imported type? For an imported interface, the interface will give a hint, usually either specifying the complete type , or else giving a subtype hint. This pretty much fixes the amount of available activities on items of that type, since the interface gives you all the info you'll ever get or should need. A parameter interface can export types about which we really don't kn ow anything in advance. So what can we do with them: - make/pass/use a reference to that item - tricky since we have to ke ep track of where that reference goes. - do an assignment - all we need is the storage size - pass it as a parameter - again storage size needed. This is pretty much an Ada private type. (sorry ;-)) If we do anything else on it, we are making it impossible to compile th e generic component, since the compiler can't decide if what's happening is valid. Subscription, assignment from or to an item of a known type, de-referencing, etceteraa, etceteraa, etceteraa... You can't say a bloo dy thing about the validity of these actions. You can at most try to check the consistency. If we do want to be able to say something about it, we'll have to introduce subtyping specifications for other types that objects and references. IMHO that is a _very_ interesting subject. See OBJ. 3), 4) I think point (2) describes the issues best, and they also relate to pt s (1), (3), and (4). So, my conclusion would be that Generics in Modula-3 introduce a way of specifying that you can't specify things, and I think some extensions in M3's subtyping features might solve a lot. _Then_ generics don't add anything new anymore, and we can scrap them and go back to business, which I think should be aimed at getting a good Module-interconnection specification method, and maybe (sorry, a hobbyhorse) a limited form of type parameterization. Greetings, Bert -- #include Bert Laverman, Dept. of Computing Science, Groningen University Friendly mail to: laverman@cs.rug.nl The rest to: /dev/null ======================================================================== 23 === Date: 20 Nov 91 08:58:44 From: vixie@decwrl.dec.com (Paul A Vixie) Subject: modula-N (was: generics) some day there will be a modula-oriented language that does not build in the modula-3-style magic of NEW and LOCK and so on. it will be possible to extend the basic language to provide what the syntactic sugar in M3 gives you now. we're getting there. Pascal had writeln() et al that could not be written in the basic language because of the :'s and the variable-length argument lists and so on. M3 finally fixes most of that (though i still miss the ":", i am very happy about "&" and although you can only pass arbitrary- type arguments by REFANY, it's better than M2 or pascal). i think that M3 is a useful language and a neccessary step in the evolution back to cedar :-). i plan to write quite a lot of code in M3 once real (i.e., native) compilers become available. it's quite a decent language and will teach us a lot about what Modula-4 (or whatever) needs to be like. it's also a lot of fun to code in. i spent a week with it recently and then had to go back to C for a fairly large project. very difficult transition. writing large programs in C is like building computer chips by going to the beach with a bucket and bringing some sand back with you. all that said, i basically agree with what was said today about Generics. but even in their present somewhat stilted form, they can help generate more code that is reusable and bug-free, and as such i am glad that they will some day be available. -- Paul Vixie, DEC Network Systems Lab Palo Alto, California, USA "Be neither a conformist or a rebel, decwrl!vixie for they are really the same thing. vixie!paul Find your own path, and stay on it." (me) ======================================================================== 24 === Date: Wed, 20 Nov 91 09:27:23 PST From: Subject: Re: modula-N (was: generics) i think that M3 is a useful language and a neccessary step in the evolution back to cedar :-). ...which was only a necessary step in the evolution back to Algol-68. 8-) --jorge ======================================================================== 25 === Date: Wed, 20 Nov 91 10:22:52 PST From: ehs@src.dec.com (Ed Satterthwaite) Subject: Re: modula-N (was: generics) i think that M3 is a useful language and a necessary step in the evolution back to cedar :-). ...which was only a necessary step in the evolution back to Algol-68. 8-) Much of Mesa and Cedar WAS inspired by Algol 68. It was disguised in Pascal-li ke syntax in an attempt to avoid the incredibly negative PR that seemed to deli ght the Algol 68 designers. Ed ======================================================================== 26 === Date: 20 Nov 91 20:53:06 GMT From: sysessx@gsusgi2.gsu.edu (Eliza Strickler) Subject: Is there Modula3 for Mips R3000 (Irix)? I was wondering if a version of modula3 is out that can be built under the Irix operating system on a Mips R3000 machine? What about Oberon? Any comments would be helpful. -- =============================================================================== = Elizabeth Strickler estrickl@gsu.edu o/ Georgia State University (404) 651-4573 /| stay alive Wells Computer Center / > ======================================================================== 27 === Date: 21 Nov 91 10:39:50 GMT From: laverman@cs.rug.nl (Bert Laverman) Subject: Re: modula-N (was: generics) Paul A Vixie writes: > some day there will be a modula-oriented language that does not build in > the modula-3-style magic of NEW and LOCK and so on. it will be possible > to extend the basic language to provide what the syntactic sugar in M3 > gives you now. How about: PROCEDURE NEW(TYPE t <: REFANY): t = VAR p: t; BEGIN p := LocalAllocate(SizeOf(t)); TypeCodeInit(p); RETURN p END NEW; PROCEDURE TypeCodeInit(p : (TYPE t <: REFANY)); <*RUNTIME-PACKAGE*> TYPE LockAction = PROCEDURE (VAR object : (TYPE t <: MUTEX)); PROCEDURE LOCK(VAR object : (TYPE t <: MUTEX); doit : LockAction); BEGIN Thread.Acquire(object); doit(object); Thread.Release(object) END LOCK; Just some ideas. It is my firm conviction that type parameterization is not necessarily inconveniencing to compiler builders. > [ ... ] > i spent a week with it recently and then > had to go back to C for a fairly large project. very difficult transition. > writing large programs in C is like building computer chips by going to the > beach with a bucket and bringing some sand back with you. Hear, hear! Greetings, Bert -- #include Bert Laverman, Dept. of Computing Science, Groningen University Friendly mail to: laverman@cs.rug.nl The rest to: /dev/null ======================================================================== 28 === Date: Thu, 21 Nov 91 15:12:25 GMT From: vixie@pa.dec.com (Paul Vixie) Subject: Re: modula-N (was: generics) The thing about NEW that I can't code by hand is VAR x := NEW(T, f := 1, m := foo); The thing about LOCK that I can't code by hand is LOCK x DO You can only provide this sort of thing from within the compiler, since neither one follows the syntax of things the programmer is allowed to define: NEW takes variable-magic argument lists, and LOCK has no (parens). -- Paul Vixie, DEC Network Systems Lab Palo Alto, California, USA "Be neither a conformist or a rebel, decwrl!vixie for they are really the same thing. vixie!paul Find your own path, and stay on it." (me) ======================================================================== 29 === Date: Thu, 21 Nov 91 13:21:22 PST From: Pat.Lashley@Eng.Sun.COM (Pat Lashley [MtV NeWStech Eng.]) Subject: Re: modula-N (was: generics) |> The thing about NEW that I can't code by hand is |> |> VAR |> x := NEW(T, f := 1, m := foo); |> |> The thing about LOCK that I can't code by hand is |> |> LOCK x DO |> |> You can only provide this sort of thing from within the compiler, since |> neither one follows the syntax of things the programmer is allowed to |> define: NEW takes variable-magic argument lists, and LOCK has no (parens). What you want is a -real- macro language (not to be confused with cpp or m4.) I worked with several in the early-middle 70's (CMC was probably the best.) They didn't catch on because of the enormous amount of memory they needed - about 500k. I have often considered resurecting CMC now that it would be considered a medium-to-small program.... -Pat ======================================================================== 30 === Date: 22 Nov 91 03:04:37 GMT From: objsys@netcom.COM (Object Systems) Subject: Reference Manual Could someone please repost the address to request the latest Modula-3 Reference Manual. Is this manual on-line? Thanks, Bob Hathaway objsys@netcom.com ======================================================================== 31 === Date: Fri, 22 Nov 91 10:41:35 EST From: wyant@saber.com Subject: modula-N (was: generics) >What you want is a -real- macro language (not to be confused with cpp or >m4.) I worked with several in the early-middle 70's (CMC was probably >the best.) They didn't catch on because of the enormous amount of memory >they needed - about 500k. I have often considered resurecting CMC now >that it would be considered a medium-to-small program.... > >-Pat No, no, no ! You don't want a real-macro processor ! It makes it impossible to write intelligent program analysis tools or do any sort of reasonable incremental compilation. Please don't "fix" the language by adding on additional preprocessors (especially when it ain't particularly broke ;-)) --Geoff Wyant wyant@centerline.com Centerline Software, Inc. (formerly Saber Software, Inc.) ======================================================================== 32 === Date: Fri, 22 Nov 91 08:46:06 PST From: Pat.Lashley@Eng.Sun.COM (Pat Lashley [MtV NeWStech Eng.]) Subject: Re: modula-N (was: generics) |> No, no, no ! You don't want a real-macro processor ! It makes it impossible |> to write intelligent program analysis tools or do any sort of reasonable |> incremental compilation. Please don't "fix" the language by adding on |> additional preprocessors (especially when it ain't particularly broke ;-)) Perhaps I wasn't clear here. I don't think that m3 is broken, nor do I think that it needs any pre-processors. But the original poster was complaining about not being able to write/override certain types of operations that are `baked-in' to the compiler. A good macro processor would solve his problems. I disagree with the contention that such a processor would make it impossible to perform intelligent program analysis. In fact, it might make it easier - you could simply use a slightly different set of expansions to generate the appropriate statistics gathering code. I also object to the assumption that the macro language must be a pre- processor distinct from the language itself. The best results are availiable by integrating the macro capabilities into the language itself - that way the macro language can make tests that wouldn't otherwise be availiable (e.g. check parameter type to implement generics.) In fact, the base language can be much simpler with a good macro processor to impose the higher-level capabilities. Structured programming constructs are usually described in terms of label/goto, and simple conditionals. They could just as easily be described using loop/exit and case/else, and doing so would yield a base more amenable to safe clean optimization and proof-of-correctness. I'll admit that one of the few things I haven't done is write or maintain an incremental compilation environment; but I don't see how building in a good macro processor should significantly complicate the task. -Pat ======================================================================== 33 === Date: Fri, 22 Nov 91 09:20:08 PST From: Subject: Re: Modula-3 opaque types and how to compile them Norman is correct that the linker would need to relocate displacement fields. It's not quite as unusual as he suggests. Many machines have branch or jump instructions with odd sized fields that must be relocated. The hard problem is that the value to be used in the relocation is not simply an external constant. It may be the sum of an unknown number of external constants. For example, consider the following declarations: A.i3: TYPE A <: ROOT; A.m3: REVEAL A = OBJECT a: INTEGER END; B.i3: TYPE B <: ROOT; B.m3: REVEAL B = A OBJECT b: INTEGER END; C.i3: TYPE C = B OBJECT c, d: INTEGER END; The offset to the 'd' field is "sizeof (B) + sizeof (INTEGER)". But, the size of B isn't a simple value, it's "sizeof (A) + sizeof (INTEGER)". This type of relocation isn't particularly complicated. As you noted, it requires that the linker be able to evaluate simple expressions. Unix 'ld' can't do this, probably other linkers can. > Can you reveal only some fields? something > like: `This object has these fields, but not necessarily in that order'? No. > Hmmm, I suppose for every object type some kind of data structure needs > to be built to assist with the (a) allocation of a new object, (b) tracing > of traceble fields at destruction time. > How is this done in SRC-m3? First, the SRC Modula-3 compiler computes a globally unique name for each type. Remember, Modula-3 has structural type equivalence so multiple modules may define the same type. The runtime needs to ensure that the separate declarations are merged to produce a single type. For each object type, the compiler generates a descriptor (a typecell) that contains the following: - size and alignment of the locally defined data fields - number of new methods (i.e. non-overrides) - a pointer to the object's supertype's typecell (using the global names from above) - a procedure to finalize the descriptor (setup) - a procedure to initialize a newly allocated object (init) - a procedure to find the "pointers" in the object (trace) At the beginning of program execution (logical "link time"), the runtime does the following: First, it uses the supertype pointers to link the typecells into a tree that corresponds to the inheritance hierarchy. Then during a preorder traversal of the tree, it assigns typecodes to each typecell. This order guarantees that for each type T, there are a pair of integers FirstChild(T) and LastChild(T) such that (X <: T) iff (FirstChild(T) <= TYPECODE(X) <= LastChild(T)). Hence, we get an O(1) algorithm for implementing the ISSUBTYPE operation. Finally, during a top-down traversal of the tree, the runtime computes the total size and offsets of the data and method fields for each type, allocates space for its method vector, and calls its 'setup' procedure. The setup procedure initializes the type's method vector by copying its supertype's method vector and then adding its own new methods and overrides. When a new object of type T is allocated, the 'init' procedures on the inheritance chain from ROOT to T are called. They initialize the object's fields with its default values. During garbage collection and pickling the 'trace' procedures are called. They locate the traced refs, untraced refs and procedures within an object. The trace procedures make a call-back for each "pointer" they locate. - Bill ======================================================================== 34 === Date: 23 Nov 91 14:54:00 GMT From: moss@cs.umass.edu (Eliot Moss) Subject: macros (was: Re: modula-N (was: generics)) I agree with Geoff Wyant that macro processing at the textual/lexical level, as provided in C and C++, is unstructured and not a very good approach from the standpoint of language design and reliability. Macros as offered in LISP, which operate syntactically rather than lexically are much more attractive. Going beyond that, one can consider adding reflective capabilities to a language. If reflection is allowed at run-time then a complex run-time is required and it is hard constrain program semantics. However, we can consider allowing reflection only at compile-time, as a technique for implementing language extensions and automatic generation of pieces of code that fit standardized patterns. Tim Sheard (formerly of UMass, now of Oregon Graduate Institute) has an article in the latest TOPLAS about structure walking and reduction routines, and he and David Stemple designed the language TRPL (Type Reflective Programming Language) which allows such routine to be constructed via compile-time reflection. I am not proposing that reflection be added to Modula-3, but just trying to make the point that we *can* have disciplined extension mechanisms in languages. -- J. Eliot B. Moss, Assistant Professor Department of Computer Science Lederle Graduate Research Center University of Massachusetts Amherst, MA 01003 (413) 545-4206, 545-1249 (fax); Moss@cs.umass.edu ======================================================================== 35 === Date: 23 Nov 91 20:12:12 GMT From: wilson@cs.utexas.edu (Paul Wilson) Subject: Re: macros (was: Re: modula-N (was: generics)) In article moss@cs.umass.edu writes: >I agree with Geoff Wyant that macro processing at the textual/lexical level, >as provided in C and C++, is unstructured and not a very good approach from >the standpoint of language design and reliability. Macros as offered in LISP, >which operate syntactically rather than lexically are much more attractive. Lisp macros are still pretty ugly--- you get nasty scoping problems and variable capture weirdness. This is because Lisp macros are only syntactic in a very weak sense---they have no real notion of scope. The long-awaited Revised Revised Revised Revised Report on Scheme (R4RS) describes the new high-level macro facility for Scheme. These macros are lexically scoped, like inline procedures, but more general than inline procedures. You can define real control structures with them conveniently. The R4RS is available by anonymous ftp from altdorf.lcs.mit.edu (or is it altdorf.ai.mit.edu? I forget.) >Going beyond that, one can consider adding reflective capabilities to a >language. If reflection is allowed at run-time then a complex run-time is >required and it is hard constrain program semantics. However, we can consider >allowing reflection only at compile-time, as a technique for implementing >language extensions and automatic generation of pieces of code that fit >standardized patterns. Tim Sheard (formerly of UMass, now of Oregon Graduate >Institute) has an article in the latest TOPLAS about structure walking and >reduction routines, and he and David Stemple designed the language TRPL (Type >Reflective Programming Language) which allows such routine to be constructed >via compile-time reflection. I am not proposing that reflection be added to >Modula-3, but just trying to make the point that we *can* have disciplined >extension mechanisms in languages. >-- > J. Eliot B. Moss, Assistant Professor > Department of Computer Science > Lederle Graduate Research Center > University of Massachusetts > Amherst, MA 01003 > (413) 545-4206, 545-1249 (fax); Moss@cs.umass.edu Interesting stuff. One of these days I've gotta figure out the relationships between reflection, macroexpansion, and normal abstraction mechanisms.... (While most Scheme entities are first-class, macros aren't, at least not in the normal direct sense. Like compile-time-only reflection, this lets you have your abstraction and your efficiency too.) -- Paul P.S. For people who don't know about Scheme, it's a lexically-scoped variant of Lisp, that's very elegant and fairly small. I believe that McCarthy has said something to the effect that Scheme is what he would have come up with (instead of Lisp) if he'd read the whole book on the lambda calculus, instead of just the first half. -- | Paul R. Wilson, runtime environmentalist email: wilson@cs.utexas.edu | | U. of Texas Computer Sciences Dept. voice: (512) 471-9555 | | Taylor Hall 2.124, Austin, TX 78712-1188 fax: (512) 471-8885 | "What doesn't kill me makes me stranger" ======================================================================== 36 === Date: 11 Nov 91 19:40:48 GMT From: patl@bodacia.Eng.Sun.COM (Pat Lashley [MtV NeWStech Eng.]) Subject: :? link-compile missing in SUN4 ?? I finally have disk space and time to bring up M3 (1.6) on my Sun 4/110, but I have run into a wierd problem. During the `make system', when it reaches the `(cd compiler; .ROOT/util/m3all link-compiler)' line in the top level makefile, it complains that it doesn't know how to make `link- compile'. Greping through the tree reveals only one other occurrance of `link-', and that one is in an expression in libs/io/pickles/FastPkl.m3. What's going on here? I ftp'd the singel-file version of the distribution from gatekeeper.dec.com just a few days ago. Puzzled, -Pat X-Face: #FowkUVVz[9{ux;7z%!?7>\5DCdVqaja5uk!4Z~)5*f@-"n&||t35?wVN+UloPr-Q;iR\;t snA%,sJ:+$a[eV(aKz4\=`MIH#{`/#HW>TT6Hx=Xp06oj>ta|]bFa'1BiI5Wj_y7n,l)tFuEd(oE`V 3w'0..-`[}nX:VVJ&@Br$cCu|/iqA4VC}/APx:gge9-fj(@V*~W[L@KP@^AcXvel])1%zy[&c}t"\z :X,J8<1D%I;J>tY6EZ7lx,8R&JhgPyZ4Zz[3J`#N@zc&d<"V+&O*;gRd^)xC`34h8[!Vb+ PMLashley plashley@Sun.COM SunSoft:NeWS Tools & Services "I haven't lost my mind -- it's backed up on tape somewhere..." ======================================================================== 37 === Date: 11 Nov 91 21:34:33 GMT From: patl@bodacia.Eng.Sun.COM (Pat Lashley [MtV NeWStech Eng.]) Subject: :? link-compiler missing in SPARC [ Second try - my newsreader died while posting the first one. ] [ My appologies if they both actually make it to the net... ] I finally have time and disk space to attempt a Modula-3 build on my Sun 4/110 (SunOS 4.1.1). The problem is that when the top level makefile reaches the `(cd compiler; .ROOT/util/m3all link-compiler)' line in the `system' target, it complains that it doesn't know how to make link-compile. A quick grep through the distribution reveals that the only other use of the string `link-' is in an expression in libs/io/pickles/FastPkl.m3. I recently ftp'd the single-file distribution from gatekeeper.dec.com, so it should be up-to-date. Any ideas? -Pat X-Face: #FowkUVVz[9{ux;7z%!?7>\5DCdVqaja5uk!4Z~)5*f@-"n&||t35?wVN+UloPr-Q;iR\;t snA%,sJ:+$a[eV(aKz4\=`MIH#{`/#HW>TT6Hx=Xp06oj>ta|]bFa'1BiI5Wj_y7n,l)tFuEd(oE`V 3w'0..-`[}nX:VVJ&@Br$cCu|/iqA4VC}/APx:gge9-fj(@V*~W[L@KP@^AcXvel])1%zy[&c}t"\z :X,J8<1D%I;J>tY6EZ7lx,8R&JhgPyZ4Zz[3J`#N@zc&d<"V+&O*;gRd^)xC`34h8[!Vb+ PMLashley plashley@Sun.COM SunSoft:NeWS Tools & Services "I haven't lost my mind -- it's backed up on tape somewhere..." ======================================================================== 38 === Date: 25 Nov 91 08:43:39 GMT From: laverman@cs.rug.nl (Bert Laverman) Subject: Re: modula-N (was: generics) Paul Vixie) writes: > The thing about NEW that I can't code by hand is > > VAR > x := NEW(T, f := 1, m := foo); Yes, while writing my example I thought of that. Didn't stop me though. ;-) > The thing about LOCK that I can't code by hand is > > LOCK x DO Now _this_ one can be done. M3 knows about parameters with default values, doesn't it? Just make a 'DoNothing' the default. By the by, I wasn't really suggesting the replacement, it's just a way of formalizing the effect of statements. My impression of LOCK was that it is syntactic sugar, in which case it should be possible to give a neat replacement. Hence LOCK(). > You can only provide this sort of thing from within the compiler, since > neither one follows the syntax of things the programmer is allowed to > define: NEW takes variable-magic argument lists, and LOCK has no (parens). And this remark resulted in a lot of talk about macro processors. I don't really like Macro-processors. Their only use seems to be providing syntactic sugar, which shouldn't really be needed in a well thought out language. If the extensions offered are 'in style', and the general opinion is that they are useful, then it would be more logical to put it in the language. If they are not in style, they should be avoided. Look what a preprocessor did to C. It's preprocessor, originally just for getting named constants and an include-file mechanism, has now been put in the language standard. Worse: a C language feature has been defined in terms of preprocessor commands! (enum vs define) I think it's obsolete, since what previously was a tool to extend your programming possibilities, is now a necessary part of the language. Better to put in in with the compiler. As for the 'need' for a macro facility in Modula-3; I don't see it. M3 doesn't need include files, it has interfaces. It doesn't need macro's, it has constants and <*INLINE*> (which is pretty gross in itself, but I suppose useful). It doesn't need code selection, just do your job and modularize (ok, so a little dead-code elimination is useful too). The problem with preprocessors is that they tend to become compilers. If you think you need one, better ask yourself if you're using the right language. Greetings, Bert P.S. I hope nobody thinks I'm in for m3 bashing. I thinks it's the way to go. Seeing everyday programming going to rot thanks to over- enthousiasm for C/C++, I was relieved by finding m3. My bickering over parameterization is a result of personal interest, and the (desparate) need for clearing my head on the subject. Please don't hesitate to disagree. ;-) -- #include Bert Laverman, Dept. of Computing Science, Groningen University Friendly mail to: laverman@cs.rug.nl The rest to: /dev/null ======================================================================== 39 === Date: 25 Nov 91 16:46:34 GMT From: hudson@cs.umass.edu (Rick Hudson) Subject: Typo in Generic example. The grammar on pg 63, says Decl = TYPE {TypeDecl ";"} ^^^ which seems correct. On pg 47 lines 1 and 9 the ";" was dropped. - Rick -- Richard L. Hudson, Research Associate University Computing Services Lederle Graduate Research Center University of Massachusetts Amherst, MA 01003 (413) 545-1220; Hudson@cs.umass.edu ======================================================================== 40 === Date: 26 Nov 91 12:14:39 GMT From: wsbusup4@rwb.urc.tue.nl (Jan Stout) Subject: Re: modula-N (was: generics) vixie@decwrl.dec.com (Paul A Vixie) writes: >some day there will be a modula-oriented language that does not build in >the modula-3-style magic of NEW and LOCK and so on. it will be possible >to extend the basic language to provide what the syntactic sugar in M3 >gives you now. Try Forth for truly orthogonal extension of the basic language... Jan Stout, wsbusup4@urc.tue.nl ======================================================================== 41 === Date: Wed, 27 Nov 91 16:36:11 PST From: muller@src.dec.com (Eric Muller) Subject: Re: Is there Modula3 for Mips R3000 (Irix)? In article , sysessx@gsusgi2.gsu.edu (Eliza Strickler) writes: > I was wondering if a version of modula3 is out > that can be built under the Irix operating > system on a Mips R3000 machine? You may try to use the DS3100 architecture. It may work just out of the box. eric. ======================================================================== 42 === Date: Wed, 27 Nov 91 16:42:46 PST From: muller@src.dec.com (Eric Muller) Subject: Re: :? link-compiler missing in SPARC In article <23108@exodus.Eng.Sun.COM>, patl@bodacia.Eng.Sun.COM (Pat Lashley [M tV NeWStech Eng.]) writes: > [ Second try - my newsreader died while posting the first one. ] > [ My appologies if they both actually make it to the net... ] > > I finally have time and disk space to attempt a Modula-3 build on > my Sun 4/110 (SunOS 4.1.1). The problem is that when the top level > makefile reaches the `(cd compiler; .ROOT/util/m3all link-compiler)' > line in the `system' target, it complains that it doesn't know how > to make link-compile. A quick grep through the distribution reveals > that the only other use of the string `link-' is in an expression in > libs/io/pickles/FastPkl.m3. There a 'link-compiler' target in the file system/compiler/Imakefile. You should verify that this file did not disappear from your system. Eric. ======================================================================== 43 === Date: 27 Nov 91 23:33:08 GMT From: lance@motcsd.csd.mot.com (lance.norskog) Subject: DEC M3 -> NeXT report Last April I did a hack port of DEC Modula-3 version 1.6 to the NeXT workstation running OS 1.0. From my notes: I copied the SUN-3 config file to make the NEXT config. system/corelib/Imakefile does 'library ()' when the library macro needs an argument. I changed it to 'library (junk)'. The IBM R2 port uses the argument, the others don't. system/corelib/runtime/RTHeap.mc has funny RAM allocation: the first time through, it has an out-of-bounds RAM address but all subsequent addresses are OK. (printf time). So, I hacked it so that if an address is bad it allocates another one. Ranlib by default doesn't notice 'constants': what turns up as ' C symbol' in nm listings. Changed ranlib to ranlib -c -s. Above ranlib change inspires annoying messages from /bin/ld. Changed CC rule to /usr/local/bin/m3cc and made a shell script there that does '/bin/cc -w' to get rid of messages. As the Next and the SUN-3 come from the same BSD 4.2/4.3 lineage, and both run on 68000's, it turns out that they are somewhat binary-compatible. SUN-3 apps which only do standard file I/O, like 'cat', run perfectly on the NeXT. So, obviously, you want to put a SUN-3 and the NeXT side by side, build out the SUN-3 port, build out a NeXT port, and test out the pieces one by one. I didn't have a SUN-3. Most everything worked anyway. There were a few oddities in the compiler tools: /lib/cpp doesn't like some files and ld and ranlib have trouble with constants. Sprintf on AT&T is a void, and the Next has AT&T and BSD modes kind of. You always know what sprintf is going to return anyway, so the code that relies on its return value should just Some of the X programs actually worked, too. I was about to recycle my tape from the project, so I figured I'd post my experiences. I'm not interested in Modula-3 any more so I can't be of any assistance. Good luck with M-3, Lance Norskog And get rid of those stupid capitalized keywords. ======================================================================== 44 === Date: Wed, 27 Nov 91 17:46:24 PST From: Pat.Lashley@Eng.Sun.COM (Pat Lashley [MtV NeWStech Eng.]) Subject: Re: :? link-compiler missing in SPARC |> There a 'link-compiler' target in the file system/compiler/Imakefile. |> You should verify that this file did not disappear from your system. There seems to be some sort of mail delay, I found the solution several days before my message actually appeared on the list. I finally re-ftp`d the distribution, and modified a copy of gnugrep to not follow symlinks on a recursive diff. When I compared the two trees I discovered that the only difference was that one of the Imakefiles in the original copy had been truncated. I now have m3 up and running. Thanks all, -Pat