Date: 1 Aug 91 00:13:23 +1200 From: bwc@waikato.ac.nz (Ug!) Subject: Modula-3 Availability Hi, I saw a video about Modula-3 today (sounds suspicously like what the Modula-2 committee is trying to design) from one of the Olivetti people, and I was wondering - is the Olivetti implementation available for public? I know the DEC SRC implementation is - can someone let me know the FTP site address for this please? Thanks, Bruce Cassidy ------------------------------------------------------------------------------ Date: Wed, 31 Jul 91 10:57:06 PDT From: muller@src.dec.com (Eric Muller) Subject: Re: Modula-3 Availability In article <1991Aug1.001323.4508@waikato.ac.nz>, bwc@waikato.ac.nz writes: > I saw a video about Modula-3 today (sounds suspicously like what the Modula-2 > committee is trying to design) from one of the Olivetti people, and I was > wondering - is the Olivetti implementation available for public? I know the > DEC SRC implementation is - can someone let me know the FTP site address for > this please? SRC Modula-3 is available via anonymous ftp from gatekeeper.dec.com in pub/DEC/Modula-3: ftp> ls -lR 200 PORT command successful. 150 Opening ASCII mode data connection for /bin/ls. total 702 -r--r--r-- 1 947 302 May 11 22:44 README dr-xr-xr-x 2 947 512 Jul 7 14:05 comp.lang.modula3 dr-xr-xr-x 2 root 512 Mar 28 09:03 m3-1.6 dr-xr-xr-x 2 root 512 May 11 22:32 m3tk dr-xr-xr-x 2 root 512 Jul 2 11:58 newsletter dr-xr-xr-x 2 947 512 Jan 23 1991 report -r--r--r-- 1 root 700593 Jun 10 20:10 trestle.tar.Z comp.lang.modula3: total 542 -r--r--r-- 1 root 9154 Jul 7 10:48 89-12.Z -r--r--r-- 1 root 41743 Jul 7 10:48 90-01.Z -r--r--r-- 1 root 2256 Jul 7 10:48 90-02.Z -r--r--r-- 1 root 21440 Jul 7 10:48 90-03.Z -r--r--r-- 1 root 32745 Jul 7 10:48 90-04.Z -r--r--r-- 1 root 8887 Jul 7 10:48 90-05.Z -r--r--r-- 1 root 57987 Jul 7 10:48 90-06.Z -r--r--r-- 1 root 32653 Jul 7 10:48 90-07.Z -r--r--r-- 1 root 30358 Jul 7 10:48 90-08.Z -r--r--r-- 1 root 31680 Jul 7 10:48 90-09.Z -r--r--r-- 1 root 18891 Jul 7 10:48 90-10.Z -r--r--r-- 1 root 30292 Jul 7 10:48 90-11.Z -r--r--r-- 1 root 35720 Jul 7 10:48 90-12.Z -r--r--r-- 1 root 26209 Jul 7 10:48 91-01.Z -r--r--r-- 1 root 51772 Jul 7 10:48 91-02.Z -r--r--r-- 1 root 22931 Jul 7 10:48 91-03.Z -r--r--r-- 1 root 52578 Jul 7 10:48 91-04.Z -r--r--r-- 1 root 20443 Jul 7 10:48 91-05.Z -r--r--r-- 1 root 19692 Jul 7 10:48 91-06.Z -r--r--r-- 1 root 138 Jul 7 10:48 README m3-1.6: total 9073 -r--r--r-- 1 root 286 Mar 28 01:41 README -r--r--r-- 1 root 4603137 Mar 28 01:42 dist-1.6.tar.Z -r-xr-xr-x 1 root 524288 Mar 28 01:42 dist-1.6.tar.Z-01 -r-xr-xr-x 1 root 524288 Mar 28 01:42 dist-1.6.tar.Z-02 -r-xr-xr-x 1 root 524288 Mar 28 01:42 dist-1.6.tar.Z-03 -r-xr-xr-x 1 root 524288 Mar 28 01:42 dist-1.6.tar.Z-04 -r-xr-xr-x 1 root 524288 Mar 28 01:42 dist-1.6.tar.Z-05 -r-xr-xr-x 1 root 524288 Mar 28 01:42 dist-1.6.tar.Z-06 -r-xr-xr-x 1 root 524288 Mar 28 01:43 dist-1.6.tar.Z-07 -r-xr-xr-x 1 root 524288 Mar 28 01:43 dist-1.6.tar.Z-08 -r-xr-xr-x 1 root 408833 Mar 28 01:43 dist-1.6.tar.Z-09 m3tk: total 912 -r--r--r-- 1 root 7573 May 10 15:46 README -r--r--r-- 1 root 911833 May 10 15:45 dist-1.0.tar.Z newsletter: total 12 -r--r--r-- 1 root 11335 Jul 1 10:40 issue-1-jun91.txt.Z report: total 264 -r--r--r-- 1 947 191 Jan 15 1991 README -r--r--r-- 1 947 109935 Jan 15 1991 Report.ps.Z -r--r--r-- 1 947 46725 Jan 15 1991 Report1.ps.Z -r--r--r-- 1 947 48956 Jan 15 1991 Report2.ps.Z -r--r--r-- 1 947 49685 Jan 15 1991 Report3.ps.Z 226 Transfer complete. remote: -lR 2762 bytes received in 1.7 seconds (1.6 Kbytes/s) -- Eric. ------------------------------------------------------------------------------ Date: 1 Aug 91 07:26:31 GMT From: lewicki@beach.csulb.edu (Dave Lewicki) Subject: DEC executable sizes A friend and I recently built the DEC modula3 compiler for a sun4. The size of the executable for a "hello world" was rather LARGE: about 1.2 megabytes. Is this normal? Do all mod3 compilers do this? Enquiring minds want to know............. -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- Dave Lewicki | "C++ has a host of operators that will -- lewicki@beach.csulb.edu | be explained if and where needed." -- C.S.U. Long Beach | -- _The C++ Programming Language_. ----------------------------------------------------------------------- ------------------------------------------------------------------------------ Date: Thu, 1 Aug 91 09:34:47 PDT From: muller@src.dec.com (Eric Muller) Subject: Re: DEC executable sizes In article <1991Aug1.072631.4737@beach.csulb.edu>, Dave Lewicki asks: > A friend and I recently built the DEC modula3 compiler for a sun4. > > The size of the executable for a "hello world" was rather LARGE: about > 1.2 megabytes. Is this normal? Unfortunately, yes. Here are a few reasons: - the basic runtime is rather large (threads, gc, types, readers, writers, ...). There is no real point in having light versions of the runtime to make "Hello world" small, if most "useful" programs need the full runtime. - we chose the simplest path and generated extra code to support debugging - I suppose that the system was compiled without optimization. The m3 compiler assumes that the C compiler will do a decent job of optimization and that really simplifies the m3 compiler a lot. I have observed that on a DECstation 5000, the gc runs 1.5 times slower if compiled without optimization; there is probably a similar ratio in code size. > Do all mod3 compilers do this? Yes, but only because there is only one Modula-3 compiler ! The next release should be much better in that respect, as we do more work at link time and so the runtime is smaller. You may try to used shared libraries; this should make your link time and executable size much smaller. -- Eric. ------------------------------------------------------------------------------ Date: Thu, 1 Aug 91 11:08:54 PDT From: mjordan@src.dec.com (Mick Jordan) Subject: Re: Modula-3 Availability The Olivetti implementation is not available any more, since the lab that implemented it was closed. However, the Abstract-Syntax-Tree-based compiler front-end and associated tools lives on, and is available from SRC via gatekeeper. It lives in /pub/DEC/Modula-3/m3tk/dist-1.0. Mick Jordan ------------------------------------------------------------------------------ Date: 5 Aug 91 01:29:57 GMT From: jba@ai.mit.edu (Jonathan Amsterdam) Subject: First comments on M3 I just introduced myself to Modula-3 by reading Systems Programming with Modula-3, edited by Greg Nelson. Excellent book, especially the "rationale" chapter, which consists of several dialogs that cover some of the subtleties of the design. The first one taught me an enormous amount about type identity (structural vs. name equivalence). Until I read it, I thought that name equivalence was the "right" one. Now I'm not so sure. BTW, how much is true in the story about all the meetings being videotaped, and then the videotapes being accidentally erased? After reading the book, I have several questions and comments. Maybe some of you can help. Apologies if I missed something obvious; I only read it through once, normal speed. 1. The definition says that an implementation is free to give a static error for any n in the "BITS n FOR" construct. So this is a completely non-portable construct, even though it's safe. This seems a little extreme. Couldn't it be stipulated that certain values of n (e.g. 1, 2, 4, 8 and 16) must be permitted? Or that instead of giving a static error, an implementation should just ignore "BITS n FOR" and use the representation it normally would for the type? One could could always use BITSIZE to determine the actual allocated space, and abort if the failure to pack would invalidate the program. 2. I'm confused by something Lambdaman says at the top of page 252: "If VAR parameters are required to be passed by reference, then the semantic difference between VAR and VAR OUT vanishes, since the initial value of the parameter is available to the callee, whether he wants it or not." As I understand it, VAR OUT (like OUT in Ada) would mean that you can't read the parameter inside the procedure. This is something the compiler enforces. It's irrelevant how the parameter is passed. You would use VAR OUT not to give the compiler implementor the freedom to choose parameter-passing conventions, but to provide a guarantee that the procedure doesn't read the variable, and hence, e.g., it can be passed in uninitialized. 3. Why is there no UNION type? Most of the machinery is there, to deal with REFANY. What is significantly harder or more complex about stack-based unions? A couple of negative comments: 4. It's pretty annoying that I have to write something like Stack.T all the time, instead of calling the type "stack". It also makes it harder to read the procedures of the Stack interface and module; one is constantly encountering this uninformative "T" and having to remember that it's a stack. My usual convention when I wrote Modula-2 was to call the module "Stack" and the type "stack". Of course, I could still do that, but it would run afoul of the (in my opinion overly simple) generic feature, because in a generic declaration only interface names, not type names, are bound variables. It's strange that this doesn't bother me at all for procedure names--I don't mind having to call all my hash procedures "hash"--but it does bother me for type names. 5. The support for formatted output is very weak. In order to write printf("Evaluating %d %s %d yields %d\n", i1, "+", i2, i1+i2); in Modula-3, about the best I can do is Wr.PutText(stdout, Fmt.F("Evaluating %s %s %s yields %s\n", Fmt.Int(i1), "+", Fmt.Int(i2), Fmt.Int(i1+i2))) which is not only ghastly-looking and verbose, but also conses (i.e. heap-allocates) four TEXTs. Again, apologies if I missed something, but it strikes me as odd to say the least that a language which goes out of its way to accomodate stack allocation should fail to provide a way to write an integer without consing! Is this really perceived as unnecessary? I think people assume that getting a syntax as nice as printf's requires giving up something important, like type safety, but this doesn't seem to me to be true. Here's a suggestion for a variable-number-of-arguments feature that requires little more than open arrays: if the last formal of a procedure signature is "REST F: ARRAY OF T" (where REST is a new keyword that can only be used in this context), then a call to the procedure can take any number of arguments. All the "extra" ones at the end must be of type T, and are placed into F. E.g. if we had PROCEDURE List(REST els: ARRAY OF Elem.T): List.T = ... Then L := List(1, 2, 3) is essentially sugar for temp := ARRAY OF Elem.T {1, 2, 3}; L := List'(temp) where temp is a fresh variable and List' is like List but with REST omitted. I've never seen this proposal before, so I'd appreciate knowing if any language uses it, or if there are severe problems with it that I've overlooked. (There might be subtleties involved in mixing positional, keyword and REST arguments, but Lisp has a solution so I don't believe the problem is serious.) Anyway, given this and union types, you can write printf: TYPE BasicTypes = TEXT | INTEGER | BOOLEAN | CHAR | REAL (* etc. *) PROCEDURE Printf(format: Text; REST args: ARRAY OF BasicTypes) = ... TYPECASE args[i] OF (* if TYPECASE were extended to unions *) ... Of course, this is much better than C's printf, because you can't get screwed by passing too few arguments or arguments of a type that doesn't match the format specifier. Jonathan Amsterdam ------------------------------------------------------------------------------ Date: Mon, 5 Aug 91 11:17:33 PDT From: Subject: Re: First comments on M3 A few comments on REST, unions, and printf: One nagging problem with &REST in Lisp was whether the list was consed every time. One camp wanted to be able to write (defun list (&rest l) l) and other, less canonical variations, like storing the rest-list somewhere. The other camp wanted the rest-list to be "private" storage, so that it could be stack-allocated. Symbolics Common Lisp, for example, was in the second camp, and several of our programs broke when we ported them to Symbolics machines -- and in a fairly obscure manner until we knew what to look for. Eventually the first camp won, but I'm sure the argument will resurface in Modula 3. One difference is that the elements of the rest-array would all have to be of the same type, which makes it less useful than the rest-lists of Lisp. I'm sure the language designers will have something to say about unions (I'm also new to M3), but feel that once you define a union like your BasicTypes that includes refs and "immediates" like booleans and integers, you might as well just call it Atom and admit that you'll spend many of your runtime cycles doing type-checks. I don't think that's in the spirit of Modula 3. If that's what you want, you should stick with Lisp, which has a much fancier object system anyway. I write programs in both languages, and it's usually pretty clear which language to choose. Finally, I agree that the 'printf' situation is awkward, but your solution requires both rest-arrays and unions. As you point out, Fmt.F already provides rest-arrays (up to length 5!) where all the elements are TEXTs, but there's nothing available for mixed-type argument-lists. In an in-house version of Modula-2, there's a "special form" called PRINTF that takes a format string and an arbitrary number of arguments, of any type. The format string must be constant, so that the compiler can check both the number of arguments and their types. It's sugar, but it's the right sort of sugar, since it allows type-checking at compile-time but doesn't require excessive consing at runtime. I don't know why it wasn't included in M3. (Gee, if they'd just given us macros, we wouldn't have to bother them about this other stuff :-) ------------------------------------------------------------------------------ Date: Mon, 5 Aug 91 13:33:30 PDT From: Subject: Re: First comments on M3 Thank you for your comments. Here are some brief responses to the points that you raise. BTW, how much is true in the story about all the meetings being videotaped, and then the videotapes being accidentally erased? The story is pure myth. 1. The definition says that an implementation is free to give a static error for any n in the "BITS n FOR" construct.... This seems a little extreme. Couldn't it be stipulated that certain values of n (e.g. 1, 2, 4, 8 and 16) must be permitted? Or that instead of giving a static error, an implementation should just ignore "BITS n FOR" and use the representation it normally would for the type? The legality of a packed type depends on its context --- for example, an implementation might prohibit packed types from spanning word boundaries. Therefore we can't choose a set of sizes that must be supported for every type, even if we were willing to add the bulk to the language specification. One of the essential uses of packed types is in declaring a record that must match the format required by some IO device. If the compiler can't support the required format, it would be most disastrous for it to substitute the standard format silently. 2. I'm confused by something Lambdaman says at the top of page 252: "If VAR parameters are required to be passed by reference, then the semantic difference between VAR and VAR OUT vanishes, since the initial value of the parameter is available to the callee, whether he wants it or not." As I understand it, VAR OUT (like OUT in Ada) would mean that you can't read the parameter inside the procedure. Unfortuantely the discussion in section 8.4 about VAR OUT failed to make clear that the VAR OUT proposed for M3 was different from the Ada VAR OUT: unlike in Ada, it would not be a static error for the procedure to read the variable, since this is perfectly harmless if the procedure has initialized the variable before reading it, and it seems odd for the type system to protect against the error of reading before initializing in the case of OUT parameters but not in the case of ordinary local variables. Sorry about the confusion. 3. Why is there no UNION type? Most of the machinery is there, to deal with REFANY. What is significantly harder or more complex about stack-based unions? Are your UNION types mutable? If so it is quite tricky to make them safe. E.g., consider TYPE Arith = INTEGER | REAL; PROCEDURE P(VAR x, y: Arith) = BEGIN TYPECASE x OF INTEGER (i) => y := 2.0; i := i + 1 | ... At first this looks fine, but it fact type safety requires that it be forbidden, because x and y could be aliased. Allowing UNIONS only for READONLY parameters is all that can be salvaged, and this seems like a rather feeble design. 4. It's pretty annoying that I have to write something like Stack.T all the time, instead of calling the type "stack". It also makes it harder to read the procedures of the Stack interface and module; one is constantly encountering this uninformative "T" and having to remember that it's a stack. My usual convention when I wrote Modula-2 was to call the module "Stack" and the type "stack". Nothing in the M3 language requires that you name the type Stack.T instead of Stack.stack; it's just the style used at SRC. By the way the ".T" convention came in here about six years ago and at first was resisted by programmers who preferred "Stacks.Stack", as one of those who resisted I can testify that I eventually found the new convention to be preferable since it avoids the labored redundancy of "Stacks.Stack" (and your "Stacks.stack"). If you find "T" uninformative as the type of a parameter in the Stack interface, you can IMPORT Stack at the beginning of the interface and then give the type as Stack.T. 5. The support for formatted output is very weak. In order to write printf("Evaluating %d %s %d yields %d\n", i1, "+", i2, i1+i2); in Modula-3, about the best I can do is Wr.PutText(stdout, Fmt.F("Evaluating %s %s %s yields %s\n", Fmt.Int(i1), "+", Fmt.Int(i2), Fmt.Int(i1+i2))) The length of your M3 version comes from two sources: (1) the three occurrences of "Fmt.Int", and (2) the extra length of "Wr.PutText(stdout, " versus "printf". As for the second, if you want an output routine like "printf" that defaults the stream to standard output, you can easily define it in Modula-3. (Sam Harbison has a proposed standard interface for this.) Then the M3 version would be printf("Evaluating %d %s %d yields %d\n", Fmt.Int(i1), "+", Fmt.Int(i2), Fmt.Int(i1+i2)) As for the Fmt.Int's, you observe correctly that they could be eliminated by adding union types, but as I argued above, this has serious problems. It is true that using Fmt.Int is not very efficient. On the other hand when efficiency is important, the version with union types is not that attractive, either. When efficiency is important, you should use the routines in Wr or (if efficiency is very important) those in UnsafeWr. This is not all that different from the C world, where programmers go below the level of printf to achieve maximum speed. You also suggest the REST keyword for allowing multiple arguments; but in most cases default parameters can be used to provide the same convenience (this is the way Fmt.F works). When default parameters aren't suitable, you can use an explicit array constructor in the call. ------------------------------------------------------------------------------ Date: Mon, 5 Aug 91 16:55:52 EDT From: jba@ai.mit.edu (Jonathan Amsterdam) Subject: First comments on M3 One nagging problem with &REST in Lisp was whether the list was consed every time. One camp wanted to be able to write (defun list (&rest l) l) and other, less canonical variations, like storing the rest-list somewhere. The other camp wanted the rest-list to be "private" storage, so that it could be stack-allocated. Symbolics Common Lisp, for example, was in the second camp, and several of our programs broke when we ported them to Symbolics machines -- and in a fairly obscure manner until we knew what to look for. Yes, I've been bitten by this problem too. But I don't think it comes up in M3. The rest array would be placed on the stack and passed just like any other open array. One difference is that the elements of the rest-array would all have to be of the same type, which makes it less useful than the rest-lists of Lisp. Right, that's where union types come in. In an in-house version of Modula-2, there's a "special form" called PRINTF that takes a format string and an arbitrary number of arguments, of any type. The format string must be constant, so that the compiler can check both the number of arguments and their types. It's sugar, but it's the right sort of sugar, since it allows type-checking at compile-time but doesn't require excessive consing at runtime. I don't know why it wasn't included in M3. I neglected to mention this other solution, the special-case hack. The problem, aside from its being a special-case hack, is that it doesn't let you define your own printf-like functions. For instance, I have a C function "fatal" that I use in every C program I write. It just writes a message to the standard error and dies, and like printf it takes a format string followed by arbitrary args. As I say, I use this (and similar things) all the time. (Gee, if they'd just given us macros, we wouldn't have to bother them about this other stuff :-) I couldn't agree more. If I ever program in M3, you can bet I'll be running my code through cpp or M4 first. ------------------------------------------------------------------------------ Date: Mon, 5 Aug 91 17:27:20 EDT From: jba@ai.mit.edu (Jonathan Amsterdam) Subject: First comments on M3 One of the essential uses of packed types is in declaring a record that must match the format required by some IO device. If the compiler can't support the required format, it would be most disastrous for it to substitute the standard format silently. True, but another use of packed types is just a hint to the compiler that you're willing to save space at the expense of time. In this case you would be willing to have the compiler ignore you. In the case you bring up, you could use BITSIZE and other low-level operations to ensure that the formats matched. Are your UNION types mutable? If so it is quite tricky to make them safe. E.g., consider TYPE Arith = INTEGER | REAL; PROCEDURE P(VAR x, y: Arith) = BEGIN TYPECASE x OF INTEGER (i) => y := 2.0; i := i + 1 | ... At first this looks fine, but it fact type safety requires that it be forbidden, because x and y could be aliased. Allowing UNIONS only for READONLY parameters is all that can be salvaged, and this seems like a rather feeble design. Good point! I'll think more about it. It's examples like this that made chapter 8 so wonderful. You (or someone) should consider writing a whole book of dialogs about language design. ...I can testify that I eventually found the new convention to be preferable since it avoids the labored redundancy of "Stacks.Stack" (and your "Stacks.stack"). No, I would aways do "FROM Stack IMPORT stack" so there was no redundancy. I would argue that it's the generic facility that makes the convention strongly preferable. You also suggest the REST keyword for allowing multiple arguments; but in most cases default parameters can be used to provide the same convenience (this is the way Fmt.F works). When default parameters aren't suitable, you can use an explicit array constructor in the call. I guess in this point and the previous one we are arguing syntax niceties. Yes, you can use default parameters, but then you have to have some arbitrary maximum. Yes, you can use array constructors, but they're cumbersome. I suppose it's just that, coming from Lisp, I'm in the habit of using RESTs frequently. I agree that if language simplicity is one of the primary design goals, rest arguments can be omitted with little loss. ------------------------------------------------------------------------------ Date: 6 Aug 91 17:16:31 GMT From: figueroa@SPUNKY.CS.NYU.EDU (Samuel A. Figueroa) Subject: re: First comments on M3 In a previous message dated 5 Aug 91 01:29:57 GMT, jba@ai.mit.edu (Jonathan Amsterdam) writes: 5. The support for formatted output is very weak. In order to write printf("Evaluating %d %s %d yields %d\n", i1, "+", i2, i1+i2); in Modula-3, about the best I can do is Wr.PutText(stdout, Fmt.F("Evaluating %s %s %s yields %s\n", Fmt.Int(i1), "+", Fmt.Int(i2), Fmt.Int(i1+i2))) which is not only ghastly-looking and verbose, but also conses (i.e. heap-allocates) four TEXTs. I am certainly not an expert on programming languages, and I know very little about Modula-3, but I'd like to offer a suggestion which everyone is free to ignore if it doesn't make sense. Suppose printf were an overloaded procedure (I seem to remember overloading is allowed in Modula-3) accepting one argument, which could be a string, an integer, a character, etc. Let the following: printf("Evaluating "; i1; " + "; i2; " yields "; i1+i2; "\n"); be syntactic shorthand for: printf("Evaluating "); printf(i1); printf(" + "); printf(i2); printf(" yields "); printf(i1+i2); printf("\n"); Could this possibly be a solution for the problem(s) mentioned above? Samuel Figueroa ------------------------------------------------------------------------------ Date: Wed, 7 Aug 1991 01:12:41 GMT From: ramsey@parc.xerox.com (Norman Ramsey) Subject: Semantics of Scan.Int and its friends Since Scan.Int provides no way to inform a caller how many characters were actually consumed, I claim it should raise BadFormat unless ALL the characters are consumed. This means I believe the test IF used = 0 THEN in the implementation should be replaced with something like IF used # Text.Length(t) THEN so that "99q" for example does not correctly scan to an integer. Similarly for the other procedures in the interface. Oddly enough, Scan.Bool already has the correct semantics: Scan.Bool("TRUE ENOUGH") raises BadFormat. Comments? -- Norman Ramsey nr@princeton.edu [temporarily ramsey@parc.xerox.com, but mail to princeton] ------------------------------------------------------------------------------ Date: 6 Aug 91 14:34:18 GMT From: jnv@cl.cam.ac.uk (Neil Viljoen) Subject: How efficient is M3 code generated ----------- If an algorithm is coded in M3 and in C. How would the run speed of the two compare. This is for the compilers (DEC, Olivetti) available at present. Thanks for all comments. ------------------------------------------------------------------------------ Neil Viljoen | Tel: +44-223-334688 Univ. of Cambridge | Fax: +44-223-334678 Computer Laboratory | Pembroke Street | Email: jnv@cl.cam.ac.uk Cambridge CB2 3QG | England | ------------------------------------------------------------------------------ Date: 7 Aug 91 19:11:10 GMT From: jba@ai.mit.edu (Jonathan Amsterdam) Subject: Re: First comments on M3 Let the following: printf("Evaluating "; i1; " + "; i2; " yields "; i1+i2; "\n"); be syntactic shorthand for: printf("Evaluating "); printf(i1); printf(" + "); printf(i2); printf(" yields "); printf(i1+i2); printf("\n"); Could this possibly be a solution for the problem(s) mentioned above? Yes, except that Modula-3 doesn't have overloading. The other problem is that it's unclear how to handle arguments before the "rest" argument. For instance, you would like fprintf(file, a, b) to expand into fprintf(file, a); fprintf(file, b) but it's not clear how your proposal could handle that. ------------------------------------------------------------------------------ Date: 7 Aug 91 19:18:48 GMT From: jba@ai.mit.edu (Jonathan Amsterdam) Subject: Re: First comments on M3 Are your UNION types mutable? If so it is quite tricky to make them safe. E.g., consider TYPE Arith = INTEGER | REAL; PROCEDURE P(VAR x, y: Arith) = BEGIN TYPECASE x OF INTEGER (i) => y := 2.0; i := i + 1 | ... At first this looks fine, but it fact type safety requires that it be forbidden, because x and y could be aliased. Allowing UNIONS only for READONLY parameters is all that can be salvaged, and this seems like a rather feeble design. OK, here's my idea: think of TYPECASE for unions as having only the function of dispatching on the type of x. There is no assurance about the type of x inside an arm of the typecase in general. (Of course, there is a guarantee if no code in the arm could change the type.) The parenthesized variables are eliminated, and the compiler has to generate runtime checks when the union is read, just as it would in code outside of a typecase. The above example would check statically and fail at runtime. My guess is that most real code could be compiled without type checks, i.e. could be verified statically. ------------------------------------------------------------------------------ Date: 8 Aug 91 17:00:08 GMT From: braeu@untadc.enet.dec.com (Walter Braeu) Subject: Re System Prog in Modula-3 appears Walter Braeu walter.braeu@unt.mts.dec.com ------------------------------------------------------------------------------ Date: 8 Aug 91 19:38:18 GMT From: braeu@untadc.enet.dec.com (Walter Braeu) Subject: Re System prog in Modula-3 appears On 25-MAY-1991, Sam Harbison wrote: >I just received 50 copies of Systems Programming with Modula-3, edited >by Greg Nelson. It looks great. Congrats to Greg and the other >contributors. > >It's in the Prentice Hall Series in Innovative Technology. Price is >$25.00, softcover, approx. 275 pages. ISBN 0-13-590464-1. >Startbugging your bookstores. ... >Contact me if you have trouble getting a copy. > >Sam Harbison >Pine Creek Software; 305 S. Craig St., Suite 300; Pittsburgh, PA 15213 >+1 412 681 9811; harbison@bert.pinecreek.com I ordered the book 10 weeks ago from a local german bookstore. Now, after I asked them several times, they told me the following: They have to order the book from Prentice Hall UK, they cannot order from Prentice Hall US. Prentice Hall UK told them that the book has not been published yet. From recent notes in this conference I conclude that there are people who already bought this book, but probably all of them in US. Is this book available outside US, too? It's hard enough for us Europeans that american books are much more expensive here, it need not be that we have to wait ten weeks to get them :-( Does anybody know whether it's possible for an individual to order the book directly from Prentice Hall US? Does anybody have the address? Thanks, Walter Walter Braeu walter.braeu@unt.mts.dec.com ------------------------------------------------------------------------------ Date: 8 Aug 91 12:54:42 GMT From: moss@cs.umass.edu (Eliot Moss) Subject: Re: First comments on M3 The variables introduced in the case arms of your TYPECASE over a UNION type could be *copies* of the original data. This gets around the aliasing problem and in most cases of interest probably does not add significant overhead. However, some time ago I proposed a different solution to the whole issue. I suggested introducing a type ANY that can be used only as a type of a formal parameter. A parameter of known type could be passed by reference (copying first if it is to be passed by value) and a typecode added, perhaps as an additional implicit argument. An ANY can be passed in another call requiring an ANY, but that's about all you can do with it other than TYPECASE on it. Unlike UNION, you can't change the type via assignment, so this is safe, even for update in a case arm. The proposal is essentially to allow limited REFANYs that point into the stack; limited analogously to open array rules, so that we do not get dangling references into the stack. I'd be interested in hearing any problems with this proposal; I think it works and the only obstacle to its adoption is the extra bulk added to the language. The other thing you need for printf, of course, is a variable number of arguments. But we can simulate that reasonably well with defaults, and even pass arguments down multiple levels. It's not as nice as a true variable length argument list, but it's not horrible for the user. -- 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 ------------------------------------------------------------------------------ Date: 8 Aug 91 16:33:44 GMT From: e_splett@trofs.enet.dec.com (EVAN SPLETT) Subject: Re: Re System prog in Modula-3 appears >book from Prentice Hall UK, they cannot order from Prentice Hall US. Prentice >Hall UK told them that the book has not been published yet. I have had the same problem with Prentice Hall Canada. If a book is available in the U.S., but not yet in stock in Canada (no one has ordered it yet), their computer system lists it as "NOT YET PUBLISHED" . You need to pay them in advance, and get them to order it from the U.S. . A contact for Prentice Hall U.K. is Jackie Dent, phone 44-442-231555. >weeks to get them :-( Does anybody know whether it's possible for an >individual to order the book directly from Prentice Hall US? Does anybody hav e Prentice Hall will not let you order a text from the U.S. if you are in another country. ------------------------------------------------------------------------------ Evan Splett Digital Equipment of Canada Ltd. email e_splett@kaofs.enet.dec.com ------------------------------------------------------------------------------ ------------------------------------------------------------------------------ Date: 8 Aug 91 20:28:01 GMT From: harbison@bert.pinecreek.com (Sam Harbison) Subject: 2nd Int'l Modula-2 Conference, UK For those who may have missed the announcements, the 2nd Int'l Modula-2 Conference ("Modula-2 and Beyond") will be held at Loughborough University of Technology UK September 10-13, 1991. Of interest to Modula-3 people: Greg Nelson of DEC will give an invited paper titled "Modula-3" on 9/12, and I will be there all week with a Modula-3 display, literature, a few copies of Greg's book, and a manuscript of my forthcoming book, "Modula-3". If there is interest and space available, I would be happy to preview (well, "debug" acutally) my OOPSLA '91 tutorial, "Object Oriented Programming in Modula-3". For registration info, contact Ms. Deborah Walker, Secretariat, Modula-2 Conference, Center for Extension Studies, Loughborough Univ. of Technology, Loughborough, Leicestershire LE11 3TU, United Kingdom. Phone (0) 509 222174, Fax (0) 509 610361. 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. ------------------------------------------------------------------------------ Date: Thu, 8 Aug 1991 21:13:01 GMT From: ramsey@parc.xerox.com (Norman Ramsey) Subject: Experience with Pkl? I'm having some difficulties using Pkl to store copies of complex linked data structures. The symptom I'm able to provoke most often is that the contents of a TEXT get mangled, as in the example below. Are there any other users of Pkl out there? If so, I'd like to here from you. Norman Ramsey Example: This is a symbol table entry for a procedure, before pickling, printed as a list of key-value pairs: operand stack = [ /kind (procedure) /printer { FUNCTION } /formals (*dictionary*) /type (int %s(int, char **)) /statics (*dictionary*) /loci (*dictionary*) /address [ (__stabadr__V28a1aaf2_3ee52) 12 ] /name (main) /returntype (int) /ncalls 5 ] I pickled the entire symbol table of which this entry is a part. After unpickling, I extracted the symbol table entry for the same procedure, but the key `/type' has been changed to `/x,': operand stack = [ /kind (procedure) /printer { FUNCTION } /formals (*dictionary*) /x, (int %s(int, char **)) /statics (*dictionary*) /loci (*dictionary*) /address [ (__stabadr__V28a1aaf2_3ee52) 12 ] /name (main) /returntype (int) /ncalls 5 ] I'm unable to find a small example for which this problem occurs, but I've experienced similar problems on two different systems: SPARC and DS3100. In the (few) cases I've observed, it's always been a TEXT that gets mutated, never anything else. Anybody else out there using Pkl? -- Norman Ramsey nr@princeton.edu [temporarily ramsey@parc.xerox.com, but mail to princeton] ------------------------------------------------------------------------------ Date: 8 Aug 91 21:56:54 GMT From: lins@Apple.COM (Chuck Lins ) Subject: Re: First comments on M3 Pardon me if someone has already suggested this. But why not have a preprocessor to expand printf("Evaluating "; i1; " + "; i2; " yields "; i1+i2; "\n"); to the equivalent printf("Evaluating "); printf(i1); printf(" + "); printf(i2); printf(" yields "); printf(i1+i2); printf("\n"); . This could also deal with expanding fprintf(file, a, b) to fprintf(file, a); fprintf(file, b) . This avoids adding language features and yet seems to me provides a simple but effective solution. (I always wondered why this was never done for Modula-2 either.) Of course, it may be possible to argue that the Modula-3 compiler is really a fancy preprocessor for C anyway and it's silly to add yet another preprocessor (YAPP :-) Yet more random silly thoughts from the mindless fingers of Chuck Lins. -- Chuck Lins | "Shut up! Be happy!" -- Jello Biafra Apple Computer, Inc. | Looking for RISC Oberon compiler job. 20525 Mariani Avenue | Resume available on request. Mail Stop 58-C | Internet: lins@apple.com Cupertino, CA 95014 | ------------------------------------------------------------------------------ Date: 6 Aug 91 13:43:33 EST From: thomas@qut.edu.au Subject: Importing style (was Re: First comments on M3) > ...I can testify that I eventually found the new convention > to be preferable since it avoids the labored redundancy of > "Stacks.Stack" (and your "Stacks.stack"). > > No, I would aways do "FROM Stack IMPORT stack" so there was no redundancy. > I would argue that it's the generic facility that makes the convention > strongly preferable. Just a quick comment on programming style here. I have been using Modula-2 from just about immediately after its release and have used it for a few large projects. For programming in the large where you have many libraries and import many libraries into one module I have found the DEC SRC style to be much more useful and readable. In my software engineering class I actually force my students to use the DEC style of IMPORT Stack, and use Stack.T (or Stack.Type) and Stack.Push. This eliminates the worry of name clashes and also makes it much easier to at a glance determine where a routine, or identifier comes from. Au revoir, @~~Richard Thomas aka. The AppleByter -- The Misplaced Canadian~~~~@ { AARNet: richard@water.fit.qut.edu.au InterNet: R.Thomas@qut.edu.au } { PSI: PSI%505272223015::R.Thomas } @~~School of Computing Science - Queensland University of Technology~~@ ------------------------------------------------------------------------------ Date: 9 Aug 91 20:05:04 GMT From: harbison@bert.pinecreek.com (Sam Harbison) Subject: Should Thread.Release(m) cause a run-time error? When thread t calls Thread.Release(m), the commentary (SPWM3, p. 70) and formal spec (p. 123) says "t must hold m". Is it a checked run-time error if it does not? The SRC 1.6 implementation does not check the precondition. More generally, doe the words "P must hold" (for some predicate P, and not in UNSAFE code) a key phrase that always identify a checked error (static or run-time)? Sometimes the phrase "it is a checked runtime error if P does not hold" appears, and sometimes it does not. The language lawyers thank you... 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. ------------------------------------------------------------------------------ Date: Fri, 9 Aug 91 14:54:53 PDT From: Subject: Re: Should Thread.Release(m) cause a run-time error? Sam Harbison asks whether Thread.Release(m) should cause a run-time error. One could argue that the Thread module should check that the thread calling Thread.Release(m) actually holds m, but the failure of the current Thread module to do so is consistent with the spec, since A REQUIRES clause states a precondition that the implementation may rely on ... The specification does not constrain the implementation to any particular behavior if the precondition is not satisfied. (SPWM3, p. 123.) Larch M3 includes a specific construct (CHECKEDRTE) which can be used to specify the conditions under which the implementation is required to produce a checked runtime error. (See Kevin Jones' report, SRC72). ------------------------------------------------------------------------------ Date: 12 Aug 91 10:59:31 GMT From: hofstede@utis04.cs.utwente.nl (Jaap Hofstede) Subject: Re: Semantics of Scan.Int and its friends ramsey@parc.xerox.com (Norman Ramsey) writes: > Since Scan.Int provides no way to inform a caller how many characters > were actually consumed, I claim it should raise BadFormat unless ALL > the characters are consumed. This means I believe the test > IF used = 0 THEN > in the implementation should be replaced with something like > IF used # Text.Length(t) THEN > so that "99q" for example does not correctly scan to an integer. > Similarly for the other procedures in the interface. > ..... I think it is not a question of correct or incorrect. In some applications you prefer something like "99q" to be a BadFormat, but in others, e.g. with calculator-like input such as "99+123" or for the input of a list of resistor values like "33 47k 10M", you certainly will not appreciate a BadFormat. Personally I do not agree with Norman's preference, because it is much easier to detect "99q" to be incorrect input if BadFormat is not raised, than it is to input "99+123" or "33 47k 10M" correctly when BadFormat is raised. Jaap Hofstede, University of Twente (INF/SPA), Netherlands. hofstede@cs.utwente.nl ------------------------------------------------------------------------------ Date: Tue, 13 Aug 1991 00:02:42 GMT From: ramsey@parc.xerox.com (Norman Ramsey) Subject: Re: Semantics of Scan.Int and its friends In article <1991Aug12.105931.25518@cs.utwente.nl> hofstede@utis04.cs.utwente.nl (Jaap Hofstede) writes: >ramsey@parc.xerox.com (Norman Ramsey) writes: >> Since Scan.Int provides no way to inform a caller how many characters >> were actually consumed, I claim it should raise BadFormat unless ALL >> the characters are consumed... >> so that "99q" for example does not correctly scan to an integer. > >I think it is not a question of correct or incorrect. In some applications >you prefer something like "99q" to be a BadFormat, but in others, e.g. >with calculator-like input such as "99+123" or for the input of a list >of resistor values like "33 47k 10M", you certainly will not appreciate >a BadFormat. In the examples you cite, the Scan interface is useless, because it does not tell you how many characters have been consumed. Even if BadFormat is not raised, you cannot make progress without scanning the string yourself (or getting the Convert) interface to do it for you. If you want to validate the input (detect "99q" to be incorrect), the Scan interface is also useless. In short, Scan.Int seems to be useful only for finding the ``integer prefix'' of a string when you don't care what the rest of the string is. ``Convert and validate the entire string'' and ``consume and convert the valid prefix, returning the remainder'' are both useful abstractions. I find the current semantics of Scan.Int, ``convert the valid prefix, ignoring the remainder,'' a poor compromise. -- Norman Ramsey nr@princeton.edu [temporarily ramsey@parc.xerox.com, but mail to princeton] ------------------------------------------------------------------------------ Date: 13 Aug 91 20:31:42 GMT From: braeu@untada.enet.dec.com (Walter Braeu) Subject: Re system prog in Modula3 appears Thanks to all that sent me mail. (I ordered the book today from Sam Harbison) Walter :-) Walter Braeu walter.braeu@unt.mts.dec.com ------------------------------------------------------------------------------ Date: 13 Aug 91 18:47:45 GMT From: fld@newton.NoSubdomain.NoDomain (Guenter Feldmann) Subject: m3 on SUN3 Hello M3 freaks, I tried to install m3-1.6 on our Suns (Sun3 and SPARC slc's). On the SPARC slc it works perfectly but on SUN3 the compiler crashes when compiling the first ...i3 program. The Message is as follows: > ------ os starting on Tue Aug 13 19:07:15 MET DST 1991 > .ROOT/system/driver/m3.local -D../Interfaces -g -c Unix.i3 > M3 runtime error, "RTHeap.m3":409: Value out of range > > Program .ROOT/system/compiler/m3compiler got fatal signal 3. I tried to install the compiler with the Sun's cc and gnu gcc (1.39). but the effect is allways the same. The operating System is SunOS 4.1 Can anyone give me some help? ------------------------------------------------------------------------------ Date: Tue, 13 Aug 1991 19:28:08 GMT From: ramsey@parc.xerox.com (Norman Ramsey) Subject: compiler warnings revisited More experience with my favorite warning: "MipsLoadState.nw", line 158: warning: function does not return a value (FindIt ) The procedure in question is: PROCEDURE FindIt(state:T; value:Value; offset:[0..1]):Binding RAISES {Error.UserE, Error.FailE}= BEGIN IF value.space # Location.CodeSegment THEN Error.Fail(Error.FC.Unimplemented,"loader search through other than code"); <*NOWARN*> ELSE IF state.proctable = NIL THEN SetProctable(state); END; WITH proc = state.proctable[ProcedureIndex(state.proctable, value.offset)+o ffset], m = state.target.m, name = GetText(m,Word.Plus(state.stringtableoffset, GetField(m,proc.table,Fields.irpss))) DO RETURN Binding {NameList {Name {name, NameClass.Other}, NIL}, Value {proc .entry}}; END; END; END FindIt; And line 158 is (you guessed it) the RETURN statement. Can someone tell me under what circumstances ``function does not return a value'' is issued, and for what line number so that I can figure out the right place to plant the evil and wrong <*NOWARN*>? (Notice the futile placement with the call to Error.Fail.) -- Norman Ramsey nr@princeton.edu [temporarily ramsey@parc.xerox.com, but mail to princeton] ------------------------------------------------------------------------------ Date: 13 Aug 91 21:15:06 GMT From: pb@cs.albany.edu (Peter Bloniarz) Subject: Re: m3 on SUN3 In article <970@ubrinf.Informatik.Uni-Bremen.DE>, fld@newton.NoSubdomain.NoDoma in (Guenter Feldmann) writes: > I tried to install m3-1.6 on our Suns (Sun3 and SPARC slc's). > On the SPARC slc it works perfectly but on SUN3 the compiler > crashes when compiling the first ...i3 program. > The Message is as follows: > > > ------ os starting on Tue Aug 13 19:07:15 MET DST 1991 > > .ROOT/system/driver/m3.local -D../Interfaces -g -c Unix.i3 > > M3 runtime error, "RTHeap.m3":409: Value out of range > > > > Program .ROOT/system/compiler/m3compiler got fatal signal 3. We encountered a similar problem with the C compiler on our SUN3's running SunOS 4.1 when we tried to install the software as originally distributed. The distribution gives the -O option to cc. When we removed all compiler options in util/config (COPT= ; MOPT= ), it compiled clean. We had no success with gcc 1.37.1 on the same system. ******************************************************************************* * * Peter Bloniarz * * * (518) 442-4277 * Computer Science Department * * pb@cs.albany.edu (internet) * LI 67A * * bloniarz@albnyvms (bitnet) * State University of New York at Albany * * uunet!cs.albany.edu!pb (uucp) * Albany, New York 12222 * ******************************************************************************* * ------------------------------------------------------------------------------ Date: Tue, 13 Aug 91 19:57:07 CDT From: psde@crayamid.cray.com (Peter Edwards) Subject: Re: m3 on SUN3 Peter Bloniarz wrote: > > We encountered a similar problem with the C compiler on > our SUN3's running SunOS 4.1 when we tried to install the > software as originally distributed. The distribution gives the > -O option to cc. When we removed all compiler options > in util/config (COPT= ; MOPT= ), it compiled clean. Some time ago, someone warned of a problem with the -O (which is the same as -O2) option of the SunOS C compiler, and said that choosing -O1 sidestepped it. Hooroo - Peter Cray Research Australia Suite 2.6, 424 St Kilda Rd, Melbourne, Vic 3004 Voice: +61-3-6694389 FAX: +61-3-6694699 (marked c/o SRSU, 4th floor) US: psde@cray.com or peter.edwards@cray.com Oz: psde@burp.ho.bom.gov.au UUCP: ...!uunet!cray!psde Delphi: PSDE ------------------------------------------------------------------------------ Date: 14 Aug 91 06:38:04 GMT From: chased@rbbb.Eng.Sun.COM (David Chase) Subject: Re: m3 on SUN3 fld@newton.NoSubdomain.NoDomain (Guenter Feldmann) writes: > >Hello M3 freaks, >I tried to install m3-1.6 on our Suns (Sun3 and SPARC slc's). >On the SPARC slc it works perfectly but on SUN3 the compiler >crashes when compiling the first ...i3 program. Be specific about what kind of Sun 3. The 68020 (3/60) and 68030 (3/80) machines put their stacks in different places. Since 3/80s aren't that common (that I know of -- I was the first to encounter this bug in the Olivetti distribution back when I was at ORC, and we only had one), this could have been overlooked. Failing that, try compiling either at O1 or at O0 to see if it is a bad GC/optimizer interaction. (Expect more of these in the future, by the way. It is not a bug in the optimizer -- it is a bug in the use of C as an intermediate language with a conservative stack-and-register-scanning collector.) David Chase Sun ------------------------------------------------------------------------------ Date: 14 Aug 91 10:20:45 GMT From: mgallo@zeus.calpoly.edu (M. Gallo) Subject: Where can I learn more? I hope y'all don't mind this question, but where can I get info on Modula-3? I've DLed the language report from gatekeeper, but it's in ps (Post Script?) format and I don't know quite what to do with it. What implementations are available for Modula-3? Please respond by e-mail so we don't irritate knowledgable people. Thanks for your help. -- _ /| Miguel \'o.O' mgallo@ares.calpoly.edu =(___)= "C is its own virus." U ------------------------------------------------------------------------------ Date: Wed, 14 Aug 91 13:28:20 PDT From: muller@src.dec.com (Eric Muller) Subject: Re: m3 on SUN3 In article <18456@exodus.Eng.Sun.COM>, David Chase writes: > Failing that, try compiling either at O1 or at O0 to see if it is a > bad GC/optimizer interaction. (Expect more of these in the future, by > the way. It is not a bug in the optimizer -- it is a bug in the use > of C as an intermediate language with a conservative > stack-and-register-scanning collector.) It seems we need to create comp.lang.modula3.folklore 8-) As of today, nobody knows precisely why SRC Modula-3 compiled with optimization does not work on (some) Sun 3. Or whoever knows never told us. I wish I could put my hands on a Sun3 to find that problem. -- Eric. ------------------------------------------------------------------------------ Date: Wed, 14 Aug 91 17:34:37 PDT From: muller@src.dec.com (Eric Muller) Subject: Re: Where can I learn more? In article <1991Aug14.102045.317068@zeus.calpoly.edu>, M. Gallo asks: > I hope y'all don't mind this question, but where can I get info on > Modula-3? I've DLed the language report from gatekeeper, but it's in > ps (Post Script?) format and I don't know quite what to do with it. The current definition of the Modula-3 language can be found in "Systems Programming with Modula-3", edited by Greg Nelson, Prentice Hall Series in Innovative Technology; price is $25.00, softcover, approx. 275 pages; ISBN 0-13-590464-1. This book contains discussions on using Modula-3 for multi-threaded programs, input/output, window systems. > What implementations are available for Modula-3? SRC Modula-3 1.6 is the only implementation available today. It implements a language slightly different from the one described in the book (it actually implements the language described in the report you grabbed; you can get a paper copy of the report by asking for report # 52 to src-report@src.dec.com). It runs on: SUN3 running SunOS Encore Multimax running UMAX 4.3 (R4.1.1) Acorn R260 running RISC iX 1.21 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 VAX running Ultrix 3.1 DECstation 3100 and 5100 running Ultrix 3.1 SPARCstation running SunOS 4.0.3 -- Eric. ------------------------------------------------------------------------------ Date: 15 Aug 91 11:59:01 GMT From: liam@dcs.qmw.ac.uk (William Roberts) Subject: Re: m3 on SUN3 In <1991Aug14.132820.7783@src.dec.com> muller@src.dec.com (Eric Muller) writes: >As of today, nobody knows precisely why SRC Modula-3 compiled with >optimization does not work on (some) Sun 3. Or whoever knows never >told us. I wish I could put my hands on a Sun3 to find that problem. Robert Stroud in Newcastle (R.J.Stroud@newcastle.ac.uk) sent me various suggestions when I asked for hints of working out why I couldn't build M3 gcc, mostly related to the way that the garbage collector examines the stack and makes (compiler-dependent) assumptions about how to find pointers. Would it be possible for someone to post a small example C program to this newsgroup which demonstrates concisely the "ferretting through the stack" behaviour that is rumoured to be the cause of these problems? -- % William Roberts Internet: liam@dcs.qmw.ac.uk % Queen Mary & Westfield College UUCP: liam@qmw-dcs.UUCP % Mile End Road Telephone: +44 71 975 5234 % LONDON, E1 4NS, UK Fax: +44 81-980 6533 ------------------------------------------------------------------------------ Date: Sat, 17 Aug 1991 05:15:20 GMT From: hjones@magnus.acs.ohio-state.edu (Horace B Jones) Subject: Modula-3 on TOPS-10/20? Has anyone tried getting SRC Modula-3 ported to a TOPS-10 or TOPS-20 environment? It appears that it would be a pretty formidable task involving LINK as well as compiler technology. But I have to ask in case anyone is trying this. Thanks. -- Benny Jones CompuServe 70003,1153 Internet hjones@magnus.acs.ohio-state.edu -- Send compilers articles to compilers@iecc.cambridge.ma.us or {ima | spdcc | world}!iecc!compilers. Meta-mail to compilers-request. ------------------------------------------------------------------------------ Date: 19 Aug 91 21:39:07 GMT From: mike@cs.wisc.edu (Mike Litzkow) Subject: Need help with Building modula3 on R6000/AIX3.1 I am trying to build modula3 on an R6000 running AIX3.1, but getting nowhere fast. I have changed "imake.c" to define REDUCED_TO_ASCII_SPACE and have IMAKECPP set to /usr/lpp/X11/Xamples/util/cpp/cpp. Some of the errors which appear are: --- compiler starting on Mon Aug 19 16:21:35 CDT 1991 ------ builtinOps starting on Mon Aug 19 16:21:36 CDT 1991 .ROOT/system/driver/m3.bootstrap -D../Interfaces -w1 -O -c Abs.ic 18 | extern volatile TYPE TC_REFANY; extern volatile char .....................a............................... a - 1506-030: (S) Illegal redeclaration of identifier. VS_REFANY__4b8748e831fc107a; 22 | extern volatile TYPE TC_ADDRESS; extern volatile char .....................a................................ a - 1506-030: (S) Illegal redeclaration of identifier. VS_ADDRESS__30f7308738738b44; 25 | extern volatile TYPE TC_NULL; extern volatile char .....................a............................. a - 1506-030: (S) Illegal redeclaration of identifier. VS_NULL__fb50c7d53bec30dc; The line numbers in system/compiler/builtinOps/Abs.ic don't match the lines printed in the error messages. If anyone has built mod3 for R6000, I would be grateful for any help. Please reply by email. -- mike ------------------------------------------------------------------------------ Date: 19 Aug 91 18:14:08 GMT From: moss@cs.umass.edu (Eliot Moss) Subject: Re: compiler warnings revisited It is probably not realizing that there is no way to fall out of the WITH statement. I couldn't say where to put the NOWARN exactly, but you probably need one both where it is now and also near the end of the WITH. Better yet, we need compilers with real flow analysis to eliminate most of these warnings. I hope that our gcc-based system will be better at it because gcc has flow analysis. Eliot -- 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 ------------------------------------------------------------------------------ Date: Tue, 20 Aug 1991 14:41:21 -0500 (CDT) From: Dick Orgass Subject: Re: Need help with Building modula3 on R6000/AIX3.1 Mike, It's hard to say exactly what went wrong from your post to comp.lang.modula3. Here are some guesses. My best guess is this: The declarations that xlc is complaining about actually appear in IBMR2.obj/system/runtime/M3Machine.h Following the ANSI rule exactly, xlc doesn't allow extern volatile anything. It looks like I didn't send the necessary change to Eric. At the beginning of the file, you should find text that looks like this: #ifdef NEED_ALLOCA #pragma alloca #endif /* These are the storage classes and type qualifiers */ #define PRIVATE static #define IMPORT extern #define EXPORT /* #define PRIVATE static volatile #define IMPORT extern volatile #define EXPORT volatile */ #define LOCAL_PROC static #define LOCAL auto If your text doesn't look like this, then I failed to send the last change to Eric. I'd appreciate it if you would make the correction and tell me what happens. Dick PS I'm going to be at Carnegie-Mellon for two years working on Modula-3 and multimedia applications. The last time I'll regularly read mail here in Rochester is this Thursday afternoon. Starting Tuesday, September 3rd, I'll answer mail sent to Dick.Orgass@andrew.cmu.edu or to do12+@andrew.cmu.edu. ------------------------------------------------------------------------------ Date: 21 Aug 91 11:04:03 GMT From: liam@dcs.qmw.ac.uk (William Roberts) Subject: Re: Need help with Building modula3 on R6000/AIX3.1 In <1991Aug19.213907.21675@spool.cs.wisc.edu> mike@cs.wisc.edu (Mike Litzkow) writes: >I am trying to build modula3 on an R6000 running AIX3.1, but getting >nowhere fast. I have changed "imake.c" to define REDUCED_TO_ASCII_SPACE >and have IMAKECPP set to /usr/lpp/X11/Xamples/util/cpp/cpp. This isn't really related to your problem, but the imake source supplied with dist-1.6 of Modula3 is looking somewhat dated now. Perhaps it would be a good idea to pick up the latest imake from X11R5 for the next distribution of Modula3? I had imake problems trying to build modula3 under A/UX, but arranging to use the GNU version of cpp for imake solved the problem: the X11R4 version of imake has extra stuff in it for the A/UX native cpp. It was also not clearly indicated in the various config files that the CPP it asks you for is only ever used by imake. The relevant lines of config* are: /* What about CPP ? */ CPP = /lib/cpp Just changing the comment to something like /* What about CPP (only used by imake)? */ would help make this clearer. -- % William Roberts Internet: liam@dcs.qmw.ac.uk % Queen Mary & Westfield College UUCP: liam@qmw-dcs.UUCP % Mile End Road Telephone: +44 71 975 5234 % LONDON, E1 4NS, UK Fax: +44 81-980 6533 ------------------------------------------------------------------------------ Date: 21 Aug 91 11:10:27 GMT From: liam@dcs.qmw.ac.uk (William Roberts) Subject: Re: Need help with Building modula3 on R6000/AIX3.1 In orgass+@rchland.ibm.com (Dick Orgass) writes: >Following the ANSI rule exactly, xlc doesn't allow extern volatile >anything. extern is a storage class specifier and volatile is a type qualifier. There is no sign of anything in K&R edition 2 which suggests that you can't combine the two, and it is completely obvious that a) the combination is meaningful, and b) the combination is probably quite frequently needed. -- % William Roberts Internet: liam@dcs.qmw.ac.uk % Queen Mary & Westfield College UUCP: liam@qmw-dcs.UUCP % Mile End Road Telephone: +44 71 975 5234 % LONDON, E1 4NS, UK Fax: +44 81-980 6533 ------------------------------------------------------------------------------ Date: Wed, 21 Aug 91 11:56:28 CDT From: mike@cs.wisc.edu Subject: Re: Need help with Building modula3 on R6000/AIX3.1 Dick, Thanks so much for your reply regarding my question about building mod3 on R6000 machines. Your suggestion on changing the #define's in system/runtime/M3Machine.h got me past one roadblock, but now there is another. Perhaps a better description of what I've done so far will be helpful. 1. The imake supplied did not work with the cpp on the machine. Somebody on the net suggested using /usr/lpp/X11/Xamples/util/cpp by listing it as my IMAKECPP environment variable. Then modifying util/imake.c to define REDUCED_TO_ASCII_SPACE. That helped. 2. I ran into the problem with the volatile declarations, and posted to the net for help. Your suggestion of changing those define's did work. 3. "Imake" kept dying because "make" died because of a "syntax error on line 346". Of course all makefiles get created in /tmp, and deleted after use, even if there is an error. I eventually tracked down the problem to the m3all.tmpl and m3fromC.tmpl which contained make action lines including the string "-bM:SRE". This conflicted with the REDUCED_TO_ASCII_SPACE action which assumes all makefile lines with ":" in them must be dependence lines and therefore should begin in column 1. I got around this by substituting "-bM\:SRE" in the .tmpl files. 4. Now "make system" dies with the message "sh: .ROOT/util/mkexport: not found." I noticed that mkexport.c has your name in it, so I thought you might be the person to ask about this. hopefully, -- mike ------------------------------------------------------------------------------ Date: Tue, 20 Aug 91 17:51:15 PDT From: muller@Pa.dec.com (Eric Muller) Subject: Re: Modula-3 on TOPS-10/20? In article <91-08-077@comp.compilers>, hjones@magnus.acs.ohio-state.edu (Horace B Jones) writes: > Has anyone tried getting SRC Modula-3 ported to a TOPS-10 or TOPS-20 > environment? It appears that it would be a pretty formidable task > involving LINK as well as compiler technology. But I have to ask > in case anyone is trying this. Thanks. The real problem today is that we are really assuming a bsd-like machine. The situation should be improved with 2.0, where we won't use symbolic links (this will help a lot for System V). Another gray area is the thead emulation; but since this is really an OS problem, I suppose that we should provide an alternate implementation which is simpler to port, but does not offer the full thread functionality (no preemptive scheduling, may be no threads at all). I am not too worried about the compiler/linker part. Using C isolates us a lot from machine characteristics. Of course, we have never tried 36 bits machines and we may have some surprises. By the way, what is sizeof (int) ? and the number of bits in a char ? --- Eric. -- Send compilers articles to compilers@iecc.cambridge.ma.us or {ima | spdcc | world}!iecc!compilers. Meta-mail to compilers-request. ------------------------------------------------------------------------------ Date: Wed, 21 Aug 1991 12:31:45 -0500 (CDT) From: Dick Orgass Subject: Re: Need help with Building modula3 on R6000/AIX3.1 Mike, I first built the Modula-3 system on a pre-product version of AIX 3 and ran into lots of trouble with cpp and imake -- both the one that comes with the C compiler and the one in /usr/lpp/X11.... Fortunately, I was able to port cpp from 4.3 BSD and this works just fine; I considered the problem solved. The 4.3 code, including the lex library, ports very easily. Just change cc to bsdcc in the make files. The result works just fine for Modula-3 and lots of other software built using imake. The program .ROOT/util/mkexport is specific to AIX 3.1. It's trivial filter to convert the output of /usr/ucb/nm into an export list so that ld can be used to create shared libraries. There doesn't seem to be a reasonable place to put the make file rules for building it because it is platform specific so it gets done by hand. Here's the simple set of instructions: cd .../IBMR2.obj/util bsdcc -o mkexport mkexport.c Sounds like you're very close to the end of the system build. Please let me know how it comes out. Dick ------------------------------------------------------------------------------ Date: Wed, 21 Aug 91 13:30:07 CDT From: mike@cs.wisc.edu Subject: Re: Need help with Building modula3 on R6000/AIX3.1 Dick, Again thanks for your help and encouragement. Your instructions on how to create mkexport worked fine. Here is output relevant to the next roadblock. -- mike -------------------------------------------------------------- ... ------ list done on Wed Aug 21 13:18:36 CDT 1991 /bin/ld -o shr.o -L.ROOT/libs ./Csupport/M3Runtime.o ./Csupport/M3Runt i me2.o ./coreos/CoreOS.io ./coreos/CoreOS.mo ./coreos/setjmp.o ./runtime/RTT y pe.io ./runtime/RTType.mo ./runtime/RTTypeRep.io ./runtime/RTProc.io ./runt i me/RTProc.mo ./runtime/RTProcRep.io ./runtime/RTHeap.io ./runtime/RTHeap.mo ./runtime/RTHeapRep.io ./runtime/RTException.io ./runtime/RTException.mo ./r u ntime/RTMath.io ./runtime/RTMath.mo ./runtime/RTMisc.io ./runtime/RTMisc.mo ./runtime/RTLink.io ./runtime/RTScheduler.io ./main/Main.io ./text/Text.io . /text/Text.mo ./text/TextF.io ./time/Time.io ./time/Time.mo ./thread/Thread . io ./thread/Thread.mo ./thread/ThreadF.io ./word/Word.io ./word/Word.o ./C / Ctypes.io ./C/Cstddef.io ./C/Cstring.io ./C/Cstdarg.io ./C/Cstdarg.mo ./C/ C stdlib.io ./C/Csetjmp.io ./C/Cerrno.io ./C/Cstdio.io ./C/M3toC.io ./C/M3to C .mo ./convert/Convert.io ./convert/Convert.mo ./convert/CConvert.io ./conve r t/CConvert.mo ./fmt/Fmt.io ./fmt/Fmt.mo ./smallio/SmallIO.io ./smallio/Smal l IO.mo ./scan/Scan.io ./scan/Scan.mo ./rd/Rd.io ./rd/UnsafeRd.io ./rd/RdCla s s.io ./rd/RdMove.mo ./wr/Wr.io ./wr/UnsafeWr.io ./wr/WrClass.io ./wr/WrMov e .mo ./textrw/TextRd.io ./textrw/TextRd.mo ./textrw/TextWr.io ./textrw/TextW r .mo ./filerw/Stdio.io ./filerw/FileStream.io ./filerw/UFileRdWr.io ./filerw / UFileRdWr.mo ./fingerprint/FPrint.io ./fingerprint/FPrint.mo ./fingerprint/P o ly.io ./fingerprint/Poly.mo ./fingerprint/PolyBasis.io ./fingerprint/PolyBas i s.mo ./tables/IntTable.io ./tables/IntTable.mo ./list/List.io ./list/List.m o -bM\:SRE \ -bE\:libm3core.exp -bI\:libm3core.imp \ -lm -lbsd -lc -lcfg -lodm -T512 -H512 0706-221 WARNING: Import version of 'pow' replaced by local definition. 0706-221 WARNING: Import version of '.pow' replaced by local definition. 0706-224 WARNING: Duplicate symbol '._setjmp'. 0706-224 WARNING: Duplicate symbol '._longjmp'. 0706-224 WARNING: Duplicate symbol '.jmpsavefpr'. 0706-224 WARNING: Duplicate symbol '.jmprestfpr'. 0706-222 WARNING: Import version of 'setpgrp' replaced by import definition. 0706-222 WARNING: Import version of '.setpgrp' replaced by import definition. 0706-222 WARNING: Import version of 'timezone' replaced by import definition. 0706-222 WARNING: Import version of 'fcntl' replaced by import definition. 0706-222 WARNING: Import version of '.fcntl' replaced by import definition. 0706-222 WARNING: Import version of 'ioctl' replaced by import definition. 0706-222 WARNING: Import version of '.ioctl' replaced by import definition. 0706-222 WARNING: Import version of 'mktemp' replaced by import definition. 0706-222 WARNING: Import version of '.mktemp' replaced by import definition. 0706-222 WARNING: Import version of 'nice' replaced by import definition. 0706-222 WARNING: Import version of '.nice' replaced by import definition. 0706-222 WARNING: Import version of 'nlist' replaced by import definition. 0706-222 WARNING: Import version of '.nlist' replaced by import definition. 0706-222 WARNING: Import version of 're_comp' replaced by import definition. 0706-222 WARNING: Import version of '.re_comp' replaced by import definition. 0706-222 WARNING: Import version of 're_exec' replaced by import definition. 0706-222 WARNING: Import version of '.re_exec' replaced by import definition. 0706-222 WARNING: Import version of 'signal' replaced by import definition. 0706-222 WARNING: Import version of '.signal' replaced by import definition. 0706-222 WARNING: Import version of 'sigvec' replaced by import definition. 0706-222 WARNING: Import version of '.sigvec' replaced by import definition. 0706-222 WARNING: Import version of 'sleep' replaced by import definition. 0706-222 WARNING: Import version of '.sleep' replaced by import definition. 0706-244 ERROR: No entry point or export symbols were found following garbage collection. make: 1254-004 The error code from the last command is 8. Make Quitting. .ROOT/util/imake: Exit code 1. Stop. make: 1254-004 The error code from the last command is 1. Make Quitting. .ROOT/util/imake: Exit code 1. Stop. make: 1254-004 The error code from the last command is 1. Make Quitting. ------------------------------------------------------------------------------ Date: Thu, 22 Aug 1991 01:43:39 GMT From: hjones@magnus.acs.ohio-state.edu (Horace B Jones) Subject: Re: Modula-3 on TOPS-10/20? We have an ANSI C compiler and in the next month or so, we'll have a fairly POSIX-compliant implementation of threads in our OS. Our ints are 36 bits and our chars are 9 bits. -- Benny Jones CompuServe 70003,1153 Internet hjones@magnus.acs.ohio-state.edu -- Send compilers articles to compilers@iecc.cambridge.ma.us or {ima | spdcc | world}!iecc!compilers. Meta-mail to compilers-request. ------------------------------------------------------------------------------ Date: 22 Aug 91 14:49:41 GMT From: fld@newton.informatik.Uni-Bremen.DE (Guenter Feldmann) Subject: Modula3 on HH 9000/7xx We would like to use Modula-3 on the new HP 9000/{700,800} RISC machines. Has anyone allredy done a port to these type of machine or (if not) could give me some hints on how to get it work? Guenter Feldmann ------------------------------------------------------------------------------ Date: Sat, 24 Aug 1991 22:22:52 GMT From: mgallo@zeus.calpoly.edu (M. Gallo) Subject: Why use Modula-3? This is for a friend who wants to convince his boss and co-workers to use Modula-3 for a research project. They are currently using C++ on IBM PC's, RT's, and sometimes an R6000. 1) How much time and effort did it take to get Modula-3 up and running on your machines? 2) What experiences have you had with using Modula-3 for large, ongoing software projects? Please e-mail responses to trodrigu@morpheus.calpoly.edu. Thank you. -- _ /| Miguel \'o.O' mgallo@ares.calpoly.edu =(___)= "C is its own virus." U ------------------------------------------------------------------------------ Date: 28 Aug 91 15:21:41 GMT From: harbison@bert.pinecreek.com (Sam Harbison) Subject: Language spot: DIV The DIV operator in Modula-3 is defined as rounding towards minus infinity. This definition differs from the one in Modula-2 and C, which define DIV (/ in C) as rounding towards 0. I assume the C and Modula-2 definitions correspond more closely to how computer integer division typically works. (I note that SRC M3 in fact uses a function call to perform the operation in the generated C code.) Why is DIV defined in this way? 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. ------------------------------------------------------------------------------ Date: Wed, 28 Aug 91 10:41:37 PDT From: muller@src.dec.com (Eric Muller) Subject: Re: Language spot: DIV In article <1991Aug28.152141.7147@bert.pinecreek.com>, Sam Harbison writes: >The DIV operator in Modula-3 is defined as rounding towards minus >infinity. This definition differs from the one in Modula-2 and C, >which define DIV (/ in C) as rounding towards 0. False. / is implementation-dependent if either argument is negative (K&R p 188, ANSI 3.3.5). > (I note that SRC M3 in >fact uses a function call to perform the operation in the generated C >code.) Since we have to compute DIV using / only on positive arguments, there are five cases to consider based on the sign of the arguments. Inlining that code would be a bit expensive. When the sign of one of the arguments is known, we generate inline code. > Why is DIV defined in this way? 1. so that it is defined. 2. see Knuth: The art of computer programming Concrete mathematics -- Eric. ------------------------------------------------------------------------------ Date: Wed, 28 Aug 91 11:45:21 PDT From: Subject: Re: Language spot: DIV > The DIV operator in Modula-3 is defined as rounding towards minus > infinity. This definition differs from the one in Modula-2 and C, > which define DIV (/ in C) as rounding towards 0. > I assume the C and Modula-2 definitions correspond more closely to how > computer integer division typically works. (I note that SRC M3 in > fact uses a function call to perform the operation in the generated C > code.) > Why is DIV defined in this way? Aahhh, don't ask. This is my second most favorite pet war (after stamping out the TAB character). I have tons of saved mail about this issue that I am ready to dump on anyone who dares to wish the return of the Good Old Times of FORTRAN arithmetic. 8-) Seriously, the argument goes as follows. First of all, DIV and MOD should be consistent with each other, that is x = (x DIV y) * y + (x MOD y) for any x and any nonzero y. Now if DIV rounds towards 0, then MOD of negative x and positive y should be negative. So the question you asked is equivalent to "why is (-12 MOD 5) equal to 3, instead of -2?" There are several reasons: 1. That is the way mathematicians define MOD. 2. The M3 definition of MOD has many nice properties that the other one lacks (e.g. ((x + k*y) MOD y) = (x MOD y) for any x and k) (This explains item 1.) 3. The M3 definition is more useful to programmers, for things like circular buffers, hash tables, bit addressing, and so on. (Not surprising, given item 2.) 4. The M3 definition is consistent with two's complement arithmetic. For example, (x MOD 256) can be computed by extracting the low-order byte of x, even when x<0. In fact, two's complement arithmetic obeys the identity (internal value) = (external value) MOD 2^(word size). Neither of these properties holds for the C definition. 5. When one uses x DIV y to approximate the fraction x/y (e.g. in scaling from World to Window coordinates), the C definition produces a "glitch" around x=0: twice as many values of x get mapped to 0 than to any other number. This is a common cause of bugs, e.g.in plotting routines. The M3 definition produces no such glitch. There are other reasons, but these should do for now. On the other hand, the C semantics has basically only one reason to go for it: 9. That is the way most computers do it. Which is true mainly because 8. That is the way FORTRAN does it. Which presumably is true because 7. In the late fifties, computers typically used the sign-magnitude decimal encoding for integers. Well, perhaps not exactly, but you can sense my feelings. Tradition is no excuse for perpetuating old mistakes. Let's dare to make some progress, for a change. Cheers, --jorge 8-) PS. Lucky of you for not asking what (x MOD y) should do when y<0... ------------------------------------------------------------------------------ Date: 28 Aug 91 20:00:07 GMT From: larry@rock.psl.nmsu (Larry Cunningham) Subject: Modula-3 I'm a Modula-2 fan who is new to reading this group. Can someone fill me in about the Modula-3 changes over Modula-2, availability of compilers, etc. Thanks in advance. "Yeh, Buddy.. | lcunning@nmsu.edu (Larry Cunningham) | _~~_ I've got your COMPUTER! | % Physical Science Laboratory | (O)(-) Right HERE!!" | New Mexico State University | /..\ (computer THIS!) | Las Cruces, New Mexico, USA 88003 | <> -------------------------------------------------------------------------- Disclaimer: Opinions expressed here are CORRECT, mine, and not PSLs or NMSUs.. ------------------------------------------------------------------------------ Date: Wed, 28 Aug 91 15:22:30 PDT From: muller@src.dec.com (Eric Muller) Subject: FAQ Here is a first version of the FAQ. If you have suggestion for improving it, please send me a message. I intend to repost update versions of this message every month. -- Eric. 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: greaterrobustness, 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. 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 from SRC by sending a message to src-report@src.dec.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 5100 running Ultrix 3.1 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.0.3 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. Is comp.lang.modula3 archived ? Yes, in gatekeeper.dec.com:pub/DEC/Modula-3/comp.lang.modula3 What if I don't have ftp access ? You can contact: Pine Creek Software Suite 300 305 South Craig Street Pittsburgh, PA 15213 Phone & Fax: [1] (412) 681 9811 Email: harbison@bert.pinecreek.com ------------------------------------------------------------------------------ Date: 29 Aug 91 16:04:16 GMT From: buschman@tubsibr.uucp (Andreas Buschmann) Subject: Re: Modula-3 Hallo, larry@rock.psl.nmsu (Larry Cunningham) writes: >I'm a Modula-2 fan who is new to reading this group. Can someone fill >me in about the Modula-3 changes over Modula-2, availability of compilers, >etc. I have my diploma thesis written on this subject, but it is in German, so it might not help you much. A language definition is available via anonymous ftp from 'gatekeeper.dec.com' [16.1.0.2], in '/pub/DEC/Modula-3/report' A compiler for several unix systems is also available there. Tschuess Andreas /|) Andreas Buschmann /-|) TU Braunschweig, Germany bitnet: buschman%tubsibr@dbsinf6.bitnet uucp: buschman@ibr.cs.tu-bs.de old: buschman@tubsibr.uucp ------------------------------------------------------------------------------ Date: 30 Aug 91 17:12:59 GMT From: mgallo@zeus.calpoly.edu (M. Gallo) Subject: Re: Language spot: DIV I was going to e-mail this, but Jorge neglected to leave his InterNet address. In article <9108281845.AA11430@jumbo.pa.dec.com> stolfi (Jorge Stolfi) writes: > >Aahhh, don't ask. This is my second most favorite pet war (after >stamping out the TAB character). I have tons of saved mail about this >issue that I am ready to dump on anyone who dares to wish the return >of the Good Old Times of FORTRAN arithmetic. 8-) >PS. Lucky of you for not asking what (x MOD y) should do when y<0... OK, call me a masochist, but I'll bite. What do you think (x MOD y) should do when y < 0? Does it simply follow from your previous definitions of DIV and MOD, in which case you probably didn't need to add your P.S., or do you have something else in mind? -- _ /| Miguel \'o.O' mgallo@ares.calpoly.edu =(___)= "C is its own virus." U ------------------------------------------------------------------------------ Date: Fri, 30 Aug 91 17:27:21 GMT From: jimad@microsoft.com (Jim ADCOCK) Subject: Re: Language spot: DIV In article <1991Aug28.152141.7147@bert.pinecreek.com> harbison@bert.pinecreek.c om (Sam Harbison) writes: |The DIV operator in Modula-3 is defined as rounding towards minus |infinity. This definition differs from the one in Modula-2 and C, |which define DIV (/ in C) as rounding towards 0. C and C++ leave it implementation defined whether / rounds towards zero or minus infinity. The requirement if either operand is negative is simply that (a/b)*b + a%b gives a again. [where '%' is 'mod'] |I assume the C and Modula-2 definitions correspond more closely to how |computer integer division typically works. C and C++ are defined to correspond closely to how a particular computer's arithmetic works, no matter what the hardware guys decide to do. 1/2 :-) [It's a tacit assumption that software people are smart enough to avoid such machine dependencies :-] ------------------------------------------------------------------------------ Date: 30 Aug 91 20:54:27 GMT From: mccalpin@perelandra.cms.udel.edu (John D. McCalpin) Subject: Trouble with m3tk under IBMR2 I have successfully built m3 release 1.6 under AIX 3.1 (3005). I am having trouble compiling M3AST_all.i3 in m3tk. The machine spins its wheels for quite a while (running m3), then starts running the C compiler (xlc) and a bit later dies with the message: 1506-239: (S) System resource has been exhausted. Compilation ended. The manuals helpfully tell me that message 1506 is from the C compiler front-end, but I can get no info on message 239, other than "System resource has been exhausted". I am reasonably certain that it is not a configurable limit problem, since the machine has 512 MB RAM, 1008 MB swap space, and my account has no limits on cpu time, stack size, etc. Has anyone gotten this to compile on an RS/6000? -- John D. McCalpin mccalpin@perelandra.cms.udel.edu Assistant Professor mccalpin@brahms.udel.edu College of Marine Studies, U. Del. J.MCCALPIN/OMNET ------------------------------------------------------------------------------ Date: Fri, 30 Aug 91 15:49:11 PDT From: mjordan@src.dec.com (Mick Jordan) Subject: Re: Trouble with m3tk under IBMR2 In article , mccalpin@perelandra. cms.udel.edu (John D. McCalpin) writes: > I have successfully built m3 release 1.6 under AIX 3.1 (3005). > > I am having trouble compiling M3AST_all.i3 in m3tk. The machine spins > its wheels for quite a while (running m3), then starts running the C > compiler (xlc) and a bit later dies with the message: > 1506-239: (S) System resource has been exhausted. Compilation ended. > > The manuals helpfully tell me that message 1506 is from the C compiler > front-end, but I can get no info on message 239, other than "System > resource has been exhausted". > > I am reasonably certain that it is not a configurable limit problem, > since the machine has 512 MB RAM, 1008 MB swap space, and my account > has no limits on cpu time, stack size, etc. > > Has anyone gotten this to compile on an RS/6000? Dick Orgass has successfully built m3tk for an RS/6000 I believe. However, I am not sure that he uses the standard C compiler. Maybe gcc. His new mail address is Dick.Orgass@andrew.cmu.edu. Mick Jordan ------------------------------------------------------------------------------