======================================================================== 1 === Date: Mon, 2 Mar 92 10:58:08 PST From: Subject: Re: errors and exceptions There is a reasonable way of implementing a slight restriction of path 2, errors as control transfers. That is to note at compile time whether a runtime exception generated by an expression can be caught or not. If the runtime error exception cannot be caught then the compiler is free to optimize as much as it wants. If it can be caught it must be careful. A runtime error can be caught if the expression occurs statically inside of a TRY EXCEPT for the indicated exception or the procedure the expression is contained in mentions the exception. In this way the compiler can note whether the kind of optimizations that you envision can be made. For example in, PROCEDURE X() = BEGIN TRY INC(x); INC(y); EXCEPT | RTException.IntegerOverflow: END; END X; The increments of x and y cannot be done in parallel. While in PROCEDURE X() = BEGIN INC(x); INC(y); END X; they can. The slight restriction of path 2 have to do with catching an exception resulting from an unhandled exception. For example in: MODULE Main; VAR x: INTEGER := LAST(INTEGER); VAR y: INTEGER := 0; PROCEDURE X() = BEGIN INC(x); INC(y); END X; BEGIN TRY X(); EXCEPT ELSE <* ASSERT y = 0 *> END; END Main. One would like not to have to make this program work. Garret ======================================================================== 2 === Date: 2 Mar 92 11:56:13 GMT From: os102@cl.cam.ac.uk (Oliver Stephens) Subject: Trestle Question How does a filter change the domain of it's child without calling the child's Reshape method ? This may sound like an odd question, but I have implemented a StretchyBorderVBT which is like a BorderedVBT except that it always gives it's child it's preferred size (useful when the child has size constraints such as a constant aspect ratio or can only use a discrete number of different sizes). In the filter's Reshape method, I want to change the domain of the child to be the maximum possible, then call GetShapes which returns the child's preferred shape within this domain, then resize the filter borders and call the child's Reshape method with it's final position. If I use the child's Reshape method for the initial change, then the child will attempt a redraw twice - once in the wrong position, then again in the correct position. At the moment, I have it working by changing the child's domain field explicitly (filter.ch.domain) but I don't think I'm supposed to do this. I would be very grateful for any `guru' comments/suggestions, Olly ------------------------------------------------------------------------- Olly Stephens oliver.stephens@cl.cam.ac.uk Computer Laboratory University of Cambridge Loved you there and then, and now like a sheep United Kingdom - Van Morrison ======================================================================== 3 === Date: 2 Mar 92 17:00:57 GMT From: Olin.Shivers@cs.cmu.edu Subject: errors and exceptions Requiring run-time errors to raise exceptions can impede optimising compilers. For example, suppose we define integer arithmetic overflow to raise an exception, which if not caught, terminates the program. Sounds reasonable. However, you've just about eliminated any possibility of the compiler reordering integer ops -- like hoisting very-busy exps, or rescheduling them inside basic blocks to fill load or jump delay slots. Doing the operation early might prevent some side-effect visible to the exception handler code from happening. Defining the error to terminate your program makes it easier to justify doing this. Another example: I loop from 0 to K over an array. A fancy compiler hoists the bounds check outside the loop. If array bounds errors are *errors* - not allowed in correct programs, and terminate the program, then it's OK that the program terminated early, without first executing the initial loop iterations where the index was legal. Now suppose instead we require index errors to generate an exception. The user might have been counting on that exception happening -- maybe he was trying to loop over all the legal indices of the array in a kind of sleazy way. There are people who really do this in ML. The problem with exceptions is that they introduce these extra control edges into your program. It's just about impossible to remove them because the control transfers have dynamic scope, being set up by exception handlers, so how can you prove no one is going to handle them? Furthermore, they encourage a business-as-usual exploitation of run-time errors which makes it hard to define your language to allow for early detection of these errors. The errors have to happen right when they happen, so forget about hoisting stuff out of loops. For operations like integer arithmetic and array indexing, that's not so good. So, there are two possible paths you can take about run-time errors: 1. Fail-stop: A run-time error is not exhibited by a correct program. A program will always detect and report these errors. Early detection is allowed, that is error detection is not ordered wrt the external side-effects of the partially-executed errorful program. 2. Errors-are-just-another-control-transfer: Errors are always detected, causing exceptions to be raised. The errorful operation and the exception it triggers is ordered wrt the side-effects of the program (after all, it's just a conditional branch). You need to be careful which errors are put in which set. My belief is that array bounds checks definitely belong in set 1, for reasons of efficiency and programming style. Arithmetic ops? Maybe you could provide two different arithmetic modules. Excuse me if this isn't germane to M3. I don't have my M3 book on me in HK, so I'm a little fuzzy on details of the language. -Olin ======================================================================== 4 === Date: Mon, 2 Mar 92 12:09:33 PST From: Subject: Re: errors and exceptions Note that the reason Ada has to resort to pragmas and compiler modes to solve this problem is because the language does not have RAISES clauses. If Ada had RAISES clauses it could fix things in the simple and elegant (if I say so myself) way I suggested. Note that a pragma or compiler switch that allows the compiler to generate code that violates the language semantics is an "illegal" pragma (a.k.a. "a hack"). Changing the language to allow "imprecise" exceptions and adding pragmas to tighten things up is less of a hack but it certainly muddies up the language semantics. Garret ======================================================================== 5 === Date: Mon, 2 Mar 1992 20:13:35 GMT From: mday@pion.lcs.mit.edu (Mark Day) Subject: Re: errors and exceptions Olin.Shivers@cs.cmu.edu writes: So, there are two possible paths you can take about run-time errors: 1. Fail-stop: A run-time error is not exhibited by a correct program. A program will always detect and report these errors. Early detection is allowed, that is error detection is not ordered wrt the external side-effects of the partially-executed errorful program. 2. Errors-are-just-another-control-transfer: Errors are always detected, causing exceptions to be raised. The errorful operation and the exception it triggers is ordered wrt the side-effects of the program (after all, it's just a conditional branch). You need to be careful which errors are put in which set. My belief is that array bounds checks definitely belong in set 1, for reasons of efficiency and programming style. I might believe the efficiency concern. My experience with CLU causes me to disbelieve the programming style concern. Certain kinds of programs have markedly improved clarity if you can write them as "do this to the array element, but if it isn't there then do this other thing." If I wrote a lot of scientific programs that did regular marching through arrays in tight loops, I might prefer efficiency to expressive power; but for a lot of the code that I write, it would be a pain in the neck to have an out-of-bounds access be fatal. --Mark Day mday@lcs.mit.edu ======================================================================== 6 === Date: Mon, 2 Mar 92 11:47:52 PST From: msm@src.dec.com (Mark S. Manasse) Subject: Re: Trestle Question The shape methods in Trestle aren't designed to do what you want; they are designed to give us a way to compute the overall layout constraints for top-level windows. If you want use the domain of your window to compute your desired shape, you'll get double repaints. You could avoid the double repaint in several ways: by defining a PaintBatch procedure that trapped painting, by examining the domain of your parent VBT, or by defining a private protocol for the purposes of your computation. The last would probably be my choice; if you place an entry on the child's PropSet containing the bounding rectangle that you would like it to work within , the child shape method could read that and do whatever it wanted. But that's still unlikely to get the child to ask for a sensible shape in the first place. As an alternative, the child could simply center itself in whatever domain it receives, and then call NewShape. When the parent reshapes the child, it could provide the old domain; the child could notice that the only part it cared about was in fact preserved. An alternative would be for the VBT to handle reshapes by simply marking the VBT, and, if necessary, calling NewShape (but only if the VBT wasn't already marked, to avoid infinite looping). On a call to the redisplay method, call the reshape method of the child. This loses you the ability to use your old old domain, unless you guess what part of it might be useful, and copy it. Mark ======================================================================== 7 === Date: 2 Mar 92 19:27:01 GMT From: emery@Dr_No.mitre.org (David Emery) Subject: Re: errors and exceptions There is a great amount of "knowledge" on this topic in Ada. Generally, it's known in the Ada community as "11.6", after the part of the Ada Reference Manual which discusses the interactions between exceptions and optimizations. There is always a tension between precision and optimization. The current Ada 9X approach is to permit more optimizations in general, but to have a compiler mode (as one of the specified annexes, which may not be supported by all compilers) that requires 'canonical' execution. In some respects, this is equivalent to a pragma that permits or forbids the compiler to do substantial reordering, etc, during optimization. dave ======================================================================== 8 === Date: Tue, 3 Mar 1992 10:55:16 GMT From: aet@ee.mu.OZ.AU (bert thompson) Subject: oberon for sun4 sparc can someone please tell me where i'd find an oberon implementation for a sun4 sparc. i don't want to have to install it at /usr/local/contrib/... but instead in my own home directory. (i ftp'ed an oberon compiler but couldn't get it going because it wanted to live at /usr/local/contrib/...) (as a last resort i may try to convince the sysadmin to install it.) even an interpreter would be very nice. i just want to check out the language for myself: it's seems to be just what i've always wanted in a procedural language! most grateful for any help! bert (an ordinary non-superuser 8^) (btw, sorry for posting in these groups but there is no comp.lang.oberon.) ======================================================================== 9 === Date: 3 Mar 92 16:26:25 GMT From: harbison@bert.pinecreek.com (Sam Harbison) Subject: Modula-3 Video I recently received a brochure from University Video Communications listing a series of videotapes by noted authorities on various CS topics. One of them was Jim Donahue talking on Modula-3. Since Jim's affiliation was listed as Olivetti Research, I guess this video is at least a couple of years old. I have not seen it, nor do I know anything about the company. According to the brochure, the videos are normally $60 each, but there's a special offer of 4 for $100. Contact University Video Communications, P.O.Box 5129, Stanford, CA 94309. Phone (415) 327-0131; fax (415) 813-0315. 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. ======================================================================== 10 === Date: Tue, 3 Mar 1992 10:53:33 -0500 (EST) From: Dick Orgass Subject: SRC Modula-3 Runtime Question I've been working on making the Andrew Toolkit available as a set of shared Modula-3 libraries. This is being done by retaining the C code that provides the function and adding Modula-3 interfaces and replacing the ATK runtime with the Modula-3 runtime. The result has been a significant simplification of the runtime code. There is one piece of the ATK runtime that I don't quite know how to replace/improve. At runtime, I would like to be able to bind the invocation of specific methods of specific objects to key sequences, eg, ^S to the search-forward method of the text object. Finding the actual method pointer is clean and easy. However, I don't know how to find the signature of the method proc at runtime so that I can LOOPHOLE the ADDRESS in the MethodSuite to a procedure with the correct signature. Using an explicit type makes the whole thing much more reliable. I would appreciate hints, references to papers, etc. Many thanks! Dick ======================================================================== 11 === Date: Tue, 3 Mar 1992 17:19:55 GMT From: rau_larry@tandem.com Subject: Case of keywords Here is an EASY question??!! In the first report on Modula-3 it stated that Keywords (I can't remember if Reserved words are included) could be either ALL uppercase or ALL lower case. In the revised Modula-3 report and in the "Green" book nothing is said about this, nor is their a mention that this has indeed changed. So, my question is am I to assume that Keywords must be ALL UPPERCASE?? .................larry ======================================================================== 12 === Date: 4 Mar 92 06:46:06 GMT From: sakkinen@jyu.fi (Markku Sakkinen) Subject: Re: Modula-3 Video In article <1992Mar3.162625.1679@bert.pinecreek.com> harbison@bert.pinecreek.co m (Sam Harbison) writes: >I recently received a brochure from University Video Communications >listing a series of videotapes by noted authorities on various CS >topics. One of them was Jim Donahue talking on Modula-3. Since >Jim's affiliation was listed as Olivetti Research, I guess this video >is at least a couple of years old. I have not seen it, nor do I know >anything about the company. > >According to the brochure, the videos are normally $60 each, but >there's a special offer of 4 for $100. Contact University Video >Communications, P.O.Box 5129, Stanford, CA 94309. Phone (415) >327-0131; fax (415) 813-0315. > >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. ======================================================================== 13 === Date: 4 Mar 92 07:32:54 GMT From: sakkinen@jyu.fi (Markku Sakkinen) Subject: Re: Modula-3 Video Oops, pressed the wrong key so a junk posting was sent. Sorry. In article <1992Mar4.064606.6841@jyu.fi> sakkinen@jyu.fi (Markku Sakkinen) writ es: >In article <1992Mar3.162625.1679@bert.pinecreek.com> harbison@bert.pinecreek.c om (Sam Harbison) writes: >>I recently received a brochure from University Video Communications >>listing a series of videotapes by noted authorities on various CS >>topics. One of them was Jim Donahue talking on Modula-3. Since >>Jim's affiliation was listed as Olivetti Research, I guess this video >>is at least a couple of years old. I have not seen it, nor do I know >>anything about the company. Our department has bought several of those tapes. I have seen Donahue's video once, and I quite liked it. The lecture and short discussion has been recorded in late November 1989, thus very shortly before Olivetti Research was closed, but Donahue's speech gave me the impression that he did not know yet what was coming. I think that this later history was mentioned in the titles. The picture quality of these UVC videotapes is not overwhelming but sufficient (texts on the slides or screen displays are large enough). It's near to what I get when recording TV programmes at half speed. Conversion from NTSC to PAL may have been a factor, so perhaps they are a bit better in America. Unfortunately, some speakers of the series (not Donahue) mumble rather unclearly, thus some presentations may be difficult for foreign students to understand. ---------------------------------------------------------------------- Markku Sakkinen (sakkinen@jytko.jyu.fi) SAKKINEN@FINJYU.bitnet (alternative network address) Department of Computer Science and Information Systems University of Jyvaskyla (a's with umlauts) PL 35 SF-40351 Jyvaskyla (umlauts again) Finland ---------------------------------------------------------------------- ======================================================================== 14 === Date: 4 Mar 92 16:43:43 GMT From: geb@amber.Rational.COM (Gary Barnes) Subject: Is there a definitive "definition of Modula-3"? Does the language have a generally agreed upon definition yet? I have the original "Modula-3 Report" out of Olivetti and I have a copy of Samuel Harbison's new "Modula-3" book, but... These two references describe related but distinctly different languages and they both contain noticable holes, ambiguities, and contraditions about the edges and hard semantic rules of the language. Does Modula-3 have a hard edged standard yet? Is there a group working on making a standard for it (ala IEEE, ANSI, ISO groups) or working on writing a single definitive definition such as Ada's LRM? Or is the language largely defined by what the SRC compiler accepts or rejects? On a related question, has anyone started on an equivalent to Ada's ACVC tests for testing out an implementation to see whether it implements "Modula-3" or merely "something that looks a lot like Modula-3"? Gary E. Barnes geb@Rational.com ======================================================================== 15 === Date: 4 Mar 92 14:19:49 GMT From: moss@cs.umass.edu (Eliot Moss) Subject: Re: SRC Modula-3 Runtime Question Why don't you LOOPHOLE it to a procedure type with first parameter REFANY and second parameter the key sequence that was used to invoke it? The methods actually used would of course have only self and a key sequence as arguments. Note that the REFANY technique would allow people to bind arbitrary procedures, too, that were not included as methods by the definer of the object. Or maybe I'm misunderstanding the whole nature of what you were asking. Note that you need to know what instance to invoke this on, too. Again, using REFANY in your key tables is general. Making this all truly type safe is another matter. I can imagine doing that only by having a KeySequence method in a high level interface and having all the objects inherit from that and having each object dispatch the different key sequences internally (the last part is the unpleasant part). Seems we really would like to have closures, which you can approximate with a record but will have potential type safety problems. -- 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 ======================================================================== 16 === Date: 4 Mar 92 14:11:42 GMT From: moss@cs.umass.edu (Eliot Moss) Subject: Re: Case of keywords Yes, if I remember correctly, that was changed between the original report and the revised report. Personally, I liked the old way fine, not being a fan of all upper case for just about anything, but that's what happened ... 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 ======================================================================== 17 === Date: 4 Mar 92 14:12:26 GMT From: moss@cs.umass.edu (Eliot Moss) Subject: Re: Modula-3 Video I have seen the video and it is a pretty good introduction to the history, motivation, and major features of M3 .... 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 ======================================================================== 18 === Date: Wed, 4 Mar 92 15:02:07 PST From: muller@src.dec.com (Eric Muller) Subject: Re: Is there a definitive "definition of Modula-3"? In article <4872@igor.Rational.COM>, geb@amber.Rational.COM (Gary Barnes) write s: > Does the language have a generally agreed upon definition yet? I have > the original "Modula-3 Report" out of Olivetti and I have a copy of > Samuel Harbison's new "Modula-3" book, but... @book (m3-Nel91, title = "System Programming with Modula-3", editor = "Greg Nelson", publisher = "Prentice Hall", isbn = "0-13-590464-1", year = 1991, what = "The bible for Modula-3. Includes the language reference manual and papers on the I/O library, threads, and the Trestle window system." ) -- Eric. ======================================================================== 19 === Date: 4 Mar 92 18:58:41 GMT From: chased@rbbb.Eng.Sun.COM (David Chase) Subject: Re: Is there a definitive "definition of Modula-3"? In article <4872@igor.Rational.COM> geb@amber.Rational.COM (Gary Barnes) writes : > >Does the language have a generally agreed upon definition yet? Yes -- Harbison's book may be correct already, but I believe that Nelson's is supposed to be The Truth. >These two references describe related but distinctly different >languages and they both contain noticable holes, ambiguities, and >contraditions about the edges and hard semantic rules of the >language. There were 3 published versions of the language -- two described in (both) DEC-SRC and Olivetti tech reports, and the third described in Nelson's book. > ... Is there a group >working on making a standard for it (ala IEEE, ANSI, ISO groups) or >working on writing a single definitive definition such as Ada's LRM? I hope like hell not. I've got more faith in the people on the original committee (in spite of my disagreements from time to time) than I do in any standards committee, especially in this new world of standards-as-marketing-weapons. There was enough feedback from the peanut gallery (implementors and porters) to keep them from screwing up too badly. The book defines a useable language. >Or is the language largely defined by what the SRC compiler accepts or >rejects? No, this is definitely not the case. David Chase Sun ======================================================================== 20 === Date: 5 Mar 92 14:00:21 GMT From: harbison@bert.pinecreek.com (Sam Harbison) Subject: Re: Is there a definitive "definition of Modula-3"? In article <4872@igor.Rational.COM> geb@amber.Rational.COM (Gary Barnes) writes : >Does the language have a generally agreed upon definition yet? ... Both Greg's and my book *should* describe the same language. If mine disagrees with Greg's then there's a bug and I'd like to know about it. Ditto about "noticable holes, ambiguities, and contraditions about the edges and hard semantic rules of the language." >...Has anyone started on an equivalent to Ada's ACVC tests for testing ... I think this would be a good idea, but it hasn't seemed to have gotten to the top of anyone's stack. Perhaps Rational should abandon that silly Ada stuff and switch to Modula-3? 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. ======================================================================== 21 === Date: 6 Mar 1992 23:10:12 -0600 From: wilson@cs.utexas.edu (Paul Wilson) Subject: Re: Safe cheap objects for Modula 3 In article moss@cs.umass.edu writes: >>>>>> On 26 Feb 92 19:20:51 GMT, Hans_Boehm.PARC@xerox.com said: > >Hans> Let's keep things in perspective. There is a significant cost to >Hans> allocating collectible storage rather than stack allocating storage. >Hans> [...] You may need some locking or synchronization on allocation, or >Hans> risk fragmenting the heap by dividing it up on a per thread basis. > >What I had in mind for gm3 was a generational heap where each thread has its >own nursery but the older spaces are shared. One then needs synchronization >only on scavenging and promotion, which require coordination anyway. I'd be >interested in folks thoughts on this approach (not on generational vs. other >schemes, but this multi-thread generational scheme). It seems to me that it will be a good idea to have separate nurseries for each threads if and only if they're running on separate processors. If you have high rates of heap allocation, the reuse of the nursery (creation area) will dominate your cache-level locality. (I don't know how high is high, to any precision, or how many M3 programs get there.) Basically, each nursery will have a big nasty footprint in the cache. If multiple threads share the same nursery, you'll have several big nasty footprints---any multitasking you do at a timescale relevant to the cache will cause your working set to be the set union of the nursery sizes, if heap allocation rates are high. Unfortunately, it may be more efficient to use separate nurseries, unless you can gc opportunistically. If multiple processes allocate from the same hunk of memory, they'll use it up and cause a gc sooner, even though none of them will have made lots of progress, so they'll still have a lot of live intermediate results. Having them share a nursery could make each of them less efficient, unless it's too big to fit in cache anyway. One way around this would be to task switch preferentially after a gc scavenge. When you've emptied the nursery, you task switch and let the next process use it. That's better than task switching halfway through, and having one process cause another process's data to be copied. If this scheduling doesn't conflict with other things, then you get the best of both worlds. On the other hand, in the ideal case you have one processor per process, and can have each nursery entirely cached in one processor's cache. >I'd like to explore the optimization of stack allocation of some objects, and >in fact have a pending grant proposal on gc that would include that as part of >a comprehensive gc system. I agree that stack allocation is cheaper than heap >allocation, but I want to get some numbers that show the difference. Maybe gm3 >will be running well enough soon that we can try some tests to see the >difference in cost with our collector. That would be very interesting. If we get threads running in Scheme-48 soon, we may try a similar experiment with Scheme. (Ideally, within the next month so it can go in our caching paper for LFP... here's hoping.) -- Paul -- | Paul R. Wilson, runtime environmentalist 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 | ======================================================================== 22 === Date: 7 Mar 92 17:52:33 GMT From: doug@sni.ca (Doug Moen) Subject: Re: Is there a definitive "definition of Modula-3"? geb@amber.Rational.COM (Gary Barnes) writes: >>Does the language have a generally agreed upon definition yet? chased@rbbb.Eng.Sun.COM (David Chase) writes: >Yes -- Harbison's book may be correct already, but I believe that >Nelson's is supposed to be The Truth. >>These two references describe related but distinctly different >>languages and they both contain noticable holes, ambiguities, and >>contraditions about the edges and hard semantic rules of the >>language. ... Is there a group >>working on making a standard for it (ala IEEE, ANSI, ISO groups) or >>working on writing a single definitive definition such as Ada's LRM? >I hope like hell not. I've got more faith in the people on the >original committee ... than I do in any standards committee >>Or is the language largely defined by what the SRC compiler accepts or >>rejects? >No, this is definitely not the case. Well, in that case, there is a problem. Nelson's book is an informal description of Modula-3; it is also incomplete and ambiguous. If I were writing a Modula-3 compiler, I would not be able to do so strictly from reading Nelson's book. In order to resolve ambiguities in the language description, I would have to experiment with the SRC compiler to see what it did, or I would have to obtain clarifications from the language designers. So the Modula-3 "language definition" resides partly in Greg Nelson's book, partly in the behaviour of the SRC compiler, and partly in the minds of the language designers. This situation is workable for now, because the Modula-3 community is small and friendly. If Modula-3 is to grow past its current stage, then either it will need to have a complete, unambiguous formal definition and reference manual that can be consulted as the final authority on what is or is not legal Modula-3, or there will be a "tower of babel" effect with different compilers implementing different variants of the language, with the consequent portability problems that that will entail for users of the language. Actually, the tower of babel effect will happen anyway (as it has for C). But the existence of the ANSI C Standard means that I can at least complain to my compiler vendor when they violate the standard. I agree with David Chase's comments about standards committees. I certainly don't like what the ANSI committee did to the C language. All the more reason for the Modula-3 language designers to produce a complete, unambigous and definitive description of the language (using formal description mechanisms where possible), before a committee of compiler vendors attempts to do the job for them. -- Doug Moen | doug@sni.ca | uunet!snitor!doug ======================================================================== 23 === Date: 8 Mar 92 15:38:24 GMT From: moss@cs.umass.edu (Eliot Moss) Subject: Re: Is there a definitive "definition of Modula-3"? >>>>> On 7 Mar 92 17:52:33 GMT, doug@sni.ca (Doug Moen) said: >>Or is the language largely defined by what the SRC compiler accepts or >>rejects? >No, this is definitely not the case. Doug> Well, in that case, there is a problem. Nelson's book is an informal Doug> description of Modula-3; it is also incomplete and ambiguous. If I were Doug> writing a Modula-3 compiler, I would not be able to do so strictly from Doug> reading Nelson's book. In order to resolve ambiguities in the language Doug> description, I would have to experiment with the SRC compiler to see Doug> what it did, or I would have to obtain clarifications from the language Doug> designers. So the Modula-3 "language definition" resides partly in Greg Doug> Nelson's book, partly in the behaviour of the SRC compiler, and partly Doug> in the minds of the language designers. Actually, there are fewer ambiguities than I first thought. When we dug in to implement GNU Modula-3 (gm3) we went through the language definition carefully and there were indeed a few points where we were confused. Ultimately I think that Nelson's book (or the previous definitions) were not so much ambiguous as difficult to understand in a few places. We obtained clarification from Greg, et al., and a few additional programming examples would have straightened out the difficulties we had. Short of a formal definition such as that for ML, the Vienna definition of PL/1, or the Van Wijngarten (sp?) grammars of Algol-68, I think the language designers have done a good job of language definition. (I may not always agree with their choices, but that's a different matter.) It could be that there are places where an implementor was deliberately given freedom and it bothers you, e.g., checked run-time exceptions. The point here is that though the SRC compiler does it one way, gm3 could legally do it another way, and programs that depend on a specific behavior are wrong, though compielrs are not necessarily required to detect such situations and warn the programmer. While this may not always make for happy programmers, the technology is not there (or perhaps we could say even if it is, it's not cost effective to apply it) to do the checks, and because different machines, operating systems, etc., do things different ways, there are points on which it is inappropriate for the language designers to force a particular implementation. There *will* be differences in implementation between SRC M3 and gm3, but we certainly intend that correct programs exhibit the same behavior in both language systems. Finally, of course there are probably *some* errors and ambiguities in the Nelson book's definition. Heck, we found a minor error having to do with whether a particular token was a keyword or reserved word (it got on the wrong list), and we certainly found a few places that were hard for us to understand. This leads me to agree that there needs to be a mechanism for clarification and correction of the language definition -- possibly some language designer approved "errata" or "addenda" that one can acquire via anonymous ftp, etc. Further, if the language comes into wider use, the community will undoubtedly interact with the designers to consider real language changes and enhancements. I think the designers envision occasional meetings of the most interested parties at which such topics can be discussed, along the lines of an annual M3 users/implementors group meeting. But PLEASE don't claim that the language should be defined by the book definition plus the SRC compiler! We're working on a different compiler, and he SRC folks will admit (I believe) that the SRC compiler does not always implement the language as defined (what about integer overflow?). Well, enough soapbox, Eliot; back to work! -- 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 ======================================================================== 24 === Date: Sun, 8 Mar 1992 13:35:00 PST From: David Goldberg Subject: Re: Is there a definitive "definition of Modula-3"? Eloit Moss says: the SRC compiler does not always implement the language as defined (what about integer overflow?). I hate to pick nits, but the SRC compiler is correct with respect to integer overflow. As explained on page 54 of "Systems Programming with Modula-3", detecting integer overflow is not required. David Goldberg goldberg@parc.xerox.com ======================================================================== 25 === Date: Mon, 9 Mar 92 08:29:47 PST From: kalsow@src.dec.com (Bill Kalsow) Subject: Re: Is there a definitive "definition of Modula-3"? In article <1992Mar7.175233.17378@sni.ca>, doug@sni.ca (Doug Moen) writes: > Nelson's book is an informal description of Modula-3; it is also incomplete > and ambiguous. The ambiguities that exist in Greg's book are errors. If you'll point them out, we'll gladly fix them. When the SRC Modula-3 compiler disagrees with Greg's book, the compiler is in error. Again, please let us know and we'll fix it. Send bug reports to m3-request@src.dec.com. Thanks, - Bill Kalsow ======================================================================== 26 === Date: 9 Mar 92 19:03:36 GMT From: mayor@faraday.ece.cmu.edu (Gilberto S. Mayor) Subject: Looking for Public Domain Modula3 compiler Hi, I need a public-domain Modula-3 compiler. Does anyone know any site where I can get one (both UNIX and PC versions) ? Thanks in advance for all the responses, ' Gilberto Mayor ======================================================================== 27 === Date: Mon, 9 Mar 92 21:24:11 GMT From: chambers@klamath.cs.washington.edu (Craig Chambers) Subject: Re: Is there a definitive "definition of Modula-3"? In article <1992Mar9.162640.9346@sni.ca>, doug@sni.ca (Doug Moen) writes: |> >Eloit Moss says: |> > |> > the SRC compiler does not always |> > implement the language as defined (what about integer overflow?). |> |> David Goldberg writes: |> >I hate to pick nits, but the SRC compiler is correct with respect to |> >integer overflow. As explained on page 54 of "Systems Programming |> >with Modula-3", detecting integer overflow is not required. |> |> I've read page 54 over several times; it says nothing of the sort in |> my copy. Is there a new, revised 2nd edition of Systems Programming |> with Modula-3? |> -- |> Doug Moen | doug@sni.ca | uunet!snitor!doug I just got my Nelson book, so I looked this up. Overflow checking is controlled by the operations of the FloatMode interface (pp. 75-77). It appears possible for a legal implementation to ignore integer overflow (and other exceptions) and not support re-enabling this checking. See the SetBehavior and GetBehavior procedures. -- Craig Chambers ======================================================================== 28 === Date: Mon, 9 Mar 1992 16:26:40 GMT From: doug@sni.ca (Doug Moen) Subject: Re: Is there a definitive "definition of Modula-3"? >Eloit Moss says: > > the SRC compiler does not always > implement the language as defined (what about integer overflow?). David Goldberg writes: >I hate to pick nits, but the SRC compiler is correct with respect to >integer overflow. As explained on page 54 of "Systems Programming >with Modula-3", detecting integer overflow is not required. I've read page 54 over several times; it says nothing of the sort in my copy. Is there a new, revised 2nd edition of Systems Programming with Modula-3? -- Doug Moen | doug@sni.ca | uunet!snitor!doug ======================================================================== 29 === Date: 10 Mar 92 01:04:18 GMT From: thor@asgard.mty.itesm.mx (Antonio Quesada-Duarte) Subject: README File found in gatekeeper Hi there. I've just FTP'ed the modula3 sources found in gatekeeper.dec.com in pub/DEC/modula3/m3-2.0 Among other things, there is a README file coded in some strange page formatting language. Does anybody in netland know what should i use to decode it? I've tried using TeX but it didn't work (maybe i did something wrong). Any help will be greatly appreciated. Thanks a lot. >From Monterrey, MEXICO: Antonio Quesada-Duarte ======================================================================== 30 === Date: 10 Mar 92 03:26:18 GMT From: moss@cs.umass.edu (Eliot Moss) Subject: Re: Looking for Public Domain Modula3 compiler Do you really mean public domain, or do you mean you don't have to pay for it? Public domain means anybody can do anything with it, which is not true of a lot of free software, including most of the GNU stuff. To answer your question, you can pick up the SRC M3 compiler from gatekeeper.dec.com in pub/DEC/Modula-3; *read its license agreement*! Sometime we'll get our GNU M3 compiler done and you'll have a second source. SRC M3 runs on many Unix systems. There is no PC version of M3 yet. And guess what: all this info is in the FAQ for this news group, which you could have gotten by perusing the archives (on gatekeeper.dec.com, and probably other places, too) .... Eliot Moss -- 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 ======================================================================== 31 === Date: Mon, 9 Mar 92 18:39:57 PST From: muller@src.dec.com (Eric Muller) Subject: Re: README File found in gatekeeper Here is a plain text translation: What is available ================= SRC Modula-3 is distributed via anonymous ftp from gatekeeper.dec.com. The distribution is in a set of compressed files in the directory named pub/DEC/Modula-3/m3-2.0. The files are of the form archive-version.tar.Z; in the rest of the chapter, we will speak of the archive archive and forget the version numbers. The archives boot. are used to build and install m3make, a driver and a compiler. These programs are built from intermediate C files that are architecture specific; you need to get the archive(s) corresponding to the architecture(s) on which you want to install SRC Modula-3. The supported architectures are: Arch | Hardware | OS | build | install | | | disk | cpu | disk ------------------------------------------------------------------------------ AIX386 | | AIX/PS2 | | | AP3000 | Apollo DN4500 | Domain/OS 10.2 | | | ARM | Acorn R260 | RISC iX 1.21 | | | DS3100 | DECstation 5000/200 | Ultrix 4.2 | 23170 | 8 + 7 | 2758 HP300 | HP 9000/300 | HP-UX 7.0 | | | IBMR2 | IBM RISC System/6000 | AIX 3.1 | | | IBMRT | IBM RT | IBM/4.3 (AOS 4.3) | | | SPARC | Sparcstation-1 | SunOS 4.1.x | | | SUN3 | Sun 3/? | SunOS ? | | | UMAX | Encore Multimax | UMAX 4.3 (R4.1.1) | | | VAX | VAX 8800 | Ultrix 4.2 | | | Each of these archives is about 4000 kilobytes. The column ``Build'' indicates the resources you need to build the two programs: ``disk'' is the amount of disk space (in kilobytes), ``cpu'' is the amount of user and system cpu time (in minutes). The column ``Install'' indicates the amount of disk space that will be permanently used after the installation is done (in kilobytes). The other archives contain Modula-3 source files for various libraries and programs. File | Build | Inst | Contents Name | size | disk | cpu | disk | ------------------------------------------------------------------------------- libm3 | 1096 | 20374 | 8+4 | 5742 | base library X11R4 | 128 | 2906 | 4+1 | 1057 | binding interfaces to X11R4 trestle | 416 | 13245 | 14+3 | 4048 | Trestle window system, needs X11R4 pinecreek | 312 | 842 | 1+0 | 89 | Pine Creek Library bicycle | | | | | library for Trestle card games demos | 80 | 10446 | 4+1 | 0 | demo programs, needs trestle & bicycle data | 40 | 2693 | 2+1 | 856 | some generic container types color | 53 | 1559 | 1+1 | 483 | color manipulation sx | 168 | 2294 | 1+0 | 413 | Lisp-like S-expressions tools | 184 | 1746 | 1+0 | 548 | development tools compiler | 360 | 11255 | 12+5 | 0 | compiler driver | 66 | | | 0 | driver m3make | 44 | | | 0 | make for Modula-3 doc | | | | | the documentation for SRC Modula-3 tests | 336 | | | 0 | ``validation'' tests The column ``File Size'' is the size (in kilobytes) of the compressed tar file. The colum ``Build'' indicates the resources you need to build and install these pieces of sources: ``disk'' is the amount of disk space (in kilobytes), ``cpu'' is the amount of user and system cpu time (in minutes). The column ``Install'' indicates the amount of disk space that will be permanently used after the installation is done; if you want to keep the sources around, you will need more space. These time and sizes have been measured on a DECstation 5000/200 running Ultrix 4.2; other architectures may have different requirements. You need to build and install libm3 to have a useful system, but all the other pieces are optional. The m3make and doc archives are also contained in the boot archives. Getting SRC Modula-3 ==================== In the following, $ is the shell prompt and ftp> is the ftp prompt. To get SRC Modula-3: 1. Make sure that you have enough disk space using the tables above. 2. Create a fresh directory for the software and go there. Path names below are relative to that directory, and it will be called the top-level directory: $ mkdir top-level $ cd top-level 3. Open an connection with gatekeeper.dec.com [16.1.0.2]; give anonymous for the name and your login id for the password: $ ftp gatekeeper.dec.com Connected to gatekeeper.dec.com. ... Name (gatekeeper.dec.com): anonymous Password (gatekeeper.dec.com:anonymous): your name@ your machine ... 4. Change to the proper directory: ftp> cd pub/DEC/Modula-3/m3-2.0 5. Set the transmission type to binary: ftp> type binary 6. Get the files you want: ftp> get boot.-.tar.Z ftp> get libm3-.tar.Z ftp> get ... 7. Close the connection: ftp> quit 8. Uncompress and extract the files: $ zcat boot.-*.tar.Z | tar xpof - $ zcat libm3-*.tar.Z +|+ tar xpof - $ ... The arguments specify the following options: x: extract the files from the file to the current directory p: restore files to their original modes o: override the original ownership, this makes you the owner of the files f: use the following argument (e.g -) as the input file; - as the input file means stdin You can add the v option to see what is going on. 9. At this point you may delete the archives to save space (the disk requirements indicated above assume that you do delete these files): $ rm *.tar.Z Installation procedure ====================== See the toplevel README for what do. Note ==== The 2.03 top-level m3makefile does not work on SPARC. Apply the following path after you have uncompressed and extracted all the archives: *** m3makefile.old Fri Feb 7 23:52:18 1992 --- m3makefile Fri Feb 7 23:53:15 1992 *************** *** 145,146 **** --- 145,147 ---- #define machine_iter(x) @ @\ + all_##x:: @ @\ @for d in $(MACHINES); do \ @@\ *************** *** 149,158 **** ! all_cross:: ! machine_iter (cross) ! all_bootstrap_both:: ! machine_iter (bootstrap_both) ! all_bootstrap_scratch:: ! machine_iter (bootstrap_scratch) ! all_pack:: ! machine_iter (pack) --- 150,155 ---- ! machine_iter (cross) ! machine_iter (bootstrap_both) ! machine_iter (bootstrap_scratch) ! machine_iter (pack) -- Eric. ======================================================================== 32 === Date: 10 Mar 92 16:08:18 GMT From: harbison@bert.pinecreek.com (Sam Harbison) Subject: Modula-3 News #3 call for articles I am beginning to prepare the third issue of "Modula-3 News," a Modula-3 newsletter, and am requesting material to include. If you are teaching Modula-3 or writing software with it or developing Modula-3 products or services, send me a brief description. Anything related to Modula-3 is welcome. I typically edit all submissions (except ads), but will let you review the edited version. I hope that this issue will be the first one with real advertisements for Modula-3 products and services. (No charge for including them.) This is a paper newsletter, distributed free worldwide to people on our mailing list and at various conferences, etc. Plain-text electronic versions have also been distributed, without the photos, etc. If you would like to be on the mailing list and/or receive back issues, send me your name and address. Please submit material by the end of March, as I would like to send out the next issue in April, before schools begin to let out for the summer. 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. ======================================================================== 33 === Date: 11 Mar 92 13:53:42 GMT From: laverman@cs.rug.nl (Bert Laverman) Subject: SRC Modula-3 on the HP 9000/800 Dear All, Has anybody ever contemplated porting SRC-m3 to the HP 9000/800 system? I know there is a 9000/300 port, but the 800 is a RISC monster... I'm definately _not_ a 9000/800 wizard, but would be _very_ grateful for any tips and hints. Greetings, Bert -- #include Bert Laverman, Dept. of Computing Science, Groningen University Friendly mail to: laverman@cs.rug.nl The rest to: /dev/null ======================================================================== 34 === Date: 12 Mar 92 10:49:57 GMT From: btaplin@silver.ucs.indiana.edu (Brad Taplin) Subject: Windows development under Mod3? Hello. I have considered Pascal and Smalltalk as serious alternatives to C, which seems to me unsuited to Windows. Smalltalk is supposed to be good but requires enormous resources (say netters) and has a steep learning curve. Turbo Pascal might work, but supposedly has limitations. Actor 4.0 at $99 is something I haven't examined much. So, is there anything Mod3 can't do very well? Can it deal with DLLs and UAEs? Bugs? I wanna develop on the side with something more suited to prototyping than C but still able to produce clean, fast GUI executables. Please recommend sources. Will this require the SDK? Gotta run. Thanks for the info. ======================================================================== 35 === Date: 12 Mar 92 16:26:23 GMT From: abbasi@star.enet.dec.com (Nasser ABBASI) Subject: Modula-3 For scientific/mathematical programming ? in comp.lang.fortran there is some talk about fortran vs this language and that language, and i thought of Modula-3, has anyone looked at modula-3 from the point of view of using it for scientific programming? what's their experience with it in this regard? sorry if this sounds like a very general question. /nasser ======================================================================== 36 === Date: 12 Mar 92 14:25:20 GMT From: dagenais@vlsi.polymtl.ca (Michel Dagenais) Subject: Modula 3 and the Andrew system The CMU Andrew system just released newsletter includes a paragraph about Modula 3. FYI: > \bold{Modula-3 } - Although not the work of the Consortium, a related group > is developing a Modula-3 interface for ATK. The goal is bi-directional: > modula-3 objects will be able to invoke methods of ATK objects and ATK > objects will be able to call methods of modula-3 objects. Each will be able > to have pointers to the other. This magic is possible because the run-time > representations were originally close enough that the ATK object > representation could be modified sufficiently to match the modula-3 model. > The result is that future development can be done in the modula-3 environment > with automatic storage management, exceptions, an inter-module definition > language sufficient to support strong typing in function calls, and numerous > other pleasantries. (Unfortunately, the ATK portion of the system will still > not have storage management.) -- --------------------------------------------------------------------- Prof. Michel Dagenais dagenais@vlsi.polymtl.ca Dept of Electrical and Computer Eng. Ecole Polytechnique de Montreal tel: (514) 340-4029 --------------------------------------------------------------------- ======================================================================== 37 === Date: Thu, 12 Mar 92 17:37:13 +0100 From: Piet van Oostrum Subject: Re: Modula-3 on HP300 vs HP700 >>>>> SCHWEIZER@eldi.epfl.ch (PS) writes: PS> Dear Sir PS> I got the Modula-3 system from gatekeeper.dec.com and try to install you r HP300 version on a HP700. PS> Unfortunatly, the 700 serie has not too much ion common with the 300 PS> serie. After some bad tricks, I got the driver and compiler compiled, PS> but both crashes in the early steps of the library initialisation, PS> namely in RTMain__installSignalsHandler(). PS> Please could you confirm that it is really needed to cross-compile, PS> i.e. there is no way to just try to recompile the c-code. PS> Perhaps could you comment the message I posted : PS> Subject: Modula-3 on HP900/700 PS> Date: 12 Mar 92 14:06:43 GMT PS> From: SCHWEIZER@eldi.epfl.ch (NICOUD) PS> Organization: Ecole Polytechnique Federale de Lausanne, Dpt d'informatique PS> Dear Modula enthousiasts PS> One of the last message asked about a port to the HP 800 series. PS> I am trying toport on the HP 700 series (model 720) which is said to be PS> highly compatible with the 800 serie. PS> I started from the HP300 version available on gatekeeper.dec.com, but PS> have not succeded. First, just avoid to compile the m3make, it is not PS> easy, and perhaps not really needed for a first try. ============================== This problem is probably caused by the make program. A solution is to use the gnu make. By the way this problem also appears on the HP300. ============================== PS> BUT, there is one file in assembly language : alloca.s ============================== This can be circumvented by including libPW (-lPW) on the loader commands. ============================== PS> On the link command, note the -lBSD to link with the BSD library, required PS> by the sigvec subroutine. PS> However, m3 crashes after 10 instructions. In RTMain__InstallSignalsHandler (), PS> at the time he tries to clear (initialize) a sigvec variable. He uses PS> _ZERO( 40, vs) to clear 40 bytes. So it seems that the size of variables ar e PS> determined by the compiler DEPENDING ON THE TARGET (perhaps by parsing some .h PS> files for the specific target ?) ============================== This is right ============================== I have found why this problem occurs. It should probably also give problems on HP9000/300 systems. There is a wrong definition in Usignal.i3. The definition of sigvec is: struct_sigvec = RECORD sv_handler: SignalHandler; (* signal handler *) sv_mask: sigset_t; (* signal mask to apply *) sv_flags: int; (* see signal options below *) END; It should be struct_sigvec = RECORD sv_handler: SignalHandler; (* signal handler *) sv_mask: int; (* signal mask to apply *) sv_flags: int; (* see signal options below *) END; I think it would be savest if somebody with a good compiler (e.g. the developers) recompiled the thing. I can try to recompile, but I don't know if my compiler (with the above bug) is good enough. Piet* van Oostrum, Dept of Computer Science, Utrecht University, Padualaan 14, P.O. Box 80.089, 3508 TB Utrecht, The Netherlands. Telephone: +31 30 531806 Uucp: uunet!mcsun!ruuinf!piet Telefax: +31 30 513791 Internet: piet@cs.ruu.nl (*`Pete') ======================================================================== 38 === Date: 12 Mar 92 14:06:43 GMT From: SCHWEIZER@eldi.epfl.ch (NICOUD) Subject: Modula-3 on HP900/700 Dear Modula enthousiasts One of the last message asked about a port to the HP 800 series. I am trying toport on the HP 700 series (model 720) which is said to be highly compatible with the 800 serie. I started from the HP300 version available on gatekeeper.dec.com, but have not succeded. First, just avoid to compile the m3make, it is not easy, and perhaps not really needed for a first try. the other way to go is: cd driver/boot-HP300 cc -cg *.c cc -om3 *.o -lBSD cd .. cd compiler/boot-HP300 and also compile in the same way BUT, there is one file in assembly language : alloca.s you can try to create instead a file alloca.c with inside : #include void *alloca( size) int size; { return malloc( size ); } On the link command, note the -lBSD to link with the BSD library, required by the sigvec subroutine. So, everything compiles and links smoothly. However, m3 crashes after 10 instructions. In RTMain__InstallSignalsHandler(), at the time he tries to clear (initialize) a sigvec variable. He uses _ZERO( 40, vs) to clear 40 bytes. So it seems that the size of variables are determined by the compiler DEPENDING ON THE TARGET (perhaps by parsing some .h files for the specific target ?) Can any body confirm/inform ? Aside this, I would greatly appreciate if somebody has already done the port (I am not a U**X guru) Thanks in advance Philippe Schweizer schweize@eldi.epfl.ch tel 011 41 21 801 72 71 fax 011 (41) (21) 802 13 00 (switzerland) ======================================================================== 39 === Date: 12 Mar 92 19:29:07 GMT From: chased@rbbb.Eng.Sun.COM (David Chase) Subject: Re: Modula-3 For scientific/mathematical programming ? In article <34151@nntpd.lkg.dec.com> abbasi@star.enet.dec.com (Nasser ABBASI) w rites: >has anyone looked at modula-3 from the point of view of using it for >scientific programming? what's their experience with it in this regard? Little experience, but the ability to declare a parameter to be a multi-dimensional open array was provided specifically to be friendly to scientific programming. Thus, one can say: PROCEDURE GEPP (VAR a:ARRAY OF ARRAY OF FLOAT; VAR pivot : ARRAY OF INT; VAR condition_number : FLOAT) Maniacal array mutiliation in the style of Fortran is not permitted, but you are not as constrained as you are in C or Pascal or Modula-2. Subarrays can be taken, but all you get are subsections of the leading (row) dimension -- you cannot use subarrays to tile a matrix. This was more or less the point of compromise. By keeping that restriction, multi-dimensional open arrays are never more expensive than their Modula-2 equivalent (which is often "illegal", or "infinite cost"). "Obviously" all the descriptor manipulation is amenable to classical optimization techniques, so if there is ever sufficient demand for an optimizing Modula-3 compiler, it will not be an insurmountable task to make Fortran-in-Modula-3 run well. Nested functions are another big plus for numerical work that is unavailable in either F77 or C. I also found that exception handling was quite a handy tool when I wrote a little dinky Newton-solver -- if it fails to converge, it raises an exception. One thing that is missing that I still hope to see in the language (someday) is a declarations of VAR IN VAR OUT and possibly VAR IN_OUT (* Like VAR, but different aliasing rules. *) The intent is that these parameters have "Fortran aliasing rules", which can be translated to "either by reference or value-result, and if your program can tell the difference, then it is illegal". This has obvious benefits for systems that wish to support RPC (copy-in, copy-out), and obvious (to Fortran optimizer-writers) benefits for code restructuring optimizations that increase cache locality, parallelism, and register reuse. I believe that these additional keywords could be added with little damage to the existing legal prorgams -- "IN" is already a keyword, and if we wanted we could say "VAR RETURN" instead of "VAR OUT" to avoid accidental clashes with legal programs. (However, one should not get too cute with this game.) Those are about the only concrete proposals. There's been some muttering from friends of mine about the usefulness of something like "FORALL", meaning "run all the iterations in any order, using threads if it helps, but not if it doesn't", but a definite proposal never came out of it. David Chase Sun ======================================================================== 40 === Date: Thu, 12 Mar 1992 14:07:25 PST From: David Goldberg Subject: Re: Modula-3 For scientific/mathematical programming ? Yes, I have looked at using Modula-3 for scientific programming. Overall, it is my (highly biased) opinion that Modula-3 is almost as good as FORTRAN for scientific computing. First of all, there are the general plusses of Modula-3: strong typing, interfaces, etc. For mathematical uses, some of the advantages are (1) generics, so that you can generate the single and double precision versions of programs automatically, (2) three float-types, so that you can access extended precision (on machines which have it) in a portable way, (3) good control over floating-point arithmetic. There are built-in floating-point interfaces which let you easily get the values of machine epsilon, smallest representable number, etc.; a standard (i.e. required interface) way to access IEEE arithmetic (such as rounding modes) on machines that have it, ability to query the type of arithmetic being used, and the ability to query (and manipulate) how a machine handles exceptions like overflow. Thus programs can deal with rounding, overflows, and underflows in a portable way (portable across machines that implement Modula-3, that is). The disadvantages are much like C, Pascal, etc: (1) no built-in complex type, (2) no built-in exponential function (3) arrays don't match FORTRAN (they are zero-based and stored by row, not column) (4) there isn't a standard required math library for transcendentals (5) no simple way to specify floating-point constants exactly (i.e. in binary). However, unlike C and Pascal, Modula-3 does handle functions that take arbitrary-length arrays as arguments: the size of an array argument can be instantiated at call-time. There is also a disadvantage of the current Modula-3 compiler from SRC, which is that it generates C, and thus has to work around C's propensity to automatically promote float to double. David Goldberg goldberg@parc.xerox.com ======================================================================== 41 === Date: Thu, 12 Mar 92 11:53:32 PST From: muller@src.dec.com (Eric Muller) Subject: Re: Modula-3 on HP300 vs HP700 We are going to make a release either tomorrow or monday (2.04). I will send a message with the details at that time, but here are some news for the HP world. > PS> BUT, there is one file in assembly language : alloca.s > ============================== > This can be circumvented by including libPW (-lPW) on the loader commands. We got rid of alloca in the new version. > There is a wrong definition in Usignal.i3. The definition of sigvec is: > > > struct_sigvec = RECORD > sv_handler: SignalHandler; (* signal handler *) > sv_mask: sigset_t; (* signal mask to apply *) > sv_flags: int; (* see signal options below *) END; > > > It should be > > > struct_sigvec = RECORD > sv_handler: SignalHandler; (* signal handler *) > sv_mask: int; (* signal mask to apply *) > sv_flags: int; (* see signal options below *) END; > Fixed. I suspect that the same change should be made to the strct_sigaction type declaration that is just above it ? -- Eric. ======================================================================== 42 === Date: 12 Mar 92 20:15:59 GMT From: kalakota@ut-emx.uucp (Ravi Kalakota) Subject: O-O maintanence -- A myth ? Easy maintenence in O-O environments -- A myth?? The two oft-cited advantages of O-Based and O-Oriented approaches have been code (and design) reuse and easy extensibility and modifiability. Code reuse has brought about substantial reduction in the size of new code that has to be generated and also the size of the overall system. As the code size becomes less, the complexity of the system increases dramatically. Does complexity affect maintenence? Probably not in a simple project. But in a large system ... Software maintanence usually takes anywhere between 60-90% of the software budget, according to popular literature. Has O-O-P really affected this figure? I would like to gather information and data on this and your views (either pro/con). Another important issue is that could be discussed is -- whether O-O-P is a strategic advantage versus a strategic necessity in today's business world. Please e-mail your thoughts/views to me and I will summarize. Ravi Kalakota Centre for Information Systems Management University of Texas at Austin e-mail : kalakota@emx.utexas.edu ======================================================================== 43 === Date: Thu, 12 Mar 92 12:30:21 PST From: muller@src.dec.com (Eric Muller) Subject: Re: Modula-3 For scientific/mathematical programming ? I suppose that the presence of three real types (REAL, LONGREAL and EXTENDED), that are supposed to match IEEE types whenever possible, will be useful. Also, the standard floating point interfaces give some access to the floating point runtime: for example, you can specify that floating point exceptions should be mapped to Modula-3 exceptions. The integration of these things in the language will probably help a lot the portability of floating point programs. Many thanks to David Goldberg for designing these interfaces. The current status of the implementations is not quite as nice. SRC Modula-3 2.04 (coming soon) implements these interfaces for DS3100 and SPARC (the status is not yet thread-specific, but that should come soon). -- Eric. ======================================================================== 44 === Date: 12 Mar 92 16:00:58 GMT From: piet@cs.ruu.nl (Piet van Oostrum) Subject: Re: SRC Modula-3 on the HP 9000/800 >>>>> laverman@cs.rug.nl (Bert Laverman) (BL) writes: BL> Dear All, BL> Has anybody ever contemplated porting SRC-m3 to the HP 9000/800 system? BL> I know there is a 9000/300 port, but the 800 is a RISC monster... BL> I'm definately _not_ a 9000/800 wizard, but would be _very_ grateful BL> for any tips and hints. I have contemplated this (actually for the 700 which is very similar). I will try this probably next week. Please note that a number of problems have been found with the HP version. -- Piet van Oostrum ======================================================================== 45 === Date: Fri, 13 Mar 92 11:41:55 +0100 From: Piet van Oostrum Subject: Re: Modula-3 on HP300 vs HP700 >>>>> muller@src.dec.com (Eric Muller) (EM) writes: EM> We are going to make a release either tomorrow or monday (2.04). I EM> will send a message with the details at that time, but here are some EM> news for the HP world. EM> Fixed. I suspect that the same change should be made to the strct_sigactio n EM> type declaration that is just above it ? No the sigaction should contain the sigset. from signal.h: /* Structures used with POSIX signal facilities. */ # ifdef _INCLUDE_HPUX_SOURCE typedef struct __sigset_t { long sigset[8]; } sigset_t; # else /* not _INCLUDE_HPUX_SOURCE */ typedef struct __sigset_t { long __sigset[8]; } sigset_t; # endif /* _INCLUDE_HPUX_SOURCE */ struct sigaction { void (*sa_handler)(__harg); /* SIG_DFL, SIG_IGN, or pointer to a func */ sigset_t sa_mask; /* Additional set of signals to be blocked during execution of signal-catching function. */ int sa_flags; /* Special flags to affect behavior of sig */ }; struct sigstack { /* Used with sigstack(). */ char *ss_sp; /* signal stack pointer */ int ss_onstack; /* current status */ }; struct sigvec { /* Used with sigvec() and sigvector(). */ void (*sv_handler)(__harg); /* signal handler */ int sv_mask; /* signal mask to apply */ int sv_flags; /* see below */ }; By the way, I found why the HPUX make doesn't work with imake: This make does not allow the use of comments in the rules. Some m3makefiles have #if sections in the rules and cpp translate these into a # linenumber. So ideally imake should filter out the # comment lines from the output of cpp. Did you receive my earlier comments about the HP port? Anyway, here is what I collected thus far: 1. compiler error (register allocation error). This is a serious compiler error in HP-UX 8.0. In some cases it goes away by using -O (on AutoFlushWr.m in the compiler/driver and libm3), but in trestle there are cases where this doesn't help. Use -O in m3makefiles and m3make/toplevel.tmpl 2. -lBSD missing 3. config says INCLDIR, m3makefile says $(INCL). 4. test does not exist in csh (used in m3make.model). Better replace with if (-d)... For now I created the following shell script called test: ------------------------------------------------------------------------ #! /bin/sh test "$@" ------------------------------------------------------------------------ 5. alloca.s is better than the built-in alloca (from libBSD or libPW?) but only on HP9000/300. Otherwise use -lPW. 6. dtoa.c must be updated. It should define #define IEEE_MC68k. Here are the diffs that I used for the compiler: (The dtoa.c thing and the Floating Point interfaces have to be looked into more seriously I think, but for the moment they might suffice.) libm3 needs also a -O for AutoFlushWr. I am not happy with this because I don't trust the -O. I have seen too many programs fail with -O and succeed with +O1, but this compiler bug also bites with +O1. Good luck! ------------------------------------------------------------------------ *** m3make/config/config.~1~ Thu Feb 13 14:22:33 1992 --- m3make/config/config Thu Mar 12 17:25:25 1992 *************** *** 114,120 **** KEEP_LIBRARIES_RESOLVED = 0 /* We don't want to use the predefined CFLAGS */ ! CFLAGS = -O /* Some versions of make(1) let us specify the shell to use. In any case, we want sh */ --- 115,121 ---- KEEP_LIBRARIES_RESOLVED = 0 /* We don't want to use the predefined CFLAGS */ ! CFLAGS = /* Some versions of make(1) let us specify the shell to use. In any case, we want sh */ *** m3make/toplevel.tmpl.~1~ Wed Feb 5 22:11:06 1992 --- m3make/toplevel.tmpl Tue Feb 25 12:39:26 1992 *************** *** 17,23 **** M3 = $(BIN_USE)/m3 /* $(BIN_USE) to go around a bug in Ultrix 4.2 make */ M3FLAGS = -w1 -make -why ! M3OPT = -g M3DEFPATH = M3LIBPATH = DO_M3 = $(M3) $(M3FLAGS) $(M3OPT) $(M3DEFPATH) $(M3LIBPATH) --- 17,23 ---- M3 = $(BIN_USE)/m3 /* $(BIN_USE) to go around a bug in Ultrix 4.2 make */ M3FLAGS = -w1 -make -why ! M3OPT = -O M3DEFPATH = M3LIBPATH = DO_M3 = $(M3) $(M3FLAGS) $(M3OPT) $(M3DEFPATH) $(M3LIBPATH) *** m3make/makefile.~1~ Sun Feb 2 07:50:31 1992 --- m3make/makefile Thu Mar 12 17:26:28 1992 *************** *** 1,3 **** --- 1,4 ---- + SHELL=/bin/sh all:: imake call_m3make imake: imake.c config/config *** driver/boot-HP300/m3makefile.objs.~1~ Thu Feb 6 11:13:39 1992 --- driver/boot-HP300/m3makefile.objs Thu Feb 13 15:01:41 1992 *************** *** 228,230 **** --- 228,233 ---- Usignal_m.o \ Utypes_m.o \ _m3main.o + + AutoFlushWr_m.o: AutoFlushWr_m.c + IFS=' $(SEP)'; $(PASS1) -c -O AutoFlushWr_m.c *** driver/boot-HP300/dtoa.c.~1~ Tue Feb 4 11:39:57 1992 --- driver/boot-HP300/dtoa.c Thu Feb 13 16:22:50 1992 *************** *** 2,9 **** #define KR_headers #endif ! #ifndef IEEE_8087 ! #define IEEE_8087 #endif #include "dtoa.h" --- 2,9 ---- #define KR_headers #endif ! #ifndef IEEE_MC68k ! #define IEEE_MC68k #endif #include "dtoa.h" *** driver/src/m3makefile.~1~ Thu Feb 6 10:28:34 1992 --- driver/src/m3makefile Thu Feb 13 15:16:55 1992 *************** *** 32,38 **** all:: m3 m3:: $(OBJS) ! IFS=' $(SEP)'; $(PASS2) -o m3 $(OBJS) -lm .c.o: IFS=' $(SEP)'; $(PASS1) -c $< --- 32,38 ---- all:: m3 m3:: $(OBJS) ! IFS=' $(SEP)'; $(PASS2) -o m3 $(OBJS) -lBSD -lm .c.o: IFS=' $(SEP)'; $(PASS1) -c $< *** compiler/boot-HP300/m3makefile.objs.~1~ Thu Feb 6 11:12:15 1992 --- compiler/boot-HP300/m3makefile.objs Thu Feb 13 15:02:44 1992 *************** *** 561,563 **** --- 561,566 ---- Usignal_m.o \ Utypes_m.o \ _m3main.o + + AutoFlushWr_m.o: AutoFlushWr_m.c + IFS=' $(SEP)'; $(PASS1) -c -O AutoFlushWr_m.c *** compiler/boot-HP300/dtoa.c.~1~ Tue Feb 4 10:29:41 1992 --- compiler/boot-HP300/dtoa.c Thu Feb 13 16:23:09 1992 *************** *** 2,9 **** #define KR_headers #endif ! #ifndef IEEE_8087 ! #define IEEE_8087 #endif #include "dtoa.h" --- 2,9 ---- #define KR_headers #endif ! #ifndef IEEE_MC68k ! #define IEEE_MC68k #endif #include "dtoa.h" *** compiler/src/m3makefile.~1~ Thu Feb 6 10:29:17 1992 --- compiler/src/m3makefile Thu Feb 13 15:17:10 1992 *************** *** 10,16 **** all:: m3compiler m3compiler:: $(OBJS) ! IFS=' $(SEP)'; $(PASS2) -o m3compiler $(OBJS) -lm .c.o: IFS=' $(SEP)'; $(PASS1) -c $< --- 10,16 ---- all:: m3compiler m3compiler:: $(OBJS) ! IFS=' $(SEP)'; $(PASS2) -o m3compiler $(OBJS) -lBSD -lm .c.o: IFS=' $(SEP)'; $(PASS1) -c $< *** libm3/Csupport/src/HP300/dtoa.c.~1~ Thu Jan 30 07:08:38 1992 --- libm3/Csupport/src/HP300/dtoa.c Thu Feb 13 16:23:35 1992 *************** *** 2,9 **** #define KR_headers #endif ! #ifndef IEEE_8087 ! #define IEEE_8087 #endif #include "dtoa.h" --- 2,9 ---- #define KR_headers #endif ! #ifndef IEEE_MC68k ! #define IEEE_MC68k #endif #include "dtoa.h" ------------------------------------------------------------------------ Piet* van Oostrum, Dept of Computer Science, Utrecht University, Padualaan 14, P.O. Box 80.089, 3508 TB Utrecht, The Netherlands. Telephone: +31 30 531806 Uucp: uunet!mcsun!ruuinf!piet Telefax: +31 30 513791 Internet: piet@cs.ruu.nl (*`Pete') ======================================================================== 46 === Date: 13 Mar 92 11:02:06 GMT From: qs101@cl.cam.ac.uk (Quentin Stafford-Fraser) Subject: Re: Windows development under Mod3? In article <1992Mar12.055006.7578@bronze.ucs.indiana.edu>, btaplin@silver.ucs.indiana.edu (Brad Taplin) writes: |> So, is there anything Mod3 can't do very well? Err, yes. It won't run on a PC. Please, someone, tell me I'm wrong... ----------------------------------- Quentin Stafford-Fraser Cambridge University Computer Lab qs101@cl.cam.ac.uk Tel +44 223 334645 ----------------------------------- ======================================================================== 47 === Date: 13 Mar 92 15:45:31 GMT From: harbison@bert.pinecreek.com (Sam Harbison) Subject: Re: Windows development under Mod3? In article <1992Mar13.110206.22438@cl.cam.ac.uk> qs101@cl.cam.ac.uk (Quentin St afford-Fraser) writes: >... >Err, yes. It won't run on a PC. > >Please, someone, tell me I'm wrong... >... After having looked at SRC Modula-3 2.0's "bootstrap" structure and at the next generation of PC tools (in particular, the 32-bit compilers from Microsoft and Borland due summer/fall), I think a PC port of SRC Modula-3 is now feasible. An OS/2 port could begin as soon as IBM ships OS/2 2.0 this month, since it will have a full 32-bit development environment. So, if you're interested, get to work... 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. ======================================================================== 48 === Date: 13 Mar 92 16:01:59 GMT From: mar19@cl.cam.ac.uk (M.A. Ramage) Subject: Re: Windows development under Mod3? In article <1992Mar12.055006.7578@bronze.ucs.indiana.edu> btaplin@silver.ucs.in diana.edu (Brad Taplin) writes: > > Hello. I have considered Pascal and Smalltalk as serious > alternatives to C, which seems to me unsuited to Windows. > Smalltalk is supposed to be good but requires enormous > resources (say netters) and has a steep learning curve. > Turbo Pascal might work, but supposedly has limitations. > Actor 4.0 at $99 is something I haven't examined much. > > So, is there anything Mod3 can't do very well? Can it > deal with DLLs and UAEs? Bugs? I wanna develop on the > side with something more suited to prototyping than C > but still able to produce clean, fast GUI executables. > Please recommend sources. Will this require the SDK? > > Gotta run. Thanks for the info. Well, there's a fundamental problem... There isn't yet a Modula-3 compiler for the PC, and even when one comes out I doubt it'll be Windows compatible. I'd recommend Turbo Pascal for Windows, it's got lots of class libraries so you can program reasonably efficiently without too much recourse to using the Windows Application Programming Interface (API) - though you might find it necessary for some things. I entirely sympathise with you about disliking C, I think it's an abomination o f a language (and C++ isn't much better). TPW has its limitations, but it's probably the best development environment for Windows just now. ---- Magnus Ramage mar19@phx.cam.ac.uk Undergraduate computer scientist but I'm not spotty honest guv. I'm spending far too much time using Windows though... ======================================================================== 49 === Date: 13 Mar 92 21:50:41 GMT From: mbk@lyapunov.ucsd.edu (Matt Kennel) Subject: Re: Modula-3 For scientific/mathematical programming ? chased@rbbb.Eng.Sun.COM (David Chase) writes: : In article <34151@nntpd.lkg.dec.com> abbasi@star.enet.dec.com (Nasser ABBASI) writes: : >has anyone looked at modula-3 from the point of view of using it for : >scientific programming? what's their experience with it in this regard? : Little experience, but the ability to declare a parameter to be a : multi-dimensional open array was provided specifically to be friendly : to scientific programming. : : Those are about the only concrete proposals. There's been some : muttering from friends of mine about the usefulness of something like : "FORALL", meaning "run all the iterations in any order, using threads : if it helps, but not if it doesn't", but a definite proposal never : came out of it. Have you been reading the present thread in comp.lang.misc and comp.lang.fortran? A few people have been asking for a language that understands essentially summation conventions and general index notation, as used in undergraduate math. So, in some sort of vague psuedocode: for i,j: C(i,j) = sum k : A(i,k) * B(j,k) Which says C = A * Transpose(B) in a straightforward way, of course, assuming it can figure out the array bounds for i,j,k, which is often not much a problem. (And the "sum" is an expression, not part of a statement). And/or how about a new integer type INDEX, which makes the sums and foralls implicit for all repeated indices? This is a lollipop purely for the numerical community, but as even Fortran 90 doesn't do this, it might enormously increase the base of appeal for a new language. All of a sudden, people who would have never bothered to learn ("Oh it's just another silly CS poofta weenie DissertationLanguage") will listen carefully. I've stopped learning C++, thinking it's really ugly (even though I already program in C these days), hoping that Modula-3 will be better. If it would be better than even new fortran for numerical work plus decent OOP features plus garbage collection... Wow!! Ppupupupupupppppplease? :-) Why not try and make it really really excellent before you have the crushing burden of backwards compatibility? : David Chase : Sun Matt Kennel mbk@inls1.ucsd.edu ======================================================================== 50 === Date: 13 Mar 92 23:41:43 GMT From: chased@rbbb.Eng.Sun.COM (David Chase) Subject: Re: Modula-3 For scientific/mathematical programming ? In article mbk@lyapunov.ucsd.edu (Matt Kennel) writes: >Have you been reading the present thread in comp.lang.misc and >comp.lang.fortran? >So, in some sort of vague psuedocode: > for i,j: C(i,j) = sum k : A(i,k) * B(j,k) >Which says C = A * Transpose(B) in a straightforward way, of course, assuming >it can figure out the array bounds for i,j,k, which is often not much >a problem. (And the "sum" is an expression, not part of a statement). >Why not try and make it really really excellent before you have the crushing >burden of backwards compatibility? There's a couple of things to note -- first, I'm a member of the peanut gallery, not the committee proper (though people on the committee read this stuff). I had some influence on the original language, but I was hardly one of its definers. Second, there is a definite "Modula tradition" that is followed in the language. I don't know if this is a bug or a feature; it seems to depend on what one is familiar with. You'd have to make an effort to get your syntax into the "Modula tradition", just for starters. (I'll have a shot at it, below.) Third problem is that "really really excellent" is very subjective. Given the C++ experience, it looks a policy of "just say 'no' to nifty new features" is probably a wise one. Also, the net is not someplace that I'd for for deep thoughts and reasoned argument. If you were asking me what *I* wanted for *my* programming, as opposed to what I think would make the language successful, I'd be very interested in closures. It is possible to close over both object methods and over nested functions (in fact, given that traced objects are managed by the garbage collector, method closures are a no-brainer). I'd also lobby hard for anonymous functions (lambda expressions, more or less). I thought for a moment about automatic coercion of expressions to lambda expressions, but I think I can demonstrate why that is not going to fly (see example far below). Now, about your array syntax. I think you had two things going on there -- one was the sum expression, the other was the "forall array elements i and j". Offhand, I'd have to admit to a little bit of queasiness here. My first try at syntax came out looking sufficiently like a function that maybe you ought to try writing it that way first: (Here follows my first use ever of a generic interface:) GENERIC INTERFACE G(Result); PROCEDURE Sum(from,to,by:INTEGER; PROCEDURE Plus(x,y:Result.T):Result.T; PROCEDURE Element(i:INTEGER):Result.T) : Result.T; END G. GENERIC MODULE G(Result); PROCEDURE Sum(from,to,by:INTEGER; PROCEDURE Plus(x,y:Result.T):Result.T; PROCEDURE Element(i:INTEGER):Result.T) : Result.T = VAR i:INTEGER; VAR accumulator:Result.T := Result.Zero. BEGIN FOR i := from TO to BY by DO accumulator := Plus(accumulator,Element(i)); END; RETURN accumulator; END Sum; END G. INTERFACE Float; TYPE T = FLOAT; CONST Zero : FLOAT = 0.0; PROCEDURE Plus(x,y:T):T; END Float; INTERFACE Floatsum = G(Float) END Floatsum. MODULE Floatsum = G(Float) END Floatsum. So, in my code I might say: VAR a : REF ARRAY OF ARRAY OF FLOAT; VAR j:INTEGER; PROCEDURE Bogus(INTEGER i) : FLOAT = BEGIN RETURN a[i,j]; END; ... x := Floatsum.Sum(1,n,1,Float.Plus,Bogus); Of course, if we had lambda expressions (I'll use constructor syntax with a procedure type): VAR a : REF ARRAY OF FLOAT; VAR j:INTEGER; ... x := Floatsum.Sum(1,n,1,Float.Plus,PROCEDURE(i:INTEGER):FLOAT{a[i,j]}); Now, if we had automatic coercion of expressions into functions, we might try writing: VAR a : REF ARRAY OF FLOAT; VAR j:INTEGER; ... x := Floatsum.Sum(1,n,1,Float.Plus,a[i,j]); This works, just this once, because we can see that we have an expression with one unbound integer (i) that could yield a float, in a context where a procedure from an integer to a float is called for. Thus, there is exactly one way to "Do What I Mean". Suppose I had instead written: VAR a : REF ARRAY OF FLOAT; VAR i,j:INTEGER; (* <----- Note the declaration of i *) ... x := Floatsum.Sum(1,n,1,Float.Plus,a[i,j]); Now there's no unbound integer -- what do I mean in this case? So, the situation is not perfect, but it isn't as horrible as you might have thought. Presumably (if you think this is important) you could look into defining a standard library of these combining functions. They could be inlined, of course. Of course, the syntax for defining "temporary" procedures is pretty horrid. It's that good old Modula tradition again. It would be far nicer if we could have a ton of optional syntax -- for example, in the above, if we could say x := Floatsum.Sum(1,n,1,Float.Plus,PROCEDURE(i){a[i,j]}); and rely on the type checker to infer that in fact, i is an integer, and the result type is a float. But, (to debate with myself) what about procedures that return nothing? We have no syntax for them. Grumble, grumble. I think I'd wave my arms at this point (if I were on the committee) and say "shorthand, shorthand". After all, that's really what you wanted, isn't it? It's kind of a shame that PROCEDURE has so many letters in it. Well, I'm all tuckered out now, and I didn't even get to the elementwise array assignment. I hope this was enlightening on more than one level -- here's one way to do what you want in M3, here's another person's view on what is "really really excellent" (and it isn't the same as your view), and here's an example of how things don't always turn out as planned (in tis case, anonymous lambda expressions). David Chase Sun ======================================================================== 51 === Date: 13 Mar 92 20:54:39 GMT From: do12+@andrew.cmu.edu (Dick Orgass) Subject: Re: Windows development under Mod3? It may actually be possible to bring up Modula-3 on DOS 5 for 386 and higher machines. There's a DOS 32-bit port of gcc and g++ together with what appears to be an adequate but not great library. The compiler actually uses ld, ar, as, etc from GNU and ld produces an a.out file. There's a stub program that converts the a.out into a .exe. This might well be enough to bring up the compiler, driver and large parts of the library. My guess is that the big question is using setjmp/longjmp to implement threads. The compiler itself is supposed to have been compiled by gcc in the usual way and seems to run well on a 16 Mhz machine with 10Meg. I haven't done enough with it to have more of an opinion. The compiler itself can be found in directory /pub/msdos/djgpp on grape.ecs.clarkson.edu [128.153.28.12]. Dick ======================================================================== 52 === Date: 14 Mar 92 00:15:02 GMT From: mbk@lyapunov.ucsd.edu (Matt Kennel) Subject: Re: Modula-3 For scientific/mathematical programming ? goldberg@parc.xerox.com (David Goldberg) writes: : Yes, I have looked at using Modula-3 for scientific programming. : Overall, it is my (highly biased) opinion that Modula-3 is almost as : good as FORTRAN for scientific computing. : : First of all, there are the general plusses of Modula-3: strong typing, : interfaces, etc. : Fine, but many languages have those. : For mathematical uses, some of the advantages are (1) generics, so that : you can generate the single and double precision versions of programs : automatically, (2) three float-types, so that you can access extended : precision (on machines which have it) in a portable way, (3) good : control over floating-point arithmetic. There are built-in : floating-point interfaces which let you easily get the values of machine : epsilon, smallest representable number, etc.; a standard (i.e. required : interface) way to access IEEE arithmetic (such as rounding modes) on : machines that have it, ability to query the type of arithmetic being : used, and the ability to query (and manipulate) how a machine handles : exceptions like overflow. Thus programs can deal with rounding, : overflows, and underflows in a portable way (portable across machines : that implement Modula-3, that is). Those are small details from my point of view. : : The disadvantages are much like C, Pascal, etc: (1) no built-in complex : type, (2) no built-in exponential function These are big omissions, though. : (3) arrays don't match : FORTRAN (they are zero-based and stored by row, not column) No big deal. : (4) there : isn't a standard required math library for transcendentals A Big deal. :-( : (5) no simple : way to specify floating-point constants exactly (i.e. in binary). A little deal. : However, unlike C and Pascal, Modula-3 does handle functions that take : arbitrary-length arrays as arguments: the size of an array argument can : be instantiated at call-time. Non crippled. Good. I have the feeling that computer scientists have an odd idea of what is really important for scentific programming: according to their language decisions(actions not words), it's critical to get floating point interfaces for "machine epsilon", a standard way of getting at those damn IEEE "rounding modes", and manipulate how to handle "overflow", and yet, no complex numbers, few standard mathematical functions, no exponentiation, no *good* array support. Great on the details and lousy on the big picture. So raise you hand if you want Modula-4 or Oberon-3... : David Goldberg : goldberg@parc.xerox.com ======================================================================== 53 === Date: Fri, 13 Mar 92 21:01:17 PST From: Subject: Re: Modula-3, Fortran, Numbers & Aliens > [Matt Kennel:] So here's the problem: Write a program to do... > > for i,j: C(i,j) = sum k : A(i,k) * B(j,k) > > Which says C = A * Transpose(B) in a straightforward way, of course, > assuming it can figure out the array bounds for i,j,k, which is > often not much a problem. (And the "sum" is an expression, not > part of a statement). > > [...] > > Sheesh. I think i'll stick with > DO I=1,N > DO J=1,N > SUM = 0.0 > DO K=1,N > SUM = SUM + B(I,K) * C(J,K) > ENDDO > A(I,J) = AUM > ENDDO > ENDDO Well, don't let David's elucubrations scare you too much. In Modula 3 you CAN use meat-and-potatoes FOR loops: FOR i := 1 TO N DO FOR j := 1 TO N DO VAR sum: REAL := 0.0; BEGIN FOR k := 1 TO N DO sum := sum + B[i,k] * C[j,k] END; A[i,j] := sum END END END Or, also, FOR i := 1 TO N DO WITH ai = A[i], bi = B[i] DO FOR j := 1 TO N DO WITH cj = C[j] DO VAR sum: REAL := 0.0; BEGIN FOR k := 1 TO N DO sum := sum + bi[k] * cj[k] END; ai[j] := sum END END END END END But I would probably write PROCEDURE Dot(VAR x, y: ARRAY OF REAL): REAL = VAR sum: REAL := 0.0; BEGIN FOR k := FIRST(x) TO LAST(x) DO sum := sum + x[k] * y[k] END; RETURN sum END Dot; FOR i := 1 TO N DO FOR j := 1 TO N DO A[i,j] := Dot(B[i], C[j]) END END; I suppose these bits of code will not convince you to give up fortran, but hopefully they will reassure you that we "CS types" are not entirely out of our minds (yet). Jorge Stolfi Modula-3 User DEC SRC ======================================================================== 54 === Date: 14 Mar 92 01:07:16 GMT From: mbk@lyapunov.ucsd.edu (Matt Kennel) Subject: Modula-3, Fortran, Numbers & Aliens So here's the problem: Write a program to do... : > for i,j: C(i,j) = sum k : A(i,k) * B(j,k) : >Which says C = A * Transpose(B) in a straightforward way, of course, assumin g : >it can figure out the array bounds for i,j,k, which is often not much : >a problem. (And the "sum" is an expression, not part of a statement). David's Modula-3 solution(?)... chased@rbbb.Eng.Sun.COM (David Chase) writes: : GENERIC INTERFACE G(Result); : PROCEDURE Sum(from,to,by:INTEGER; : PROCEDURE Plus(x,y:Result.T):Result.T; : PROCEDURE Element(i:INTEGER):Result.T) : Result.T; : : END G. : : GENERIC MODULE G(Result); : PROCEDURE Sum(from,to,by:INTEGER; : PROCEDURE Plus(x,y:Result.T):Result.T; : PROCEDURE Element(i:INTEGER):Result.T) : Result.T = : : VAR i:INTEGER; : VAR accumulator:Result.T := Result.Zero. : BEGIN : FOR i := from TO to BY by DO : accumulator := Plus(accumulator,Element(i)); : END; : RETURN accumulator; : END Sum; : END G. : : INTERFACE Float; : TYPE T = FLOAT; : CONST Zero : FLOAT = 0.0; : PROCEDURE Plus(x,y:T):T; : END Float; : : INTERFACE Floatsum = G(Float) END Floatsum. : MODULE Floatsum = G(Float) END Floatsum. : : So, in my code I might say: : : VAR a : REF ARRAY OF ARRAY OF FLOAT; : VAR j:INTEGER; : PROCEDURE Bogus(INTEGER i) : FLOAT = BEGIN RETURN a[i,j]; END; : ... : x := Floatsum.Sum(1,n,1,Float.Plus,Bogus); : : Of course, if we had lambda expressions (I'll use constructor syntax : with a procedure type): : : VAR a : REF ARRAY OF FLOAT; : VAR j:INTEGER; : ... : x := Floatsum.Sum(1,n,1,Float.Plus,PROCEDURE(i:INTEGER):FLOAT{a[i,j]}); : : Now, if we had automatic coercion of expressions into functions, we : might try writing: : : VAR a : REF ARRAY OF FLOAT; : VAR j:INTEGER; : ... : x := Floatsum.Sum(1,n,1,Float.Plus,a[i,j]); : : This works, just this once, because we can see that we have an : expression with one unbound integer (i) that could yield a float, in a : context where a procedure from an integer to a float is called for. : Thus, there is exactly one way to "Do What I Mean". Suppose I had : instead written: : : VAR a : REF ARRAY OF FLOAT; : VAR i,j:INTEGER; (* <----- Note the declaration of i *) : ... : x := Floatsum.Sum(1,n,1,Float.Plus,a[i,j]); ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Sorry, but "I've Got That Gagging Feeling...." : : Now there's no unbound integer -- what do I mean in this case? : : So, the situation is not perfect, but it isn't as horrible as you : might have thought. Presumably (if you think this is important) you : could look into defining a standard library of these combining : functions. They could be inlined, of course. uhh, I wanted A = B * C^Transpose...... where did that go? And for the compiler to figure out loop bounds when it was obvious. Any anyway, why bother complicating up something that's really simple and then try to make a really fancy optimizer to undo the damage? Also your solution still is based on the model of a serial computer, with the explicit sum and iteration. : Well, I'm all tuckered out now, and I didn't even get to the : elementwise array assignment. And in the other corner....(better no doubt, but still....) : In J, you'd write one of: : a =. +/ V*W NB: sum (+/) of product of two arrays. :or : a =. V +/ ..* W NB: Inner product works fine on vectors. Well the same to you, you !@#a /2+a XV ..*&! :-) :-) :-) Survey says...... BZZZZZZZZZZZZZZZZZZZZTTTT! Sheesh. I think i'll stick with DO I=1,N DO J=1,N SUM = 0.0 DO K=1,N SUM = SUM + B(I,K) * C(J,K) ENDDO A(I,J) = AUM ENDDO ENDDO (I wrote a macro for GNU CC that lets me write SUM(i,1,N, expression), so I can do for(i=1;i<=N;i++) for(j=1;j<=N;j++) A[i][j] = SUM(k,1,B[i][k] * C[j][k]); No insult intended to you CS folks out there, but it's like talking to aliens. In other words, Yes I Want A Special Case Syntax I Don't Care If It's Possible To Do In Some Other Way That's Turing Equivalent Because My Brain Hurts No I Haven't Taken Graduate CS Courses Sorry I Want To Have A Life. :-) :-) :-) Maybe this will convince you... I want a syntax where the parellelism is obvious, natural, and semantically close to the way that humans think of things. Humans first, computers second. Humans sometimes have special cases too. Why is it fine in every language to write a = 3*X + sin(4.5), but not the obvious extension to arrays? cheers, Matt mbk@inls1.ucsd.edu who was it who said something like, "Mathemeticians are like Frenchmen. Anything you explain to them they will translate into their own language whence it becomes totally incomprehensible even to you." : David Chase : Sun ======================================================================== 55 === Date: 14 Mar 92 02:48:45 GMT From: chased@rbbb.Eng.Sun.COM (David Chase) Subject: Re: Modula-3, Fortran, Numbers & Aliens In article mbk@lyapunov.ucsd.edu (Matt Kennel) writes: >No insult intended to you CS folks out there, but it's like talking to aliens. >In other words, Yes I Want A Special Case Syntax I Don't Care If It's >Possible To Do In Some Other Way That's Turing Equivalent Because My Brain >Hurts No I Haven't Taken Graduate CS Courses Sorry I Want To Have A Life. Actually, I have a pretty nice life. Don't knock computer science till you've tried it. In general, the bulk of the world is completely unable to agree on a special case syntax -- at a minimum, you have to be able to write down a specification of what the syntax is and what it means. It doesn't matter if I "know what it means", because we haven't yet figured out how to transfer the contents of my brain into a compiler -- lacking that, we've got to have a specification. ( This by the way, is part of the reason why it is interesting to look for within-language solutions -- we can at least agree on what it means, and then consider shorthand from there. The use of a generic was intended to suggest that (perhaps) one might implement it differently -- for expository purposes, I used a simple loop. Obviously, threads are an option, as are weird compiler pragmas to enable (in a generic sense) additional parallelizing transformations. ) Anyhow, given that the world does not present a unified request, what goes in or out of the language is pretty much up to the definers. In this case, they relied heavily on precedent. Modula-2 has been moderately successful, and its relatives (Cedar Mesa and Modula-2+) had good and bad features well-known to the people defining Modula-3. This strategy has a better chance of yielding progress, because much time is spent correcting old mistakes instead of generating new mistakes. ( I've been programming in C++ for about 18 months now, and I think it is fair to say that I have some experience with "new mistakes". The new Cobol standard was so wonderful that I believe an insurance company sued (or threatened) the standards committee, Fortran 90 is Really Really Big, and Common Lisp -- well, I'll bet Common Lisp has got what you want, if only you can find it. On a much smaller scale, I once spent a summer tinkering with FP84, and *it* had some very interesting "new mistakes". Language design is hard. ) In the case of Modula-3, the aim (my aim, specifically) was to make it *possible* to do mathematical programming. You are correct that complex should have been added -- it is a small thing (much smaller than multi-dimensional open arrays, which were added for math. prog.), and it is very useful. Standard mathematical functions can be provided after the fact. The syntax is, well, Modula. It says it in the name. >Maybe this will convince you... I want a syntax where the parallelism is >obvious, natural, and semantically close to the way that humans think of >things. Humans first, computers second. I suppose putting "parallel" in all the procedure names is not what you had in mind ? (:-) Seriously, you think maybe there's a reason this problem hasn't been solved? I've been plenty convinced for years, but I don't like pounding my head on an insoluble problem when there's interesting hard problems that I can solve. I've turned down jobs to do what you want done because I didn't think I'd be able to solve the problem (and in fact, the problem remains unsolved, and I haven't heard much from that company lately). Good syntax for parallel semantics appears to be hard. David Chase Sun ======================================================================== 56 === Date: 14 Mar 92 10:07:33 GMT From: qs101@cl.cam.ac.uk (Quentin Stafford-Fraser) Subject: Re: Modula-3 on HP300 vs HP700 I've been having another goat building 2.03 on my HP9000 300 under HPUX 7. I did lots of hacks, the main ones being: 1. to use gnumake, 2. -lBSD added in driver/src/m3makefile and compiler/src/m3makefile 3. INCL changed to INCLDIR after -z4 in driver/src/m3makefile (is this right?) I also changed the sv_mask from sigset_t to int as mentioned elsewhere. This got me much further than before, but when I do >m3make build_libm3 install_libm3 it hangs while compiling LongRealTime.i3. (just seems to loop) Can anyone help? I'm a bit of a novice at this sort of thing! ----------------------------------- Quentin Stafford-Fraser Cambridge University Computer Lab qs101@cl.cam.ac.uk Tel +44 223 334645 ----------------------------------- ======================================================================== 57 === Date: Sat, 14 Mar 92 17:05:53 -0500 From: Norman Ramsey Subject: Re: Modula-3 For scientific/mathematical programming ? > A few people have been asking for a language that understands essentially > summation conventions and general index notation, as used in undergraduate > math. > > So, in some sort of vague psuedocode: > > for i,j: C(i,j) = sum k : A(i,k) * B(j,k) > > Which says C = A * Transpose(B) in a straightforward way, of course, assuming > it can figure out the array bounds for i,j,k, which is often not much > a problem. (And the "sum" is an expression, not part of a statement). > > And/or how about a new integer type INDEX, which makes the sums and foralls > implicit for all repeated indices? Long ago in a previous life with a startup company, I implemented implicit summation over repeated indices as part of the ``MATHGRAF expression language'' that was to be part of some ``lab assistant'' software to run on PC's. The startup ran out of money long before MATHGRAF ever got out the door, but I still remember that notation fondly. It's concise and elegant, which is probably why physicists use it in the first place. It wouldn't surprise me if Macsyma or Mathematica or one of their ilk provided such a notation. At any rate, it's not hard to implement. Norman Ramsey nr@princeton.edu ======================================================================== 58 === Date: 14 Mar 92 20:43:38 GMT From: harbison@bert.pinecreek.com (Sam Harbison) Subject: Modula-3 book call for errata Prentice Hall informs me that my book "Modula-3" will soon go into its second printing. Some people have sent me notes about typos and errors they've found. If you have found any, this would be a good time to e-mail them to me. I will also publish an errata list. 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. ======================================================================== 59 === Date: 14 Mar 1992 21:22:43 GMT From: mbk@lyapunov.ucsd.edu (Matt Kennel) Subject: Re: Modula-3, Fortran, Numbers & Aliens chased@rbbb.Eng.Sun.COM (David Chase) writes: : In article mbk@lyapunov.ucsd.edu (Matt Kennel ) writes: : : >No insult intended to you CS folks out there, but it's like talking to alien s. : : >In other words, Yes I Want A Special Case Syntax I Don't Care If It's : >Possible To Do In Some Other Way That's Turing Equivalent Because My Brain : >Hurts No I Haven't Taken Graduate CS Courses Sorry I Want To Have A Life. : : Actually, I have a pretty nice life. Don't knock computer science : till you've tried it. No I have no problem with CS, it's just that I personally don't have time to learn serious CS in addition to my present degree... : In general, the bulk of the world is completely unable to agree on a : special case syntax -- at a minimum, you have to be able to write down : a specification of what the syntax is and what it means. It doesn't : matter if I "know what it means", because we haven't yet figured out : how to transfer the contents of my brain into a compiler -- lacking : that, we've got to have a specification. : : ( This by the way, is part of the reason why it is interesting to look : for within-language solutions -- we can at least agree on what it : means, and then consider shorthand from there. The use of : a generic was intended to suggest that (perhaps) one might implement : it differently -- for expository purposes, I used a simple loop. : Obviously, threads are an option, as are weird compiler pragmas to : enable (in a generic sense) additional parallelizing transformations. ) : : Anyhow, given that the world does not present a unified request, what : goes in or out of the language is pretty much up to the definers. In : this case, they relied heavily on precedent. Modula-2 has been : moderately successful, and its relatives (Cedar Mesa and Modula-2+) : had good and bad features well-known to the people defining Modula-3. : This strategy has a better chance of yielding progress, because much : time is spent correcting old mistakes instead of generating new : mistakes. Ok, I can agree with this, but..... The concepts of tensor index notation and complex variables have been around a long long time and are certainly NOT mistakes. It's only a question of how to make index notation usable on a computer. There's all sorts of research on creating languages to implement new concepts that are only relevant with a computer-- so why not those other small easy things that are well established outside computer science? : : ( I've been programming in C++ for about 18 months now, and I think it : is fair to say that I have some experience with "new mistakes". : The new Cobol standard was so wonderful that I believe an insurance : company sued (or threatened) the standards committee, Fortran 90 : is Really Really Big, and Common Lisp -- well, I'll bet Common Lisp : has got what you want, if only you can find it. Again, tensor notation would make Fortran 90 smaller, or more likely another langauge as useful as Fortran90 for arrays, but significantly cleaner and more elegant. Oh and someone complained about my example: for i,j: A(i,j) = sum k: B(i,k) * C(k,j) because the sum and whatever isn't easily delimited... I have no particular attachment to the nitty gritty of the syntax---that's what CS professionals are useful for. I don't see anything wrong with for i,j : A(i,j) = (sum k B(i,k)*C(k,j)) or whatever.... : In the case of Modula-3, the aim (my aim, specifically) was to make it : *possible* to do mathematical programming. You are correct that : complex should have been added -- it is a small thing (much smaller : than multi-dimensional open arrays, which were added for math. prog.), : and it is very useful. Standard mathematical functions can be : provided after the fact. The syntax is, well, Modula. It says it in : the name. Well to be a little unfair, that's like saying C makes it "possible" to do object oriented programming if you roll your own everything with pointers, or (stretching things) Fortran can let you write dynamic memory allocators if you're clever enough with EQUIVALENCE and COMMON blocks. : >Maybe this will convince you... I want a syntax where the parallelism is : >obvious, natural, and semantically close to the way that humans think of : >things. Humans first, computers second. : I suppose putting "parallel" in all the procedure names is not what : you had in mind ? (:-) Seriously, you think maybe there's a reason : this problem hasn't been solved? Oh I agree with you that the general problem is very hard. But can be made alot easier for some of more common special cases (if numerical mathematics is just a "special case"). Special Case Customers also spend alot of $$ on computers, and they generally know standard "science math" but not always computer science. The "Grand Challenge" type problems that will require Big Parallel Uranium (heavier than big iron, ya know) are frequently numerical. Even in the worst possible world, Microsoft Windows NT-XZ 5.1 shouldn't require more than a few dozens of processors... Making parallelization explicit is only a side-benefit for tensor notation. I was simply thinking of having a language closer to the way users normally think and write, that can still be precise enough for a computer. : I've been plenty convinced for : years, but I don't like pounding my head on an insoluble problem when : there's interesting hard problems that I can solve. I think my particular special case is an interesting easy problem that a CS grad student or two could solve. But if you come back and tell me no, it's actually very difficult to do, and solving would require P=NP, and the resolution of the Riemann Conjecture, etc. etc. I'd take your word for it, though I'd still think it was weird. : David Chase : Sun cheers, Matt Kennel mbk@inls1.ucsd.edu ======================================================================== 60 === Date: 15 Mar 92 04:57:50 GMT From: rockwell@socrates.umd.edu (Raul Deluth Miller-Rockwell) Subject: Re: Modula-3, Fortran, Numbers & Aliens Matt Kennel: Humans sometimes have special cases too. Why is it fine in every language to write a = 3*X + sin(4.5), but not the obvious extension to arrays? Huh? But in j that expression works fine [tests if a is equal to the expression on the right hand side of the '='] even if X is an array of arbitrary rank. ;-) The problem, as I see it, is not so much getting a language to recognize your syntax. It's not even getting a language which will recognize your semantics. The problem is convincing people that a language which has the limitations you envision is worth implementing. For example, I am now used to treating array indexing as a _function_. This is significant, because I can use meta-functions and the like to derive new functions based on array indexing. You can live with treating array indexing as an operation with anomalous syntax, but why should I have to? [And remember, if you can come up with a useful enough of a reason, you might even convince me to switch to your style of thinking...] -- Raul Deluth Miller-Rockwell ======================================================================== 61 === Date: 15 Mar 92 22:09:33 GMT From: lindsay+@cs.cmu.edu (Donald Lindsay) Subject: Re: Modula-3, Fortran, Numbers & Aliens In article <9203140501.AA01871@jumbo.pa.dec.com> stolfi (Jorge Stolfi) writes: > > for i,j: C(i,j) = sum k : A(i,k) * B(j,k) >But I would probably write > > PROCEDURE Dot(VAR x, y: ARRAY OF REAL): REAL = ... > FOR i := 1 TO N DO > FOR j := 1 TO N DO > A[i,j] := Dot(B[i], C[j]) > END > END; This treatment seems to have lost the transposition of C. -- Don D.C.Lindsay Carnegie Mellon Computer Science ======================================================================== 62 === Date: Mon, 16 Mar 92 10:25:18 EST From: Mr Richard Thomas Subject: Re: Modula-3 for scientific/mathematic programming > : The disadvantages are much like C, Pascal, etc: (1) no built-in complex > : type, (2) no built-in exponential function > > These are big omissions, though. May I ask the math people why these are big omissions? You can easily build your own Complex object (that's why objects were invented, to let you add features to your environment.) And you can make a generic exponential function. Most math people that I have had discussions with just answer this with, but I want it built-in. Which is more of "I don't want to learn something new." Now, if you want to say that if these aren't built-in, then we can't optimize them enough to make code useable, now I'll agree. (Which is why I didn't argue too much against the addition of a built-in COMPLEX type in ISO Modula-2 (yes it is there now!)) > : (4) there > : isn't a standard required math library for transcendentals > > A Big deal. :-( Now I agree this is a Big Mistake. IMHO I thought this was the biggest problem with Modula-2, no standard libraries (and we are not just talking about math). And yet everyone who has gone on to extend Modula-2 has fallen into the same error. This lack of standard libraries not only scares off the math people, but also a fair chunk of the CS community as well. Au revoir, @~~Richard Thomas aka. The AppleByter -- The Misplaced Canadian~~~~@ { AARNet: richard@snow.fit.qut.edu.au InterNet: R.Thomas@qut.edu.au } { PSI: PSI%505272223015::R.Thomas } @~~School of Computing Science - Queensland University of Technology~~@ ======================================================================== 63 === Date: 16 Mar 92 05:16:10 GMT From: mbk@lyapunov.ucsd.edu (Matt Kennel) Subject: Re: Modula-3, Fortran, Numbers & Aliens rbe@yrloc.ipsa.reuter.COM (Robert Bernecky) writes: : In article mbk@lyapunov.ucsd.edu (Matt Kennel ) writes: : >Maybe this will convince you... I want a syntax where the parellelism is : >obvious, natural, and semantically close to the way that humans think of : >things. Humans first, computers second. Shoot--I screwed up. I wanted to add "syntactically similar to the way humans write things" as well. Sorry. : : OK. How do you tell a child to compute the mean of a set of numbers. : "Add the numbers, and divide by the number of numbers". (Note that : we don't have to tell the child how many numbers there are. It's : implicit in the data. Same in J and APL. : : We can do this several ways: : : (+/ N) % $ N NB: Add up N ( +/ N) and divide (%) by number of number s ($ n) : : >Humans sometimes have special cases too. Why is it fine in : >every language to write a = 3*X + sin(4.5), but not the obvious extension : >to arrays? : : Umm, perhaps you are out of date on things. APL has worked this way since : the late 1960's. Fortran 90 works this way since 1991 or maybe even earlier. I've *never* thought that no language has ever done this. My only complaint is that either the syntax is cumbersome and half kludgey (Fortran 77/90) or completely different from normal mathematical conventions, and otherwise very unconventional. (APL) I think there is a place for conventional array notation in conventional computer languages to be used by conventional scientists. That's all. There's nothing wrong with APL, but it's just not the right thing "for the rest of us". Is it easy to write code to create & search conventional heirarchical trees in APL? (I have no idea...) cheers, Matt mbk@inls1.ucsd.edu : Bob : Robert Bernecky rbe@yrloc.ipsa.reuter.com bernecky@itrchq.itrc.on.ca : Snake Island Research Inc (416) 368-6944 FAX: (416) 360-4694 : 18 Fifth Street, Ward's Island : Toronto, Ontario M5J 2B9 : Canada ======================================================================== 64 === Date: Mon, 16 Mar 1992 05:52:59 GMT From: rockwell@socrates.umd.edu (Raul Deluth Miller-Rockwell) Subject: Re: Modula-3, Fortran, Numbers & Aliens Matt Kennel: Is it easy to write code to create & search conventional heirarchical trees in APL? (I have no idea...) It is easy with J [which provides boxed arrays, and conditional execution forms]. It becomes moderately difficult if you are working with a version of APL which forces you to do some of the storage management explicitly. In my opinion, the easiest search algorithm to implement is "breadth first". Finally, note that it's possible [even, dare I say it, ...easy] to traverse a directed graph with cycles in a purely functional manner (side effect free), with guaranteed termination. -- Raul Deluth Miller-Rockwell ======================================================================== 65 === Date: 16 Mar 92 04:51:08 GMT From: T.Moore@massey.ac.nz (T. Moore) Subject: Re: Modula-3 for scientific/mathematic programming >> : The disadvantages are much like C, Pascal, etc: (1) no built-in complex >> : type, (2) no built-in exponential function >> >> These are big omissions, though. > >May I ask the math people why these are big omissions? You can easily >build your own Complex object (that's why objects were invented, to let >you add features to your environment.) And you can make a generic >exponential function. Most math people that I have had discussions with >just answer this with, but I want it built-in. Which is more of "I don't Unless you are going to put operators in the language (like in Algol 68) You have to write Multiply(z1, z2); or Power(x, n); I would agree with not having these things built in if operators are provided. Even so, it is a nuisance having to write code for things which are so frequently used. The addition of operators, though would allow standard libraries to take care of the extras. -- Terry Moore Department of Mathematics and Statisics, Massey University, Palmerston North, New Zealand Kronecker: "God made the natural numbers, the rest is the work of man." Zermelo: "But I can construct the natural from the empty set alone." Bystander: "Who said 'You can't get something for nothing.'?" ======================================================================== 66 === Date: Sun, 15 Mar 92 22:16:28 GMT From: rbe@yrloc.ipsa.reuter.COM (Robert Bernecky) Subject: Re: Modula-3, Fortran, Numbers & Aliens In article mbk@lyapunov.ucsd.edu (Matt Kennel) writes: > > >Maybe this will convince you... I want a syntax where the parellelism is >obvious, natural, and semantically close to the way that humans think of >things. Humans first, computers second. OK. How do you tell a child to compute the mean of a set of numbers. "Add the numbers, and divide by the number of numbers". (Note that we don't have to tell the child how many numbers there are. It's implicit in the data. Same in J and APL. We can do this several ways: (+/ N) % $ N NB: Add up N ( +/ N) and divide (%) by number of numbers ($ n) or, ( +/ % $ ) N NB: Use of tacit definition. or, if you like names: sum =. +/ dividedby =. % sizeof =. $ (sum N) dividedby sizeof N > >Humans sometimes have special cases too. Why is it fine in >every language to write a = 3*X + sin(4.5), but not the obvious extension >to arrays? Umm, perhaps you are out of date on things. APL has worked this way since the late 1960's. Fortran 90 works this way since 1991 or maybe even earlier. Bob Robert Bernecky rbe@yrloc.ipsa.reuter.com bernecky@itrchq.itrc.on.ca Snake Island Research Inc (416) 368-6944 FAX: (416) 360-4694 18 Fifth Street, Ward's Island Toronto, Ontario M5J 2B9 Canada ======================================================================== 67 === Date: 16 Mar 92 06:19:19 GMT From: gl8f@fermi.clas.Virginia.EDU (Greg Lindahl) Subject: Re: Modula-3, Fortran, Numbers & Aliens In article rockwell@socrates.umd.edu (Raul Deluth Miller-Rockwell) writes: >Matt Kennel: > Is it easy to write code to create & search conventional > heirarchical trees in APL? (I have no idea...) > >It is easy with J [which provides boxed arrays, and conditional >execution forms]. That's nice; but could you please stop cross-posting this discussion to the Modula-3 and Fortran groups if it has strayed into the depths of J, never to return? Edit your newsgroups lines, folks. ======================================================================== 68 === Date: 16 Mar 92 18:59:58 GMT From: eijkhout@cupid.cs.utk.edu (Victor Eijkhout) Subject: Re: Modula-3, Fortran, Numbers & Aliens In article , mbk@lyapunov.ucsd.edu (Matt Kennel) writes: |> for i,j: A(i,j) = sum k: B(i,k) * C(k,j) Nice to see how this discussions drifts away from all relevant issues. I guess Matt has a point of the mind-set of CS'ers. Parts of what you want already exist in such extensions as Alliant Fortran: most languages with vector notation (aiming at vector computers) allow you to write sum( B(i,:)*C(:,j) ) which generates a scalar (the inner product of a row of B and a column of C) and they also allow you to generate vectors: A(:,:) = B(:,:)*C(:,:) by componentwise multiplication, but I've never seen the combination you want. You could imagine a syntax A(:1,:2) = B(:1,:3) * C(:3,:2) where the compiler matches up :i indexes. Any index not in the left hand side has to be summed. Some of the proposed solutions to this problem in previous msgs are highly objectionable from the point of compiling for parallelism/ vectorization. The more you leave unspecified the better. If you would write for (i,j,k : a(i,j)=a(i,j)+b(i,k)*c(k,j)) and leave it to the compiler to figure out what loop should be outermost, it would be best by far. Compilers have a hell of a job figuring out what the user *meant* to say, so that they can rearrange it for vectorization/ cache reuse/ parallelism. |> Matt Kennel Victor. ======================================================================== 69 === Date: Mon, 16 Mar 92 13:22:04 PST From: Subject: Re: Modula-3, Fortran, Numbers & Aliens In article <9203140501.AA01871@jumbo.pa.dec.com> stolfi (Jorge Stolfi) writ es: > > for i,j: C(i,j) = sum k : A(i,k) * B(j,k) > But I would probably write > > PROCEDURE Dot(VAR x, y: ARRAY OF REAL): REAL = > ... > FOR i := 1 TO N DO > FOR j := 1 TO N DO > A[i,j] := Dot(B[i], C[j]) > END > END; This treatment seems to have lost the transposition of C. Perhaps I am being dense, but I think that what I wrote is indeed is A := B*TRANSPOSE(C). Note that C[j] means *row* j of C, not *column* j. Jorge Stolfi Modula-3 User DEC SRC PS. Unfortunately I cannot code A := B*C in the same style, because M3 does not let me select a *column* of a matrix and treat it as as vector. But FORTRAN has a similar restriction, doesn't it? PPS. If I well remember, Algol 68 would let you take arbitrary slices of arrays. Not only that, but if X was an array of records, all of them with a field named "foo", you could write X.foo to get an array consisting of those fields only (as locations, not just values). These features are relatively trivial to implement: you only need to include one extra word in every array descriptor. As a bonus, you will get the ability to do general transposition, cropping, reversal, and subsampling of n-dimensional arrays. But the Holy Dogma of Simplicity (known to ecologists as "Breeders' Strategy") says that languages shall be designed for the benefit of implementors, not of users... ======================================================================== 70 === Date: 16 Mar 92 19:08:58 GMT From: jlg@cochiti.lanl.gov (Jim Giles) Subject: Re: Modula-3, Fortran, Numbers & Aliens In article <1992Mar15.221628.24491@yrloc.ipsa.reuter.COM>, rbe@yrloc.ipsa.reute r.COM (Robert Bernecky) writes: |> In article mbk@lyapunov.ucsd.edu (Matt Kenne l) writes: |> > |> > |> >Maybe this will convince you... I want a syntax where the parellelism is |> >obvious, natural, and semantically close to the way that humans think of |> >things. Humans first, computers second. |> |> OK. How do you tell a child to compute the mean of a set of numbers. |> "Add the numbers, and divide by the number of numbers". (Note that |> we don't have to tell the child how many numbers there are. It's |> implicit in the data. Same in J and APL. I don't understand how this argument is relevant to the discussion. The J notation you gave is nearly identical to the proposed Fortran syntax for which Matt Kennel has been arguing. Your statement supports rather than refutes him. His notation would give: Ave = (sum i: N(i))/size(N) Whereas yours gives: |> |> (+/ N) % $ N NB: Add up N ( +/ N) and divide (%) by number of numbe rs ($ n) Or worse. Frankly, I think the first would be easier to explain to a child (or anyone else). J. Giles ======================================================================== 71 === Date: Mon, 16 Mar 92 16:43:45 GMT From: adam@visix.com Subject: Re: Modula-3, Fortran, Numbers & Aliens Do I sense another Herman Rubin in the making :-) :-) :-) Yes, I know, computer scientists have a way of making things too complicated. But essentially you're saying, "all I want is a Do What I Mean instruction". Perhaps we don't understand your requirements. But perhaps you don't understand our constraints. Adam "If you want a job done right, you have to do it yourself." ======================================================================== 72 === Date: 16 Mar 92 16:44:55 GMT From: dagenais@vlsi.polymtl.ca (Michel Dagenais) Subject: Remote Method call (or OO RPC) Is anything getting done for Modula 3 in this area. I vaguely remember someone at Xerox Parc generating stubs for RPC. I would like to have persistent objects (Modula 3 objects pickled to disk for now) accessible from any number of viewers (or clients) through OO RPC. Some kind of daemon would locate a desired object for a client (directory service), start a process to serve it and offer various possible interfaces to access remotely this object (arrays of remote callable methods that depend on the access rights granted). Of course this is very similar to what the Object Management Group is doing, but not necessarily benefiting from the Modula 3 flavor (messages through pickles, structural type equivalence). That brings up an important question: in their current implementation, are Pickles machine independant to a certain point (byte order, member offset, word length)? -- --------------------------------------------------------------------- Prof. Michel Dagenais dagenais@vlsi.polymtl.ca Dept of Electrical and Computer Eng. Ecole Polytechnique de Montreal tel: (514) 340-4029 --------------------------------------------------------------------- ======================================================================== 73 === Date: Tue, 17 Mar 92 13:57:34 EST From: Mr Richard Thomas Subject: RE: Modula-3 for scientific/mathematic programming > Unless you are going to put operators in the language (like in Algol 68) > You have to write > Multiply(z1, z2); > or Power(x, n); > I would agree with not having these things built in if operators are > provided. Even so, it is a nuisance having to write code for things Good point. I had thought of this before, but forgot to mention it in my post. Who else out there wants to see operator overloading in Modula-3? Not only does it solve some of the problem with this example, but it provides a very flexible tool for library code. Au revoir, @~~Richard Thomas aka. The AppleByter -- The Misplaced Canadian~~~~@ { AARNet: richard@snow.fit.qut.edu.au InterNet: R.Thomas@qut.edu.au } { PSI: PSI%505272223015::R.Thomas } @~~School of Computing Science - Queensland University of Technology~~@ ======================================================================== 74 === Date: 16 Mar 92 15:09:55 GMT From: dagenais@vlsi.polymtl.ca (Michel Dagenais) Subject: PostScript out of Trestle Trestle comes with X11 support. An object receives paint commands from a VBT tree and translates them to X11 drawing operations. To get PostScript output i presume that a similar object would need to translate the paint commands into PostScript commands. Of course this assumes that similar fonts are available and so on... Does such a thing already exists? By the way, we are still in the process of trying Trestle on small toy applications but so far so good, we like it a lot! -- --------------------------------------------------------------------- Prof. Michel Dagenais dagenais@vlsi.polymtl.ca Dept of Electrical and Computer Eng. Ecole Polytechnique de Montreal tel: (514) 340-4029 --------------------------------------------------------------------- ======================================================================== 75 === Date: Mon, 16 Mar 92 19:35:37 GMT From: adam@visix.com Subject: Re: Modula-3, Fortran, Numbers & Aliens In article , mbk@lyapunov.ucsd.edu (Matt Kennel) writes: |> I have no particular attachment to the nitty gritty of the syntax---that's |> what CS professionals are useful for. You better SMILE when you say that, pardner ... Adam :-) ======================================================================== 76 === Date: 17 Mar 92 05:17:14 GMT From: n8243274@henson.cc.wwu.edu (steven l. odegard) Subject: Re: Modula-3 for scientific/mathematic programming richard@snow.fit.qut.edu.au (Mr Richard Thomas) writes: >Who else out there wants to see operator overloading in Modula-3? I feel that this overloading should be property of a combination of object-oriented interfaces and pre-processor that parses into Modula-3. Parse( Matrix, "M * A + M * B" ) would expand into Matrix.Add( Matrix.Mult( M, A ), Matrix.Mult( M, B ) ) ; or use temporarily-declared variables if the expanded expression would be too complicated for the compiler to parse. Such a project could also provide exponentiation. CONST E = ComplexLongreal.T{ Re := Math.exp( 1.0d0 ), Im := 0.0d0 }" ; VAR A, B := ComplexLongreal.T{ Re := 1.0d0, Im := 0.0d0 } ; X := Parse( ComplexLongreal, "A + B*E**T{1,1}" ) ; I would like to see a TYPE BCD in the SYSTEM interface, to add support for all of the processors that include BCD instructions [most of them]. Speaking of which, I envision Modula-3 as the best potential Business-oriented language. The pkl interface has potential for database applications. --SLO ======================================================================== 77 === Date: Tue, 17 Mar 92 12:20:24 -0500 From: Norman Ramsey Subject: Is Trestle Portable? Michel Dagenais asked about getting PostScript out of Trestle. I have a more general question: how portable is Trestle? If I want to make Trestle work on Irises, or a NeXT, using the vendor's graphics primitives, how much work am I letting myself in for? What parts of the Trestle implementation should I look at to learn the answers to these questions? Norman Ramsey nr@princeton.edu ======================================================================== 78 === Date: Tue, 17 Mar 92 06:56:10 PST From: msm@.dec.com (Mark S. Manasse) Subject: Re: PostScript out of Trestle No, we haven't done any implementations of screen types other than those for X and for a native Trestle server. Some interesting classes, besides PostScript, would be implementations for some version of Windows, for the Mac, and for 8 1/2. For PostScript, the main problem is that you would have to choose a convention for knowing where to insert "showpage"; you could add an extension command to the painting set to indicate it, or you could wait until the window deleted itself if you just want to capture a single page. One other difference is that while painting in response to user events occurs in sequence, asynchronous painting into different VBTs is unserialized, unless you explicitly serialize it by using VBT.Sync. So, if you have any asynchronous painting you would need to sync all of the VBTs that had asynchronously painted before declaring yourself done with the page. In order to implement a new class of display service, all you need to do is to implement something parallel to ui/src/xvbtm3, and import it in the implementation of Trestle (to force it to be linked in). Sadly, the interfaces involved aren't quite as well documented as the ones in the reference manual -- you'll probably want to use the X code as a template. Mark ======================================================================== 79 === Date: Tue, 17 Mar 92 16:55:22 GMT From: rbe@yrloc.ipsa.reuter.COM (Robert Bernecky) Subject: Re: Modula-3, Fortran, Numbers & Aliens In article mbk@lyapunov.ucsd.edu (Matt Kennel) writes: >scientists. That's all. There's nothing wrong with APL, but it's just >not the right thing "for the rest of us". The difference between APL and mathematical notation is that APL is well-define d and consistent. Math notation isn't. If it was, math books would be a lot shorter, because they wouldn't have to spent half their time saying: " I use the blech to denote the alternating logarithm of..." Math has sigma and PI notation for the insertion of an unspecified function (+ or *) between array items. This is inconsistent and limiting. APL allows you to specify the function explicitly, thereby offering more conceptual power (only 1 thing to learn instead of two in this case), AND being consistent (What you learned about + and * apply consistently to insert, whereas you have to be told that + and * are related to sigma and pi): sigma =. +/ pi =. */ altsum =. -/ parity =. =/ any =. +./ NB: +. is "or" all =. *./ NB: *. is "and" So, you DO have to learn something new, but it offers the benefits of being executable, which math is not. > >Is it easy to write code to create & search conventional heirarchical trees >in APL? (I have no idea...) APL offers several ways to do this. One way is to use recursive data structures. In J, you can create a tree with 3 leaves this way: t =. (2 3$ 8) ; 'hiya folks' ; + ` * This consists of: A table of two rows and 3 columns consisting of 8's. A character list: "hiya folks" A two-element "gerund" consisting of the functions + and *. Now, I can make another array from t, and thereby form arbitrarily nested objects of any form. Then you use the usual recursive techniques (or others, if you prefer) to traverse them. Bob Robert Bernecky rbe@yrloc.ipsa.reuter.com bernecky@itrchq.itrc.on.ca Snake Island Research Inc (416) 368-6944 FAX: (416) 360-4694 18 Fifth Street, Ward's Island Toronto, Ontario M5J 2B9 Canada ======================================================================== 80 === Date: 18 Mar 92 01:13:20 GMT From: chased@rbbb.Eng.Sun.COM (David Chase) Subject: Re: Modula-3, Fortran, Numbers & Aliens In article <9203162122.AA04024@jumbo.pa.dec.com> stolfi (Jorge Stolfi) writes: >PS. Unfortunately I cannot code A := B*C in the same style, because >M3 does not let me select a *column* of a matrix and treat it as as vector. >But FORTRAN has a similar restriction, doesn't it? > >PPS. If I well remember, Algol 68 would let you take arbitrary slices >of arrays. Not only that, but if X was an array of records, all of >them with a field named "foo", you could write X.foo to get an array >consisting of those fields only (as locations, not just values). > >These features are relatively trivial to implement: you only need to >include one extra word in every array descriptor. As a bonus, you >will get the ability to do general transposition, cropping, reversal, >and subsampling of n-dimensional arrays. But the Holy Dogma of >Simplicity (known to ecologists as "Breeders' Strategy") says that >languages shall be designed for the benefit of implementors, >not of users... Careful there -- at least one implementor was willing to sign on for somewhat more general arrays that we got. There's at least 3 different levels of support for arrays that (easily) be imagined: 1. (what we've got) top-level subarrays only -- no support for sectioning a matrix into pieces. This requires that a descriptor provide (at minimum) the address of the array and the size of each dimension. Two particular benefits are: a) don't need to invent new SUBARRAY syntax. b) indexing in the trailing dimension is guaranteed to be unit-stride. 2. (what I wish we had) generally N-dimensional SUBARAY. Given a [0..M, 0..N] matrix, I can partition it into whatever 2-dimensional index-contiguous pieces I choose. This requires that the descriptor also contain the row-to-row stride, as well as the length of a row. Two particular benefits are: a) Much easier to do interesting matrix manipulations in recursive programs, since subdivision is a cinch. b) indexing in the trailing dimension is guaranteed to be unit-stride. I would have been perfectly happy with additional parameters to SUBARRAY, along the lines of: WITH UL = SUBARRAY(A,0,M/2,0,N/2), UR = SUBARRAY(A,0,M/2,N/2+1,N), LL = SUBARRAY(A,M/2+1,M,0,N/2), LR = SUBARRAY(A,M/2+1,M,N/2+1,N) DO ... END 3. (what I contemplated) General index-to-index affine transformations. Given an array A with D dimensions, I can construct an alias A' with D' dimensions. This requires (in the descriptor) information about the element to element stride in the trailing dimension. A sick person might choose to overload this onto the WITH statement (strap on your barf bags, examples follow): WITH A[i,j] = B[j,i] DO ... END WITH ROWi[j] = B[i,j] DO ... END WITH COLj[i] = B[i,j] DO ... END WITH D[i] = B[i,i] DO ... END WITH UpperD[i] = B[i,i+1] DO ... END This has the disadvantage of not limiting the indices in any explicit way, but this is just an exercise. Also, this is a very general general case -- it could slow down some (naively compiled) code in the unextended language. At some time or another, something like this was contemplated for Fortran 90, but I don't know offhand if it made it in or not. Now, it turns out that what was implemented at Olivetti in fact could have supported option 2 above (for a while, rows of arrays were allocated in 2-byte boundaries. This was a Bad Idea). It certainly wasn't a killer in terms of implementation cost. If anyone cares, you'll notice that these are compatible extensions to Modula-3 -- supporting them does not change the meaning of any legal program. There's some question about efficiency problems for other programs if you support option 3 -- you'd like to at least have a "decent" compiler that would recognize that the element-to-element stride was loop invariant, and special cases in a lot of the library code to spot the unit stride case. David Chase Sun ======================================================================== 81 === Date: Wed, 18 Mar 92 14:49:49 CST From: sya@prism.keh.utulsa.edu (Syed Shibli) Please add me to your Modula-3 mailing list. sya@prism.keh.utulsa.edu Thanks, Syed ======================================================================== 82 === Date: Thu, 19 Mar 1992 15:57:44 GMT From: abbas@osf.org (Abbas Birjandi) Subject: Looking for material on threads Hi, I am looking for tutorials, public domain examples, etc for preparing a one day hands on course on threads. I would appreciate any pointers, hints to anything useful that I can use in preparing my lectures and examples. Thanks. Abbas PS:Please respond by mail to abbas@osf.org ======================================================================== 83 === Date: 20 Mar 92 02:32:58 GMT From: gajarsky@pilot.njin.net (Bob Gajarsky) Subject: SURVEY:Please read, for scholastic purposes. Please note this message is being crossposted to a large number of groups. I am sorry for any inconvenience, but there are members of many newsgroups that I wish to reach , and this is the only way that I can accomplish this. Thank you for your understanding. ========================================================================= My name is Bob Gajarsky. I am a graduate level management student, and am conducting a survey for one of my classes. It would greatly help my studies if you could take a few minutes and complete the following survey. All results will be kept completely confidential, and your e-mail addresses will not be seen by anyone but me. Also, I am only looking for complete surveys from people who are actually out in the workplace as computer programmers, as opposed to those (like me) who are students. Additionally, I would request that only people who work in the United States reply to this. Thank you in advance for your responses. --------------------------- BEGINNING OF SURVEY ----------------------------- What city is your place of work? - (OPTIONAL) What company do you work at? - How many years of programming experience do you have? How many years of post-high school education have you had? How many computer languages do you know? If you program in any of the following languages, please check it: Ada APL Cobol C C++ Fortran Lisp Pascal How many software packages do you know how to use (ie. Lotus, MS-Works, etc.) 1-2 3-5 6-8 9-10 over 10 Do you know any databases? (Y/N) If so, which ones? On the average, how many hours does it take you to learn a application (ie. Word Processor, Graphics Package, etc.)? How do you prefer to learn new applications? More than one may be checked: Tutorials Videos Self-Instruction Other _________________________ Do you personally have a VCR? (Y/N) Does your workplace have a VCR? (Y/N) Have you ever used a video to learn an application before? (Y/N) If so, how would you rate it? (10 is an excellent experience, 1 is an awful experience) Based on your past experiences, would you be receptive to learning another application via video? (10 is very receptive; 1 is not receptive at all) If not, how receptive would you be to learning a application via video? (10 is very receptive; 1 is not receptive at all) How many hours of video would you be able to successfully watch for a specific application? How much would you or your company pay for the following: A) A 15 hour video that teaches how to generally work with databases, program in them, and utilize them. (Between 40$ and 150$) B) A 3 hour video that teaches a specific database, (Oracle, etc.) (Between 15$ and 75$). C) A packaged of both (A) and (B). (Between 50$ and 225$). Which systems do you have a familiarity with? VAX/VMS UNIX Macintosh IBM Compatible Other ------------------- END OF SURVEY --------------------------------- Thanks! - Bob Gajarsky ======================================================================== 84 === Date: Fri, 20 Mar 92 10:47:10 GMT From: diamond@jit345.bad.jit.dec.com (Norman Diamond) Subject: Re: Modula-3 For scientific/mathematical programming ? Having seen the article on this topic that was cross-posted in comp.lang.misc, I wish to correct some errors. In article mbk@lyapunov.ucsd.edu (Matt Kennel) writes: >goldberg@parc.xerox.com (David Goldberg) writes: >: The disadvantages are much like C, Pascal, etc: (1) no built-in complex >: type, (2) no built-in exponential function >: (3) arrays don't match >: FORTRAN (they are zero-based and stored by row, not column) >: (4) there >: isn't a standard required math library for transcendentals Pascal has not suffered the above disadvantages since 1989. It does seem, however, to suffer a shortage of implementations due to prejudice in the marketplace. >: (5) no simple >: way to specify floating-point constants exactly (i.e. in binary). Yes, Pascal still suffers that disadvantage. >A little deal. >: However, unlike C and Pascal, Modula-3 does handle functions that take >: arbitrary-length arrays as arguments: the size of an array argument can >: be instantiated at call-time. That is like Pascal, since 1989. >I have the feeling that computer scientists have an odd idea of what >is really important for scentific programming: according to their >language decisions(actions not words), it's critical to get floating >point interfaces for "machine epsilon", a standard way of getting >at those damn IEEE "rounding modes", and manipulate how to handle >"overflow", Most languages started without these features, but added them because of demand from numerical analysts. >and yet, no complex numbers, few standard mathematical functions, >no exponentiation, no *good* array support. Great on the details and >lousy on the big picture. Some languages have added these as well. Some added these at the same time when other languages were adding the more primitive set of features. -- Norman Diamond diamond@jit081.enet.dec.com If this were the company's opinion, I wouldn't be allowed to post it. "Yeah -- bad wiring. That was probably it. Very bad." ======================================================================== 85 === Date: Fri, 20 Mar 92 15:53:33 PST From: muller@src.dec.com (Eric Muller) Subject: SRC Modula-3 2.04 available from gatekeeper.dec.com in pub/DEC/Modula-3/release (note the change of location). Here are some of the user-visible changes: - M3makefile's that build libraries must name all of the libraries that they import. This way you'll always get consistent recompilation. - Warnings are generated for unused imports. - Runtime error messages include more information about the location of the error (e.g. file and line number or PC). - The runtime supports a simple overlay mechanism that allows us to build a "partial link" model of program development. See the m3 and m3make man pages. - Single stepping into a TRY statment with your debugger should now show the "TRY" lines instead of the "EXCEPT" and "FINALLY" lines. - The explicit checking for NIL Text.Ts was removed. If you pass NIL to one of the Text procedures, you'll get the standard "possible NIL dereference" crash. - RTArgs exports "argc" and "argv", the old values in M3toC are marked obsolete. There's a new interface Params that provides simple, safe access to the command line arguments without the overhead of ParseParams. - Wr.PutString takes a READONLY array of characters. The array used to be passed by value. - "FROM X IMPORT y" doesn't import the revelations from X. - showheap now runs in a different address space than the program under investigation (it is now similar to showthread). This means that there is nothing special to do when building a program to use showthread; just pass @M3showthread as an argument when running the program. - recordheap and replayheap to take a closer look at the heap activity. As before, the user interfaces are very poor; I am waiting for the availability of FormsVBT to redo them. Installation changes: - The default M3OPT to use in m3makefile is now part of the config rather than part of the toplevel template. There is also a BOOTOPT option in the config, passed to the C compiler when compiling the bootstrap C code for the compiler and the driver. - The m3make component works more like the other components: the derived files are created in a separate directory for each architecture. - INSTALL in the config is now a macro with arguments that expands to the full command to use for installing a file. Together with the previous change, this should allow to install files by creating links rather than copying the bits. Some news about the various ports: - The FloatMode interface has been implemented for SPARC and DS3100. The status is global (not yet per-thread). - There is a NEXT version for NeXT machine. This is only a test version. It incorporates changes to the U* interfaces for NeXT, as reported by Gary Frederick (thanks a lot). - All HP300 fixes reported by Piet van Oostrum have been incorporated. Internal changes and bug fixes: - Debugging symbols for Modula-3 types are generated on a per-library basis. - Thread stack overflows are detected with write protected "guard pages" rather than explicit checking on procedure entry. The result is less code and a more efficient procedure call. This is used for DS3100, VAX and SPARC only. For the other machines, we need to know if mmap() exists and how it works (arguments, returns values). - Better code is generated for exception handlers and return statements. - The compiler no longer uses "alloca". - Subtype tests are compiled in-line. - Taking the address (explicitly or when passing by VAR) of a VALUE REAL parameter works. - Raising an exception with a one-word argument doesn't require an allocation. - Generics with no parameters are allowed. - The builtin operations that take types as arguments correctly declare the type. (e.g. LOOPHOLE (a, UNTRACED REF INTEGER) will work even if this is the only reference to UNTRACED REF INTEGER.) - LOOPHOLE (x, ARRAY OF T) works. - Nested procedures within a module's main body get legal C names. - "NEW (T, f := P())" doesn't allocate two T's. - The <*OBSOLETE*> pragma works again. - RETURN from within a TRY-EXCEPT-ELSE doesn't clobber the pending return value. - Typecell pointers are allocated in each library so shared libraries will work on SunOS and OSF. We haven't yet modified the templates to build shared libraries. - Exceptions with arguments smaller than a word should work. This is only a problem on big-endian machines so I can't test my fix. - The PRAGMA pragma allows you to define pragmas that use Modula-3 reserved words. - The compiler recognizes some (intentionally) undocumented flags that disable runtime checks so we can do some performance measurements. - When a compilation fails, m3 exits with a non-zero status. - The bogus "unhandled exception" warnings are gone. - Library names can contain arbitrary characters. -- Eric. ======================================================================== 86 === Date: Fri, 20 Mar 92 15:30:26 PST From: muller@src.dec.com (Eric Muller) Subject: Modula-3 Frequently Asked Questions (FAQ) Archive-name: Modula-3-faq Last-modified: Mar 19 1992 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. Is Modula-3 a superset of Modula-2 ? No; valid Modula-2 programs are not valid Modula-3 programs. Where can I get a description 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 also known as SPwM3. Sam Harbison has written a book about Modula3: Modula-3 Samuel P. Harbison Prentice Hall, 1992 ISBN 0-13-596396-6 as well as an overview article, "Modula-3", in Byte, Vol. 15, Number 12, October 1990, p 385. 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. If you do not have access to Usenet, there is a relay 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/src-m3. The current version, 2.04, implements the language defined in SPwM3. There are versions for the following machines: AIX386 IBM PC running AIX/PS2, AP3000 Apollo DN4500 running Domain/OS ARM Acorn R260 running RISC iX 1.21 DS3100 DECstation 3100 and 5000 running Ultrix 4.0 and 4.2 HP300 HP 9000/300 running HP-UX 8.0 IBMR2 IBM R6000 running AIX 3.1, IBMRT IBM RT running IBM/4.3, NEXT NeXT running ? SPARC SPARCstation running SunOS 4.1.x SUN3 SUN3 running SunOS UMAX Encore Multimax running UMAX 4.3 (R4.1.1) VAX VAX running Ultrix 3.1 SRC Modula-3 includes a user manual, compiler, runtime library, some libraries and a few other goodies (see below). 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). Can I contribute Modula-3 software ? Certainly. Send us what you are willing to share, be it programs, libraries or other things. We'll put them in the distribution. -- Eric. ======================================================================== 87 === Date: Fri, 20 Mar 1992 22:05:51 GMT From: ja51359@uxa.cso.uiuc.edu (Jeff Axelrod ) Subject: program to replace keywords by uppercase? Hi. Has someone written a program to change all the keywords from lower to uppercase that they would be willing to mail me? This would be a great typing aid. Thanks in advance! ======================================================================== 88 === Date: Sat, 21 Mar 92 01:03:28 MST From: ggf@saifr00.cfsat.honeywell.com (Gary Frederick) Subject: Re: SRC Modula-3 2.04 available from gatekeeper.dec.com >There is a NEXT version for NeXT machine. That still has a few small problems (-: I hope to get it up in a few days. The build went well till it tried to link and did not find waitpid and mprotect. It also had a problem with linking __IS_CLOSURE that I do not know where it is coming from. But it looked VERY close. If you want to try to get it up, this is the version to build from. Thanks for the great work. Gary ggf@jsoft.com ======================================================================== 89 === Date: Fri, 20 Mar 92 17:23:23 PST From: mjordan@src.dec.com (Mick Jordan) Subject: Re: SRC Modula-3 2.04 available from gatekeeper.dec.com In article <1992Mar20.155333.21272@src.dec.com>, muller@src.dec.com (Eric Mulle r) writes: > in pub/DEC/Modula-3/release (note the change of location). > > > Here are some of the user-visible changes: > > - M3makefile's that build libraries must name all of the libraries that > they import. This way you'll always get consistent recompilation. > There is more to it than the above remark suggests and, since I was bitten by i t, I will pass on the warning. In addition the above, all procedures declared in interfaces in the library must be implemented by a module in the same library and all opaque types declared in interfaces in the library must be given concrete revelations by some interface or module in the same library. So, you cant structure your system with "abstractions" in one library and "implementations" in (one or more) other libraries. Mick Jordan ======================================================================== 90 === Date: Sat, 21 Mar 92 10:19:29 -0500 From: Norman Ramsey Subject: SRC M3 V2.04 Is version 2.04 considered a beta test version or a reliable version? Norman Ramsey nr@princeton.edu ======================================================================== 91 === Date: Sat, 21 Mar 92 14:58:58 PST From: gnelson@src.dec.com (Greg Nelson) Subject: Re: Remote Method call (or OO RPC) Michel Dagenais asks about the status of object-oriented RPC in Modula-3. There are several projects for doing RPC in Modula-3, all of which are using the network object approach, so that an RPC call is made by invoking the method of an object in another address space. David Nichols at Xerox PARC has built a stub compiler that takes SUN RPC interface descriptions and produces a Modula-3 object whose methods perform the Sun RPC calls. I understand that he will be releasing it for public use soon. David Evers at Cambridge University has done much the same thing for the ANSA interface description language, which is much used around Cambridge. At SRC there is a project underway to build a new RPC system for Modula-3 based on network objects. As part of this project, we will be reimplementing Pickles so that they are independent of byte order, floating-point format, etc. This is unfortunately not true of the current implementation. Greg Nelson ======================================================================== 92 === Date: Fri, 20 Mar 92 15:41:00 GMT From: adam@visix.com Subject: Re: Modula-3, Fortran, Numbers & Aliens Preclaimer: I'm feeling a bit peckish today, so I'm going to play devil's advocate ... In article <1992Mar17.165522.14818@yrloc.ipsa.reuter.COM>, rbe@yrloc.ipsa.reute r.COM (Robert Bernecky) writes: |> Math has sigma and PI notation for the insertion of an unspecified |> function (+ or *) between array items. This is inconsistent and limiting. |> APL allows you to specify the function explicitly, thereby offering |> more conceptual power (only 1 thing to learn instead of two in this case), |> AND being consistent (What you learned about + and * apply consistently to |> insert, whereas you have to be told that + and * are related to sigma and |> pi): The problem is that most people already know the two concepts of sigma and pi notation, so the argument "there are less things to learn" doesn't fly. It is perfectly valid for them to say, "I don't have to learn _anything_ to continue using the notation I have." To snatch an analogy out of thin air, you lose at Blackjack because when you bust and the dealer busts, you still pay. On second thought, forget the analogy. The point is, arguments of generality don't cut it with people who never have to deal with the extra cases. If all they do is limited to a particular domain, then all they want is a notation that fits that domain. Is that wrong? Adam ======================================================================== 93 === Date: 16 Mar 92 02:42:31 GMT From: abbasi@star.enet.dec.com (Nasser ABBASI) Subject: Re: Modula-3 For scientific/mathematical programming ? In article <9203142205.AA21344@cs.Princeton.EDU>, nr@Princeton.EDU (Norman Rams ey) writes... [..] >> So, in some sort of vague psuedocode: >> for i,j: C(i,j) = sum k : A(i,k) * B(j,k) >> Which says C = A * Transpose(B) in a straightforward way, of course, assumin g [..] >Mathematica or one of their ilk provided such a notation. At any >rate, it's not hard to implement. >Norman Ramsey >nr@princeton.edu in MATLAB you type C= A * B' and you'r done :-) /Nasser ======================================================================== 94 === Date: 23 Mar 92 14:37:41 GMT From: harbison@bert.pinecreek.com (Sam Harbison) Subject: SIGPLAN Modula-3 BOF I just looked at the advance program for SIGPLAN '92 in San Francisco, June 15-19. Many of the tutorial and symposium topics are relevant to Modula-3, and it appears that our friends from Princeton and U. Mass. will be giving papers on Modula-3-related topics. Looks like a good opportunity for a big Modula-3 get-together! Make your reservations early! 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. ======================================================================== 95 === Date: Mon, 23 Mar 92 13:04:18 PST From: muller@src.dec.com (Eric Muller) Subject: Re: SRC M3 V2.04 In article <9203211519.AA12563@cs.Princeton.EDU>, Norman Ramsey asks: > Is version 2.04 considered a beta test version or a reliable version? I guess this depends on the version. The DS3100 version is in daily use at SRC and should be reliable. The SPARC version is usually very close to the DS3100 version thanks to the work of PARC. The other versions seem to be less used, and suffer from bugs in make, cc, cpp. As far as we know, all the problems associated with the twelve changes to the language, or the changes to support "m3 -make"/version stamps are now solved. The architecture-independent part is certainly as reliable as in 1.6, has less bugs and is more efficient. -- Eric. ======================================================================== 96 === Date: Mon, 23 Mar 1992 22:28:08 GMT From: jlg@cochiti.lanl.gov (Jim Giles) Subject: Re: Modula-3, Fortran, Numbers & Aliens In article <1992Mar20.154100.1603@visix.com>, adam@visix.com writes: |> [...] |> The point is, arguments of generality don't cut it with people who |> never have to deal with the extra cases. If all they do is limited |> to a particular domain, then all they want is a notation that fits |> that domain. Very good! I couldn't have said it better myself (if I could, I would have by now). The fact is that most numerical/scientific programs don't contain many reductions other than summation - which they contain lots of. So, it makes some sense to provide summation in the form that's most convenient. Further, the other reductions that are used, are so rara (and often used in different contexts entirely), that some more explicit notation, distinct from summation, might be desireable just to emphasize the less usual operation. Note, the most common reductions other than sum in numerical/scientific programs are min and max - reductions which have entirely different semantics from sum and product - so they have to be done differently anyway. J. Giles ======================================================================== 97 === Date: Mon, 23 Mar 1992 17:18:07 GMT From: stenbror@gaya.nki.no ( Stenbro) Subject: EBNF or YACC Grammar for Modula-3 Hello Modula-3 freaks!!! I am currently starting a Oberon Compiler prosject for IBM-PC, and i also want to write a Modula-3 Compiler for OS/2. Can anybody mail me EBNF or YACC Grammar of Modula-3 ????? Thank You!!! ======================================================================== 98 === Date: 24 Mar 92 15:28:50 GMT From: mhcoffin@tolstoy.uwaterloo.ca (Michael Coffin) Subject: Re: Modula-3, Fortran, Numbers & Aliens In article <1992Mar23.222808.6567@newshost.lanl.gov> jlg@cochiti.lanl.gov (Jim Giles) writes: > The fact is that most numerical/scientific programs don't contain > many reductions other than summation - which they contain lots of. > So, it makes some sense to provide summation in the form that's > most convenient. Further, the other reductions that are used, are > so rara (and often used in different contexts entirely), that some > more explicit notation, distinct from summation, might be desireable > just to emphasize the less usual operation. Note, the most common > reductions other than sum in numerical/scientific programs are min and > max - reductions which have entirely different semantics from sum and > product - so they have to be done differently anyway. I think we ought to be a little careful of this argument. People tend to use what is available---what is in their standard vocabulary. In mathematics, sum and product have well-known symbols, so people use them. Other reductions don't, so people aren't in the habit of using them. Users of J have general reductions as part of their normal vocabulary, so uses for reductions of various kinds are seen everywhere. I once had a teacher that habitually expressed the size of a set as "the sum, over all elements of the domain, of the indicator function for the set". This instead of something simple---|Set|, for example. Why? Because he had indicator functions and summation anyway, and it never occured to him to generalize absolute value to sets. Another example: I once had a boss who's pet peeve was recursion. For him, the epitome of ivory-tower language design was recursion: it was simply an unnecessary frill; he had programmed in Fortran for years and had never needed recursion. Of course, his code was full of explicit stacks used to simulate recursion. This is really a special case of a more general phenomenon. People are very conservative. When they first approach computers, they automate what they have done by hand for years. They leave the process the same, but make it less tedious. Only much later do they realize that it is the process itself that needs changing, because the process was tailored to doing things by hand. Another example: at a mine I worked for long ago, the standard way to estimate the amount of ore available was to hand-construct a Vernoi diagram on a map of drill holes, use a mechanical planimeter to find the area of each polygon, estimate the amount of ore within each polygon, and finally add up the estimates to get the total. So, of course, the first thing they did when they bought a computer was to automate this process. Only several years later did they realize that simple interpolation between drill holes is a better ways to estimate the amount of ore; Vernoi diagrams had been used only because they were easier to do by hand. (And it turned out that the methods based on interpolation were *much* easier to program, and ran much faster, than constructing Vernoi diagrams on the computer.) So, I'm not saying we shouldn't listen to users. I'm just pointing out that users are conservative and often don't know what they need. Mostly, they will tell you how to make their job less tedious. They probably won't tell you that their entire job description ought to change. Part of our job is to figure out, from what users *say* they want, what they *really* need. -mike ======================================================================== 99 === Date: Tue, 24 Mar 92 06:19:19 GMT From: rbe@yrloc.ipsa.reuter.COM (Robert Bernecky) Subject: Re: Modula-3, Fortran, Numbers & Aliens In article <1992Mar20.154100.1603@visix.com> adam@visix.com writes: > >sigma and pi notation, so the argument "there are less things to learn" >doesn't fly. It is perfectly valid for them to say, "I don't have >to learn _anything_ to continue using the notation I have." > >The point is, arguments of generality don't cut it with people who >never have to deal with the extra cases. If all they do is limited >to a particular domain, then all they want is a notation that fits >that domain. > >Is that wrong? Well, no, it isn't wrong. BUT, it does mean that they don't tend to think about ideas like: minimum/maximum of an array; or/and reduce of an array; parity of an array; minus reduce of an array (done with negative one to the power of the (whew) induction variable of the sigma)... as ALL being minor variations on the SAME idea: "Stick the thing on the left of the slash between the subarrays of the right, and evaluate the resulting expression". So, +/ is sum; */ is product; -/ is negative reduce; or/ is or reduce, etc. I don't see how sigma and pi notation are easier, except for the braindead who are unable to learn anything new. The insert notation is easier to teach to children(not sure about grad students and doddering professors) and is consistent, as well as generalizing to ANY function. I have taught insert notation to children during a 7 minute boat ride, using nonexistent functions "foo/x". They don't know how to evaluate it, but they sure know how to convert the expression into one using only foo and elements of x. Mathematicians faced with non-obvious reductions tend to spend a chapter inventing Another_new_Symbol. Whoopy zing. Of course, it took a century or so to get mathematicians to get used to the idea of using a times sign for multiply, and they still only get it sometimes, so perhaps I'm being impatient.. Robert Bernecky rbe@yrloc.ipsa.reuter.com bernecky@itrchq.itrc.on.ca Snake Island Research Inc (416) 368-6944 FAX: (416) 360-4694 18 Fifth Street, Ward's Island Toronto, Ontario M5J 2B9 Canada ======================================================================= 100 === Date: 23 Mar 92 14:48:35 GMT From: harbison@bert.pinecreek.com (Sam Harbison) Subject: Modula-3 shirts I still have some Modula-3 T-shirts and sweatshirts available. I have sweatshirts in sizes L, XL, and XXL (three of each). I have t-shirts in sizes L, XL, and XXL (one of each). First come, first served. These collector's items are available at cost, plus shipping and handling: Modula-3 T-shirt, 100% cotton, ash (gray) with maroon Modula-3 logo size L or XL $6.00 XXL 7.00 Modula-3 Sweatshirt (heavy), ash (gray) with maroon Modula-3 logo size L or XL 18.00 XXL 21.00 Shipping & handling (per sweatshirt, or for up to 3 tees) US 4.00 (priority mail) Canada 5.00 Other 8.00 (surface) Send a check or money order (US funds, US bank) to: Pine Creek Software Suite 300 305 South Craig Street Pittsburgh, PA 15213-3706 USA ======================================================================= 101 === Date: 25 Mar 92 00:42:18 GMT From: jlg@cochiti.lanl.gov (Jim Giles) Subject: Re: Modula-3, Fortran, Numbers & Aliens In article , mhcoffin@tolstoy.uwat erloo.ca (Michael Coffin) writes: |> [...] |> I think we ought to be a little careful of this argument. People tend |> to use what is available---what is in their standard vocabulary. In |> mathematics, sum and product have well-known symbols, so people use |> them. Other reductions don't, so people aren't in the habit of using |> them. Users of J have general reductions as part of their normal |> vocabulary, so uses for reductions of various kinds are seen |> everywhere. Scientists and mathematicians have been doing their thing for generations. If there were other reductions widely useful in those fields, I suspect they'd have a standardized notation for them by now. Moreso because inventing a syntax to use in textbooks and scholarly papers doesn't require any CS type to implement it for you. And, in fact, new notations are invented by every other author in these fields - and the best of these notations survive. I haven't seen any stampeed toward additional reductions though. The fact is that CS types see all reductions as variations of the same thing because they aren't in a field in which any of them dominate over the others. The assumption that they are actually the same and should be supported with the same or similar syntax is not necessarily true in all application domains. And if it's not, using the `generalized' syntax may actually be harmful in some application domains. The later seems to be the case (and I started out supporting an orthogonal syntax like the CS types are pushing). |> [... examples of `conservatism' involving Vernoi diagrams and others ...] The example exhibits marvelously that it's important for programmers to be aware of a wide variety of algorithms and techniques. I don't see that it has much relevance to language design - except to be a warning not to accept conventional ideas at face value. That's why I study the application domain I'm targetting and the programmers that are involved there. The conventional idea about reduction, for example, is that it's notation should be orthogonal for all operators. I thought so too. I decided, after studying the issue, that the conventional wisdom was both right and wrong. Reduction should be done orthogonally for all operators in a functional syntax. In additon, summation and iteration should be done in a syntax that allows covarying indices in array expressions to be denoted more clearly and succinctly. J. Giles ======================================================================= 102 === Date: Wed, 25 Mar 1992 19:03:55 GMT From: carter@EuroPARC.Xerox.COM (Kathleen Carter) Subject: Image object types for Modula-3 I have started using Modula-3 and Trestle and I would like to manipulate and display raster images grabbed from a video frame grabber. Has anyone implemented anything that might be useful for reading raster files in some standard format and for displaying them in a Trestle VBT? Thanks. Kathy Carter ======================================================================= 103 === Date: 25 Mar 92 22:46:00 GMT From: slagle@lmsc.lockheed.com (Mark Slagle) Subject: Re: Modula-3, Fortran, Numbers & Aliens In article mhcoffin@tolstoy.uwate rloo.ca (Michael Coffin) writes: In article <1992Mar23.222808.6567@newshost.lanl.gov> jlg@cochiti.lanl.gov (J im Giles) writes: > The fact is that most numerical/scientific programs don't contain > many reductions other than summation - which they contain lots of. > So, it makes some sense to provide summation in the form that's > most convenient. Further, the other reductions that are used, are > so rara (and often used in different contexts entirely), that some > more explicit notation, distinct from summation, might be desireable > just to emphasize the less usual operation. Note, the most common > reductions other than sum in numerical/scientific programs are min and > max - reductions which have entirely different semantics from sum and > product - so they have to be done differently anyway. I think we ought to be a little careful of this argument. People tend to use what is available---what is in their standard vocabulary. In mathematics, sum and product have well-known symbols, so people use them. Other reductions don't, so people aren't in the habit of using them. Users of J have general reductions as part of their normal vocabulary, so uses for reductions of various kinds are seen everywhere. ---- Good points all. There is another reason for careful use of the argument. Programming practices will soon need to change radically to accommodate parallel computations. Various as yet unfamiliar reductions will likely become commonplace in the coming computing environment. A language designer needs to anticipate the trends as well as acknowledge the status quo to avoid frustrating the programmers who will become his customers. -- ---- Mark E. Slagle PO Box 61059 slagle@lmsc.lockheed.com Sunnyvale, CA 94088 408-756-0895 USA ======================================================================= 104 === Date: Thu, 26 Mar 92 02:47:31 PST From: msm@.dec.com (Mark S. Manasse) Subject: Re: Image object types for Modula-3 Here's what's currently available in bits and pieces of the Trestle distribution: VBT.i3 exports PaintScrnPixmap, which gives you a way to take a ScrnPixmap.T and image into a VBT. You create ScrnPixmap.T's through the ScrnPixmap.Oracle in your VBT's screentype. You have to take care to free such pixmaps when you're done with them: the storage in your address space goes away, but the pixmap that we allocate in the X server won't, since we don't have any kind of object cleanup yet. To build your ScrnPixmap.T, you need to start with a ScrnPixmap.Raw, which is just a bunch of bits, and some rules for figuring out which pixel is where. You can look in the source for PixmapFromXData.m3 to see how I build a ScrnPixmap.Raw from a pile of characters for in X format bitmap; it's in the library for the card images used in 'solitaire'. This will all work, but it will be pretty slow. At present, I don't know of existing code for converting other popular image formats (like XPM or GIF or ...) into ScrnPixmap's. In the next month or two, I'll be shipping a version of Trestle which exposes more of X to those clients that have special needs. In particular, if you can somehow get your hands on the data you want to display in an X image structure, we'll be providing a procedure that lets you paint that onto your display. If you set it up right, it will even use X's shared memory transport if available. This interface will NOT be safe, but it may be useful. You'll also be able to set things up so that you can take an X pixmap, and build a ScrnPixmap.T out of it. So if you have a way (using raw X, say) to get a bunch of stuff put into an X pixmap, you'll be able to display it. There'll be more stuff in that interface: ways to use the X server connection for a given Trestle.T; ways to extract the window id associated with a Trestle window, or the cursor id associated with a Trestle cursor, etc. It won't make it really easy to use baroque X features, but it should make it possible. Mark ======================================================================= 105 === Date: 26 Mar 92 09:56:21 GMT From: laverman@cs.rug.nl (Bert Laverman) Subject: REVEAL; what does it really do? I'm trying to understand the effects of the REVEAL clause. Suppose I have the following two interfaces: INTERFACE List_1; TYPE T <: ROOT; REVEAL T = BRANDED OBJECT next : T END; END List_1. INTERFACE List_2; TYPE T = BRANDED OBJECT next : T END; END List_2; What is the difference? Am I correct in my understanding that there is no difference between the information exported by List_1 and List_2? I suppose the real use pops up when I want to define a list type _without_ exporting the knowledge that there is a 'next' field, as in: INTERFACE List_3; TYPE T <: ROOT; END List_3. MODULE List_3; REVEAL T = BRANDED OBJECT next : T END; ... END List_3. Is this the reason for REVEAL? Greetings, Bert -- #include Bert Laverman, Dept. of Computing Science, Groningen University Friendly mail to: laverman@cs.rug.nl The rest to: /dev/null ======================================================================= 106 === Date: 26 Mar 92 11:33:08 GMT From: collberg@dna.lth.se (Christian S. Collberg) Subject: Checking Subtype relationships. Judging from the source of the SRC compiler (v1.6), ISTYPE and other subtype-checking functions use an O(1) algorithm. Has this been described in the literature, and if so where? If not, can someone give me a brief description? Thanks! -- Christian.Collberg@dna.lth.se Department of Computer Science, Lund University, BOX 118, S-221 00 LUND, Sweden ======================================================================= 107 === Date: 26 Mar 92 15:32:29 GMT From: moss@cs.umass.edu (Eliot Moss) Subject: Re: REVEAL; what does it really do? Laverman noted that doing T <: ROOT and having a complete revelation of T in the same scope does not really accomplish much. I think this is true. The point is to be able to say T <: ROOT (or <: some other type) in one place, but hide the details and reveal them only in certain other scopes -- the usual information hiding / encapsulation sort of features one wants for programming in the large. It so happens that in M3 these mechanisms have been decoupled from the modularization constructs, unlike many other languages. This flexibility is probably good, but (like any other feature) can be misused. It also is yet another example of the tension between separate compilation and information hiding on the one hand, and global optimization (which requires more and more complete information to do a good job) on the other. In this case, the problem is that in compiling a module we may know T <: ROOT, and have another type S defined in terms of T, and know everything about how S extends T, yet we still cannot determine offsets of fields of S without having the revelation for T. Thus, information can be hidden even from subtype implementors, again a good thing on balance, I believe, but a problem in trying to achieve the best performance, etc. -- 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 ======================================================================= 108 === Date: 26 Mar 92 14:54:12 GMT From: moss@cs.umass.edu (Eliot Moss) Subject: Re: Checking Subtype relationships. I know of two O(1) algorithms for checking subtype relationships. The one used in the SRC M3 system relies on the fact that the hierarchy is *static*. It works as follows. Arrange all the object types of the program into a tree, with ROOT as the root of the tree. Walk the tree and mark each node with its pre-order and post-order number (these are the same for leaves). Now note that S <: T iff pre(T) <= pre(S) <= post(T). The pre and post numbers can be stored and accessed in O(1) time, so the algorithm is O(1). Another algorithm I know of (I invented it myself, but am reasonably sure others have invented it independently) does not rely on having a static hierarchy. It works as follows. Associate with each type its level in the hierarchy, e.g., ROOT is at level 1, immediate subtypes of ROOT are at level 2, etc. With each type at level i, associate a vector of its supertypes (including itself, for simplicity). Now S <: T iff level(S) >= level(T) and supers(S)[level(T)] = T. This is also O(1) in time, but may be O(t^2) in space whereas the other algorithm is O(t) in space (t = number of types in the system). We will probably use the level algorithm in GNU M3 since we want to build Persistent M3, which at some point in the future will mean dynamic loading of types, implying a dynamically changing hierarchy. We might be able to adapt the numbering algorithm to dynamic situations, though .... Both algorithms fail if you introduce multiple inheritance. -- 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 ======================================================================= 109 === Date: 26 Mar 92 18:30:26 GMT From: chased@rbbb.Eng.Sun.COM (David Chase) Subject: Re: Checking Subtype relationships. In article moss@cs.umass.edu writes: >I know of two O(1) algorithms for checking subtype relationships. The one used >in the SRC M3 system relies on the fact that the hierarchy is *static*. It >works as follows. Arrange all the object types of the program into a tree, >with ROOT as the root of the tree. Walk the tree and mark each node with its >pre-order and post-order number (these are the same for leaves). Now note that >S <: T iff pre(T) <= pre(S) <= post(T). The pre and post numbers >can be stored and accessed in O(1) time, so the algorithm is O(1). Additional data structures can be built from this numbering allowing an O(log number of cases) typecase implementation. My first knowledge of this trick comes from a chapter in the not-yet-published Zadeck-Rosen-Allen compiler book; it almost certainly appeared before this, because Paul Dietz published an algorithm for doing the fast typecase (not under that name) in STOC '81 or '82. > [other algorithm deleted] ... We might be able >to adapt the numbering algorithm to dynamic situations, though .... Yes, this is possible, depending upon your multiprocessor consistency contraints. If you assume that writes are seen in the order that they are executed (or if they are seen in that order if the writes are separated by a barrier instruction) then one can sweep through the type tree in such a way that "failure" means either "real failure" or "lost a race". Since real failure is typically expensive, it is reasonable to iteratively follow parent pointers to double-check the failure. (I heard of this trick from Roger Hoover.) However, this doesn't seem to work for the typecase check. Some people (e.g., me) think about this from time to time, since these algorithms have other uses. There is a paper by Dietz and Sleator on maintaining order in a list (1987, some ACM conference, sorry for the faulty reference) that may help here, but we haven't pushed concurrency into it yet. >Both algorithms fail if you introduce multiple inheritance. I heard that there was some paper (in TOPLAS, I think, last year or two) on efficiently performing lattice operations that might be of some help here. That's all I know for now -- I have't had time to get to it. David Chase Sun ======================================================================= 110 === Date: 26 Mar 92 15:42:38 GMT From: dagenais@vlsi.polymtl.ca (Michel Dagenais) Subject: Re: SIGPLAN Modula-3 BOF > I just looked at the advance program for SIGPLAN '92 in San Francisco, > June 15-19. Many of the tutorial and symposium topics are relevant to > Modula-3, and it appears that our friends from Princeton and U. Mass. > will be giving papers on Modula-3-related topics. > > Looks like a good opportunity for a big Modula-3 get-together! Good idea, i feel a bit lonesome using M3 in Montreal, i will make the arrangements in the next few days. (Please Bring your M3 sweat-shirts). Presumably some people from DEC SRC will be there and a visit to the M3 national monument can be arranged. Let's get a Modula 3 BOF or even a 1/2 day informal workshop going! -- --------------------------------------------------------------------- Prof. Michel Dagenais dagenais@vlsi.polymtl.ca Dept of Electrical and Computer Eng. Ecole Polytechnique de Montreal tel: (514) 340-4029 --------------------------------------------------------------------- ======================================================================= 111 === Date: 26 Mar 92 21:22:56 GMT From: harbison@bert.pinecreek.com (Sam Harbison) Subject: Re: REVEAL; what does it really do? In article <9203261946.AA19511@toaster.SFSU.EDU> frode@toaster.SFSU.EDU (Frode Odegard) writes: >... >Can someone come up with an illustrative example of using multiple >levels of revelations in several interfaces ? >... Yes, it happens I'm writing a paper on (a generalization of) this topic. The basic idea: If you are going to use objects to provide an extensible abstraction, you will probably end up with three layers of revelations: a client interface, a "VAR interface" (from "value-added reseller") for programmers extending the abstraction, and an implementation module. In Modula-3, this maps naturally to three units: X.i3: INTERFACE X; TYPE T <: Public; Public = OBJECT (*...visible stuff for clients...*) END; ... END X; X_VAR.i3 INTERFACE X_VAR; IMPORT X; REVEAL T <: VAR; VAR = X.Public OBJECT (*...stuff for VARs...*) END; ... END X_VAR; X.m3 MODULE X EXPORTS X, X_VAR; REVEAL T = VAR BRANDED OBJECT (*...internal stuff...*) END; ... END X; The client interface provides the user-level methods, the VAR interface provides the additional hooks for people extending the class X.T, and the module provides the implementation details for the specific X.T class. Why the VAR interface? It is often not effective to extend a high-level class by directly overriding its "client" methods--these methods are usually at too high a level, e.g., "Deduct a recurring fee from a 401-K account." Overriding these methods would just force you to rewrite a lot of code you'd rather reuse. Instead, the original client methods are designed so that they call other "VAR" methods that do the interesting pieces of work and that can be overridden without having to reimplement the class' "infrastructure. A real-world example of this kind of architecture is the MacApp application framework for the Macintosh. Modula-3's opaque types provide an excellent mechanism for really hiding information in these interfaces. However, this kind of polymorphic OO architecture is inherently more complicated than pre-OO module-based software architectures, and should only be used when the kind of extensibility it provides is really necessary. Otherwise, IMHO, you should stick with the simpler non-OO interfaces and modules. In C++, classes provide the only clean mechanisms for encapsulation and information hiding, and so classes are used even to implement simple (non-extensible) software architectures. That's OK, but I think C++ programmers take the next step--into inheritance and polymorphism--much too quickly. A good, extensible class structure is much harder to design and use. If you don't need it, don't use it. BTW, the problems don't show up very much in the small examples of OOP we see in textbooks (including mine). I'm talking about Big Time, application-level classes here, not just circles and stacks. It's also the big classes where the advantages of code reuse are greater. 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. ======================================================================= 112 === Date: Thu, 26 Mar 92 15:26:35 PST From: muller@src.dec.com (Eric Muller) Subject: Re: Checking Subtype relationships. In article , moss@cs.umass.edu (Eliot Mos s) writes: > Both algorithms fail if you introduce multiple inheritance. The Life programming language has a fairly elaborate scheme to handle multiple inheritance while keeping the runtime test cheap. I don't know if it has been published, nor do I remember well enough how it works to describe it. --- Eric. ======================================================================= 113 === Date: Thu, 26 Mar 92 16:05:37 PST From: Subject: Re: REVEAL; what does it really do? Frode Odegard asks for an illustrative example of using multiple levels of revelations in several interfaces. There is an extended example in Chapter 6 of Systems Programming with Modula-3 (Prentice-Hall, edited by G. Nelson). ======================================================================= 114 === Date: Thu, 26 Mar 92 11:46:31 PST From: frode@toaster.SFSU.EDU (Frode Odegard) Subject: Re: REVEAL; what does it really do? > Suppose I have the following two interfaces: > > INTERFACE List_1; > TYPE T <: ROOT; > REVEAL T = BRANDED OBJECT next : T END; > END List_1. > > INTERFACE List_2; > TYPE T = BRANDED OBJECT next : T END; > END List_2; > > What is the difference? In the first interface, you first say that T is a subtype of ROOT. But then you give a complete revelation, showing that T is - concretely - BRANDED OBJECT next : T END. Since, T isn't revealed with an explicit supertype, ROOT becomes the supertype. List_2.T is fully declared, with ROOT as its implicit supertype, also. Thus List_1.T and List_2.T are structurally equivalent, meaning "the same" in the Modula-3 type system. > [..] I suppose the real use pops up when I want to define > a list type _without_ exporting the knowledge that there > is a 'next' field, as in: > > INTERFACE List_3; > TYPE T <: ROOT; > END List_3. > > MODULE List_3; > REVEAL T = BRANDED OBJECT next : T END; > > ... > END List_3. > > Is this the reason for REVEAL? REVEAL is used to reveal information about an opaque type. In Modula-2, an opaque type had to be elaborated by simply redeclaring it as a pointer type. In Modula-3, the keyword REVEAL is used instead of TYPE. In Modula-3, partial revelations about T may occur in several interfaces. This can be confusing to a Modula-2 programmer. However, there can only be one concrete type for T, meaning: only one full revelation. All other revelations must be partial. Multiple revelations can be useful when one wants to look upon a type from different perspectives. Can someone come up with an illustrative example of using multiple levels of revelations in several interfaces ? - Frode -------------------------------------------------------------------- Frode Odegard, Odegard Labs, 100 Bush Street, Suite 625, San Francisco, CA 94104, USA, +1-415-434-4242, +1-415-982-3167 (fax), +1-415-905-6201 (voice mail), frode@toaster.sfsu.edu (internet), frode (BIX)