Date: Wed, 03 Oct 90 12:43:42 PDT From: Eric Muller Subject: September m3 mailing list archive available The mail archive for the messages sent to the m3 mailing list during the month of September is available via anonymous ftp from gatekeeper.dec.com, in pub/DEC/Modula-3/m3-mail.09-90.Z. Previous months can be found in the same directory. Eric Muller. ------------------------------------------------------------------------------ System Research Center - 130 Lytton Av. - Palo Alto, CA 94301 - (415) 853 2193 ------------------------------------------------------------------------------ Date: Fri, 5 Oct 1990 13:34:18 -0500 (CDT) From: Dick Orgass Subject: Updated fixes for Modula-3 on AIX PS/2 v 1.2 Michael Bauers of Broadway & Seymour, Inc has been doing some additional work on the AIX PS/2 port of SRC Modula-3, Version 1.5. The attached notes describe the changes that are needed to bring the system up on AIX PS/2 v 1.2. The problem with threads remains but we do have an approach to solving the problem. I'll post additional information as we have it. Dick ---------- Forwarded message begins here ---------- Date: Fri, 5 Oct 90 12:05:22 -0500 (CDT) From: Michael Bauers Subject:ps2/aix1.2 fixes The following changes are necessary to complete the build of version 1.5 of the SRC Modula-3 compiler for the PS2/AIX1.2 system. With the changes, it should correctly build the compiler and associated libraries. The tests cases also compile and execute correctly except in the following instances: c109, p006, p007, p008, p031, p032. Test case c109 is a known bug on all platforms. The remaining test cases all test threads. We are currently looking into fixing the thread problem. Notes: The Berkeley version of CPP was used rather than the product CPP. The MIT CPP provided with the X distribution will also work. Changes: 1. Add -DAIX386 to line 13 in ./makefile from: CC = /bin/cc to CC = /bin/cc -DAIX386 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'`; \ 3. 'ld' on the aix1.2 system was unable to find the aix library aix-ps2-1.2. I fixed this problem by shortening the name to 'aixps2'. The following changes are needed to do this. a) Rename .ROOT/libs/aix-ps2-1.2 to .ROOT/libs/aixps2 b) In .ROOT/util/config change 'UNIX_LIB aix-ps2-1.2' to 'UNIX_LIB aixps2' c) In .ROOT/libs/Imakefile change 'subdir(aix-ps2-1.2)' to 'subdir(aixps2)' d) In .ROOT/libs/aixps2/Imakefile.0 change 'LIB = aix-ps2-1.2' to 'LIB = aixps2' ------------------------------------------------------------------------------ Date: Fri, 05 Oct 90 17:00:35 PDT From: Eric Muller Subject: CALL FOR DISCUSSION: comp.lang.modula3 I have sent the following CALL FOR DISCUSSION to various newsgroups. I believe the creation of such a group would be good for Modula-3. Please help me make this group a reality; I'd like to keep a low-profile during the discussion. The message was posted to: news.announce.newgroups comp.compilers comp.lang.pascal comp.lang.c++ comp.lang.clu comp.lang.eiffel comp.lang.modula2 comp.lang.objective-c with followup to news.groups. Thanks, Eric Muller. PS: for those of you who do not have access to the USENET newsgroups, we will install a relay. ------------------------------------------------------------------------------ System Research Center - 130 Lytton Av. - Palo Alto, CA 94301 - (415) 853 2193 ----------------------------------------------------------------------------- I would like to propose the creation of comp.lang.modula3. NAME: comp.lang.modula3 STATUS: unmoderated CHARTER: Modula-3 is a new programming language (see below for a short description). This newsgroup would serve to discuss all aspects of the language, such as use of language, good style, availability of implementations, implementation techniques. WHY A GROUP ? There are currently two freely available implementations of the language. Other people are also working on implementations. There are also two mailing lists related to Modula-3: one as been setup to discuss the use of one of the implementations; the other deals more with implementation issues. It seems that the level of interest in Modula-3 and the traffic on theses lists is now large enough to justify the creation of a newsgroup. SCHEDULE: 1. Discussion: The discussion period will begin on Friday, October 5. 2. Voting: Assuming that the discussion does not kill this proposal, I will issue a Call For Votes on Friday, November 2. The vote will run for 21 days from when the Call For Votes appears in news.announce.newsgroups. I will post a second Call For Votes, and possibly a list of unreachable return addresses, during the voting period. When the vote is over, I will post the final results. 3. Waiting Period: I will observe the normal waiting period of five days from the time that the final results appear in news.announce.newgroups. During this time, people may report lost votes. 4. Consummation: After the waiting period, I will issue the appropriate control message to create comp.lang.modula3. About one week later, I will re-issue the creation control message. SHORT DESCRIPTION OF MODULA-3: Modula-3 is a new programming language. The goals of its design are best encapsulated in the preface to the "The Modula-3 Report (Revised)", (L. Cardelli, J. Dohnaue, L. Glassman, M. Jordan, B. Kalsow, G. Nelson, DEC Systems Research Center, Palo Alto, CA and Olivetti Research Center, Menlo Park, CA, Nov 89.): The goal of Modula-3 is to be as simple and safe as it can be while meeting the needs of modern systems programmers. Instead of exploring new features, we studied the features of the Modula family of languages that have proven themselves in practice and tried to simplify them into a harmonious language. We found that most of the successful features were aimed at one of two main goals: greater robustness, and a simpler, more systematic type system. Modula-3 descends from Mesa, Modula-2, Cedar, and Modula-2+. It also resembles its cousins Object Pascal, Oberon, and Euclid. Modula-3 retains one of Modula-2's most successful features, the provision for explicit interfaces between modules. It adds objects and classes, exception handling, garbage collection, lightweight processes (or threads), and the isolation of unsafe features. ------------------------------------------------------------------------------ Date: Wed, 10 Oct 1990 11:39:36 -0500 (CDT) From: Dick Orgass Subject: Fwd: SRC 1.5 Modula-3 port to RT/AOS4 ---------- Forwarded message begins here ---------- Date: Wed, 10 Oct 90 09:46:43 -0500 (CDT) From: Michael Bauers To: Dick Orgass Subject: SRC 1.5 Modula-3 port to RT/AOS4 This note is a correction of the note Paul Gunsch sent for me on September 25. This procedure will not correct a build tree that the Septmeber 25th fix was applied to. If you did not apply the September 25th fix ignore the rest of this paragraph. If September 25th fix has already been applied, all you have to do is correct the files M3Runtime.c, and merge.c as follows: (1) M3Runtime.c : Change the line 'fprintf (stderr, fmt, args)' to '_doprnt ( fmt, args, stderr)'. The 'fprintf' line approximately occurs on line 114 below the '#if defined (IBMRT)' line. (2) merge.c : Change the line 'fprintf (stderr, fmt, args)' to '_doprnt ( fmt, args, stderr)'. The 'fprintf' line approximately occurs on line 49 below the '#if defined (IBMRT)' line. There are a few problems when building SRC Modula-3, Version 1.5 on IBM/4.3. These problems are: dist-1.5/system/runtime/M3machine.h.IBMRT Because '_packed' is a reserved word on the High C compiler we needed to redefine it. dist-1.5/system/runtime/M3Runtime.c 'vfprintf' isn't in our library so I used '_doprnt' instead. dist-1.5/system/loader/m3ld.c I needed to write 'tempnam' for the IBMRT architecture. dist-1.5/util/clone.c Fixed a syntax error in a '#if defined(IBMRT)' clause. dist-1.5/util/merge.c 'vfprintf' isn't in our library so I used '_doprnt' instead. dist-1.5/makefile Defined IBMRT on the CC command line, so that clone will compile correctly. I'm providing corrections of these problems as a small number of files and a shell script. All of the files are in a uuencoded compressed tar file which is attached to this note. Here are the instructions for applying the corrections: (1) Save this message in a file, say changes.uu, in the directory that contains dist-1.5, that is, the directory in which you extracted m3-1.5.tar.Z from gatekeeper. (2) Execute the following commands: uudecode changes.uu zcat 1.5changes.IBMRT.tar.Z | tar xvf - At this point, you are ready to apply the changes. If a file is changed by the update procedure, the original file is saved with the additional suffix .SRC (3) Apply the changes by executing the command applypatches (4) If the build is done using the clone directory setup as specified in the SRC 1.5 build documentation, I have provided a shell script to remove a few uneeded files that the clone process created. Make sure you are in the top level build directory and then type 'rmuneeded'. (5) Once the build is done and working, the files that were untar'd, the 1.5changes.IBMRT.tar, and this file can be removed. Michael J. Bauers, BSI begin 666 1.5changes.IBMRT.tar.Z M'YV0+EX`&$BPH,&#"!,J7,BPH4.$("+>F`@"0$09,V;0J!BQ(PR.'4-&_`B" MQ@T8-&;05.F M#)ND4*-*G4JUJM6',5S4&(,FC)LS9>:X2"*DB10J+GS*<:'EJMN<'6W(!8E1 M(TB/=T6.C&@2I4J6-F9$C#$#!D:+,-XJ7ER0I]J@0XL>G;JTZ5/&F#-KWGPU M[!@Y:>#0B<&YM,.X*$"!!4T:`"PKF0;*;+QQA@H`$M= M2"6"!JL9LHI-MI`BE##'"X:70$8)8X@@I-$@!"TD6'3`D09X*0A)=4]7_Z1W M2"NLL+G56*L=D=MPAZ@UW6S8C?>N=,C!QI*!CVU&"B"L8.[G3<<^!AQYR(IZ MW$(*?KOI"Y9!1QVO"A]6ZGKW(2RQQDZ9K+T(12M:NM@G=6V9V9[);;?ANGD; M2RS):9BZW5/5KI[&31:O9>W77ZU)8S#==W=T8(="&W,X@Y!H)3=S'P`8Z\($0=(CVZ$"3"#+D>Q<)GYK&IQ4^,$K*G^:EPIG"!R3Y(M)3H+2;`@FJ?;4QU)E.8NF]M.?&KE,1:'J41U^ M)+,BT4Q5K'(5K$`@*P+>2@ZY$A*O?O2K8"%J6,5*H/6N1\,RFO&,=IJ@;]!( M$`RN1H/;.E-'!'8#$.*F!G4L(6%0F!@V+H2%>Y(?#.7EQT)>A3#Y&P$(C""A MD061"EI4'H8R9*#]B*$[+QC#&&1$A(0I8`@9TMH++NF&3&ZR!9U\9/609^RP[$69*4&+T"9RMKP`CG4`59I8-$+FC"#)L@' M0-YQ`1K&\DAN]L2;6@EGRG)6SG-"39WL="=7'B1/>F+*!5.0PA!JAH8VO$$_ M*[B#/>F`3W"*DY_F1"=`V_E.@L[3D_6949/N^4U]CK.?&BW#.CDZT'A^M)X\ M`,$$8T"=;8Z4HB6]J,-0^D^5LE,*_DQG&5RPR9M6U*08#>I&@9I2HB)4H0QU M*$0E:M2<[G.G&>WI2IG:4Z(J(*03/:I.R9E5H6Y5J4/=9$PG*(.:PB&L5CVI MW<+0JQ>T809L(`-1X9K/L;Y@KG6]:UZ=FM"%UI4^NQM()@K9_U$AUH,-K*"A>V=OT16/;J MW-T.ET58I&UAHXK;B.J6M]'-[F_U(]+@6A>ZV)UN9R=8@^::EV[TX<[L=`M? M!\VNMMR=*GW#$%_8%@NX),UG?>6K(.2"5C0W(&,VFR.'-IRS*=HA0R%Y29%? M:BLD'!1)1F1@S,`@\P8RX'`)-9(N:&)SFN^J9E*NN>`6)Z3!CCSH&\2@!J1B M%:TK%2@\A_K2@VX7Q@ESP8QK[->R+A6MA(4JD!\I9!K;&+-OH.MC!2M9_"Y9 KQDX&KVR+F^2%7ODL3:XQ>-.K725/+,A#MBM_[3O4[;KXS7".LYSG3.?N`2Y9 ` end ------------------------------------------------------------------------------ Date: Wed, 10 Oct 90 17:39:26 PDT From: David Goldberg Subject: shared libraries and Modula-3 A while back I experimented with converting the modula-3 libraries to be shared libraries (this is in SunOS). For small programs, the compiled binaries are more than 3 times smaller, and compile time is noticeably faster. I believe I have now packaged up the changes so that they are easy for anyone to install under SunOs, and hopefully with minor changes on other systems with shared libraries. If you would like this shared library package, reply to this message and I will send you a shar file with the changes. I only ask that you let me know if you were able to install it and whether it was useful. David Goldberg goldberg@parc.xerox.com ------------------------------------------------------------------------------ Date: Wed, 17 Oct 90 11:58:34 EDT From: Norman Ramsey Subject: M3v1.5, hooray! I got it installed, have run hello world. Here are some complaints: The installation procedure runs latex once, when it really should run it twice, or better yet not at all. Please change the `cloning' process to clone doc.{aux,dvi,log,ps} and so on. Also, you invoke dvips in such a way that I had to answer an interactive prompt. Perhaps this aspect of the world needs to be better documented, but why not just make my life easy and distribute the dvi and ps files? The documentation claims the linker can be invoked as m3ld and invites me to consult the man page. But the installation process doesn't put it in $BINDIR, and I can't find a man page anywhere: nr@cs (16) % pwd /usr/local/src/local.bin/m3-1.5/DS3100.obj nr@cs (17) % find . -name 'm3ld*' -print ./system/loader/m3ld.c ./system/loader/m3ld These are nits, guys. I'm looking forward to getting rolling on some real systems programs. Thanks for your pointers during installation hell and keep up the good work. Norman ------------------------------------------------------------------------------ Date: Wed, 17 Oct 90 20:34:27 EDT From: Norman Ramsey Subject: m3imc help? How do I tell m3imc to look in libm3core.a for the .io files for the builtin interfaces? Norman ------------------------------------------------------------------------------ Date: Wed, 17 Oct 90 18:48:36 PDT From: Eric Muller Subject: Re: m3imc help? > How do I tell m3imc to look in libm3core.a for the .io files for the builtin > interfaces? m3imc does not support libraries. However: - the compiler generates fingerprints for the "things" exported by an interface and generate symbols in the corresponding object; these symbols are referenced when appropriate by the implementation(s) of the interface and the importers of the interface. If you link inconsistent objects, this should be detected at link time; you will get undefined symbols of the form "VS__". I consider this mechanism better than m3imc, because it is faster and works at the level of the exported "things" rather that at the level of the full interface. - it is not a good idea to modify the standard libraries anyway. Eric Muller. ------------------------------------------------------------------------------ System Research Center - 130 Lytton Av. - Palo Alto, CA 94301 - (415) 853 2193 ------------------------------------------------------------------------------ Date: Wed, 17 Oct 90 12:29:19 EDT From: Norman Ramsey Subject: Scan interface in core library This interface is a little weak on documentation :-). Does anybody else think that these procedures should take an optional 'base' argument, just like the procedures in Convert? I gather UNTRACED REF is used with explicit DISPOSE because that's cheaper than using the garbage collector? Norman Ramsey nr@princeton.edu ------------------------------------------------------------------------------ Date: Fri, 19 Oct 90 13:02:28 EDT From: Norman Ramsey Subject: Living without variant records > I think you can express any C type in Modula-3, if you are willing to > go to the unsafe world. The only type we don't support is unions, but > LOOPHOLEs will get you that. Or do you have a C type you don't know > how to write in Modula-3 ? I would like to write a reasonable Modula-3 implementation of the following C type: typedef enum { CharVal, IntegerVal, WordVal, ShortVal, RealVal, LongrealVal, AddressVal, } ValueCode; typedef struct value { ValueCode type; union { char Char; short Short; int Integer; long Word; float Real; double Longreal; char *Address; } v; } Value; I've been able to come up with the following interface, but the proliferation of conversion procedures offends me. I'd like to hear from others who may have a better solution to this problem. INTERFACE MachineValue; IMPORT Error, Word; TYPE Type = {Char, Integer, Word, Short, Real, Longreal, Address}; Short = [-32768..32767]; Bits8 = (*BITS 8 FOR*) [0..255]; Bits16 = (* BITS 16 FOR *) Short; Bits32 = (* BITS 32 FOR *) INTEGER; Bits64 = RECORD b0, b1: Bits8; h1 : Bits16; w1 : Bits32; END; T = RECORD type: Type; v: Bits64; END; PROCEDURE ToChar(v:T):CHAR RAISES {Error.User}; PROCEDURE ToShort(v:T):Short RAISES {Error.User}; PROCEDURE ToInteger(v:T):INTEGER RAISES {Error.User}; PROCEDURE ToWord(v:T):Word.T RAISES {Error.User}; PROCEDURE ToReal(v:T):REAL RAISES {Error.User}; PROCEDURE ToLongreal(v:T):LONGREAL RAISES {Error.User}; PROCEDURE ToAddress(v:T):ADDRESS RAISES {Error.User}; PROCEDURE FromChar(x:CHAR):T RAISES {}; PROCEDURE FromShort(x:Short):T RAISES {}; PROCEDURE FromInteger(x:INTEGER):T RAISES {}; PROCEDURE FromWord(x:Word.T):T RAISES {}; PROCEDURE FromReal(x:REAL):T RAISES {}; PROCEDURE FromLongreal(x:LONGREAL):T RAISES {}; PROCEDURE FromAddress(x:ADDRESS):T RAISES {}; END MachineValue. Here's an excerpt from the implementation: UNSAFE MODULE MachineValue; IMPORT Error, Word; PROCEDURE ToChar(v:T):CHAR RAISES {Error.User} = BEGIN CASE v.type OF | Type.Char => RETURN LOOPHOLE(v.v.b0,CHAR); ELSE RAISE Error.User(Error.UserCode.Type); END; END ToChar; PROCEDURE ToShort(v:T):Short RAISES {Error.User} = BEGIN CASE v.type OF | Type.Short => RETURN LOOPHOLE(v.v.h1,Short); ELSE RAISE Error.User(Error.UserCode.Type); END; END ToShort; (* ... *) PROCEDURE FromChar(x:CHAR):T RAISES {} = VAR v: T; BEGIN v.type := Type.Char; v.v.b0 := LOOPHOLE(x,Bits8); RETURN v; END FromChar; (* ... *) BEGIN END MachineValue. ------------------------------------------------------------------------------ Date: 19 Oct 1990 1958-PDT (Friday) From: Subject: Question about BITS FOR construct Consider the type declaration TYPE AW = RECORD hi: BITS 12 FOR [0..4095]; lo: BITS 20 FOR [0..1024*1024-1] END; If I understand the report correctly, the "lo" field must be adjacent to the "hi" field. But what about the "hi" field itself? Is it required to be flush at the beginning of the record? Or is the implementation allowed to place it elsewhere? Also, can an implementation accept AW, but refuse this: TYPE BW = BITS 32 FOR AW; A related question: Is this declaration always legal: TYPE CW = BITS BITSIZE(DW) FOR DW; I suppose that the report, taken literally, says that all three questions are implementation-dependent. However, if taken literally, it also says that the implementation can simply outlaw all uses of BITS FOR --- which is probably not what the designers intended. So, my questions are more about the Spirit of the Law, than about its Letter. --jorge PS. I am aware that the current version of the SRC compiler does not always implement BITS FOR exactly as described in the report; but mine are language questions, not compiler questions. ------------------------------------------------------------------------------ Date: 20 Oct 1990 0012-PDT (Saturday) From: Subject: Re: Living without variant records Norman asks: I would like to write a reasonable Modula-3 implementation of the following C type: typedef enum { CharVal, IntegerVal, WordVal, ShortVal, RealVal, LongrealVal, AddressVal, } ValueCode; typedef struct value { ValueCode type; union { char Char; short Short; int Integer; long Word; float Real; double Longreal; char *Address; } v; } Value; He presents an interface MachineValue that provides somewhat different functionality than the C type Value. His M3 interface provides a degree of safety and syntactic sugar (constructors) not provided by the C version. If you're not concerned about the cost of allocation, why not use object classes? That would give you constructors and safety more concisely than your M3 version. If you are concerned about performance, here is a Modula-3 set of type definitions that provide the same degree of performance and safety as the C type definitions: TYPE ValueCode = {Char, Integer, Word, Short, Real, Longreal, Address}; Value = RECORD type: ValueCode; v: ARRAY [0..7] OF CHAR; END; ValueChar = RECORD type: ValueCode := ValueCode.Char; v: BITS 8 FOR CHAR; pad: BITS 56 FOR ARRAY [0..6] OF CHAR; END; ... ValueLongreal: RECORD type: ValueCode := ValueCode.Longreal; v: LONGREAL; END; To construct a M3 Value, the client writes: LOOPHOLE( ValueChar{ v := 'a' }, Value ) To construct a C Value, the client writes: Value value; value.type = CharVal; value.v = 'a'; (C doesn't allow for general initializers of unions.) To access a M3 Value, the client writes: LOOPHOLE( value, ValueChar ).v To access a C Value, the client writes: value.v.Char ------------------------------------------------------------------------------ Date: 20 Oct 1990 1544-PDT (Saturday) From: Subject: Re: Question about BITS FOR construct Jorge asks, Consider the type declaration TYPE AW = RECORD hi: BITS 12 FOR [0..4095]; lo: BITS 20 FOR [0..1024*1024-1] END; If I understand the report correctly, the "lo" field must be adjacent to the "hi" field. But what about the "hi" field itself? Is it required to be flush at the beginning of the record? Or is the implementation allowed to place it elsewhere? I suppose the report should have stated explicitly that the hi field is required to be flush at the beginning of the record. Also, can an implementation accept AW, but refuse this: TYPE BW = BITS 32 FOR AW; A related question: Is this declaration always legal: TYPE CW = BITS BITSIZE(DW) FOR DW; The report says that the legality of a packed type can depend on its context. So the interesting question is not whether BW and CW can be declared, but where they can be used in packed records. For example, I imagine that in most implementations, (1) BITSIZE(INTEGER) = 32 (3) Fields of type BITS 32 FOR INTEGER are allowed in records only if they are word-aligned. There is certainly not much point in an implementation rejecting the type declaration BITS BITSIZE(T) FOR T; on the other hand there is not much point in requiring them to accept it, since we will not require that they allow it to be used anywhere in a packed record. ------------------------------------------------------------------------------ Date: Sun, 21 Oct 90 23:05:01 EDT From: Norman Ramsey Subject: Does anyone know how to use m3imc with Make? (was m3imc help?) > > How do I tell m3imc to look in libm3core.a for the .io files for > > the builtin interfaces? > > m3imc does not support libraries. However: > > - [...] If you link > inconsistent objects, this should be detected at link time; you > will get undefined symbols of the form "VS__".[...] Granted, but I'm after something a bit different. I don't want just to detect inconsistent objects; I want something I can put in a Makefile to rederive inconsistent objects. I would settle for an `edsel'-style command that gives bad objects obsolete time stamps. When I tried to use m3imc for this purpose, it complained about not being able to find the library interfaces, hence my question. Let me now ask the correct question: Does anyone know how to user m3imc in a Makefile or mkfile to cause a correct, consistent object to be built when I type `make'? At the moment I am reduced to `rm *.?o; make'. I don't consider this a practical solution for the long haul. Norman ------------------------------------------------------------------------------ Date: 21 Oct 1990 2059-PDT (Sunday) From: Subject: Re: Does anyone know how to use m3imc with Make? (was m3imc help?) Norman, Mark Manasse and I built a shell script "m3edsel" that uses m3imc to get edsel-like behavior; that is, it removes all the obsolete .o's. It echos each file as it considers it, then echos a star if it determines that the file is obsolete. Finally, it removes all the obsolete files. Here is the shell script: b:vbtm3 cat m3edsel #! /bin/sh m3imc="/proj/ultrix/bin/m3imc -B.:/proj/ultrix/lib/m3" x="-f" for i do if [ -r $i ] then echo -n $i j=`echo $i | sed 's/o$/3/'` if $m3imc $j $i 2>/dev/null then echo else x="$x $i" echo '*' fi fi done [ $x != "-f" ] && echo rm $x rm $x exit 0 And here is the Makefile that we use with it, with long lists of files elided: CDEFS = VBT.io Split.io ... KeyboardKeySym.io CMODS = VBT.mo Split.mo ... Batch.mo DEFPATH = .:/proj/ultrix/lib/m3 M3 = /proj/packages/m3exe/1.5/DS3100.install/bin/m3 -D$(DEFPATH) EDSEL = m3edsel all: doEdselI / $(CDEFS) / doEdselM / $(CMODS) doEdselI: $(EDSEL) $(CDEFS) doEdselM: $(EDSEL) $(CMODS) .SUFFIXES: .i3 .m3 .io .mo .i3.io: $(M3) -c $< .m3.mo: $(M3) -c $< It has been some time since we have used this thing; but it worked for us at the time. Greg ------------------------------------------------------------------------------ Date: Tue, 23 Oct 90 11:36:13 EDT From: Norman Ramsey Subject: changing default methods Is there a way for me to declare a new default method of the supertype when declaring a subtype? That is, imagine TYPE A = OBJECT METHODS a() := NIL; END; AB = A OBJECT METHODS b(); END; PROCEDURE Aproc(x:AB) = ... And I somehow want to say that procedure Aproc should be the default a() method for newly allocated objects of type AB. Norman ------------------------------------------------------------------------------ Date: Wed, 24 Oct 90 09:42:03 -0100 From: Piet van Oostrum Subject: changing default methods >>>>> In article <9010231536.AA12123@cs.Princeton.EDU>, Norman Ramsey (NR) writes: NR> Is there a way for me to declare a new default method of the supertype when NR> declaring a subtype? That is, imagine NR> TYPE NR> A = OBJECT METHODS a() := NIL; END; NR> AB = A OBJECT METHODS b(); END; NR> PROCEDURE Aproc(x:AB) = ... NR> And I somehow want to say that procedure Aproc should be the default a() NR> method for newly allocated objects of type AB. Yes, the method override is used for this. TYPE A = OBJECT METHODS a() := NIL; END; AB = A OBJECT METHODS a := Aproc; b(); END; ^ no () In the new proposal the keyword OVERRIDE is used AB = A OBJECT METHODS b(); OVERRIDE a := Aproc; END; 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') ------------------------------------------------------------------------------ Date: Tue, 23 Oct 90 13:26:43 PDT From: chased@Eng.Sun.COM (David Chase) Subject: Re: Question about BITS FOR construct > A related question: Is this declaration always legal: > TYPE CW = BITS BITSIZE(DW) FOR DW; > I suppose that the report, taken literally, says that all three > questions are implementation-dependent. Beyond the obvious "it's a pain to compile it" motivations for making the answers to your questions implementation-dependent, consider the implementation of a garbage collector (especially a conservative one) in a world where the following declarations are legal: TYPE UAP = BITS BITSIZE(REFANY) FOR REFANY; TYPE BIT = BITS 1 FOR BOOLEAN; TYPE HARD_TO_SCAN = RECORD pad1 : BIT; ptr1 : UAP; (* at word boundary + 1 bit *) pad2 : BIT; ptr2 : UAP; (* at word boundary + 2 bits *) pad3 : BIT; ptr3 : UAP; (* at word boundary + 3 bits *) (* etc *) END; This requires something along the lines of (1) a conservative collector searching for pointers located at BIT boundaries. If nothing else, this makes the pointer-searching part of collection anywhere from 8 to 32 times as expensive, never mind the increased probability of discovering bogus pointers. or (2) stack and (traced) object descriptors which include detail down to the bit level. Object descriptors are just a SMOP in the current systems; stack frame descriptors (given the intermediate language) are not. This might be better treated by a collector along the lines of one recently described by Edelson for C++ (maintain an explicit list of root pointers), but I am not confident that his technique would be correct in a multi-threaded world. David Chase ------------------------------------------------------------------------------ Date: 24 Oct 1990 0835-PDT (Wednesday) From: Subject: Lost mail Several people reported that they received empty messages last week, 10/15 - 10/22. Thank you. We cannot tell when external mail is broken unless someone tells us. The local mail gurus say that a file system filled, but all is well now. Below are the messages sent to the mailing list last week. - Bill Kalsow [The messages are above in the file, I removed them from this message - EM] ------------------------------------------------------------------------------ Date: Mon, 29 Oct 90 16:28:05 MET From: Thomas Roemke Subject: another bug ? Probably I've detected another bug in your SRC M3 compiler. While the report says "Except for the redeclaration of exported procedures, the names declared at the top level of block, the visible imported names, and the names declared in the exported interfaces must be distinct." your compiler accepts the following: INTERFACE A; MODULE A INTERFACE B; VAR I: INTEGER EXPORTS B; VAR I: INTEGER; END A. BEGIN END B. I := 0; END A. Since A is implicitly added to module A's export list, I is exported twice, isn't it ? Thomas -- (* Thomas Roemke, University of Paderborn, Germany modula-3@uni-paderborn.de ..!uunet!mcsun!unido!pbinfo!modula-3 *) ------------------------------------------------------------------------------ Date: 29 Oct 1990 1414-PST (Monday) From: Subject: Re: another bug ? > INTERFACE A; MODULE A INTERFACE B; > VAR I: INTEGER EXPORTS B; VAR I: INTEGER; > END A. BEGIN END B. > I := 0; > END A. > > Since A is implicitly added to module A's export list, > I is exported twice, isn't it ? No, since module A has an explicit EXPORTS clause, interface A is not added to its export list. Page 34 of the report says "EXPORTS Interfaces" can be omitted, in which case Interfaces defaults to id. It does not say id is always added to Interfaces. - Bill Kalsow ------------------------------------------------------------------------------