Date: Fri, 3 Aug 90 15:44:31 WST From: tim@madvax.maths.uwa.oz.au (Tim Boykett) Subject: Undefined stuff I've just installed 1.5, quite hassle free, thank you to the arrangers of all this. But it isn't working. somehow there are no hersion stamps set up properly for Char, Boolean and Integer, and no init routines either. Why? What have I done wrong? What I get is blah blahblah m3 -o demo Undefined: _Integer__init _Char__init _VS_Char__NUL__ca9cblahblahblah _VS_Char__Asciis__cfblhblahblurg .... etc WHY ?!?!?!?!?!? Help! Tim. ------------------------------------------------------------------------------ Date: Fri, 3 Aug 90 14:15:00 EDT From: fkz@cs.brown.edu (Kenneth Zadeck) Subject: yet another grammar question should E6 { "+" | "-" } E7 really be E6 [ "+" | "-" ] E7 or what is the meaning of a := +++++-----++++6; kenny ------------------------------------------------------------------------------ Date: 3 Aug 1990 1142-PDT (Friday) From: Subject: Re: yet another grammar question It is correct as it stands: E6 = { "+" | "-" } E7 > or what is the meaning of > > a := +++++-----++++6; It means: a := +(+(+(+(+(-(-(-(-(-(+(+(+(+6))))))))))))); - Bill Kalsow ------------------------------------------------------------------------------ Date: Fri, 03 Aug 90 17:21:01 PDT From: Eric Muller Subject: July m3 mailing list archive available The mail archive for the messages sent to the m3 mailing list during the month of July is available via anonymous ftp from gatekeeper.dec.com, in pub/DEC/Modula-3/m3-mail.07-90.Z. Eric Muller. ------------------------------------------------------------------------------ Date: Sat, 4 Aug 90 22:09:03 PDT From: sun0!mri!woolsey (Jeff Woolsey) Subject: m3 1.5 install problems on SPARCstation I ran into a couple problems while trying to bring up release 1.5 on a SPARCstation 1+ running SunOS 4.0.3c. These problems did not occur with release 1.4 . That release was very clean. The top-level makefile botches two sed commands in the imake target. It was trying to glean values for CC and CPP from util/config. (I used the config*SPARC file for this.) I rewrote the sed commands to set these variables properly, and make SPARC then works. However, the subsequent make dies making runtime, with /bin/cc -DSPARC -c M3Runtime.c M3Runtime.c: 66: Can't find include file limits.h So, what's wrong here? ------------------------------------------------------------------------------ Date: Mon, 6 Aug 90 10:56:58 WST From: tim@madvax.maths.uwa.oz.au (Tim Boykett) Subject: AArrgghh!! Thank you to the two who replied to my anguished cry for help...but it still wont work! The problem essentially comes down to the libraries for Char etc ie the data, are not being found in the link. Well I think that that is it. So I tried -lm3data as I was told, but to no avail. I cannot read the man pages to check that I havent missed something, the sysop here doesn't seem to want to install m3 for everyone, and I cannot determine how to read the pages directly. HELP!!! I am trying to use m3 seriously, I believe in properly defined languages, but my boss is getting annoyed about my non-productivity, and wants me to change to C/C++. Even if someone could email me the plain text of the man pages, or tell me how to read them direct it would help.... Thanks in anticipation Tim Boykett tim@madvax.maths.uwa.oz ------------------------------------------------------------------------------ Date: Mon, 06 Aug 90 11:46:12 PDT From: Eric Muller Subject: Re: m3 1.5 install problems on SPARCstation > I ran into a couple problems while trying to bring up release 1.5 on > a SPARCstation 1+ running SunOS 4.0.3c. These problems did not occur > with release 1.4 . That release was very clean. > > The top-level makefile botches two sed commands in the imake target. It > was trying to glean values for CC and CPP from util/config. (I used > the config*SPARC file for this.) I rewrote the sed commands to set these > variables properly, and make SPARC then works. Jim Plank (plank.parc@xerox.com) sent a message on this list on 7/30 mentionning a few problem with the SPARC version. I suppose that sed command problem you report is fixed by this: 2. Change the two sed scripts on lines 70 and 71 in ./makefile from: cpp=`cat config | sed -e 's/^CPP[ \t]*=[ \t]*//p' -e 'd'`; \ cc=`cat config | sed -e 's/^CC[ \t]*=[ \t]//p' -e 'd'`; \ to cpp=`cat config | sed -n -e 's/^CPP[ \t]*=[ \t]*//p' -e 'd'`; \ cc=`cat config | sed -n -e 's/^CC[ \t]*=[ \t]//p' -e 'd'`; \ (the full message is in the july mail archive, available from gatekeeper.dec.com, in pub/DEC/Modula-3/m3-mail.07-90.Z). > However, the subsequent make dies making runtime, with > > /bin/cc -DSPARC -c M3Runtime.c > M3Runtime.c: 66: Can't find include file limits.h > > So, what's wrong here? Jim did not mention anything about that. Do you have a /usr/include/limits.h file ? Eric Muller. ------------------------------------------------------------------------------ System Research Center - 130 Lytton Av. - Palo Alto, CA 94301 - (415) 853 2193 ------------------------------------------------------------------------------ Date: Mon, 06 Aug 90 18:10:49 -0400 From: Roger Hoover Subject: Re: m3 1.5 install problems on SPARCstation The Sunos 4.0.3c distribution does not have /usr/include/limits.h. It compiles if you comment out the include line in M3Runtime.c A totally independent question: tetris seems to grow without bound. On a sparcstation, this gets up to about 5meg virtual space for about 10000 points or so. On the IBMR2 version, however, it grows about 5 times as fast. Any ideas where the memory leak is? roger hoover rhoover@ibm.com ------------------------------------------------------------------------------ Date: Wed, 8 Aug 90 10:55:55 EDT From: harbison@tartan.com (Samuel Harbison) Subject: Anyone got 1.5 on Sun-3? If anyone has successfully installed SRC Modula-3 1.5 on a Sun-3, I'd appreciate a note on how it was done. I have attempted such an installation in a SPARC.obj directory, using the SPARC target and after first fixing the sed and problems previously reported for SunOS 4.0.3. The Modula-3 compiler was built without apparent error, but it gets a segmentation fault when trying to compile the first Modula-3 module: AutoFlushWr.m3. (The .i3 file seemed not to cause any problems.) I had not attempted to install any previous release of SRC Modula-3 on the Sun-3, so if there is lore from older releases I'd like to hear of it. Thanks, Sam Harbison (Harbison@tartan.com) 305 S. Craig St., Pgh, PA 15213 (412) 681-9811 (ph+fax) ------------------------------------------------------------------------------ Date: Wed, 8 Aug 90 17:51:06 PDT From: sun0!mri!woolsey (Jeff Woolsey) Subject: My experiences with SRC m3 1.5 on SPARC Wed Aug 8 13:47:51 PDT 1990 Problems encountered while trying to install the SRC Modula-3 1.5 release on a SPARCstation 1+ running SunOS 4.0.3c . By comparison, the 1.4 release was flawless. 1. missing -n on the sed commands in the imake target in the top-level makefile 2. .ROOT/system/runtime/M3Machine.h includes which does not exist in SunOS 4.0.3c 3. make install fails because $(PREFIX)/lib/m3 doesn't exist beforehand 4. My links fail because of ld: -lm3ultrix-3.1: expected libx.so(.major.minor.xxx) 5. If I "fix" the above with setenv LD_OPTIONS -Bstatic, I get Undefined: _ParseParams__init _VS_ParseParams__GetParameter__81f129da259cd4a8 __ParseParams__GetParameter _VS_Char__Controls__3a84169430ead790 _VS_Char__Graphics__fa5dda4b22aa9875 __Char__Digits _VS_Char__AlphaNumerics__922461c120ef5f7b _VS_Char__Lowers__9f99c67120f6d160 _VS_Char__Uppers__d88653e628424649 _VS_Char__Digits__1f3ff2913a77d0fc _VS_Char__Asciis__cf04c68c3628875c _Char__init _VS_Char__NUL__ca9c3d492c7edcce _VS_Char__Letters__dc8b898c3d089725 Looks to me like the build process forgot to include at least Chars.io and ParseParams.io in their respective libraries. 6. make tests fails with each test unable to find M3Machine.h at CC-time when using .ROOT/compiler/m3local? when testing. I haven't been able to duplicate this one after repeated makes and installs and fudging. 7. This release requires more than 70MB of disk space and six hours to build and install. Some of that time may be due to NFS writes. I ran out of disk space running the tests after the install, especially when it leaves 70 270K executables lying around, and interposing a "clean" to reclaim disk space makes the test fail as the tests use the compiler where it was built, not where it was installed. The binaries that this release makes are gargantuan, even without the -g switch. Does anyone out there have suggestions for getting around these problems? (Answers like "punt the release", and "get a bigger disk" are not what I'm looking for...) -- Jeff Woolsey Microtec Research, Inc. ..!amdcad!sun0!woolsey +1 408 980 1300 x585 ------------------------------------------------------------------------------ Date: Thu, 09 Aug 90 13:59:22 PDT From: Eric Muller Subject: Re: My experiences with SRC m3 1.5 on SPARC > Problems encountered while trying to install the SRC Modula-3 1.5 release > on a SPARCstation 1+ running SunOS 4.0.3c . By comparison, the 1.4 release > was flawless. > 3. make install fails because $(PREFIX)/lib/m3 doesn't exist beforehand The model files for util/config mention that this directory should exist before the installation is attempted. I am willing to have the installation create missing directories if enough people ask for it. > 4. My links fail because of > ld: -lm3ultrix-3.1: expected libx.so(.major.minor.xxx) As James Planck mentionned, ld does not like it when a library name has a dot in it. We'll change that. > 7. This release requires more than 70MB of disk space and six hours > to build and install. Some of that time may be due to NFS > writes. I ran out of disk space running the tests after the > install, especially when it leaves 70 270K executables lying > around, and interposing a "clean" to reclaim disk space makes > the test fail as the tests use the compiler where it was built, > not where it was installed. The binaries that this release > makes are gargantuan, even without the -g switch. Running the tests is not part of the standard installation of the system. On a DECstation, the compiler itself compiled without optimization, with -g is 4.430 Mb. Stripping this executable brings it down to 1.350 Mb. I don't have a version an optimized version available, but I guess it should be much smaller than that. Is this the kind of sizes you are referring to (by opposition to the space needed to run the tests) ? Eric Muller. ------------------------------------------------------------------------------ System Research Center - 130 Lytton Av. - Palo Alto, CA 94301 - (415) 853 2193 ------------------------------------------------------------------------------ Date: Thu, 9 Aug 90 16:33:18 PDT From: sun0!mri!woolsey (Jeff Woolsey) Subject: Re: My experiences with SRC m3 1.5 on SPARC > 4. My links fail because of > ld: -lm3ultrix-3.1: expected libx.so(.major.minor.xxx) As James Planck mentionned, ld does not like it when a library name has a dot in it. We'll change that. Oh..... Meanwhile, what can I do about it until the next release is fixed? I'd really like to be able to _run_ the programs I write... (And static linking made it look as though the libraries were hosed.) (I haven't seen any of the July mail; if the answers are all in there I'll have to dig it up...) > 7. This release requires more than 70MB of disk space and six hour s > to build and install. Some of that time may be due to NFS > writes. I ran out of disk space running the tests after the > install, especially when it leaves 70 270K executables lying > around, and interposing a "clean" to reclaim disk space makes > the test fail as the tests use the compiler where it was built, > not where it was installed. The binaries that this release > makes are gargantuan, even without the -g switch. Running the tests is not part of the standard installation of the system. I ran them because I wondered if anything would run when I couldn't make my stuff link. It does. On a DECstation, the compiler itself compiled without optimization, with -g is 4.430 Mb. Stripping this executable brings it down to 1.350 Mb. I don't have a version an optimized version available, but I guess it should be much smaller than that. Is this the kind of sizes you are referring to (by opposition to the space needed to run the tests) ? On the SPARCstation, the unstripped compiler is more than 5MB; stripped it's about 1.5MB. This is reasonable. However, 270K for a simple monolithic program (such as Hello World) with maybe a dozen statements and nothing more complicated than Wr.PutText (which always behaved unbuffered (and very slow) to the terminal in 1.4...) doesn't seem very reasonable to me, especially if shared objects are to be used (I gather from a comment above that they aren't). The null program occupies 131072 bytes, 106496 bytes stripped. m3 missing.m3 goes into an infinite (or at least very long) loop after complaining: "missing.m3" does not exist. ------------------------------------------------------------------------------ Date: Thu, 9 Aug 90 16:33:18 PDT From: sun0!mri!woolsey (Jeff Woolsey) Subject: Re: My experiences with SRC m3 1.5 on SPARC > 4. My links fail because of > ld: -lm3ultrix-3.1: expected libx.so(.major.minor.xxx) As James Planck mentionned, ld does not like it when a library name has a dot in it. We'll change that. Oh..... Meanwhile, what can I do about it until the next release is fixed? I'd really like to be able to _run_ the programs I write... (And static linking made it look as though the libraries were hosed.) (I haven't seen any of the July mail; if the answers are all in there I'll have to dig it up...) > 7. This release requires more than 70MB of disk space and six hour s > to build and install. Some of that time may be due to NFS > writes. I ran out of disk space running the tests after the > install, especially when it leaves 70 270K executables lying > around, and interposing a "clean" to reclaim disk space makes > the test fail as the tests use the compiler where it was built, > not where it was installed. The binaries that this release > makes are gargantuan, even without the -g switch. Running the tests is not part of the standard installation of the system. I ran them because I wondered if anything would run when I couldn't make my stuff link. It does. On a DECstation, the compiler itself compiled without optimization, with -g is 4.430 Mb. Stripping this executable brings it down to 1.350 Mb. I don't have a version an optimized version available, but I guess it should be much smaller than that. Is this the kind of sizes you are referring to (by opposition to the space needed to run the tests) ? On the SPARCstation, the unstripped compiler is more than 5MB; stripped it's about 1.5MB. This is reasonable. However, 270K for a simple monolithic program (such as Hello World) with maybe a dozen statements and nothing more complicated than Wr.PutText (which always behaved unbuffered (and very slow) to the terminal in 1.4...) doesn't seem very reasonable to me, especially if shared objects are to be used (I gather from a comment above that they aren't). The null program occupies 131072 bytes, 106496 bytes stripped. m3 missing.m3 goes into an infinite (or at least very long) loop after complaining: "missing.m3" does not exist. ------------------------------------------------------------------------------ Date: 9 Aug 90 22:09:24 PDT (Thursday) From: "James_Plank.PARC"@Xerox.COM Subject: Script for installing m3-1.5 on the SPARC A bunch of people have requested this, so here's my shell script which fixes all the bugs that I found in porting m3-1.5 to the SPARC. What it lets me do is uncompress the tar file, run this script, and then 'make SPARC' and 'make' work with no bugs. This might not work on your SPARC because: - you're using /usr/local/m3-1.5 instead of /usr/m3-1.5, and therefore don't need to change the config. - your X libraries are in /usr/local/lib, and so the config doesn't need to be changed. - you use dvips and not dvi2ps, in which case you should delete all the changes relating to that. These are all pretty trivial changes to the script. The useful part of this is it does change the library names so that they don't contain dots, and thus you don't have to worry about bizarre ld options. This script should reside in the same directory as dist-1.5. Jim Plank jsp@princeton.edu or plank.parc@xerox.com -------------------------------------------------- #!/bin/sh # This file performs the file conversions for installing m3 # from the uncompressed tar files so that "make SPARC" and "make" # will all work. It should be the case that executing this # multiple times does no harm. echo "CONVERTING FILES FOR SPARC INSTALLATION" echo "Step 1 -- Creating config, and changing it" cat dist-1.5/util/config.dist-SPARC | sed -e 's%^PREFIX = .*$%PREFIX = /usr/m3-1.5%' \ -e 's%/usr/local/lib%/import/X11R4/usr/lib%' \ -e 's%dvips%dvi2ps%' \ -e 's%ultrix-3\.1%ultrix-3-1%' \ > dist-1.5/util/config echo "Step 2 -- Adding -n to the sed scripts of makefile" rm -f /tmp/makefile mv dist-1.5/makefile /tmp/makefile cat /tmp/makefile | sed -e 's/`cat config \| sed -e/`cat config \| sed '"-n -e/" \ > dist-1.5/makefile echo "Step 3 -- Changing doc/Imakefile to use dvi2ps correctly" rm -f /tmp/Imakefile mv dist-1.5/doc/Imakefile /tmp/Imakefile cat /tmp/Imakefile | sed 's%-$(DVIPS) -o f\.ps f\.dvi%-$(DVIPS) f\.dvi > f\.ps %' \ > dist-1.5/doc/Imakefile echo "Step 4 -- Changing system/driver/Imakefile to retain .c files" rm -f /tmp/Imakefile mv dist-1.5/system/driver/Imakefile /tmp/Imakefile cat /tmp/Imakefile | sed 's%^\([^/]*-/bin/rm -f m3\..*\)$%/\* \1 \*/ %' \ > dist-1.5/system/driver/Imakefile echo "Step 4a -- Changing system/loader/Imakefile to retain .c files" rm -f /tmp/Imakefile mv dist-1.5/system/loader/Imakefile /tmp/Imakefile cat /tmp/Imakefile | sed 's%^\([^/]*/bin/rm -f m3ld\..*\)$%/\* \1 \*/ %' \ > dist-1.5/system/loader/Imakefile echo "Step 5a-c -- Taking extraneous dots out of all the libraries" for i in ultrix-3.1 aix-3.1 aix-ps2-1.2 hpux-7.0 ibm-4.3; do ised=`echo $i | sed 's/\./\\\./g'` irep=`echo $i | sed 's/\./-/g'` rm -f /tmp/Imakefile mv dist-1.5/libs/Imakefile /tmp/Imakefile cat /tmp/Imakefile | sed "s:$ised:$irep:g" > dist-1.5/libs/Imakefile if [ -d dist-1.5/libs/$i ]; then echo "-- Changing $i to $irep" rm -f /tmp/Imakefile.0 mv dist-1.5/libs/$i/Imakefile.0 /tmp/Imakefile.0 cat /tmp/Imakefile.0 | sed "s:$ised:$irep:g" > dist-1.5/libs/$i/Imakefile.0 mv dist-1.5/libs/$i dist-1.5/libs/$irep else echo "-- $i Already changed to $irep" fi done ------------------------------------------------------------------------------ Date: 10 Aug 1990 1453-MET (Friday) From: Jean-Claude Herve Subject: overloading operators in m3 Is it possible to overload operators in Modula-3 (eg operator +) as C++ does ? Jean-Claude Herve. Paris Research Lab - 85 Av Victor Hugo - 92500 Rueil Malmaison, FRANCE - - +33 (1) 47 14 28 11 - Fax: +33 (1) 47 14 28 99 - ------------------------------------------------------------------------------ Date: Fri, 10 Aug 90 10:49:47 -0500 (CDT) From: Dick Orgass Subject: Version 1.5 for RISC 6000 Thanks to Eric Muller for doing a fine job on the Version 1.5 distribution. Small changes to two files are needed to build the entire system for AIX 3.1 on an IBM RISC 6000. They are described at the end of this note. The changes are so small that I didn't provide a patch file. Disk Space Requirements Installation bin .059 Mbytes lib/m3 6.856 Mbytes TOTAL 6.914 Mbytes You could save 1.73 Mbytes by removing the operating system libraries for other platforms. The executables are stripped in my installation. Building the System dist-1.5 (the SRC distribution): 26.252 Mbytes IBMR2.obj (a clone directory for this target): 76.340 Mbytes divided as follows: system (compiler and core libraries) 9.724 Mbytes libs (additional libraries) 7.316 Mbytes tools (without the m3pp program) .216 Mbytes tests (all binaries and output) 35.752 Mbytes demos 23.028 Mbytes Highwater TOTAL: 102.592 Mbytes The disk space requirements could be reduced by using shared libraries; I haven't had time to work on this problem yet. If you want to keep the highwater total down, you could delete the binary and output files for the tests after you have run them and build the demos after the tests have been run and then delete those that you don't want to keep. RISC 6000 Updates dist-1.5/makefile There are target specific changes to clone.c for all of the IBM Platforms. The #ifs in this file use the Modula-3 system target names instead of the C compiler target specific definitions. Therefore, the comments at the top of the make file should read as follows and the IBMR2 definition of CC should be as shown. # For IBMR2, set CC to /bin/bsdcc -DIBMR2; # see note in util/config.dist-IBMR2 first. # For AIX386, set CC to /usr/local/bin/hc -D_BSD -D_NO_PROTO -DAIX386 # or /bin/cc -D_BSD -D_NO_PROTO -DAIX386. # For IBMRT, set CC to /bin/cc -DIBMRT CC = /bin/bsdcc -DIBMR2 A bug in sed for AIX 3.1 causes the sed script in the rule for imake (near the end of the file) to fail. Until an update for sed is shipped, the following rule for imake will work: CPP = /usr/local/lib/cpp imake: FRC (cd util; \ sed -e s+M3_CPP+$(CPP)+ imake.c > imake.foo.c; \ /bin/bsdcc -o imake imake.foo.c; \ /bin/rm -f imake.foo.c) We use the 4.3 BSD cpp with Modula-3 and X and keep the binary in /usr/local/lib/cpp and that's why CPP is defined in this way. An alternative is to use the version of cpp shipped in /usr/lpp/X11. /lib/cpp will not work with either X or Modula-3. dist-1.5/tools/pp This change really isn't needed because the pretty printer, m3pp, doesn't work in version 1.5. Eric Muller has indicated that he will work on the problem in the future. At least for AIX 3.1, the lex library, libl.a, contains a main.o which defines function main. The ld command executed via m3.local when the make is done places -ll ahead of m3run.o which defines function main for Modula-3 programs. This means that main.o is used instead of m3run.o causing a number of undefined symbols. A quick fix is to do the following: (1) If you are building in the clone tree, IBMR2.obj, execute the following commands from this directory: cd tools/pp cp /usr/lib/libl.a . chmod u+w libl.a ar d libl.a main.o rm Imakefile cp .SRC/Imakefile . chmod u+w Imakefile Edit Imakefile to change line 30 as follows. Replace the string -ll with ./libl.a . If you are building in the distribution tree, dist-1.5, execute the following commands and then make the above change. cd tools/pp cp /usr/lib/libl.a . chmod u+w libl.a ar d libl.a main.o cp Imakefile Imakefile.SRC chmod u+w Imakefile (2) Complete building m3pp by executing the command .ROOT/util/m3all General Updates .../tests/ptests/p059/Imakefile This test program needs the operating system library for the target system. Modify line 10 to read as follows: LIBS = .ROOT/libs/misc/libm3misc.a .ROOT/libs/$(UNIX_LIB)/libm3$(UNIX_LIB).a .../tests/ptests/c109 The compiler will terminate with an assert failure when compiling this test case. This is a known problem for other platforms. Eric Muller is working on an update to the compiler. Dick ------------------------------------------------------------------------------ Date: Fri, 10 Aug 90 12:42:51 PDT From: Eric Muller Subject: Re: overloading operators in m3 In article <1990Aug10.090714.7716@src.dec.com>, mjordan@src.dec.com (Mick Jorda n) writes: |> In article <9008101253.AA17617@perle.prl.dec.com>, Jean-Claude Herve |> writes: |> |> |> |> Is it possible to overload operators in Modula-3 (eg operator +) |> |> as C++ does ? |> |> NO! We considered a proposal (from myself) to permit Algol68 style |> operator definition (partly because I am very sensitive to the C++ |> competition), but |> it was not considered worth the complexity. I would think that having a general mechanism in the CLU style is actually easier to implement than just the types allowed by Modula-3. Right now, the compiler has relatively complex IF THEN ELSE statements to handle the polymorphism of the built-in operators. Supporting a mechanism like CLU requires more elaborate data and control structures, but they ends up being much more regular and in practice simpler to write and maintain. |> I am strongly against the |> overloading of the built-in operators because, with a few exceptions such |> as complex numbers, it is a source of obfuscation. If you have to question |> the meaning of every + or -> symbol in a program, then I dont understand |> how code can ever be maintainable. I completely disagree. At the level of a module there is usually a coherent framework in which to explain the computations to perform and it is a key to success (for my style of programming) to have a simple notation for the elements and the operations on which my algorithm is based. For example, if I write a list processing module, variables named "u", "v" etc. are lists, variables named "x", "y", etc. are lists, the infix "." is cons, the infix "*" is append and so on (this is what happens after you have a class with McCarthy or Manna, I guess). In another module, say trees, I can very well reuse * for an operation on trees. I have no problem with that, mainly because one rarely speaks of trees and lists in the same module. If it is the case, I will redefine a new notation for that mix (this is one of the reasons I find renaming of imported operations and types useful, by the way). We already have such a style; the main type of module is usually written T. It is not a problem because the context gives enough information: T alone in a module is the main type of that module, T prefixed by "module." just makes clear which T we are dealing with. I feel depressed when after all the work of understanding my problem and developing an adequate notation, I have to change it to turn my algorithm into a program. Then it becomes obscure, then I start to have (more) bugs. If I go back to write a Web-like system for Modula-3, you can be assured that it will allow a change of notation in the output. Something like "when printing a call to the Modula-3 procedure Append (u, v: List.T), generate {u \star v}". Eric Muller. ------------------------------------------------------------------------------ System Research Center - 130 Lytton Av. - Palo Alto, CA 94301 - (415) 853 2193 ------------------------------------------------------------------------------ Date: Fri, 10 Aug 90 16:22:07 -0500 (CDT) From: Dick Orgass Subject: Version 1.5 for AIX PS/2 Carl Gadow of Broadway and Seymour, Inc at IBM Rochester has built Version 1.5 for AIX PS/2 1.2. Except for thread context switch, the system appears to work just as for the other platforms. Carl is working on the thread context switch problem and we will report a fix as soon as it is available. Executing a thread context switch causes a core dump. As a result, programs that do thread context switches will not execute. This includes the pretty printer, m3pp, and the following test cases: p006, p007, p008, p031 and p032. As for the other platforms, the compiler terminates with an ASSERT failure when compiling test c109. Carl points out that three changes to the top level make file are required. The following changes apply to a copy of makefile in dist-1.5/makefile or in AIX386.obj/makefile depending on how the system is being built. (1) At line 13 of makefile, CC should be defined to be one of the following: CC = /bin/cc -D_BSD -D_NO_PROTO -DAIX386 CC = /usr/local/bin/hc -D_BSD -D_NO_PROTO -DAIX386 (2) As stated in the comment, line 16 of makefile should read: LIBS = -lbsd (3) The two sed scripts on lines 70 and 71 (in the rule for imake) should be changed to: cpp=`cat config | sed -n -e 's/^CPP[ \t]*=[ \t]*//p' -e 'd'`; \ cc=`cat config | sed -n -e 's/^CC[ \t]*=[ \t]//p' -e 'd'`; \ Dick ------------------------------------------------------------------------------ Date: 12 Aug 90 15:12:47 PDT (Sunday) From: "James_Plank.PARC"@Xerox.COM Subject: ThreadF.Pause In Time.i3, Pause, LongPause, and PauseUntil are all defined as raising Alerted -- yet there is no such declaration in ThreadF.Pause, which is what they use to implement themselves. Is this because ThreadF.Pause ignores alerts, or is there some reason that I'm missing? Jim Plank plank@parc.xerox.com or jsp@princeton.edu ------------------------------------------------------------------------------ Date: Thu, 16 Aug 90 20:33:45 PDT From: Eric Muller Subject: Re: ThreadF.Pause > In Time.i3, Pause, LongPause, and PauseUntil are all defined as > raising Alerted -- yet there is no such declaration in ThreadF.Pause, > which is what they use to implement themselves. Is this because > ThreadF.Pause ignores alerts, or is there some reason that I'm missing? This is a bug. In the next release, Time.{Pause,LongPause,PauseUntil} will no longer raise Thread.Alerted. Three new procedures are introduced: Time.Alert{Pause,LongPause,PauseUntil} that raise Thread.Alerted and do the right thing (ThreadF.Pause is also modified). Thus, the situation will be similar to Thread.[Alert]{Join,Wait}. Thanks for the report, Eric Muller. ------------------------------------------------------------------------------ System Research Center - 130 Lytton Av. - Palo Alto, CA 94301 - (415) 853 2193 ------------------------------------------------------------------------------ Date: Fri, 17 Aug 90 13:02:02 MET DST From: Thomas Roemke Subject: Some bugs ???? I've just installed the new version 1.5 (sparc) successfully and (as I see) it works fine. --- Unfortunately even this version doesn't fit the syntax (and report) :-( Try to compile the following program: MODULE Error1 EXPORTS Main; TYPE Supertype = OBJECT x: INTEGER END; VAR i: INTEGER; BEGIN i := TYPECODE( Supertype OBJECT a: INTEGER END OBJECT X: CHAR E ND); END Error1. You'll get runtime error: ASSERT failed and sh: 298 Bus error - core dumped m3pp says: syntax error while pretty-printing; original position . .. I'm sure nobody of us will ever use this programming style, but the report says it's correct....... --- And now please sit down, take a cup of coffee, and try to compile the following: MODULE Error2 EXPORTS Main; TYPE y = z; TYPE z = y; BEGIN END Error2. :-) :-) After one hour of waiting, I interrupted the compiler. Somehow the compiler gets confused, if declarations are recursive. Sometimes empty types (size 0) are assumed for illegal types... The output of MODULE Error3; IMPORT Wr,Stdio,Fmt; (* illegal *) TYPE A = RECORD b: B END; TYPE B = ARRAY[1..BYTESIZE(A)] OF CHAR; (* allowed *) TYPE C = RECORD b: D END; TYPE D = REF ARRAY[1..BYTESIZE(C)] OF CHAR; BEGIN Wr.PutText(Stdio.stdout, "Size is "& Fmt.Int(BYTESIZE(A )) & "\n"); Wr.PutText(Stdio.stdout, "Size is "& Fmt.Int(BYTESIZE(C )) & "\n"); END Error3. is Size is 0 Size is 4 but in fact, the program shouldn't have been compiled without an error message. --- And finally there's a question left concerning the recursivity rule: The program MODULE a EXPORTS Main; TYPE b = REF b; BEGIN END a. is correct in the sense of the rule, but should it ? Thomas -- (* Thomas Roemke, University Paderborn, FRG modula-3@uni-paderborn.de ..!uunet!mcsun!unido!pbinfo!modula-3 *) ------------------------------------------------------------------------------ Date: Fri, 17 Aug 90 16:17:46 PDT From: sun0!mri!woolsey (Jeff Woolsey) Subject: m3 compiler bug I finally tracked this one down. I think a semantic error message would be a lot more helpful than the compiler dying with an assertion failure. (Assuming, of course, that TEXT and ARRAY OF CHAR really are different (TEXT being opaque and all...). Don't ask me how I feel about TEXT.) This is on a SPARCstation 1+ running SunOS 4.0.3c . MODULE boom; PROCEDURE A(x: ARRAY OF CHAR)= BEGIN END A; VAR nameT: TEXT; BEGIN A(nameT); END boom. -- Jeff Woolsey Microtec Research, Inc. .!amdcad!sun0!woolsey +1 408 980 1300 x585 ------------------------------------------------------------------------------ Date: Fri, 17 Aug 90 17:04:55 PDT From: Eric Muller Subject: Re: m3 compiler bug > I finally tracked this one down. I think a semantic error message > would be a lot more helpful than the compiler dying with an assertion > failure. (Assuming, of course, that TEXT and ARRAY OF CHAR really are > different (TEXT being opaque and all...). Don't ask me how I feel > about TEXT.) This is on a SPARCstation 1+ running SunOS 4.0.3c . > > MODULE boom; > > PROCEDURE A(x: ARRAY OF CHAR)= BEGIN END A; > > VAR > nameT: TEXT; > > BEGIN > A(nameT); > END boom. I fixed this bug yesterday (no kidding). By the way, a TEXT is really an ARRAY OF CHAR (with some additional constraints). The interface TextF reveals that. The "F" in "TextF" means "Friend". Most of the importers of Text are satisfied with it but others need to know more and the friend interface helps these. Something goes in a friend interface if it can not be supported by most of the implementations one could think of for the standard interface. Obviously, revelations of opaque types are typically found in friend interfaces. Additional functionnalities is another case. In 1.5, we have TextF, ThreadF, S{_,Int,Text}TableF. Eric Muller. ------------------------------------------------------------------------------ System Research Center - 130 Lytton Av. - Palo Alto, CA 94301 - (415) 853 2193 ------------------------------------------------------------------------------ Date: Fri, 17 Aug 90 18:07:09 PDT From: sun0!mri!woolsey (Jeff Woolsey) Subject: Re: m3 compiler bug ----- Begin Included Message ----- Subject: Re: m3 compiler bug Date: Fri, 17 Aug 90 17:04:55 PDT From: Eric Muller By the way, a TEXT is really an ARRAY OF CHAR (with some additional constraints). The interface TextF reveals that. ----- End Included Message ----- I wish I'd known about TextF earlier. TEXT has caused me more grief than anything else in trying to convert Modula-2 programs to Modula-3. What with all of these procedures to convert from TEXT to ARRAY OF CHAR and back, and some procedures want TEXT and others want ARRAY OF CHAR for the same data, it's been a real problem trying to keep track of what was in what form at what time. Looks like I need to rethink a fair amount of the converting I've been doing this past couple weeks... While I'm complaining, I might as well also ask why the stdout Wr[iter] is always unbuffered, or, rather, how to make it buffered. Presently it makes a system call for every character, which looks about like 4800 bps output in a Sunview window. (Sunview is capable of MUCH greater apparent speed than that, particularly on a SPARCstation...) I've taken to writing a buffered InOut module to get around that problem. -- Jeff Woolsey Microtec Research, Inc. ..!amdcad!sun0!woolsey +1 408 980 1300 x585 ------------------------------------------------------------------------------ Date: Sat, 18 Aug 90 11:50:05 EDT From: harbison@tartan.com (Samuel Harbison) Subject: Getting release 1.5 on Sun-3 Release 1.5 will not build correctly on a Sun-3 if you use the SPARC target; the structure-packing constants in Target.i3.SPARC are not correct for the Sun-3 C compiler. The built compiler dies compiling the first .m3 file in the libraries (AutoFlushWr.m3). I have been able to bring up Release 1.5 on a Sun-3 well enough to compile and run a simple example by using the HP300 target, whose constants happen to match Sun-3. You have to hand-massage the build to get a correct version of stack.c and the OS interfaces. I will continue to pursue this port in my available time and would be happy to hear from others trying it. My working hypothesis is that if Target.i3 were changed, and all .ic and .mc files depending on it regenerated, the SPARC target would otherwise be OK for Sun-3. (The unrelated and previously-reported bugs in the Release 1.5 SPARC build have to be fixed for Sun-3 also.) Some minor portability notes for M3 translator-writers: It's probably better not to try to second-guess the C compiler if you can avoid it. The C code out of m3compiler contains some magically-derived numbers for sizes of types that could be eliminated by using 'sizeof' in the generated code. Also, the C type 'int' especially should not be used in the generated code; either use 'long' or better yet a typedef name. (I briefly toyed with the idea of compiling some SRC M3 code on a machine with 16-bit int's, but soon thought better of it.) Sam Harbison ----------------------------------------------------------------------------- Pine Creek Software. Suite 300, 305 S. Craig St., Pgh, PA 15213. 412-681-9811. ------------------------------------------------------------------------------ Date: Mon, 20 Aug 90 11:03:54 PDT From: Eric Muller Subject: Re: m3 compiler bug > ... some procedures want TEXT and others want ARRAY OF CHAR for > the same data, it's been a real problem trying to keep track of what was > in what form at what time. I think that except for Convert (which is really a low-level interface for Fmt and Scan) and some procedures of Text, all the other interfaces use Text.T. Of course, we may have missed some and will gladly convert them. > While I'm complaining, I might as well also ask why the stdout Wr[iter] is > always unbuffered, or, rather, how to make it buffered. Stdio.bufferedStdout and Stdio.bufferedStderr are what you want. If you write to Stdio.bufferedStdout, then to Stdio.stdout, the characters may go out of order. Used in conjunction with AutoFlushWriters, you get something that is buffered and for which you generally don't need to flush. Some the interfaces that are documented in the Modula-3 report and the I/O report have been extended in our system. It may be worth to look around at what is available. If you think that the current organization of the installed files makes this browsing difficult, we would be interested in hearing of better schemes/tools. Eric Muller. ------------------------------------------------------------------------------ System Research Center - 130 Lytton Av. - Palo Alto, CA 94301 - (415) 853 2193 ------------------------------------------------------------------------------ Date: Mon, 20 Aug 90 12:28:54 PDT From: Eric Muller Subject: Re: Getting release 1.5 on Sun-3 > Release 1.5 will not build correctly on a Sun-3 if you use the SPARC target; > the structure-packing constants in Target.i3.SPARC are not correct for the > Sun-3 C compiler. > ... > My working > hypothesis is that if Target.i3 were changed, and all .ic and .mc files > depending on it regenerated, the SPARC target would otherwise be OK for Sun-3 If we have the parameters that go in Target.i3, there is no problem to add this machine to our list. > Some minor portability notes for M3 translator-writers: It's probably better > not to try to second-guess the C compiler if you can avoid it. The > C code out of m3compiler contains some magically-derived numbers for > sizes of types that could be eliminated by using 'sizeof' in the > generated code. But we cannot avoid it. Consider the following code: TYPE Rec = RECORD ... END; VAR v: [1..Word.Shift (BYTESIZE (Rec), -1)]; This can be legal or illegal depending on the size of Rec. > Also, the C type 'int' especially should not be used in the > generated code; either use 'long' or better yet a typedef name. (I > briefly toyed with the idea of compiling some SRC M3 code on a machine > with 16-bit int's, but soon thought better of it.) The Modula-3 report does not say that the minimal and maximal values of INTEGER are. SRC Modula-3 turns INTEGER into int and I think this should work fine. Of course, we have never tried to generate code for a 16 bits machine, but I would say that there are bugs in the system if it doesn't work. Eric Muller. ------------------------------------------------------------------------------ System Research Center - 130 Lytton Av. - Palo Alto, CA 94301 - (415) 853 2193 ------------------------------------------------------------------------------ Date: 21 Aug 90 12:49:06 PDT (Tuesday) From: "James_Plank.PARC"@Xerox.COM Subject: Compiler Bug: Returning from TRY-EXCEPT The compiler is generating bad C code for returning from TRY-EXCEPT blocks. The following module is an example: MODULE Main; EXCEPTION Number1; EXCEPTION Number2; CONST T = TRUE; PROCEDURE ReturnFromException() = BEGIN TRY IF T THEN RETURN; END; EXCEPT Number1 => RETURN; END; END ReturnFromException; PROCEDURE RaiseException2() = BEGIN RAISE Number2; END RaiseException2; BEGIN TRY ReturnFromException(); RaiseException2(); EXCEPT Number2 => (* DO Nothing *) END; END Main. This generates the following C code for ReturnFromException: PRIVATE t6 _Main__ReturnFromException () { #line 8 "Main.m3" { { CHECKSTACKOVERFLOW; { HANDLER htry_0; PUSH_TRY (htry_0, try_labels_0, try_0); #line 11 if ( 1 ) { return; }; CUT_TO_NEXT_HANDLER (htry_0); goto try_0_exit; try_0: CUT_TO_NEXT_HANDLER (htry_0); if ((htry_0.exception->e == & _Main__Number1)) { #line 11 return; }; RAISE_FOR_SURE (htry_0.exception); try_0_exit: /**/; }; } } }; Note that the first return doesn't pop htry_0 off of the _ThreadSup__handlers list, so when it returns, _ThreadSup__handlers points to htry_0's location, which is now garbage. This bug is in the M3 compiler -- in Host.OpenWriter, but it doesn't get discovered, as under normal execution, no exceptions are raised. Jim Plank jsp@princeton.edu or plank.parc@xerox.com ------------------------------------------------------------------------------ Date: Thu, 23 Aug 90 17:49:10 WST From: tim@madvax.maths.uwa.oz.au (Tim Boykett) Subject: Procedure Types A theoretical question...why aren't PROCEDUREs a subtype of REFANY? Tim tim@madvax.maths.uwa.oz boykett@wacsvax.cs.uwa.oz ------------------------------------------------------------------------------ Date: Sat, 25 Aug 90 12:23:06 EST From: Ryan Stansifer Subject: m3 compiler The problem illustrated in the program below caught me unawares. It seems to me the compiler can detect when an object is created by NEW without a procedure associated with some method. Shouldn't it? MODULE Main; TYPE T = OBJECT METHODS m(); (* no default *) END; R = RECORD f: INTEGER END; (* no default for "f" either *) VAR O := NEW (T); (* Shouldn't the compiler complain? *) X := R{}; (* We get a type-checking error here! *) BEGIN O.m(); END Main. ------------------------------------------------------------------------------ Date: Sat, 25 Aug 90 16:07:57 EDT From: diwan%ibis@cs.umass.edu (Amer Diwan) Subject: m3 compiler This is in response to Ryan's message... >MODULE Main; >TYPE > T = OBJECT > METHODS > m(); (* no default *) > END; > R = RECORD f: INTEGER END; (* no default for "f" either *) >VAR > O := NEW (T); (* Shouldn't the compiler complain? *) No. According to the Modula-3 report: "Fields or methods for which no binding is supplied will be initialized to their defaults if they have defaults;... Note that methods always have defaults, since the "default default" is NIL". However, if the 'm' method is invoked, then it should result in a runtime error (M3 Report: Statements: Procedure Call: "It is a checked runtime error to call an undefined or NIL procedure). > X := R{}; (* We get a type-checking error here! *) M3 Report: Expressions: Set, array, and record constructors: "The rewritten bindings must bind only field names and must bind each field name exactly once". Thus, if you don't have default for a record field, then your constructor must provide some value for it. >BEGIN > O.m(); >END Main. Amer ------------------------------------------------------------------------------ Date: Mon, 27 Aug 90 19:09:56 N From: Subject: inheritance and methods Here's a program which produces output that doesn't make sense to me. I thought that methods are all virtual. Can anybody explain ? (see the comments) Solange ---------------------------------------------------- TYPE A = OBJECT METHODS foo () := fooA; END; (* B overrides foo *) B = A OBJECT dummy: INTEGER; METHODS foo () := fooB; END; VAR a: A; b: B; PROCEDURE fooA (self: A) = BEGIN Wr.PutText (Stdio.stdout, "foo A\n"); END fooA; PROCEDURE fooB (self: B) = BEGIN Wr.PutText (Stdio.stdout, "foo B\n"); END fooB; PROCEDURE MethodTestA (x: A) = BEGIN x.foo (); END MethodTestA; PROCEDURE MethodTestB (x: B) = BEGIN x.foo (); END MethodTestB; BEGIN b := NEW (B, dummy:= 0); (* comments display the output *) b.foo (); (* foo B *) MethodTestA (b); (* foo A -> I would expect foo B *) MethodTestB (b); (* foo B *) a := b; (* a is type A and B *) a.foo (); (* foo A -> I would expect foo B *) MethodTestA (a); (* foo A -> I would expect foo B *) MethodTestB (a); (* foo B *) END test. ------------------------------------------------------------------------------ Date: 27 Aug 1990 1154-PDT (Monday) From: Subject: Re: inheritance and methods Solange, A method override has the syntax methodName := defaultValue not the syntax methodName signature := defaultValue which occurs in your declaration of the type B. That is, instead of overriding the method, you accidentally declared a subtype with two methods, both named "foo". If you change the line TYPE B = A OBJECT dummy: INTEGER METHODS foo () := fooB END to TYPE B = A OBJECT dummy: INTEGER METHODS foo := fooB END the program will work the way you expect. Greg ------------------------------------------------------------------------------ Date: 28 Aug 90 21:07:58 PDT (Tue) From: ogicse!agora!tima (Tim Anderson) Subject: Total bonehead makes first attempt at M3... I made attempt number one at compiling Modula-3 today, and I thought I'd voice some problems... System: SGI 4D/20 I chose to compile things using the DS3100 switch, simply because the SPARC switch used a non-existent file on my system. Prob 1: system/driver/m3.c prototyped system (I think, not sure!) and the SGI gags endlessly if you prototype calls that have already been prototyped. Prob 2: system/corelib/cconvert.ic system/corelib/convert.mc prototyped scanf. See above. Prob 3: system/runtime/M3Runtime.c hard wired ld to /bin/ld. SGI uses /usr/bin/ld. This I fixed in the config file also. For some odd reason after doing a make I still got the sh: /bin/ld not found error. I am assuming that the makefile did not include something that actually was dependant on /system/runtime/M3Runtime.c. I copied ld to /bin/ld and tried again. Prob 4: totally ran out of disk space (approx 37 megs). I will have to work on this after I purchase a bunch of tapes to back up all of my neato demo's. I will make a ton of room sometime next month, and try from scratch. I noticed that a make -u (or make everything regardless) dies continuously because ln fails when you try to link existing files. I gotta run, but I thought I'd let the powers that be know of the 'anomolies' that I found... tima@agora.hf.intel.com ------------------------------------------------------------------------------ Date: Wed, 29 Aug 90 16:53:26 EDT From: harbison@tartan.com (Samuel Harbison) Subject: A Modula-3 questonnaire (170 lines) MODULA-3 QUESTIONNAIRE Well, folks, the next year promises to be a big one for Modula-3. BYTE magazine will carry an article on Modula-3 in their November issue, and other articles, a couple of books, and possibly some new implementations are in the works. My company, Pine Creek Software, is trying to help make Modula-3 a success. We're working with the authors and DEC to publicize the language and to develop services and products for Modula-3 programmers and students. You can help us set priorities for the coming year by telling us how you are using Modula-3 and what we or others could do to support you. (And what you'd like to do to help.) Please take a few minutes to edit your answers into the following questionnaire and return it to harbison@tartan.com. Don't reply directly to the Modula-3 BBoard, since (I hope) there will be many messages. I'll post a summary of the responses. Don't be limited by the questions; if you want to submit an essay, go ahead. If it's more convenient, mail your response to Pine Creek Software, Suite 300, 305 S. Craig St., Pittsburgh, PA 15213. If you have questions, please call me at 412-681-9811. Thanks, Sam Harbison ----- To: harbison@tartan.com Subject: Modula-3 questionnaire response Questionnaire responses will be summarized and the summary will be posted or released to anyone who asks for it. Your particular responses will not be released unless you give permission. Is it all right to release your response? (yes/no) -> Part 1: The Modula-3 Language. (In this section, please disregard current implementations.) Generally speaking, how well do you like the Modula-3 language? (e.g., not at all, a little, a lot, tremendously) -> Which features or capabilities of Modula-3 are particularly good? -> What features (present or missing) significantly hinder your use of Modula-3? (e.g., multiple inheritance, overloading, generics, case sensitivity, garbage collection, threads) -> What features or changes are on your "wish list" for Modula-3? -> Modula-3 is currently described in a research report from SRC and Olivetti. Is this report sufficient to support your programming? Would you like a more detailed reference? Would you like a Modula-3 programming textbook? -> In your opinion, what other languages compete most directly with Modula-3? How does Modula-3 stack up against them? -> Do you think Modula-3 has the potential to be a major programming language of the 1990's? (If not, why not?) -> Part 2: Implementations. What computer(s) do you run Modula-3 on now? -> What other computers would have to support Modula-3 for you to use Modula-3 seriously? (PC/DOS? Mac? VAX/VMS? Crays? Other UNIX machines?) -> If you've programmed in Modula-3, how much code have you written? -> Do you currently use the SRC implementation, the Olivetti implementation, or some other? (If you use more than one, indicate the approximate percentages and which one you like best.) -> Are these implementations satisfactory for your current interest in Modula-3? What do they need most? -> Would these implementations support the use of Modula-3 as your principal programming language? What would they need most? -> Are the libraries (I/O, OS, strings, etc.) provided with your Modula-3 implementations adequate? How would you like them enhanced or changed? -> Is it important to have more general-purpose libraries, such as support for particular data structures? Which ones do you want? -> Is the documentation with the implementations adequate? What improvements would you like to see? -> Which of the following Modula-3 implementations would you use? (You can choose more than one.) a. An interpreter with excellent diagnostic, interactive, and debugging capabilities. b. A fast compiler that generates "OK" code, with a debugger. c. A slower compiler that generates highly optimized code, with a debugger. d. A fully integrated and graphically-oriented system with editor, compiler, linker, debugger, etc. -> Which currently-available compilers or programming environments (for any language) do you like? Which one(s) do you use? -> Part 3: You, again. If you are using Modula-3 for a specific project, or are working on an implementation, please tell us something about it. -> Are you planning to produce any Modula-3 software that could be used by other Modula-3 programmers? -> Would you be interested in writing an article on Modula-3 for the trade press or for a refereed journal or conference? If so, what subject areas interest you? -> Would you be willing to teach a conference tutorial on Modula-3, or organize a conference discussion? -> Are you planning to use Modula-3 in an academic course? If so: which course, where, and is there anything you need for it? -> Would you be interested in a "Modula-3 user's group," or in receiving a regular newsletter about Modula-3 developments? If so, please include a postal address below. -> (Postal address) What is the single most important thing we could do to support your use of Modula-3? -> If your job was to make Modula-3 a success, what would you do first? -> That's it. Thanks for your time. ------------------------------------------------------------------------------ Date: Wed, 29 Aug 90 19:01:56 PDT From: Eric Muller Subject: Re: Total bonehead makes first attempt at M3... > I made attempt number one at compiling Modula-3 today, and I thought I'd > voice some problems... Thanks. > Prob 1: system/driver/m3.c prototyped system (I think, not sure!) and > the SGI gags endlessly if you prototype calls that have already been > prototyped. Hum. The declaration for system we have in system/driver/m3.c is extern union wait system (); It seems to me that this should be compatible with any prototype that would come from one of the include files. Unless the return type is not the same on your machine. In any case, system is not used in the driver, and I removed the declaration for the next release. > Prob 3: system/runtime/M3Runtime.c hard wired ld to /bin/ld. SGI uses > /usr/bin/ld. This I fixed in the config file also. For some odd reason > after doing a make I still got the sh: /bin/ld not found error. I am > assuming that the makefile did not include something that actually was > dependant on /system/runtime/M3Runtime.c. I copied ld to /bin/ld and > tried again. Don't worry about the /bin/ld in M3Runtime.c. This is part of an experimental piece of code (to do fast-turnaround) that is being developped only for the DS3100 architecture for now. Of course, such things should come from the config file. Yes, we don't have full dependencies in the Imakefiles. This is not a problem for the Modula-3 code: there are some special symbols in the objects files to do a fine-grain analysis. > Prob 4: totally ran out of disk space (approx 37 megs). I will have to > work on this after I purchase a bunch of tapes to back up all of my > neato demo's. In 1.6, you will be able to control which Unix libraries you want. That should cut a bit the disk usage. > I gotta run, but I thought I'd let the powers that be know of the > 'anomolies' that I found... Thanks a lot. Eric Muller. ------------------------------------------------------------------------------ System Research Center - 130 Lytton Av. - Palo Alto, CA 94301 - (415) 853 2193 ------------------------------------------------------------------------------ Date: Thu, 30 Aug 90 15:42:47 EDT From: hudson@yough.ucc.umass.edu (Rick Hudson) Subject: Open array constructors. "An open array type can be used only as the type of a formal parameter, the referent of a reference type, the element type of another open array type, or as the type in an array constructor." pg 5 "VAR id: T := E ... If T is omitted, it is taken to be the type of E." pg 29 We have a question about what the language designers meant when they allowed open array constructors. First an example: VAR foo := ARRAY OF INTEGER {1, 2, 3}; bar : ARRAY [1 ..3] OF INTEGER := ARRAY OF INTEGER {1, 2, 3}; Clearly variable bar has the type ARRAY [1 .. 3] OF INTEGER. What is not clear is what the type of foo is or even if this is a legal declaration. Is foo's type a fixed array or an open array. As an implementor my preference is for the simpler answer of foo's type is the same as bar's type. If the designers meant the use of open array constructors to be a convenience to programmers so they don't have to count elements then the type of foo should be fixed array. If they meant to force programmers to count these elements, then is the declaration for foo illegal or is this a way to declare some variable an open array? - Rick and Amer ------------------------------------------------------------------------------ Date: Thu, 30 Aug 90 14:43:19 PDT From: Eric Muller Subject: Re: Open array constructors. > VAR > foo := ARRAY OF INTEGER {1, 2, 3}; > bar : ARRAY [1 ..3] OF INTEGER := ARRAY OF INTEGER {1, 2, 3}; I know that the SRC implementation differs from the report in that area. That is, "ARRAY OF INTEGER {1, 2, 3}" is interpreted to be the same as "ARRAY [0..2] OF INTEGER {1, 2, 3}". I could not find any value in the strict interpretation, other than to have to count the elements and be wrong half of the time (no, I don't know how to count, that's why I'm using computers). Of course, those who do not trust computers can still pretend they know better and write "ARRAY [0..2] OF INTEGER". Note the index type is [0..2]; this is preferable to [1..3], as it is the range of legal values for the open array type. I realize that this difference did not make it in the Release notes. I'll make sure it is there for the next release. Sorry if this caused some problems. Eric Muller. ------------------------------------------------------------------------------ System Research Center - 130 Lytton Av. - Palo Alto, CA 94301 - (415) 853 2193 ------------------------------------------------------------------------------ Date: 30 Aug 1990 1552-PDT (Thursday) From: Subject: Re: Open array constructors. This issue was discussed at length. As the manual says, the type of T{...} is T, even if T is an open array type. Since open array variables are illegal, this will sometimes force the programmer to count the number of entries in a large array constructor. However, large array constructors are usually constants, and CONST V = ARRAY OF T{...} is legal. So if the programmer is willing to name the constant array (which he often will want to do anyway) he doesn't have to count the elements. ------------------------------------------------------------------------------ Date: 30 Aug 1990 1642-PDT (Thursday) From: Subject: Re: Open array constructors. Greg writes: > However, large array constructors are usually constants, and > > CONST V = ARRAY OF T{...} > > is legal. So if the programmer is willing to name the constant array > (which he often will want to do anyway) he doesn't have to count the > elements. I don't see how this suggestion solves the problem. Eric wants to be able to declare a *variable* of an array type and have the number of elements determined by the size of the initializer. As I read the report, the constant V in the example above has type (open) ARRAY OF T, so it still can't be used as the initializer for a variable whose type is elided. Thus the following two examples are both illegal for the same reason: 1) Eric's example VAR foo := ARRAY OF INTEGER {1, 2, 3}; 2) What Greg seems to be suggesting CONST V := ARRAY OF INTEGER {1, 2, 3}; VAR foo := V; --Tim ------------------------------------------------------------------------------ Date: Fri, 31 Aug 90 09:54:29 EDT From: moss%ibis@cs.umass.edu (Eliot Moss) Subject: RE: Open array constructors. I had assumed that Greg meant something like this: CONST AV = ARRAY OF INTEGER {1, 2, 3}; VAR v: ARRAY [ 1 .. NUMBER(AV) ] := AV; It's a bit more writing, but does not require counting the number of array elements ... Eliot J. Eliot B. Moss, Assistant Professor Department of Computer and Information Science Lederle Graduate Research Center University of Massachusetts Amherst, MA 01003 (413) 545-4206; Moss@cs.umass.edu ------------------------------------------------------------------------------ Date: Fri, 31 Aug 90 10:06:56 EDT From: emery@d74sun.mitre.org (David Emery) Subject: RE: Open array constructors. One of the nicest pieces of the Ada language design (in my humble opinion) are type attributes. To me, "av'range" is a lot nicer than "number(av)". Once you get used to using them, Ada attributes are real easy to use, easy to read (particularly with respect to maintenance, it's easy to see that this expression is an attribute, which means go back and look at the type declaration), and contribute significantly to program portability and reliability. I also suspect that they make things easier for the compiler, since it's real easy to generate the optimum code when the type is constrained (by substituting a constant). But then, language beauty is in the eyes of the beholder. dave emery emery@aries.mitre.org ------------------------------------------------------------------------------