Date: Thu, 2 May 1991 16:33:32 -0500 (CDT) From: Dick Orgass Subject: AIX PS/2 Libraries and Long Names The ar command for AIX PS/2 is restricted to file names whose length is less than or equal to 14 characters. Name truncation occurs while a file is added and a new file whose name matches an old file in the first 14 characters replaces the old file even if the name is different beyond the first 14 characters. I never saw the problem when working with the SRC distribution; this may reflect the fact that there are no files whose names are too long. A small C program, fixobjs.c, is attached. Using this program, it's possible to build Modula-3 libraries when there are files whose names fail to satisfy the 14 character name restriction. An example of a make file fragment to use this program to create a library follows. In this example, the make macro INTOBJS contains a list of the .io files that are to be placed into the library and MODOBJS contains a list of .mo files to be placed in the library. Finally, EXTOBJS contains a list of plain .o files to be placed in the library. The value of AR is the program ar, typically /bin/ar and the value of ARFLAGS is the options to be passed to ar. liboli.a: $(INTOBJS) $(MODOBJS) $(EXTOBJS) -rm -f liboli.a liboli.ma fixints fixmods ls *.io | fixobjs -i > fixints chmod +x fixints fixints $(AR) $(ARFLAGS) liboli.a `ls I*.o` ls *.mo | fixobjs -m > fixmods chmod +x fixmods fixmods $(AR) $(ARFLAGS) liboli.a `ls M*.o` $(AR) $(ARFLAGS) liboli.a $(EXTOBJS) -rm -f fixobjs fixmods I*.o M*.o liboli.ma: liboli.a $(M3AR) liboli.a Of course, liboli.ma appears in the list of dependencies of all. Dick ------------------- fixobjs.c ----------------------- /* File fixobjs.c created by Dick Orgass at 12:32:20 on Wed May 1 1991. */ /* Copyright (C) by IBM Corporation, 1991. */ #include #include extern char *strchr(char*, char); #define private static private char ibmid[] = "Copyright(c) by IBM Corporation, 1991."; private char rcsHeader[] = "$Header$"; private char rcsRevision[] = "$Revision$"; private char rcsDate[] = "$Date$"; private void error() { printf("%s: Must specify exactly one of -i or -m.\n"); exit(1); } void main (int argc, char **argv) { int fileNumber = 0; char leadingChar; char buff[MAXNAMLEN] = {'\0'}; char *tmp; if ((argc == 1) || (argc > 2)) error(); if (argv[1][0] != '-') error(); switch (argv[1][1]) { case 'i': leadingChar = 'I'; break; case 'm': leadingChar = 'M'; break; default: error(); } printf("#! /bin/csh\n"); while (TRUE) { if (fgets(buff, sizeof(buff), stdin) == NULL) break; tmp = strchr(buff, '\n'); *tmp = '\0'; printf("ln -s %s %c%.5d.o\n", buff, leadingChar, fileNumber); fileNumber++; } } /* by Brief description of the change and why it was made. $Log$ */ ----------------------- End --------------------------- ------------------------------------------------------------------------------ Date: Tue, 7 May 91 09:03:42 PDT From: Subject: Re: OBJECTs and their default methods > suppose we have the following declarations: > > TYPE O1 = OBJECT METHODS m () : INTEGER := zehn END; > TYPE O2 = O1 OBJECT m : INTEGER := 2 END; > > PROCEDURE zehn (self : O1): INTEGER = > BEGIN RETURN 10; END zehn; Then, "O2.m" is illegal. Page 13 of the report says A field or method in a subtype masks any field or method with the same name in a supertype. So, if anything O2.m would name the INTEGER field, but the report does not attach a meaning to "ObjectType.Field". The lack of an error message when you try to use "O2.m" is a compiler bug. - Bill Kalsow ------------------------------------------------------------------------------ Date: Sat, 11 May 91 21:35:15 PDT From: mjordan@src.dec.com (Mick Jordan) Subject: Modula-3 toolkit The Modula-3 toolkit, a development of the otherwise defunct Olivetti Modula-3 implemention, is now available via ftp from gatekeeper.dec.com. The code-generation and run-time aspects of the Olivetti implementation have been removed and the toolkit has been altered to be compatible with the conventions assumed by the SRC compiler. The system is made available under the same licence terms as the SRC compiler. In addition the original Olivetti sources are covered by a separate, non-restrictive, copyright notice. The toolkit is designed to support the creation of Modula-3 program development tools and is structured around a compiler front-end which uses a public Abstract Syntax Tree (AST) to represent program source. A description of the system can be found in: "An Extensible Programming Environment for Modula-3", Mick Jordan, Proceedings of the Fourth ACM SIGSOFT Symposium on Software Development Environments, Software Engineering Notes, 15, 6, Dec 1990. A number of tools are provided with the toolkit, vis: * A compiler front-end (syntax/semantic analysis), with optional checks for unused variables, uncaught exceptions, etc. The compiler can compile multiple sources in one invocation and compiles each interface once only. * A tool to generate skeleton modules from interfaces. * A tool to build parameterised interfaces and modules from a generic specification. (Useful to experiment with generics in the interim). * A Makefile generator for Modula-3 libraries and applications. * A tool that is a step towards an integrated, incremental program development environment for Modula-3. It includes the compiler front end, a tool to scan the file system for source file changes and recompile changed (and dependent) units, a pre-linker to analyse a program for completeness, a primitive browser and the Makefile generator. The toolkit is designed to be extensible, by virtue of the AST and a collection of reusable compiler components. I expect to add more tools over time, and hope that others will be motivated to do so. The toolkit is stored in the directory /pub/DEC/Modula-3/m3tk in the file dist-1.0.tar.Z. Follow the same general instructions as per SRC Modula-3 to extract the distribution into a clean directory called, say, 'm3tk', and then read the file m3tk/dist-1.0/m3tk-install.notes. This file is also stored in /pub/DEC/Modula-3/m3tk/README. To make effective use of the tools you need a machine with at least 12Mb of main memory, preferably more. I run it on DECstation 3100/5100s and it has been tested on IBM kit (thanks to Dick Orgass) and on a Sparcstation (thanks for David Goldberg). I am reasonably confident that it will run on other systems without problems. Mick Jordan ------------------------------------------------------------------------------ Date: 13 May 91 18:03:48 GMT From: sloboda@i41s6.ira.uka.de (Tilo Sloboda) Subject: Modula 3 Is Modula 3 available for either Macintosh or Atari ST Computers ? Especially the latter would be interesting for many students. thanks, bye Tilo. ------------------------------------------------------------------------------ Date: 14 May 91 17:20:53 GMT From: jgm@student.ecok.edu (John McGrew) Subject: HELP - Want modula-3 v 1.6 HELP We have been unable to obtain v. 1.6 of Modula-3. We do not have anonymous ftp capability and have not been able to access decwrl. If someone would be willing to make a tape for us we would provide the tape and postage both ways. We have an Altos 5000 which uses a QIC-24 tape. Thanks +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ John G. McGrew Assistant Professor Department of Computer Science East Central University Ada, OK 74820 email: jm@cs.ecok.edu =============================================================================== ------------------------------------------------------------------------------ Date: 14 May 91 11:58:13 GMT From: smgf@cl.cam.ac.uk (Steve Freeman) Subject: Modula-3 and Isis, memory smashes For reasons best left unspoken, I have been trying to use Isis from Modula-3. Unfortunately, after O(a couple of hundred) messages I get a memory smash during Modula-3 (v 1.6) garbage collection. This only seems to happen when I accept Isis messages - I can, for example, send messages to another process written in C without difficulty. I know that this is not a lot to go on, but has anyone got any ideas about places to look? Otherwise, I guess it's back to C :-\. Thanks, -- Steve - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Steve Freeman, Computer Lab, University of Cambridge, UK Steve.Freeman@computer-lab.cambridge.ac.uk "The science of medicine is founded on conjecture and improved by murder" Sir Astley Cooper. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Steve Freeman, Computer Lab, University of Cambridge, UK Steve.Freeman@computer-lab.cambridge.ac.uk ------------------------------------------------------------------------------ Date: 15 May 91 13:38:32 GMT From: ken@CS.Cornell.EDU (Ken Birman) Subject: Re: Modula-3 and Isis, memory smashes In article <1991May14.115813.1349@cl.cam.ac.uk> smgf@cl.cam.ac.uk (Steve Freema n) writes: >For reasons best left unspoken, I have been trying to use Isis from >Modula-3. Unfortunately, after O(a couple of hundred) messages I get a >memory smash during Modula-3 (v 1.6) garbage collection. This only seems to >happen when I accept Isis messages - I can, for example, send messages to >another process written in C without difficulty. I know that this is not a >lot to go on, but has anyone got any ideas about places to look? Otherwise, >I guess it's back to C :-\. > This sounds really interesting! I think Modula 3 is a great language and we would be happy to help you get this working if you will post a patch list to comp.sys.isis later so that other can benefit. Offline, how about sending me a short description of how you got the interfaces to work and how the Modula-3 dynamic memory allocator actually works. Perhaps ISIS needs to negotiate with Modula 3 for the memory it allocates, or perhaps some sort of argument passing problem is causing us to misinterpret certain of the arguments passed from Modula 3 into ISIS. A third and forth problem to consider would be that our tasking scheme is a problem (in Modula, we should probably map the ISIS task primitives to the Modula task primitives) or that "varargs" isn't working. Anyhow, I am sure I can figure this out. You seem to have gotten pretty far. -- Kenneth P. Birman E-mail: ken@cs.cornell.edu 4105 Upson Hall, Dept. of Computer Science TEL: 607 255-9199 (office) Cornell University Ithaca, NY 14853 (USA) FAX: 607 255-4428 ------------------------------------------------------------------------------ Date: 16 May 91 12:02:18 GMT From: bert@let.rug.nl (Bert Bos) Subject: Bug in Oberon-M (MS-DOS)? While trying to write a Quicksort routine in Oberon-M, I found the following weird behaviour. Program 1 is incorrect, while program 2 is accepted by the compiler: (* 1 *) MODULE test; (* this program doesn't compile *) TYPE Object = POINTER TO ObjectRec; ObjectRec = RECORD END; PROCEDURE p(VAR x: ARRAY OF Object); VAR h: Object; ^^^^^^^^^ BEGIN h:= x[0] END p; BEGIN END test. (* 2 *) MODULE test2; (* this program does compile *) TYPE Object = POINTER TO ObjectRec; ObjectRec = RECORD END; PROCEDURE p(VAR x: ARRAY OF Object); VAR h: ObjectRec; ^^^^^^^^^^^^ BEGIN h:= x[0] END p; BEGIN END test2. Is this a bug, or is Oberon supposed to treat arrays of pointers as arrays of records? If it isn't a bug, how else do you create an array of elements of unspecified (i.e. extended) type? -- "The Door is the Way. Bert Bos (bert@let.rug.nl) Capital letters are always the best way of Alfa-informatica dealing with things you don't have a good RijksUniversiteit Groningen answer to. (Douglas Adams: Dirk Gently's...)" Groningen, The Netherlands ------------------------------------------------------------------------------ Date: Sat, 18 May 91 02:46:05 PDT From: Subject: Local exceptions I notice that Modula-3 allows exception declarations only at the top level of modules and interfaces. What was the point of this restriction? (Local exceptions seem a pretty natural concept.) --j Jorge Stolfi DEC Systems Research Center stolfi@src.dec.com, ...!decwrl!stolfi ------------------------------------------------------------------------------ Date: Sat, 18 May 91 14:22:42 PDT From: Subject: Re: Local exceptions Jorge Stolfi asks, I notice that Modula-3 allows exception declarations only at the top level of modules and interfaces. What was the point of this restriction? (Local exceptions seem a pretty natural concept.) You can make sense of local exceptions, but the benefits are not worth the cost of the effort. I suppose that with local exceptions, you want the following block to be a checked runtime error: EXCEPTION E; BEGIN TRY EXCEPTION E; BEGIN RAISE E END EXCEPT E: (*Skip*) END END That is, you want the different exception declarations to produce different exceptions. Now consider: PROCEDURE P(b: BOOLEAN) = EXCEPTION E; BEGIN TRY IF b THEN P(NOT b) ELSE RAISE E END EXCEPT E: (* Skip *) END END P; Do you want P(FALSE) to be an unhandled exception? That is, do the declarations of EXCEPTION E at the two levels of recursion introduce different exceptions, or the same exception? If they introduce the same exception, then the procedure call behaves differently than its body would; semanticists will not like this. If they introduce different exceptions, programmers might well be surprised. The Modula-3 committee could not find any real use for local exceptions, and therefore decided that the wisest choice was "none of the above". ------------------------------------------------------------------------------ Date: 19 May 91 04:10:52 GMT From: brendan@cs.widener.edu (Brendan Kehoe) Subject: building modula3 on a sun4 Hi folks...is there a FAQ for this group stored anywhere? I figured I'd try for that before asking hopelessly redundant questions about why my attempt at building Modula-3 died. :-) Thanks. Brendan -- Brendan Kehoe - Widener Sun Network Manager - brendan@cs.widener.edu Widener University in Chester, PA A Bloody Sun-Dec War Zone ------------------------------------------------------------------------------ Date: Sat, 18 May 91 21:48:53 PDT From: muller@src.dec.com (Eric Muller) Subject: Re: building modula3 on a sun4 In article , brendan@cs.widener.edu (Brendan Kehoe) wri tes: > > Hi folks...is there a FAQ for this group stored anywhere? No. But you can ftp the archive of comp.lang.modula3 from gatekeeper.dec.com:pub/DEC/Modula-3. > I figured > I'd try for that before asking hopelessly redundant questions about > why my attempt at building Modula-3 died. :-) I guess it will be simpler to ask your questions. You can address them to us directly (m3-request@src.dec.com), we will summarize to comp.lang.modula3. -- Eric. ------------------------------------------------------------------------------ Date: 19 May 91 17:51:10 GMT From: brendan@cs.widener.edu (Brendan Kehoe) Subject: Re: building modula3 on a sun4 muller@src.dec.com wrote: >I guess it will be simpler to ask your questions. You can address them >to us directly (m3-request@src.dec.com), we will summarize to >comp.lang.modula3. Turns out it's unnecessary -- in looking on gatekeeper for the archives, what should I come across but v1.6! (I was trying to build 1.5.) I snagged 1.6, built it [ate lunch, had kids .. ha ha], and it's working like a charm now! Definitely an improvement over 1.5. Thanks a lot. Brendan -- Brendan Kehoe - Widener Sun Network Manager - brendan@cs.widener.edu Widener University in Chester, PA A Bloody Sun-Dec War Zone ------------------------------------------------------------------------------ Date: Mon, 20 May 91 14:50:07 PDT From: Subject: Re: Local exceptions Greg, thanks for your reply. However, I must say I didn't understand your example: PROCEDURE P(b: BOOLEAN) = EXCEPTION E; BEGIN TRY IF b THEN P(NOT b) ELSE RAISE E END EXCEPT E: (* Skip *) END END P; I don't see what is the problem here, since the exception E is always caught in the same frame where it is raised. If we substitute the body of P for the call, we get something like PROCEDURE P(b: BOOLEAN) = EXCEPTION E; BEGIN TRY IF b THEN WITH b = NOT b DO EXCEPTION E; BEGIN TRY IF b THEN P(NOT b) ELSE RAISE E END EXCEPT E: (* Skip *) END END P; END ELSE RAISE E END EXCEPT E: (* Skip *) END END P; which doesn't seem to pose any problems of interpretation. Perhaps you meant to write PROCEDURE P(b: BOOLEAN) = EXCEPTION E; BEGIN IF b THEN TRY P(NOT b) EXCEPT E: (* Skip *) END ELSE RAISE E END END P; However, in this case the natural interpretation is that the RAISE E is an error, since (according to the Twelve Changes) P has an empty RAISES clause, and hence a call to P cannot raise E. Am I confused? I am also quite surprised by your assertion that local exceptions have no real use. Sure, they are not strictly necessary; but the same can be said of local variables, types, constants, and procedures, which you agree are Very Good Things. A typical use of local exceptions would be PROCEDURE Foo(..) = EXCEPTION NotFound; PROCEDURE Lookup(...) RAISES {NotFound} = BEGIN ... END Lookup; BEGIN ... TRY Lookup(...) EXCEPT NotFound => ... END; ... END Foo; --jorge PS. By the way, the argument that "a procedure call should have the same effect as its body" is not very convincing. Consider for example PROCEDURE F(n: INTEGER): REFANY = TYPE T = BRANDED REF INTEGER; BEGIN IF n = 0 THEN WITH t = NEW(T) DO t^ := 0; RETURN t END ELSE RETURN F(n-1) END END F; From this code, I would expect F(0) and F(1) to have the same typecode (and the SRC compiler seems to agree.) However, if we substitute the body of F for the call F(n-1), we will get two declarations of type T, and the brands of F(0) and F(1) will be different. ------------------------------------------------------------------------------ Date: Mon, 20 May 91 15:43:40 PDT From: Subject: Re: Local exceptions Jorge points out that I flubbed my example. The question is, what do you want to be the result of P(TRUE) after: PROCEDURE P(b: BOOLEAN) RAISES ANY = EXCEPTION E; BEGIN IF b THEN TRY P(NOT b) EXCEPT E: (* Skip *) END ELSE RAISE E END END P; ------------------------------------------------------------------------------ Date: Tue, 21 May 91 09:41:56 PDT From: Subject: Re: Local exceptions [Greg Nelson:] The question is, what do you want to be the result of P(TRUE) after: PROCEDURE P(b: BOOLEAN) RAISES ANY = EXCEPTION E; BEGIN IF b THEN TRY P(NOT b) EXCEPT E: (* Skip *) END ELSE RAISE E END END P; I suppose the most useful interpretation is that each *static* occurrence of "EXCEPTION Id" defines a new exception, irrespective of how many times it is "executed". Then all occurrences of E in the above example refer to the same exception. Admittedly this is not consistent with the principle of structural type equivalence, but is at least consistent with the semantics of BRANDED T. By the way, here is another situation where the Report seems a bit ambiguous about static versus dynamic scopes: MODULE M2 EXPORT Main; PROCEDURE MemeChose(n: INTEGER; p: PROCEDURE():INTEGER): BOOLEAN = PROCEDURE G(): INTEGER = BEGIN RETURN n END G; BEGIN IF n = 0 THEN RETURN p = G ELSE RETURN MemeChose(n-1, G) END END F; PROCEDURE Irrelevant(): INTEGER = BEGIN RETURN 0 END P0; BEGIN <* ASSERT NOT MemeChose(1, Irrelevant) *> END M2. Should the ASSERT fail or succeed? The question is whether all instances of G are the same procedural value, i.e. whether the "environment" component of a procedure value is a static scope or a dynamic scope. To further confound the issue, the Report calls G a procedure *constant*... (The SRC compiler does the right thing, by the way.) --jorge ------------------------------------------------------------------------------ Date: 21 May 91 18:10:08 GMT From: chased@rbbb.Eng.Sun.COM (David Chase) Subject: Re: procedure value ambiguity In article <9105211642.AA01692@jumbo.pa.dec.com> stolfi (Jorge Stolfi) writes: >By the way, here is another situation where the Report seems >a bit ambiguous about static versus dynamic scopes: > > MODULE M2 EXPORT Main; > > PROCEDURE MemeChose(n: INTEGER; p: PROCEDURE():INTEGER): BOOLEAN = > > PROCEDURE G(): INTEGER = > BEGIN RETURN n END G; > ... >The question is whether all instances of G are the same procedural >value, i.e. whether the "environment" component of a procedure value >is a static scope or a dynamic scope. To further confound the issue, >the Report calls G a procedure *constant*... No ambiguity at all; I recall seeing the words specifying that each instance of G was distinct, and being very unhappy about the fact that this would require creation of a distinct value even in those cases where it was not necessary. "Procedures are equal if they agree as closures; that is, if they refer to the same procedure body and environment." (See "EXPRESSIONS.Relations, paragraph 2.) I think it's a stupid rule, but it's clearly stated. (Why do I think it is stupid? Because use of local procedures that inherit no bindings from their lexical ancestor is made more expensive, so that an extremely rare equality test is made well-defined.) G is certainly a constant, too -- it's just a different constant in different environments (same name, different value). Note that they did not call it a "literal". David Chase Sun ------------------------------------------------------------------------------ Date: Tue, 21 May 91 13:08:12 PDT From: Subject: Re: procedure value ambiguity > [David Chase, quoting:] "Procedures are equal if they agree as > closures; that is, if they refer to the same procedure body and > environment." (See "EXPRESSIONS.Relations, paragraph 2.) Yes, I am aware of this passage. But the "environment" of a procedure value is defined as "the scope with respect to which the variable names in the body will be interpreted" (page 9). The question is whether "scope" here means "static scope" or "dynamic scope". Reasoning backwards, one could argue that since G is supposed to be a "constant", its environment must be the static scope. In fact, I don't think the report says what the value of F(FALSE, NoOp) should be, given the following declarations: PROCEDURE F(arg: BOOLEAN; p: PROCEDURE(x: INTEGER)): INTEGER = VAR local: INTEGER; PROCEDURE G(x: INTEGER) = BEGIN local := x END G; BEGIN IF arg THEN local := 777; p(999); RETURN local ELSE RETURN F(NOT arg, G) END END F; PROCEDURE NoOp(x: INTEGER) = BEGIN END NoOp; I don't think it says anywhere in the report that the call to p(999) must modify the previous instance of "local", as opposed to the current one. I think the latter would be consistent with interpreting "environment" as "static scope", and it could be the semantics of a naive implementation of local procedures (e.g. using "display" registers a la Algol 60). Please note that I am only being a devil's advocate here. Surely, the dynamic interpretation is more natural and useful than the static one. (Perhaps it would have been even more correct to define the environment as the set of all variables *actually referenced* by the body. However, I suspect that this definition would be somewhat harder to implement than the present one.) > G is certainly a constant, too -- it's just a different constant > in different environments (same name, different value). As the motto goes, "variables won't; constants aren't"... 8-) I guess the problem is that some declarations (e.g. branded TYPE) must interpreted statically, whereas others (VAR) must interpreted dynamically. CONST declarations can be interpreted either way, but since the language forces their values to be truly constant, most compilers will probably opt for the static interpretation. So, it is not immediately obvious whether local procedure declarations are static or dynamic. Jorge Stolfi DEC Systems Research Center ------------------------------------------------------------------------------ Date: Fri, 24 May 91 15:50:24 GMT From: hassan@prl.dec.com (Hassan Ait-Kaci) Subject: 2nd Conf. on Software Engineering and A.I. Dear Netters, I am forwarding the following announcement from the Logic distribution list, with headers kept but mildly edited for spelling and presentation format. I encourage all to submit -- for one thing, Tunis (and Tunisia) is a beautiful place. Please do not contact me for further information as this is all I know. I am not involved in the organization, nor was I asked to assist in any way, nor do I know the organizers, but I took on myself to advertize and disseminate it as widely as possible. This is just meant as a modest token of encouragement from me to the organizers, as I know how hard it is to people in that part of the world doing research to keep abreast with what is going on in the rest of the world. (I myself am originally from Algeria). Apologies to those who are seeing this for the umpteenth time. Kind regards, -hak ------- Forwarded Message Return-Path: Received: from enet-gw.pa.dec.com by perle.prl.dec.com with SMTP (5.61++prl/27- May-90); id AA02688; Thu, 23 May 91 19:37:23 +0200 (MET) Received-Date: Thu, 23 May 91 19:37:23 +0200 Received: by enet-gw.pa.dec.com; id AA03847; Thu, 23 May 91 10:37:56 -0700 Received: from stork (STORK.LCS.MIT.EDU) by theory (4.1/TOC-1.2S) id AA20454; Thu, 23 May 91 13:08:19 EDT Received: by stork (4.1/TOC-1.2C) id AA27198; Thu, 23 May 91 13:06:53 EDT Date: Thu, 23 May 91 13:06:53 EDT Message-Id: <9105231706.AA27198@stork> To: logic@theory.lcs.mit.edu From: Gianna Reggio Sender: meyer@theory.lcs.mit.edu Subject: [REGGIO%IGECUNIV.BITNET@mitvma.mit.edu: contribution for the list] Date: Thu, 23 May 91 17:54 ITA CALL FOR PAPERS SECOND MAGHREB CONFERENCE ON SOFTWARE ENGINEERING AND ARTIFICIAL INTELLIGENCE TUNIS 13-16 April 1992 ORGANIZERS: University of Tunis - Tunisia Tunisian Information Processing Society - Tunisia University of Constantine - Algeria SPONSORS (solicited): IEEE Computer Society - Washington IFIP International Federation for Information Processing - Geneva AICA Associazione Italiana per il Calcolo Automatico - Milano AFCET Association Francaise pour la Cybernetique Economique et Technique - Paris This is the second of a series of Maghreb-wide conferences started in September 1989 in Constantine (Algeria). Also, this conference is part of a two-pillar program of technology transfer that TIPS (Tunisian Information Processing Society) is planning to implement on a Maghreb-wide scale: the first pillar is a series of biennial conferences whose purpose is to present state-of-the-art research conducted worldwide on Software Engineering and Artificial Intelligence. The second pillar is a series of biennial schools, held alternatively with the conferences, which consist of a set of short courses on Software Engineering and Artificial Intelligence, and which serves as a forum of exchange between the academic and the industrial milieu in the maghreb. From one conference to the next, the theme of the conference is selected on the basis of the interest of the moment, and the pertinence of these interests to our region. TOPICS The topics for this conference are the following: - Software specification and verification - Object oriented languages and systems - Distributed systems - Software project management - Software engineering education. GENERAL CHAIR Noureddine Boudriga Faculte des Sciences de Tunis Departement d'Informatique 1002 Tunis Belvedere - Tunisie PROGRAM CHAIRS Ali Mili Mohamed Bettaz Faculte des Sciences de Tunis Institut d'Informatique Departement d'Informatique Universite de Constantine 1002 Tunis Belvedere - Tunisie 2500 Constantine - Algerie PROGRAM COMMITTEE E. Astesiano - Genova B. Belkhouche - New Orleans A. Ben Cherifa - Tunis C. Ben Yelles - Alger M. Bidoit - Paris N. Boudriga - Tunis M. Broy - Munich N. Cercone - Vancouver C. Choppy - Paris J. Desharnais - Quebec R. Dssouli - Sherbrooke J. Eder - Vienna A. El Magarmid - West Lafayette A. El Iraki - Rabat J. Feki - Sfax J.P. Finance - Nancy A. Ferchichi - Tunis P. Freeman - Atlanta M. Gafsi - Tunis M. Ghellab - Toulouse F. Gherfal - Tripoli A. Jaoua - Quebec M. Jazayeri - Palo Alto R. Lazrak- Rabat Ch. Marlin - Adelaide M. Maourane - Nouakchott F. Mhidi - Detroit R. Mittermeier - Klgenfurt B. Raggad - Tunis G. Rose - Brisbane Z. Sahnoun - Constantine M. Shaw - Pittisburg Y. Slimani - Tunis J. Urban - Tucson K. Zeroual - Sherbrooke INSTRUCTIONS TO AUTHORS Authors are invited to submit 3 copies of original contributions in Arabic, French, or English, to the general chair. Submissions must be printed on one side of the page only and should not exceed 20 double spaced pages. ORGANIZATION COMMITTEE Promotion: A. Ferchichi - Tunis B. El Ayeb - Sherbroke Tutorials: S. Guemara El Fatmi - Tunis Local Arrangements: M. Chemmam - Tunis Registration: A. Ben Cherifa - Tunis Proceedings: Y. Slimani - Tunis INFORMATION Faculte des Sciences de Tunis Departement d'Informatique 1002 Tunis Belvedere - Tunisie Tel (216.1) 662 886 Fax (216.1) 500 666 Telex 13162 TN ------- End of Forwarded Message ------------------------------------------------------------------------------ Date: Sat, 25 May 91 09:32:33 PDT From: harbison@bert.pinecreek.com Subject: System Prog in Modula-3 appears I just received 50 copies of Systems Programming with Modula-3, edited by Greg Nelson. It looks great. Congrats to Greg and the other contributors. It's in the Prentice Hall Series in Innovative Technology. Price is $25.00, softcover, approx. 275 pages. ISBN 0-13-590464-1. Startbugging your bookstores. CONTENTS Acknowledgements 1. Introduction 2. Language Definition 3. Standard Interfaces 4. An Introduction to Programming with Threads 5. Thread Synchronization: A Formal Specification 6. I/O Streams: Abstract Types, Real Programs 7. Trestle Window System Tutorial 8. How the language got its spots Contact me if you have trouble getting a copy. Sam Harbison Pine Creek Software; 305 S. Craig St., Suite 300; Pittsburgh, PA 15213 +1 412 681 9811; harbison@bert.pinecreek.com ------- End of Blind-Carbon-Copy ------------------------------------------------------------------------------ Date: 26 May 91 02:37:15 GMT From: ken@CS.Cornell.EDU (Ken Birman) Subject: Re: Modula-3 and Isis, memory smashes In article <1991May14.115813.1349@cl.cam.ac.uk> smgf@cl.cam.ac.uk (Steve Freema n) writes: > ... memory smash after O(hundreds of messages) ... I talked to some people at DEC SRC and the problem is likely to be in the way that M3 garbage collects. To make a long story short, you need to get ISIS to use the M3 tasking primitives. Although ISIS may seem to work when its own threads are combined with the M3 scheme, M3 won't know that ISIS has pointers to your dynamically allocated M3 objects on its stacks and hence may not relocate things correctly. On the other hand, you should NOT change ISIS to use the M3 allocator instead of malloc. The SRC M3 people can help you do the mapping (in cl_task.h, .c) if you have problems. See the CTHREADS example... -- Kenneth P. Birman E-mail: ken@cs.cornell.edu 4105 Upson Hall, Dept. of Computer Science TEL: 607 255-9199 (office) Cornell University Ithaca, NY 14853 (USA) FAX: 607 255-4428 ------------------------------------------------------------------------------ Date: Mon, 27 May 91 07:40:26 PDT From: harbison@bert.pinecreek.com Subject: Modula-3 tutorial at OOPSLA '91 OOPSLA '91 will feature a half-day tutorial on Modula-3. This will be an excellent opportunity to learn about the language. Please spread the word. The speaker should be entertaining. (At least, I'll try to be...) OOPSLA '91 is in Phoenix, October 6-11. Sam Harbison Pine Creek Software; 305 S. Craig St., Suite 300; Pittsburgh, PA 15213 +1 412 681 9811; harbison@bert.pinecreek.com ------------------------------------------------------------------------------ Date: 29 May 91 01:29:06 GMT From: wilson@cs.utexas.edu (Paul Wilson) Subject: CFP: GC '91 (2nd OOPSLA Workshop on Garbage Collection) Call for Participation GC '91: The Second Workshop on Garbage Collection in Object-oriented Systems Phoenix, Arizona, October 6, 1991 (in conjunction with OOPSLA '91) Organizers: Paul R. Wilson, University of Texas at Austin Barry Hayes, Stanford University and Xerox PARC This workshop will focus on garbage collection, its implementation, and its implications for language and hardware design. It is intended for researchers and software developers with actual experience in garbage collection. Possible topics include, but are not limited to: * Garbage collection vs. explicit storage management * Language- and/or paradigm-dependence * Algorithms, such as reference counting, mark-sweep, copying, and hybrids. * Efficiency and locality * Performance tuning, profiling, adaptiveness, and opportunism * Benchmarking and issues of scale * Language features such as separately-managed areas, weak pointers, and finali zation * Architectural support for objects and garbage collection * Compiler support for garbage collection and optimizations * Garbage collecting parallel, distributed, and persistent systems * Portability, toolkits, and multilanguage systems Roughly thirty participants will be selected on the basis of short (2-5 page) position papers. (Only one person may attend on the basis of a single paper.) Some of the papers will be chosen for presentation at the workshop. Panel discussions will cover a few important issues; suggestions for panel topics and participants are invited. The deadline for receipt of position papers is August 1, 1991. Authors will be notified of acceptance or rejection by September 1, 1991. Send hardcopy to Paul Wilson at the address below. (If convenient, please also send an email copies directly to bhayes@cs.stanford.edu and wilson@cs.utexas.edu.) Paul R. Wilson (GC '91 Organizer) Electrical Engineering and Computer Science Dept. University of Illinois at Chicago Box 4348 (m/c 154) Chicago, IL 60607 email: wilson@cs.utexas.edu phone: (312) 226-3179 fax: (312) 413-0024 ------------------------------------------------------------------------------ Date: 29 May 91 15:18:00 GMT From: stt@inmet.inmet.com Subject: Re: Local exceptions Re: non-top-level exceptions > /* Written 12:41 pm May 21, 1991 by stolfi@src.dec.com */ > > [Greg Nelson:] The question is, what do you want to be the result > of P(TRUE) after: > > PROCEDURE P(b: BOOLEAN) RAISES ANY = > EXCEPTION E; > BEGIN > IF b THEN > TRY P(NOT b) EXCEPT E: (* Skip *) END > ELSE > RAISE E > END > END P; > > I suppose the most useful interpretation is that each *static* > occurrence of "EXCEPTION Id" defines a new exception, irrespective > of how many times it is "executed". Then all occurrences of E in the > above example refer to the same exception. > > Admittedly this is not consistent with the principle of structural > type equivalence, but is at least consistent with the semantics of > BRANDED T. Ada took this path to defining the meaning of exceptions declared in a recursive procedure, namely that each "static" occurrence defines a unique exception. My recommendation: Avoid the problem. Stick with top-level only. It is of marginal use to allow local exceptions, and the butchery done to the normal model of declarations is not worth the trouble. Furthermore, it really gets nasty with "generics" in Ada, since each instantiation is considered a new "static" occurrence, requiring replication of exceptions even if otherwise the code can be shared between two generic instantiations. S. Tucker Taft stt@inmet.inmet.com Intermetics, Inc. Cambridge, MA 02138 ------------------------------------------------------------------------------ Date: Thu, 30 May 91 06:04:19 PDT From: Subject: Re: Local exceptions > [S. Tucker Taft:] Ada took this path to defining the meaning of > exceptions declared in a recursive procedure, namely that each > "static" occurrence defines a unique exception. My recommendation: > Avoid the problem. Stick with top-level only. It is of marginal > use to allow local exceptions, and the butchery done to the normal > model of declarations is not worth the trouble. A strong argument for allowing local exceptions is precisely that they would simplify the model of declarations. If types, procedures, constants, and variables can be declared at any level, why should exceptions be an exception? Besides, BRANDED types already follow the "static" declaration paradigm. > Furthermore, it really gets nasty with "generics" in Ada, > since each instantiation is considered a new "static" occurrence, > requiring replication of exceptions even if otherwise the code > can be shared between two generic instantiations. I suppose this will be a problem also for Modula-3 generics, although the way the latter are implemented (with explicit instantiations) makes the non-equivalence of such exceptions more obvious and understandable. Jorge Stolfi DEC Systems Research Center ---------------------------------------------------------------------- DISCLAIMER: I'm only a user... ------------------------------------------------------------------------------