Received: from lcs.mit.edu (CHAOS 15044) by AI.AI.MIT.EDU; 17 Apr 90 19:10:37 EDT Received: from MCC.COM by mintaka.lcs.mit.edu id aa01919; 17 Apr 90 19:11 EDT Received: from crash.cs.umass.edu by MCC.COM with TCP/SMTP; Tue 17 Apr 90 17:43:31-CDT Received: from vax3.cs.umass.edu by crash.cs.umass.edu (5.61/Ultrix2.0-B) id AA00976; Tue, 17 Apr 90 18:43:25 -0400 Message-Id: <9004172243.AA00976@crash.cs.umass.edu> Date: Tue, 17 Apr 90 18:41 EST From: BROLIO@cs.umass.edu Subject: En/Decryption code? To: common-lisp@mcc.com X-Vms-To: IN%"common-lisp@mcc.com" Does anyone know of a Lisp DES private-key encryption/decryption implementation? John Brolio Brolio@cs.umass.edu  Received: from lcs.mit.edu (CHAOS 15044) by AI.AI.MIT.EDU; 11 Apr 90 17:44:54 EDT Received: from MCC.COM by mintaka.lcs.mit.edu id aa16352; 11 Apr 90 17:39 EDT Received: from SAIL.Stanford.EDU by MCC.COM with TCP/SMTP; Wed 11 Apr 90 15:41:15-CDT Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 11 Apr 90 13:40:02 PDT Received: from Semillon.ms by ArpaGateway.ms ; 11 APR 90 13:35:45 PDT Date: Wed, 11 Apr 90 13:34 PDT From: Gregor.pa@xerox.com Subject: Re: Call for contribution: A "CLOS Report" Publication To: commonloops.pa@xerox.com, common-lisp-object-system@sail.stanford.edu, common-lisp@sail.stanford.edu Fcc: BD:>Gregor>mail>outgoing-mail-9.text.newest In-Reply-To: <19900411011133.2.GREGOR@SPIFF.parc.xerox.com> Message-ID: <19900411203426.8.GREGOR@SPIFF.parc.xerox.com> Line-fold: no I want to apologize to the many hundreds of people who, because of my ineptitude, received copies of a message I meant to send only to Andreas Paepcke. Gregor -------  Received: from lcs.mit.edu (CHAOS 15044) by AI.AI.MIT.EDU; 10 Apr 90 22:04:38 EDT Received: from MCC.COM by mintaka.lcs.mit.edu id aa29701; 10 Apr 90 22:04 EDT Received: from SAIL.Stanford.EDU by MCC.COM with TCP/SMTP; Tue 10 Apr 90 20:31:41-CDT Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 10 Apr 90 18:30:34 PDT Received: from Semillon.ms by ArpaGateway.ms ; 10 APR 90 18:12:43 PDT Date: Tue, 10 Apr 90 18:11 PDT From: Gregor.pa@xerox.com Subject: Re: Call for contribution: A "CLOS Report" Publication To: Andreas Paepcke cc: commonloops.pa@xerox.com, common-lisp-object-system@sail.stanford.edu, common-lisp@sail.stanford.edu Fcc: BD:>Gregor>mail>outgoing-mail-9.text.newest In-Reply-To: <9004042034.AA11896@hplap.HPL.HP.COM> Message-ID: <19900411011133.2.GREGOR@SPIFF.parc.xerox.com> Line-fold: no Heya, I have a slightly altered version of what a CLOS book might be like that I would like to talk to you about. In person would be best, the bandwidth is better that way. This plan has some advantages: it really focuses on the mop (the most different part of CLOS), it involves fewer people (easier to coordinate), it can really produce a book (more bang for buck). It also has some disadvantages, namely it takes more work. Tomorrow (wednesday) I will be at home in the morning (till about 11) and then in my office until about 5. -------  Received: from lcs.mit.edu (CHAOS 15044) by AI.AI.MIT.EDU; 5 Apr 90 11:54:05 EDT Received: from MCC.COM by mintaka.lcs.mit.edu id aa04325; 5 Apr 90 11:50 EDT Received: from SAIL.Stanford.EDU by MCC.COM with TCP/SMTP; Thu 5 Apr 90 10:26:33-CDT Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 5 Apr 90 08:25:27 PDT Received: from KENNETH-WILLIAMS.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 773238; 5 Apr 90 10:40:55 EDT Date: Thu, 5 Apr 90 10:46 EDT From: "David A. Moon" Subject: common-lisp for a 386 machine To: michael9%kean.ucs.mun.ca@forsythe.stanford.edu cc: common-lisp@sail.stanford.edu In-Reply-To: <0109563@leif.mun.ca> Message-ID: <19900405144620.8.MOON@KENNETH-WILLIAMS.SCRC.Symbolics.COM> Contact a Symbolics sales person and ask about Cloe, a Common Lisp for 386/486 machines running MS/DOS or Unix.  Received: from lcs.mit.edu (CHAOS 15044) by AI.AI.MIT.EDU; 5 Apr 90 11:42:18 EDT Received: from MCC.COM by mintaka.lcs.mit.edu id aa03749; 5 Apr 90 11:37 EDT Received: from atc.boeing.com by MCC.COM with TCP/SMTP; Thu 5 Apr 90 10:18:09-CDT Received: by atc.boeing.com on Thu, 5 Apr 90 08:18:15 PDT Received: by gallium. (4.0/SMI-4.0) id AA16309; Thu, 5 Apr 90 08:12:50 PDT Date: Thu, 5 Apr 90 08:12:50 PDT From: "William H. Nicholls" Message-Id: <9004051512.AA16309@gallium.> To: common-lisp@mcc.com, info-ti-explorer@sumex.aim.stanford.edu, slug@ai.sri.com Subject: C to LISP translator/compiler? Does anyone know if a translator exists to convert C into Lisp? I've heard of one going the other way...... --------- William H. Nicholls - nicholls@atc.boeing.com Boeing Defense & Space Group - nicholls@ee.washington.edu (let ((*standard-disclaimers* t)) ... )  Received: from lcs.mit.edu (CHAOS 15044) by AI.AI.MIT.EDU; 4 Apr 90 23:40:00 EDT Received: from MCC.COM by mintaka.lcs.mit.edu id aa07634; 4 Apr 90 23:38 EDT Received: from SAIL.Stanford.EDU by MCC.COM with TCP/SMTP; Wed 4 Apr 90 22:22:09-CDT Received: from Forsythe.Stanford.EDU by SAIL.Stanford.EDU with TCP; 4 Apr 90 20:21:04 PDT Received: by Forsythe.Stanford.EDU; Wed, 4 Apr 90 20:21:46 PDT Received: from kean.ucs.mun.ca by kean.ucs.mun.ca with mail11; id 00109571; version Mailer V3.4; 05 Apr 90 00:40 -0330 Date: 05 Apr 90 00:36 -0330 Message-ID: <0109563@leif.mun.ca> From: michael9%kean.ucs.mun.ca@forsythe.stanford.edu To: common-lisp@sail.stanford.edu X-Vms-To: IN%"common-lisp@sail.stanford.edu" Subject: common-lisp for a 386 machine I have been using Gold Hill Common-Lisp V3.1 on a 386 machine for the past year or two. Unfortunately this is a 16-bit implementation. Does anyone know of a faster common-lisp that will run on a 386? If not, what seems to be the best system-implementation combination for the necessarily budget minded? Mike Rabinowitz ... "MICHAEL9@MUN"  Received: from lcs.mit.edu (CHAOS 15044) by AI.AI.MIT.EDU; 4 Apr 90 18:15:43 EDT Received: from MCC.COM by mintaka.lcs.mit.edu id aa21997; 4 Apr 90 18:06 EDT Received: from SAIL.Stanford.EDU by MCC.COM with TCP/SMTP; Wed 4 Apr 90 15:35:55-CDT Received: from hplms2.hpl.hp.com by SAIL.Stanford.EDU with TCP; 4 Apr 90 13:34:38 PDT Received: from hplap.hpl.hp.com by hplms2.hpl.hp.com with SMTP (15.11.1.3/15.5+IOS 3.20) id AA02906; Wed, 4 Apr 90 13:35:17 pdt Received: from localhost by hplap.HPL.HP.COM; Wed, 4 Apr 90 13:34:59 pdt Full-Name: Andreas Paepcke Message-Id: <9004042034.AA11896@hplap.HPL.HP.COM> To: commonloops.pa@xerox.com, common-lisp-object-system@sail.stanford.edu, common-lisp@sail.stanford.edu Subject: Call for contribution: A "CLOS Report" Publication X-Mailer: mh6.5 Date: Wed, 04 Apr 90 13:34:57 PDT From: Andreas Paepcke With the standardization of chapters 1 and 2 done and people slaving away at building applications, I feel it is time to make CLOS more accessible to people with various degrees of interest. I am therefore soliciting your help in working towards a publication to accomplish this. I have in mind a collection of papers by members of the CLOS community, which would be published in a place where it is easiliy available to a broad audience. This serves the purpose both of popularizing CLOS and of ensuring recognition for the contributors. The appendix of this message contains a draft of the collection's categorization. I am now looking for participation and/or suggestions to get this project off the ground. Examples: * Does the categorization make sense? * Do you recommend an existing paper to be reprinted in the collection? * Would you like to contribute a new paper? * Do you know of someone else who might be able to contribute? * Can you volunteer to help with the editing process? If you can produce a paper, I would very much like to hear from you informally soon. It is enough to explain which category you want to address and very roughly what you have in mind. This will make planning a lot easier because it will help me decide which contributions I must actively reach out for to get coverage. Please help me gather some of this data by the end of April. As a separate project, I am organizing this year's CLOS Users and Implementors Workshop to be held in the context of OOPSLA '90. I will send out the call for participation as soon as the OOPSLA administration gives a green light. This should be by May 28. Even though the Workshop is separate from the publication described here, there will be linkage in that work done for the Workshop can find its way into the publication. Hoping to hear from you soon, Andreas Hewlett-Packard Laboratory Palo Alto, Ca 94304 paepcke@hplabs.hp.com 415-857-7398 ;;;;;;;;;;;;;;;;;;;; Categorization Draft ;;;;;;;;;;;;;;;;;;;;;;;;; %----------------------------------------------------- % Summary Categorization of Papers %--------------------------------- Prologue: What is it like to build a language? Short introduction to CLOS Applications Contrasting CLOS with other languages CLOS Analysis and Discussion CLOS implementations Open research issues Glossary Annotated Bibliography Index over all papers Author Index Prologue: What is it like to build a language? ---------------------------------------------- Audience: General, not necessarily CLOS or even language-oriented. Example contents: - How were existing languages used as blueprints? - How was the design effort organized? - Comments on PCL's implementation and distribution. - Honestly: Was CLOS designed top-down, bottom-up, upside-down, inside-out or without any of the fashionable CASE disciplines? - How did the standardization process work? Any advice for others who want to standardize something? Short introduction to CLOS: --------------------------- Very top level, a few pages that make a casual reader aware of what CLOS is about. If someone has heard the term "CLOS" a lot and wants to know what it is, this should be the place to go to. Example contents: - The five CLOS building blocks. - A few programming examples. - Maybe the architecture (MOP concept). - References to more in-depth sources. Applications: ------------- Contributions in this category should go into some depth. While some parts could be accessible to a casually browsing audience, other parts of the contributions should satisfy a more serious reader who is considering the use of CLOS for her own purposes. Example contents: - What does the application do? - Why was CLOS chosen as the implementation language in the first place? - Where did CLOS shine for the application, where did it weaken or fail? There might be a discussion of how other languages would have worked out for this particular application. - How did the language affect the application design? - How is the application delivered? (ex: Is there a small CLOS delivery kernel?) Contrasting CLOS with other languages: -------------------------------------- Contributions may be arbitrarily complex and specialized, although it would be good to have one or two papers accessible to an interested computer scientist who knows some other object-oriented language and wants an easy way of finding the correct mental pigeon hole for CLOS. It would be nice if contributions were dialectic. Maybe two or more authors with violently different opinions could get together and produce one sharp-edged discussion. Example contents: - Strong and weak points of CLOS vs. other languages. - Classification of languages along a particular theme (ex: realization of functional programming, extensibility, oop philosophy, speed/functionality tradeoffs, etc.) - Classification of applications by which languages would be optimal for their realizations. CLOS Analysis and Discussion: ----------------------------- This is for very CLOS-specific contributions. Like papers in the "language contrasting" category, possibly combative, but *technical* pro/con flames combined into one paper would be interesting if they help to focus a reader's attention on some CLOS aspect. Example contents: - Was the MOP a good idea? - Is the MOP-level class hierarchy sensible? - What were the CLOS architectural tradeoffs? Why were particular alternatives chosen? - Which tradeoffs were resolved to CLOS' detriment. CLOS implementations: --------------------- This is to be a non-commercial category. Papers may point out implementation issues, even if the author(s) have not produced any implementation themselves. Example contents: - Which parts of CLOS are easy to implement, which are hard? - Are there clever optimization opportunities? - Are there language aspects that should have been defined differently, given the experience gained from an actual implemention process. Open research issues: --------------------- The audience for papers in this category would be a competent computer scientist looking for something to do. Example contents: - Anything Glossary: --------- Short definitions of CLOS terms. Annotated Bibliography: ----------------------- This is to cover the range from casual interest to very specific CLOS issues. It would be nice if this could be a union of the bibliographies of the papers. Index ----- Terms, concepts, etc. covering all the papers. Author Index ------------ Names and addresses  Received: from lcs.mit.edu (CHAOS 15044) by AI.AI.MIT.EDU; 2 Apr 90 20:10:21 EDT Received: from MCC.COM by mintaka.lcs.mit.edu id aa26480; 2 Apr 90 17:55 EDT Received: from SAIL.Stanford.EDU by MCC.COM with TCP/SMTP; Mon 2 Apr 90 16:25:35-CDT Received: from ti.com by SAIL.Stanford.EDU with TCP; 2 Apr 90 14:24:32 PDT Received: by ti.com id AA00615; Mon, 2 Apr 90 14:46:46 -0500 Received: from vdle8 by tilde id AA22197; Mon, 2 Apr 90 14:37:36 CDT Message-Id: <2848073839-3374082@vdle8> Sender: FARROW@vdle8.csc.ti.com Date: Mon, 2 Apr 90 14:37:19 CDT From: Rob Farrow To: gls@think.com Cc: common-lisp@sail.stanford.edu Subject: SETF VALUES "not a difficult task" You stated on page 129 of CL 2nd ed. that user defined SETF VALUES is not a difficult task. I've been having trouble solving this non-difficult task in several UNIX based Common LISPs. On an EXPLORER, the below implementation works. (define-setf-method values (&rest places) (let ((g (gensym))) (values nil nil (list g) `(multiple-value-setq ,places ,g) g))) But in two prominent Common LISPs (which I will leave nameless), this will not. I was even told by one vendor that this potentially cannot be done. The EXPLORER uses a superset of CL so I cannot depend on it. Neither can I depend of the macro expansion on the vendor LISPs to be correct. I would greatly appreciate some clarification. 1. Should this work? 2. If not, could you send me a version which should work? I will take these results to the vendor so the bug can be fixed. Thank you. P.S. Note that the above implementation does not account for nested generalized variables (not a difficult task).  Received: from lcs.mit.edu (CHAOS 15044) by AI.AI.MIT.EDU; 15 Mar 90 17:33:20 EST Received: from MCC.COM by mintaka.lcs.mit.edu id aa06384; 15 Mar 90 17:26 EST Received: from SAIL.Stanford.EDU by MCC.COM with TCP/SMTP; Thu 15 Mar 90 15:59:07-CST Received: from Think.COM (Gateway.Think.COM) by SAIL.Stanford.EDU with TCP; 15 Mar 90 13:58:03 PST Received: from Fafnir.Think.COM by Think.COM; Thu, 15 Mar 90 16:58:28 -0500 Return-Path: Received: from verdi.think.com by fafnir.think.com; Thu, 15 Mar 90 16:56:54 EST Received: by verdi.think.com; Thu, 15 Mar 90 16:58:20 EST Date: Thu, 15 Mar 90 16:58:20 EST From: Guy Steele Message-Id: <9003152158.AA25893@verdi.think.com> To: CommonLoops@xerox.com, common-lisp@sail.stanford.edu Cc: GLS@think.com Subject: ANSI CL Spec Date: Wed, 14 Mar 90 06:08 PST From: Bruce Esrig To: commonloops-request.PA Subject: ANSI CL Spec Is Steele, 2nd ed. the current best presentation of ANSI Common Lisp ? Bruce Esrig esrig%oravax.uucp@cu-arpa.cs.cornell.edu Perhaps the following text, excerpted from the preface to the second edition of "Common Lisp: The Language", will shed some light on the intended relationship of that book to the standard: ---------------------------------------------------------------- X3J13 has completed the bulk of its technical work in rectifying the 1984 definition and codifying extensions to that definition that have received widespread use and approval. A draft standard is now being prepared; it will probably be available in 1990. There will then be a period (required by ANSI) for public review. X3J13 must then consider the comments it receives and respond appropriately. If the comments result in substantial changes to the draft standard, multiple public review periods may be required before the draft can be approved as an American National Standard. Fortunately, X3J13 has done an outstanding job of documenting its work. ... By my count, by June 1989 some 186 [proposals] were approved as language changes.... The purpose of this second edition is to bridge the gap between the first edition and the forthcoming ANSI standard for Common Lisp. Because of the requirement for formal public review, it will be some time yet before the ANSI standard is final. This book in no way resembles the forthcoming standard (which is being written independently by Kathy Chapman of Digital Equipment Corporation with assistance from the X3J13 Drafting Subcommittee). I have incorporated into this second edition a great deal of material based on the votes of X3J13, in order to give the reader a picture of where the language is heading. My purpose here is not simply to quote the X3J13 documents verbatim but to paraphrase them and relate them to the structure of the first edition. A single vote by X3J13 may be discussed in many parts of this book, and a single passage of this book may be affected by many of the votes. I wish to be very clear: this book is not an official document of X3J13, though it is based on publicly available material produced by X3J13. In no way does this book constitute a definitive description of the forthcoming ANSI standard. The committee's decisions have been remarkably stable (it has rescinded earlier decisions only two or three times), and I do not expect radical changes in direction. Nevertheless, it is quite probable that the draft standard will be substantively revised in response to editorial review or public comment. I have therefore reported here on the actions of X3J13 not to inscribe them in stone, but to make clear how the language of the first edition is likely to change. I have tried to be careful in my wording to avoid saying ``the language has been changed'' and to state simply that ``X3J13 voted at such-and-so time to make the following change.'' Until the day when an official ANSI Common Lisp standard emerges, it is likely that the 1984 definition of Common Lisp will continue to be used widely. This book has been designed to be used as a reference both to the 1984 definition and to the language as modified by the actions of X3J13. ---------------------------------------------------------------- --Guy Steele  Received: from lcs.mit.edu (CHAOS 15044) by AI.AI.MIT.EDU; 23 Feb 90 16:46:36 EST Received: from MCC.COM by mintaka.lcs.mit.edu id aa16149; 23 Feb 90 16:40 EST Received: from SAIL.Stanford.EDU by MCC.COM with TCP/SMTP; Fri 23 Feb 90 15:20:40-CST Received: from boulder.Colorado.EDU by SAIL.Stanford.EDU with TCP; 23 Feb 90 13:19:51 PST Return-Path: Received: by boulder.Colorado.EDU (cu-hub.890824) Received: by frost.colorado.edu (cu.generic.890828) Message-Id: <9002232119.AA19198@frost.colorado.edu> To: common-lisp@sail.stanford.edu Subject: Interest in large Common Lisp object-oriented programs... Date: Fri, 23 Feb 90 14:19:46 +0000 From: Benjamin Zorn I'm interested in getting copies of several large Common Lisp programs that make extensive use of CLOS-defined objects. I am interested in measuring the way in which objects are used and contrasting Lisp object-oriented programming with more traditional Lisp programming styles. Any application area would be of interest, but I am especially interested in memory and computation intensive applications as opposed to interactive editors, browsers and the like. In exchange for providing me with a copy of your program, I can tell you things about it's memory-system behavior that may be hard to determine otherwise (object lifespan distribution, allocation rates, object size distribtion, etc). If you know of any such programs, please let me know. Thank you. Benjamin Zorn University of Colorado, Boulder  Received: from lcs.mit.edu (CHAOS 15044) by AI.AI.MIT.EDU; 2 Feb 90 15:00:10 EST Received: from MCC.COM by mintaka.lcs.mit.edu id aa17921; 2 Feb 90 14:38 EST Received: from Think.COM by MCC.COM with TCP/SMTP; Fri 2 Feb 90 13:22:58-CST Return-Path: Received: from Occam.Think.COM by Think.COM; Fri, 2 Feb 90 11:19:12 -0500 Date: Fri, 2 Feb 90 11:19 EST From: Barry Margolin Subject: Lisp and Symbolic Computation. To: Stephen Nicoud Cc: common-lisp@mcc.com In-Reply-To: <19900201181240.4.SLN@SKAGIT.atc.boeing.com> Message-Id: <19900202161900.0.BARMAR@OCCAM.THINK.COM> Date: Thu, 1 Feb 90 10:12 PST From: Stephen Nicoud Would someone pass on information about subscribing to "Lisp and Symbolic Computation" and "Lisp Pointers"? "Lisp Pointers" is now an ACM SIGPLAN publication, so you subscribe to it through ACM. I don't know who to contact re Lisp and Symbolic Computation. barmar  Received: from lcs.mit.edu (CHAOS 15044) by AI.AI.MIT.EDU; 2 Feb 90 14:58:06 EST Received: from MCC.COM by mintaka.lcs.mit.edu id aa14561; 2 Feb 90 13:10 EST Received: from SAIL.Stanford.EDU by MCC.COM with TCP/SMTP; Fri 2 Feb 90 11:56:19-CST Received: from lucid.com by SAIL.Stanford.EDU with TCP; 2 Feb 90 09:55:04 PST Received: from kent-state ([192.31.212.24]) by heavens-gate.lucid.com id AA20777g; Fri, 2 Feb 90 09:55:10 PST Received: by kent-state id AA02314g; Fri, 2 Feb 90 09:49:51 PST Date: Fri, 2 Feb 90 09:49:51 PST From: Jon L White Message-Id: <9002021749.AA02314@kent-state> To: SEB1525@ccfvx3.draper.com Cc: snicoud@atc.boeing.com, common-lisp@sail.stanford.edu In-Reply-To: "Steve Bacher (Batchman)"'s message of Fri, 2 Feb 90 07:53 EST <9002021436.AA19444@lucid.com> Subject: Lisp and Symbolic Computation. Lisp Pointers will be distributed through ACM/SIGPLAN beginning this year. More details to come. When ACM members receive their renewal forms, they will show a line for Lisp Pointers. It is my understanding that the current readership will not have to re-subscribe. Currently, I've been directing subscription requests to the general editor Mary van Deusen; her electronic address is maida@ibm.com. -- JonL --  Received: from lcs.mit.edu (CHAOS 15044) by AI.AI.MIT.EDU; 2 Feb 90 14:30:23 EST Received: from MCC.COM by mintaka.lcs.mit.edu id aa07019; 2 Feb 90 9:43 EST Received: from SAIL.Stanford.EDU by MCC.COM with TCP/SMTP; Fri 2 Feb 90 08:27:58-CST Received: from RELAY.CS.NET by SAIL.Stanford.EDU with TCP; 2 Feb 90 06:27:13 PST Received: from relay2.cs.net by RELAY.CS.NET id ag10534; 2 Feb 90 8:27 EST Received: from draper.com by RELAY.CS.NET id ab17207; 2 Feb 90 9:26 EST Date: Fri, 2 Feb 90 07:53 EST From: "Steve Bacher (Batchman)" Subject: RE: Lisp and Symbolic Computation. To: snicoud@atc.boeing.com, common-lisp@sail.stanford.edu X-VMS-To: IN%"snicoud@atc.boeing.com" Message-ID: <9002020943.aa07019@mintaka.lcs.mit.edu> "Lisp and Symbolic Computation" is available from : Kluwer Academic Publishers P.O. Box 358 Accord Sta. Hingham, MA 02018-0358 (617) 871-6600 Subscription rate is $60.00 for an individual subscription, or $130.00 for an institutional one (in US dollars - rates may differ for other countries). "LISP Pointers" is published by Sorry, I'd give you info on "LISP Pointers" but all my copies are at home. In the past it was put out by a different company each issue, but I think that now it's being disseminated by one. I'll try to remember to get the info for you over the weekend. - Steve Bacher - Charles Stark Draper Lab  Received: from lcs.mit.edu (CHAOS 15044) by AI.AI.MIT.EDU; 2 Feb 90 14:29:33 EST Received: from MCC.COM by mintaka.lcs.mit.edu id aa05425; 2 Feb 90 8:52 EST Received: from mcsun.EU.net by MCC.COM with TCP/SMTP; Fri 2 Feb 90 06:54:23-CST Received: by mcsun.EU.net via EUnet; Fri, 2 Feb 90 13:54:03 +0100 (MET) Received: from prl.philips.co.uk by kestrel.Ukc.AC.UK with UUCP id aa20826; 2 Feb 90 10:54 GMT Received: from apollo01.prl.philips.co.uk by prlhp1.prl.philips.co.uk; Fri, 2 Feb 90 10:27:37 gmt From: Ashok Gupta Date: Fri, 2 Feb 90 09:09:46 gmt Message-Id: <337.9002020909@apollo54.prl.philips.co.uk> To: snicoud@atc.boeing.com Subject: Re: Lisp and Symbolic Computation. Cc: common-lisp@mcc.com "Lisp and Symbolic Computation, An International Journal", published by Kluwer, Editors-in-Chief Gabriel and Steele. ISSN 0892-4635. Subscription orders can be sent to: Kluwer Academic Publishers P.O. Box 358 Accord Station Hingham, MA 02018-0358 $137 for institutions, $55 for individuals. "Lisp Pointers" :- Published quarterly, no charge for subscription. To get on to the mailing- list, write to :- LISP POINTERS Mary S. Van Deusen, Editor IBM Watson Research PO Box 704 Yorktown Heights NY 10598 USA  Received: from lcs.mit.edu (CHAOS 15044) by AI.AI.MIT.EDU; 1 Feb 90 13:37:57 EST Received: from MCC.COM by mintaka.lcs.mit.edu id aa28232; 1 Feb 90 13:32 EST Received: from atc.boeing.com by MCC.COM with TCP/SMTP; Thu 1 Feb 90 12:05:16-CST Received: by atc.boeing.com on Thu, 1 Feb 90 10:05:03 PST Date: Thu, 1 Feb 90 10:12 PST From: Stephen Nicoud Subject: Lisp and Symbolic Computation. To: common-lisp@mcc.com Message-Id: <19900201181240.4.SLN@SKAGIT.atc.boeing.com> Would someone pass on information about subscribing to "Lisp and Symbolic Computation" and "Lisp Pointers"? Thanks, Steve -- Stephen Nicoud uw-beaver!bcsaic!snicoud Boeing Advanced Technology Center for Computer Sciences  Received: from lcs.mit.edu (CHAOS 15044) by AI.AI.MIT.EDU; 16 Jan 90 04:44:09 EST Received: from MCC.COM by mintaka.lcs.mit.edu id aa14455; 16 Jan 90 4:36 EST Received: from arisia.Xerox.COM by MCC.COM with TCP/SMTP; Tue 16 Jan 90 02:38:10-CST Received: from omnibus.parc.Xerox.COM by arisia.Xerox.COM with SMTP (5.61+/IDA-1.2.8/gandalf) id AA26036; Tue, 16 Jan 90 00:04:50 -0800 Received: by omnibus.parc.xerox.com (5.61+/IDA-1.2.8/gandalf) id AA02084; Tue, 16 Jan 90 00:11:43 PST Message-Id: <9001160811.AA02084@omnibus.parc.xerox.com> Date: Tue, 16 Jan 90 00:11:43 PST To: common-lisp@mcc.com Cc: loosemore@cs.utah.edu Subject: X3J13 cleanup issues In-Reply-To: DonC's request for X3J13 discussions... From: Larry Masinter Sender: masinter@parc.xerox.com Reply-To: masinter@parc.xerox.com The common lisp cleanup issues (and some other related material) is available for anonymous FTP from arisia.xerox.com, in the directory tree under "cl". For example, cl/cleanup/passed has those cleanup issues that were passed in previous meetings. Caveats: ** I'm behind. I haven't finished updating the issues passed at the last (November '89) meeting... ** None of this is 'official': this is my personal archive of what I think passed at previous meetings, and, in any case, X3J13 has been known to reverse itself. ** there are a number of items voted in by X3J13 that are not included in this archive, including the CLOS spec (available elsewhere on arisia), LOOP, the condition system. The subdirectories for compiler, character, etc. are unreliable (old and not maintained). I'm (sporadically) working on a mail archive server for cleanup issues and other material; until that's done, anonymous ftp is the best way to access this material. I think Sandra Loosemore has been keeping the "compiler" subcommittee issues more up to date, on cs.utah.edu.  Received: from lcs.mit.edu (CHAOS 15044) by AI.AI.MIT.EDU; 15 Jan 90 16:34:05 EST Received: from MCC.COM by mintaka.lcs.mit.edu id aa22502; 15 Jan 90 16:25 EST Received: from SAIL.Stanford.EDU by MCC.COM with TCP/SMTP; Mon 15 Jan 90 13:34:04-CST Received: from RELAY.CS.NET by SAIL.Stanford.EDU with TCP; 15 Jan 90 11:33:12 PST Received: from relay2.cs.net by RELAY.CS.NET id am13154; 15 Jan 90 13:33 EST Received: from gte.com by RELAY.CS.NET id ac24838; 15 Jan 90 14:30 EST Received: from centauri.gte.com (centauri) by bunny.gte.com (4.41/GTEL1.13) id AA08223; Mon, 15 Jan 90 14:26:04 EST Date: Mon, 15 Jan 90 14:26 EST From: Mark Weissman Subject: Change my email address please To: common-lisp@sail.stanford.edu, cl-windows@sail.stanford.edu Message-Id: <19900115192645.5.MW06@centauri.gte.com> Hello, Could someone please change my email address on this list from weissman@apollo.com to weissman@bunny.gte.com. Thanks, Mark Weissman  Received: from lcs.mit.edu (CHAOS 15044) by AI.AI.MIT.EDU; 14 Jan 90 04:07:03 EST Received: from MCC.COM by mintaka.lcs.mit.edu id aa01981; 14 Jan 90 4:01 EST Received: from vaxa.isi.edu by MCC.COM with TCP/SMTP; Sun 14 Jan 90 01:55:49-CST Posted-Date: Sat, 13 Jan 90 23:49:23 PST Message-Id: <9001140749.AA28814@vaxa.isi.edu> Received: from LOCALHOST by vaxa.isi.edu (5.61/5.61) id AA28814; Sat, 13 Jan 90 23:49:27 -0800 Subject: destructive operations - a few replies To: barmar@think.com, Moon@stony-brook.scrc.symbolics.com, common-lisp@mcc.com Date: Sat, 13 Jan 90 23:49:23 PST From: Don Cohen I am not sure that you can specify precisely, unambiguously, and independent of implementation what you are asking to be guaranteed about these functions. How about, for delete on a list, that only cdrs of the argument are altered, specifically cdrs that originally pointed to things to be deleted are altered to point to the next element not to be deleted, and that the first cdr (generally the zero'th) not pointing to an element to be deleted is returned. I suspect similar specs are not hard for other destructive operations. Code is never a good specification, ... I was suggesting that some reasonable piece of code would universally suffice. Since you want to be picky, I'll be happy to specify that all I need is "operationally equivalent" code - you shouldn't be able to tell from accessing the resulting state that you did anything different from the supplied definition. This does not constrain internal names, timing, space usage, etc. (In the absence of multiple processes it leaves a lot of leeway on ordering, but there are more serious problems associated with concurrency.) Implementations can improve performance of many of the above-mentioned functions when they are not under the constraint to implement them in a highly constrained fashion. If that's the case, as I suggested, please supply another version that I can use when I care. The solution of making me (and everyone else who ever needs it) write his own is certainly one approach, but not the one taken by commonlisp or any of the other lisps it was trying to unify. See the file arisia.xerox.com:/cl/cleanup/passed/remf-destruction-unspecified for all the specifications. Thanks (for a whole gold mine...). I notice that this file contains a few specs I like, viz., nconc, nsubstitute, and quite a few like delete that I don't. Since we didn't want to require multiple versions, we (X3J13) opted... My suggestion of a new keyword or new function does not REQUIRE multiple versions - only if you want to supply an optimized version that doesn't meet the additional requirements. I'm surprised that you'd try to avoid this situation. It's not as if it's been avoided in the past. How about stable-sort?  Received: from lcs.mit.edu (CHAOS 15044) by AI.AI.MIT.EDU; 13 Jan 90 00:16:50 EST Received: from MCC.COM by mintaka.lcs.mit.edu id aa08690; 13 Jan 90 0:10 EST Received: from STONY-BROOK.SCRC.Symbolics.COM by MCC.COM with TCP/SMTP; Fri 12 Jan 90 15:35:03-CST Received: from KENNETH-WILLIAMS.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 722042; 12 Jan 90 16:32:25 EST Date: Fri, 12 Jan 90 16:34 EST From: "David A. Moon" Subject: destructive operations To: Don Cohen cc: common-lisp@mcc.com In-Reply-To: <9001122047.AA26595@vaxa.isi.edu> Message-ID: <19900112213433.3.MOON@KENNETH-WILLIAMS.SCRC.Symbolics.COM> Date: Fri, 12 Jan 90 12:47:12 PST From: Don Cohen According to issue REMF-DESTRUCTION-UNSPECIFIED:X3J13-MAR-89, Where can I get this and other such discussions? The easiest way would be for you to contact whoever in your organization is a member of the X3J13 standards committee. I am not sure that you can specify precisely, unambiguously, and independent of implementation what you are asking to be guaranteed about these functions. It's quite possible that the easiest specification is the code. Code is never a good specification, since there is no way to know which aspects of the code were intended to be part of the specification and which aspects of the code were mere accidents. For example, when you write code you have to give specific names to internal functions and variables, you have to choose a specific order in which to perform all operations, and you have to either omit all optimizations or write code that is hard to read. It's unlikely that by doing that you meant to specify that those names must be used, that order must be followed slavishly, and no optimizations are permitted. The only way code makes a good specification is when you actually intend to specify that every implementation must be implemented exactly the same way.  Received: from lcs.mit.edu (CHAOS 15044) by AI.AI.MIT.EDU; 12 Jan 90 22:06:57 EST Received: from MCC.COM by mintaka.lcs.mit.edu id aa03763; 12 Jan 90 21:55 EST Received: from Princeton.EDU by MCC.COM with TCP/SMTP; Fri 12 Jan 90 16:38:13-CST Received: from winnie.Princeton.EDU by Princeton.EDU (5.58+++/2.29/mailrelay) id AA18823; Fri, 12 Jan 90 17:36:03 EST Received: by winnie (4.12/1.96) id AA27734; Fri, 12 Jan 90 17:36:25 est Date: Fri, 12 Jan 90 17:36:25 est From: eliot handelman Message-Id: <9001122236.AA27734@winnie> To: Moon@stony-brook.scrc.symbolics.com, donc@vaxa.isi.edu Subject: Re: destructive operations Cc: common-lisp@mcc.com >unspecified. According to issue REMF-DESTRUCTION-UNSPECIFIED:X3J13-MAR-89, Where are these documents to be found? --eliot  Received: from lcs.mit.edu (CHAOS 15044) by AI.AI.MIT.EDU; 12 Jan 90 20:56:12 EST Received: from MCC.COM by mintaka.lcs.mit.edu id aa01631; 12 Jan 90 20:49 EST Received: from Think.COM by MCC.COM with TCP/SMTP; Fri 12 Jan 90 16:28:09-CST Return-Path: Received: from Occam.Think.COM by Think.COM; Fri, 12 Jan 90 17:26:06 -0500 Date: Fri, 12 Jan 90 17:25 EST From: Barry Margolin Subject: destructive operations To: Don Cohen Cc: Moon@stony-brook.scrc.symbolics.com, common-lisp@mcc.com In-Reply-To: <9001122047.AA26595@vaxa.isi.edu> Message-Id: <19900112222557.7.BARMAR@OCCAM.THINK.COM> Date: Fri, 12 Jan 90 12:47:12 PST From: Don Cohen I bet my example would work in every lisp I've ever used, although I'd have to change the name of the delete function several times. Is this a discussion about DELETE or about destructive operations on lists in general? At the present time, you're probably right about DELETE. But as I mentioned in my previous message, the same argument cannot be made about many of the other destructive functions, which don't even behave consistently within a particular implementation. barmar  Received: from lcs.mit.edu (CHAOS 15044) by AI.AI.MIT.EDU; 12 Jan 90 19:38:04 EST Received: from MCC.COM by mintaka.lcs.mit.edu id aa02104; 12 Jan 90 19:29 EST Received: from Think.COM by MCC.COM with TCP/SMTP; Fri 12 Jan 90 16:19:23-CST Return-Path: Received: from Occam.Think.COM by Think.COM; Fri, 12 Jan 90 17:17:39 -0500 Date: Fri, 12 Jan 90 17:17 EST From: Barry Margolin Subject: destructive operations To: Don Cohen Cc: common-lisp@mcc.com In-Reply-To: <9001121905.AA02195@daystar.aca.mcc.com> Message-Id: <19900112221724.5.BARMAR@OCCAM.THINK.COM> Date: Tue, 09 Jan 90 15:14:58 PST From: Don Cohen instance, suppose I do: (setq a '(1 2 3 4 5)) (setq b (nthcdr 2 a)) Suppose I "know" that neither a nor b starts with 4. After (delete 4 a) I'd like to be able to assume that b no longer contains 4. Is this unreasonable? If so, why? If there's really a great potential for optimization in the absence of my requirement, perhaps commonlisp should offer two versions (or another argument) of destructive operations. If not, the maximal sharing ought to be specified. Dave Moon already gave a pretty good answer; I just want to add a point that I'm surprised he didn't make. The problem with heaping lots of requirements on the functions is that it prevents a number of implementation-specific optimizations. For instance, when deleting an element of a cdr-coded list, maintaining optimal sharing may result in poorer paging performance. I'm not sure that any of the cdr-coded implementations actually implement such an optimization, but I know that Symbolics uses different implementations of NREVERSE for cdr-coded and normal lists (for normal lists (eq (last x) (nreverse x)) is true (it reverses the cdr chains), while for cdr-coded lists (eq x (nreverse x)) is true (it swaps the elements)). They may also use different algorithms for SORT, but I'm not sure (if they don't, they probably want to keep the option open). Since we didn't want to require multiple versions, we (X3J13) opted for the one that allows the implementors the most flexibility and opportunity to optimize. Note, however, that we did not do this for all the destructive functions; there are some where we actually strengthened the requirement over what CLtL specifies. See the file arisia.xerox.com:/cl/cleanup/passed/remf-destruction-unspecified for all the specifications. barmar  Received: from lcs.mit.edu (CHAOS 15044) by AI.AI.MIT.EDU; 12 Jan 90 16:45:10 EST Received: from MCC.COM by mintaka.lcs.mit.edu id aa25885; 12 Jan 90 16:41 EST Received: from vaxa.isi.edu by MCC.COM with TCP/SMTP; Fri 12 Jan 90 15:18:37-CST Posted-Date: Fri, 12 Jan 90 12:47:12 PST Message-Id: <9001122047.AA26595@vaxa.isi.edu> Received: from LOCALHOST by vaxa.isi.edu (5.61/5.61) id AA26595; Fri, 12 Jan 90 12:47:17 -0800 To: Moon@stony-brook.scrc.symbolics.com Subject: destructive operations Cc: common-lisp@mcc.com Date: Fri, 12 Jan 90 12:47:12 PST From: Don Cohen In ANSI Common Lisp, the value of B after that call to DELETE is unspecified. That's even worse than I thought. According to issue REMF-DESTRUCTION-UNSPECIFIED:X3J13-MAR-89, Where can I get this and other such discussions? I am not sure that you can specify precisely, unambiguously, and independent of implementation what you are asking to be guaranteed about these functions. It's quite possible that the easiest specification is the code. In any case, my guess is that the Common Lisp designers (including X3J13) felt that the type of programming practice you are proposing is rarely enough used that it isn't appropriate to add additional features to the language in support of it. If so, I'd disagree. In fact, it's often hard to tell whether you're relying on this sort of behavior until you meet an implementation that doesn't have it. Also, I don't really believe that the current state of affairs is quite as chaotic as the quotation suggests. I bet my example would work in every lisp I've ever used, although I'd have to change the name of the delete function several times. I also fail to see the great opportunity for optimization in this and related cases.  Received: from lcs.mit.edu (CHAOS 15044) by AI.AI.MIT.EDU; 12 Jan 90 15:39:27 EST Received: from MCC.COM by mintaka.lcs.mit.edu id aa23325; 12 Jan 90 15:31 EST Received: from STONY-BROOK.SCRC.Symbolics.COM by MCC.COM with TCP/SMTP; Fri 12 Jan 90 14:11:56-CST Received: from KENNETH-WILLIAMS.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 721935; 12 Jan 90 14:48:48 EST Date: Fri, 12 Jan 90 14:51 EST From: "David A. Moon" Subject: destructive operations To: Don Cohen cc: common-lisp@mcc.com In-Reply-To: <9001121905.AA02195@daystar.aca.mcc.com> Message-ID: <19900112195105.8.MOON@KENNETH-WILLIAMS.SCRC.Symbolics.COM> Date: Tue, 09 Jan 90 15:14:58 PST From: Don Cohen I've seen some discussion lately (on lisp newsgroups) of the fact that CLtL promises very little about destructive operations. For instance, it looks like delete could be defined as remove. In particular, there's no requirement of maximal structure sharing. While this might allow some optimization in some implementations, I think that the assumption of maximal sharing is important in a lot of cases. This means that in those cases it becomes necessary to write your own versions of the destructive functions. (Worse still, since MOST implementations do maximally share structure, it's real easy to write non-portable code without even realizing it!) The cases I have in mind involve purposely shared structure. For instance, I might use list structure to represent a "semantic net", where there are many pointers to the same structure. I'd like to be able to do a destructive operation on the structure I get by following one path and assume that the change affects the (originally same) structure that I reach by another path. For instance, suppose I do: (setq a '(1 2 3 4 5)) (setq b (nthcdr 2 a)) Suppose I "know" that neither a nor b starts with 4. After (delete 4 a) I'd like to be able to assume that b no longer contains 4. In ANSI Common Lisp, the value of B after that call to DELETE is unspecified. According to issue REMF-DESTRUCTION-UNSPECIFIED:X3J13-MAR-89, (DELETE object sequence ...) when sequence is a list, is permitted to SETF any part, CAR or CDR, of the top-level list structure held in that sequence. Thus DELETE is permitted to perform arbitrary SETF operations on the CAR and CDR of the three conses that make up B. Is this unreasonable? If so, why? More quotations from REMF-DESTRUCTION-UNSPECIFIED:X3J13-MAR-89: Implementations already vary widely on their implementation techniques for these functions. This effectively clarifies the status quo, making it more clear to programmers what they may rely upon in portable code. Implementations can improve performance of many of the above-mentioned functions when they are not under the constraint to implement them in a highly constrained fashion. If there's really a great potential for optimization in the absence of my requirement, perhaps commonlisp should offer two versions (or another argument) of destructive operations. If not, the maximal sharing ought to be specified. I am not sure that you can specify precisely, unambiguously, and independent of implementation what you are asking to be guaranteed about these functions. In any case, my guess is that the Common Lisp designers (including X3J13) felt that the type of programming practice you are proposing is rarely enough used that it isn't appropriate to add additional features to the language in support of it. It's not too hard to write your own functions in terms of CAR and RPLACD. Of course your point that this is a portability trap is a good point. Common Lisp does contain several portability traps like this (although I think Common Lisp contains fewer portability traps than C).  Received: from lcs.mit.edu (CHAOS 15044) by AI.AI.MIT.EDU; 12 Jan 90 14:55:17 EST Received: from MCC.COM by mintaka.lcs.mit.edu id aa21705; 12 Jan 90 14:48 EST Received: from daystar.aca.mcc.com by MCC.COM with TCP/SMTP; Fri 12 Jan 90 13:22:45-CST Date: Fri, 12 Jan 90 13:22:39 CST Posted-Date: Fri, 12 Jan 90 13:22:39 CST Message-Id: <9001121922.AA02205@daystar.aca.mcc.com> Received: by daystar.aca.mcc.com (4.0/ACAv4.1i) id AA02205; Fri, 12 Jan 90 13:22:39 CST To: CL-Cleanup@mcc.com, CL-Window@mcc.com, Common-Lisp@mcc.com, Common-Lisp-Object-System@mcc.com Subject: TEST message from Postmaster From: Common-Lisp-Request@mcc.com Sender: loeffler@daystar.aca.mcc.com Reply-To: Common-Lisp-Request@mcc.com Please disregard this message. It is being send as a test to see how many addresses the mailer bounces.  Received: from lcs.mit.edu (CHAOS 15044) by AI.AI.MIT.EDU; 12 Jan 90 14:37:41 EST Received: from MCC.COM by mintaka.lcs.mit.edu id aa20950; 12 Jan 90 14:30 EST Received: from daystar.aca.mcc.com by MCC.COM with TCP/SMTP; Fri 12 Jan 90 13:05:39-CST Posted-Date: Tue, 09 Jan 90 15:14:58 PST Message-Id: <9001121905.AA02195@daystar.aca.mcc.com> Received: by daystar.aca.mcc.com (4.0/ACAv4.1i) id AA02195; Fri, 12 Jan 90 13:05:35 CST To: common-lisp@mcc.com Subject: destructive operations Date: Tue, 09 Jan 90 15:14:58 PST From: Don Cohen Sender: loeffler@daystar.aca.mcc.com Received: from SAIL.Stanford.EDU by MCC.COM with TCP/SMTP; Tue 9 Jan 90 17:15:27-CST Received: from vaxa.isi.edu by SAIL.Stanford.EDU with TCP; 9 Jan 90 15:14:42 PST Posted-Date: Tue, 09 Jan 90 15:14:58 PST Message-Id: <9001092315.AA16001@vaxa.isi.edu> Received: from LOCALHOST by vaxa.isi.edu (5.61/5.61) id AA16001; Tue, 9 Jan 90 15:15:04 -0800 To: common-lisp@sail.stanford.edu Subject: destructive operations Date: Tue, 09 Jan 90 15:14:58 PST From: Don Cohen I've seen some discussion lately (on lisp newsgroups) of the fact that CLtL promises very little about destructive operations. For instance, it looks like delete could be defined as remove. In particular, there's no requirement of maximal structure sharing. While this might allow some optimization in some implementations, I think that the assumption of maximal sharing is important in a lot of cases. This means that in those cases it becomes necessary to write your own versions of the destructive functions. (Worse still, since MOST implementations do maximally share structure, it's real easy to write non-portable code without even realizing it!) The cases I have in mind involve purposely shared structure. For instance, I might use list structure to represent a "semantic net", where there are many pointers to the same structure. I'd like to be able to do a destructive operation on the structure I get by following one path and assume that the change affects the (originally same) structure that I reach by another path. For instance, suppose I do: (setq a '(1 2 3 4 5)) (setq b (nthcdr 2 a)) Suppose I "know" that neither a nor b starts with 4. After (delete 4 a) I'd like to be able to assume that b no longer contains 4. Is this unreasonable? If so, why? If there's really a great potential for optimization in the absence of my requirement, perhaps commonlisp should offer two versions (or another argument) of destructive operations. If not, the maximal sharing ought to be specified.  Received: from lcs.mit.edu (CHAOS 15044) by AI.AI.MIT.EDU; 19 Dec 89 15:25:22 EST Received: from MCC.COM by mintaka.lcs.mit.edu id aa00383; 19 Dec 89 15:13 EST Received: from SAIL.Stanford.EDU by MCC.COM with TCP/SMTP; Tue 19 Dec 89 13:52:37-CST Received: from lucid.com by SAIL.Stanford.EDU with TCP; 19 Dec 89 11:51:29 PST Received: from rose ([192.31.212.83]) by lucid.com id AA19170g; Tue, 19 Dec 89 08:48:02 PST Received: by rose id AA17764g; Tue, 19 Dec 89 08:50:39 PST Date: Tue, 19 Dec 89 08:50:39 PST From: Jan Zubkoff Message-Id: <8912191650.AA17764@rose> To: X3J13@sail.stanford.edu, common-lisp@sail.stanford.edu Subject: address change LISP AND SYMBOLIC COMPUTATION: An International Journal and X3J13 Business Please send future correspondence, submissions and reviews to me at the following address: Jan Zubkoff Lucid, Inc. 707 Laurel Street Menlo Park, CA 94025 jlz@lucid.com 415/329-8400 x5509 I will be in transit for 3 weeks after Christmas arriving January 15. ---jan---  Received: from lcs.mit.edu (CHAOS 15044) by AI.AI.MIT.EDU 17 Nov 89 13:52:15 EST Received: from MCC.COM by mintaka.lcs.mit.edu id aa16610; 17 Nov 89 13:27 EST Received: from atc.boeing.com by MCC.COM with TCP/SMTP; Fri 17 Nov 89 12:02:30-CST Received: by atc.boeing.com on Fri, 17 Nov 89 10:02:26 PST Received: by tieton.atc.boeing.com (3.2/SMI-3.0DEV3) id AA01890; Fri, 17 Nov 89 10:02:31 PST Date: Fri, 17 Nov 89 10:02:31 PST From: aseem@atc.boeing.com Message-Id: <8911171802.AA01890@tieton.atc.boeing.com> To: CommonLoops.pa@xerox.com, clue-review@dsg.csc.ti.com, common-lisp@mcc.com, common0-lisp-object-system@mcc.com Subject: CLX toolkit and/or CLUE Contact "classes/libraries" Are there any CLX toolkits and/or CLUE Contact "libraries" available (commercially or publically) which provide a set of basic interactive objects like buttons, scrollbars, menus, forms, text etc. I am looking at writing an interface using CLUE and do not wish to build up the interface components from scratch using CLX. aseem@atc.boeing.com 206-865-3225  Received: from lcs.mit.edu (CHAOS 15044) by AI.AI.MIT.EDU 14 Nov 89 16:11:58 EST Received: from MCC.COM by mintaka.lcs.mit.edu id aa00238; 14 Nov 89 16:03 EST Received: from daystar.aca.mcc.com by MCC.COM with TCP/SMTP; Tue 14 Nov 89 14:22:27-CST Date: Tue, 14 Nov 89 14:22:20 CST From: David Loeffler Posted-Date: Tue, 14 Nov 89 14:22:20 CST Message-Id: <8911142022.AA15313@daystar.aca.mcc.com> Received: by daystar.aca.mcc.com (3.2/ACTv4.1i) id AA15313; Tue, 14 Nov 89 14:22:20 CST To: Common-Lisp@mcc.com, Common-Lisp-Object-system@mcc.com, Cl-windows@mcc.com, CL-Cleanup@mcc.com Subject: Test Message This is a test message. Please disregard it. We are testing a new host for distributing mail on these lists. This message is just a test to see how well the mailer handles distributing the mail. Thank you.  Received: from lcs.mit.edu (CHAOS 15044) by AI.AI.MIT.EDU 13 Nov 89 13:13:30 EST Received: from Sail.Stanford.EDU by mintaka.lcs.mit.edu id ad10394; 13 Nov 89 13:08 EST Received: from gateway.mitre.org by SAIL.Stanford.EDU with TCP; 13 Nov 89 09:57:42 PST Return-Path: Received: by gateway.mitre.org (5.54/SMI-2.2) id AA04664; Mon, 13 Nov 89 13:01:06 EST Received: by starbase (4.0/SMI-4.0) id AA25064; Mon, 13 Nov 89 12:54:21 EST Date: Mon, 13 Nov 89 12:54:21 EST From: David Vogel Message-Id: <8911131754.AA25064@starbase> To: common-lisp@sail.stanford.edu Subject: put me on the mailing list Please. Thank you.  Received: from lcs.mit.edu (CHAOS 15044) by AI.AI.MIT.EDU 10 Nov 89 14:46:28 EST Received: from Sail.Stanford.EDU by mintaka.lcs.mit.edu id ad13999; 10 Nov 89 14:40 EST Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 10 Nov 89 11:31:48 PST Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 690324; 10 Nov 89 14:30:37 EST Date: Fri, 10 Nov 89 14:30 EST From: Kent M Pitman Subject: make-echo-stream & unread-char To: johnw%cogs.sussex.ac.uk@nsfnet-relay.ac.uk cc: common-lisp@sail.stanford.edu In-Reply-To: <12178.8911091633@psune.cogs.susx.ac.uk> Message-ID: <19891110193017.3.KMP@BOBOLINK.SCRC.Symbolics.COM> Date: Thu, 9 Nov 89 16:33:24 GMT From: John Williams If you 'unread' a character to an echo-stream, then should that character be echoed again when it is read again? CLtL is not adequately specific. ANSI Common Lisp will take a position on this. Briefly (because this is a large list), the position will likely be that the character is echoed the first time it is seen on the stream, and not re-echoed later. Note that ANSI Common Lisp is not a standard yet--it's not even a draft standard. The position of X3J13 (the ANSI CL commitee) on this issue could change between now and the time the standard is approved. Also note that any decisions by X3J13 are not binding on implementations of CLtL. It is perfectly legitimate for a correct `implementation of CLtL' to differ in interpretation on an issue such as this from what would be necessary in a correct `implementation of ANSI CL' (whatever that might turn out to be). So nothing forces you to go with the X3J13 interpretation of this situation--but it's not a bad idea to go with it for expected-future-compatibility's sake if nothing keeps you from doing so. -kmp  Received: from lcs.mit.edu (CHAOS 15044) by AI.AI.MIT.EDU 9 Nov 89 12:55:04 EST Received: from Sail.Stanford.EDU by mintaka.lcs.mit.edu id ad24272; 9 Nov 89 12:47 EST Received: from NSFnet-Relay.AC.UK by SAIL.Stanford.EDU with TCP; 9 Nov 89 09:38:29 PST Received: from sun.nsfnet-relay.ac.uk by vax.NSFnet-Relay.AC.UK via Janet with NIFTP id aa09616; 9 Nov 89 16:32 GMT Received: from psune by syma.sussex.ac.uk; Thu, 9 Nov 89 16:31:31 GMT Message-Id: <12178.8911091633@psune.cogs.susx.ac.uk> From: John Williams Date: Thu, 9 Nov 89 16:33:24 GMT To: common-lisp@sail.stanford.edu Subject: make-echo-stream & unread-char If you 'unread' a character to an echo-stream, then should that character be echoed again when it is read again? I ask because my implementation of READ uses UNREAD-CHAR to 'unread' terminating macro characters when they are read as the terminator to a token. This means that if you READ an echo-stream terminating macro chars (e.g. "(") get echoed twice. John Williams, Dept. of Cognitive and Computing Sciences, University of Sussex, UK  Received: from lcs.mit.edu (CHAOS 15044) by AI.AI.MIT.EDU 1 Nov 89 17:02:45 EST Received: from Sail.Stanford.EDU by mintaka.lcs.mit.edu id ad04768; 1 Nov 89 16:40 EST Received: from lucid.com by SAIL.Stanford.EDU with TCP; 1 Nov 89 13:32:11 PST Received: from bhopal ([192.43.178.13]) by heavens-gate id AA09060g; Wed, 1 Nov 89 13:28:31 PST Received: by bhopal id AA01668g; Wed, 1 Nov 89 13:30:24 PST Date: Wed, 1 Nov 89 13:30:24 PST From: Jon L White Message-Id: <8911012130.AA01668@bhopal> To: jonl@lucid.com Cc: snicoud@atc.boeing.com, common-lisp@sail.stanford.edu In-Reply-To: Jon L White's message of Wed, 1 Nov 89 10:51:13 PST <8911011851.AA00929@bhopal> Subject: :DISPLACED-TO & :DISPLACED-INDEX-OFFSET. Ooops, my message ignored the "accidental" equivalence of the types (ARRAY BIT) and (ARRAY (UNSIGNED-BYTE 1)). CLtL p29 explicitly requires that specialized array types be provided for arrays of element type BIT and STRING-CHAR. Just convert the type-specifiers in that msg as follows (UNSIGNED-BYTE 1) ==> (UNSIGNED-BYTE 2) (UNSIGNED-BYTE 2) ==> (UNSIGNED-BYTE 4) and it is all technically correct again. Thanks to Eric Benson for pointing this out. -- JonL --  Received: from lcs.mit.edu (CHAOS 15044) by AI.AI.MIT.EDU 1 Nov 89 14:47:43 EST Received: from Sail.Stanford.EDU by mintaka.lcs.mit.edu id ae09896; 1 Nov 89 14:42 EST Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 1 Nov 89 11:35:41 PST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 685649; 1 Nov 89 14:33:56 EST Date: Wed, 1 Nov 89 14:33 EST From: "David A. Moon" Subject: :DISPLACED-TO & :DISPLACED-INDEX-OFFSET. To: Jon L White , snicoud@atc.boeing.com cc: common-lisp@sail.stanford.edu In-Reply-To: <8911011851.AA00929@bhopal> Message-ID: <19891101193358.8.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Wed, 1 Nov 89 10:51:13 PST From: Jon L White In answer to your second question: Does the :DISPLACED-INDEX-OFFSET refer to the number of '(UNSIGNED-BYTE 2) or '(UNSIGNED-BYTE 1) elements to offset? I think CLtL p288 makes it clear that the :DISPLACED-INDEX-OFFSET is in units of the array to which the displacement is being made. [Last paragraph: "It is required that the total size of A (the array being displaced to) be no smaller than the sum of the total size of B plus the offset n specified by the :DISPLACED-INDEX-OFFSET argument.] Note however it is presuming that the sizes of the "chunks" necessary to store elements from the two arrays is the same. In Symbolics' extension that allows displacement to an array with a different element-type, the :DISPLACED-INDEX-OFFSET is in units of the array to which the option is applied, not in units of the :DISPLACED-TO array. I imagine the same is true of TI's similar extension, although I did not check this. As you say, in strict Common Lisp the two units must be the same, so the issue does not arise. Yes, multilevel displaced arrays of differing types work in the obvious way, again as an extension; strict Common Lisp requires all the types to be the same. It's possible to construct a multilevel displaced array that cannot be AREF'ed because the combined displaced index offset is not an integral multiple of the array element size. Symbolics' extension proves to be extremely useful for certain inherently machine-dependent operations, but I would not recommend trying to add it to the portable language. As you say, it is inherently dependent on the machine's data representation.  Received: from lcs.mit.edu (CHAOS 15044) by AI.AI.MIT.EDU 1 Nov 89 14:38:59 EST Received: from Sail.Stanford.EDU by mintaka.lcs.mit.edu id ad26039; 1 Nov 89 13:59 EST Received: from lucid.com by SAIL.Stanford.EDU with TCP; 1 Nov 89 10:52:19 PST Received: from bhopal ([192.43.178.13]) by heavens-gate id AA08376g; Wed, 1 Nov 89 10:49:17 PST Received: by bhopal id AA00929g; Wed, 1 Nov 89 10:51:13 PST Date: Wed, 1 Nov 89 10:51:13 PST From: Jon L White Message-Id: <8911011851.AA00929@bhopal> To: snicoud@atc.boeing.com Cc: common-lisp@sail.stanford.edu In-Reply-To: Stephen Nicoud's message of Tue, 31 Oct 89 15:37 PST <19891031233708.3.SLN@SKAGIT.atc.boeing.com> Subject: :DISPLACED-TO & :DISPLACED-INDEX-OFFSET. The problem with the specification on p288 -- "... does not have the same :element-type" -- is that there is an ambiguity in the meaning of the :element-type. See CLtL p45 where explicit permission is given to "upgrade" the requested element type in a call to make-array. Thus whether or not: (make-array 4 :element-type '(unsigned-byte 1)) (make-array 4 :element-type '(unsigned-byte 2)) are both upgraded into the same underlying element-type is very much implementation dependent. The X3J13 committee -- which is making a recommendation for an ANSI standard for Common Lisp -- voted in a proposal ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:UNIFY-UPGRADING which clarified this notion. Now, since the real restriction against displacing to arrays with differing element types is based on the potential for "endian" mismatch, then you can be sure that there is no mismatch when both requests produce the same sort of specialized array. But if the underlying sizes of "chunks" necesary to hold the elements aren't the same, then it makes a difference how two n-bit chunks are packed into a single 2n-bit chunk. E.g., is it +---------+---------+ ||| +---------+---------+ or is it +---------+---------+ ||| +---------+---------+ Thus it is even reasonable for an implementation to permit displacement to an array with a different underlying element-size, but this would not be portable becauses the indices would have a significantly different meaning in an implementation with a different "endianness". In fact, since the element-type upgrading scheme is implementation-dependent, then the only portable displacements are to those arrays whose element-type specifiers are equivalent over all implementations. Of course, (unsigned-byte 1) and (unsigned-byte 2) are not type-equivalent, since there are easily some implementations which will merge them into a single specialized array type, and other implementations that will make different specialized array types for each one. In answer to your second question: Does the :DISPLACED-INDEX-OFFSET refer to the number of '(UNSIGNED-BYTE 2) or '(UNSIGNED-BYTE 1) elements to offset? I think CLtL p288 makes it clear that the :DISPLACED-INDEX-OFFSET is in units of the array to which the displacement is being made. [Last paragraph: "It is required that the total size of A (the array being displaced to) be no smaller than the sum of the total size of B plus the offset n specified by the :DISPLACED-INDEX-OFFSET argument.] Note however it is presuming that the sizes of the "chunks" necessary to store elements from the two arrays is the same. re: III. Is it allowed to displace to a displaced array? Yes. re: IV. Bonus question: What about :displaced-index-offset to displaced arrays? This is trivial when you assume that all the underlying element sizes are the same. It only becomes an interesting question when they are different; and in this case, you are treading on waters of non-portability. I would think, however, that a simple relation can be derived by transitivity after you have established the constraints and relations between the two individual displacements: A displaced-to B ;figure out offsets etc B displaced-to C ;figure out offsets etc thus for the relation between A's units and C's, you should be able to cascade the two individual relations is some obvious way. -- JonL --  Received: from lcs.mit.edu (CHAOS 15044) by AI.AI.MIT.EDU 1 Nov 89 10:06:53 EST Received: from Sail.Stanford.EDU by mintaka.lcs.mit.edu id ad22819; 1 Nov 89 9:59 EST Received: from FRED.SLISP.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 1 Nov 89 06:50:01 PST Received: from fred.slisp.cs.cmu.edu by FRED.SLISP.CS.CMU.EDU id aa06347; 1 Nov 89 9:47:15 EST To: Stephen Nicoud cc: common-lisp@sail.stanford.edu Subject: Re: :DISPLACED-TO & :DISPLACED-INDEX-OFFSET. In-reply-to: Your message of Tue, 31 Oct 89 15:37:00 -0800. <19891031233708.3.SLN@SKAGIT.atc.boeing.com> Date: Wed, 01 Nov 89 09:46:19 EST From: Rob.MacLachlan@fred.slisp.cs.cmu.edu Message-ID: <8911010959.ad22819@mintaka.lcs.mit.edu> Although not clearly stated, "same type" has the normal interpretation in this context. (unsigned-byte 1) and (unsigned-byte 2) are not the same type, so you cannot displace between arrays with these types. Some implementations (such as the Lisp Machine) do allow such displacing, but I don't know the exect interpretation they give. In any case, a conforming Common Lisp program cannot do such displacing. Rob  Received: from lcs.mit.edu (CHAOS 15044) by AI.AI.MIT.EDU 31 Oct 89 20:17:55 EST Received: from Sail.Stanford.EDU by mintaka.lcs.mit.edu id ad02130; 31 Oct 89 20:07 EST Received: from atc.boeing.com ([130.42.28.80]) by SAIL.Stanford.EDU with TCP; 31 Oct 89 17:00:45 PST Received: by atc.boeing.com on Tue, 31 Oct 89 15:31:37 PST Date: Tue, 31 Oct 89 15:37 PST From: Stephen Nicoud Subject: :DISPLACED-TO & :DISPLACED-INDEX-OFFSET. To: common-lisp@sail.stanford.edu Message-Id: <19891031233708.3.SLN@SKAGIT.atc.boeing.com> Hello! I have some questions concerning the :DISPLACED-TO and :DISPLACED-INDEX-OFFSET options to MAKE-ARRAY for '(UNSIGNED-BYTE X) elements. I. Given the following forms: (setq A (make-array 4 :element-type '(unsigned-byte 1))) (setq B (make-array 2 :element-type '(unsigned-byte 2) :displaced-to A)) If the element types of A and B are not considered the same, CLtL (pg. 288) would seem to suggest B's MAKE-ARRAY call is an error, so ... Is B a valid array? Is the answer different if A were displaced to B? Are all '(UNSIGNED-BYTE X) arrays considered to be of the same 'array' type and thus 'displacable' to each other? II. If the element types are the same, and I specify the :DISPLACED-INDEX-OFFSET argument like this: (setq A (make-array 4 :element-type '(unsigned-byte 1))) (setq B (make-array 1 :element-type '(unsigned-byte 2) :displaced-to A :displaced-index-offset 1)) Does the :DISPLACED-INDEX-OFFSET refer to the number of '(UNSIGNED-BYTE 2) or '(UNSIGNED-BYTE 1) elements to offset? III. Is it allowed to displace to a displaced array? That is, is the following valid? (setq A (make-array 4 :element-type '(unsigned-byte 4))) (setq B (make-array 8 :element-type '(unsigned-byte 2) :displaced-to A)) (setq C (make-array 16 :element-type '(unsigned-byte 1) :displaced-to B)) IV. Bonus question: What about :displaced-index-offset to displaced arrays? Given: (setq A (make-array 4 :element-type '(unsigned-byte 4))) (setq B (make-array 4 :element-type '(unsigned-byte 2) :displaced-to A :displaced-index-offset 1)) (setq C (make-array 4 :element-type '(unsigned-byte 1) :displaced-to B :displaced-index-offset 1)) Does the :DISPLACED-INDEX-OFFSET for C refer to the number of A, B or C's :element-types to offset? Steve Nicoud snicoud@atc.boeing.com  Received: from lcs.mit.edu (CHAOS 15044) by AI.AI.MIT.EDU 30 Oct 89 16:18:11 EST Received: from Sail.Stanford.EDU by mintaka.lcs.mit.edu id ad09994; 30 Oct 89 16:12 EST Received: from WHITE.SWW.Symbolics.COM ([128.81.57.24]) by SAIL.Stanford.EDU with TCP; 30 Oct 89 13:05:03 PST Received: from CHROME.SWW.Symbolics.COM by WHITE.SWW.Symbolics.COM via CHAOS with CHAOS-MAIL id 28804; Mon 30-Oct-89 13:01:01 PST Date: Mon, 30 Oct 89 13:00 PST From: mArQ lE bRuN Subject: array-element-type = NIL To: jonl@lucid.com cc: common-lisp@sail.stanford.edu, maj@lucid.com, discuss-lisp@white.sww.symbolics.com In-Reply-To: <8910261912.AA11518@bhopal> Message-ID: <19891030210017.2.MLB@CHROME.SWW.Symbolics.COM> [this is my personal opinion and does not necessarily reflect those of my employers or colleagues] Date: Thu, 26 Oct 89 12:12:06 PDT From: Jon L White Is there any practical use for arrays with element type NIL? I know of no actual current uses of this specific thing. I can certainly make up some hypothetical ones for you, however. Such an array does have dimensions and can apparently have a fill-pointer and it can be displaced (albeit only to other type NIL arrays). Thus a number of array operators remain meaningful and error-free (even if potentially worthless) when given such an array. If only to allow simple and safe boundary conditions one might expect these to remain valid. A plausible use for such an object is as a placeholder for a "real" array. Everything in a program could pretty much "just work" (eg CHECK-TYPE) except operations which depended on the actual elements of the array (as opposed to its "arrayness"). In fact, I have for several years used similar (although differently implemented) placeholder arrays in some applications I maintain. These arrays are normally "displaced" to hardware at physical addresses on our system's bus. However saving a binary image of a Lisp containing such arrays to disk is dangerous, because the machine it is later booted on may have the hardware at a different place, or it may even be entirely absent, resulting in bus errors, system crashes and, worst of all, user bug reports. Therefore such arrays are tracked, and are automatically "invalidated" before saves by indirecting them to a placeholder array, which gets errors if accessed, but otherwise doesn't cause problems (actually I use zero length arrays, but the principle applies). Further, in extended Lisp systems built over CL, placeholder arrays may have additional uses. For example in Symbolics Lisp arrays are the substrate used for implementing structures. One could at least imagine using NIL type vectors in some (possibly degenerate) structures in some applications. (In my application I give the placeholders type symbols that try to help explain why they are invalid). Also, there may be more permissive versions of adjust-array or even just array indirection that would make NIL type array placeholders easier to use (eg if you are allowed to indirect to subtypes of your type, rather than to the exact same type, as in CLtL). Should it be an error to try to make such an array? No. Everything that isn't explicitly forbidden should be permitted. However I sympathize with implementations (including Symbolics') that punt by erroring on this, since if you allow such arrays you have to somehow be able to detect the invalid accesses to them that may happen later. But from a pure-language perspective I don't think it's right. Note that I'm not asking what (array :element-type NIL) should be upgraded to. Rather assume that you don't upgrade the element type and just keep it as NIL. Thus the array can't have any elements; even if it has a non-zero size, it still can't have any elements because no "element" can be of type NIL. "Upgrading" such an array would be a worse folly than erroring anyway. How many arrays can dance on the head of a . . . (Ask rather: how many pinheads can dance in arrays?) -- JonL --  Received: from lcs.mit.edu (CHAOS 15044) by AI.AI.MIT.EDU 27 Oct 89 20:17:30 EDT Received: from Sail.Stanford.EDU by mintaka.lcs.mit.edu id ad05338; 27 Oct 89 20:04 EDT Received: from Think.COM (Gateway.Think.COM) by SAIL.Stanford.EDU with TCP; 27 Oct 89 16:58:43 PDT Received: from Fafnir.Think.COM by Think.COM; Fri, 27 Oct 89 18:00:45 -0400 Return-Path: Received: from verdi.think.com by fafnir.think.com; Fri, 27 Oct 89 17:56:20 EDT Received: by verdi.think.com; Fri, 27 Oct 89 17:56:14 EDT Date: Fri, 27 Oct 89 17:56:14 EDT From: Guy Steele Message-Id: <8910272156.AA23107@verdi.think.com> To: jonl@lucid.com Cc: common-lisp@sail.stanford.edu, maj@lucid.com In-Reply-To: Jon L White's message of Thu, 26 Oct 89 12:12:06 PDT <8910261912.AA11518@bhopal> Subject: array-element-type = NIL Date: Thu, 26 Oct 89 12:12:06 PDT From: Jon L White Is there any practical use for arrays with element type NIL? Should it be an error to try to make such an array? Note that I'm not asking what (array :element-type NIL) should be upgraded to. Rather assume that you don't upgrade the element type and just keep it as NIL. Thus the array can't have any elements; even if it has a non-zero size, it still can't have any elements because no "element" can be of type NIL. How many arrays can dance on the head of a . . . A very interesting point indeed. Consider a similar question: does (DECLARE (TYPE NIL FOO)) mean that FOO never has a value? You can redundantly MAKUNBOUND it, but you can't do much else. If so, then I agree with your interpretation. But if that declaration is illegal, then I argue that an array whose element-type is NIL could still be meaningful but its total-size must be zero. A third position is that NIL is always an invalid element-type.  Received: from lcs.mit.edu (CHAOS 15044) by AI.AI.MIT.EDU 26 Oct 89 16:35:24 EDT Received: from Sail.Stanford.EDU by mintaka.lcs.mit.edu id ad06899; 26 Oct 89 16:22 EDT Received: from FRED.SLISP.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 26 Oct 89 13:17:13 PDT Received: from fred.slisp.cs.cmu.edu by FRED.SLISP.CS.CMU.EDU id aa01795; 26 Oct 89 16:15:01 EDT To: Jon L White cc: common-lisp@sail.stanford.edu, maj@lucid.com Subject: Re: array-element-type = NIL In-reply-to: Your message of Thu, 26 Oct 89 12:12:06 -0700. <8910261912.AA11518@bhopal> Date: Thu, 26 Oct 89 16:14:54 EDT From: Rob.MacLachlan@fred.slisp.cs.cmu.edu Message-ID: <8910261622.ad06899@mintaka.lcs.mit.edu> element-type = NIL doesn't seem very useful to me. You can't read them or write them, which are the interesting operations on arrays. But I don't think it should be an error to specify :element-type NIL, since MAKE-ARRAY can return a correct result even when NIL isn't a supported specialized element type. Since NIL is a subtype of every type, it could arbitrarily choose any element type. Rob  Received: from lcs.mit.edu (CHAOS 15044) by AI.AI.MIT.EDU 26 Oct 89 16:18:28 EDT Received: from Sail.Stanford.EDU by mintaka.lcs.mit.edu id ad01351; 26 Oct 89 16:08 EDT Received: from Think.COM (Gateway.Think.COM) by SAIL.Stanford.EDU with TCP; 26 Oct 89 13:01:23 PDT Return-Path: Received: from Occam.Think.COM by Think.COM; Thu, 26 Oct 89 16:02:06 -0400 Date: Thu, 26 Oct 89 15:57 EDT From: Barry Margolin Subject: array-element-type = NIL To: Jon L White Cc: common-lisp@sail.stanford.edu, maj@lucid.com In-Reply-To: <8910261912.AA11518@bhopal> Message-Id: <19891026195730.1.BARMAR@OCCAM.THINK.COM> Character-Type-Mappings: (1 0 (NIL 0) (:FIX :ROMAN :NORMAL) "CPTFONT") Fonts: CPTFONT, CPTFONT Date: Thu, 26 Oct 89 12:12:06 PDT From: Jon L White Is there any practical use for arrays with element type NIL? Should it be an error to try to make such an array? Genera signals an error: "1Attempt to make an array with :ELEMENT-TYPE NIL, probably an error0". However, it doesn't detect the error when the element type is something like (AND INTEGER FLOAT); it creates a type T array. Note that I'm not asking what (array :element-type NIL) should be upgraded to. Rather assume that you don't upgrade the element type and just keep it as NIL. Thus the array can't have any elements; even if it has a non-zero size, it still can't have any elements because no "element" can be of type NIL. Well, for that matter, what good is the type specifier NIL at all? You can't declare a variable of that type, you can't declare a function returning that type. The only thing you can do with the NIL type specifier is use it in TYPEP (for all x, (typep x nil) is NIL), SUBTYPEP (for all type specifiers x (subtypep nil x) => T and (subtypep x nil) => NIL), and building type specifiers using boolean operations. I'd say that it should be implementation-dependent. If (array-upgraded-element-type nil) returns something non-NIL, then it is equivalent to specifying the upgraded type; if it returns NIL, then MAKE-ARRAY must signal an error. barmar  Received: from lcs.mit.edu (CHAOS 15044) by AI.AI.MIT.EDU 26 Oct 89 15:27:57 EDT Received: from Sail.Stanford.EDU by mintaka.lcs.mit.edu id ad25012; 26 Oct 89 15:19 EDT Received: from lucid.com by SAIL.Stanford.EDU with TCP; 26 Oct 89 12:13:22 PDT Received: from bhopal ([192.43.178.13]) by heavens-gate id AA28264g; Thu, 26 Oct 89 12:10:25 PDT Received: by bhopal id AA11518g; Thu, 26 Oct 89 12:12:06 PDT Date: Thu, 26 Oct 89 12:12:06 PDT From: Jon L White Message-Id: <8910261912.AA11518@bhopal> To: common-lisp@sail.stanford.edu Cc: maj@lucid.com Subject: array-element-type = NIL Is there any practical use for arrays with element type NIL? Should it be an error to try to make such an array? Note that I'm not asking what (array :element-type NIL) should be upgraded to. Rather assume that you don't upgrade the element type and just keep it as NIL. Thus the array can't have any elements; even if it has a non-zero size, it still can't have any elements because no "element" can be of type NIL. How many arrays can dance on the head of a . . . -- JonL --  Received: from lcs.mit.edu (CHAOS 15044) by AI.AI.MIT.EDU 5 Sep 89 20:11:14 EDT Received: from Sail.Stanford.EDU by mintaka.lcs.mit.edu id ad12769; 5 Sep 89 20:03 EDT Received: from helen.Berkeley.EDU by SAIL.Stanford.EDU with TCP; 5 Sep 89 16:56:35 PDT Received: by helen.Berkeley.EDU (5.57/1.25) id AA13170; Tue, 5 Sep 89 16:57:01 PDT Date: Tue, 5 Sep 89 16:57:01 PDT From: Kinson Ho Message-Id: <8909052357.AA13170@helen.Berkeley.EDU> To: common-lisp@sail.stanford.edu Subject: Request for Lisp Applications Cc: ho@ginger.berkeley.edu I am looking for a number of meduim size, sequential Common Lisp programs for porting to Multiprocessing Spur Lisp. Spur Lisp is a dialect of Common Lisp with extensions for programming on shared memory multiprocessors. The programs will be used in my study of high level primitives for multiprocessing based on Spur Lisp. They should be "real" applications that are reasonably well written (and documented). All kinds of Lisp applications are welcome. Typical examples include compilers, simulators (of all kinds), theorem provers, expert systems, symbolic algebra systems, heuristic search, graph algorithms and CAD programs. With the permission of the authors, and subject to disk space constraints, I may make these programs available for public ftp. Such a collection of Lisp programs may serve as a common baseline for groups developing parallel Lisp systems. If you have a program that may benefit from a parallel implementation, or know of anyone who does, please send me electronic mail. Thanks in advance. Kinson Ho (ho@ginger.Berkeley.EDU) Computer Science Division University of California, Berkeley  Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by AI.AI.MIT.EDU 28 Aug 89 17:42:19 EDT Received: from AI.MIT.EDU by REAGAN.AI.MIT.EDU via INTERNET with SMTP id 255132; 28 Aug 89 15:30:18 EDT Received: from reagan.ai.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AB04878; Mon, 28 Aug 89 13:21:44 EDT Received: from Think.COM (Gateway.Think.COM) by SAIL.Stanford.EDU with TCP; 28 Aug 89 09:45:31 PDT Received: from fafnir.think.com by Think.COM; Mon, 28 Aug 89 12:46:26 EDT Return-Path: Received: from verdi.think.com by fafnir.think.com; Mon, 28 Aug 89 12:43:39 EDT Received: by verdi.think.com; Mon, 28 Aug 89 12:43:24 EDT Date: Mon, 28 Aug 89 12:43:24 EDT From: gls@think.com (Guy Steele) Message-Id: <8908281643.AA09641@verdi.think.com> To: jeff%aiai.edinburgh.ac.uk@nsfnet-relay.ac.uk Cc: barmar@think.com, Martin%ai-sun.jpl.nasa.gov@nsfnet-relay.ac.uk, common-lisp@sail.stanford.edu In-Reply-To: Jeff Dalton's message of Mon, 28 Aug 89 17:24:10 BST <16958.8908281624@aiai.ed.ac.uk> Subject: Porting Scheme to Common Lisp Date: Mon, 28 Aug 89 17:24:10 BST From: Jeff Dalton > About the only thing Scheme has that would be difficult to reproduce in > Common Lisp is its first-class continuations, and various constructs > built on them. Another problem may be that Scheme guarantees that tail-recursion will be optimized, which may not happen in Common Lisp. Let us say, rather, that Scheme, unlike Common Lisp, is forbidden to pessimize tail-recursion. --Guy  Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by AI.AI.MIT.EDU 28 Aug 89 17:42:07 EDT Received: from AI.MIT.EDU by REAGAN.AI.MIT.EDU via INTERNET with SMTP id 255131; 28 Aug 89 15:29:47 EDT Received: from SAIL.Stanford.EDU by life.ai.mit.edu (4.1/AI-4.10) id AA04878; Mon, 28 Aug 89 13:21:36 EDT Received: from NSFnet-Relay.AC.UK by SAIL.Stanford.EDU with TCP; 28 Aug 89 09:28:07 PDT Received: from aiai.edinburgh.ac.uk by NSFnet-Relay.AC.UK via Janet with NIFTP id aa07303; 28 Aug 89 17:18 BST Date: Mon, 28 Aug 89 17:24:10 BST Message-Id: <16958.8908281624@aiai.ed.ac.uk> From: Jeff Dalton Subject: Re: Porting Scheme to Common Lisp To: Barry Margolin , Gaius Martin In-Reply-To: Barry Margolin's message of Fri, 25 Aug 89 15:48 EDT Cc: common-lisp@sail.stanford.edu > About the only thing Scheme has that would be difficult to reproduce in > Common Lisp is its first-class continuations, and various constructs > built on them. Another problem may be that Scheme guarantees that tail-recursion will be optimized, which may not happen in Common Lisp.  Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by AI.AI.MIT.EDU 25 Aug 89 20:23:01 EDT Received: from SAIL.STANFORD.EDU by REAGAN.AI.MIT.EDU via INTERNET with SMTP id 254622; 25 Aug 89 20:12:33 EDT Received: from Think.COM (Gateway.Think.COM) by SAIL.Stanford.EDU with TCP; 25 Aug 89 17:03:01 PDT Return-Path: Received: from OCCAM.THINK.COM by Think.COM; Fri, 25 Aug 89 20:04:29 EDT Date: Fri, 25 Aug 89 20:01 EDT From: Barry Margolin Subject: Re: Porting Scheme to Common Lisp To: Dan L. Pierson Cc: Gaius Martin , common-lisp@sail.stanford.edu In-Reply-To: <8908252040.AA01505@mist.> Message-Id: <19890826000141.4.BARMAR@OCCAM.THINK.COM> Date: Fri, 25 Aug 89 16:40:23 EDT From: Dan L. Pierson However, in many Scheme systems you could define some macros and read-macros to let the above style be accepted. This would simplify later rewriting at the cost of outranging the aesthetic sensibilities of any local Scheme programmers. True, but irrelevant. The original question was about converting code written by a Scheme programmer. He's not likely to want to use a bunch of macros that make his code look like CL. If he were willing to write code with #' and FUNCALL, he might as well use CL rather than Scheme. barmar  Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by AI.AI.MIT.EDU 25 Aug 89 18:30:18 EDT Received: from AI.MIT.EDU by REAGAN.AI.MIT.EDU via INTERNET with SMTP id 254315; 25 Aug 89 18:12:05 EDT Received: from SAIL.Stanford.EDU by life.ai.mit.edu (4.1/AI-4.10) id AA08114; Fri, 25 Aug 89 17:37:03 EDT Received: from multimax.encore.com by SAIL.Stanford.EDU with TCP; 25 Aug 89 13:42:44 PDT Received: from mist.encore.COM by multimax.encore.com with SMTP (5.61/25-eef) id AA16147; Fri, 25 Aug 89 16:46:25 -0400 Received: from localhost by mist. (4.0/SMI-4.0) id AA01505; Fri, 25 Aug 89 16:40:26 EDT Message-Id: <8908252040.AA01505@mist.> To: Gaius Martin Cc: common-lisp@sail.stanford.edu Subject: Re: Porting Scheme to Common Lisp In-Reply-To: Your message of Fri, 25 Aug 89 15:48:00 -0400. <19890825194808.3.BARMAR@OCCAM.THINK.COM> Date: Fri, 25 Aug 89 16:40:23 EDT From: Dan L. Pierson On Fri, 25 Aug 89 15:48 EDT, Barry Margolin said: > The other noticeable difference between Scheme and CL is the way > function-valued expressions are used. ... > instead of the more Lispy: > (flet ((foo (x) (+ x x))) > ... > (another-fun #'foo) > (foo bar)) However, in many Scheme systems you could define some macros and read-macros to let the above style be accepted. This would simplify later rewriting at the cost of outranging the aesthetic sensibilities of any local Scheme programmers. However, there is another aspect of the feature of Scheme that you should be aware of. In Common Lisp a variable has two values: its value and its function (and its property list...). In Scheme a variable only has a single value. This means that Common Lisp code such as the following will not work as expected in Scheme: (defun foo (list bar) (let ((a (cadr list))) (list a bar))) This shouldn't cause you too much trouble, since the danger is in translating Common Lisp to Scheme, but you should be aware of it.  Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by AI.AI.MIT.EDU 25 Aug 89 16:00:10 EDT Received: from SAIL.Stanford.EDU (INTERNET|36.86.0.194) by REAGAN.AI.MIT.EDU via INTERNET with SMTP id 254140; 25 Aug 89 15:59:00 EDT Received: from Think.COM (Gateway.Think.COM) by SAIL.Stanford.EDU with TCP; 25 Aug 89 12:49:45 PDT Return-Path: Received: from OCCAM.THINK.COM by Think.COM; Fri, 25 Aug 89 15:50:52 EDT Date: Fri, 25 Aug 89 15:48 EDT From: Barry Margolin Subject: Porting Scheme to Common Lisp To: Gaius Martin Cc: common-lisp@sail.stanford.edu In-Reply-To: <19890825184517.1.MARTIN@AI-NEPTUNE.jpl.nasa.gov> Message-Id: <19890825194808.3.BARMAR@OCCAM.THINK.COM> Date: Fri, 25 Aug 89 11:45 PDT From: Gaius Martin We have a programmer here who wants to do some prototyping in Scheme. We will eventually have to move the code to Common Lisp. I know nothing about Scheme, so I do not know where it differs from Common Lisp. I am looking for information and references to articles or books that compare Scheme and Common Lisp. If anyone has done this port of Scheme to Common Lisp before, I would like to hear of any lessons learned and any difficulties that were encountered along the way. About the only thing Scheme has that would be difficult to reproduce in Common Lisp is its first-class continuations, and various constructs built on them. So, most programs that use CALL-WITH-CURRENT-CONTINUATION (aka CALL/CC) will be difficult to port to CL. In Scheme, the equivalents of BLOCK, CATCH, and UNWIND-PROTECT are constructed using CALL/CC, and they are much more flexible than the CL versions; in particular, they have indefinite extent, so you can return from once of these constructs more than once in Scheme, while CL only allows you to return once. The other noticeable difference between Scheme and CL is the way function-valued expressions are used. In CL you must write (funcall ), but in Scheme you just write ( ). And when functions named, CL requires you to use FLET to bind local names and (FUNCTION ) to reference functions by name, to indicate that the function namespace should be used, while Scheme only has one namespace and therefore uses ordinary LET and variable referencing. It may be possible to transform such code from Scheme to CL automatically, but the result probably won't be pretty, containing lots of extraneous LAMBDAs and FUNCALLs; for instance, the code: (let ((foo (lambda (x) (+ x x)))) ... (another-fun foo) (foo bar)) would be translated (by a simplistic algorithm) to: (let ((foo #'(lambda (x) (+ x x)))) ... (another-fun foo) (funcall foo bar)) instead of the more Lispy: (flet ((foo (x) (+ x x))) ... (another-fun #'foo) (foo bar))  Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by AI.AI.MIT.EDU 25 Aug 89 15:32:06 EDT Received: from SAIL.Stanford.EDU (INTERNET|36.86.0.194) by REAGAN.AI.MIT.EDU via INTERNET with SMTP id 254119; 25 Aug 89 15:31:03 EDT Received: from AI-SUN.jpl.nasa.gov by SAIL.Stanford.EDU with TCP; 25 Aug 89 12:19:02 PDT Received: from AI-NEPTUNE.jpl.nasa.gov by AI-SUN.jpl.nasa.gov via CHAOS with CHAOS-MAIL id 22175; Fri 25-Aug-89 11:45:25 PDT Date: Fri, 25 Aug 89 11:45 PDT From: Gaius Martin Subject: Porting Scheme to Common Lisp To: common-lisp@sail.stanford.edu cc: Martin@AI-SUN.jpl.nasa.gov Message-ID: <19890825184517.1.MARTIN@AI-NEPTUNE.jpl.nasa.gov> We have a programmer here who wants to do some prototyping in Scheme. We will eventually have to move the code to Common Lisp. I know nothing about Scheme, so I do not know where it differs from Common Lisp. I am looking for information and references to articles or books that compare Scheme and Common Lisp. If anyone has done this port of Scheme to Common Lisp before, I would like to hear of any lessons learned and any difficulties that were encountered along the way. Thanks for any comments and help, Gaius  Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by AI.AI.MIT.EDU 22 Aug 89 16:14:37 EDT Received: from SAIL.STANFORD.EDU by REAGAN.AI.MIT.EDU via INTERNET with SMTP id 252656; 22 Aug 89 16:14:21 EDT Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 22 Aug 89 12:55:49 PDT Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 645529; 22 Aug 89 15:57:30 EDT Date: Tue, 22 Aug 89 15:57 EDT From: Kent M Pitman Subject: Condition sensitive resarts (or the lack thereof). To: moose@Think.COM cc: Common-Lisp@SAIL.Stanford.EDU In-Reply-To: <8908220514.AA09126@odin.think.com>, <8908220503.AA09031@odin.think.com> Message-ID: <19890822195727.6.KMP@BOBOLINK.SCRC.Symbolics.COM> Date: Tue, 22 Aug 89 01:03:25 EDT From: moose@Think.COM ... Given a something like a restart-case construct, I would like to make the dynamically available restarts depend on the type/class of the condition signalled. That is, if an arithmetic-error condition is signalled, I would like to have one group of restarts active. ... I believe the new :TEST option in RESTART-CASE or :TEST-FUNCTION option in RESTART-BIND (see item #7 of proposal CONDITION-RESTARTS, version 2) is exactly what you are looking for. e.g., (RESTART-CASE (ERROR SOME-CONDITION-OR-OTHER) (FIX-ARITHMETIC-1 () :TEST (LAMBDA (CONDITION) (TYPEP CONDITION 'ARITHMETIC-ERROR)) ...) (FIX-ARITHMETIC-2 () :TEST (LAMBDA (CONDITION) (TYPEP CONDITION 'ARITHMETIC-ERROR)) ...) (FIX-CONTROL-1 () :TEST (LAMBDA (CONDITION) (TYPEP CONDITION 'CONTROL-ERROR)) ...)) If this isn't enough to take care of your needs, please respond to me privately saying why and maybe we can come up with something that is. -kmp  Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by AI.AI.MIT.EDU 22 Aug 89 01:24:16 EDT Received: from SAIL.STANFORD.EDU by REAGAN.AI.MIT.EDU via INTERNET with SMTP id 252458; 22 Aug 89 01:24:12 EDT Received: from Think.COM (Gateway.Think.COM) by SAIL.Stanford.EDU with TCP; 21 Aug 89 22:16:10 PDT Return-Path: Received: from odin.think.com by Think.COM; Tue, 22 Aug 89 01:17:46 EDT Received: by odin.think.com; Tue, 22 Aug 89 01:14:07 EDT Date: Tue, 22 Aug 89 01:14:07 EDT From: moose@Think.COM Message-Id: <8908220514.AA09126@odin.think.com> To: common-lisp@sail.stanford.edu Subject: Correction to my previous question. I inadvertently cited an imaginary feature of Zetalisp. With-proceed-cases is a local construct. It is built on the Zetalisp catch-error-restart facility. Apologies: moose  Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by AI.AI.MIT.EDU 22 Aug 89 01:13:58 EDT Received: from SAIL.STANFORD.EDU by REAGAN.AI.MIT.EDU via INTERNET with SMTP id 252450; 22 Aug 89 01:13:49 EDT Received: from Think.COM (Gateway.Think.COM) by SAIL.Stanford.EDU with TCP; 21 Aug 89 22:05:32 PDT Return-Path: Received: from odin.think.com by Think.COM; Tue, 22 Aug 89 01:07:05 EDT Received: by odin.think.com; Tue, 22 Aug 89 01:03:25 EDT Date: Tue, 22 Aug 89 01:03:25 EDT From: moose@Think.COM Message-Id: <8908220503.AA09031@odin.think.com> To: common-lisp@sail.stanford.edu Subject: Condition sensitive resarts (or the lack thereof). In reading the Condition System Revision #18 document (KMP 12 Mar 88), I am surprised to find that the proposed (adopted?) standard does not make any provision for associating restarts with specific conditions. I don't believe that this is the same concern as that voiced in CONDITION-RESTARTS change (passed by X3j13 in June '88). My complaint is: Given a something like a restart-case construct, I would like to make the dynamically available restarts depend on the type/class of the condition signalled. That is, if an arithmetic-error condition is signalled, I would like to have one group of restarts active. If an illegal-throw is signalled, I might like to have a different set of restarts available. I have in mind the Zetalisp (Symbolics) with-proceed-cases construct. I am at a loss as to how to build this from the available handler/restart constructs which are described in the documents mentioned above. Any suggestions will be appreciated. Many thanks: moose Adam Greenberg Thinking Machines Corporation moose@think.com  Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by AI.AI.MIT.EDU 20 Jul 89 10:06:18 EDT Received: from SAIL.STANFORD.EDU by REAGAN.AI.MIT.EDU via INTERNET with SMTP id 238477; 20 Jul 89 10:05:04 EDT Received: from RELAY.CS.NET by SAIL.Stanford.EDU with TCP; 20 Jul 89 06:56:16 PDT Received: from relay2.cs.net by RELAY.CS.NET id aa00725; 20 Jul 89 9:55 EDT Received: from draper.com by RELAY.CS.NET id aa00437; 20 Jul 89 9:49 EDT Date: Thu, 20 Jul 89 07:21 EDT From: "Steve Bacher (Batchman)" Subject: Re: sun commonlisp 3.0.2 and in-package To: jeff%aiai.edinburgh.ac.uk@NSFNET-RELAY.AC.UK, common-lisp@SAIL.STANFORD.EDU, pierson%mist.encore.com@NSFNET-RELAY.AC.UK X-VMS-To: IN%"jeff%aiai.edinburgh.ac.uk@nsfnet-relay.ac.uk" >>> Not to worry. The Common Lisp gang is going to get rid of >>> PROVIDE/REQUIRE anyhow, since most of them think it's useless >>> and/or nonportable. > >Do I detect a trace of bitterness here? Au contraire. Having never implemented PROVIDE or REQUIRE, I would be just as glad to see them disappear. :-)  Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by AI.AI.MIT.EDU 19 Jul 89 22:33:11 EDT Received: from SAIL.STANFORD.EDU by REAGAN.AI.MIT.EDU via INTERNET with SMTP id 238340; 19 Jul 89 22:31:08 EDT Received: from lucid.com by SAIL.Stanford.EDU with TCP; 19 Jul 89 19:21:40 PDT Received: from bhopal ([192.43.178.13]) by heavens-gate id AA01478g; Wed, 19 Jul 89 19:19:06 PDT Received: by bhopal id AA28414g; Wed, 19 Jul 89 19:21:16 PDT Date: Wed, 19 Jul 89 19:21:16 PDT From: Jon L White Message-Id: <8907200221.AA28414@bhopal> To: stanonik@nprdc.navy.mil Cc: common-lisp@sail.stanford.edu In-Reply-To: Jon L White's message of Tue, 18 Jul 89 23:16:32 PDT <8907190616.AA26340@bhopal> Subject: sun commonlisp 3.0.2 and in-package re: [JonL:] There should be documentation with Sun Common Lisp release 3.0.2 which suggests overriding the order of the "7 extremely randoms" recommended in CLtL, and placing the PROVIDE statement last in the file; then, an IN-PACKAGE statement can always be first in the file. I'm going to have to emmend my comment here. Not all 3.0-level releases from Lucid seem to have the same documentation with them. In particular, the Sun3/3.0 release doesn't have the stylistic suggestions re PROVIDE and REQUIRE, although several others do [I think someone added the "warning" code after the first set of documentations was prepeared, but before the final Sun3 image shipment?] If you would like these extra pages, just let me know and I'm sure I can find some way to send them to you, either electronically or by hardcopy. As I mentioned before, I think PROVIDE/REQUIRE have a justifiable use outside of the aborted defsystem debate. If that is not the issue, but the "warning" is, then you should complain to Sun customer support about it (or, about the lack of documentation on how to turn it off?). In a world without PROVIDE/REQUIRE, it _certainly_ is better style to put an IN-PACKAGE as the first form in a file; this will be the case in the proposed ANSI Common Lisp, and is an issue independent of DEFPACKAGE. -- JonL --  Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by AI.AI.MIT.EDU 19 Jul 89 18:07:08 EDT Received: from SAIL.STANFORD.EDU by REAGAN.AI.MIT.EDU via INTERNET with SMTP id 238218; 19 Jul 89 18:06:04 EDT Received: from PHOENIX.SCH.Symbolics.COM ([128.81.38.192]) by SAIL.Stanford.EDU with TCP; 19 Jul 89 14:57:51 PDT Received: from FARRAGUT.SCH.Symbolics.COM by PHOENIX.SCH.Symbolics.COM via CHAOS with CHAOS-MAIL id 90095; Wed 19-Jul-89 14:56:37 PDT Date: Wed, 19 Jul 89 14:56 PDT From: barmar@THINK.COM Subject: exit extent (formerly nonlocal exit from unwind-protect) To: Don Cohen cc: common-lisp@sail.stanford.edu In-Reply-To: <8907180014.AA03478@vaxa.isi.edu> Message-ID: <19890719215656.4.BARMAR@FARRAGUT.SCH.Symbolics.COM> Date: Mon, 17 Jul 89 17:14:29 PDT From: Don Cohen Is there any way known under the "minimal" proposal to write an un-exitable loop? Of course, whether that's a good thing to be able to do is another question. No, there isn't. If something does a THROW, RETURN-FROM, or GO to a target outside the loop then any targets used by the loop are disestablished as soon as the transfer begins.  Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by AI.AI.MIT.EDU 19 Jul 89 14:58:43 EDT Received: from SAIL.STANFORD.EDU by REAGAN.AI.MIT.EDU via INTERNET with SMTP id 238086; 19 Jul 89 14:57:38 EDT Received: from multimax.encore.com by SAIL.Stanford.EDU with TCP; 19 Jul 89 11:49:00 PDT Received: from mist.encore.COM by multimax.encore.com with SMTP (5.61/25-eef) id AA14911; Wed, 19 Jul 89 14:52:09 -0400 Received: from localhost by mist. (4.0/SMI-4.0) id AA06869; Wed, 19 Jul 89 14:47:43 EDT Message-Id: <8907191847.AA06869@mist.> To: Jeff Dalton <"jeff%aiai.edinburgh.ac.uk@NSFnet-Relay.AC.UK"@multimax.encore.com> Cc: common-lisp@sail.stanford.edu Subject: Re: sun commonlisp 3.0.2 and in-package In-Reply-To: Your message of Wed, 19 Jul 89 19:05:33 -0000. <2768.8907191805@aiai.ed.ac.uk> Date: Wed, 19 Jul 89 14:47:40 EDT From: Dan L. Pierson Date: Wed, 19 Jul 89 19:05:33 BST From: Jeff Dalton Maybe I wasn't paying attention, because I would have voted against allowing only a string. As far as I can tell, (in-package :foo) is more portable than (in-package "FOO") because it works even if someone has changed the internal case to lower case (which is possible in some implementations). However, (use-package 'foo) can lead to problems, because it may create a symbol, FOO, which may turn out to have been a mistake. All of this was discussed, but not included in the infinite (and rather bizare) rehashes and revotes on the original motion. You are of course right that :foo is safer than 'foo. I believe that the final motion only requires the new IN-PACKAGE to accept a string. There was a great deal of agreement with the concept that the IN-PACKAGE macro could be written so as to accept any of: a string, a quote symbol, or an unquoted symbol (note that the macro does not evaluate its argument). If a symbol is supplied, the macro could expand into code that takes the SYMBOL-NAME of the symbol and uses that string. It was expected that this transformation would happen at compile time in files to be compiled. The treatment of keyword and non-keyword symbols would presumably be identical. Note that the preceding paragraph is not part of the standard. I don't recall anyone every proposing that we require this behavior and some people were not convinced that it would work all that well. In particular, it does nothing to help loading source files.  Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by AI.AI.MIT.EDU 19 Jul 89 14:37:22 EDT Received: from SAIL.STANFORD.EDU by REAGAN.AI.MIT.EDU via INTERNET with SMTP id 238073; 19 Jul 89 14:36:21 EDT Received: from NSFnet-Relay.AC.UK by SAIL.Stanford.EDU with TCP; 19 Jul 89 11:25:03 PDT Received: from aiai.edinburgh.ac.uk by NSFnet-Relay.AC.UK via Janet with NIFTP id aa08878; 19 Jul 89 18:49 BST Date: Wed, 19 Jul 89 19:05:33 BST Message-Id: <2768.8907191805@aiai.ed.ac.uk> From: Jeff Dalton Subject: Re: sun commonlisp 3.0.2 and in-package To: "Dan L. Pierson" , "Steve Bacher (Batchman)" <@uunet.uu.net:SEB1525@ccfvx3.draper.com> In-Reply-To: Dan L. Pierson's message of Wed, 19 Jul 89 11:01:37 EDT Cc: common-lisp@sail.stanford.edu >> Not to worry. The Common Lisp gang is going to get rid of >> PROVIDE/REQUIRE anyhow, since most of them think it's useless >> and/or nonportable. Do I detect a trace of bitterness here? > IN-PACKAGE has been changed to a macro that only takes a single > argument which is a constant string. It is anticipated (but > neither stated nor required) that many implementations will make > the macro transform (IN-PACKAGE 'foo) to (IN-PACKAGE "FOO") > automatically. Maybe I wasn't paying attention, because I would have voted against allowing only a string. As far as I can tell, (in-package :foo) is more portable than (in-package "FOO") because it works even if someone has changed the internal case to lower case (which is possible in some implementations). However, (use-package 'foo) can lead to problems, because it may create a symbol, FOO, which may turn out to have been a mistake. For example, suppose I write a file that looks like this: (in-package "MATCH") (export '(match match-case)) Now suppose someone writes (use-package 'match) A name conflict will most likely result, because the call to USE-PACKAGE will create an internal symbol MATCH in the using package, and that symbol will conflict with MATCH:MATCH. -- Jeff  Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by AI.AI.MIT.EDU 19 Jul 89 14:30:43 EDT Received: from SAIL.STANFORD.EDU by REAGAN.AI.MIT.EDU via INTERNET with SMTP id 238062; 19 Jul 89 14:29:44 EDT Received: from multimax.encore.com by SAIL.Stanford.EDU with TCP; 19 Jul 89 11:22:41 PDT Received: from mist.encore.COM by multimax.encore.com with SMTP (5.61/25-eef) id AA14465; Wed, 19 Jul 89 14:25:47 -0400 Received: from localhost by mist. (4.0/SMI-4.0) id AA06766; Wed, 19 Jul 89 14:21:21 EDT Message-Id: <8907191821.AA06766@mist.> To: "Steve Bacher (Batchman)" Cc: common-lisp@SAIL.STANFORD.EDU Subject: Re: sun commonlisp 3.0.2 and in-package In-Reply-To: Your message of Wed, 19 Jul 89 12:34:00 -0400. <8907191821.AA14393@multimax.encore.com> Date: Wed, 19 Jul 89 14:21:19 EDT From: Dan L. Pierson X3J13 has voted to include DEFPACKAGE in the draft standard. I should note here that all X3J13 votes are subject to change at a later meeting. It's not the draft standard until we send it out, etc. However, DEFPACKAGE has a lot of support and little, if any, opposition, so I personally expect it to be in the standard.  Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by AI.AI.MIT.EDU 19 Jul 89 14:16:02 EDT Received: from SAIL.STANFORD.EDU by REAGAN.AI.MIT.EDU via INTERNET with SMTP id 238049; 19 Jul 89 14:15:01 EDT Received: from RELAY.CS.NET by SAIL.Stanford.EDU with TCP; 19 Jul 89 11:07:39 PDT Received: from relay2.cs.net by RELAY.CS.NET id ac21059; 19 Jul 89 14:08 EDT Received: from draper.com by RELAY.CS.NET id ab25037; 19 Jul 89 14:06 EDT Date: Wed, 19 Jul 89 12:34 EDT From: "Steve Bacher (Batchman)" Subject: Re: sun commonlisp 3.0.2 and in-package To: pierson@mist.encore.com, common-lisp@SAIL.STANFORD.EDU X-VMS-To: IN%"pierson@mist.encore.com" Thanks for clarifications re PROVIDE/REQUIRE and IN-PACKAGE. Now, what about DEFPACKAGE? Is that going to be reality? It's certainly preferable in form to IN-PACKAGE, and less likely to cause breakage (since nobody is currently using it).  Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by AI.AI.MIT.EDU 19 Jul 89 11:14:50 EDT Received: from SAIL.STANFORD.EDU by REAGAN.AI.MIT.EDU via INTERNET with SMTP id 237960; 19 Jul 89 11:13:47 EDT Received: from multimax.encore.com by SAIL.Stanford.EDU with TCP; 19 Jul 89 08:02:58 PDT Received: from mist.encore.COM by multimax.encore.com with SMTP (5.61/25-eef) id AA08306; Wed, 19 Jul 89 11:06:06 -0400 Received: from localhost by mist. (4.0/SMI-4.0) id AA06548; Wed, 19 Jul 89 11:01:40 EDT Message-Id: <8907191501.AA06548@mist.> To: "Steve Bacher (Batchman)" Cc: common-lisp@SAIL.STANFORD.EDU Subject: Re: sun commonlisp 3.0.2 and in-package In-Reply-To: Your message of Wed, 19 Jul 89 08:13:00 -0400. <8907191414.AA07817@multimax.encore.com> Date: Wed, 19 Jul 89 11:01:37 EDT From: Dan L. Pierson Not to worry. The Common Lisp gang is going to get rid of PROVIDE/REQUIRE anyhow, since most of them think it's useless and/or nonportable. It looks like IN-PACKAGE may be redefined, if not discarded, as well. Watch for a DEFPACKAGE macro in the next edition of CL. Close, but not quite. The current vote status is: Delete PROVIDE/REQUIRE. This is an extremely controversial compromise position (which I wrote). The basic argument is: 1. The file loading behavior of REQUIRE is non-portable. Everyone seems to agree with this. 2. In particular, a user of REQUIRE on a system which supports useful automatic file loading (e.g. DEFSYSTEM invocation), will very likely be unpleasantly surprised when trying to move a large application developed on such a system to a system where REQUIRE doesn't autoload files. The problem is that REQUIRE can't simply be used as a safety net if it loads the file instead of complaining. This argument is not universally accepted. 3. Many people feel that restricting PROVIDE and REQUIRE to trivial safety net functionality reduces them to functions that a user can trivially write. This is obviously true, but it certainly hasn't been uniformly applied as a reason to keep things out of Common Lisp. 4. Many implementors who do provide a REQUIRE that loads files objected strenuously to any attempt to make their current functionality illegal. This sort of objection carries a good deal of weight in X3J13 because their user base would really be hurt by the change. 5. Deleting PROVIDE/REQUIRE permits all implementations to continue offering their current functionality while making it clear to users that these functions are NOT portable and should be avoided in portable code. The only required change is that the symbols must now appear in a package other than COMMON-LISP. IN-PACKAGE has been changed to a macro that only takes a single argument which is a constant string. It is anticipated (but neither stated nor required) that many implementations will make the macro transform (IN-PACKAGE 'foo) to (IN-PACKAGE "FOO") automatically. This was done because the second argument to the current IN-PACKAGE is a dangerous booby trap (ask JonL for more details) and because X3J13 is trying to move to a clearer model of compiler processing. Part of the compiler model effort is a drive to minimize or eliminate the magic special compiler handling of forms such as the "seven extremely random"s. Personally, I think that the lack of a standard DEFSYSTEM is one of our biggest failures in this round of the Common Lisp standards effort. The isssue was controversial and might not have passed. None the less, several of us are guilty of not writing up a proposal and trying to get it through.  Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by AI.AI.MIT.EDU 19 Jul 89 09:49:19 EDT Received: from SAIL.STANFORD.EDU by REAGAN.AI.MIT.EDU via INTERNET with SMTP id 237897; 19 Jul 89 09:47:48 EDT Received: from RELAY.CS.NET by SAIL.Stanford.EDU with TCP; 19 Jul 89 06:36:13 PDT Received: from relay2.cs.net by RELAY.CS.NET id aw14411; 19 Jul 89 9:35 EDT Received: from draper.com by RELAY.CS.NET id ab21937; 19 Jul 89 9:31 EDT Date: Wed, 19 Jul 89 08:13 EDT From: "Steve Bacher (Batchman)" Subject: Re: sun commonlisp 3.0.2 and in-package To: common-lisp@SAIL.STANFORD.EDU X-VMS-To: COMMON-LISP Not to worry. The Common Lisp gang is going to get rid of PROVIDE/REQUIRE anyhow, since most of them think it's useless and/or nonportable. It looks like IN-PACKAGE may be redefined, if not discarded, as well. Watch for a DEFPACKAGE macro in the next edition of CL.  Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by AI.AI.MIT.EDU 19 Jul 89 02:27:23 EDT Received: from SAIL.STANFORD.EDU by REAGAN.AI.MIT.EDU via INTERNET with SMTP id 237808; 19 Jul 89 02:26:12 EDT Received: from lucid.com by SAIL.Stanford.EDU with TCP; 18 Jul 89 23:17:21 PDT Received: from bhopal ([192.43.178.13]) by heavens-gate id AA17350g; Tue, 18 Jul 89 23:14:40 PDT Received: by bhopal id AA26340g; Tue, 18 Jul 89 23:16:32 PDT Date: Tue, 18 Jul 89 23:16:32 PDT From: Jon L White Message-Id: <8907190616.AA26340@bhopal> To: stanonik@nprdc.navy.mil Cc: common-lisp@sail.stanford.edu In-Reply-To: Ron Stanonik's message of 18 July 1989 0744-PDT (Tuesday) <8907181444.AA20259@atlantic.nprdc.navy.mil> Subject: sun commonlisp 3.0.2 and in-package re: We just installed sun commonlisp 3.0.2 (from lucid) and it now warns when files don't begin with in-package. It warns even if in-package is preceded by provide, the order recommended in CLtL. The explanation given is that provide/require are useless (better to use a defsystem) and discouraged in ansi commonlisp. I'm not sure where you got "the explanation given", but it couldn't have been from any Lucid source. There should be documentation with Sun Common Lisp release 3.0.2 which suggests overriding the order of the "7 extremely randoms" recommended in CLtL, and placing the PROVIDE statement last in the file; then, an IN-PACKAGE statement can always be first in the file. Incidentally, a very large number of users find PROVIDE/REQUIRE very useful (with even fewer porting problems than many other Common Lisp constructs, such as SUBTYPEP!). One reasonable use of REQUIRE is merely as a "safety net" to assure that the remainder of a file isn't loaded unless the pre-requisite facilities are available; a particularly useful version of this is to assure that a program's "package setup" file is loaded before proceeding with the loading of any part of the coding. It is not a reasonable use of PROVIDE and REQUIRE to expect them to replace a defsystem facility, although the fuzzy language at the bottom of page 188 of CLtL seems to suggest so. One more problem may arise with an initial IN-PACKAGE in a file. Because of another lacuna (which the upcoming proposed ANSI Common Lisp doesn't correct either), you have no guarantee whatsoever as to what package an IN-PACKGE form is read into. To be on the super-safe side, you should do something like: (LISP:IN-PACKAGE "MY-PACKAGE-NAME") unless you can be 100% sure that you will never be "in" a package that doesn't "use" LISP. Note the use of a string rather than a symbol as the package name, and note also no other arguments, implying that the call to IN-PACKAGE *** does not *** create the package, but merely selects it. [Yes, I know that there is at least one implementation that has several differnt definitions of IN-PACKAGE, and they are selected by *not* package-qualifying IN-PACKAGE in your file. Lotsa luck if you ever load a file "by hand" rather than using their automated defsystem.] -- JonL --  Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by AI.AI.MIT.EDU 18 Jul 89 21:27:02 EDT Received: from SAIL.STANFORD.EDU by REAGAN.AI.MIT.EDU via INTERNET with SMTP id 237715; 18 Jul 89 21:26:06 EDT Received: from cayuga.cs.rochester.edu by SAIL.Stanford.EDU with TCP; 18 Jul 89 18:16:22 PDT Received: from lesath.cs.rochester.edu by cayuga.cs.rochester.edu (5.59/m) id AA22785; Tue, 18 Jul 89 21:15:02 EDT Received: from loopback by lesath.cs.rochester.edu (3.2/m) id AA07306; Tue, 18 Jul 89 21:15:47 EDT Message-Id: <8907190115.AA07306@lesath.cs.rochester.edu> To: Stephen Nicoud Cc: stanonik@nprdc.navy.mil, common-lisp@sail.stanford.edu Subject: Re: sun commonlisp 3.0.2 and in-package In-Reply-To: Your message of Tue, 18 Jul 89 14:42:02 -0600. <2825786522-9736245@QUINAULT> Date: Tue, 18 Jul 89 21:15:43 -0400 From: quiroz@cs.rochester.edu | The logic for putting PROVIDE at the beginning of the file which REQUIRE | loads doesn't seem quite right. PROVIDE probably should be the last | thing evaluated after the contents of module are loaded. In that way, | if an error occurs during the loading, attempts to reuse REQUIRE, after | fixing the error, should succeed. If the recommended method were used | (putting PROVIDE first) the user would have to manually remove then | module name from *modules* before being able to reuse REQUIRE. Not as clear as it seems at first sight. LOAD could keep track of PROVIDES and undo them on failure to complete loading. The advantage, if anything, in putting PROVIDE first, reside in stopping accidental indirect recursions of requirements. (That LOAD has to keep a subjunctive environment to undo in case of failure goes along with similar impositions on the compiler.) On the issue of the original message, I think there is agreement that PROVIDE-REQUIRE is not very strong, and I think everybody uses one form of DEFSYSTEM or another anyway. But leaving PROVIDE-REQUIRE in is a nice aspect of self-documenting coding style. And, at any rate, *as long* as CLtL is the accepted standard, complaining about code that is complying with it is rude. Cesar  Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by AI.AI.MIT.EDU 18 Jul 89 18:32:54 EDT Received: from SAIL.STANFORD.EDU by REAGAN.AI.MIT.EDU via INTERNET with SMTP id 237601; 18 Jul 89 18:32:07 EDT Received: from atc.boeing.com by SAIL.Stanford.EDU with TCP; 18 Jul 89 15:18:49 PDT Received: by atc.boeing.com on Tue, 18 Jul 89 14:43:43 PDT Message-Id: <2825786522-9736245@QUINAULT> Sender: SLN@QUINAULT.atc.boeing.com Date: Tue, 18 Jul 89 14:42:02 MDT From: Stephen Nicoud To: stanonik@nprdc.navy.mil Cc: common-lisp@sail.stanford.edu Subject: Re: sun commonlisp 3.0.2 and in-package In-Reply-To: Msg of 18 July 1989 0744-PDT (Tuesday) from stanonik@nprdc.navy.mil.ARPANET (Ron Stanonik) Organization: Boeing Advanced Technology Center for Computer Sciences Date: 18 July 1989 0744-PDT (Tuesday) From: stanonik@nprdc.navy.mil.ARPANET (Ron Stanonik) Subject: sun commonlisp 3.0.2 and in-package It warns even if in-package is preceded by provide, the order recommended in CLtL. The logic for putting PROVIDE at the beginning of the file which REQUIRE loads doesn't seem quite right. PROVIDE probably should be the last thing evaluated after the contents of module are loaded. In that way, if an error occurs during the loading, attempts to reuse REQUIRE, after fixing the error, should succeed. If the recommended method were used (putting PROVIDE first) the user would have to manually remove the module name from *modules* before being able to reuse REQUIRE. The explanation given is that provide/require are useless (better to use a defsystem) and discouraged in ansi commonlisp. I haven't kept up with ansi commonlisp, require/provide are weak compared to defsystem, but I was still surprised to see a warning in this case. Ron Stanonik stanonik@nprdc.navy.mil PROVIDE/REQUIRE is weak. Integrating PROVIDE/REQUIRE with DEFSYSTEMs is really interesting 8^) depending on how you interpret the term "module". You could use "module" to mean the system being defined by DEFSYSTEM, the DEFSYSTEM modules, or both. There are advantages and disadvantages to any of the interpretations (which become more dramatic if you're trying to develop portable code). Integrating PROVIDE/REQUIRE with DEFSYSTEMs *and* SPE's DEFMODULES becomes an even more interesting exercise in compatibility. Is it too optimistic to hope that there will there be an attempt to define a Common Lisp standard for system maintenance which captures dependencies, modules, systems, and operations on them? Steve Nicoud snicoud@atc.boeing.com  Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by AI.AI.MIT.EDU 18 Jul 89 10:55:22 EDT Received: from SAIL.STANFORD.EDU by REAGAN.AI.MIT.EDU via INTERNET with SMTP id 237322; 18 Jul 89 10:54:28 EDT Received: from nprdc.navy.mil by SAIL.Stanford.EDU with TCP; 18 Jul 89 07:44:33 PDT Received: from atlantic.nprdc.navy.mil by nprdc.navy.mil (5.59/SMI-4.0) id AA18194; Tue, 18 Jul 89 07:44:02 PDT Received: by atlantic.nprdc.navy.mil (4.0/SMI-4.0) id AA20259; Tue, 18 Jul 89 07:44:48 PDT From: stanonik@nprdc.navy.mil (Ron Stanonik) Message-Id: <8907181444.AA20259@atlantic.nprdc.navy.mil> Date: 18 July 1989 0744-PDT (Tuesday) To: common-lisp@sail.stanford.edu Subject: sun commonlisp 3.0.2 and in-package Reply-To: stanonik@nprdc.navy.mil Sorry if this has been beat to death before. We just installed sun commonlisp 3.0.2 (from lucid) and it now warns when files don't begin with in-package. It warns even if in-package is preceded by provide, the order recommended in CLtL. The explanation given is that provide/require are useless (better to use a defsystem) and discouraged in ansi commonlisp. I haven't kept up with ansi commonlisp, require/provide are weak compared to defsystem, but I was still surprised to see a warning in this case. Ron Stanonik stanonik@nprdc.navy.mil  Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by AI.AI.MIT.EDU 17 Jul 89 20:34:50 EDT Received: from SAIL.STANFORD.EDU by REAGAN.AI.MIT.EDU via INTERNET with SMTP id 237086; 17 Jul 89 20:33:59 EDT Received: from vaxa.isi.edu by SAIL.Stanford.EDU with TCP; 17 Jul 89 17:14:32 PDT Posted-Date: Mon, 17 Jul 89 17:14:29 PDT Message-Id: <8907180014.AA03478@vaxa.isi.edu> Received: from LOCALHOST by vaxa.isi.edu (5.61/5.61) id AA03478; Mon, 17 Jul 89 17:14:31 -0700 To: common-lisp@sail.stanford.edu Subject: exit extent (formerly nonlocal exit from unwind-protect) Date: Mon, 17 Jul 89 17:14:29 PDT From: Don Cohen Is there any way known under the "minimal" proposal to write an un-exitable loop? Of course, whether that's a good thing to be able to do is another question. A more reasonable thing would be to generate an error in the unwind-protect that would warn the user about exiting and give him a restart option. However it's not clear to me that even this is possible under the minimal proposal. Opinions?  Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by AI.AI.MIT.EDU 10 Jul 89 18:45:02 EDT Received: from SAIL.STANFORD.EDU by REAGAN.AI.MIT.EDU via INTERNET with SMTP id 233762; 10 Jul 89 18:43:07 EDT Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 10 Jul 89 15:34:06 PDT Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 623054; 10 Jul 89 18:05:48 EDT Date: Mon, 10 Jul 89 18:05 EDT From: David A. Moon Subject: SYMBOL-MACROLET To: goldman@vaxa.isi.edu cc: common-lisp@sail.stanford.edu In-Reply-To: <8907102149.AA27155@vaxa.isi.edu> Message-ID: <19890710220541.4.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Mon, 10 Jul 89 13:49:20 PST From: goldman@vaxa.isi.edu Is it the case that the expansion code for a symbol-macro, (unlike a lexical macro introduced with MACROLET) has not means to obtain the current lexical environment? There is no expansion code for a symbol-macro. A symbol-macro always expands into the same thing; one specifies the expansion directly, rather than specifying Lisp forms that will compute and return the expansion. Of course a symbol macro could expand into a call to a regular macro, which could then expand into whatever it wants, potentially looking at the lexical environment.  Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by AI.AI.MIT.EDU 10 Jul 89 18:02:47 EDT Received: from SAIL.Stanford.EDU (INTERNET|36.86.0.194) by REAGAN.AI.MIT.EDU via INTERNET with SMTP id 233737; 10 Jul 89 18:02:16 EDT Received: from vaxa.isi.edu by SAIL.Stanford.EDU with TCP; 10 Jul 89 14:49:08 PDT Posted-Date: Mon, 10 Jul 89 13:49:20 PST Message-Id: <8907102149.AA27155@vaxa.isi.edu> Received: from LOCALHOST by vaxa.isi.edu (5.61/5.61) id AA27155; Mon, 10 Jul 89 14:49:23 -0700 To: common-lisp@sail.stanford.edu From: goldman@vaxa.isi.edu Subject: SYMBOL-MACROLET Date: Mon, 10 Jul 89 13:49:20 PST Sender: goldman@vaxa.isi.edu Is it the case that the expansion code for a symbol-macro, (unlike a lexical macro introduced with MACROLET) has not means to obtain the current lexical environment? neil  Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by AI.AI.MIT.EDU 6 Jul 89 12:31:55 EDT Received: from SAIL.STANFORD.EDU by REAGAN.AI.MIT.EDU via INTERNET with SMTP id 232324; 6 Jul 89 12:30:27 EDT Received: from cayuga.cs.rochester.edu ([192.5.53.209]) by SAIL.Stanford.EDU with TCP; 6 Jul 89 09:22:57 PDT Received: from sol.cs.rochester.edu by cayuga.cs.rochester.edu (5.59/m) id AA29685; Thu, 6 Jul 89 12:21:34 EDT Received: from cayuga.cs.rochester.edu by sol.cs.rochester.edu (3.2/m) id AA06471; Thu, 6 Jul 89 12:22:17 EDT Received: from QUCDN.QueensU.CA by cayuga.cs.rochester.edu (5.59/m) id AA29677; Thu, 6 Jul 89 12:20:17 EDT Received: from qusuno.qucis.queensu.ca by QUCDN.QueensU.CA (IBM VM SMTP R1.2) with TCP; Thu, 06 Jul 89 12:20:55 EDT Received: by qusuno.qucis.queensu.ca (3.2/SMI-3.2) id AA00289; Thu, 6 Jul 89 12:22:36 EDT Date: Thu, 6 Jul 89 12:22:36 EDT From: tomek@qucis.queensu.ca Message-Id: <8907061622.AA00289@qusuno.qucis.queensu.ca> To: cl@cs.rochester.edu Subject: CL flyer Dear James, I have just noticed the CL flyer that has been distributed at ACL meeting in Vancouver, and I am somewhat baffled. It says that the number 3 of volume 15 (to appear in September) will contain a paper "Non-Singular Concepts in Natural Language Discourse" by Nick Cercone. Well, Nick is the second of the TWO authors of this paper, i.e., it is Tomek Strzalkowski and Nick Cercone. My name may be difficult to spell but that's no reason to drop the first author's name altogether! Just hoping my name will appear on top of the paper. Greetings, Tomek Strzalkowski  Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by AI.AI.MIT.EDU 2 Jun 89 09:03:27 EDT Received: from SAIL.STANFORD.EDU by REAGAN.AI.MIT.EDU via INTERNET with SMTP id 217385; 2 Jun 89 21:01:52 EDT Received: from lucid.com by SAIL.Stanford.EDU with TCP; 2 Jun 89 17:25:43 PDT Received: from challenger ([192.9.200.17]) by heavens-gate id AA01255g; Fri, 2 Jun 89 16:28:47 PDT Received: by challenger id AA01058g; Fri, 2 Jun 89 16:26:32 PDT Date: Fri, 2 Jun 89 16:26:32 PDT From: Jan Zubkoff Message-Id: <8906022326.AA01058@challenger> To: common-lisp@sail.stanford.edu, x3j13@sail.stanford.edu Subject: New submission address for LASC LISP AND SYMBOLIC COMPUTATION Journal questions and submissions should be sent to the following new address: Jan Zubkoff Associate Editor, LASC Lucid, Inc. Route 5, Box 2834 Crawfordville, FL 32327 904/926-8039 Please send 5 copies of your paper for review. The final copy should be submitted in electronic LaTex form, either by netmail or on a 1.2M floppy. Volume 2 Issue 2 has just been mailed and Issue 3/4 will be another double issue due to be mailed in about a month. There have been some changes I thought you'd like to know about. Guy L. Steele Jr. has taken a one year sabatical to devote his time to other pressing activities. Carolyn Talcott has graciously stepped in as Acting Editor-in-Chief and has made short work of every paper. Mark Wegman and L. Peter Deutsch have both resigned to devote their time to research. Bob Kessler and JonL White have joined our Editorial Board and have given a great deal of their time reviewing papers. I'd like to thank each member of our Editorial Board for making this journal possible. Richard P. Gabriel Carolyn Talcott Daniel G. Bobrow Kenneth Kahn Robert S. Cartwright Robert Kessler Jerome Chailloux John McCarthy Daniel P. Friedman Larry Masinter Martin L. Griss Julian Padget Paul Hudak David S. Touretzky Masayuki Ida Mitchell Wand Gilles Kahn John L. White Thank you to all the authors who have submitted their work to LASC and have made this an exceptional joural. ---jan---  Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by AI.AI.MIT.EDU 20 Apr 89 17:45:22 EDT Received: from SAIL.STANFORD.EDU by REAGAN.AI.MIT.EDU via INTERNET with SMTP id 195354; 20 Apr 89 17:40:55 EDT Received: from cayuga.cs.rochester.edu by SAIL.Stanford.EDU with TCP; 20 Apr 89 14:34:43 PDT Received: from lesath.cs.rochester.edu by cayuga.cs.rochester.edu (5.59/l) id AA18692; Thu, 20 Apr 89 17:34:34 EDT Received: from loopback by lesath.cs.rochester.edu (3.2/l) id AA02604; Thu, 20 Apr 89 17:34:28 EDT Message-Id: <8904202134.AA02604@lesath.cs.rochester.edu> To: Guy Steele Cc: common-lisp@sail.stanford.edu Subject: Re: intent of (THE ) In-Reply-To: Your message of Thu, 20 Apr 89 16:59:15 -0400. <8904202059.AA00383@joplin.think.com> Date: Thu, 20 Apr 89 17:34:24 -0400 From: quiroz@cs.rochester.edu | Better to say that it checks as many types as requsted, but passes on | exactly the values it receives. That sounds better, indeed. So, do both of Neil's programs remain correct then? (Meaning here: "(setf x (the integer (truncate 7 3)))" is as correct as "(setf x (truncate 7 3))") Cesar  Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by AI.AI.MIT.EDU 20 Apr 89 17:17:21 EDT Received: from SAIL.STANFORD.EDU by REAGAN.AI.MIT.EDU via INTERNET with SMTP id 195320; 20 Apr 89 17:12:07 EDT Received: from Think.COM by SAIL.Stanford.EDU with TCP; 20 Apr 89 14:04:41 PDT Received: from fafnir.think.com by Think.COM; Thu, 20 Apr 89 17:04:38 EDT Return-Path: Received: from verdi.think.com by fafnir.think.com; Thu, 20 Apr 89 17:03:41 EDT Received: from joplin.think.com by verdi.think.com; Thu, 20 Apr 89 16:59:42 EDT From: Guy Steele Received: by joplin.think.com; Thu, 20 Apr 89 16:59:15 EDT Date: Thu, 20 Apr 89 16:59:15 EDT Message-Id: <8904202059.AA00383@joplin.think.com> To: quiroz@cs.rochester.edu Cc: common-lisp@sail.stanford.edu In-Reply-To: quiroz@cs.rochester.edu's message of Thu, 20 Apr 89 16:02:10 -0400 <8904202002.AA02490@lesath.cs.rochester.edu> Subject: intent of (THE ) ... PROPOSAL: What it boils down to, is that THE should check only as many types as requested (and pass back only as many). No, this is not cool. THE is supposed to act purely as a declaration, but you are changing it to require it to pass on only as many values as the type specifer indicates. This could change the semantics of a suitably devious program. Better to say that it checks as many types as requsted, but passes on exactly the values it receives. --Guy  Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by AI.AI.MIT.EDU 20 Apr 89 16:15:29 EDT Received: from SAIL.STANFORD.EDU by REAGAN.AI.MIT.EDU via INTERNET with SMTP id 195244; 20 Apr 89 16:10:49 EDT Received: from cayuga.cs.rochester.edu by SAIL.Stanford.EDU with TCP; 20 Apr 89 13:02:40 PDT Received: from lesath.cs.rochester.edu by cayuga.cs.rochester.edu (5.59/l) id AA18246; Thu, 20 Apr 89 16:02:25 EDT Received: from loopback by lesath.cs.rochester.edu (3.2/l) id AA02490; Thu, 20 Apr 89 16:02:14 EDT Message-Id: <8904202002.AA02490@lesath.cs.rochester.edu> To: common-lisp@sail.stanford.edu Subject: Re: intent of (THE ) In-Reply-To: Your message of Thu, 20 Apr 89 09:35:50 -0800. <8904201735.AA13354@vaxa.isi.edu> Date: Thu, 20 Apr 89 16:02:10 -0400 From: quiroz@cs.rochester.edu Summary: Don't disturb Unaware Callers. Don't let THE pass back values that it didn't check. [For details, search down for the string PROPOSAL.] After the latest note by Neil Goldman, I think I see with less sympathy the proposed transformations to clarify THE. I suggest that a guiding concern be this: Unaware Callers don't suffer unintended weirdness when they call a Multiple Value function. By Unaware Callers I mean those that don not intentionally use any of the forms that do something with multiple values. So, I would have it this way: (setf x (truncate 7 3)) ; the second value is discarded, right? (setf x (the integer (truncate 7 3))) ; the second value is also discarded (setf (the integer x) (truncate 7 3)) would all do the same thing: discard the second value, even for type checking. I didn't request the second value, I don't want to have to declare its type. (Also, instead of truncate, think of a user defined function that over time gets extended to return multiple values, I don't want this benign extension to break anything that worked before). PROPOSAL: What it boils down to, is that THE should check only as many types as requested (and pass back only as many). This entails rewording the entry for THE in p. 138 of CLtL: * If the type specifier specifier of the THE form is not of the form (VALUES ...), only one value is checked and passed back. Else, only as many returned values as specified in the (VALUES ...) specifier are checked and passed back. (Missing values are assumed to be nil, they are checked and passed back.) A type specifier of the form (VALUES ... &rest T) is used to indicate that extra values may be present, and are not type checked, but are passed back. Possible draw-back: (multiple-value-bind (foo bar) (the integer (truncate 7 3)) (declare (type integer foo bar)) (list foo bar)) would be in error (bar would be nil). The program without the THE declaration looks correct to me, but the declaration screws it up. That's is philosophically OK with me (Aware Callers have all the responsibility to do the right thing; only Unaware Callers are protected from peculiarities of the Multiple Value system), but still some may feel it to be a touch rude. The fix, of course, would be: (multiple-value-bind (foo bar) (the (values integer integer) (truncate 7 3)) ...) So adding a corect declaration is still possible. Sorry this got too long. Cesar  Received: from SAIL.Stanford.EDU (TCP 4425400302) by AI.AI.MIT.EDU 20 Apr 89 14:34:14 EDT Received: from vaxa.isi.edu by SAIL.Stanford.EDU with TCP; 20 Apr 89 10:35:54 PDT Posted-Date: Thu, 20 Apr 89 09:35:50 PST Message-Id: <8904201735.AA13354@vaxa.isi.edu> Received: from LOCALHOST by vaxa.isi.edu (5.61/5.61) id AA13354; Thu, 20 Apr 89 10:35:53 -0700 To: common-lisp@sail.stanford.edu From: goldman@vaxa.isi.edu Subject: re: intent of (THE ) Cc: barmar@think.com, mincy@think.com Date: Thu, 20 Apr 89 09:35:50 PST Sender: goldman@vaxa.isi.edu Jeff is absolutely correct in rejecting the resolution I stated as my preference. It would have said that: a) (truncate 7 3) is a correct program, and it returns two values b) (the integer (truncate 7 3)) is a correct program, and it returns one value But all that has happened (syntactically) is the addition of a type declaration to a correct program. I still think the meaning of (the ) needs clarification. What do you think of this alternative: 1) if the is not of the form (VALUES ...), then let (VALUES &rest T) be the effective type specifier. Otherwise, itself is the effective type specifier. 2) The value(s) returned by expression must be compatible with the effective type specifer, where compatibility is as described on page 48 in the definition of VALUES style type specifiers. [But that paragraph should be expanded to include &allow-other-keys. It should also make explicit that i) the value-type list is a lambda list in which type-specifiers appear where parameter names would appear in a normal lambda list ii) none the the component type specifiers may be a VALUES type specifier iii) the type specifiers all appear as top-level components of the value-type list for positional values (required or &optional), and as ( type-specifier) for keyword type-specifiers (I presume that was the intent?) The is NOT coerced to the keyword package. For example, (the (values integer &optional number &key (a symbol) (:b cons) &allow-other-keys) (values 7 8 :b '(x 1) 'a 3 'b 2)) would be correct. (the integer (truncate 7 3) would be correct, because it is treated as (the (values integer &rest t) (integer 7 3) (the (values integer) (truncate 7 3)) would be an error. Neil  Received: from SAIL.Stanford.EDU (TCP 4425400302) by AI.AI.MIT.EDU 20 Apr 89 13:35:48 EDT Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 20 Apr 89 09:36:31 PDT Received: from Riesling.ms by ArpaGateway.ms ; 20 APR 89 06:02:17 PDT Sender: "Larry_Masinter.PARC"@Xerox.COM Date: 19 Apr 89 09:36:38 PDT (Wednesday) Subject: Re: the "N" in "NCONC" From: masinter.PARC@Xerox.COM To: KMP@STONY-BROOK.SCRC.Symbolics.COM cc: padget@ilog.ilog.fr, Dave.Touretzky@CS.CMU.EDU, common-lisp@sail.stanford.EDU, jmc@sail.stanford.EDU In-Reply-to: KMP%STONY-BROOK.SCRC.Symbolics:COM's message of Monday, April 17, 1989 11:49 am Reply-to: masinter.PARC@Xerox.COM Message-ID: <890420-060217-3764@Xerox> The convention wasn't universal. While Interlisp had NCONC, it used DREVERSE (for Destructive REVERSE) , DREMOVE, DSUBST, etc.  Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by AI.AI.MIT.EDU 20 Apr 89 11:23:55 EDT Received: from SAIL.STANFORD.EDU by REAGAN.AI.MIT.EDU via INTERNET with SMTP id 194919; 20 Apr 89 11:19:34 EDT Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 20 Apr 89 07:41:39 PDT Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP id aa08443; 20 Apr 89 15:31 BST Date: Thu, 20 Apr 89 15:25:29 BST Message-Id: <20806.8904201425@subnode.aiai.ed.ac.uk> From: Jeff Dalton Subject: Re: the "N" in "NCONC" To: Jon L White <@sail.stanford.edu:jonl@lucid.com>, padget%ilog.ilog.fr@NSS.Cs.Ucl.AC.UK In-Reply-To: Jon L White's message of Tue, 18 Apr 89 02:31:03 PDT Cc: Dave.Touretzky@cs.cmu.edu, common-lisp@sail.stanford.edu, jmc@sail.stanford.edu > This explanation doesn't seem very likely to me. The Lisp 1.5 Programmer's > Manual -- which dates to mid 1962 -- shows both CONC and NCONC as being > N-ary operations. Um, JonL, when I look in the Lisp 1.5 manual, I see NCONC (p 62) described as a 2-argument function. CONC is n-argument, Both are destructive.  Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by AI.AI.MIT.EDU 20 Apr 89 10:55:14 EDT Received: from SAIL.STANFORD.EDU by REAGAN.AI.MIT.EDU via INTERNET with SMTP id 194887; 20 Apr 89 10:50:40 EDT Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 20 Apr 89 07:41:39 PDT Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP id aa08443; 20 Apr 89 15:31 BST Date: Thu, 20 Apr 89 15:25:29 BST Message-Id: <20806.8904201425@subnode.aiai.ed.ac.uk> From: Jeff Dalton Subject: Re: the "N" in "NCONC" To: Jon L White <@sail.stanford.edu:jonl@lucid.com>, padget%ilog.ilog.fr@NSS.Cs.Ucl.AC.UK In-Reply-To: Jon L White's message of Tue, 18 Apr 89 02:31:03 PDT Cc: Dave.Touretzky@cs.cmu.edu, common-lisp@sail.stanford.edu, jmc@sail.stanford.edu > This explanation doesn't seem very likely to me. The Lisp 1.5 Programmer's > Manual -- which dates to mid 1962 -- shows both CONC and NCONC as being > N-ary operations. Um, JonL, when I look in the Lisp 1.5 manual, I see NCONC (p 62) described as a 2-argument function. CONC is n-argument, Both are destructive.  Received: from SAIL.Stanford.EDU (TCP 4425400302) by AI.AI.MIT.EDU 19 Apr 89 18:36:34 EDT Received: from Think.COM by SAIL.Stanford.EDU with TCP; 19 Apr 89 15:21:49 PDT Return-Path: Received: from OCCAM.THINK.COM by Think.COM; Wed, 19 Apr 89 18:17:14 EDT Date: Wed, 19 Apr 89 18:16 EDT From: Barry Margolin Subject: intent of (THE ) To: Jeff Mincy Cc: goldman@vaxa.isi.edu, common-lisp@sail.stanford.edu In-Reply-To: <19890419213156.5.MINCY@ZENO.THINK.COM> Message-Id: <19890419221642.8.BARMAR@OCCAM.THINK.COM> Date: Wed, 19 Apr 89 17:31 EDT From: Jeff Mincy Date: Wed, 19 Apr 89 12:44:00 PST From: goldman@vaxa.isi.edu If P1 is correct, how about P2 P2: (let ((x 0)) (declare (integer x)) (setf x (the integer (truncate 7 3)))) Personal preference: I would like (the ), where was not a VALUES type specifier, to mean (the (VALUES )) (the integer (values 0 3)) would be correct and return only one value, 0. Neil (Correct) type declarations are not supposed to affect the semantics of a correct program. Your type declaration just changed the the semantics. The operative word is "correct". If the expression returns two values and the type declaration is interpreted as specifying that it returns exactly one value, then the type declaration isn't correct. If this is the correct interpretation of non-VALUES type specifiers in THE forms, then the above is just as incorrect as (the float 0). I'm not sure what the right interpretation of this is. As far as I can tell, it hasn't come up in X3J13 (there's only one Cleanup issue related to THE, and it's about a different problem). In the description of the THE special form, the only wording I can find that indicates either way is the comments in the examples on p.162. When describing the interpretation of (the integer (+ x 3)) the comments say "the result of + will be an integer." The use of the singular in these comments implies that the declaration specifies that + will only return one value. However, the description of THE as used with SETF, p.96, implies the other way. It says that (setf (the ) ) is processed as if it were (setf (the )) Therefore, (setf (the integer x) (truncate 7 3)) would be treated as (setf x (the integer (truncate 7 3))). Intuitively, the original version seems correct, so the transformed version should be valid. It is certainly counterintuitive to require one to write (setf (the (values integer integer) x) (truncate 7 3)) This latter problem could be fixed either by fixing the definition of the THE special form, or by fixing the definition of the THE SETF-place. barmar  Received: from SAIL.Stanford.EDU (TCP 4425400302) by AI.AI.MIT.EDU 19 Apr 89 17:47:10 EDT Received: from Think.COM by SAIL.Stanford.EDU with TCP; 19 Apr 89 14:32:23 PDT Return-Path: Received: from sauron.think.com by Think.COM; Wed, 19 Apr 89 17:32:24 EDT Received: from ZENO.THINK.COM by sauron.think.com; Wed, 19 Apr 89 17:31:33 EDT Date: Wed, 19 Apr 89 17:31 EDT From: Jeff Mincy Subject: intent of (THE ) To: goldman@vaxa.isi.edu, common-lisp@sail.stanford.edu In-Reply-To: <8904192044.AA21853@vaxa.isi.edu> Message-Id: <19890419213156.5.MINCY@ZENO.THINK.COM> Date: Wed, 19 Apr 89 12:44:00 PST From: goldman@vaxa.isi.edu If P1 is correct, how about P2 P2: (let ((x 0)) (declare (integer x)) (setf x (the integer (truncate 7 3)))) Personal preference: I would like (the ), where was not a VALUES type specifier, to mean (the (VALUES )) (the integer (values 0 3)) would be correct and return only one value, 0. Neil (Correct) type declarations are not supposed to affect the semantics of a correct program. Your type declaration just changed the the semantics. (setq x (the integer (truncate 7 3))) should not signal an error. After all, only one value is being used, and I want to declare that one value. When giving a non values type declaration such as INTEGER, it should be taken to declare the first value. Any other values returned are not declared. If I want to declare that something returns exactly one value, and it is an integer, then I can use the type (values integer). The types INTEGER and (VALUES INTEGER) should either be equivalent or not, and this should be specified better in CLtL. I think is it more useful if they are not equivalent. -jeff  Received: from SAIL.Stanford.EDU (TCP 4425400302) by AI.AI.MIT.EDU 19 Apr 89 17:02:57 EDT Received: from vaxa.isi.edu by SAIL.Stanford.EDU with TCP; 19 Apr 89 13:44:06 PDT Posted-Date: Wed, 19 Apr 89 12:44:00 PST Message-Id: <8904192044.AA21853@vaxa.isi.edu> Received: from LOCALHOST by vaxa.isi.edu (5.61/5.61) id AA21853; Wed, 19 Apr 89 13:44:07 -0700 To: common-lisp@sail.stanford.edu From: goldman@vaxa.isi.edu Subject: intent of (THE ) Date: Wed, 19 Apr 89 12:44:00 PST Sender: goldman@vaxa.isi.edu 1) Is program P1 a correct common lisp program, or is it "an error": P1: (let ((x 0)) (declare (integer x)) (setf x (truncate 7 3))) If P1 is correct, how about P2 P2: (let ((x 0)) (declare (integer x)) (setf x (the integer (truncate 7 3)))) Why this is a question: TRUNCATE returns 2 values. Is (THE INTEGER ) equivalent to (THE (VALUES INTEGER &rest T) )) -- in which case P2 is correct, and (THE INTEGER (TRUNCATE 7 3)) returns 2 values, 2 and 1? Or is (THE INTEGER ) equivalent to (THE (VALUES INTEGER &REST T) (VALUES )) in which case P2 is correct and (THE INTEGER (TRUNCATE 7 3)) returns a single value, 2? Observations: If P1 is correct, and P2 is "an error", then the "transformation" of wrapping (the ) around expressions being assignmened to a variable for which a type has been declared is NOT a correct transformation in Common Lisp. Of course if BOTH P1 and P2 are incorrect, it may still be a legitimate transformation. Empirical observation that raised this question: Symbolics' implementation signals an error for P2 (interpreted, though NOT compiled). It does not signal an error for P1 in any case. This is consistent with considering P2 to be "is an error" and considering P1 to be either correct OR "is an error". I don't know what their position is. I am not able to determine a stance on this question from the text on pp 161-162 of CLtL84. Personal preference: I would like (the ), where was not a VALUES type specifier, to mean (the (VALUES )) (the (values integer) (values 1 2)) would be an error. (the integer (values 0 3)) would be correct and return only one value, 0. (the (values integer integer) (values 1 2)) would be correct and return 2 values, 1 and 2. Remotely related question -- can DEFTYPE be used to define VALUES style or FUNCTION style type specifiers, or only the kind that TYPEP is willing to accept? On my symbolics implementation, I can do (deftype two-integers () (values integer integer)) without any error. The interpreter accepts (the (values integer integer) (values 1 2)) returning two values, 1 and 2. but the interpreter signals an error for (the (two-integers) (values 1 2)) which is consistent with considering it to be an error for a use of a type "macro" defined with DEFTYPE to produce a VALUES style type specifier. (although the error message scarcely makes that appear to be the offense.) Neil  Received: from SAIL.Stanford.EDU (TCP 4425400302) by AI.AI.MIT.EDU 19 Apr 89 12:12:58 EDT Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 19 Apr 89 08:56:57 PDT Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs) id AA13751; Wed, 19 Apr 89 09:57:00 -0600 Received: by defun.utah.edu (5.61/utah-2.0-leaf) id AA07006; Wed, 19 Apr 89 09:56:57 -0600 From: sandra%defun@cs.utah.edu (Sandra J Loosemore) Message-Id: <8904191556.AA07006@defun.utah.edu> Date: Wed, 19 Apr 89 09:56:56 MDT Subject: questions about EVALHOOK To: common-lisp@sail.stanford.edu I have some questions about how EVALHOOK is supposed to work in implementations whose evaluators compile (or partially compile) forms passed to EVAL. Page 321 of CLtL says that this technique "renders the EVALHOOK mechanism relatively useless". Does this mean it's possible that the *EVALHOOK* function might never be called by EVAL? Or, might the form argument it receives be some kind of structure representing the source code, instead of the Lisp source code itself? Also, page 323 says that "the STEP facility is implemented using this hook". Is this really a *requirement* on the implementation of STEP, or just a suggestion on how it *might* be implemented? -Sandra -------  Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by AI.AI.MIT.EDU 18 Apr 89 05:42:06 EDT Received: from SAIL.STANFORD.EDU by REAGAN.AI.MIT.EDU via INTERNET with SMTP id 193511; 18 Apr 89 05:37:59 EDT Received: from lucid.com by SAIL.Stanford.EDU with TCP; 18 Apr 89 02:31:29 PDT Received: from bhopal ([192.43.178.13]) by heavens-gate.lucid.com id AA09534g; Tue, 18 Apr 89 02:31:09 PDT Received: by bhopal id AA03330g; Tue, 18 Apr 89 02:31:03 PDT Date: Tue, 18 Apr 89 02:31:03 PDT From: Jon L White Message-Id: <8904180931.AA03330@bhopal> To: padget@ilog.ilog.fr Cc: Dave.Touretzky@CS.CMU.EDU, common-lisp@sail.stanford.edu, jmc@sail.stanford.edu In-Reply-To: Julian Padget's message of Mon, 17 Apr 89 09:30:16 +0200 <8904170730.AA08639@ilog.ilog.fr> Subject: the "N" in "NCONC" re: . . . KMP (I think) avowed that it was a result of a misunderstanding which arose as follows: there was a function CONC which destructively joined two lists together (once upon a time) and then it was generalised into an N-ary function and renamed NCONC. This explanation doesn't seem very likely to me. The Lisp 1.5 Programmer's Manual -- which dates to mid 1962 -- shows both CONC and NCONC as being N-ary operations. When I first showed up around MIT in the late 60's, the common gossip was that the "N" stood for "Non-Consing". Interlisp (nee, BBN-Lisp) had another nomenclature -- a prefix "D" meant "Destructive" rather than "Non-Consing". Interestingly, there was one exception to the Interlisp scheme -- NCONC. Possibly, then, it was trying to remain compatible with Lisp 1.5. But the pattern must have been instituted after the break in communications between the BBN gang and the MIT gang, since MacLisp's predecessor on the PDP6 had NREVERSE whereas Interlisp has DREVERSE. In the early days of 7094 Lisp (on CTSS), consing "too much" could be disastrous. People were known even back then to try tricks to avoid it. Despite the humongous increase in address space that the 7094 afforded over the 650, there was still the likelihood that all of the nearly 32 thousand cells would be occupied. And the first garbage collectors were known to "take a while". Hmmmm, 32 thousand "new cells"; hmmm, we've come a long way, baby. -- JonL --  Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by AI.AI.MIT.EDU 17 Apr 89 17:43:17 EDT Received: from SAIL.STANFORD.EDU by REAGAN.AI.MIT.EDU via INTERNET with SMTP id 193153; 17 Apr 89 17:39:32 EDT Received: from gremlin.nrtc.northrop.com by SAIL.Stanford.EDU with TCP; 17 Apr 89 14:34:38 PDT Received: from tribble by gremlin.nrtc.northrop.com id aa03485; 17 Apr 89 14:31 PDT To: Dick Gabriel cc: common-lisp@sail.stanford.edu, JMC@sail.stanford.edu, padget@ilog.ilog.fr, jbarnett@gremlin.nrtc.northrop.com Subject: Re: the "N" in "NCONC" In-reply-to: Your message of 17 Apr 89 13:19:00 -0700. <1UPwyf@SAIL.Stanford.EDU> Date: Mon, 17 Apr 89 14:30:56 -0700 From: jbarnett@gremlin.nrtc.northrop.com The name, "NCONC" was in existence long before InterLisp was ever thought about. It appeared in the Q32 LISP 1.5 and I think in the MAC Lisp on the 7094 and PDP 10. I'm sure from my own experience that it was in vogue by the early 1960's. The N in NCONC may be like the D in DREVERSE, but both NCONC and DREVERSE were in the same systems. In any event, what is more curious to me than the fact that the name NCONC starts with an N, is the fact that the function was never and is not called DAPPEND or even NAPPEND.  Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by AI.AI.MIT.EDU 17 Apr 89 17:38:10 EDT Received: from SAIL.STANFORD.EDU by REAGAN.AI.MIT.EDU via INTERNET with SMTP id 193144; 17 Apr 89 17:34:23 EDT Received: from SPICE.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 17 Apr 89 14:27:16 PDT Date: Mon, 17 Apr 1989 17:19-EDT From: Jamie.Zawinski To: common-lisp@SAIL.Stanford.EDU Subject: Re: the "N" in "NCONC" > I believe the term comes from ``Non-consing CONCatenate,'' which predates > Maclisp. Possbly Greenblatt, Gosper, or even Mike Levin came up with it. > The InterLisp equivalent is D- as in ``dreverse.'' Does that mean that "Dedit" is a non-consing editor? :-)  Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by AI.AI.MIT.EDU 17 Apr 89 16:33:17 EDT Received: from SAIL.STANFORD.EDU by REAGAN.AI.MIT.EDU via INTERNET with SMTP id 193095; 17 Apr 89 16:29:31 EDT Message-ID: <1UPwyf@SAIL.Stanford.EDU> Date: 17 Apr 89 1319 PDT From: Dick Gabriel Subject: the "N" in "NCONC" To: common-lisp@SAIL.Stanford.EDU CC: JMC@SAIL.Stanford.EDU, padget@ILOG.ILOG.FR I believe the term comes from ``Non-consing CONCatenate,'' which predates Maclisp. Possbly Greenblatt, Gosper, or even Mike Levin came up with it. The InterLisp equivalent is D- as in ``dreverse.'' -rpg-  Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by AI.AI.MIT.EDU 17 Apr 89 15:54:43 EDT Received: from SAIL.STANFORD.EDU by REAGAN.AI.MIT.EDU via INTERNET with SMTP id 193040; 17 Apr 89 15:50:59 EDT Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 17 Apr 89 12:45:35 PDT Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP id aa09161; 17 Apr 89 20:30 BST Date: Mon, 17 Apr 89 20:22:42 BST Message-Id: <15142.8904171922@subnode.aiai.ed.ac.uk> From: Jeff Dalton Subject: Re: the "N" in "NCONC" To: Julian Padget , Dave.Touretzky@cs.cmu.edu In-Reply-To: Julian Padget's message of Mon, 17 Apr 89 09:30:16 +0200 Cc: common-lisp@sail.stanford.edu, jmc@sail.stanford.edu > I remember this being discussed on an old lisp mailing list about 5 > years ago. KMP (I think) avowed that it was a result of a > misunderstanding which arose as follows: there was a function CONC > which destructively joined two lists together (once upon a time) and > then it was generalised into an N-ary function and renamed NCONC. > Someone else (no names remembered or given) reading the description > decided that the N prefix distinguished it as a destructive operation > and so christened destructive reverse NREVERSE, and so on. I've long thought that this story was correct, but if you look at the Lisp 1.5 manual you'll see that CONC is the n-arg version, NCONC is a 2-arg function, and both work without copying. -- Jeff  Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by AI.AI.MIT.EDU 17 Apr 89 14:31:55 EDT Received: from SAIL.STANFORD.EDU by REAGAN.AI.MIT.EDU via INTERNET with SMTP id 192984; 17 Apr 89 14:28:09 EDT Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 17 Apr 89 11:20:37 PDT Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 578392; Mon 17-Apr-89 14:20:32 EDT Date: Mon, 17 Apr 89 14:19 EDT From: Kent M Pitman Subject: the "N" in "NCONC" To: padget@ilog.ilog.fr cc: Dave.Touretzky@CS.CMU.EDU, common-lisp@sail.stanford.edu, jmc@sail.stanford.edu In-Reply-To: <8904170730.AA08639@ilog.ilog.fr> Message-ID: <890417141925.9.KMP@BOBOLINK.SCRC.Symbolics.COM> Date: Mon, 17 Apr 89 09:30:16 +0200 From: padget@ilog.ilog.fr (Julian Padget) I remember this being discussed on an old lisp mailing list about 5 years ago. KMP (I think) avowed that it was a result of a misunderstanding which arose as follows: there was a function CONC which destructively joined two lists together (once upon a time) and then it was generalised into an N-ary function and renamed NCONC. Someone else (no names remembered or given) reading the description decided that the N prefix distinguished it as a destructive operation and so christened destructive reverse NREVERSE, and so on. Yes, you probably heard this from me but I got the story (I think) from Drew McDermott. When I heard it, I raced to my Lisp 1.5 manual to check it out, and sure enough it doesn't align. I still tell the story, though, usually disclaiming it as having come from Drew and observing it to be `probably apocryphal' just because it's so typical of things that really -do- happen.  Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by AI.AI.MIT.EDU 17 Apr 89 13:46:33 EDT Received: from SAIL.STANFORD.EDU by REAGAN.AI.MIT.EDU via INTERNET with SMTP id 192956; 17 Apr 89 13:42:53 EDT Received: from argus.Stanford.EDU by SAIL.Stanford.EDU with TCP; 17 Apr 89 10:32:49 PDT Received: from INRIA.INRIA.FR by argus.Stanford.EDU with TCP; Mon, 17 Apr 89 10:21:34 PDT Received: by inria.inria.fr (5.61+/89.0.7) via Fnet-EUnet id AA14241; Mon, 17 Apr 89 09:33:56 +0200 (MET) Date: Mon, 17 Apr 89 09:30:16 +0200 Received: by ilog.ilog.fr, Mon, 17 Apr 89 09:30:16 +0200 From: padget@ilog.ilog.fr (Julian Padget) Message-Id: <8904170730.AA08639@ilog.ilog.fr> To: Dave.Touretzky@CS.CMU.EDU Cc: common-lisp@sail.stanford.edu, jmc@sail.stanford.edu In-Reply-To: Dave.Touretzky@b.gp.cs.cmu.edu's message of Sat, 15 Apr 89 02:43:43 EDT <2558.608625823@DST.BOLTZ.CS.CMU.EDU> Subject: the "N" in "NCONC" I remember this being discussed on an old lisp mailing list about 5 years ago. KMP (I think) avowed that it was a result of a misunderstanding which arose as follows: there was a function CONC which destructively joined two lists together (once upon a time) and then it was generalised into an N-ary function and renamed NCONC. Someone else (no names remembered or given) reading the description decided that the N prefix distinguished it as a destructive operation and so christened destructive reverse NREVERSE, and so on. --Julian.  Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by AI.AI.MIT.EDU 15 Apr 89 02:54:53 EDT Received: from SAIL.STANFORD.EDU by REAGAN.AI.MIT.EDU via INTERNET with SMTP id 192188; 15 Apr 89 02:51:40 EDT Received: from DST.BOLTZ.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 14 Apr 89 23:43:53 PDT Received: from DST.BOLTZ.CS.CMU.EDU by DST.BOLTZ.CS.CMU.EDU; 15 Apr 89 02:43:45 EDT To: common-lisp@sail.stanford.edu cc: jmc@sail.stanford.edu Reply-To: Dave.Touretzky@cs.cmu.edu Subject: the "N" in "NCONC" Date: Sat, 15 Apr 89 02:43:43 EDT Message-ID: <2558.608625823@DST.BOLTZ.CS.CMU.EDU> From: Dave.Touretzky@B.GP.CS.CMU.EDU To complete the 2nd edition of my Lisp book, I am researching the origin of the "N" convention for naming destructive functions. >From the description of NCONC in the Lisp 1.5 Programmer's Manual (p. 62), it seems plausible that the "N" originally stood for "No copy". The manual never says this explicitly, though. If any of you Lisp historians out there can shed more light on this important matter, I'd be much obliged. -- Dave  Received: from SAIL.Stanford.EDU (TCP 4425400302) by AI.AI.MIT.EDU 24 Mar 89 15:56:04 EST Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 24 Mar 89 12:45:27 PST Received: from syma.sussex.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP id aa05669; 24 Mar 89 20:33 GMT Received: from csuna.cogs.susx.ac.uk (csuna-gateway) by uk.ac.sussex.syma; Fri, 24 Mar 89 20:38:57 GMT From: Aaron Sloman Date: Fri, 24 Mar 89 20:33:20 GMT Message-Id: <18371.8903242033@csuna.cogs.susx.ac.uk> To: various_colleagues%cogs.sussex.ac.uk@NSS.Cs.Ucl.AC.UK Subject: email address change -- "cvaxa" -> "cogs" In case nobody else has told you, or you need reminding: Please change all reference in University of Sussex email addresses from "cvaxa" to "cogs". Cvaxa refers to a machine that dies this month. "cogs" comes via the new Sequent Symmetry in our computing centre, known as "uk.ac.sussex.syma". "cogs" is registered as a subdomain of this. [Apologies if you have received this information more than once.] Aaron ----------------------------------------------------------------------- Aaron Sloman, School of Cognitive and Computing Sciences, Univ of Sussex, Brighton, BN1 9QN, England ARPANET : aarons%uk.ac.sussex.cogs@nss.cs.ucl.ac.uk aarons%uk.ac.sussex.cogs%nss.cs.ucl.ac.uk@relay.cs.net JANET aarons@cogs.sussex.ac.uk BITNET: aarons%uk.ac.sussex.cogs@uk.ac or aarons%uk.ac.sussex.cogs%ukacrl.bitnet@cunyvm.cuny.edu UUCP: ...mcvax!ukc!cogs!aarons or aarons@cogs.uucp IN CASE OF DIFFICULTY use "syma" instead of "cogs"  Received: from SAIL.Stanford.EDU (TCP 4425400302) by AI.AI.MIT.EDU 22 Mar 89 12:35:33 EST Received: from vaxa.isi.edu by SAIL.Stanford.EDU with TCP; 22 Mar 89 09:19:10 PST Posted-Date: Wed, 22 Mar 89 09:18:16 PST Message-Id: <8903221718.AA01878@vaxa.isi.edu> Received: from LOCALHOST by vaxa.isi.edu (5.59/5.51) id AA01878; Wed, 22 Mar 89 09:18:26 PST To: common-lisp@sail.stanford.edu From: goldman@vaxa.isi.edu Subject: Common Lisp function signatures Date: Wed, 22 Mar 89 09:18:16 PST Sender: goldman@vaxa.isi.edu Does anyone out there have a machine processable file containing a representation of the input-output type signatures of the functions of CommonLisp? i.e., something that would let me define a function IO-SIGNATURE, where IO-SIGNATURE[CONS] ==> (T T) , (CONS) IO-SIGNATURE[VALUES-LIST] ==> (CONS), (&REST T) IO-SIGNATURE[+] ==> (NUMBER &rest NUMBER), (NUMBER) etc. I would also be interested in other abstract characterizations of the common lisp functions, such as whether they are "applicative" or "context dependent". neil  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 10 Mar 89 10:52:52 EST Received: from cheops.cis.ohio-state.edu by SAIL.Stanford.EDU with TCP; 10 Mar 89 07:44:54 PST Received: by cheops.cis.ohio-state.edu (5.59/2.890120) id AA07623; Fri, 10 Mar 89 10:41:58 EST Date: Fri, 10 Mar 89 10:41:58 EST From: Arun Welch Message-Id: <8903101541.AA07623@cheops.cis.ohio-state.edu> To: Forster%vax2@cs.umass.edu Cc: common-lisp@sail.stanford.edu In-Reply-To: Forster%vax2@cs.umass.edu's message of Fri, 10 Mar 89 10:34:48 EST <2814536088-2521485@Cousteau> Subject: [LOOP docs and source] Thanks. ...arun  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 10 Mar 89 10:44:24 EST Received: from crash.cs.umass.edu ([128.119.40.235]) by SAIL.Stanford.EDU with TCP; 10 Mar 89 07:34:36 PST Received: from cousteau.cs.umass.edu by crash.cs.umass.edu (5.59/Ultrix2.0-B) id AA00200; Fri, 10 Mar 89 10:35:09 est Message-Id: <2814536088-2521485@Cousteau> Sender: DAVID%Cousteau@cs.umass.edu Date: Fri, 10 Mar 89 10:34:48 EST From: Forster%vax2@cs.umass.edu To: common-lisp@sail.stanford.edu Cc: welch@cis.ohio-state.EDU Subject: re: [LOOP docs and source] > From: Arun Welch > > Can someone out there point me to documentation for/a description of the > recently-passed LOOP macro? Portable code would be nice, too. In September of 1987, and later on New Year's in 1988, two loop macros were advertised in this netnews group, one the actual distribution, and the other indicating the ftp address. I'm including editted versions of the original messages at the end of this message. I don't know if these correspond to the proposal (apparently from Lucid?) 100%, but they're a start, I guess, and pretty much PD, I gather. As far as documentation goes, perhaps the originators could forward the proposal presented to the committee to this list? - David Forster ________________ KCL stuff: ________________ From: Taiichi Yuasa Here is my code for LOOP, which will be included in the next release of KCL available from University of Texas. -- Taiichi ... ;; (c) Copyright Taiichi Yuasa and Masami Hagiya, 1984. All rights reserved. ;; Copying of this file is authorized to users who have executed the true and ;; proper "License Agreement for Kyoto Common LISP" with SIGLISP. ;;;; loop.lsp ;;;; ;;;; defines the sophisticated LOOP macro, with the hope it's ;;;; compatible with Symbolics Common Lisp. ________________ sloop stuff: ________________ From: Bill Schelter ... sloop.lisp ... is available on rascal:/usr2/ftp/pub/sloop.lisp Internet Address: 128.83.144.1 rascal.ics.utexas.edu rascal # sun unix login anonymous with password guest. ... Any bug reports or complaints (or even contented user reports) should also go to that address. Bill Schelter ________________ End of forwarded text ________________  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 9 Mar 89 15:56:33 EST Received: from cheops.cis.ohio-state.edu by SAIL.Stanford.EDU with TCP; 9 Mar 89 12:43:02 PST Received: by cheops.cis.ohio-state.edu (5.59/2.890120) id AA04131; Thu, 9 Mar 89 15:40:50 EST Date: Thu, 9 Mar 89 15:40:50 EST From: Arun Welch Message-Id: <8903092040.AA04131@cheops.cis.ohio-state.edu> To: common-lisp@sail.stanford.edu Subject: Loop Can someone out there point me to documentation for/a description of the recently-passed LOOP macro? Portable code would be nice, too. Converting between Interlisp Clisp forms and CL DO is really twisting my brain...:-) ...arun ---------------------------------------------------------------------------- Arun Welch Lisp Systems Programmer, Lab for AI Research, Ohio State University welch@tut.cis.ohio-state.edu  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 2 Mar 89 18:28:01 EST Received: from NMFECC.ARPA by SAIL.Stanford.EDU with TCP; 2 Mar 89 15:11:08 PST Received: from tuva.sainet.mfenet by ccc.mfenet with Tell via MfeNet ; Thu, 2 Mar 89 15:06:40 PST Date: Thu, 2 Mar 89 15:06:40 PST From: POTHIERS%TUVA.SAINET.MFENET@NMFECC.ARPA Message-Id: <890302150640.23200215@NMFECC.ARPA> To: COMMON-LISP@SAIL.STANFORD.EDU Subject: LOOP macro Date: Thu, 2-MAR-1989 16:07 MST X-VMS-Mail-To: @CL I'm looking for a LOOP macro. Is it going to be in the new CL standard? If it is going to be in the standard, can someone tell me what the standard says about it? Unfortunately, I'm not sure what type of loop macro I'm looking for! I'm porting some code that is supposed to be CL except for the LOOP. It looks similar to the Symbolics LOOP. I know they at least use COLLECT, FOR, DO and probably lots more. If anyone can send be a relatively complete LOOP I can wing it from there. Please send replies directly to me at pothiers%tuva.sainet@nmfecc.arpa Thank Yew!  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 1 Mar 89 22:44:50 EST Received: from ALDERAAN.SCRC.Symbolics.COM ([128.81.41.109]) by SAIL.Stanford.EDU with TCP; 1 Mar 89 19:32:23 PST Received: from GANG-GANG.SCRC.Symbolics.COM by ALDERAAN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 276814; Wed 1-Mar-89 22:26:31 EST Date: Wed, 1 Mar 89 22:26 EST From: Glenn S. Burke Subject: Why do input functions need RECURSIVE-P argument? To: barmar@Think.COM, common-lisp@sail.stanford.edu In-Reply-To: <19890301201524.9.BARMAR@OCCAM.THINK.COM> Message-ID: <19890302032621.6.GSB@GANG-GANG.SCRC.Symbolics.COM> Date: Wed, 1 Mar 89 15:15 EST From: Barry Margolin Something has been bothering me for a while, and I was reminded about it when reading the latest version of the draft chapter on I/O for ANSI CL: why is the RECURSIVE-P argument necessary for Common Lisp input functions? I understand that it is necessary for an input function to know whether it is a top-level call or a recursive call, but that doesn't tell me why this must be an argument to the functions. The implementation could simply make use of a flag in the stream object, e.g. (defstruct stream ... (inside-input-function-p nil) ...) (defun read (&optional stream ...) ... (let ((recursive-p (stream-inside-input-function-p stream))) (unwind-protect (progn (setf (stream-inside-input-function-p stream) t) ...) (setf (stream-inside-input-function-p stream) recursive-p))) ...) The only justification for making it an argument would be to allow calls that actually are recursive to pretend that they aren't; however, I can't think of a legitimate reason to want to do this. And this provides an easy trap for read-macro programmers to fall into, when they accidentally forget to include the RECURSIVE-P argument. This won't work right on an interactive stream (*terminal-io*) when a new toplevel call to read can be initiated while within the dynamic scope of that unwind-protect body. It is true, however, that the same sort of stream encapsulation technology which can be used to handle sophisticated printing (to get around the lack of a recursive-p argument to the printing functions!) could be used by the reader. That is, recursive calls to read don't get the original stream argument, but some other stream which encapsulates other state of the read in progress. MacLisp didn't have a RECURSIVE-P argument and it worked OK in this regard, didn't it? No. Maclisp went to lots of effort to reset state on when stacking anything (error, interrupts, etc.). i.e., global knowledge about the state of the reader (and other things) was needed. barmar  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 1 Mar 89 15:29:51 EST Received: from Think.COM by SAIL.Stanford.EDU with TCP; 1 Mar 89 12:18:14 PST Return-Path: Received: from sauron.think.com by Think.COM; Wed, 1 Mar 89 15:14:26 EST Received: from OCCAM.THINK.COM by sauron.think.com; Wed, 1 Mar 89 15:12:30 EST Date: Wed, 1 Mar 89 15:15 EST From: Barry Margolin Subject: Why do input functions need RECURSIVE-P argument? To: common-lisp@sail.stanford.edu Message-Id: <19890301201524.9.BARMAR@OCCAM.THINK.COM> Something has been bothering me for a while, and I was reminded about it when reading the latest version of the draft chapter on I/O for ANSI CL: why is the RECURSIVE-P argument necessary for Common Lisp input functions? I understand that it is necessary for an input function to know whether it is a top-level call or a recursive call, but that doesn't tell me why this must be an argument to the functions. The implementation could simply make use of a flag in the stream object, e.g. (defstruct stream ... (inside-input-function-p nil) ...) (defun read (&optional stream ...) ... (let ((recursive-p (stream-inside-input-function-p stream))) (unwind-protect (progn (setf (stream-inside-input-function-p stream) t) ...) (setf (stream-inside-input-function-p stream) recursive-p))) ...) The only justification for making it an argument would be to allow calls that actually are recursive to pretend that they aren't; however, I can't think of a legitimate reason to want to do this. And this provides an easy trap for read-macro programmers to fall into, when they accidentally forget to include the RECURSIVE-P argument. MacLisp didn't have a RECURSIVE-P argument and it worked OK in this regard, didn't it? barmar  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 27 Feb 89 04:49:27 EST Received: from DST.BOLTZ.CS.CMU.EDU ([128.2.220.61]) by SAIL.Stanford.EDU with TCP; 27 Feb 89 01:39:51 PST Received: from DST.BOLTZ.CS.CMU.EDU by DST.BOLTZ.CS.CMU.EDU; 27 Feb 89 04:37:12 EST To: common-lisp@sail.stanford.edu Reply-To: Dave.Touretzky@cs.cmu.edu Subject: pluralization: two proposals Date: Mon, 27 Feb 89 04:37:06 EST Message-ID: <3127.604575426@DST.BOLTZ.CS.CMU.EDU> From: Dave.Touretzky@B.GP.CS.CMU.EDU The ~P format directive and its : and @ variants provide only the suffixes "s" and "ies". What about nouns whose singular forms end in "s" or "z"? They use "es" to form their plural, e.g. bus --> buses glass --> glasses buzz --> buzzes First, I propose that ~P and ~:P be modified to produce the "es" plural form instead of "s" when given a numeric argument of -1. Second, a more ambitious proposal: how about introducing a new conditional directive to handle arbitrary singular/plural distinctions: ~:@[ singular ~; plural ~] If the argument is EQL to 1, the first alternative is taken; otherwise the second alternative is taken. This lets you do neat things like: (format nil "There ~:@[is~;are~]~:* ~D~:* ~:@[wolf~;wolves~] here." 3) ==> "There are 3 wolves here." (format nil "There ~:@[is~;are~]~:* ~D~:* ~:@[wolf~;wolves~] here." 1) ==> "There is 1 wolf here." (format nil "Your tab comes to ~D~:* ~:@[wolfs'~;wolves'~] head~:P." -5) ==> "Your tab comes to -5 wolves' heads." (format nil "Your tab comes to ~D~:* ~:@[wolf's~;wolves'~] head~:P." 1) ==> "Your tab comes to 1 wolf's head." Notes: 1) The example with -5 shows why special plural forms can't simply be handled with an ordinary conditional by writing ~[plural~;singular~:;plural~] 2) The pluralization conditional is also useful for handling things like possessive forms (wolf's vs. wolves') and the verb "be" (is vs. are). -- Dave