Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 7 Oct 87 03:38:22 EDT Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 6 Oct 87 23:05:08 PDT Received: from relay2.cs.net by RELAY.CS.NET id ai03910; 7 Oct 87 1:24 EDT Received: from cs.umass.edu by RELAY.CS.NET id dg12948; 7 Oct 87 1:22 EDT Date: Tue, 6 Oct 87 19:00 EDT From: Kevin Gallagher Subject: Defstruct and CLOS To: Common-Lisp@SAIL.STANFORD.EDU X-VMS-To: IN%"Common-Lisp@Sail.Stanford.EDU" > From: "Daniel L. Weinreb" > > One idea that's been discussed that would do what you want, in fact do > something more general, is to redefine structures in terms of > object-oriented programming, if and after CLOS is accepted as part of > Common Lisp. The basic idea is that CLOS would have a defined mechanism > for talking about slots and their properties. I don't know whether > this idea is still current; I suspect it's mainly on the back burner > while the CLOS proposal itself is being finished. One reason people use structures rather than ``objects'' is that there is a significant overhead incurred by using objects. If defstruct were subsumed into an object oriented standard there should be a way of turning off all the power (and overhead) of the OOS. In particular, you don't want the defstruct accessor functions to become generic functions. Kevin Gallagher  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 7 Oct 87 02:59:19 EDT Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 6 Oct 87 23:05:08 PDT Received: from relay2.cs.net by RELAY.CS.NET id ai03910; 7 Oct 87 1:24 EDT Received: from cs.umass.edu by RELAY.CS.NET id dg12948; 7 Oct 87 1:22 EDT Date: Tue, 6 Oct 87 19:00 EDT From: Kevin Gallagher Subject: Defstruct and CLOS To: Common-Lisp@SAIL.STANFORD.EDU X-VMS-To: IN%"Common-Lisp@Sail.Stanford.EDU" > From: "Daniel L. Weinreb" > > One idea that's been discussed that would do what you want, in fact do > something more general, is to redefine structures in terms of > object-oriented programming, if and after CLOS is accepted as part of > Common Lisp. The basic idea is that CLOS would have a defined mechanism > for talking about slots and their properties. I don't know whether > this idea is still current; I suspect it's mainly on the back burner > while the CLOS proposal itself is being finished. One reason people use structures rather than ``objects'' is that there is a significant overhead incurred by using objects. If defstruct were subsumed into an object oriented standard there should be a way of turning off all the power (and overhead) of the OOS. In particular, you don't want the defstruct accessor functions to become generic functions. Kevin Gallagher  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 7 Oct 87 02:40:28 EDT Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 6 Oct 87 23:04:56 PDT Received: from relay2.cs.net by RELAY.CS.NET id ab03913; 7 Oct 87 1:24 EDT Received: from cs.umass.edu by RELAY.CS.NET id de12948; 7 Oct 87 1:22 EDT Date: Tue, 6 Oct 87 18:39 EDT From: Kevin Gallagher Subject: Extending Defstruct To: Common-Lisp@SAIL.STANFORD.EDU X-VMS-To: IN%"Common-Lisp@Sail.Stanford.EDU" I am glad to see the revival of the discussion of defstruct. I brought up this issue more than a year ago. At that time it got only one reply. The defstruct facility would be much more useful to layered systems builders if information about the defstruct definition was available. In addition, you should be able to access and update a slot in a structure via the slot name. Most implementations keep the necessary information around anyway. Simply being able to get the names of the accessor functions is not sufficient. This will enable you to access the value of a slot by using FUNCALL, but won't allow you to update the value of the slot because funcall is not a valid place form. I would like to see several functions added to the language: STRUCTURE-SLOT structure slot [Function] Returns the value of the slot in STRUCTURE specified by SLOT. STRUCTURE is a defstruct instance and SLOT is a symbol. SETF may be used with STRUCTURE-SLOT to modify a slot in a structure. STRUCTURE-SLOT-NAMES structure-type [Function] STRUCTURE-TYPE must be a type defined by DEFSTRUCT. This function returns a list of slot names for structures of that type. MAKE-STRUCTURE structure-type keyword-1 value-1 ... [Function] Creates an instance of a structure. STRUCTURE-TYPE is the type of structure to create. The rest of the arguments are the same as for the default constructor function. If a slot is not initialised by a slot-keyword, then the slot will be initialized with the default init form specified in the defstruct. STRUCTURE-OPTION structure-type option [Function] STRUCTURE-TYPE must be a type defined by defstruct. OPTION must be a defstruct option (e.g., :conc-name). This function returns the argument that was given to that option if an argument was given in the call to defstruct. Otherwise it returns the default value of that option. For example, after the defstruct on page 312, (structure-option 'astronaut :conc-name) ==> astro- STRUCTURE-SLOT-OPTION structure-type slot option [Function] STRUCTURE-TYPE must be a type defined by defstruct. SLOT is the name of a slot in that defstruct. OPTION must be a defstruct slot option (:type or :read-only). This function returns the argument that was given to that option if an argument was given in the call to defstruct. Otherwise it returns the default value of that option. DEFSTRUCTP symbol [Function] This function returns true if SYMBOL is the name of a defstruct type. Kevin Gallagher Gallagher@CS.UMass.EDU  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 7 Oct 87 02:33:17 EDT Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 6 Oct 87 23:05:08 PDT Received: from relay2.cs.net by RELAY.CS.NET id ai03910; 7 Oct 87 1:24 EDT Received: from cs.umass.edu by RELAY.CS.NET id dg12948; 7 Oct 87 1:22 EDT Date: Tue, 6 Oct 87 19:00 EDT From: Kevin Gallagher Subject: Defstruct and CLOS To: Common-Lisp@SAIL.STANFORD.EDU X-VMS-To: IN%"Common-Lisp@Sail.Stanford.EDU" > From: "Daniel L. Weinreb" > > One idea that's been discussed that would do what you want, in fact do > something more general, is to redefine structures in terms of > object-oriented programming, if and after CLOS is accepted as part of > Common Lisp. The basic idea is that CLOS would have a defined mechanism > for talking about slots and their properties. I don't know whether > this idea is still current; I suspect it's mainly on the back burner > while the CLOS proposal itself is being finished. One reason people use structures rather than ``objects'' is that there is a significant overhead incurred by using objects. If defstruct were subsumed into an object oriented standard there should be a way of turning off all the power (and overhead) of the OOS. In particular, you don't want the defstruct accessor functions to become generic functions. Kevin Gallagher  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 6 Oct 87 04:47:46 EDT Received: from RUTGERS.EDU by SAIL.STANFORD.EDU with TCP; 6 Oct 87 01:21:54 PDT Received: by RUTGERS.EDU (5.54/1.14) with UUCP id AA07346; Tue, 6 Oct 87 04:03:52 EDT Received: from pyrnova.pyramid.COM (manpyrnova) by pyramid.UUCP (5.51/OSx4.0b-870424) id AA05751; Mon, 5 Oct 87 23:29:04 PDT Received: by pyrnova.pyramid.COM (5.52/OSx4.0b-870424) id AA18870; Mon, 5 Oct 87 23:30:56 PDT Date: 5 Oct 1987 23:23-PDT From: David Bein Subject: multiple-value-bind pervasive-ness ... To: common-lisp@sail.stanford.edu@RUTGERS.EDU Message-Id: <560499808/bein@pyrnova> I know this must have come up before .. Is the scope of the declarations in a multiple-value-bind to include to evaluation of the form which produces the multiple-values? For example ... (SETQ A :SPECIAL-A) (DEFUN HACK (A) (MULTIPLE-VALUE-BIND (A SECOND-VALUE) (VALUES A 'DUMMY) (DECLARE (SPECIAL A)) (LIST A SECOND-VALUE))) Should (HACK :LEXICAL-A) return (:SPECIAL-A DUMMY) or (:LEXICAL-A DUMMY) ? The reason for the second-value is to avoid what a compiler might do as a rewrite to a let binding in which case the answer is fairly clear. If the answer is that the declaration does NOT apply to the evaluation of the value producing form, then a rewrite into the most obvious let is of course illegal. --David  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 5 Oct 87 17:11:54 EDT Received: from VENERA.ISI.EDU by SAIL.STANFORD.EDU with TCP; 5 Oct 87 11:41:13 PDT Posted-Date: Mon, 05 Oct 87 11:41:30 PDT Message-Id: <8710051841.AA24782@venera.isi.edu> Received: from LOCALHOST by venera.isi.edu (5.54/5.51) id AA24782; Mon, 5 Oct 87 11:41:41 PDT To: Common-Lisp@sail.stanford.edu, AILIST@sri.com Subject: CMU Common Lisp Distribution Date: Mon, 05 Oct 87 11:41:30 PDT From: Vicki L. Gordon With DARPA funding, the University of Southern California's Information Sciences Institute (USC/ISI) is serving as a distribution center for public-domain Common Lisp software packages. The first of these packages includes the source files for CMU Common Lisp (formerly known as "Spice Lisp"). The package also includes an unsupported public-domain version of the OPS5 language that is written in Common Lisp. If there is sufficient interest, and if funding allows, we will later expand the distribution program to include additional software packages from other sources. CMU Common Lisp is a full implementation of Common Lisp, developed as part of the Spice project at Carnegie-Mellon University (CMU). This system runs only on the IBM RT PC, and only under CMU's Mach operating system (superficially similar to 4.3bsd Unix, but with a different internal organization). Since the IBM RT version of Mach is not currently supported outside of CMU, it follows that CMU Common Lisp is *NOT* a system that anyone can obtain and run as is. We are making the sources for this system available because a number of groups have found it to be a useful starting point for their own Common Lisp implementations. Typically, it takes a man-year of effort to port this system to a new machine and operating system (more if the target environment is unusual). Individuals and small research groups who want a Common Lisp for their own use are advised to use one of the commercially available products. This source code is in the public domain and, once you have them, there is no restriction on how you may use them. They are made available as a public service, with no warranty of any sort by the authors, CMU, or USC/ISI, and with no promise of future support. CMU Common Lisp has been heavily used at CMU, but it has not been extensively tested in any systematic way. Questions about the distribution procedure may be directed via electronic mail to ACTION@ISI.EDU, or you may call (213) 822-5511. Bug reports and questions about the code itself should also be directed to SCOTT.FAHLMAN@CS.CMU.EDU. This distribution package contains approximately 7 megabytes of ASCII source files. It can be obtained over the Arpanet/Milnet by establishing an FTP connection to VENERA.ISI.EDU and logging in as "anonymous" (any password can be used). For optimal response time, please conduct your file transfer during our non-primetime hours (1800 to 0800 PDT). The source files are kept in the following directories: /common-lisp/implementation/cmu/code (Runtime system and interpreter for CMU Common Lisp on IBM RT PC under Mach) /common-lisp/implementation/cmu/clc (Compiler from Common Lisp to native code for RT/Mach. Mostly written in Common Lisp itself.) /common-lisp/implementation/cmu/hemlock (Sources for the Hemlock text editor. This editor is similar at user level to Emacs. Written in Common Lisp, but contains some Mach-specific system calls and display code. Uses either X windows or standard termcap terminals.) /common-lisp/implementation/cmu/OPS5 (Portable Common Lisp version of the OPS5 production-system language. A quick and dirty port of the public domain version that was developed originally in Franz Lisp. No support whatsoever is provided.) /common-lisp/implementation/cmu/miscops (Low level support routines for the IBM PC RT: garbage collection, generic arithmetic, etc. Totally machine-specific. Provided as an example of what needs to be done in order to port this lisp to another machine.) /common-lisp/implementation/cmu/icode (Lisp functions implementing the interface between Mach and CMU Common Lisp. Very system-specific. Provided only as an example.) /common-lisp/implementation/cmu/lib (Cursor definition file and spelling dictionary used by the Lisp runtime system). If you would like to order a tape, we will first send you a release form which you are required to sign prior to receiving the tape. When you return the signed release, include a check made payable to USC/Information Sciences Institute for $100.00 to cover the production and mailing costs. Please remember to include a complete return address. The default tape format will be tar 1600 bpi, unless otherwise specified. Currently ISI is only prepared to distribute tapes containing the CMU Common Lisp code to individuals or companies within the United States. We are currently negotiating with the Department of Commerce and CMU to obtain authorization to distribute the code to countries outside of the United States; however, we do not expect approval in the immediate future. The following hardcopy documentation produced by CMU is also available to all recipients at a cost of $20.00 per package (payable to USC/ Information Sciences Institute). The package includes: - "Internal Design of Common Lisp on the IBM RT PC" - "CMU Common Lisp User's Manual, Mach/IBM RT PC Edition" - "Hemlock User's Manual" - "Hemlock Command Implementor's Manual" Please send your request for a tape and/or documentation to ACTION@ISI.EDU, or mail it to the following address: USC/Information Sciences Institute Attn: ACTION 4676 Admiralty Way Marina del Rey, CA 90292 (213) 822-1511 ext 289  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 5 Oct 87 16:03:52 EDT Received: from VENERA.ISI.EDU by SAIL.STANFORD.EDU with TCP; 5 Oct 87 11:41:13 PDT Posted-Date: Mon, 05 Oct 87 11:41:30 PDT Message-Id: <8710051841.AA24782@venera.isi.edu> Received: from LOCALHOST by venera.isi.edu (5.54/5.51) id AA24782; Mon, 5 Oct 87 11:41:41 PDT To: Common-Lisp@sail.stanford.edu, AILIST@sri.com Subject: CMU Common Lisp Distribution Date: Mon, 05 Oct 87 11:41:30 PDT From: Vicki L. Gordon With DARPA funding, the University of Southern California's Information Sciences Institute (USC/ISI) is serving as a distribution center for public-domain Common Lisp software packages. The first of these packages includes the source files for CMU Common Lisp (formerly known as "Spice Lisp"). The package also includes an unsupported public-domain version of the OPS5 language that is written in Common Lisp. If there is sufficient interest, and if funding allows, we will later expand the distribution program to include additional software packages from other sources. CMU Common Lisp is a full implementation of Common Lisp, developed as part of the Spice project at Carnegie-Mellon University (CMU). This system runs only on the IBM RT PC, and only under CMU's Mach operating system (superficially similar to 4.3bsd Unix, but with a different internal organization). Since the IBM RT version of Mach is not currently supported outside of CMU, it follows that CMU Common Lisp is *NOT* a system that anyone can obtain and run as is. We are making the sources for this system available because a number of groups have found it to be a useful starting point for their own Common Lisp implementations. Typically, it takes a man-year of effort to port this system to a new machine and operating system (more if the target environment is unusual). Individuals and small research groups who want a Common Lisp for their own use are advised to use one of the commercially available products. This source code is in the public domain and, once you have them, there is no restriction on how you may use them. They are made available as a public service, with no warranty of any sort by the authors, CMU, or USC/ISI, and with no promise of future support. CMU Common Lisp has been heavily used at CMU, but it has not been extensively tested in any systematic way. Questions about the distribution procedure may be directed via electronic mail to ACTION@ISI.EDU, or you may call (213) 822-5511. Bug reports and questions about the code itself should also be directed to SCOTT.FAHLMAN@CS.CMU.EDU. This distribution package contains approximately 7 megabytes of ASCII source files. It can be obtained over the Arpanet/Milnet by establishing an FTP connection to VENERA.ISI.EDU and logging in as "anonymous" (any password can be used). For optimal response time, please conduct your file transfer during our non-primetime hours (1800 to 0800 PDT). The source files are kept in the following directories: /common-lisp/implementation/cmu/code (Runtime system and interpreter for CMU Common Lisp on IBM RT PC under Mach) /common-lisp/implementation/cmu/clc (Compiler from Common Lisp to native code for RT/Mach. Mostly written in Common Lisp itself.) /common-lisp/implementation/cmu/hemlock (Sources for the Hemlock text editor. This editor is similar at user level to Emacs. Written in Common Lisp, but contains some Mach-specific system calls and display code. Uses either X windows or standard termcap terminals.) /common-lisp/implementation/cmu/OPS5 (Portable Common Lisp version of the OPS5 production-system language. A quick and dirty port of the public domain version that was developed originally in Franz Lisp. No support whatsoever is provided.) /common-lisp/implementation/cmu/miscops (Low level support routines for the IBM PC RT: garbage collection, generic arithmetic, etc. Totally machine-specific. Provided as an example of what needs to be done in order to port this lisp to another machine.) /common-lisp/implementation/cmu/icode (Lisp functions implementing the interface between Mach and CMU Common Lisp. Very system-specific. Provided only as an example.) /common-lisp/implementation/cmu/lib (Cursor definition file and spelling dictionary used by the Lisp runtime system). If you would like to order a tape, we will first send you a release form which you are required to sign prior to receiving the tape. When you return the signed release, include a check made payable to USC/Information Sciences Institute for $100.00 to cover the production and mailing costs. Please remember to include a complete return address. The default tape format will be tar 1600 bpi, unless otherwise specified. Currently ISI is only prepared to distribute tapes containing the CMU Common Lisp code to individuals or companies within the United States. We are currently negotiating with the Department of Commerce and CMU to obtain authorization to distribute the code to countries outside of the United States; however, we do not expect approval in the immediate future. The following hardcopy documentation produced by CMU is also available to all recipients at a cost of $20.00 per package (payable to USC/ Information Sciences Institute). The package includes: - "Internal Design of Common Lisp on the IBM RT PC" - "CMU Common Lisp User's Manual, Mach/IBM RT PC Edition" - "Hemlock User's Manual" - "Hemlock Command Implementor's Manual" Please send your request for a tape and/or documentation to ACTION@ISI.EDU, or mail it to the following address: USC/Information Sciences Institute Attn: ACTION 4676 Admiralty Way Marina del Rey, CA 90292 (213) 822-1511 ext 289  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 5 Oct 87 15:13:50 EDT Received: from VENERA.ISI.EDU by SAIL.STANFORD.EDU with TCP; 5 Oct 87 11:41:13 PDT Posted-Date: Mon, 05 Oct 87 11:41:30 PDT Message-Id: <8710051841.AA24782@venera.isi.edu> Received: from LOCALHOST by venera.isi.edu (5.54/5.51) id AA24782; Mon, 5 Oct 87 11:41:41 PDT To: Common-Lisp@sail.stanford.edu, AILIST@sri.com Subject: CMU Common Lisp Distribution Date: Mon, 05 Oct 87 11:41:30 PDT From: Vicki L. Gordon With DARPA funding, the University of Southern California's Information Sciences Institute (USC/ISI) is serving as a distribution center for public-domain Common Lisp software packages. The first of these packages includes the source files for CMU Common Lisp (formerly known as "Spice Lisp"). The package also includes an unsupported public-domain version of the OPS5 language that is written in Common Lisp. If there is sufficient interest, and if funding allows, we will later expand the distribution program to include additional software packages from other sources. CMU Common Lisp is a full implementation of Common Lisp, developed as part of the Spice project at Carnegie-Mellon University (CMU). This system runs only on the IBM RT PC, and only under CMU's Mach operating system (superficially similar to 4.3bsd Unix, but with a different internal organization). Since the IBM RT version of Mach is not currently supported outside of CMU, it follows that CMU Common Lisp is *NOT* a system that anyone can obtain and run as is. We are making the sources for this system available because a number of groups have found it to be a useful starting point for their own Common Lisp implementations. Typically, it takes a man-year of effort to port this system to a new machine and operating system (more if the target environment is unusual). Individuals and small research groups who want a Common Lisp for their own use are advised to use one of the commercially available products. This source code is in the public domain and, once you have them, there is no restriction on how you may use them. They are made available as a public service, with no warranty of any sort by the authors, CMU, or USC/ISI, and with no promise of future support. CMU Common Lisp has been heavily used at CMU, but it has not been extensively tested in any systematic way. Questions about the distribution procedure may be directed via electronic mail to ACTION@ISI.EDU, or you may call (213) 822-5511. Bug reports and questions about the code itself should also be directed to SCOTT.FAHLMAN@CS.CMU.EDU. This distribution package contains approximately 7 megabytes of ASCII source files. It can be obtained over the Arpanet/Milnet by establishing an FTP connection to VENERA.ISI.EDU and logging in as "anonymous" (any password can be used). For optimal response time, please conduct your file transfer during our non-primetime hours (1800 to 0800 PDT). The source files are kept in the following directories: /common-lisp/implementation/cmu/code (Runtime system and interpreter for CMU Common Lisp on IBM RT PC under Mach) /common-lisp/implementation/cmu/clc (Compiler from Common Lisp to native code for RT/Mach. Mostly written in Common Lisp itself.) /common-lisp/implementation/cmu/hemlock (Sources for the Hemlock text editor. This editor is similar at user level to Emacs. Written in Common Lisp, but contains some Mach-specific system calls and display code. Uses either X windows or standard termcap terminals.) /common-lisp/implementation/cmu/OPS5 (Portable Common Lisp version of the OPS5 production-system language. A quick and dirty port of the public domain version that was developed originally in Franz Lisp. No support whatsoever is provided.) /common-lisp/implementation/cmu/miscops (Low level support routines for the IBM PC RT: garbage collection, generic arithmetic, etc. Totally machine-specific. Provided as an example of what needs to be done in order to port this lisp to another machine.) /common-lisp/implementation/cmu/icode (Lisp functions implementing the interface between Mach and CMU Common Lisp. Very system-specific. Provided only as an example.) /common-lisp/implementation/cmu/lib (Cursor definition file and spelling dictionary used by the Lisp runtime system). If you would like to order a tape, we will first send you a release form which you are required to sign prior to receiving the tape. When you return the signed release, include a check made payable to USC/Information Sciences Institute for $100.00 to cover the production and mailing costs. Please remember to include a complete return address. The default tape format will be tar 1600 bpi, unless otherwise specified. Currently ISI is only prepared to distribute tapes containing the CMU Common Lisp code to individuals or companies within the United States. We are currently negotiating with the Department of Commerce and CMU to obtain authorization to distribute the code to countries outside of the United States; however, we do not expect approval in the immediate future. The following hardcopy documentation produced by CMU is also available to all recipients at a cost of $20.00 per package (payable to USC/ Information Sciences Institute). The package includes: - "Internal Design of Common Lisp on the IBM RT PC" - "CMU Common Lisp User's Manual, Mach/IBM RT PC Edition" - "Hemlock User's Manual" - "Hemlock Command Implementor's Manual" Please send your request for a tape and/or documentation to ACTION@ISI.EDU, or mail it to the following address: USC/Information Sciences Institute Attn: ACTION 4676 Admiralty Way Marina del Rey, CA 90292 (213) 822-1511 ext 289  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 2 Oct 87 13:57:35 EDT Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 2 Oct 87 10:33:11 PDT Received: from PinotNoir.ms by ArpaGateway.ms ; 02 OCT 87 10:21:21 PDT Date: 2 Oct 87 10:20 PDT From: ghenis.pasa@Xerox.COM Subject: Re: [KAHLE@Aquinas.Think.COM: defstruct request for common lisp] In-reply-to: Barry Margolin 's message of Thu, 1 Oct 87 23:16 EDT To: barmar@Think.COM cc: ghenis.pasa@Xerox.COM, common-lisp@sail.stanford.edu Message-ID: <871002-102121-5691@Xerox> What limitation are you talking about? Structure slot names are also the names of functions, which can be FUNCALLed. Thus, one could write (defun show-structure-slots (structure) (dolist (slot (structure-slots (type-of structure))) (format t "~A: ~S" slot (funcall slot structure)))) Mea culpa for reading too literally. I was (narrowly) thinking of the semantics of STRUCTURE-SLOTS as returning slot NAMES, which would be of very little use. Your interpretation could be better called STRUCTURE-ACCESSORS and its output is truly useful. From that point of view Kahle's request makes a lot more sense... Pablo Ghenis  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 2 Oct 87 08:24:26 EDT Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 2 Oct 87 05:02:01 PDT Return-Path: Received: from occam by Think.COM via CHAOS; Thu, 1 Oct 87 23:14:21 EDT Date: Thu, 1 Oct 87 23:16 EDT From: Barry Margolin Subject: Re: [KAHLE@Aquinas.Think.COM: defstruct request for common lisp] To: Pablo Ghenis Cc: DLW@alderaan.scrc.symbolics.com, gls@Think.COM, common-lisp@sail.stanford.edu In-Reply-To: <871001-172543-4788@Xerox> Message-Id: <871001231654.3.BARMAR@OCCAM.THINK.COM> Date: 1 Oct 87 17:25 PDT From: Pablo Ghenis What useful things could one do with the output of (structure-slots ), given that the choice of slot to access cannot be gracefully deferred until run-time the way p-lists allow? I'm afraid that a "structure-slots" function wouldn't be all that valuable because of this deeper limitation of structures. What limitation are you talking about? Structure slot names are also the names of functions, which can be FUNCALLed. Thus, one could write (defun show-structure-slots (structure) (dolist (slot (structure-slots (type-of structure))) (format t "~A: ~S" slot (funcall slot structure)))) You may have been thinking of Maclisp and Zetalisp defstruct, which defined the accessors as macros, so they couldn't be FUNCALLed. Common Lisp fixed this. barmar  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 1 Oct 87 23:53:29 EDT Received: from CS.UTAH.EDU by SAIL.STANFORD.EDU with TCP; 1 Oct 87 20:24:53 PDT Received: by cs.utah.edu (5.54/utah-1.0) id AA06847; Thu, 1 Oct 87 21:24:42 MDT Received: by orion.utah.edu (5.54/utah-1.0-slave) id AA18914; Thu, 1 Oct 87 21:24:37 MDT Date: Thu, 1 Oct 87 21:24:37 MDT From: sandra%orion@cs.utah.edu (Sandra J Loosemore) Message-Id: <8710020324.AA18914@orion.utah.edu> Subject: defstruct slot info To: common-lisp@sail.stanford.edu Pablo Ghenis writes: > What useful things could one do with the output of (structure-slots > ), given that the choice of slot to access cannot be > gracefully deferred until run-time the way p-lists allow? I'm afraid > that a "structure-slots" function wouldn't be all that valuable because > of this deeper limitation of structures. If the function returned more information than just the slot names -- like the name of the accessor function for each slot, and maybe the :type and :read-only flags -- then it would be very useful. For example, I could implement a portable data structure browser. Basically, I'd like to be able to display a structure as a box with labelled sub-boxes to show (and maybe modify) the slot values. Without an inquiry function, about the only alternative is to redefine DEFSTRUCT to cache the information I need. I definitely want to avoid forcing users (who are probably having enough troubles already if they're resorting to the use of this kind of debugging tool) to define a special "browser" function for each structure type they use, akin to the structure print function. My experience is that many (most? all?) implementations already cache at least the slot descriptor information around somewhere, since it's used when you :include the structure type in another. Incidentally, my gripe with structures right now has to do with the "maybe modify" the slot values part -- because of the reliance on SETF, I have to construct and EVAL a piece of code, when I would really much rather just FUNCALL a setter function.... -Sandra -------  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 1 Oct 87 21:46:13 EDT Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 1 Oct 87 18:16:09 PDT Received: from PinotNoir.ms by ArpaGateway.ms ; 01 OCT 87 17:25:43 PDT Date: 1 Oct 87 17:25 PDT Sender: ghenis.pasa@Xerox.COM Subject: Re: [KAHLE@Aquinas.Think.COM: defstruct request for common lisp] In-reply-to: Daniel L. Weinreb 's message of Mon, 21 Sep 87 09:50 EDT To: DLW@ALDERAAN.SCRC.Symbolics.COM cc: gls@Think.COM, common-lisp@sail.stanford.edu, Ghenis.Pasa@Xerox.COM from: Pablo Ghenis Message-ID: <871001-172543-4788@Xerox> I wish there were a function like: (structure-slots ) that returns the list of slots of a defstruct. One idea that's been discussed that would do what you want, in fact do something more general, is to redefine structures in terms of object-oriented programming, if and after CLOS is accepted as part of ... What useful things could one do with the output of (structure-slots ), given that the choice of slot to access cannot be gracefully deferred until run-time the way p-lists allow? I'm afraid that a "structure-slots" function wouldn't be all that valuable because of this deeper limitation of structures. I'm not knocking structures though. The no-free-lunch rule indicates that if one wants such dynamic slot selection then there will be a price to pay at run-time. What this points out is the current lack of a data structure in CL that provides a fixed number of named slots AND run-time choice of slot to access. Perhaps the following table (off the top of my keyboard) can highlight the characteristics of CL's data structures and the (missing) functionality that objects will add to the language. This should graphically reinforce your point that the needs that Brewster Kahle originally had in mind might be properly addressed only by CLOS Some Common Lisp Data Structures and their usage ------------------------------------------------ | CLOS Arrays Structures P-Lists A-Lists | Objects? | | Numerically | indexed | access * | | "Labeled" | access * * * | * | Fixed # | of "slots" * * | * | Dynamic | labels (1) * * * | * | Destructively | update * * * (2) | * (1) The name of the slot to be accessed can be determined at run-time (impossible with structures, barring some horrible kludge) (2) Possible but the general case is more trouble than with P-Lists, where (setf (getf plist key) newvalue) suffices for old OR NEW keys.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 1 Oct 87 11:26:09 EDT Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 1 Oct 87 08:02:04 PDT Received: ID ; Thu 1 Oct 87 10:59:54-EDT Date: Thu, 1 Oct 1987 10:59 EDT Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: ghenis.pasa@XEROX.COM Cc: common-lisp@SAIL.STANFORD.EDU Subject: Source code non-access (Re: defstruct request) In-reply-to: Msg of 30 Sep 1987 15:19-EDT from ghenis.pasa at Xerox.COM If it is true that definitions cannot be programmatically reconstructed in Common Lisp, was this an explicit committee decision? It has never been the case in the Maclisp world that all of the information is the source program is preserved at runtime, especially in the case where the code you load is compiled. Implementations do various things to make the original information available for debugging purposes, but this has always been considered an environment issue -- a debugging aid, mostly -- and not a part of the language proper. For example, some implementations "macro-memoize" (replace a macro call with its expansion) in the interpreter, and many of these expanders keep track of the original macro form so that the expansion can be undone if the macro is altered at runtime; some keep track of what forms were created by character macros in the reader so that the printer can perform the inverse transform; some annotate each compiled function with a pointer back into the proper place in the original source file. But the language spec does not require any of this. The tradition in Interlisp is different, since the runtime image is considered to be the primary form of a program with which the user interacts; in Maclisp, you go back to the source file to make changes, usually using some Emacs-like editor. Therefore, in Interlisp, all of the information about a program must be included in or accessible from the runtime program. The Common Lisp design tries to accommodate this style of interaction, but not to require it. I don't think that it was ever an explicit decision of the design group that the language would not require that all information in the source be preserved at runtime; it was simply an assumption that was never challenged. The question did come up whether we should require an Interlisp-style or an Emacs-style editing environment, and it was clear that Common Lisp would not be accepted unless it accommodated both styles, but required neither. -- Scott  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 30 Sep 87 17:22:26 EDT Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 30 Sep 87 13:50:45 PDT Received: from PinotNoir.ms by ArpaGateway.ms ; 30 SEP 87 12:20:12 PDT Date: 30 Sep 87 12:19 PDT From: ghenis.pasa@Xerox.COM Subject: Source code non-access (Re: defstruct request) In-reply-to: gls@Think.COM's message of Fri, 18 Sep 87 14:43:08 EDT To: gls@Think.COM cc: common-lisp@sail.stanford.edu Message-ID: <870930-122012-2377@Xerox> This looks like a special case of a larger issue in Common Lisp. Unless I have misread the spec it looks like definitions cannot be reconstructed programmatically. What I mean is that once you type/load a DEFSTRUCT, there is no body of CL code that can reconstruct the expression as originally typed/loaded. This also appears to be true for DEFUN, DEFMACRO, etc. Please tell me I'm wrong! Interestingly, this seems to be possible in some implementations of CL when running interpreted code, only that it is done in implementation-specific (yeech!) ways. If it is true that definitions cannot be programmatically reconstructed in Common Lisp, was this an explicit committee decision?  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 29 Sep 87 17:13:43 EDT Received: from BCO-MULTICS.ARPA by SAIL.STANFORD.EDU with TCP; 29 Sep 87 13:49:05 PDT Received: FROM HIS-PHOENIX-MULTICS.ARPA BY BCO-MULTICS.ARPA WITH dial; 29 SEP 1987 16:46:51 EDT Date: Tue, 29 Sep 87 13:42 MST From: Bob May Subject: New Member Questions Reply-To: May%pco@BCO-MULTICS.ARPA To: <@BCO-MULTICS.ARPA:Common-Lisp@SAIL.STANFORD.EDU> Message-ID: <870929204215.288214@HIS-PHOENIX-MULTICS.ARPA> Hello. We have just joined this meeting. Would the chairperson send me info about obtaining the archive files? I am also trying to find a good connection for the CL-VALIDATION mailing list that was mentioned a while back. Can someone please post that information or send me mail? Thanks, Robert M. May (Bob) Honeywell Bull Phoenix, Arizona  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 28 Sep 87 14:37:22 EDT Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 28 Sep 87 11:11:29 PDT Received: from Cabernet.ms by ArpaGateway.ms ; 28 SEP 87 11:07:50 PDT Date: 28 Sep 87 11:04 PDT From: Masinter.pa@Xerox.COM Subject: Re: Japanese Activities toward Lisp Standardization In-reply-to: yuasa%kurims.kurims.kyoto-u.junet's message of 24 Sep 87 03:55 To: yuasa%kurims.kurims.kyoto-u.junet@utokyo-relay.cs.net cc: Common-Lisp@sail.stanford.edu from: Cl-Cleanup@Sail.stanford.edu reply-to: CL-Cleanup@Sail.stanford.edu Message-ID: <870928-110750-18955@Xerox> In the United States, the X3J13 committee of ANSI is progressing toward establishing a standard for Lisp. As with TG/A, X3J13 has agreed that Common Lisp is a good starting point for technical discussions. We have also been discussing various technical deficiencies of Common Lisp and proposals for their correction. The Lisp community as a whole can be best served if there are not too many standards. We would like to invite a member TG/A to participate in the discussions of the "cleanup" working group of X3J13, and to bring forward those technical deficiencies that are of most serious concern to TG/A. Fortunately, almost all of our work goes on using electronic mail. We would welcome active participation, argumentation, proposals and criticisms. --- The "cleanup" committee  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 27 Sep 87 17:47:44 EDT Received: from HPLABS.HP.COM by SAIL.STANFORD.EDU with TCP; 27 Sep 87 14:23:02 PDT Received: from hplabsz.hpl.hp.com by hplms2; Sun, 27 Sep 87 14:22:26 pdt Return-Path: Received: from hplabsz by hplabsz; Sun, 27 Sep 87 15:23:24 pdt To: Masinter.pa@Xerox.COM Cc: common-lisp@sail.stanford.edu Subject: Re: STREAM-CLASS-ACCESS X-Mailer: mh6.5 In-Reply-To: Your message of 24 Sep 87 12:08:00 -0700. <870924-120839-15432@Xerox> Date: Sun, 27 Sep 87 15:23:22 MST Message-Id: <11726.559776202@hplabsz> From: kempf%hplabsz@hplabs.HP.COM > I can't find any responses to this mail. I wonder if some of the stream > options might be easier to access if STREAM were a class under CLOS. I would agree with this. It would certainly make writing an extensible window system, perhaps based on CommonWindows, easier. Jim Kempf kempf@hplabs.hp.com  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 25 Sep 87 12:56:12 EDT Received: from BCO-MULTICS.ARPA by SAIL.STANFORD.EDU with TCP; 25 Sep 87 09:30:26 PDT Received: FROM HIS-PHOENIX-MULTICS.ARPA BY BCO-MULTICS.ARPA WITH dial; 25 SEP 1987 12:25:47 EDT Date: Fri, 25 Sep 87 09:25 MST From: Paul Dickson Subject: Please add us to you mailing list Reply-To: Paul Dickson To: <@BCO-MULTICS.ARPA:Common-Lisp@SAIL.STANFORD.EDU> Message-ID: <870925162504.600016@HIS-PHOENIX-MULTICS.ARPA> Please add us to your mailing list. Our mailing address is: Common-Lisp-mtg%pco @ BCO-Multics.ARPA Thanks. Paul Dickson Dickson%pco@BCO-Multics.ARPA  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 24 Sep 87 20:11:31 EDT Received: from SCRC-YUKON.ARPA by SAIL.STANFORD.EDU with TCP; 24 Sep 87 16:31:31 PDT Received: from WHITE-BIRD.SCRC.Symbolics.COM by YUKON.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 266632; Thu 24-Sep-87 19:08:50 EDT Date: Thu, 24 Sep 87 19:09 EDT From: Robert W. Kerns Subject: Synonym streams To: DON%atc.bendix.com@RELAY.CS.NET cc: common-lisp@SAIL.STANFORD.EDU In-Reply-To: The message of 23 Sep 87 15:34 EDT from DON%atc.bendix.com@RELAY.CS.NET Message-ID: <870924190915.8.RWK@WHITE-BIRD.SCRC.Symbolics.COM> Date: Wed, 23 Sep 87 15:34 EDT From: DON%atc.bendix.com@RELAY.CS.NET Is a synonym-stream a stream? Can a stream be a synonym of a synonym-stream? On the LMI, I tried (defvar *describe-output* (make-synonym-stream '*standard-output*)) Because *standard-output* is by default a synonym of *terminal-io*, *describe- output* became a synonym for a synonym. When I tried printing to *describe-stream*, the system hung. It did not hang if I used *terminal-io* in place of *standard-output*. LMI's technical support agreed that in spirit it should work; however, CLtL is ambiguous or at least not complete. The problem, of course, is that if a synonym-stream is a stream but cannot be the synonym for another stream, then there must be some function for testing whether a stream is a synonym or a real stream. (synonym-stream-p). Do other systems support using *standard-output* as a synonym? It works in Symbolics Common Lisp. CLtL appears to be completely unambiguous to my eyes. Yes, it doesn't explicitly state the logical consequences, but "any operations on the new stream will be performed on the stream that is then the value of the dynamic variable named by the @I(symbol)" seems clear enough. I'm not arguing that there's no need to elucidate further in the next manual, but that's an editorial issue that I won't take up on this list.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 24 Sep 87 15:32:29 EDT Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 24 Sep 87 12:10:16 PDT Received: from Cabernet.ms by ArpaGateway.ms ; 24 SEP 87 12:08:39 PDT Date: 24 Sep 87 12:08 PDT From: Masinter.pa@Xerox.COM Subject: STREAM-CLASS-ACCESS In-reply-to: "DON%atc.bendix.com%RELAY.CS.NET":GV:Xerox's message of 23 Sep 87 20:49 To: DON%atc.bendix.com@RELAY.CS.NET cc: common-lisp@sail.stanford.edu Message-ID: <870924-120839-15432@Xerox> I can't find any responses to this mail. I wonder if some of the stream options might be easier to access if STREAM were a class under CLOS. Date: Fri, 19 Dec 86 15:19 EST From: Kent M Pitman Subject: FOLLOW-SYNONYM-STREAM To: Common-Lisp@SAIL.STANFORD.EDU Message-ID: <861219151955.2.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> From time to time, I find myself doing: (LET ((*TERMINAL-IO* *STANDARD-OUTPUT*)) ...) in a multi-window system in order to temporarily change my interaction to the same window as output has been redirected to. On the Lisp Machine (and probably on many or most other implementations), *STANDARD-OUTPUT* can sometimes (often) contain a synonym-stream for *TERMINAL-IO* and the result of the operation above is to send output to a stream which is a (circular) synonym for itself. The kind of lossage this results in is fairly severe because *DEBUG-IO* is often a synonym for *TERMINAL-IO* and if that is in turn a synonym for *TERMINAL-IO*, then the debugger cannot run. A couple of things would make this problem more tractable: SYNONYM-STREAM-P object [Function] This accepts any kind of argument. If the argument is not a synonym stream, then NIL is returned. If the argument is a synonym stream, then the symbol for which the object is a synonym is returned. FOLLOW-SYNONYM-STREAM stream [Function] This accepts a stream and returns the result of following that stream through any number of synonym stream indirections (including zero). While I'm on page 329, I think we should also have the following functions (or functionalities) which I have needed at other times: BROADCAST-STREAM-P object [Function] CONCATENATED-STREAM-P stream [Function] TWO-WAY-STREAM-P [Function] ... This accepts any kind of argument. It returns T if the argument is a {concatenated/broadcast/two-way/...} stream and NIL if the argument is any other kind of stream. EXPAND-BROADCAST-STREAM broadcast-stream [Function] EXPAND-CONCATENATED-STREAM concatenated-stream [Function] EXPAND-TWO-WAY-STREAM two-way-stream [Function] ... This accepts a {broadcast/concatenated/two-way/...} stream and returns a list of the streams which were used to compose it (in an order compatible with the order of arguments to the creation function). Note: Implementations are allowed, but not required, to return the same list every time. The result list should not be destructively modified. ----- End Forwarded Messages -----  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 24 Sep 87 06:39:10 EDT Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 24 Sep 87 03:12:21 PDT Received: from relay2.cs.net by RELAY.CS.NET id aa25267; 24 Sep 87 6:13 EDT Received: from utokyo-relay by RELAY.CS.NET id ax09298; 24 Sep 87 5:59 EDT Received: by ccut.cc.u-tokyo.junet (5.51/6.2.9Junet) id AA23712; Thu, 24 Sep 87 17:39:28 JST Received: by titcca.cc.titech.junet (4.12/6.2Junet) id AA00456; Thu, 24 Sep 87 17:14:08 jst Received: by nttlab.NTT (4.12/6.2NTT.g) with TCP; Thu, 24 Sep 87 15:58:29 jst Received: by kuis.kuis.kyoto-u.junet (2.0/6.2Junet) id AA16002; Thu, 24 Sep 87 14:50:16 jst Received: by kurims.kurims.kyoto-u.junet (3.2/6.2Junet) id AA01955; Thu, 24 Sep 87 14:35:50 JST Date: Thu, 24 Sep 87 14:35:50 JST From: Taiichi Yuasa Return-Path: Message-Id: <8709240535.AA01955@kurims.kurims.kyoto-u.junet> To: common-lisp@SAIL.STANFORD.EDU Subject: Japanese Activities toward Lisp Standardization Japanese Activities toward Lisp Standardization The demand for Lisp standardization has been growing rapidly in Japanese computer industries and academic organizations. AIST (Agency of Industrial Science and Technology), which is responsible for Japan Industrial Standards (JIS in short), has initiated its activity toward JIS Lisp standardization. In April 1986, in response to the request from AIST, a working group for Lisp standardization was formed at JEIDA (Japan Electronic Industry Development Association). After one year's preliminary discussions, the following committee "JEIDA Committee for Lisp Standardization" was formed and its active efforts have begun in June 1987. The aim of this committee is to develop a Lisp language specification suitable for JIS standard in cooperation with ISO and the organizations for Lisp standardization in other countries. JEIDA Committee for Lisp Standardization ---------------------------------------- Chairman: Takayasu Ito (Tohoku University) Secretaries: Tsuneo Furuyama (NTT: Nippon Telegraph and Telephone Corp.) Fumio Motoyoshi (ETL: Electrotechnical Laboratory) Taiichi Yuasa (Kyoto University) Members from Major Computer Companies: Fujitsu Ltd. Hitachi Ltd. IBM Japan Ltd. Mitsubishi Electric Corp. NEC Corp. Oki Electric Industry Co. Ltd. Toshiba Corp. Observers: Masayuki Ida (Aoyama Gakuin University) Tetsuo Ida (The Institute of Physical and Chemical Research) Ryo Kamito (AIST) Masakazu Nakanishi (Keio University) Takehisa Nireki (JEIDA) Kentaro Shimizu (University of Tokyo) Technical issues for Lisp standardization will be discussed by the subsidiary working group "JEIDA Technical Working Group for Lisp Standardization", or TG/A in short. This group started technical discussions soon after it was formed in August 1987. It has been agreed that Common Lisp is a good starting point for technical discussions. But various technical deficiencies of Common Lisp have been already pointed out at TG/A. The role of TG/A is to clear up major technical issues for Lisp standardization, continuing detailed technical examinations on Common Lisp and other Lisp dialects. JEIDA Technical Working Group for Lisp Standardization ------------------------------------------------------ Chairman: Taiichi Yuasa (Research Institute for Mathematical Sciences, Kyoto University) Members: Takashi Chikayama (ICOT) Etsuya Shibayama (Dept. of Information Science, Tokyo Institute of Technology) Kentaro Shimizu (Dept. of Information Science, University of Tokyo) Akikazu Takeuchi (Central Research Lab., Mitsubishi Electric Corp.) Kyoji Umemura (NTT Software Lab., NTT) Advisors: Toshiaki Kurokawa (Tokyo Research Lab., IBM Japan Ltd.) Michiaki Yasumura (Central Research Lab., Hitachi Ltd.) Anyone interested in Japanese activities for Lisp standardization should contact: Professor Takayasu Ito Department of Information Engineering School of Engineering Tohoku University Sendai 980, Japan Junet: chairlsp@nttlab.ntt.junet or Dr. Taiichi Yuasa Research Institute for Mathematical Sciences Kyoto University Kyoto 606, Japan Junet: yuasa@kurims.kurims.kyoto-u.junet  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 24 Sep 87 01:33:28 EDT Received: from G.BBN.COM by SAIL.STANFORD.EDU with TCP; 23 Sep 87 22:06:51 PDT Date: 24 Sep 1987 01:04-EDT Sender: NGALL@G.BBN.COM Subject: Re: setf order of evaluation From: NGALL@G.BBN.COM To: Moon@SCRC-STONY-BROOK.ARPA Cc: common-lisp@SAIL.STANFORD.EDU Message-ID: <[G.BBN.COM]24-Sep-87 01:04:44.NGALL> In-Reply-To: <870911144430.9.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Fri, 11 Sep 87 14:44 EDT From: David A. Moon Date: Thu, 10 Sep 87 23:13 EDT From: Kent M Pitman ... ;; #2: The case in question (using a non-variable as a place) (PROGN (SETQ R '(A 1 B 2 C 3)) (SETQ S R) (SETF (GETF (NTHCDR 2 R) 'B) (PROGN (SETQ R NIL) 6)) (VALUES R S)) ... ;; #2a: doesn't use GETF at all (PROGN (SETQ R '(A 1 B 2 C 3)) (SETQ S R) (SETF (NTHCDR 2 R) (PROGN (SETQ R NIL) 6)) (VALUES R S)) which again blows up with CLtL's setf-method for variables, but does what one would expect with the one I suggested. These two examples changed my mind; now I think the one I suggested is obviously right, and the one in CLtL, evidently used by Symbolics and Lucid (and no doubt other implementations) is obviously wrong. Minor point: NTHCDR is not a standard generalized variable in CLtL. Major point: Does the following example change your mind back? (PROGN (SETQ R (LIST (LIST A 1 B 2 C 3))) (SETQ S (CAR R)) (SETF (GETF (CAR R) 'B) (PROGN (SETF (CAR R) NIL) 6)) (VALUES R S)) I'll bet that SCL currently returns (A 1 B 2 C 3) ; ((B 6)) regardless of variable setf-method used. But it should return (A 1 B 6 C 3) ; (NIL) As JonL (I think) implicitly pointed out, it is the responsibility of GETF to evaluate the access-form of the sub-setf-method (e.g., (CAR G0001)). It is NOT the responsibility of the sub-setf-method. Otherwise the setf-method for (CAR exp) would have to look like (G0001 G0002) (exp (CAR G0001)) (G0003) (PROGN (RPLACA G0001 G0003) G0003) G0002 Here's another GETF puzzle (only for implementations that did the right thing above): (PROGN (SETF S (LIST (LIST A 1 B 2 C 3))) (SETF R (CAR S)) (SETF (GETF (CAR S) 'D) (PROG1 4 (SETF (CAR S) NIL))) (VALUES R S)) could legally return: #1=(A 1 B 2 C 3) ; (D 4 . #1#) {if new pairs are added to the front} (A 1 B 2 C 3 D 4) ; NIL {if new pairs are added not at the front, and the sub-update-form is not used} #1=(A 1 B 2 C 3 D 4) ; #1# {if new pairs are added not at the front, and the sub-update-form is used} One final SETF puzzle: (PROGN (SETF S (LIST (LIST 1))) (SETF R (CAR S)) (SETF (CAAR S) (PROG1 2 (SETF (CAR S) (LIST NIL)))) (VALUES R S)) Is this valid? (1) ; ((2)) {I think: Yes definitely.} Is this? (2) ; ((NIL)) {I think: Probably not.} Try it in your implementation. Hint: The big issue here is when the setf-method gets a handle on the object whose cell is being stored into. The definition of DEFSETF strongly implies that the first choice is the correct one. -- Nick  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 23 Sep 87 23:38:18 EDT Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 23 Sep 87 20:13:25 PDT Received: from relay2.cs.net by RELAY.CS.NET id ac22322; 23 Sep 87 23:19 EDT Received: from atc.bendix.com by RELAY.CS.NET id ac07602; 23 Sep 87 23:09 EDT Date: Wed, 23 Sep 87 15:34 EDT From: DON%atc.bendix.com@RELAY.CS.NET Subject: Synonym streams To: common-lisp@SAIL.STANFORD.EDU X-VMS-To: IN%"common-lisp@sail.stanford.edu" Is a synonym-stream a stream? Can a stream be a synonym of a synonym-stream? On the LMI, I tried (defvar *describe-output* (make-synonym-stream '*standard-output*)) Because *standard-output* is by default a synonym of *terminal-io*, *describe- output* became a synonym for a synonym. When I tried printing to *describe-stream*, the system hung. It did not hang if I used *terminal-io* in place of *standard-output*. LMI's technical support agreed that in spirit it should work; however, CLtL is ambiguous or at least not complete. The problem, of course, is that if a synonym-stream is a stream but cannot be the synonym for another stream, then there must be some function for testing whether a stream is a synonym or a real stream. (synonym-stream-p). Do other systems support using *standard-output* as a synonym? Don Mitchell Don@atc.bendix.com Bendix Aero. Tech. Ctr. Don%atc.bendix.com@relay.cs.net 9140 Old Annapolis Rd. (301)964-4156 Columbia, MD 21045  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 23 Sep 87 14:42:21 EDT Received: from G.BBN.COM by SAIL.STANFORD.EDU with TCP; 22 Sep 87 15:41:19 PDT Date: 22 Sep 1987 18:38-EDT Sender: NGALL@G.BBN.COM Subject: Re: [KAHLE@Aquinas.Think.COM: common lisp question] From: NGALL@G.BBN.COM To: gls@THINK.COM Cc: common-lisp@SAIL.STANFORD.EDU, kahle@THINK.COM Message-ID: <[G.BBN.COM]22-Sep-87 18:38:35.NGALL> In-Reply-To: <8709181933.AA01314@kali.think.com> Comment: Remailed at SAIL.STANFORD.EDU after delay caused by mailing list error. How about defining a print-function for your structure that printed #.(make-death-row :person 2 :crime 3 :allow-other-keys t) It's the simplest solution I can think of. In the current CLtL you can't use &key in a boa-constructor lambda-list, and besides, you couldn't make #S use it anyway (it only uses the 'standard' constructor {whatever that is}). So, the next easiest solution is probably redefine the dispatch-reader-macro for S to handle a list beginning with DEATH-ROW as a special case. -- Nick Date: Fri, 18 Sep 87 15:33:21 EDT From: gls@Think.COM Date: Wed, 16 Sep 87 17:25 EDT From: Brewster Kahle Subject: common lisp question To: gls@godot.think.com, mincy@godot.think.com Moon: 1 day, 13 hours, 32 minutes since the last quarter of the moon. I want to make a stucture that is printed as #S(death-row :person 2 :crime 3) but I want it to be readable by a machine that thinks there is only the :person slot. ie (defstruct (death-row :constructor 'something-special) :person) Basically I would like to specify the arguments to the constructor to be (defun make-death-row (&rest keywords &key person &allow-other-keys) ...) is this possible? If it isnt then structures are limited as a communication medium between potentially different software versions. -brewster  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 23 Sep 87 04:35:15 EDT Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 22 Sep 87 14:34:30 PDT Received: from PinotNoir.ms by ArpaGateway.ms ; 22 SEP 87 14:30:16 PDT Date: 22 Sep 87 14:30 PDT From: newman.pasa@Xerox.COM Subject: Common Lisp 3270 emulation available? To: common-lisp@sail.stanford.edu cc: newman.pasa@Xerox.COM Message-ID: <870922-143016-12618@Xerox> Comment: Remailed at SAIL.STANFORD.EDU after delay caused by mailing list error. All, Is there a common lisp implementation of IBM 3270 terminal emulation available anywhere? Please reply to me, as I do not subscribe to this distribution list. Thanks, >>Dave  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 23 Sep 87 04:30:18 EDT Received: from CS.UTAH.EDU by SAIL.STANFORD.EDU with TCP; 22 Sep 87 15:28:16 PDT Received: by cs.utah.edu (5.54/utah-1.0) id AA15822; Tue, 22 Sep 87 16:27:58 MDT Received: by orion.utah.edu (5.54/utah-1.0-slave) id AA06472; Tue, 22 Sep 87 16:27:53 MDT Date: Tue, 22 Sep 87 16:27:53 MDT From: shebs%orion@cs.utah.edu (Stanley T. Shebs) Message-Id: <8709222227.AA06472@orion.utah.edu> To: common-lisp@sail.stanford.edu Subject: Bigger Benchmarks Comment: Remailed at SAIL.STANFORD.EDU after delay caused by mailing list error. Does anybody have any benchmarks larger and more complex than the Gabriel benchmarks? I'm especially interested in those that use a variety of data structures and that are CPU rather than I/O intensive. A more complete use of CL is desirable also. Suggestions or code equally welcome... stan  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 22 Sep 87 17:27:58 EDT Received: from LINDY.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 22 Sep 87 13:59:24 PDT Received: by lindy.stanford.edu; Tue, 22 Sep 87 13:59:45 PDT Received: by Forsythe.Stanford.EDU; Tue, 22 Sep 87 12:56:50 PDT Date: Tue, 22 Sep 87 14:53 CDT From: Subject: BBS To: common-lisp@sail.stanford.edu X-Original-To: common-lisp@SAIL.STANFORD.EDU, KARSAIG1 Could you include me in your mailing list ? Thanks, Gabor Karsai Internet: KARSAIG1%VUENGVAX.BITNET@WISCVM.WIS.EDU  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 21 Sep 87 17:36:29 EDT Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 21 Sep 87 14:10:39 PDT Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 238035; Mon 21-Sep-87 17:11:32 EDT Date: Mon, 21 Sep 87 17:10 EDT From: David A. Moon Subject: Re: setf order of evaluation To: NGALL@G.BBN.COM cc: DALY@IBM.COM, common-lisp@SAIL.STANFORD.EDU In-Reply-To: <[G.BBN.COM]10-Sep-87 10:40:24.NGALL> Message-ID: <870921171049.0.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: 10 Sep 1987 10:40-EDT From: NGALL@G.BBN.COM Date: Wed, 9 Sep 87 14:40 EDT From: David A. Moon I didn't look inside the Lucid implementation, but in the Symbolics implementation the source of the bug is that (get-setf-method 'r) returns NIL, NIL, (#:G6411), (SETQ R #:G6411), R, whereas it should return (#:G6410), (R), (#:G6411), (SETQ R #:G6411), #:G6410. See CLtL page 104 for the description of the meaning of these values. Changing it to return the latter makes your SETF example behave as you expected, evaluating R -before- bashing it, and setq'ing it to the updated property list -after- setq'ing it to nil. Unfortunately, on pg 105 the setf method for the variable X is defined to be () () (#:g0001) (setq X #:g0001) X. So if this is the right place to fix things, then CLtL must be fixed too. This is fine with me, but it would make SETF methods less efficient (or require them to be more intelligent about optimizing). I'm told Symbolics will be fixing our next release to do what I said I thought was right, rather than what CLtL says. I guess that obligates me to write this up and submit it to the cleanup committee, which I will do. I don't take the efficiency issue very seriously; it's very easy to optimize the cases in question, in my opinion.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 21 Sep 87 10:24:12 EDT Received: from [128.81.41.109] by SAIL.STANFORD.EDU with TCP; 21 Sep 87 06:57:42 PDT Received: from CHICOPEE.SCRC.Symbolics.COM by ALDERAAN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 121449; Mon 21-Sep-87 09:54:50 EDT Date: Mon, 21 Sep 87 09:55 EDT From: Daniel L. Weinreb Subject: [KAHLE@Aquinas.Think.COM: common lisp question] To: gls@Think.COM, common-lisp@sail.stanford.edu cc: kahle@Think.COM In-Reply-To: <8709181933.AA01314@kali.think.com> Message-ID: <870921095514.7.DLW@CHICOPEE.SCRC.Symbolics.COM> Date: Fri, 18 Sep 87 15:33:21 EDT From: gls@Think.COM Date: Wed, 16 Sep 87 17:25 EDT From: Brewster Kahle To: gls@godot.think.com, mincy@godot.think.com Moon: 1 day, 13 hours, 32 minutes since the last quarter of the moon. I want to make a stucture that is printed as #S(death-row :person 2 :crime 3) but I want it to be readable by a machine that thinks there is only the :person slot. ie (defstruct (death-row :constructor 'something-special) :person) Basically I would like to specify the arguments to the constructor to be (defun make-death-row (&rest keywords &key person &allow-other-keys) ...) is this possible? If it isnt then structures are limited as a communication medium between potentially different software versions. It's not structures that are limited, it's PRINT. Suppose you chose to represent a death-row instance as a list with two elements, CRIME and PERSON, in which the extractor for person was a macro that expanded to CADR. Then you try to transmit that to a software version that doesn't store CRIME, just PERSON, and uses CAR to extract the person. It would still fail, although not quite at the same time. The point is that you need to communicate at a higher level of abstraction than the raw Lisp data structures represented by raw Lisp PRINT.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 21 Sep 87 10:21:54 EDT Received: from [128.81.41.109] by SAIL.STANFORD.EDU with TCP; 21 Sep 87 06:57:27 PDT Received: from CHICOPEE.SCRC.Symbolics.COM by ALDERAAN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 121448; Mon 21-Sep-87 09:50:39 EDT Date: Mon, 21 Sep 87 09:50 EDT From: Daniel L. Weinreb Subject: [KAHLE@Aquinas.Think.COM: defstruct request for common lisp] To: gls@Think.COM, common-lisp@sail.stanford.edu In-Reply-To: <8709181843.AA01280@kali.think.com> Message-ID: <870921095059.6.DLW@CHICOPEE.SCRC.Symbolics.COM> Date: Fri, 18 Sep 87 14:43:08 EDT From: gls@Think.COM Date: Sat, 12 Sep 87 17:07 EDT From: Brewster Kahle Subject: defstruct request for common lisp To: gls@godot.think.com Moon: 4 days, 22 hours, 25 minutes since the full moon. I wish there were a function like: (struction-slots ) that returns the list of slots of a defstruct. The obvious extension of this is to return the declarations and all, but I have never needed any of these. Im sure there are some hairy issues that I do not understand (like include), but I have wanted the vanilla version many times. -brewster One idea that's been discussed that would do what you want, in fact do something more general, is to redefine structures in terms of object-oriented programming, if and after CLOS is accepted as part of Common Lisp. The basic idea is that CLOS would have a defined mechanism for talking about slots and their properties. I don't know whether this idea is still current; I suspect it's mainly on the back burner while the CLOS proposal itself is being finished.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 18 Sep 87 15:54:59 EDT Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 18 Sep 87 12:33:33 PDT Return-Path: Received: from kali.think.com by Think.COM; Fri, 18 Sep 87 15:33:07 EDT Received: by kali.think.com; Fri, 18 Sep 87 15:33:21 EDT Date: Fri, 18 Sep 87 15:33:21 EDT From: gls@Think.COM Message-Id: <8709181933.AA01314@kali.think.com> To: common-lisp@sail.stanford.edu Cc: kahle@Think.COM Subject: [KAHLE@Aquinas.Think.COM: common lisp question] Date: Wed, 16 Sep 87 17:25 EDT From: Brewster Kahle Subject: common lisp question To: gls@godot.think.com, mincy@godot.think.com Moon: 1 day, 13 hours, 32 minutes since the last quarter of the moon. I want to make a stucture that is printed as #S(death-row :person 2 :crime 3) but I want it to be readable by a machine that thinks there is only the :person slot. ie (defstruct (death-row :constructor 'something-special) :person) Basically I would like to specify the arguments to the constructor to be (defun make-death-row (&rest keywords &key person &allow-other-keys) ...) is this possible? If it isnt then structures are limited as a communication medium between potentially different software versions. -brewster  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 18 Sep 87 15:08:13 EDT Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 18 Sep 87 11:43:02 PDT Return-Path: Received: from kali.think.com by Think.COM; Fri, 18 Sep 87 14:42:55 EDT Received: by kali.think.com; Fri, 18 Sep 87 14:43:08 EDT Date: Fri, 18 Sep 87 14:43:08 EDT From: gls@Think.COM Message-Id: <8709181843.AA01280@kali.think.com> To: common-lisp@sail.stanford.edu Subject: [KAHLE@Aquinas.Think.COM: defstruct request for common lisp] Date: Sat, 12 Sep 87 17:07 EDT From: Brewster Kahle Subject: defstruct request for common lisp To: gls@godot.think.com Moon: 4 days, 22 hours, 25 minutes since the full moon. I wish there were a function like: (struction-slots ) that returns the list of slots of a defstruct. The obvious extension of this is to return the declarations and all, but I have never needed any of these. Im sure there are some hairy issues that I do not understand (like include), but I have wanted the vanilla version many times. -brewster  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 12 Sep 87 02:00:04 EDT Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 11 Sep 87 22:40:27 PDT Received: from relay2.cs.net by RELAY.CS.NET id ag06485; 12 Sep 87 1:40 EDT Received: from cs.umass.edu by RELAY.CS.NET id an18149; 12 Sep 87 1:31 EDT Date: Fri, 11 Sep 87 09:45 EDT From: Stride 440 User Subject: RE: setf order of evaluation To: common-lisp@SAIL.STANFORD.EDU X-VMS-To: IN%"common-lisp@sail.stanford.edu" > From: Timothy Daly > To: common-lisp@SAIL.STANFORD.EDU > > Given > > (setq r '(a 1 b 2 c 3)) > (setq s r) > (setf (getf r 'b) (progn (setq r nil) 6)) > > what is the value of R and S? > > Note that P97 of CLtL states that SETF guarantees the > left-to-right order of evaluation of its arguments. > > (yes, i know it is crufty to change R). > > Both Symbolics and Lucid seem to generate > R = (B 8) and S = (A 1 B 2 C 3) VAXLISP Version U2.2 does the same thing: LLVS (ll)> (setq r '(a 1 b 2 c 3)) ... (a 1 b 2 c 3) LLVS (ll)> (setq s r) ... (a 1 b 2 c 3) LLVS (ll)> (setf (getf r 'b) (progn (setq r nil) 6)) ... 6 LLVS (ll)> s ... (a 1 b 2 c 3) LLVS (ll)> r ... (b 6) LLVS (ll)> (get-setf-method '(getf r b)) ... (#:g430) (b) (#:g429) (do* ((#:g431 r) (#:g432 #:g431 (cddr #:g432))) ((atom #:g432) (let ((#:g428 (list* #:g430 #:g429 #:g431))) (setq r #:g428)) #:g429) (cond ((atom (cdr #:g432)) (error "Odd length property list in SETF of GETF.")) ((eq (car #:g432) #:g430) (rplaca (cdr #:g432) #:g429) (return #:g429)))) (getf r #:g430 nil) LLVS (ll)> (setq r '(a 1 b 2 c 3)) ... (a 1 b 2 c 3) LLVS (ll)> (setq s r) ... (a 1 b 2 c 3) LLVS (ll)> (macroexpand '(setf (getf r 'b) (progn (setq r nil) 6))) ... (let* ((#:g446 'b) (#:g445 (progn (setq r nil) 6))) (do* ((#:g447 r) (#:g448 #:g447 (cddr #:g448))) ((atom #:g448) (let ((#:g444 (list* #:g446 #:g445 #:g447))) (setq r #:g444)) #:g445) (cond ((atom (cdr #:g448)) (error "Odd length property list in SETF of GETF.")) ((eq (car #:g448) #:g446) (rplaca (cdr #:g448) #:g445) (return #:g445))))) t Robert Heller ARPANet: Heller@CS.UMass.EDU BITNET: Heller@UMass.BITNET BIX: Heller GEnie: RHeller FidoNet: 321/148 (Locks Hill BBS, Wendell, MA) CompuServe 71450,3432 Local PV VAXen: COINS::HELLER UCC Cyber/DG: Heller@CS  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 11 Sep 87 15:08:47 EDT Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 11 Sep 87 11:43:53 PDT Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 232057; Fri 11-Sep-87 14:44:54 EDT Date: Fri, 11 Sep 87 14:44 EDT From: David A. Moon Subject: setf order of evaluation To: common-lisp@SAIL.STANFORD.EDU In-Reply-To: <870910231312.9.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> Message-ID: <870911144430.9.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Thu, 10 Sep 87 23:13 EDT From: Kent M Pitman [philosophy for future languages deleted] As food for thought, consider the following examples... ;; #1: The case in question (using a variable as a place) (PROGN (SETQ R '(A 1 B 2 C 3)) (SETQ S R) (SETF (GETF R 'B) (PROGN (SETQ R NIL) 6)) (VALUES R S)) ;; #2: The case in question (using a non-variable as a place) (PROGN (SETQ R '(A 1 B 2 C 3)) (SETQ S R) (SETF (GETF (NTHCDR 2 R) 'B) (PROGN (SETQ R NIL) 6)) (VALUES R S)) Definitely an illuminating case. This blows up trying to RPLACD NIL with the get-setf-method of variables prescribed by CLtL, but does what one would expect with the get-setf-method of variables I suggested the other day. Also illuminating: ;; #2a: doesn't use GETF at all (PROGN (SETQ R '(A 1 B 2 C 3)) (SETQ S R) (SETF (NTHCDR 2 R) (PROGN (SETQ R NIL) 6)) (VALUES R S)) which again blows up with CLtL's setf-method for variables, but does what one would expect with the one I suggested. These two examples changed my mind; now I think the one I suggested is obviously right, and the one in CLtL, evidently used by Symbolics and Lucid (and no doubt other implementations) is obviously wrong. ;; #3: This can't work, but think hard about why not. Works fine for me, and returns the same values as #1. ;; There's a sense in which it feels like it ought to be identical ;; to #1 above. (PROGN (SETQ R '(A 1 B 2 C 3)) (SETQ S R) (SETF (GETF (NTHCDR 0 R) 'B) (PROGN (SETQ R NIL) 6)) (VALUES R S)) ;; #4: This is not as much like the others, but I found its return ;; value to be instructive anyway. (PROGN (SETQ R '(A 1 B 2 C 3)) (SETQ S R) (SETF (CAR R) (PROGN (SETQ R NIL) 6)) (VALUES R S)) Nothing surprising here.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 10 Sep 87 23:41:30 EDT Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 10 Sep 87 20:13:18 PDT Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 231604; Thu 10-Sep-87 23:13:39 EDT Date: Thu, 10 Sep 87 23:13 EDT From: Kent M Pitman Subject: setf order of evaluation To: franz!ficl!drb@ucbarpa.Berkeley.EDU, Moon@STONY-BROOK.SCRC.Symbolics.COM cc: DALY@ibm.com, common-lisp@sail.stanford.edu, KMP@STONY-BROOK.SCRC.Symbolics.COM In-Reply-To: <8709092139.AA02338@ficl> Message-ID: <870910231312.9.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> I believe the root of this problem is bad interplay between the following two design issues: * I think it was a big mistake to make (SETF var val) work. Anyone who's ever implemented SETF knows there's something strange about variables that they have to be handled so differently than structure accessors. The sense in which SETQ makes a side-effect (to a structure which is effectively not user-accessible as a first-class object (in dialects not having a LOCF extension)) is different than the sense in which RPLACA makes a side-effect. The fact that (DEFUN F (X Y) (PUSH X Y) Y) is so radically different in its I/O behavior than (DEFUN F (X Y) (PUSH X (CDR Y)) Y) is symptomatic of the problem I'm citing. * I think there's something odd about GETF in that it takes a place as an argument, but nothing can enforce that. eg, (GETF '(A B C D) 'C) works, even though (QUOTE ...) is not a place. If you try to SETF it, you see the error of your ways. The fact that SETF has to reach through the GETF to get its first argument and fool with it is what leads to a problem like the one I was mentioning above. I don't think there's much we can do about this (short of documenting clearly how this particular special case (and others like it) should be dealt with). I think it's doomed to be somewhat of an embarrassment because we've chosen to create a system of rules which I think inherently cannot generalize in a completely satisfying way. I'm not advocating that we change SETF at this late date, but if I were designing a new language, I'd sure advocate doing things differently. As food for thought, consider the following examples... ;; #1: The case in question (using a variable as a place) (PROGN (SETQ R '(A 1 B 2 C 3)) (SETQ S R) (SETF (GETF R 'B) (PROGN (SETQ R NIL) 6)) (VALUES R S)) ;; #2: The case in question (using a non-variable as a place) (PROGN (SETQ R '(A 1 B 2 C 3)) (SETQ S R) (SETF (GETF (NTHCDR 2 R) 'B) (PROGN (SETQ R NIL) 6)) (VALUES R S)) ;; #3: This can't work, but think hard about why not. ;; There's a sense in which it feels like it ought to be identical ;; to #1 above. (PROGN (SETQ R '(A 1 B 2 C 3)) (SETQ S R) (SETF (GETF (NTHCDR 0 R) 'B) (PROGN (SETQ R NIL) 6)) (VALUES R S)) ;; #4: This is not as much like the others, but I found its return ;; value to be instructive anyway. (PROGN (SETQ R '(A 1 B 2 C 3)) (SETQ S R) (SETF (CAR R) (PROGN (SETQ R NIL) 6)) (VALUES R S))  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 10 Sep 87 22:42:21 EDT Received: from UCBARPA.Berkeley.EDU by SAIL.STANFORD.EDU with TCP; 10 Sep 87 19:19:50 PDT Received: by ucbarpa.Berkeley.EDU (5.58/1.25) id AA20402; Thu, 10 Sep 87 19:20:51 PDT Received: from ficl by franz (5.5/3.14) id AA00482; Thu, 10 Sep 87 18:29:10 PDT Received: by ficl (5.5/3.14) id AA02338; Wed, 9 Sep 87 14:39:55 PDT Date: Wed, 9 Sep 87 14:39:55 PDT From: franz!ficl!drb@ucbarpa.Berkeley.EDU (David Barton) Return-Path: Message-Id: <8709092139.AA02338@ficl> To: Moon@stony-brook.scrc.symbolics.com Cc: DALY@ibm.com, common-lisp@sail.stanford.edu In-Reply-To: David A. Moon's message of Wed, 9 Sep 87 14:40 EDT <870909144023.7.MOON@EUPHRATES.SCRC.Symbolics.COM> Subject: setf order of evaluation Date: Wed, 9 Sep 87 14:40 EDT From: David A. Moon Date: 9 September 1987, 10:31:51 EDT From: Timothy Daly Given (setq r '(a 1 b 2 c 3)) (setq s r) (setf (getf r 'b) (progn (setq r nil) 6)) what is the value of R and S? Note that P97 of CLtL states that SETF guarantees the left-to-right order of evaluation of its arguments. (yes, i know it is crufty to change R). Both Symbolics and Lucid seem to generate R = (B 8) and S = (A 1 B 2 C 3) which implies that the second argument of setf is evaluated first. What did I miss? It's not a good idea to speak of "arguments" when dealing with forms that aren't function calls. It's less confusing to speak of subforms. The subforms of that setf that get evaluated are r 'b (progn (setq r nil) 6) so I think the behavior you describe is a bug (although the description in CLtL is so ambiguous that the implementors of the respective systems could easily disagree with me.) I didn't look inside the Lucid implementation, but in the Symbolics implementation the source of the bug is that (get-setf-method 'r) returns NIL, NIL, (#:G6411), (SETQ R #:G6411), R, whereas it should return (#:G6410), (R), (#:G6411), (SETQ R #:G6411), #:G6410. See CLtL page 104 for the description of the meaning of these values. Changing it to return the latter makes your SETF example behave as you expected, evaluating R -before- bashing it, and setq'ing it to the updated property list -after- setq'ing it to nil. Franz Inc.'s Common Lisp ("Allegro CL") ends up with r = nil and s = (a 1 b 6 c 3). However, it returns the same 5 forms for (get-setf-method 'r) that Symbolics does, and in fact these 5 forms are given as an example on p. 105 of CLtL.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 10 Sep 87 21:42:21 EDT Received: from ORVILLE.ARPA by SAIL.STANFORD.EDU with TCP; 10 Sep 87 18:24:02 PDT Received: Thu, 10 Sep 87 18:24:00 PDT by orville.arpa (5.54/1.2) Message-Id: <8709110124.AA20824@orville.arpa> To: common-lisp@SAIL.STANFORD.EDU Cc: raible@orville.nas.nasa.gov Subject: Re: Common Lisp LOOP Date: 10 Sep 87 18:23:58 PDT (Thu) From: raible@orville.nas.nasa.gov Well, I was hoping that it would get reposted since I received a truncated copy of the KCL LOOP code. Is there anyone who got the whole thing who would be willing to repost, or send it to me? Thanks - Eric Raible (raible@orville.nas.nasa.gov)  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 10 Sep 87 11:05:48 EDT Received: from G.BBN.COM by SAIL.STANFORD.EDU with TCP; 10 Sep 87 07:41:40 PDT Date: 10 Sep 1987 10:40-EDT Sender: NGALL@G.BBN.COM Subject: Re: setf order of evaluation From: NGALL@G.BBN.COM To: Moon@SCRC-STONY-BROOK.ARPA Cc: DALY@IBM.COM, common-lisp@SAIL.STANFORD.EDU Message-ID: <[G.BBN.COM]10-Sep-87 10:40:24.NGALL> In-Reply-To: <870909144023.7.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Wed, 9 Sep 87 14:40 EDT From: David A. Moon Date: 9 September 1987, 10:31:51 EDT From: Timothy Daly Given (setq r '(a 1 b 2 c 3)) (setq s r) (setf (getf r 'b) (progn (setq r nil) 6)) what is the value of R and S? ... Both Symbolics and Lucid seem to generate R = (B 8) and S = (A 1 B 2 C 3) ... so I think the behavior you describe is a bug (although the description in CLtL is so ambiguous that the implementors of the respective systems could easily disagree with me.) I agree that it is a bug. Cf pg 99: "As an example of these semantic rules, in the generalized-variable reference (SETF reference value) the VALUE form must be evaluated AFTER all the subforms of the reference because the value form appears to the right of them" I didn't look inside the Lucid implementation, but in the Symbolics implementation the source of the bug is that (get-setf-method 'r) returns NIL, NIL, (#:G6411), (SETQ R #:G6411), R, whereas it should return (#:G6410), (R), (#:G6411), (SETQ R #:G6411), #:G6410. See CLtL page 104 for the description of the meaning of these values. Changing it to return the latter makes your SETF example behave as you expected, evaluating R -before- bashing it, and setq'ing it to the updated property list -after- setq'ing it to nil. Unfortunately, on pg 105 the setf method for the variable X is defined to be () () (#:g0001) (setq X #:g0001) X. So if this is the right place to fix things, then CLtL must be fixed too. This is fine with me, but it would make SETF methods less efficient (or require them to be more intelligent about optimizing). -- Nick  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 9 Sep 87 15:03:21 EDT Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 9 Sep 87 11:39:43 PDT Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 230463; Wed 9-Sep-87 14:40:44 EDT Date: Wed, 9 Sep 87 14:40 EDT From: David A. Moon Subject: setf order of evaluation To: Timothy Daly cc: common-lisp@sail.stanford.edu In-Reply-To: <090987.103153.daly@ibm.com> Message-ID: <870909144023.7.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: 9 September 1987, 10:31:51 EDT From: Timothy Daly Given (setq r '(a 1 b 2 c 3)) (setq s r) (setf (getf r 'b) (progn (setq r nil) 6)) what is the value of R and S? Note that P97 of CLtL states that SETF guarantees the left-to-right order of evaluation of its arguments. (yes, i know it is crufty to change R). Both Symbolics and Lucid seem to generate R = (B 8) and S = (A 1 B 2 C 3) which implies that the second argument of setf is evaluated first. What did I miss? It's not a good idea to speak of "arguments" when dealing with forms that aren't function calls. It's less confusing to speak of subforms. The subforms of that setf that get evaluated are r 'b (progn (setq r nil) 6) so I think the behavior you describe is a bug (although the description in CLtL is so ambiguous that the implementors of the respective systems could easily disagree with me.) I didn't look inside the Lucid implementation, but in the Symbolics implementation the source of the bug is that (get-setf-method 'r) returns NIL, NIL, (#:G6411), (SETQ R #:G6411), R, whereas it should return (#:G6410), (R), (#:G6411), (SETQ R #:G6411), #:G6410. See CLtL page 104 for the description of the meaning of these values. Changing it to return the latter makes your SETF example behave as you expected, evaluating R -before- bashing it, and setq'ing it to the updated property list -after- setq'ing it to nil.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 9 Sep 87 11:19:41 EDT Received: from IBM.COM by SAIL.STANFORD.EDU with TCP; 9 Sep 87 08:03:05 PDT Date: 9 September 1987, 10:31:51 EDT From: Timothy Daly To: common-lisp@sail.stanford.edu Message-Id: <090987.103153.daly@ibm.com> Subject: setf order of evaluation Given (setq r '(a 1 b 2 c 3)) (setq s r) (setf (getf r 'b) (progn (setq r nil) 6)) what is the value of R and S? Note that P97 of CLtL states that SETF guarantees the left-to-right order of evaluation of its arguments. (yes, i know it is crufty to change R). Both Symbolics and Lucid seem to generate R = (B 8) and S = (A 1 B 2 C 3) which implies that the second argument of setf is evaluated first. What did I miss? tim DALY@IBM.COM IBM T.J. Watson Research Center Yorktown Heights, N.Y. 10598  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 7 Sep 87 13:31:49 EDT Received: from TUNNEL.CS.UCL.AC.UK by SAIL.STANFORD.EDU with TCP; 7 Sep 87 10:13:57 PDT Received: from aiva.edinburgh.ac.uk by nss.Cs.Ucl.AC.UK via Janet with NIFTP id aa08808; 7 Sep 87 17:29 BST From: Jeff Dalton Date: Mon, 7 Sep 87 17:30:59 -0100 Message-Id: <12061.8709071630@aiva.ed.ac.uk> To: common-lisp@sail.stanford.edu Subject: KCL LOOP posting > The LOOP posting by Taiichi Yuasa for KCL arrived here truncated. Same here. Nor can I FTP it from anywhere, were someone to put it somewhere. -- Jeff (J.Dalton%uk.ac.ed@nss.cs.ucl.ac.uk)  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 7 Sep 87 11:41:56 EDT Received: from LINDY.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 7 Sep 87 08:29:06 PDT Received: by lindy.stanford.edu; Mon, 7 Sep 87 08:29:23 PDT Received: by Forsythe.Stanford.EDU; Mon, 7 Sep 87 08:28:05 PDT Date: Mon, 7 Sep 87 10:29 CDT From: (David Linn) Subject: KCL LOOP posting To: common-lisp@sail.stanford.edu X-Original-To: common-lisp@sail.stanford.edu, LINNDR The LOOP posting by Taiichi Yuasa for KCL arrived here truncated. Did this happen everywhere? If not, can someone arrange to send it to me (please send mail first so that I don't receive multiple copies)? David Linn LINNDR@VUENGVAX.BITNET ...!seismo!uunet!vuse!drl  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 5 Sep 87 14:06:22 EDT Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 5 Sep 87 10:31:14 PDT Received: from relay2.cs.net by RELAY.CS.NET id aa04506; 5 Sep 87 10:06 EDT Received: from utokyo-relay by RELAY.CS.NET id ac11318; 5 Sep 87 9:48 EDT Received: by ccut.cc.u-tokyo.junet (5.51/6.2.9Junet) id AA13118; Sat, 5 Sep 87 22:41:23 JST Received: by titcca.cc.titech.junet (4.12/6.2Junet) id AA18600; Sat, 5 Sep 87 22:09:13 jst Received: by nttlab.NTT (4.12/6.2NTT.g) with TCP; Sat, 5 Sep 87 19:51:20 jst Received: by kuis.kuis.kyoto-u.junet (2.0/6.2Junet) id AA03223; Sat, 5 Sep 87 12:57:38 jst Received: by kurims.kurims.kyoto-u.junet (3.2/6.2Junet) id AA00683; Sat, 5 Sep 87 11:45:42 JST Date: Sat, 5 Sep 87 11:45:42 JST From: Taiichi Yuasa Return-Path: Message-Id: <8709050245.AA00683@kurims.kurims.kyoto-u.junet> To: common-lisp@SAIL.STANFORD.EDU Subject: Re: Common Lisp LOOP Here is my code for LOOP, which will be included in the next release of KCL available from University of Texas. -- Taiichi ------------------- Cut Here ---------------------- ;; (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. (in-package 'lisp) (export '(define-loop-path define-loop-sequence-path)) (in-package 'system) (export '(loop-tequal loop-tmember loop-tassoc loop-named-variable)) (eval-when (compile) (proclaim '(optimize (safety 2) (space 3)))) (defvar *loop-named-variables* nil) (defun loop-tequal (x key) " Args: (object symbol) Returns T if OBJECT is a symbol with the same print name as SYMBOL; NIL otherwise. Used typically to define a loop-path." (and (symbolp x) (or (eq x key) (string= (symbol-name x) (symbol-name key))))) (defun loop-tmember (x keys) " Args: (object symbols) Similar to MEMBER but uses SI:LOOP-TEQUAL to compare OBJECT and each element of SYMBOLS. Used typically to define a loop-path." (and (symbolp x) (member (symbol-name x) keys :test #'string= :key #'symbol-name))) (defun loop-tassoc (x alist) " Args: (object alist) Similar to ASSOC but uses SI:LOOP-TEQUAL to compare OBJECT and the car of each element of ALIST using . Used typically to define a loop-path." (and (symbolp x) (assoc (symbol-name x) alist :test #'(lambda (s key) (string= s (symbol-name key)))))) (defun loop-named-variable (key) " Args: (symbol) Returns the name of the variable for SYMBOL, which is specified by the USING key of LOOP. Returns NIL if no variable is specified. Should be used only in loop-path definitions." (cadr (loop-tassoc key *loop-named-variables*))) (defmacro test body `(macroexpand-1 '(loop ,@body))) (defvar *loop-paths* (make-hash-table :test 'equal)) (defmacro define-loop-path (name fun keys &rest data) " Syntax: (define-loop-path name-or-names symbol keys &rest data) Defines loop-paths. When LOOP encounters a clause of the form FOR var [type] BEING {THE | EACH} name (key1 thing1)...(keyn thingn) LOOP invokes the function named SYMBOL with the following arguments. 1. name 2. var 3. type (or NIL if type is not specified) 4. ((key1 thing1)...(keyn thingn)) 5. NIL 6. keys specified by DEFINE-LOOP-PATH 7. data specified by DEFINE-LOOP-PATH In case of FOR var [type] BEING form AND ITS name (key1 thing1)...(keyn thingn) LOOP invokes the same function with the same arguments except for the fourth and fifth: 4. ((OF form) (key1 thing1)...(keyn thingn)) 5. T Then LOOP expects a list of six or ten elements returned by the function 1. variable bindings as a list ((var init)...(var init)) 2. prologue forms as a list (form...form) 3-6. general iteration spec 7-10. first iteration spec For a six-element list, 7-10 are assumed the same as 3-6, respectively. The iteration spec is 3. pre-step endtest 4. steps as a list ((var form)...(var form)) 5. post-step endtest 6. pseudo-steps as a list ((var form)...(var form))" `(progn ,.(mapcar #'(lambda (x) `(setf (gethash ,(symbol-name x) *loop-paths*) (list ',fun ',keys ',data))) (if (symbolp name) (list name) name)) ',name)) (defmacro define-loop-sequence-path (name fetch size &optional type1 type2) " Syntax: (define-loop-sequence-path name-or-names fetch-fun size-fun &optional type1 type2) Defines loop-sequence-paths." (declare (ignore type1 type2)) `(progn ,.(mapcar #'(lambda (x) `(setf (gethash ,(symbol-name x) *loop-paths*) (list nil ',fetch ',size))) (if (symbolp name) (list name) name)) ',name)) (defvar *loop-body*) (defvar *bindings*) (defvar *prologue*) (defvar *pre-steps*) (defvar *body*) (defvar *post-steps*) (defvar *epilogue*) (defvar *acc*) (defvar *acclist*) (defvar *named-block*) (defvar *t2*) (defvar *it*) (defvar *its-name*) (defvar *it-is-used*) (defvar *temps*) (defvar *aux-bindings*) (defmacro lkcase clauses (let ((key (gensym)) (form nil)) (dolist (clause (reverse clauses) `(let ((,key (if (symbolp (car *loop-body*)) (symbol-name (car *loop-body*)) ""))) ,form)) (declare (object clause)) (setq form (if (eq (car clause) :ow) `(progn ,@(cdr clause)) `(if ,(cond ((atom (car clause)) `(string= ,key ,(symbol-name (car clause)))) (t `(or ,.(mapcar #'(lambda (x) `(string= ,key ,(symbol-name x))) (car clause))))) (progn (pop-body) ,@(cdr clause)) ,form)))))) (defmacro pop-body () '(pop *loop-body*)) (defmacro peek-body () '(car *loop-body*)) (defmacro end-body () '(endp *loop-body*)) (defmacro do-it (form) `(push ,form *body*)) (defconstant *default-terminators* '(REPEAT FOR AS WITH NODECLARE INITIALLY FINALLY DO DOING COLLECT COLLECTING NCONC NCONCING APPEND APPENDING COUNT COUNTING SUM SUMMING MAXIMIZE MINIMIZE WHILE UNTIL LOOP-FINISH ALWAYS NEVER THEREIS WHEN IF UNLESS NAMED RETURN)) (defun parse-type (terminators) (cond ((end-body) t) ((loop-tmember (peek-body) terminators) t) (t (pop-body)))) (defmacro aux-bind (v init) `(push (list ,v ,init) *aux-bindings*)) (defun get-it () (unless *it* (error "The IT keyword comes in a wrong place.")) (setq *it-is-used* t) (or *its-name* (prog1 (setq *its-name* (gensym)) (aux-bind *its-name* nil)))) (defmacro loop *loop-body* " Syntax: (loop {list-form}* {clause}*) Upper compatible extension of the Common Lisp LOOP macro. If no CLAUSE is given, then LOOP simply repeats execution of LIST-FORMs. The use of CLAUSEs is expected to be compatible with those in Symbolics Common Lisp, with the following syntax. clause ::= REPEAT form [AND more-iteration-clauses] | {FOR | AS} FOR-clause [AND more-iteration-clauses] | WITH var [type] [= form] | {INITIALLY | FINALLY} form {list-form}* | {DO | DOING} form {list-form}* | {WHEN | IF | UNLESS} form clause {AND clause}* [ELSE clause {AND clause}*] | {COLLECT | NCONC | APPEND} {form | IT} [INTO symbol] | {COUNT | SUM} {form | IT} [INTO symbol] [type] | {MAXIMIZE | MINIMIZE} {form | IT} [type] [INTO symbol] | {WHILE | UNTIL | ALWAYS | NEVER | THEREIS} form | LOOP-FINISH | NAMED symbol | NODECLARE symbol-list | RETURN {form | IT} FOR-clause ::= var [type] { FROM form { {TO | DOWNTO | BELOW | ABOVE | BY} form }* | {DOWNFROM | UPFROM} form [BY form] | {IN | ON} form [BY form] | = form [THEN form] | FIRST form THEN form | BEING form AND {ITS | EACH} loop-path {key thing}* | BEING [THE | EACH] loop-path {key thing}* } Type declarations are simply ignored in the current version. The only known differences from Symbolics Common Lisp LOOP are: 1. DEFAULT-LOOP-PATH is not supported simply because I (Taiichi) do not know in which case I should use the default. 2. No built-in loop-path is defined. In order to define a loop-path, use DEFINE-LOOP-PATH or DEFINE-LOOP-SEQUENCE-PATH. See SI:LOOP-TEQUAL, SI:LOOP-TMEMBER, SI:LOOP-TASSOC, and SI:LOOP-NAMED- VARIABLES." (let (*bindings* *temps* *aux-bindings* *prologue* *pre-steps* *body* *post-steps* *epilogue* *acc* *acclist* *named-block* (*t2* (gensym)) *it* *its-name* *it-is-used*) (parse-loop-body) (let* ((identical-steps (do ((x nil)) ((or (endp *pre-steps*) (endp *post-steps*) (not (equal (car *pre-steps*) (car *post-steps*)))) x) (push (pop *pre-steps*) x) (pop *post-steps*))) (t1 (gensym)) (template (list 'tagbody)) (form `(block ,*named-block* ,(lv-bind *bindings* *aux-bindings* template)))) (setf (cdr template) `(,.(nreverse *prologue*) ,.(nreverse (mapcar #'(lambda (x) (if (eq (car x) 'when) x (lv-set x))) *pre-steps*)) ,t1 ,.(mapcar #'(lambda (x) (if (eq (car x) 'when) x (lv-set x))) identical-steps) ,.(nreverse *body*) ,.(nreverse (mapcar #'(lambda (x) (if (eq (car x) 'when) x (lv-set x))) *post-steps*)) (go ,t1) ,*t2* ,.(nreverse *epilogue*) (return ,*acc*))) form))) (defun lv-bind (bindings aux-bindings form) (let ((sb nil) (pb nil)) (labels ((lv-bind-tree (tree form) (cond ((null tree)) ((atom tree) (push (list tree form) sb)) (t (lv-bind-tree (cdr tree) `(cdr ,form)) (lv-bind-tree (car tree) `(car ,form))))) (lv-bind-nil (tree) (cond ((null tree)) ((atom tree) (push tree sb)) (t (lv-bind-nil (cdr tree)) (lv-bind-nil (car tree)))))) (dolist (b aux-bindings) (push b sb)) (dolist (bs bindings) (cond ((endp (cdr bs)) (let ((b (car bs))) (cond ((or (symbolp b) (symbolp (car b))) (push b sb)) ((null (cadr b)) (lv-bind-nil (car b))) (t (let ((temp (gensym))) (lv-bind-tree (car b) temp) (push (list temp (cadr b)) sb) (push temp *temps*)))))) (t (dolist (b (reverse bs)) (cond ((or (symbolp b) (symbolp (car b))) (push b pb)) ((null (cadr b)) (lv-bind-nil (car b))) (t (let ((temp (gensym))) (lv-bind-tree (car b) temp) (push (list temp (cadr b)) pb) (push temp *temps*))))) (when sb (setq form `(let* ,sb ,form)) (setq sb nil)) (when pb (setq form `(let ,pb ,form)) (setq pb nil))))) (if sb `(let* ,sb ,form) form)))) (defun lv-set (sl) (let ((more-temps nil) (temps *temps*) (ps nil) (ss nil)) (labels ((lv-set-tree (tree form) (cond ((null tree)) ((atom tree) (push form ss) (push tree ss)) (t (lv-set-tree (cdr tree) `(cdr ,form)) (lv-set-tree (car tree) `(car ,form)))))) (cond ((endp (cdr sl)) (let ((s (car sl))) (cond ((symbolp (car s)) `(setq ,(car s) ,(cadr s))) ((endp temps) (let ((temp (gensym))) (lv-set-tree (car s) temp) `(let ((,temp ,(cadr s))) (setq ,@ss)))) (t (let ((temp (car temps))) (lv-set-tree (car s) temp) `(setq ,temp ,(cadr s) ,@ss)))))) (t (dolist (s (reverse sl)) (cond ((symbolp (car s)) (push (cadr s) ps) (push (car s) ps)) (t (let (temp) (cond (temps (setq temp (pop temps))) (t (setq temp (gensym)) (push temp more-temps))) (push (cadr s) ps) (push temp ps) (lv-set-tree (car s) temp))))) (let ((body (if ss `((setq ,@ss)) nil))) (when ps (push `(psetq ,@ps) body)) (cond (more-temps `(let* ,more-temps ,@body)) ((endp (cdr body)) (car body)) (t (cons 'progn body))))))))) (defun lv-pair-tree (tree form &optional (rest nil)) (cond ((null tree) rest) ((atom tree) (cons (list tree form) rest)) (t (lv-pair-tree (car tree) `(car ,form) (lv-pair-tree (cdr tree) `(cdr ,form) rest))))) (defun lv-tree-symbols (tree &optional (more nil)) (cond ((null tree) more) ((atom tree) (cons tree more)) (t (lv-tree-symbols (car tree) (lv-tree-symbols (cdr tree) more))))) (defun parse-loop-body () (when (and (not (end-body)) (not (symbolp (car *loop-body*)))) (parse-do)) (do () ((end-body)) (parse-a-clause))) (defun parse-a-clause () (lkcase ((REPEAT) (do ((inf (parse-repeat) (merge-inf inf (lkcase (REPEAT (parse-repeat)) ((FOR AS) (parse-for)) (WITH (parse-with)) (:ow (parse-repeat)))))) ((lkcase (AND nil) (:ow t)) (set-iteration inf)))) ((FOR AS) (do ((inf (parse-for) (merge-inf inf (lkcase (REPEAT (parse-repeat)) ((FOR AS) (parse-for)) (WITH (parse-with)) (:ow (parse-for)))))) ((lkcase (AND nil) (:ow t)) (set-iteration inf)))) ((WITH) (do ((inf (parse-with) (merge-inf inf (lkcase (REPEAT (parse-repeat)) ((FOR AS) (parse-for)) (WITH (parse-with)) (:ow (parse-with)))))) ((lkcase (AND nil) (:ow t)) (set-iteration inf)))) ((NODECLARE) (pop-body)) ((INITIALLY) (parse-initially)) ((FINALLY) (parse-finally)) ((DO DOING) (parse-do)) ((COLLECT COLLECTING) (parse-collect)) ((NCONC NCONCING) (parse-nconc)) ((APPEND APPENDING) (parse-append)) ((COUNT COUNTING) (parse-count)) ((SUM SUMMING) (parse-sum)) ((MAXIMIZE MAXIMIZING) (parse-maximize)) ((MINIMIZE MINIMIZING) (parse-minimize)) ((WHILE) (do-it `(unless ,(pop-body) (go ,*t2*)))) ((UNTIL) (do-it `(when ,(pop-body) (go ,*t2*)))) ((LOOP-FINISH) (do-it `(go ,*t2*))) ((ALWAYS) (do-it `(unless ,(pop-body) (return)))) ((NEVER) (do-it `(when ,(pop-body) (return)))) ((THEREIS) (parse-thereis)) ((WHEN IF) (parse-when t)) ((UNLESS) (parse-when nil)) ((NAMED) (setq *named-block* (pop-body))) ((RETURN) (do-it `(return ,(lkcase (IT (get-it)) (:ow (pop-body)))))) (:ow (error "~S is an illegal LOOP keyword." (car *loop-body*))))) (defun merge-inf (inf inf1) (mapcar #'append inf inf1)) (defun set-iteration (inf) (flet ((make-end-test (tests) (cond ((cdr tests) `(when (or ,@tests) (go ,*t2*))) (t `(when ,(car tests) (go ,*t2*)))))) (push (first inf) *bindings*) (mapcar #'(lambda (x) (push x *prologue*)) (second inf)) (when (third inf) (push (make-end-test (third inf)) *post-steps*)) (when (fourth inf) (push (fourth inf) *post-steps*)) (when (fifth inf) (push (make-end-test (fifth inf)) *post-steps*)) (when (sixth inf) (push (sixth inf) *post-steps*)) (when (seventh inf) (push (make-end-test (seventh inf)) *pre-steps*)) (when (eighth inf) (push (eighth inf) *pre-steps*)) (when (ninth inf) (push (make-end-test (ninth inf)) *pre-steps*)) (when (tenth inf) (push (tenth inf) *pre-steps*)))) (defun parse-repeat () (let ((temp (gensym))) (list `((,temp ,(pop-body))) nil `((not (plusp ,temp))) `((,temp (1- ,temp))) nil nil `((not (plusp ,temp))) `((,temp (1- ,temp))) nil nil))) (defun parse-for () (let ((v (pop-body))) (parse-type '(FROM DOWNFROM UPFROM IN ON = FIRST BEING)) (lkcase (FROM (let ((init (pop-body)) test limit (step-fun '+) (step 1)) (lkcase (TO (setq test '> limit (pop-body)) (lkcase (BY (setq step (pop-body))))) (DOWNTO (setq test '< limit (pop-body) step-fun '-) (lkcase (BY (setq step (pop-body))))) (BELOW (setq test '>= limit (pop-body)) (lkcase (BY (setq step (pop-body))))) (ABOVE (setq test '<= limit (pop-body) step-fun '-) (lkcase (BY (setq step (pop-body))))) (BY (setq step (pop-body)) (lkcase (TO (setq test '> limit (pop-body))) (DOWNTO (setq test '< limit (pop-body) step-fun '-)) (BELOW (setq test '>= limit (pop-body))) (ABOVE (setq test '<= limit (pop-body) step-fun '-))))) (parse-for1 v init test limit step-fun step))) (DOWNFROM (parse-for1 v (pop-body) nil nil '- (lkcase (BY (pop-body)) (:ow 1)))) (UPFROM (parse-for1 v (pop-body) nil nil '+ (lkcase (BY (pop-body)) (:ow 1)))) (IN (let* ((form (pop-body)) (fun (lkcase (BY (pop-body)) (:ow '#'cdr))) (temp (gensym)) (inf (list nil nil nil nil `((endp ,temp)) nil nil nil `((endp ,temp)) nil))) (cond ((and (consp fun) (eq (car fun) 'function)) (push `(,temp (,(cadr fun) ,temp)) (fourth inf))) ((constantp fun) (push `(,temp (funcall ,fun ,temp)) (fourth inf))) (t (let ((temp1 (gensym))) (push (list temp1 fun) (first inf)) (push `(,temp (funcall ,temp1 ,temp)) (fourth inf))))) (push (list temp form) (first inf)) (cond ((symbolp v) (push `(,v (car ,temp)) (sixth inf)) (push `(,v (car ,temp)) (tenth inf)) (push v (first inf))) (t (let ((pairs (lv-pair-tree v `(car ,temp)))) (setf (sixth inf) pairs) (setf (tenth inf) pairs)) (mapc #'(lambda (x) (push x (first inf))) (nreverse (lv-tree-symbols v))))) inf)) (ON (let* ((form (pop-body)) (fun (lkcase (BY (pop-body)) (:ow '#'cdr)))) (cond ((symbolp v) (let ((inf (list nil nil nil nil `((endp ,v)) nil nil nil `((endp ,v)) nil))) (cond ((and (consp fun) (eq (car fun) 'function)) (push `(,v (,(cadr fun) ,v)) (fourth inf))) (t (unless (constantp fun) (let ((temp1 (gensym))) (push (list temp1 fun) (first inf)) (setq fun temp1))) (push `(,v (funcall ,fun ,v)) (fourth inf)))) (push (list v form) (first inf)) inf)) (t (let* ((temp (gensym)) (pairs (lv-pair-tree v temp)) (inf (list nil nil nil nil `((endp ,temp)) pairs nil nil `((endp ,temp)) pairs))) (cond ((and (consp fun) (eq (car fun) 'function)) (push `(,temp (,(cadr fun) ,temp)) (fourth inf))) (t (unless (constantp fun) (let ((temp1 (gensym))) (push (list temp1 fun) (first inf)) (setq fun temp1))) (push `(,temp (funcall ,fun ,temp)) (fourth inf)))) (push (list temp form) (first inf)) (mapc #'(lambda (x) (push x (first inf))) (nreverse (lv-tree-symbols v))) inf))))) (= (let* ((init (pop-body))) (lkcase (THEN (list `((,v ,init)) nil nil `((,v ,(pop-body))) nil nil nil nil nil nil)) (:ow (list `((,v nil)) nil nil `((,v ,init)) nil nil nil `((,v ,init)) nil nil))))) (FIRST (let* ((init (pop-body)) (form (lkcase (THEN (pop-body)) (:ow (error "THEN missing after FIRST."))))) (list `((,v nil)) nil nil `((,v ,form)) nil nil nil `((,v ,init)) nil nil))) (BEING (parse-loop-path v)) (:ow (error "~S is an illegal LOOP keyword" (car *loop-body*)))))) (defun parse-for1 (v init test limit step-fun step) (unless (symbolp v) (error "The FOR control variable ~S cannot be destructured." v)) (let ((inf (make-list 10))) (unless (numberp step) (let ((temp (gensym))) (push (list temp step) (first inf)) (setq step temp))) (when test (unless (numberp limit) (let ((temp (gensym))) (push (list temp limit) (first inf)) (setq limit temp))) (let ((x (list test v limit))) (push x (fifth inf)) (push x (ninth inf)))) (push (list v init) (first inf)) (push (list v (list step-fun v step)) (fourth inf)) inf)) (defun parse-loop-path (v) (let ((flag nil) (pps nil) path (*loop-named-variables* nil)) (lkcase ((EACH THE) (setq path (pop-body))) (:ow (setq path (pop-body)) (lkcase (AND (setq flag t) (push (list 'of (pop-body)) pps) (lkcase ((ITS EACH HIS HER THEIR) (setq path (pop-body))) (:ow (error "ITS is missing after FOR..BEING..AND."))))))) (unless (symbolp path) (error "The LOOP path-name ~S is not a symbol." path)) (let ((def (gethash (symbol-name path) *loop-paths*)))  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 4 Sep 87 14:09:00 EDT Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 4 Sep 87 10:52:36 PDT Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 228277; Fri 4-Sep-87 13:53:08 EDT Date: Fri, 4 Sep 87 13:52 EDT From: David A. Moon Subject: Common Lisp LOOP To: Michael Ginn cc: common-lisp@sail.stanford.edu In-Reply-To: <12331825355.20.GINN@SUMEX-AIM.STANFORD.EDU> File-References: AI.AI.MIT.EDU: GSB; CLLOOP > Message-ID: <870904135252.8.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Thu, 3 Sep 87 21:19:52 PDT From: Michael Ginn Has anyone written a LOOP macro for common lisp? Check the file GSB;CLLOOP which you can retrieve from AI.AI.MIT.EDU by FTP. You don't need a password to retrieve files from there.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 4 Sep 87 00:40:28 EDT Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 3 Sep 87 21:19:20 PDT Received: from SUMEX-AIM.Stanford.EDU by navajo.stanford.edu with TCP; Thu, 3 Sep 87 21:16:22 PDT Date: Thu, 3 Sep 87 21:19:52 PDT From: Michael Ginn Subject: Common Lisp LOOP To: common-lisp%sail.stanford.edu@navajo.stanford.edu Message-Id: <12331825355.20.GINN@SUMEX-AIM.STANFORD.EDU> Has anyone written a LOOP macro for common lisp? Most of the common lisps I use, besides the Symbolics and TI versions, have no definition at all for LOOP. (In Steele's book, LOOP is mentioned only as a future possibility for extension of the common lisp specification). Most specifically, I'd like to use it in KCL and in Post-Penultimate Common Lisp, but of course any definition conforming to the specification would probably work. ---Michael Ginn -------  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 29 Aug 87 19:31:23 EDT Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 29 Aug 87 16:17:54 PDT Received: from Cabernet.ms by ArpaGateway.ms ; 29 AUG 87 16:18:10 PDT Date: 29 Aug 87 16:18 PDT From: Masinter.pa@Xerox.COM Subject: Re: cleanup status? In-reply-to: sandra%orion%cs.utah:EDU:Xerox's message of 28 Aug 87 09:19 To: common-lisp@Sail.stanford.edu Message-ID: <870829-161810-4731@Xerox> A number of messages have come by referring to the "cleanup committee". The cleanup committee is a sub-committee of X3J13, which, as you know, is the ANSII organization working on Common Lisp standardization. Our process has been to solicit proposals from members of X3J13 (and ourselves), and then make recommendations to X3J13. All decisions about the standard must be made by the full X3J13 committee. Results of those ballots are reported in the X3J13 minutes. While a number of us read Common-lisp@Sail.stanford.edu, and we frequently use it as a resource, there is no process by which issues discussed on this list automatically become proposals for X3J13. Of the issues you mention, none of them have been brought up before the cleanup committee directly. I believe two of the issues you mention ("which DEFxxx forms should be processed at compile time", and "declarations in FLET/LABELS") await some further input from other subcommittees.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 28 Aug 87 20:21:14 EDT Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 28 Aug 87 17:02:17 PDT Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 223700; Fri 28-Aug-87 20:02:37 EDT Date: Fri, 28 Aug 87 20:02 EDT From: Kent M Pitman Subject: length To: edsel!bhopal!jonl@LABREA.STANFORD.EDU cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, DALY@IBM.COM, Common-Lisp@SAIL.STANFORD.EDU In-Reply-To: <8708282220.AA02711@bhopal.edsel.com> Message-ID: <870828200231.4.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> Date: Fri, 28 Aug 87 15:20:00 PDT From: edsel!bhopal!jonl@labrea.stanford.edu (Jon L White) Your presumption that Lucid's ENDP returns something rather than signalling an error on "erroneous" arguments isn't borne out. Sorry. I must have mis-read something. In any case, my main point was that much flexibility is (for better or worse) legal. I thought you were flexing differently than we, but even if you weren't, some other implementation probably is. The intended point about CLtL, p265, is that LIST-LENGTH should view the matter the same way that ENDP does. [Assuming I understand you this time,] I don't agree. It is permitted to do so, but not required to do so. The definition shown is only a sample and is not definitional. Just because they both do something undefined doesn't mean they have to do the same undefined thing. My reading is that an implementation for which (ENDP 'A) returns T may still signal an error on (LIST-LENGTH '(A . A)). Similarly, even if (LIST-LENGTH '(A . A)) returns 1, (ENDP 'A) may signal an error. It is somewhat possible that what you say (LIST-LENGTH and ENDP should behave in a correlated fashion) was the intention of the author(s), but if so I don't believe that this intent was adequately carried through into the written word.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 28 Aug 87 20:00:17 EDT Received: from LABREA.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 28 Aug 87 16:45:06 PDT Received: by labrea.stanford.edu; Fri, 28 Aug 87 16:25:52 PDT Received: from bhopal.edsel.com by edsel.uucp (3.2/SMI-2.0) id AA07586; Fri, 28 Aug 87 15:19:51 PDT Received: by bhopal.edsel.com (3.2/SMI-3.2) id AA02711; Fri, 28 Aug 87 15:20:00 PDT Date: Fri, 28 Aug 87 15:20:00 PDT From: edsel!bhopal!jonl@labrea.stanford.edu (Jon L White) Message-Id: <8708282220.AA02711@bhopal.edsel.com> To: labrea!KMP%STONY-BROOK.SCRC.Symbolics.COM@labrea.stanford.edu Cc: labrea!DALY%IBM.COM@labrea.stanford.edu, labrea!Common-Lisp%SAIL@labrea.stanford.edu In-Reply-To: Kent M Pitman's message of Fri, 28 Aug 87 15:45 EDT <870828154557.8.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> Subject: length Your presumption that Lucid's ENDP returns something rather than signalling an error on "erroneous" arguments isn't borne out. The intended point about CLtL, p265, is that LIST-LENGTH should view the matter the same way that ENDP does. -- JonL --  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 28 Aug 87 16:10:19 EDT Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 28 Aug 87 12:45:52 PDT Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 223450; Fri 28-Aug-87 15:46:11 EDT Date: Fri, 28 Aug 87 15:45 EDT From: Kent M Pitman Subject: length To: DALY@IBM.COM, edsel!bhopal!jonl@LABREA.STANFORD.EDU cc: Common-Lisp@SAIL.STANFORD.EDU, KMP@STONY-BROOK.SCRC.Symbolics.COM In-Reply-To: <082787.141428.daly@ibm.com>, <8708281605.AA00537@bhopal.edsel.com> Message-ID: <870828154557.8.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> Date: 27 August 1987, 14:14:28 EDT From: Timothy Daly Is (LENGTH '(3 . 3)) an error? Yes, but it doesn't necessarily signal an error. Lucid Common returns 1. Symbolics Common returns error. This is reasonable and consistent. You're talking about a situation which is beyond the scope of the specification. [By the way, as a point of terminology, programs don't "return" errors, they signal them. Indeed, signalling an error is what one does when one doesn't want to return.] The bible states: p248: length takes a sequence p245: sequences are lists and arrays p27: often the term list refers either to true lists or to dotted lists. When the distinction is important, the term "true list" will be used to refer to a list terminated by nil. Most functions advertised to operate on lists expect to be given true lists. Throughout this manual, unless otherwise specified, it is an error to pass a dotted list to a function that is specified to require a list as an argument. p27: implementors are encouraged to use the equivalent of the predicate ENDP whenever it is necessary to test for the end of a list. Whenever feasible, this test should explicitly signal an error if a list is found to be terminated by a non-nil atom. However, such an explicit error is not required .... It seems that one should 'signal an error' and that it 'is an error' but, well, maybe not. The wording you cite is extremely clear to me. The situation is an error. Implementations are encouraged to signal an error (Symbolics does this) but are not required to (Lucid does this). comments? Has this been resolved before? Probably -- though in fact there is nothing really to resolve. The point of "is an error" situations is that we're telling programmers that they cannot depend on the behavior of their programs in this situation. See the bottom of p5 -- it is technically legitimate for (length '(3 . 3)) to do anything at all. ----- Date: Fri, 28 Aug 87 09:05:15 PDT From: edsel!bhopal!jonl@labrea.stanford.edu (Jon L White) In addition to your list of quotes from CLtL pertaining to (LENGTH '(3 . 3)), I refer you to page 265, which says that "LIST-LENGTH could be implemented as follows: (defun list-length (x) (do ((n 0 (+ 2 n)) (fast x (cddr fast)) (slow x (cdr slow))) (nil) (when (endp fast) (return n)) (when (endp (cdr fast)) (return (+ n 1))) (when (and (eq fast slot) (> n 0)) (return nil)))) " The use of 'endp' here seems to imply that Lucid's implemention is not in conformance with CLtL. The decision to admit non-standard lists everywhere in the sequence functions was taken long before my coming to Lucid, and no one now seems to remember exactly why it was decided that way. But I have heard claims that the matter was discussed with Guy Steele in the fall of 1984, and he concurred (so goes the claim) that signalling an error on non-standard lists isn't required. Don't sell your people short, Jonl. I think the current Lucid position is completely defensible. (It happens not to be the behavior I'd prefer personally, but my objections would be aesthetic, not biblical.) The use of ENDP is what makes it optional whether you support dotted lists. The description of ENDP on p264 quite clearly says it is "false for conses, true for NIL, and an error for all other arguments." p5 defines what "is an error" means and it's quite liberal in what interpretations it allows. Now, the implementation note which follows suggests that if it is not going to signal an error, it should return T for non-null atoms (which Lucid presumably does), but I'm not completely convinced that even that behavior is forced (because of its placement in a note rather than in the text of the definition and because the text of the definition is so unambiguous).  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 28 Aug 87 12:43:04 EDT Received: from LABREA.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 28 Aug 87 09:16:42 PDT Received: by labrea.stanford.edu; Fri, 28 Aug 87 08:57:31 PDT Received: from bhopal.edsel.com by edsel.uucp (3.2/SMI-2.0) id AA06656; Fri, 28 Aug 87 09:05:08 PDT Received: by bhopal.edsel.com (3.2/SMI-3.2) id AA00537; Fri, 28 Aug 87 09:05:15 PDT Date: Fri, 28 Aug 87 09:05:15 PDT From: edsel!bhopal!jonl@labrea.stanford.edu (Jon L White) Message-Id: <8708281605.AA00537@bhopal.edsel.com> To: labrea!DALY%ibm.com@labrea.stanford.edu Cc: labrea!common-lisp%sail@labrea.stanford.edu In-Reply-To: Timothy Daly's message of 27 August 1987, 14:14:28 EDT <082787.141428.daly@ibm.com> Subject: length In addition to your list of quotes from CLtL pertaining to (LENGTH '(3 . 3)), I refer you to page 265, which says that "LIST-LENGTH could be implemented as follows: (defun list-length (x) (do ((n 0 (+ 2 n)) (fast x (cddr fast)) (slow x (cdr slow))) (nil) (when (endp fast) (return n)) (when (endp (cdr fast)) (return (+ n 1))) (when (and (eq fast slot) (> n 0)) (return nil)))) " The use of 'endp' here seems to imply that Lucid's implemention is not in conformance with CLtL. The decision to admit non-standard lists everywhere in the sequence functions was taken long before my coming to Lucid, and no one now seems to remember exactly why it was decided that way. But I have heard claims that the matter was discussed with Guy Steele in the fall of 1984, and he concurred (so goes the claim) that signalling an error on non-standard lists isn't required. -- JonL --  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 28 Aug 87 12:04:30 EDT Received: from CS.UTAH.EDU by SAIL.STANFORD.EDU with TCP; 28 Aug 87 08:49:18 PDT Received: by cs.utah.edu (5.54/utah-1.0) id AA01843; Fri, 28 Aug 87 09:52:13 MDT Received: by orion.utah.edu (5.54/utah-1.0-slave) id AA15136; Fri, 28 Aug 87 09:52:09 MDT Date: Fri, 28 Aug 87 09:52:09 MDT From: sandra%orion@cs.utah.edu (Sandra J Loosemore) Message-Id: <8708281552.AA15136@orion.utah.edu> Subject: cleanup status? To: common-lisp@sail.stanford.edu Have there been any decisions made by the cleanup committee on issues that have been previously hashed out in gory detail on this mailing list? If so, is there a document that describes what changes have been approved? Some of the areas of concern are: - which DEFxxx forms should be processed at compile time - clarifications on syntax for DEFMACRO lambda lists - PARSE-BODY function and extensions to &BODY - declarations in FLET/LABELS - etc. I don't want to initiate more flaming on these topics, I just want to know if anything has been resolved or not. -Sandra -------  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 28 Aug 87 10:45:38 EDT Received: from DECWRL.DEC.COM by SAIL.STANFORD.EDU with TCP; 28 Aug 87 07:18:14 PDT Received: from decvax.dec.com by decwrl.dec.com (5.54.4/4.7.34) id AA09869; Fri, 28 Aug 87 07:18:26 PDT Received: from admin.uucp (mcae) by cvbnet.uucp (2.0/SMI-2.0) id AA02024; Fri, 28 Aug 87 10:04:34 edt Received: from expert.uucp by admin.uucp (3.2/SMI-3.0DEV3) id AA13811; Fri, 28 Aug 87 10:09:13 EDT Received: by expert.uucp (3.2/SMI-3.0DEV3) id AA04278; Fri, 28 Aug 87 10:00:48 EDT Date: Fri, 28 Aug 87 10:00:48 EDT From: decvax!cvbnet!expert!pmorris@decwrl.dec.com (Peter Morris ) Message-Id: <8708281400.AA04278@expert.uucp> To: cvbnet!decvax!decwrl!sail.stanford.edu!common-lisp Subject: New Reader Please add me to the mail list for common-lisp. Thank you. ...!decwrl!decvax!cvbnet!expert!pmorris Peter J. Morris Computervision Inc. 14 Crosby Drive Bedford, MA 01730 (617) 275-1800 X4140  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 27 Aug 87 17:04:58 EDT Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 27 Aug 87 13:44:43 PDT Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 222421; Thu 27-Aug-87 16:45:50 EDT Date: Thu, 27 Aug 87 16:45 EDT From: David A. Moon Subject: The values returned by SETF To: common-lisp@SAIL.STANFORD.EDU In-Reply-To: Message-ID: <870827164522.5.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Tue, 25 Aug 1987 10:12 EDT From: Ram@C.CS.CMU.EDU Date: Monday, 24 August 1987 14:47-EDT From: David A. Moon To: D. Loewenstern Re: The values returned by SETF Date: Mon, 24 Aug 87 14:25:04 EDT From: dml@nadc.arpa (D. Loewenstern) Is the value returned by SETF defined in general, for all standard get/put functions? Specifically, what is returned by (SETF (VALUES IGNORE X) (VALUES 1 2))? SETF returns the values of its last subform (CLtL p.97). Actually, it says "the ultimate result of evaluating the setf form is the value of newvalue." I would interpret your restatement to mean that it has to return all the values of the newvalue form. I can't see how you can do this in a Common Lisp macro without using Multiple-Value-List. At least in our implementation: (setf foo (values 1 2 3)) => 1 I would guess that the actual rule is that setf returns the number of values that the setf method was expecting (supposing that the setf method writer bothers to return the right value(s)). The setf method writer has to return the right values, or he didn't write his setf method correctly. The question is what are the right values. I now agree with you that it shouldn't be all the values of , and that CLtL isn't trying to say that. Here's what I would propose. For all of the standard SETFs documented in CLtL, which use only one value of , a portable program can depend on SETF returning that one value and cannot depend on any additional values. Implementations that implement the extension (SETF (VALUES ...) ...) should return all the values that are used. Thus the answer to the original question is that in implementations where the form is not an error, it returns two values, 1 and 2.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 27 Aug 87 15:55:55 EDT Received: from IBM.COM by SAIL.STANFORD.EDU with TCP; 27 Aug 87 12:39:32 PDT Date: 27 August 1987, 14:14:28 EDT From: Timothy Daly To: common-lisp@sail.stanford.edu Message-Id: <082787.141428.daly@ibm.com> Subject: length Is (LENGTH '(3 . 3)) an error? Lucid Common returns 1. Symbolics Common returns error. The bible states: p248: length takes a sequence p245: sequences are lists and arrays p27: often the term list refers either to true lists or to dotted lists. When the distinction is important, the term "true list" will be used to refer to a list terminated by nil. Most functions advertised to operate on lists expect to be given true lists. Throughout this manual, unless otherwise specified, it is an error to pass a dotted list to a function that is specified to require a list as an argument. p27: implementors are encouraged to use the equivalent of the predicate ENDP whenever it is necessary to test for the end of a list. Whenever feasible, this test should explicitly signal an error if a list is found to be terminated by a non-nil atom. However, such an explicit error is not required .... It seems that one should 'signal an error' and that it 'is an error' but, well, maybe not. comments? Has this been resolved before? tim DALY@IBM.COM IBM T.J. Watson Research Center Yorktown Heights, N.Y.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 25 Aug 87 18:45:57 EDT Received: from [192.5.53.205] by SAIL.STANFORD.EDU with TCP; 25 Aug 87 15:26:46 PDT Date: Tue, 25 Aug 87 18:23 EDT From: Brad Miller Subject: SHADOW et. al To: common-lisp@sail.stanford.edu Message-ID: <870825182322.3.MILLER@DOUGHNUT.CS.ROCHESTER.EDU> Default-Character-Style: (:FIX :CONDENSED :NORMAL) Fonts: CPTFONTC Sender: miller@cs.rochester.edu Reply-To: miller@cs.rochester.edu Organization: University of Rochester, Department of Computer Science Postal-address: Computer Science Department, University of Rochester, Rochester NY 14627 Phone: Currently: 716-275-7747 After 1 Sept. also try: 716-275-1118 Actually this discussion of shadow brings to mind a problem I have had with CL packages, which deals with just what symbol you get... Lets presume that the symbol FOO exists in 3 places, packages A B and C... I create package D which will :USE A B C. Which foo does it get? well, probably it will complain, and force you to shadowing-import one of them. What I would sort of like to see (others probably know more about the issues here than I do) is that the USE list of a package is also the order in which the packages are searched to resolve symbol references. Thus in the above example, a reference to FOO in D would be resolved as A::FOO with *no complaint* about the duplicates in B and C. For debugging purposes, there can be some special the package system uses to complain about duplicates as in the above, what I want is a mechanism such that there is a default, normal, behavior for such things, which allows this duplication. Brad Miller ------ miller@cs.rochester.edu {...[allegra|seismo]!rochester!miller} Brad Miller University of Rochester Computer Science Department NOTE: Our computers will be down the first week of September to be moved to a new home. If mail should fail, please retry. TKS!  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 25 Aug 87 17:14:37 EDT Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 25 Aug 87 13:54:50 PDT Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 220537; Tue 25-Aug-87 16:52:56 EDT Date: Tue, 25 Aug 87 16:52 EDT From: David A. Moon Subject: Interpretation of shadowing [and type of argument to SHADOW] To: Jon L White cc: Common-lisp@sail.stanford.edu In-Reply-To: <8708251851.AA15097@bhopal.edsel.com> Message-ID: <870825165230.3.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Tue, 25 Aug 87 11:51:21 PDT From: edsel!bhopal!jonl@labrea.stanford.edu (Jon L White) I would like to see SHADOW changed to take strings as arguments, rather than symbols. More realistically, it should at least be permitted to take strings as well as symbols. You're right of course. A close reading of CLtL shows that one can already use (shadow '#:bar) in place of (shadow 'bar), to achieve much the same effect as (shadow "bar"). But the user should not have to play such games, strings should be accepted. Current practice: shadow already accepts strings in Symbolics Common Lisp.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 25 Aug 87 15:27:37 EDT Received: from LABREA.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 25 Aug 87 12:01:51 PDT Received: by labrea.stanford.edu; Tue, 25 Aug 87 11:42:33 PDT Received: from bhopal.edsel.com by edsel.uucp (3.2/SMI-2.0) id AA05644; Tue, 25 Aug 87 11:50:54 PDT Received: by bhopal.edsel.com (3.2/SMI-3.2) id AA15097; Tue, 25 Aug 87 11:51:21 PDT Date: Tue, 25 Aug 87 11:51:21 PDT From: edsel!bhopal!jonl@labrea.stanford.edu (Jon L White) Message-Id: <8708251851.AA15097@bhopal.edsel.com> To: labrea!Moon%STONY-BROOK.SCRC.Symbolics.COM@labrea.stanford.edu Cc: labrea!unido!ztivax!kolb%seismo.CSS.GOV@labrea.stanford.edu, labrea!samalone%ATHENA.MIT.EDU@labrea.stanford.edu, labrea!Common-lisp%sail@labrea.stanford.edu In-Reply-To: David A. Moon's message of Mon, 24 Aug 87 14:07 EDT <870824140704.4.MOON@EUPHRATES.SCRC.Symbolics.COM> Subject: Interpretation of shadowing [and type of argument to SHADOW] re: ... The SHADOW function always adds the symbol to the PACKAGE-SHADOWING-SYMBOLS list, and the informal wording on p.186 of CLtL should not be interpreted otherwise. At Lucid (against our better instincts!) we followed the "letter of the law" on page 186. That phraseology is certainly misguided, but not exactly ambiguous: "If , then nothing is done. Otherwise, . [And]... also ." I say, "not ambiguous" because the sentence "[And]... also " only parses in the context of "something having been done", so that is done ALSO, or "in addition" to that "something". However, that behaviour -- even if mandated by CLtL -- is not productive, and I would very much like to see it redefined. On the other hand, this glitch hasn't been the source of the most serious problem with SHADOW. The fact that it's argument is a symbol, which it immediately discards after extracting the symbol-name, has caused a very subtle bug in virtually every implementation's compiled-code format. To avoid this bug, I would like to see SHADOW changed to take strings as arguments, rather than symbols. More realistically, it should at least be permitted to take strings as well as symbols so that one can avoid the lossage evident in the following example. Consider the file: (in-package "FOO") (shadow 'bar) ;maybe this BAR is inherited from LISP? (print (symbol-package 'bar)) ;but this BAR should be only in FOO. How will the call to shadow be compiled when BAR is already present in FOO as an internal shadowing symbol? Now consider how that compiled file will load into a runtime environment whose package structure is DIFFERENT from that of the compile-time environment in the critical aspect that BAR is not present in the FOO package (much less being present as a shadowing symbol). Admittedly, CLtL give the user no guarantees if he doesn't arrange to have his runtime package environment "the same" as the compile time one; but this scenario is a very common, forgivable one. It will happen if you compile a file twice (from the same Lisp image), and then load the result into a fresh Lisp image. At least one Common Lisp implementation has it's compiler recognize top-level calls to shadow and compile them specially. But this is a fix only for the specific situation of top-level calls, not for a call like: (in-package "FOO) (funcall (if (probably-true) #'shadow #'print) 'bar) ;maybe this BAR is inherited from LISP? (print (symbol-package 'bar)) ;but this BAR should be only in FOO. A much better solution would be to allow the author of this code to write: (in-package "FOO) (funcall (if (probably-true) #'shadow #'print) "BAR") ;No question about this "BAR" ! (print (symbol-package 'bar)) ;and this BAR should be only in FOO. instead. -- JonL -- P.S. Please, no discussion on why (if (probably-true) #'shadow #'print)) is a useless line of code. I picked it only to illustrate that this particular SHADOW problem isn't completely solved by having the compiler statically re-write the user's code.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 25 Aug 87 10:30:43 EDT Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 25 Aug 87 07:13:37 PDT Received: ID ; Tue 25 Aug 87 10:13:02-EDT Date: Tue, 25 Aug 1987 10:12 EDT Message-ID: Sender: RAM@ From: Ram@C.CS.CMU.EDU To: "David A. Moon" Cc: common-lisp@SAIL.STANFORD.EDU, "D. Loewenstern" Subject: The values returned by SETF In-reply-to: Msg of 24 Aug 1987 14:47-EDT from David A. Moon Date: Monday, 24 August 1987 14:47-EDT From: David A. Moon To: D. Loewenstern Re: The values returned by SETF Date: Mon, 24 Aug 87 14:25:04 EDT From: dml@nadc.arpa (D. Loewenstern) Is the value returned by SETF defined in general, for all standard get/put functions? Specifically, what is returned by (SETF (VALUES IGNORE X) (VALUES 1 2))? SETF returns the values of its last subform (CLtL p.97). Actually, it says "the ultimate result of evaluating the setf form is the value of newvalue." I would interpret your restatement to mean that it has to return all the values of the newvalue form. I can't see how you can do this in a Common Lisp macro without using Multiple-Value-List. At least in our implementation: (setf foo (values 1 2 3)) => 1 I would guess that the actual rule is that setf returns the number of values that the setf method was expecting (supposing that the setf method writer bothers to return the right value(s)). Rob  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 24 Aug 87 16:23:26 EDT Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 24 Aug 87 13:09:50 PDT Received: from Semillon.ms by ArpaGateway.ms ; 24 AUG 87 13:07:49 PDT Date: Mon, 24 Aug 87 13:07:36 PDT From: Pavel.pa@Xerox.COM Subject: Re: The values returned by SETF In-reply-to: <8708241825.AA20419@NADC.ARPA> To: dml@nadc.arpa (D. Loewenstern) Cc: common-lisp@sail.stanford.edu Message-ID: <870824-130749-7757@Xerox> Specifically, what is returned by (SETF (VALUES IGNORE X) (VALUES 1 2))? Common Lisp does not define the behaviour of SETF of VALUES. Do you have a question about one of the ccases that IS defined? Pavel  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 24 Aug 87 15:19:03 EDT Received: from LANL.GOV by SAIL.STANFORD.EDU with TCP; 24 Aug 87 12:04:35 PDT Received: by LANL.GOV (5.54/1.14) id AA28950; Mon, 24 Aug 87 13:02:21 MDT Date: Mon, 24 Aug 87 13:02:21 MDT Message-Id: <8708241902.AA28950@LANL.GOV> From: 093725%incdp1@LANL.GOV (TOM NORRIS) To: common-lisp@sail.stanford.edu Subject: New Address for Common Lisp Common_Iisp: I have a new mailing address for receiving mail from the Common-lisp. The old address was: 093725%incdp1.xnet@lanl.gov The new address is: tln@beta.lanl.gov Thank-you Tom Norris Los Alamos National Lab. 505-667-4630  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 24 Aug 87 15:02:02 EDT Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 24 Aug 87 11:47:55 PDT Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 219303; Mon 24-Aug-87 14:48:12 EDT Date: Mon, 24 Aug 87 14:47 EDT From: David A. Moon Subject: The values returned by SETF To: D. Loewenstern cc: common-lisp@sail.stanford.edu In-Reply-To: <8708241825.AA20419@NADC.ARPA> Message-ID: <870824144731.8.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Mon, 24 Aug 87 14:25:04 EDT From: dml@nadc.arpa (D. Loewenstern) Is the value returned by SETF defined in general, for all standard get/put functions? Specifically, what is returned by (SETF (VALUES IGNORE X) (VALUES 1 2))? SETF returns the values of its last subform (CLtL p.97). SETF of VALUES is an extension to Common Lisp, but that shouldn't change the rules for what SETF returns.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 24 Aug 87 14:37:11 EDT Received: from NADC.ARPA by SAIL.STANFORD.EDU with TCP; 24 Aug 87 11:22:53 PDT Received: by NADC.ARPA (5.51/1.0 ) id AA20419; Mon, 24 Aug 87 14:25:04 EDT Date: Mon, 24 Aug 87 14:25:04 EDT From: dml@nadc.arpa (D. Loewenstern) Message-Id: <8708241825.AA20419@NADC.ARPA> To: common-lisp@sail.stanford.edu Subject: The values returned by SETF Cc: dml@NADC.ARPA Is the value returned by SETF defined in general, for all standard get/put functions? Specifically, what is returned by (SETF (VALUES IGNORE X) (VALUES 1 2))? Gold Hill's GCLISP (LM version) seems to return 1 when evaled but NIL when compiled. David Loewenstern Naval Air Development Center code 7013 Warminster, PA 18974-5000  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 24 Aug 87 14:26:11 EDT Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 24 Aug 87 11:11:39 PDT Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 219204; Mon 24-Aug-87 14:07:36 EDT Date: Mon, 24 Aug 87 14:07 EDT From: David A. Moon Subject: Interpretation of shadowing To: Dieter Kolb , samalone@ATHENA.MIT.EDU cc: Common-lisp@sail.stanford.edu In-Reply-To: <8708241350.AA23968@ztivax.uucp>, <8708241451.AA28748@HADES.MIT.EDU> Message-ID: <870824140704.4.MOON@EUPHRATES.SCRC.Symbolics.COM> I agree with Malone. The SHADOW function always adds the symbol to the PACKAGE-SHADOWING-SYMBOLS list, and the informal wording on p.186 of CLtL should not be interpreted otherwise. This does not seem to be on the cleanup subcommittee's agenda yet, so I'll add a writeup of the issue. Thanks for pointing it out.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 24 Aug 87 11:08:48 EDT Received: from ATHENA.MIT.EDU by SAIL.STANFORD.EDU with TCP; 24 Aug 87 07:53:01 PDT Received: by ATHENA.MIT.EDU (5.45/4.7) id AA18770; Mon, 24 Aug 87 10:52:55 EDT From: Received: by HADES.MIT.EDU (5.45/4.7) id AA28748; Mon, 24 Aug 87 10:51:46 EDT Message-Id: <8708241451.AA28748@HADES.MIT.EDU> To: "Dieter Kolb" Cc: common-lisp@sail.stanford.edu Subject: Re: Interpretation of shadowing In-Reply-To: Your message of Mon, 24 Aug 87 14:50:37 -0100. <8708241350.AA23968@ztivax.uucp> Date: Mon, 24 Aug 87 10:51:44 EDT CLtL describes in section 11.5, page 180 a name conflict problem by applying the function use-package. The name conflict is between a symbol directly present in the using package and an external symbol of the used package. This name conflict may be resolved in favor of the symbol directly present in the using package by making it a shadowing symbol. However, CLtL gives no advice how that should be done. In our understanding the function shadow should be used to resolve this name conflict. However the function shadow has no effect, if the symbol is already present in the package (CLtL, section 11.7). So, following CLtL, this could not be the solution... I understand your confusion. I believe that the problem is due to an ambiguity in the definition of SHADOW given in CLtL. (Someone on the cleanup committee should correct me if I'm wrong.) Unfortunately, many Common Lisp implementers have taken the wrong interpretation of this section of the manual, and so propagated the confusion on to their users. You are correct that SHADOW should be used to resolve the name conflict you described. Interpreted correctly, CLtL describes a SHADOW function that _is_ capable of resolving the name conflict. When CLtL says that "If such a symbol is present in this package, nothing is done", this is intended to contrast only with the following sentence, which says "Otherwise, a new symbol is created with this print name..." The next sentence that says "The symbol is also placed on the shadowing-symbols list of package" applies regardless of whether such a symbol is present in this package or not. Given this interpretation, SHADOW has an effect whether the symbol is already present in the package or not (unless it is already a shadowing symbol), and so is the correct way to resolve the name conflict you described. From the descriptions you provided, it sounds like the SPICE LISP implementers did the right thing. --Stuart A. Malone  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 24 Aug 87 09:41:52 EDT Received: from seismo.CSS.GOV by SAIL.STANFORD.EDU with TCP; 24 Aug 87 06:28:20 PDT Received: from unido.UUCP by seismo.CSS.GOV (5.54/1.14) with UUCP id AA04764; Mon, 24 Aug 87 09:28:24 EDT Received: by unido.uucp with uucp; Mon, 24 Aug 87 14:52:38 +0100 From: "Dieter Kolb" Date: Mon, 24 Aug 87 14:50:37 -0100 Message-Id: <8708241350.AA23968@ztivax.uucp> Received: by ztivax.uucp; Mon, 24 Aug 87 14:50:37 -0100 To: Common-lisp@sail.stanford.edu Subject: Interpretation of shadowing Cc: unido!Dieter@seismo.CSS.GOV, unido!Kolb@seismo.CSS.GOV CLtL describes in section 11.5, page 180 a name conflict problem by applying the function use-package. The name conflict is between a symbol directly present in the using package and an external symbol of the used package. This name conflict may be resolved in favor of the symbol directly present in the using package by making it a shadowing symbol. However, CLtL gives no advice how that should be done. In our understanding the function shadow should be used to resolve this name conflict. However the function shadow has no effect, if the symbol is already present in the package (CLtL, section 11.7). So, following CLtL, this could not be the solution. Therefore, we investigated some other CL implementations: Lucid Common LISP on Apollo DOMAIN as well as Xerox LISP: The name conflict can be resolved by using the function shadowing-import SPICE LISP: The functionality of the function shadow in SPICE LISP is extended. shadow works also if the symbol is already present. So, the name conflict can be resolved by using the function shadow. (However, shadow works different as described in CLtL.) Kyoto Common Lisp on VAX: shadow works as described in CLtL. The name conflict cannot be resolved in this system. How should CLtL be interpreted with respect to this problem? Dieter Kolb  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 18 Aug 87 16:52:54 EDT Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 18 Aug 87 13:28:28 PDT Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 215806; Tue 18-Aug-87 16:28:17 EDT Date: Tue, 18 Aug 87 16:27 EDT From: David A. Moon Subject: FLET & declarations To: GZ%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU cc: common-lisp@SAIL.STANFORD.EDU In-Reply-To: <12327146435.14.GZ@OZ.AI.MIT.EDU> Message-ID: <870818162759.2.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Mon 17 Aug 87 03:57:47-EDT From: GZ%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU Are 'pervasive' declarations in FLET supposed to apply to the function bodies? E.g. (flet ((foo () x)) ;Is this x special? (declare (special x)) ...) (flet ((foo () (foo) ...)) ;Does this call to (foo) return a fixnum? (declare (function foo () fixnum)) ...) (flet ((foo () (foo 17))) ;Is (foo 17) inline? (declare (inline foo)) ...) CLtL does not permit DECLARE to be used in that position (see p.113). I believe it has been proposed to change that, although I couldn't find a copy of the proposal in my rather disorganized files. I would argue that the paragraph in the middle of page 155 of CLtL supports the position that when this extension is made, the pervasive declarations should apply to the function bodies. Note that the FUNCTION declaration used in your middle example is not pervasive. Since you use FLET rather than LABELS, this declaration would not apply to the call to FOO within the body of FOO. It's a different FOO. The INLINE declaration is said by CLtL to be pervasive, however I believe that to be a bug since it makes it unclear which of the two FOOs in your example it refers to. Perhaps it refers to both. Anyone putting together a proposal to clean up the specification of declarations in Common Lisp ought to address the issues raised by your question.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 18 Aug 87 12:14:36 EDT Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 18 Aug 87 09:02:15 PDT Received: from LIVE-OAK.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 18 Aug 87 12:02-EDT Received: from ACORN.Gold-Hill.DialNet.Symbolics.COM by MIT-LIVE-OAK.DialNet.Symbolics.COM via DIAL with SMTP id 55991; 18 Aug 87 11:56:15-EDT Received: from BOSTON.Gold-Hill.DialNet.Symbolics.COM by ACORN.Gold-Hill.DialNet.Symbolics.COM via CHAOS with CHAOS-MAIL id 78425; Tue 18-Aug-87 11:39:11-EDT Date: Tue, 18 Aug 87 11:44 est From: mike%acorn@oak.lcs.mit.edu To: RpK%acorn@oak.lcs.mit.edu Subject: Question on function type spec and lambda-list keywords Cc: common-lisp@sail.stanford.edu Date: Mon, 3 Aug 87 12:39 EDT From: RpK%acorn@oak.lcs.mit.edu Is the ftype of + (function (&rest number) number) or (function (&rest list) number) ? I would assume the former (since &rest args are always of type list), but there aren't any examples in CLtL that make this clear. This seems a bit wierd, but I'd assume the latter, since (function (&rest (list-of number)) number) seems right. Unfortunately, common lisp's type language doens't allow parameterized types of this sort, so you can't really express this. Other programming languages allow this sort of type construction. You could do: (deftype list-of-number () `(satisfies list-of-number-p)) (defun list-of-number-p (x) (or (null x) (and (consp x) (numberp (car x)) (list-of-number-p (cdr x)))) Then, (proclaim '(ftype + (function (&rest list-of-number) number))) since we're using "satisfies" here, I don't see how this could be useful tho. ...mike beckerle Gold Hill  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 17 Aug 87 04:04:42 EDT Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 17 Aug 87 00:54:33 PDT Date: Mon 17 Aug 87 03:57:47-EDT From: GZ%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU Subject: FLET & declarations To: common-lisp@SAIL.STANFORD.EDU Message-ID: <12327146435.14.GZ@OZ.AI.MIT.EDU> Are 'pervasive' declarations in FLET supposed to apply to the function bodies? E.g. (flet ((foo () x)) ;Is this x special? (declare (special x)) ...) (flet ((foo () (foo) ...)) ;Does this call to (foo) return a fixnum? (declare (function foo () fixnum)) ...) (flet ((foo () (foo 17))) ;Is (foo 17) inline? (declare (inline foo)) ...) -------  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 10 Aug 87 15:31:53 EDT Received: from VAXA.ISI.EDU by SAIL.STANFORD.EDU with TCP; 10 Aug 87 12:16:03 PDT Posted-Date: Mon, 10 Aug 87 12:16:23 PDT Message-Id: <8708101916.AA00282@vaxa.isi.edu> Received: from LOCALHOST by vaxa.isi.edu (5.54/5.51) id AA00282; Mon, 10 Aug 87 12:16:28 PDT To: COMMON-LISP@sail.stanford.edu From: wile@vaxa.isi.edu Subject: Test suite available Date: Mon, 10 Aug 87 12:16:23 PDT Sender: wile@vaxa.isi.edu Folks-- A Common Lisp Validation Suite has been assembled here at ISI by Richard Berman. He essentially developed a test driver and has converted portions of the suites of some of the vendors to his format. The suite contains only a small fraction of the tests he has received, but it is a start for anyone responsible for quality assurance of CL implementations. Unfortunately for us, Richard resigned recently (to go off and become a recording star and/or AI in music guru), so there will be little additional support or development until a replacement for him is found. Although several of you are aware of the existence of this suite, we have been told that many interested parties were not; hence, this message. To access the suite, ftp to venera.isi.edu logging in as anonymous. Please respond with your name and affiliation as the password. The two directories of interest are: /usr/ftp/Valid-Code/*.* and /usr/ftp/Valid-Tests/*.*. (Capitalization is necessary.) The file README.NOW contains the information necessary to understand how to invoke the test suite and what files to transfer to your machine. Apparently around 400 tests are available now. We have no way to monitor the activity on the files, except with the ftp log of your anonymous password. We would very much appreciate hearing about any successes, problems, or suggestions (perhaps as to which remaining tests to convert first) you have. Send mail to WILE@VAXA.ISI.EDU for now. Testily yours, Dave Wile USC/ Information Sciences Institute (213) 822-1511  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 9 Aug 87 17:54:13 EDT Received: from THEORY.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 9 Aug 87 14:39:07 PDT Date: Sunday, 9 August 1987 17:40:16 EDT From: Timothy.Freeman@theory.cs.cmu.edu To: common-lisp@sail.stanford.edu Subject: Continuation Passing Style? Message-ID: <1987.8.9.21.29.37.Timothy.Freeman@theory.cs.cmu.edu> Does anyone have any code to transform some subset of Common Lisp into continuation passing style? How about some idea of what that subset would have to be? If you have a response, please mail it to me as well as the mailing list, because I no longer read this mailing list.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 8 Aug 87 17:00:42 EDT Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 8 Aug 87 13:46:53 PDT Received: ID ; Sat 8 Aug 87 16:46:33-EDT Date: Sat, 8 Aug 1987 16:46 EDT Message-ID: Sender: RAM@ From: Ram@C.CS.CMU.EDU To: sandra%orion@cs.utah.edu (Sandra J Loosemore) Cc: common-lisp@SAIL.STANFORD.EDU Subject: truename, merge-pathnames, etc. In-reply-to: Msg of 6 Aug 1987 16:11-EDT from sandra%orion at cs.utah.edu (Sandra J Loosemore) In CMU Common Lisp, we have hacked around these problems by playing with the rules for filename parsing. Although the result may be somewhat nonintuitive, it is legal common Lisp, since the namestring => pathname translation is not specified. Parse-Namestring contrives to translate pathnames so that Merge-Pathnames "works right". This is mostly done by by sticking special values in the pathname, and is probably similar to the notion of :Unspecified. For example, we get around to problem you mention by having: (pathname-device "foo:") => #() That is, a namestring that specifies only a device is translated so as to make explcit that a directory is being specified as well. The directory has no components, so NAMESTRING translates back to the original namestring, but merging of other directories in inhibited. We are currently running on a Unix filesystem. Since Unix has no notion of devices or logical names, we use the pathname device field for a "search list" mechanism that is implemented by Lisp. If we were on a filesystem where devices meant anything, then this hack probably wound't work so well. There are also some other cases in which merging is inhibited by the appropriate namestring translation: (pathname-device "/foo/") => :ABSOLUTE (pathname-device "foo/") => "Default" (pathname-type "foo.") => "" I agree that Common Lisp should address this, and think that a general solution would be appropriate, but it is possible in many cases to do the right thing within the constraints of the current MERGE-PATHNAMES definition by tweaking the namestring translation. Rob  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 8 Aug 87 12:11:33 EDT Received: from CS.UTAH.EDU by SAIL.STANFORD.EDU with TCP; 8 Aug 87 08:58:21 PDT Received: by cs.utah.edu (5.54/utah-1.0) id AA03714; Sat, 8 Aug 87 10:00:58 MDT Received: by orion.utah.edu (5.54/utah-1.0-slave) id AA21647; Sat, 8 Aug 87 10:00:54 MDT Date: Sat, 8 Aug 87 10:00:54 MDT From: sandra%orion@cs.utah.edu (Sandra J Loosemore) Message-Id: <8708081600.AA21647@orion.utah.edu> To: HELLER%cs.umass.edu@relay.cs.net Cc: common-lisp@sail.stanford.edu Subject: RE: truename, merge-pathnames, etc. News-Path: utah-cs!@SAIL.STANFORD.EDU,@RELAY.CS.NET:HELLER@cs.umass.edu References: <8708080541.AA18042@cs.utah.edu> Actually, I was having the problem with Lucid Lisp. VaxLisp does indeed handle logical names in a "reasonable" manner, but after rereading CLtL I've decided that its behavior is probably technically incorrect, and that Lucid's behavior is correct. That is, CLtL implies that PARSE-NAMESTRING and MERGE-PATHNAMES are only supposed to operate on pathname *syntax* without regard to the *semantics* attached to the various components by the underlying file system. Translation is mentioned only in the context of TRUENAME. Your idea with concatenating and using probe-file won't work either, first of all because it's nonportable (the whole reason for having the pathname functions in the first place is to avoid this kind of operation), and secondly because I may be trying to build the name of a file that doesn't exist yet. Also, this problem is not specific to VMS. You can get into the same problem under Un*x if your Lisp supports the use of environment variables or shell variables in filenames. -Sandra  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 8 Aug 87 01:28:51 EDT Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 7 Aug 87 22:15:09 PDT Received: from relay2.cs.net by RELAY.CS.NET id ad05638; 8 Aug 87 1:12 EDT Received: from cs.umass.edu by RELAY.CS.NET id ak07820; 8 Aug 87 1:04 EDT Date: Fri, 7 Aug 87 09:06 EDT From: Stride 440 User Subject: RE: truename, merge-pathnames, etc. To: Common-lisp@SAIL.STANFORD.EDU X-VMS-To: IN%"Common-lisp@SAIL.STANFORD.EDU" >From: IN%"Sandra J Loosemore " 7-AUG-1987 04:58 >Subj: truename, merge-pathnames, etc. > >I'm having a problem with incorrect expansion of pathnames under VMS, when >logical names are used. The problem happens when I, or the Lisp runtime, does >something like > > (merge-pathnames "LIBRARY:" *default-pathname-defaults*) > >My logical name "LIBRARY:" is likely to translate to a string that supplies >both a device and directory. However, the Lisp doesn't do the translation and >is instead pulling the directory from *default-pathname-defaults*, with the >end result that it builds up a pathname pointing to the wrong place. I can't >use TRUENAME to force translation of the logical name first, because it >complains about not being able to find a file that matches the incomplete >specification. And, I can't build up a complete file specification to give >to TRUENAME because of the other problem. Perhaps we need another function >like TRUENAME that just does the name translation without checking to see >that the file exists? > >-Sandra >------- > Hm... What version of VAX-LISP are you using? I just did some tests and it actually works ok for me: Lisp> (translate-logical-name "LLVS") ("LLVS$DISK:[LLVS]") Lisp> (merge-pathnames "LLVS:" *default-pathname-defaults*) #S(pathname :host "VAX9" :device "VIS3$DISK" :directory "LLVS" :name nil :type nil :version :newest) Lisp> *default-pathname-defaults* #S(pathname :host "VAX9" :device "VIS$DISK" :directory "HELLER.VISION.NEW_SYSTEM" :name nil :type nil :version nil) For completeness I also tried: Lisp> (merge-pathnames (pathname "LLVS:") *default-pathname-defaults*) #S(pathname :host "VAX9" :device "VIS3$DISK" :directory "LLVS" :name nil :type nil :version :newest) I think the last version is probably safest, since it forces the logical name to be processed into a proper pathname. There is still a problem with search lists (logical names with a list of values). For that you probably should not use merge-pathnames at all - instead use concatenate to create an un-parsed filename string and use probe-file to fetch the actual path. (Probe-file correctly handle search lists, since it calls RMS to search for the file (probably with a SYS$SEARCH call).) BTW: we are running VMS 4.5 and VAX-LISP U2.2 (yes we are a field test site). Robert Heller ARPANet: Heller@CS.UMass.EDU BITNET: Heller@UMass.BITNET BIX: Heller GEnie: RHeller FidoNet: 321/148 (Locks Hill BBS, Wendell, MA) CompuServe 71450,3432 Local PV VAXen: COINS::HELLER UCC Cyber/DG: Heller@CS  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 6 Aug 87 19:26:23 EDT Received: from SCRC-YUKON.ARPA by SAIL.STANFORD.EDU with TCP; 6 Aug 87 16:12:06 PDT Received: from WHITE-BIRD.SCRC.Symbolics.COM by YUKON.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 246352; Thu 6-Aug-87 19:07:56 EDT Date: Thu, 6 Aug 87 19:07 EDT From: Robert W. Kerns Subject: truename, merge-pathnames, etc. To: Sandra J Loosemore cc: common-lisp@sail.stanford.edu In-Reply-To: <8708062011.AA16097@orion.utah.edu> Message-ID: <870806190756.3.RWK@WHITE-BIRD.SCRC.Symbolics.COM> Date: Thu, 6 Aug 87 14:11:14 MDT From: sandra%orion@cs.utah.edu (Sandra J Loosemore) I'm having a problem with incorrect expansion of pathnames under VMS, when logical names are used. The problem happens when I, or the Lisp runtime, does something like (merge-pathnames "LIBRARY:" *default-pathname-defaults*) My logical name "LIBRARY:" is likely to translate to a string that supplies both a device and directory. However, the Lisp doesn't do the translation and is instead pulling the directory from *default-pathname-defaults*, with the end result that it builds up a pathname pointing to the wrong place. I can't use TRUENAME to force translation of the logical name first, because it complains about not being able to find a file that matches the incomplete specification. And, I can't build up a complete file specification to give to TRUENAME because of the other problem. Perhaps we need another function like TRUENAME that just does the name translation without checking to see that the file exists? -Sandra ------- This is what :UNSPECIFIC as a pathname component is good for. (Not that we implement it in this particular case, either). The people who borrowed the Symbolics pathname system for Common Lisp emasculated it without understanding it. The idea is that if a pathname *isn't supposed to have* certain components, then you use :UNSPECIFIC. If they're just not supplied yet, use NIL. Then MERGE-PATHNAMES can figure out the right thing to do for itself. Of course, this moves the burden onto the shoulders of PARSE-PATHNAME. For UNIX pathnames (distinguishing between "foo", and "foo.", and "foo" with no type specified yet), this is apparent from the syntax. Since the designers of VMS didn't choose to make their pathname syntax independent of run-time context (boo, hiss!), PARSE-PATHNAME has to be able to ask the operating system what logical pathname translations are in effect at the time. The pathname section of CLtL is full of gotcha's like this. It is in need of some serious cleanup.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 6 Aug 87 16:23:41 EDT Received: from CS.UTAH.EDU by SAIL.STANFORD.EDU with TCP; 6 Aug 87 13:08:44 PDT Received: by cs.utah.edu (5.54/utah-1.0) id AA29865; Thu, 6 Aug 87 14:11:17 MDT Received: by orion.utah.edu (5.54/utah-1.0-slave) id AA16097; Thu, 6 Aug 87 14:11:14 MDT Date: Thu, 6 Aug 87 14:11:14 MDT From: sandra%orion@cs.utah.edu (Sandra J Loosemore) Message-Id: <8708062011.AA16097@orion.utah.edu> Subject: truename, merge-pathnames, etc. To: common-lisp@sail.stanford.edu I'm having a problem with incorrect expansion of pathnames under VMS, when logical names are used. The problem happens when I, or the Lisp runtime, does something like (merge-pathnames "LIBRARY:" *default-pathname-defaults*) My logical name "LIBRARY:" is likely to translate to a string that supplies both a device and directory. However, the Lisp doesn't do the translation and is instead pulling the directory from *default-pathname-defaults*, with the end result that it builds up a pathname pointing to the wrong place. I can't use TRUENAME to force translation of the logical name first, because it complains about not being able to find a file that matches the incomplete specification. And, I can't build up a complete file specification to give to TRUENAME because of the other problem. Perhaps we need another function like TRUENAME that just does the name translation without checking to see that the file exists? -Sandra -------  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 6 Aug 87 11:23:45 EDT Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 6 Aug 87 08:09:24 PDT Return-Path: Received: from boethius by Think.COM via CHAOS; Thu, 6 Aug 87 11:08:41 EDT Date: Thu, 6 Aug 87 11:11 EDT From: Guy Steele Subject: New special form suggestion: LET-CONSTANT To: SOLEY@xx.lcs.mit.edu, barmar@Think.COM Cc: common-lisp@sail.stanford.edu, gls@Think.COM In-Reply-To: Message-Id: <870806111111.3.GLS@BOETHIUS.THINK.COM> Date: Thu, 6 Aug 1987 10:18 EDT From: SOLEY@xx.lcs.mit.edu Date: Monday, 3 August 1987 12:07-EDT From: Barry Margolin ... It seems like a LET-CONSTANT special form, or an &CONSTANT lambda-list keyword, would be the right thing for this. LET-CONSTANT would be to DEFPARAMETER what FLET is to DEFUN, and &CONSTANT would be analogous to &AUX. Yeah, and how about an &LOGOUT lambda-list keyword, to log out the current process? Really, although I understand the trivial difference in scope between LET and &AUX, do we need to continue adding random lambda-list keywords, which (worse yet) aren't keywords at all? Oh, wow! I don't mean to make fun of anyone, but you just gave me a great idea for eliminating LOOP by folding it into LAMBDA. (JONL, are you listening? That old idea resurfaces in new syntax.) (defun factorial (n &for j &from 1 &to n &for a &= 1 &then (* a j) &finally (return a))) A great feature of this is that it defuses the old quibble of whether or not LOOP "keywords" should be :-keywords by making them be &-keywords. We can get declarations in this way, too. (defun factorial (n &integer n &for j &from 1 &to n &for a &= 1 &then (* a j) &integer j a &finally (return a))) Also, let's do for English as for Lisp and replace documentation strings. What's sauce for the goose is sauce for the gander. (defun factorial (n &integer n &for j &from 1 &to n &for a &= 1 &then (* a j) &integer j a &finally (return a)) &documentation &factorial &takes &a &nonnegative &integer &n &and &returns &the &product &of &all &positive &integers ¬ &greater &than &n &.) &Maybe &I &could &get &to &like &this &language &after &all &. --Quux  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 6 Aug 87 10:35:15 EDT Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 6 Aug 87 07:21:42 PDT Date: Thu, 6 Aug 1987 10:18 EDT Message-ID: From: SOLEY@XX.LCS.MIT.EDU To: Barry Margolin Cc: common-lisp@SAIL.STANFORD.EDU Subject: New special form suggestion: LET-CONSTANT In-reply-to: Msg of 3 Aug 1987 12:07-EDT from Barry Margolin Date: Monday, 3 August 1987 12:07-EDT From: Barry Margolin Today I noticed myself creating DEFCONSTANTS for symbolic constants that would only be used by the one function I was writing. A declaration would be much cleaner; you could still write let-constant (or constantlet) in terms of it, as well as defconstant for that matter [(proclaim '(constant ...))]. It seems like a LET-CONSTANT special form, or an &CONSTANT lambda-list keyword, would be the right thing for this. LET-CONSTANT would be to DEFPARAMETER what FLET is to DEFUN, and &CONSTANT would be analogous to &AUX. Yeah, and how about an &LOGOUT lambda-list keyword, to log out the current process? Really, although I understand the trivial difference in scope between LET and &AUX, do we need to continue adding random lambda-list keywords, which (worse yet) aren't keywords at all? -- Richard  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 4 Aug 87 14:10:50 EDT Received: from [128.81.51.3] by SAIL.STANFORD.EDU with TCP; 4 Aug 87 10:57:23 PDT Received: from RAVEN.S4CC.Symbolics.COM by DIAMOND.S4CC.Symbolics.COM via CHAOS with CHAOS-MAIL id 110013; Mon 3-Aug-87 12:30:09 EDT Date: Mon, 3 Aug 87 12:29 EDT From: Scott Cyphers Subject: New special form suggestion: LET-CONSTANT To: barmar@Think.COM, common-lisp@sail.stanford.edu In-Reply-To: <870803120736.7.BARMAR@NIETZSCHE.THINK.COM> Message-ID: <870803122946.7.CYPHERS@RAVEN.S4CC.Symbolics.COM> Date: Mon, 3 Aug 87 12:07 EDT From: Barry Margolin Today I noticed myself creating DEFCONSTANTS for symbolic constants that would only be used by the one function I was writing. It struck me that they really wanted to be local to the function, not top-level variables, but I wanted to make sure that the compiler would open-code them, and I also wanted to declare their constantness to readers. There is currently no way to do this in Common Lisp (nor, as far as I know, in Symbolics Common Lisp, which I was using) without DEFCONSTANT, which also creates a useless special variable. It seems like a LET-CONSTANT special form, or an &CONSTANT lambda-list keyword, would be the right thing for this. LET-CONSTANT would be to DEFPARAMETER what FLET is to DEFUN, and &CONSTANT would be analogous to &AUX. I think a CONSTANT declaration would be better than a new special form. It would be the value cell equivalent of the INLINE declaration for functions. Actually, for consistency with the names FLET and MACROLET, I suppose this should be called CONSTANTLET (although to me that seems like the word for a little constant). However, I never liked those names anyway. barmar@think.com  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 4 Aug 87 02:31:03 EDT Received: from LABREA.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 3 Aug 87 23:17:51 PDT Received: by labrea.stanford.edu; Mon, 3 Aug 87 23:05:15 PDT Received: from bhopal.edsel.uucp by edsel.uucp (3.2/SMI-2.0) id AA12283; Mon, 3 Aug 87 23:00:28 PDT Received: by bhopal.edsel.uucp (3.2/SMI-3.2) id AA00205; Mon, 3 Aug 87 22:57:55 PDT Date: Mon, 3 Aug 87 22:57:55 PDT From: edsel!bhopal!jonl@labrea.stanford.edu (Jon L White) Message-Id: <8708040557.AA00205@bhopal.edsel.uucp> To: labrea!Moon%STONY-BROOK.SCRC.Symbolics.COM@labrea.stanford.edu Cc: bhopal!eb@labrea.stanford.edu, labrea!barmar%Think.COM@labrea.stanford.edu, labrea!common-lisp%sail@labrea.stanford.edu In-Reply-To: David A. Moon's message of Mon, 3 Aug 87 16:18 EDT <870803161813.4.MOON@EUPHRATES.SCRC.Symbolics.COM> Subject: LET-CONSTANT [or "Anonymous Constants"] A compiler can figure out that a local variable isn't being setq'd, and hence can propogate through the binding as a constant literal *providing* that it can determine that the form it is being bound to is a constant. Admittedly, that seems to be the thrust of the messages so far -- does common lisp need a local constant declaration for variables -- and I think the answer is, as you phrase it, "no, because any information that such a declaration provides can equally well be discerned mechanically by the compiler." But I see the need for a local constant declaration for random expressions apart from the issue of properties of program variables. "Anonymous Constants", if you will. Consider for example Interlisp's [special-form] function CONSTANT: (let ((x (constant `(JonL-phone-no ,(call-up-bell-tel-co))))) (check-phone-book x) (broadcast-to-friends x (constant (figger-out-broadcast-routing))) x) Without the very-local "declaration" provided by 'constant', the compiler would be obliged NOT to propogate the binding value of x, and not to elide the runtim calls to 'call-up-bell-tel-co', 'list', and the totally random 'figger-out-broadcast-routing'. [And also not to create the list in a static, or read-only area, etc.] Using 'constant' rather than #. is more of an issue in Interlisp style -- the "residential" style as opposed to the EMACS style -- but I don't think it should be ignored in CL. In fact, a later addition to Interlisp was 'loadtimeconstant', which is a functionality that has been under active discussion on this mailing list in recent weeks. -- JonL --  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 3 Aug 87 23:53:58 EDT Received: from LABREA.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 3 Aug 87 20:39:25 PDT Received: by labrea.stanford.edu; Mon, 3 Aug 87 20:26:34 PDT Received: from bhopal.edsel.uucp by edsel.uucp (3.2/SMI-2.0) id AA11997; Mon, 3 Aug 87 20:18:06 PDT Received: by bhopal.edsel.uucp (3.2/SMI-3.2) id AA17170; Mon, 3 Aug 87 20:15:34 PDT Date: Mon, 3 Aug 87 20:15:34 PDT From: edsel!bhopal!jonl@labrea.stanford.edu (Jon L White) Message-Id: <8708040315.AA17170@bhopal.edsel.uucp> To: labrea!snyder%hplabs@labrea.stanford.edu Cc: labrea!common-lisp%sail@labrea.stanford.edu In-Reply-To: Alan Snyder's message of Mon, 03 Aug 87 10:18:31 PDT <8708031718.AA03272@hplsny> Subject: compile-time processing of REQUIRE You've jumped ahead into another problem -- that of the pervasiveness of the COMPILE context. But I was talking merely about the compiler's interface -- when and where it decides to wrap an eval-when(eval compile load) around a form. When the user supplies his own wrapper, e.g. (eval-when (eval load) (require "tarnation")) then this form is not implicitly "wrapped", since the user's actions take precedence over the implicit activity. That is, Lucid's compiler does NOT convert the above form into anything like. (eval-when (eval load) (eval-when (eval compile load) (require "tarnation")) ) I wonder if this view of "implicit wrapping" is used in other compiler? -- JonL --  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 3 Aug 87 20:13:46 EDT Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 3 Aug 87 16:58:43 PDT Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 205940; Mon 3-Aug-87 19:59:39 EDT Date: Mon, 3 Aug 87 19:59 EDT From: David A. Moon Subject: Re: New special form suggestion: LET-CONSTANT To: common-lisp@sail.stanford.edu In-Reply-To: <8708031628.AA00890@HADES.MIT.EDU> Message-ID: <870803195934.6.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Mon, 03 Aug 87 12:28:38 EDT From: It seems like a LET-CONSTANT special form.... As an alternative, I recommend a CONSTANT declaration. The Cleanup subcommittee of X3J13 were discussing just that in May, incidental to another proposal for language cleanup. Perhaps such a declaration is a good idea. Presumably it would mean that the compiler is allowed to assume that the variable is never setq'ed and the variable's value is never side-effected (e.g. if an array, its elements are not changed and not side-effected themselves), and the compiler is encouraged to complain if it can prove that these assumptions are violated. Right now that cleanup proposal is in limbo but perhaps it will get more attention later.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 3 Aug 87 17:40:11 EDT Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 3 Aug 87 14:27:11 PDT Received: from nietzsche by Think.COM via CHAOS; Mon, 3 Aug 87 17:25:32 EDT Date: Mon, 3 Aug 87 17:26 EDT From: Barry Margolin Subject: New special form suggestion: LET-CONSTANT To: Eric Benson Cc: common-lisp@sail.stanford.edu In-Reply-To: <8708031905.AA11862@kent-state.edsel.uucp> Message-Id: <870803172620.2.BARMAR@NIETZSCHE.THINK.COM> Date: Mon, 3 Aug 87 12:05:52 PDT From: edsel!kent-state!eb@labrea.stanford.edu (Eric Benson) There's actually no need for a declaration or special form. LET will do fine all by itself. If the expression to which the variable is bound is constant and there are no SETQs to the variable, all references to the variable may be legitimately replaced by the constant expression. This is a very common optimization in Lisp compilers. However, as far as I know it is not done by the Symbolics compiler. I thought of that, and rejected it. I want to tell the compiler, interpreter, and other programmers reading the code that a particular name is a symbolic constant. If I accidentally assign to it, I want the system to produce an error message. In Lisp this isn't a problem as much as in my previous language, PL/I, because Lisp doesn't have call by reference; however, I still prefer to code what I mean. Someone else (DCP?) mentioned using MACROLET for this. I also considered this, and almost did it. It just seemed more esthetically unpleasing than the DEFCONSTANTs. Now, if Symbolics had SYMBOL-MACROLET to go with their DEFINE-SYMBOL-MACRO, I could use that (my code was a Zmail extension, so I had no reason not to use Symbolics-only features) (actually, I don't really care for symbol macros, because they allow a function call to masquerade as a variable reference, which is really confusing to the reader). barmar  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 3 Aug 87 17:07:22 EDT Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 3 Aug 87 13:52:39 PDT Date: Mon, 3 Aug 1987 16:52 EDT Message-ID: From: BROOKS%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU To: "David A. Moon" Cc: barmar@THINK.COM, common-lisp@SAIL.STANFORD.EDU, Eric Benson Subject: New special form suggestion: LET-CONSTANT In-reply-to: Msg of 3 Aug 1987 16:18-EDT from David A. Moon EB: If the expression to which the variable is bound is constant and there are no SETQs to the variable, all references to the variable may be legitimately replaced by the constant expression. MOON: It isn't an optimization in the Symbolics 3600, for most constants. The same is true in any other machine that keeps variables in registers and doesn't have an immediate addressing mode capable of accomodating all Lisp constants, I believe. Actually that's not quite true. On the 68k in Lucid lisp for instance compare 1. (let ((foo 'baz)) (setf (car x) foo)) and 2. (setf (car x) 'baz) The symbol baz can't be represented as an immediate addressing mode. Instead it is at some constant offset (inside any particular procedure) from a closure pointer which is in a known register. There is a memory to memory move on the 68k that can accomodate a source addressing mode that refers to baz, and a destination mode that refers to (car x), assuming x is already in a register. So case 2 takes one instruction, whereas case 1 under your description would take two--one to move baz into the register used for foo, and one to move that into (car x). Of course in this simple case a peephole optimizer should be able to clean case 1 up, but if there is other intervening stuff around it may not get it as easily as the source level transform. So on some machines the optimization is more generally useful than your note implies.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 3 Aug 87 16:53:36 EDT Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 3 Aug 87 13:39:57 PDT Received: ID ; Mon 3 Aug 87 16:39:50-EDT Date: Mon, 3 Aug 1987 16:39 EDT Message-ID: Sender: RAM@ From: Ram@C.CS.CMU.EDU To: common-lisp@SAIL.STANFORD.EDU Subject: LET-CONSTANT and DECLARE (CONSTANT Date: Monday, 3 August 1987 16:09-EDT From: AITG::VANROGGEN To: common-lisp Re: LET-CONSTANT and DECLARE (CONSTANT Related question: are quoted constants in compiled functions "read-only"? How about initial values for DEFCONSTANTs? Yes and yes. I believe that assuming that quoted constants are immutable is widely accepted. If the inital value to defconstant is quoted, that the constant value would also be immutable. In order to conclude that constants are constant in the general case of an arbitrary expression, I appeal to taste and common sense. Rob  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 3 Aug 87 16:32:08 EDT Received: from [128.81.41.223] by SAIL.STANFORD.EDU with TCP; 3 Aug 87 13:17:24 PDT Received: from EUPHRATES.SCRC.Symbolics.COM by SAPSUCKER.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 150921; Mon 3-Aug-87 16:18:16 EDT Date: Mon, 3 Aug 87 16:18 EDT From: David A. Moon Subject: New special form suggestion: LET-CONSTANT To: Eric Benson cc: barmar@Think.COM, common-lisp@sail.stanford.edu In-Reply-To: <8708031905.AA11862@kent-state.edsel.uucp> Message-ID: <870803161813.4.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Mon, 3 Aug 87 12:05:52 PDT From: edsel!kent-state!eb@labrea.stanford.edu (Eric Benson) There's actually no need for a declaration or special form. LET will do fine all by itself. If the expression to which the variable is bound is constant and there are no SETQs to the variable, all references to the variable may be legitimately replaced by the constant expression. This is a very common optimization in Lisp compilers. However, as far as I know it is not done by the Symbolics compiler. It isn't an optimization in the Symbolics 3600, for most constants. The same is true in any other machine that keeps variables in registers and doesn't have an immediate addressing mode capable of accomodating all Lisp constants, I believe. I'm not disagreeing that it is useful for compilers to make this optimization in the cases where it is in fact an optimization. I think your reasoning for why Common Lisp has DEFCONSTANT but no corresponding local form is correct: the local form isn't needed since the compiler has access to everything in the scope of a local variable and hence can infer the same information.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 3 Aug 87 16:30:26 EDT Received: from HUDSON.DEC.COM by SAIL.STANFORD.EDU with TCP; 3 Aug 87 13:15:20 PDT Date: 3 Aug 87 16:09:00 EDT From: "AITG::VANROGGEN" Subject: LET-CONSTANT and DECLARE (CONSTANT To: "common-lisp" cc: vanroggen Reply-To: "AITG::VANROGGEN" Perhaps the complaint about "binding constants" isn't about the constancy of association between a variable and its value, but about whether the value happens to be read-only. This would permit additional compiler optimizations regarding state dependent functions like ELT. Related question: are quoted constants in compiled functions "read-only"? How about initial values for DEFCONSTANTs? Is this what was intended by DECLARE (CONSTANT V)? ---Walter ------  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 3 Aug 87 15:24:17 EDT Received: from LABREA.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 3 Aug 87 12:11:45 PDT Received: by labrea.stanford.edu; Mon, 3 Aug 87 12:00:16 PDT Received: from kent-state.edsel.uucp by edsel.uucp (3.2/SMI-2.0) id AA10784; Mon, 3 Aug 87 12:08:32 PDT Received: by kent-state.edsel.uucp (3.2/SMI-3.2) id AA11862; Mon, 3 Aug 87 12:05:52 PDT Date: Mon, 3 Aug 87 12:05:52 PDT From: edsel!kent-state!eb@labrea.stanford.edu (Eric Benson) Message-Id: <8708031905.AA11862@kent-state.edsel.uucp> To: labrea!barmar%Think.COM@labrea.stanford.edu Cc: labrea!common-lisp%sail.stanford.edu@labrea.stanford.edu In-Reply-To: Barry Margolin's message of Mon, 3 Aug 87 12:07 EDT <870803120736.7.BARMAR@NIETZSCHE.THINK.COM> Subject: New special form suggestion: LET-CONSTANT There's actually no need for a declaration or special form. LET will do fine all by itself. If the expression to which the variable is bound is constant and there are no SETQs to the variable, all references to the variable may be legitimately replaced by the constant expression. This is a very common optimization in Lisp compilers. However, as far as I know it is not done by the Symbolics compiler.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 3 Aug 87 13:56:41 EDT Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 3 Aug 87 10:40:53 PDT Received: from LIVE-OAK.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 3 Aug 87 13:40-EDT Received: from ACORN.Gold-Hill.DialNet.Symbolics.COM by MIT-LIVE-OAK.DialNet.Symbolics.COM via DIAL with SMTP id 54193; 3 Aug 87 13:35:58-EDT Date: Mon, 3 Aug 87 12:39 EDT From: RpK%acorn@oak.lcs.mit.edu Subject: Question on function type spec and lambda-list keywords To: common-lisp@sail.stanford.edu Message-ID: <870803123923.1.RPK@ACORN.Gold-Hill.DialNet.Symbolics.COM> Is the ftype of + (function (&rest number) number) or (function (&rest list) number) ? I would assume the former (since &rest args are always of type list), but there aren't any examples in CLtL that make this clear.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 3 Aug 87 13:38:10 EDT Received: from HPLABS.HP.COM by SAIL.STANFORD.EDU with TCP; 3 Aug 87 10:21:12 PDT Received: from hplms2 by hplabs.HP.COM with TCP ; Mon, 3 Aug 87 10:19:13 pdt Received: from hplsny (hplsny) by hplms2; Mon, 3 Aug 87 10:18:53 pdt Return-Path: Received: from hplsny.hpl.hp.com by hplsny ; Mon, 3 Aug 87 10:18:35 pdt Message-Id: <8708031718.AA03272@hplsny> To: edsel!bhopal!jonl@labrea.stanford.edu (Jon L White) Cc: common-lisp@sail.stanford.edu Subject: Re: compile-time processing of REQUIRE Reply-To: snyder@hplabs In-Reply-To: Your message of Sat, 01 Aug 87 22:31:24 -0700. <8708020531.AA08106@bhopal.edsel.uucp> Date: Mon, 03 Aug 87 10:18:31 PDT From: Alan Snyder In addition to REQUIRE, Lucid has added UNINTERN to the set of forms implicitly wrapped in an eval-when(eval compile load). Note that there is nothing stopping the programmer from using his own wrappers, which will have precedence over the implicit one. I believe that the CLtL specification of EVAL-WHEN is inadequate to guarantee that the programmer can achieve this effect. In particular, following the "precise model" (p 70): (eval-when (load eval) (eval-when (compile load eval) (foo))) is no different than (eval-when (compile load eval) (foo)) There is no way to have a "negative" effect (such as "do NOT do this at compile time"). I hope the "clean up" committee is addressing this issue. Alan  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 3 Aug 87 13:34:06 EDT Received: from [128.81.51.3] by SAIL.STANFORD.EDU with TCP; 3 Aug 87 10:20:51 PDT Received: from KOYAANISQATSI.S4CC.Symbolics.COM by DIAMOND.S4CC.Symbolics.COM via CHAOS with CHAOS-MAIL id 110034; Mon 3-Aug-87 13:17:49 EDT Date: Mon, 3 Aug 87 13:17 EDT From: David C. Plummer Subject: New special form suggestion: LET-CONSTANT To: Barry Margolin , samalone@ATHENA.MIT.EDU cc: common-lisp@sail.stanford.edu In-Reply-To: <870803120736.7.BARMAR@NIETZSCHE.THINK.COM>, <8708031628.AA00890@HADES.MIT.EDU> Message-ID: <870803131722.1.DCP@KOYAANISQATSI.S4CC.Symbolics.COM> Yes, CONSTANTLET would be a better name. Proclamations don't solve Barry's concern: he doesn't want a "useless" variable which proclomations would require. As far as I can tell, PROCLAIM/DEFPARAMETER is just another syntax for DEFCONSTANT and doesn't solve anything. On the other hand, a (DECLARE (CONSTANT XYZ)) in the declarations part of a LET body (or of a DEFUN for &AUX) might be the way to go. You can get what you want today, kludgily, by using MACROLET and making the desired constants look like function calls. I'm glad some people prefer to err on the side of naming seldom-used constants than to wire in magic numbers into their code; numbers by themselves don't convey much information to the casual reader.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 3 Aug 87 12:43:05 EDT Received: from ATHENA.MIT.EDU by SAIL.STANFORD.EDU with TCP; 3 Aug 87 09:30:24 PDT Received: by ATHENA.MIT.EDU (5.45/4.7) id AA22194; Mon, 3 Aug 87 12:28:47 EDT From: Received: by HADES.MIT.EDU (5.45/4.7) id AA00890; Mon, 3 Aug 87 12:28:40 EDT Message-Id: <8708031628.AA00890@HADES.MIT.EDU> To: common-lisp@sail.stanford.edu Subject: Re: New special form suggestion: LET-CONSTANT In-Reply-To: Your message of Mon, 03 Aug 87 12:07:00 -0400. <870803120736.7.BARMAR@NIETZSCHE.THINK.COM> Date: Mon, 03 Aug 87 12:28:38 EDT It seems like a LET-CONSTANT special form, or an &CONSTANT lambda-list keyword, would be the right thing for this. LET-CONSTANT would be to DEFPARAMETER what FLET is to DEFUN, and &CONSTANT would be analogous to &AUX. As an alternative, I recommend a CONSTANT declaration. DEFCONSTANT could then be defined in terms of (PROCLAIM '(CONSTANT variable)). The statement (PROCLAIM '(DECLARATION CONSTANT)) would provide compatibility with implementations that don't support the declaration. --Stuart A. Malone  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 3 Aug 87 12:18:59 EDT Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 3 Aug 87 09:07:12 PDT Received: from nietzsche by Think.COM via CHAOS; Mon, 3 Aug 87 12:06:50 EDT Date: Mon, 3 Aug 87 12:07 EDT From: Barry Margolin Subject: New special form suggestion: LET-CONSTANT To: common-lisp@sail.stanford.edu Message-Id: <870803120736.7.BARMAR@NIETZSCHE.THINK.COM> Today I noticed myself creating DEFCONSTANTS for symbolic constants that would only be used by the one function I was writing. It struck me that they really wanted to be local to the function, not top-level variables, but I wanted to make sure that the compiler would open-code them, and I also wanted to declare their constantness to readers. There is currently no way to do this in Common Lisp (nor, as far as I know, in Symbolics Common Lisp, which I was using) without DEFCONSTANT, which also creates a useless special variable. It seems like a LET-CONSTANT special form, or an &CONSTANT lambda-list keyword, would be the right thing for this. LET-CONSTANT would be to DEFPARAMETER what FLET is to DEFUN, and &CONSTANT would be analogous to &AUX. Actually, for consistency with the names FLET and MACROLET, I suppose this should be called CONSTANTLET (although to me that seems like the word for a little constant). However, I never liked those names anyway. barmar@think.com  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 2 Aug 87 11:22:30 EDT Received: from LABREA.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 2 Aug 87 08:08:10 PDT Received: by labrea.stanford.edu; Sat, 1 Aug 87 22:32:50 PDT Received: from bhopal.edsel.uucp by edsel.uucp (3.2/SMI-2.0) id AA07051; Sat, 1 Aug 87 22:34:04 PDT Received: by bhopal.edsel.uucp (3.2/SMI-3.2) id AA08106; Sat, 1 Aug 87 22:31:24 PDT Date: Sat, 1 Aug 87 22:31:24 PDT From: edsel!bhopal!jonl@labrea.stanford.edu (Jon L White) Message-Id: <8708020531.AA08106@bhopal.edsel.uucp> To: labrea!sandra%orion%cs.utah.edu@labrea.stanford.edu Cc: labrea!common-lisp%sail@labrea.stanford.edu In-Reply-To: Sandra J Loosemore's message of Fri, 31 Jul 87 23:02:05 MDT <8708010502.AA05593@orion.utah.edu> Subject: compile-time processing of REQUIRE re: Am I correct that REQUIRE forms appearing at top level are not supposed to be evaluated at compile time? It is not in the list of magic functions on p. 182 of CLtL. However, both VaxLisp and Lucid . . . I have been under the impression that the compilation interface is one area where CLtL, as a specification, didn't succeed very well. Although no complete guarantee can be given to insure package layout consistency, it seems to me that the usage pattern of REQUIRE (but *not* PROVIDE) is such that it should be implicitly recognized by the compiler interface. For example, see Table 11-1 of CLtL, p189: ;;;; Lisp init file for I. Newton ;;; Set upthe USER pacakge the wayk I like it. (require 'calculus) ;I use CALCULUS a lot. Load it. (use-package 'calculus) ;Get easy access to its exported symbols . . . ;;; Import only what I need into the USER package. (require 'relativity) (import '(relativity:speed-of-light)...) Quite evidently, the CALCULUS package is created and set up by the calculus module; and parameters with names like RELATIVITY:SPEED-OF-LIGHT are defined in the RELATIVITY module (indeed, isn't this the intention of "modular" programming!). Thus this example, as a file, would not be compilable unless the REQUIRE statements are executed, in the order in which they appear, during the file compilation. In addition to REQUIRE, Lucid has added UNINTERN to the set of forms implicitly wrapped in an eval-when(eval compile load). Note that there is nothing stopping the programmer from using his own wrappers, which will have precedence over the implicit one. Incidentally, one other area where I personally violate the CLtL suggestions on package usage is in the placement of PROVIDE statements. Section 11.9 suggests placeing them first in a file, and the cutsy little mnemonic on page 191 -- PutInSevenExtremelyRandomUserInterfaceCommands -- also does that. But because loading a lisp file is a dynamic action with ocasionally loooooong duration, and because it is very easy to abort the loading right in the middle -- either interactively or through the error system -- then I place my PROVIDE's last, so that the *MODULES* list will not actually be updated until the whole module is fully present. One final point: I've used the word "statements" to refer to these functions. I hope you don't think that I'm just some kind of nerd who learned Lisp yesterday and doesn't know enough to refer to these sorts of things as "forms" or "s-expressions" or whatever. In fact the functionality provided by these "...ExtremelyRandomUserInterface..." commands is very much like that of a JobControlLanguage. That is why I refer to them as "statements". Allow me, if you will, to express one more very strong opinion: I definitely prefer to write my "statements" in Lisp syntax rather than in YAJCL*, or FORTRAN, or even the Emacs-inspired "File Attribute" syntax of the MIT Lisp machine descendents. [Lisp is "good enough"; it does the job.] -- JonL -- * = YetAnotherJobControlLanguage  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 1 Aug 87 13:41:54 EDT Received: from EMS.MEDIA.MIT.EDU by SAIL.STANFORD.EDU with TCP; 1 Aug 87 10:31:16 PDT Received: by EMS.MEDIA.MIT.EDU (5.54/4.8) id AA25229; Sat, 1 Aug 87 13:23:25 EDT Date: Sat, 1 Aug 87 13:23:25 EDT From: smh@EMS.MEDIA.MIT.EDU (Steven Haflich) Message-Id: <8708011723.AA25229@EMS.MEDIA.MIT.EDU> To: common-lisp@sail.stanford.edu, sandra%orion@cs.utah.edu Subject: Re: compile-time processing of REQUIRE The problem is only partly one of underspecification. Depending whether the required file contains only macros, both macros and execution-time functions, or just execution-time functions, typically you will want REQUIRE to happen at compile/eval, compile/load/eval, or load/eval times. Regardless when a naked REQUIRE does or doesn't happen, you can get explicit control by surrounding it with an EVAL-WHEN. This will protect somewhat from differences between implementations.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 1 Aug 87 01:11:17 EDT Received: from CS.UTAH.EDU by SAIL.STANFORD.EDU with TCP; 31 Jul 87 21:59:39 PDT Received: by cs.utah.edu (5.54/utah-1.0) id AA09047; Fri, 31 Jul 87 23:02:09 MDT Received: by orion.utah.edu (5.54/utah-1.0-slave) id AA05593; Fri, 31 Jul 87 23:02:05 MDT Date: Fri, 31 Jul 87 23:02:05 MDT From: sandra%orion@cs.utah.edu (Sandra J Loosemore) Message-Id: <8708010502.AA05593@orion.utah.edu> Subject: compile-time processing of REQUIRE To: common-lisp@sail.stanford.edu Am I correct that REQUIRE forms appearing at top level are not supposed to be evaluated at compile time? It is not in the list of magic functions on p. 182 of CLtL. However, both VaxLisp and Lucid attempt to process them at compile time. Has there been a proposal to make REQUIRE magical, that I haven't heard about? The reason why this behavior is causing a problem for me is that I have a number of modules which involve several files. I've found it convenient to put all of the external interface stuff (EXPORTs, etc.) in a separate file and have it REQUIRE the remaining files. When I compile this top-level file, sometimes these other files don't exist yet: I haven't compiled them yet, or I haven't copied the files to the place where REQUIRE wants to look for them, or whatever. If this is not the way REQUIRE was intended to be used, can somebody tell me how it *is* supposed to be used? -Sandra -------  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 31 Jul 87 18:10:16 EDT Received: from VAXA.ISI.EDU by SAIL.STANFORD.EDU with TCP; 31 Jul 87 14:55:48 PDT Posted-Date: Fri, 31 Jul 87 14:33:58 PDT Message-Id: <8707312134.AA13154@vaxa.isi.edu> Received: from loopback by vaxa.isi.edu (5.54/5.51) id AA13154; Fri, 31 Jul 87 14:34:02 PDT To: COMMON-LISP@sail.stanford.edu From: wile@vaxa.isi.edu Subject: Test Suite availability Date: Fri, 31 Jul 87 14:33:58 PDT Sender: wile@vaxa.isi.edu A Common Lisp Validation Suite has been assembled here at ISI by Richard Berman. He essentially developed a test driver and has converted portions of the suites of some of the vendors to his format. The suite contains only a small fraction of the tests he has received, but it is a start for anyone responsible for quality assurance of CL implementations. Unfortunately for us, Richard resigned recently (to go off and become a recording star and/or AI in music guru), so there will be little additional support or development until a replacement for him is found. Although several of you are aware of the existence of this suite, we have been told that many interested parties were not; hence, this message. To access the suite, ftp to venera.isi.edu logging in as anonymous. Please respond with your name and affiliation as the password. The two directories of interest are: /usr/ftp/Valid-Code/*.* and /usr/ftp/Valid-Tests/*.*. (Capitalization is necessary.) The file README.NOW contains the information necessary to understand how to invoke the test suite and what files to transfer to your machine. Apparently around 400 tests are available now. We have no way to monitor the activity on the files, except with the ftp log of your anonymous password. We would very much appreciate hearing about any successes, problems, or suggestions (perhaps as to which remaining tests to convert first) you have. Send mail to WILE@VAXA.ISI.EDU for now. There is a mailing list for the validation group--named CL-VALIDATION. You get onto it by mailing to RPG@SAIL.STANFORD.EDU.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 29 Jul 87 10:07:06 EDT Received: from EMS.MEDIA.MIT.EDU by SAIL.STANFORD.EDU with TCP; 29 Jul 87 06:48:03 PDT Received: by EMS.MEDIA.MIT.EDU (5.54/4.8) id AA08459; Wed, 29 Jul 87 09:39:29 EDT Date: Wed, 29 Jul 87 09:39:29 EDT From: smh@EMS.MEDIA.MIT.EDU (Steven Haflich) Message-Id: <8707291339.AA08459@EMS.MEDIA.MIT.EDU> To: MURRAY%cs.umass.edu@RELAY.CS.NET, common-lisp@SAIL.STANFORD.EDU Subject: Re: *eof-value* From: MURRAY%cs.umass.edu@RELAY.CS.NET I would like to suggest the addition of new constant, *eof-value*, that is the default value for EOF-VALUE in all the read functions. >From: IN%"Steven Haflich " 28-JUL-1987 01:59 >Although the proposed change is otherwise cogent, I >would opt against it since the benefit is only minor convenience and >not increased functionality. But at no real cost, since the constant is going to exist anyway. Perhaps I wasn't really clear. The important cost is that changing the current default value of eof-value from NIL to anything else may break existing code that depends on (READ stream NIL) returning NIL on eof. Even though CL might be a better language if the spec were changed in this regard, this rather minor improvement wouldn't justify making an incompatible change, particularly since the desired functionality can be achieved via (READ stream NIL *EOF-VALUE*). By the way, exporting a new symbol such as *EOF-VALUE* from the LISP package is an incompatible change, although often a more-easily detectible one. The problem is that code written under the old spec will suddenly find it's like-named internal symbol(s) "unified" with the symbol in the LISP package. If it were really a CONSTANT (why?) than presumably any user attempt to set or even DEFVAR it will signal an error. But even innocently adding a new exported function name can break code that happens to use that name either as a function or a special variable. It will certainly happen that X3J13 will propose add new functions and variables that must be exported from the LISP package. However, they will weigh the cost of each such change and only make changes for which there is a significant benefit that cannot otherwise easily be obtained using the existing language definition.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 29 Jul 87 03:54:38 EDT Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 29 Jul 87 00:39:21 PDT Received: from relay2.cs.net by RELAY.CS.NET id aa22549; 29 Jul 87 3:37 EDT Received: from cs.umass.edu by RELAY.CS.NET id bj03680; 29 Jul 87 3:29 EDT Date: Tue, 28 Jul 87 14:35 EDT From: MURRAY%cs.umass.edu@RELAY.CS.NET Subject: *eof-value* To: common-lisp@SAIL.STANFORD.EDU X-VMS-To: CLMAIL From: MURRAY%cs.umass.edu@RELAY.CS.NET I would like to suggest the addition of new constant, *eof-value*, that is the default value for EOF-VALUE in all the read functions. >From: IN%"Steven Haflich " 28-JUL-1987 01:59 >Although the proposed change is otherwise cogent, I >would opt against it since the benefit is only minor convenience and >not increased functionality. But at no real cost, since the constant is going to exist anyway. >From: Barry Margolin >While I admit that it is common, it is not foolproof, because someone >can type #.*eof-value*. The only really safe eof value is an object >consed on the fly, as in.. I hadn't considered this, but it just occured to me you found a neat way of commenting out the rest of a file! (Assuming the loader is checking for *eof-value*, and not NIL, or something consed on the fly, or si:*eof-value*, or etc.) (defun foo ..) #.*eof-value* (defun unused-foo ..) .. - Kelly Murray University of Massachusetts  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 28 Jul 87 04:04:08 EDT Received: from WOMBAT by SAIL.STANFORD.EDU with TCP; 28 Jul 87 00:49:55 PDT Date: 28 Jul 87 00:48:00 PST From: "Wade Hennessey" Subject: EOF value To: "common-lisp" Reply-To: "Wade Hennessey" The stream you are reading from is usually a perfectly good EOF value. Rod Brooks showed me this, and I have yet to encounter a situation where it did not suffice. Wade ------  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 27 Jul 87 20:21:09 EDT Received: from MULTIMAX.ARPA by SAIL.STANFORD.EDU with TCP; 27 Jul 87 17:06:19 PDT Received: by multimax.ARPA (4.12/25-eef) id AA02229; Mon, 27 Jul 87 20:00:55 edt Date: Mon, 27 Jul 87 20:00:55 edt From: Dan Pierson Message-Id: <8707280000.AA02229@multimax.ARPA> To: SCHMIDT@SUMEX-AIM.STANFORD.EDU Cc: common-lisp@SAIL.STANFORD.EDU Subject: Toplevel lexical variables Ah, but the original desire (as I understand it) was to have the LET be top-level rather than nested inside of a DEFUN. CLtL allows top-level forms to be nested inside PROGN but not LET. The use of top-level LETs is a common, and useful, Scheme idiom. I suspect that it was discovered by the Scheme folks first because they've had lexical scoping longer, but we really should support it in Common Lisp. Your definition B followed by: (eval-when (load eval) (b)) does the same job at the costs of: an extra function defintion and call, and considerably more opaque syntax. I don't believe that it's any easier to compile properly (i.e. ensure that the internal lambdas are optionally compiled). dan  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 27 Jul 87 18:02:38 EDT Received: from SUMEX-AIM.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 27 Jul 87 14:46:56 PDT Date: Mon, 27 Jul 87 14:46:58 PDT From: Christopher Schmidt Subject: Re: Toplevel lexical variables To: VERACSD%A.ISI.EDU@SUMEX-AIM.STANFORD.EDU cc: common-lisp@SAIL.STANFORD.EDU Message-ID: <12321792358.60.SCHMIDT@SUMEX-AIM.STANFORD.EDU> (DEFUN A () (DEFUN B () (LET ((X 1)) (LET ((X 1)) (DEFUN F () X) (SETF (SYMBOL-FUNCTION 'F) #'(LAMBDA () X)) (DEFUN G (Y) (SETQ X Y)))) (SETF (SYMBOL-FUNCTION 'G) #'(LAMBDA (Y) (SETQ X Y))))) I think definition B above would provide the behavior you desire and skirt the issue of compiling DEFUN as other than a top-level form; hence I believe it to be more portable. --Christopher P.S. My apologies to the list if this is so obvious that it doesn't bear stating. -------  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 27 Jul 87 17:38:06 EDT Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 27 Jul 87 14:23:07 PDT Received: from polycarp by Think.COM via CHAOS; Mon, 27 Jul 87 15:33:27 EDT Date: Mon, 27 Jul 87 15:26 EDT From: Guy Steele Subject: EOF-VALUE To: barmar@think.com, MURRAY%cs.umass.edu@relay.cs.net Cc: common-lisp@sail.stanford.edu In-Reply-To: <870727112913.6.BARMAR@NIETZSCHE.THINK.COM> Message-Id: <870727152620.7.GLS@POLYCARP.THINK.COM> Date: Mon, 27 Jul 87 11:29 EDT From: Barry Margolin Date: Sat, 25 Jul 87 19:53 EDT From: MURRAY%cs.umass.edu@relay.cs.net ... ... However, I wouldn't object strongly to adding *eof-value*, as anyone who types #.*eof-value* deserves what they get. That's true even if we don't spec or implement it. --Guy  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 27 Jul 87 13:08:22 EDT Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 27 Jul 87 09:49:03 PDT Received: from nietzsche by Think.COM via CHAOS; Mon, 27 Jul 87 11:51:35 EDT Date: Mon, 27 Jul 87 11:29 EDT From: Barry Margolin Subject: EOF-VALUE To: MURRAY%cs.umass.edu@relay.cs.net Cc: common-lisp@sail.stanford.edu In-Reply-To: <8707260551.AA27872@Think.COM> Message-Id: <870727112913.6.BARMAR@NIETZSCHE.THINK.COM> Date: Sat, 25 Jul 87 19:53 EDT From: MURRAY%cs.umass.edu@relay.cs.net [...] For this reason, In just about every file that calls read, I've got something like (Defconst *eof-value* (cons nil nil)), (maybe it's eof-value, or si:eof-value, or sys:**eof-value**, I can never remember), so I can supply and test for it as an EOF-VALUE. I would like to suggest the addition of new constant, *eof-value*, that is the default value for EOF-VALUE in all the read functions. Every system using something like this, why not make it standard? While I admit that it is common, it is not foolproof, because someone can type #.*eof-value*. The only really safe eof value is an object consed on the fly, as in (let ((eof-value (ncons '*eof-value*))) ;self-documenting structure ... (read *standard-input* nil eof-value) ...) The only way one could get at that value is by using a debugger or some other internal hack to look in the lexical environment, and they don't count. However, I wouldn't object strongly to adding *eof-value*, as anyone who types #.*eof-value* deserves what they get. barmar  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 26 Jul 87 19:36:49 EDT Received: from REAGAN.AI.MIT.EDU by SAIL.STANFORD.EDU with TCP; 26 Jul 87 16:23:36 PDT Received: from JONES.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 50335; Sun 26-Jul-87 19:23:37 EDT Date: Sun, 26 Jul 87 19:23 EDT From: Christopher Fry Subject: EOF-VALUE To: MURRAY%cs.umass.edu@RELAY.CS.NET, common-lisp@SAIL.STANFORD.EDU In-Reply-To: The message of 25 Jul 87 19:53 EDT from MURRAY%cs.umass.edu@RELAY.CS.NET Message-ID: <870726192338.4.CFRY@JONES.AI.MIT.EDU> What is the default value of EOF-VALUE for all the read functions? For example, READ takes (&Optional input-stream eof-error-p eof-value). If only INPUT-STREAM and EOF-ERROR-P are supplied, and EOF-ERROR-P is non-nil, CLtL says that the value of EOF-VALUE will be returned if an end-of-file is found. Without any further specification, I must assume that it defaults to NIL, which is the default default value for unsupplied &Optionals. For READ-CHAR, and READ-BYTE, NIL is an impossible value, but for READ and company, NIL is a perfectly reasonable return value. Thus, it makes no sense to supply a non-nil second argument, but not the third. In fact, the only safe value for EOF-VALUE in these cases is some non-atomic object that could never be EQ to something read in. For this reason, In just about every file that calls read, I've got something like (Defconst *eof-value* (cons nil nil)), (maybe it's eof-value, or si:eof-value, or sys:**eof-value**, I can never remember), so I can supply and test for it as an EOF-VALUE. I would like to suggest the addition of new constant, *eof-value*, that is the default value for EOF-VALUE in all the read functions. Every system using something like this, why not make it standard? - Kelly Murray I second this proposal. Make EOF processing easy!  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 26 Jul 87 17:49:08 EDT Received: from EMS.MEDIA.MIT.EDU by SAIL.STANFORD.EDU with TCP; 26 Jul 87 14:33:21 PDT Received: by EMS.MEDIA.MIT.EDU (5.54/4.8) id AA17837; Sun, 26 Jul 87 17:24:57 EDT Date: Sun, 26 Jul 87 17:24:57 EDT From: smh@EMS.MEDIA.MIT.EDU (Steven Haflich) Message-Id: <8707262124.AA17837@EMS.MEDIA.MIT.EDU> To: MURRAY%cs.umass.edu@RELAY.CS.NET, common-lisp@SAIL.STANFORD.EDU Subject: Re: EOF-VALUE From: MURRAY%cs.umass.edu@RELAY.CS.NET I would like to suggest the addition of new constant, *eof-value*, that is the default value for EOF-VALUE in all the read functions. This is not *quite* an upward compatible change. An existing application using READ could reasonably depend on NIL being synonymous to a real EOF. Although the proposed change is otherwise cogent, I would opt against it since the benefit is only minor convenience and not increased functionality.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 26 Jul 87 02:03:16 EDT Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 25 Jul 87 22:49:22 PDT Received: from relay2.cs.net by RELAY.CS.NET id ac21038; 26 Jul 87 1:49 EDT Received: from cs.umass.edu by RELAY.CS.NET id bt15822; 26 Jul 87 1:39 EDT Date: Sat, 25 Jul 87 19:53 EDT From: MURRAY%cs.umass.edu@RELAY.CS.NET Subject: EOF-VALUE To: common-lisp@SAIL.STANFORD.EDU X-VMS-To: CLMAIL What is the default value of EOF-VALUE for all the read functions? For example, READ takes (&Optional input-stream eof-error-p eof-value). If only INPUT-STREAM and EOF-ERROR-P are supplied, and EOF-ERROR-P is non-nil, CLtL says that the value of EOF-VALUE will be returned if an end-of-file is found. Without any further specification, I must assume that it defaults to NIL, which is the default default value for unsupplied &Optionals. For READ-CHAR, and READ-BYTE, NIL is an impossible value, but for READ and company, NIL is a perfectly reasonable return value. Thus, it makes no sense to supply a non-nil second argument, but not the third. In fact, the only safe value for EOF-VALUE in these cases is some non-atomic object that could never be EQ to something read in. For this reason, In just about every file that calls read, I've got something like (Defconst *eof-value* (cons nil nil)), (maybe it's eof-value, or si:eof-value, or sys:**eof-value**, I can never remember), so I can supply and test for it as an EOF-VALUE. I would like to suggest the addition of new constant, *eof-value*, that is the default value for EOF-VALUE in all the read functions. Every system using something like this, why not make it standard? - Kelly Murray  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 24 Jul 87 15:36:02 EDT Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 24 Jul 87 12:18:03 PDT Received: from nietzsche by Think.COM via CHAOS; Fri, 24 Jul 87 15:12:05 EDT Date: Fri, 24 Jul 87 15:12 EDT From: Barry Margolin Subject: Re: Correction To: Daniel L. Weinreb Cc: Gregor.pa@xerox.com, SWM@sapsucker.scrc.symbolics.com, VERACSD@a.isi.edu, common-lisp@sail.stanford.edu, veracsd.rs@a.isi.edu In-Reply-To: <870724133345.1.DLW@CHICOPEE.SCRC.Symbolics.COM> Message-Id: <870724151251.2.BARMAR@NIETZSCHE.THINK.COM> Date: Fri, 24 Jul 87 13:33 EDT From: Daniel L. Weinreb It seems to me that the use of lexical bindings around several methods is rather akin to the concept of "class variables". (Except that you control the scope by lexical containment in the let, rather than having the scope always me the set of all methods of a class.) To continue further from what Dan was saying, I believe that the response to this type of thing in the past has been to suggest that the class should be broken up into two classes. In Gregor's example, the LET would be replaced by a MARK-MIXIN, which would have the class variable MARK. barmar  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 24 Jul 87 14:00:50 EDT Received: from [128.81.41.109] by SAIL.STANFORD.EDU with TCP; 24 Jul 87 10:43:48 PDT Received: from CHICOPEE.SCRC.Symbolics.COM by ALDERAAN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 103619; Fri 24-Jul-87 13:34:38 EDT Date: Fri, 24 Jul 87 13:33 EDT From: Daniel L. Weinreb Subject: Re: Correction To: Gregor.pa@Xerox.COM, SWM@SAPSUCKER.SCRC.Symbolics.COM cc: VERACSD@A.ISI.EDU, common-lisp@SAIL.STANFORD.EDU, veracsd.rs@A.ISI.EDU In-Reply-To: <870724-093917-2611@Xerox> Message-ID: <870724133345.1.DLW@CHICOPEE.SCRC.Symbolics.COM> Line-fold: No It seems to me that the use of lexical bindings around several methods is rather akin to the concept of "class variables". (Except that you control the scope by lexical containment in the let, rather than having the scope always me the set of all methods of a class.)  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 24 Jul 87 13:37:49 EDT Received: from [128.81.41.223] by SAIL.STANFORD.EDU with TCP; 24 Jul 87 10:20:26 PDT Received: from EVENING-GROSBEAK.SCRC.Symbolics.COM by SAPSUCKER.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 148385; Fri 24-Jul-87 13:21:07 EDT Date: Fri, 24 Jul 87 13:20 EDT From: Scott McKay Subject: Re: Correction To: Gregor.pa@Xerox.COM, SWM@SAPSUCKER.SCRC.Symbolics.COM cc: VERACSD@A.ISI.EDU, common-lisp@SAIL.STANFORD.EDU, veracsd.rs@A.ISI.EDU In-Reply-To: <870724-093917-2611@Xerox> Message-ID: <870724132056.7.SWM@EVENING-GROSBEAK.SCRC.Symbolics.COM> Date: 24 Jul 87 09:38 PDT From: Gregor.pa@Xerox.COM From: Scott McKay Subject: Correction Date: 23 Jul 1987 20:38-EDT From: VERACSD@A.ISI.EDU (I might add that Symbolics does not allow lexical bindings around defmethods (not sure about TI); I hope they will consider it.) Isn't this what instance variables are for? In CLOS, methods get to choose what "slots" (CLOSpeak for "instance variable") they are allowed to access, so can get the "own variable" behavior you want that way. No, this kind of use of lexical variables is not at all the same as slots (instance variables). Slots are a piece of storage which is associated with an object (in the case of class variables it can be more than one object). Effectively that means that with respect to the body of the method slots are dynamic variables. Needless to say, lexical variables around a defmethod aren't dynamic variables. Here is what I think of as a prototypical example of methods using both a slot and a lexical variable. Thanks for unconfusing me. (defclass plist-mixin () ((plist :initform () :accessor plist))) (let ((mark (list "mark"))) (defmethod mark ((x plist-mixin)) (setf (getf (plist x) mark) t)) (defmethod markp ((x plist-mixin)) (getf (plist x) mark)) )  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 24 Jul 87 12:54:37 EDT Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 24 Jul 87 09:39:32 PDT Received: from Cabernet.ms by ArpaGateway.ms ; 24 JUL 87 09:39:17 PDT Date: 24 Jul 87 09:38 PDT From: Gregor.pa@Xerox.COM Subject: Re: Correction In-reply-to: Scott McKay 's message of Fri, 24 Jul 87 10:45 EDT To: SWM@SAPSUCKER.SCRC.Symbolics.COM cc: VERACSD@A.ISI.EDU, common-lisp@SAIL.STANFORD.EDU, veracsd.rs@A.ISI.EDU Message-ID: <870724-093917-2611@Xerox> From: Scott McKay Subject: Correction Date: 23 Jul 1987 20:38-EDT From: VERACSD@A.ISI.EDU (I might add that Symbolics does not allow lexical bindings around defmethods (not sure about TI); I hope they will consider it.) Isn't this what instance variables are for? In CLOS, methods get to choose what "slots" (CLOSpeak for "instance variable") they are allowed to access, so can get the "own variable" behavior you want that way. No, this kind of use of lexical variables is not at all the same as slots (instance variables). Slots are a piece of storage which is associated with an object (in the case of class variables it can be more than one object). Effectively that means that with respect to the body of the method slots are dynamic variables. Needless to say, lexical variables around a defmethod aren't dynamic variables. Here is what I think of as a prototypical example of methods using both a slot and a lexical variable. (defclass plist-mixin () ((plist :initform () :accessor plist))) (let ((mark (list "mark"))) (defmethod mark ((x plist-mixin)) (setf (getf (plist x) mark) t)) (defmethod markp ((x plist-mixin)) (getf (plist x) mark)) )  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 24 Jul 87 11:21:52 EDT Received: from [128.81.41.223] by SAIL.STANFORD.EDU with TCP; 24 Jul 87 08:05:53 PDT Received: from EVENING-GROSBEAK.SCRC.Symbolics.COM by SAPSUCKER.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 148310; Fri 24-Jul-87 10:45:29 EDT Date: Fri, 24 Jul 87 10:45 EDT From: Scott McKay Subject: Correction To: VERACSD@A.ISI.EDU, common-lisp@SAIL.STANFORD.EDU cc: veracsd.rs@A.ISI.EDU In-Reply-To: <[A.ISI.EDU]23-Jul-87 20:38:49.VERACSD> Message-ID: <870724104512.0.SWM@EVENING-GROSBEAK.SCRC.Symbolics.COM> Date: 23 Jul 1987 20:38-EDT From: VERACSD@A.ISI.EDU I have to apologize to Symbolics. Their release 7.1 (possibly also 7.0, but not 6.1) does allow toplevel lexical variables such as described in my posting earlier today. The user is asked whether this is really what he wants. I am informed that TI's upcoming release 3.0 will support this too. (What I said about the functions not being actually compiled remains true for 7.1; I'm not sure about 3.0.) So far, they remain uncompiled. (I might add that Symbolics does not allow lexical bindings around defmethods (not sure about TI); I hope they will consider it.) Isn't this what instance variables are for? In CLOS, methods get to choose what "slots" (CLOSpeak for "instance variable") they are allowed to access, so can get the "own variable" behavior you want that way. A little thought has also revealed to me that there is no way one can expect the compile function, called at runtime, to pick up lexical bindings. The other alternative, putting the let around the second argument to compile (as part of it) is clearly not supported by CLtL, although it would be nice if it were. Sorry for any inconvenience. Bob Sasseen  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 23 Jul 87 20:54:41 EDT Received: from A.ISI.EDU by SAIL.STANFORD.EDU with TCP; 23 Jul 87 17:38:57 PDT Date: 23 Jul 1987 20:38-EDT Sender: VERACSD@A.ISI.EDU Subject: Correction From: VERACSD@A.ISI.EDU To: common-lisp@SAIL.STANFORD.EDU Cc: veracsd.rs@A.ISI.EDU Message-ID: <[A.ISI.EDU]23-Jul-87 20:38:49.VERACSD> I have to apologize to Symbolics. Their release 7.1 (possibly also 7.0, but not 6.1) does allow toplevel lexical variables such as described in my posting earlier today. The user is asked whether this is really what he wants. I am informed that TI's upcoming release 3.0 will support this too. (What I said about the functions not being actually compiled remains true for 7.1; I'm not sure about 3.0.) (I might add that Symbolics does not allow lexical bindings around defmethods (not sure about TI); I hope they will consider it.) A little thought has also revealed to me that there is no way one can expect the compile function, called at runtime, to pick up lexical bindings. The other alternative, putting the let around the second argument to compile (as part of it) is clearly not supported by CLtL, although it would be nice if it were. Sorry for any inconvenience. Bob Sasseen  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 23 Jul 87 18:25:55 EDT Received: from MULTIMAX.ARPA by SAIL.STANFORD.EDU with TCP; 23 Jul 87 15:09:11 PDT Received: by multimax.ARPA (4.12/25-eef) id AA06883; Thu, 23 Jul 87 18:04:23 edt Date: Thu, 23 Jul 87 18:04:23 edt From: Dan Pierson Message-Id: <8707232204.AA06883@multimax.ARPA> To: common-lisp@SAIL.STANFORD.EDU Subject: Toplevel lexical variables If you expand the example to: (let ((x 1)) (defun f () x) (defun g (bar) ... (setq x ...) ...)) It becomes clear that this sort of structure is quite useful. X may be a private constant or a private "global" shared by the two top level functions F and G. The same sort of information hiding can be done with packages, but both the cost and code complexity will rise. This style is more common in Scheme than Common Lisp but it seems to me that Common Lisp implementations are required to support it. dan In real life: Dan Pierson, Encore Computer Corporation, Research Usenet: {talcott,linus,necis,decvax,ihnp4}!encore!pierson Arpanet: pierson@multimax.arpa  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 23 Jul 87 15:43:05 EDT Received: from A.ISI.EDU by SAIL.STANFORD.EDU with TCP; 23 Jul 87 12:22:50 PDT Date: 23 Jul 1987 15:19-EDT Sender: VERACSD@A.ISI.EDU Subject: Toplevel lexical variables From: VERACSD@A.ISI.EDU To: common-lisp@SAIL.STANFORD.EDU Cc: veracsd.rs@A.ISI.EDU Message-ID: <[A.ISI.EDU]23-Jul-87 15:19:07.VERACSD> (let ((x 1)) (defun f () x)) According to CLtL, it seems the above should work essentially the same at top level as it would within a function definition with (function (lambda ... )) in place of (defun ... ). The documentation for let (p. 111) says "each binding will be a lexical binding unless there is a special declaration to the contrary ... The bindings of the variables have lexical scope and indefinite extent". The documentation for defun (p. 67) says "Evaluating a defun form causes the symbol ... to be a global name for the function specified by the lambda-expression ... defined in the lexical environment in which the defun form was executed". However, neither Symbolics nor TI seems to allow this (I may not have checked the very latest releases). Why would anyone want to use this? Well, because it's there, because it's (to my taste) cleaner and more elegant than using a global special variable, and because it's good software engineering practice not to have things accessible from where they're not intended to be accessed. For a practical example, one might perhaps think of a login function using a (computed) list of passwords. The compile function (p. 438) presumably ought to work the same way (at least with the second argument supplied), although there isn't any specific textual justification. Symbolics and TI don't support this either. Finally, if I may add a comment not about Common Lisp per se, both Symbolics and TI fail to actually compile a defun within a let, but make it a named-lambda instead (in addition to not scoping it properly), when using c-sh-C from the editor, and probably do the same when compiling and loading a file. This is tolerated by Common Lisp (defun is one of the top-level forms of which CLtL says on p. 66 "Compilers, for example, may not recognize these forms properly in other than top-level contexts"), but I would think that sophisticated implementations should do the reasonable thing here. Bob Sasseen  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 22 Jul 87 10:30:35 EDT Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 22 Jul 87 07:14:57 PDT Received: from LIVE-OAK.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 22 Jul 87 09:48-EDT Received: from GOLD-HILL-ACORN.DialNet.Symbolics.COM by LIVE-OAK.LCS.MIT.EDU.ARPA via DIAL with SMTP id 52437; 22 Jul 87 10:00:27-EDT Date: Wed, 22 Jul 87 08:59 EDT From: EJS%acorn@oak.lcs.mit.edu Subject: Re: Atoms in association lists To: Cyphers@YUKON.SCRC.Symbolics.COM, sidney%acorn@oak.lcs.mit.edu, dml@NADC.ARPA cc: common-lisp@sail.stanford.edu In-Reply-To: <870709074958.7.CYPHERS@RAVEN.S4CC.Symbolics.COM> Message-ID: <870722085942.3.EJS@ACORN.Gold-Hill.DialNet.Symbolics.COM> Return-path: <@OAK.Gold-Hill.DialNet.Symbolics.COM,@LIVE-OAK.LCS.MIT.EDU.ARPA,@SAIL.STANFORD.EDU.ARPA,@SAIL.STANFORD.EDU,@DIAMOND.S4CC.Symbolics.COM:Cyphers@YUKON.SCRC.Symbolics.COM> Received: from LIVE-OAK.LCS.MIT.EDU.ARPA (MIT-LIVE-OAK.DialNet.Symbolics.COM) by GOLD-HILL-ACORN.DialNet.Symbolics.COM via DIAL with SMTP id 74916; 9 Jul 87 09:06:26-EDT Received: from SAIL.STANFORD.EDU (SAIL.STANFORD.EDU.ARPA) by LIVE-OAK.LCS.MIT.EDU.ARPA via INTERNET with SMTP id 50799; 9 Jul 87 08:06:44-EDT Received: from [128.81.51.3] by SAIL.STANFORD.EDU with TCP; 9 Jul 87 04:52:04 PDT Received: from RAVEN.S4CC.Symbolics.COM by DIAMOND.S4CC.Symbolics.COM via CHAOS with CHAOS-MAIL id 103750; Thu 9-Jul-87 07:50:39 EDT Date: Thu, 9 Jul 87 07:49 EDT From: Scott Cyphers Subject: Re: Atoms in association lists To: sidney%acorn@oak.lcs.mit.edu, dml@NADC.ARPA cc: common-lisp@sail.stanford.edu In-Reply-To: <870709062325.2.SIDNEY@ACORN.Gold-Hill.DialNet.Symbolics.COM> Message-ID: <870709074958.7.CYPHERS@RAVEN.S4CC.Symbolics.COM> Date: Thu, 9 Jul 87 06:23 EDT From: sidney%acorn@oak.lcs.mit.edu Actually, GCLisp handles atoms in alists by ignoring them, whether they are strings, NIL, or other symbols. E.g., (SETQ abc '(c (c . 3) NIL (NIL . 4))) (ASSOC 'c abc) --> (c . 3) (ASSOC nil abc) --> (NIL . 4) This is in accordance with CLtL, I believe. David Loewenstern -------- Since NIL is a list But NIL is not a cons. See page 281 of CLtL. as well as an atom and (car NIL) => NIL the correct result is (assoc NIL '((c . 3) NIL (NIL . 4))) => NIL (NIL . 4) should be returned, as someone stated earlier. The version of GCLisp I work with (2.4) evaluates it correctly. If an earlier version does return (NIL . 4) then it is a bug. (I didn't try it on any earlier versions.) -- sidney markowitz Gold Hill Computers No Sidney, I believe we are not in conformance with the spec since we fail the specific test case mentioned in CLtL. This is a long-reported bug for which the bug form sits on my desk this very instance. It is still a bug in 2.9.3 (beta release of 3.0).  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 21 Jul 87 00:44:14 EDT Received: from LABREA.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 20 Jul 87 21:30:39 PDT Received: by labrea.stanford.edu; Mon, 20 Jul 87 21:25:54 PDT Received: from bhopal.edsel.uucp by edsel.uucp (3.2/SMI-2.0) id AA05223; Fri, 17 Jul 87 11:45:06 PDT Received: by bhopal.edsel.uucp (3.2/SMI-3.2) id AA00220; Fri, 17 Jul 87 11:49:11 PDT Date: Fri, 17 Jul 87 11:49:11 PDT From: edsel!bhopal!jonl@labrea.stanford.edu (Jon L White) Message-Id: <8707171849.AA00220@bhopal.edsel.uucp> To: labrea!vrotney%venera.isi.edu@labrea.stanford.edu Cc: labrea!Common-Lisp%sail@labrea.stanford.edu, labrea!cl-cleanup%sail@labrea.stanford.edu In-Reply-To: vrotney@venera.isi.edu's message of Tue, 14 Jul 87 19:45:12 PDT <8707150245.AA03095@hpai00> Subject: Apropos case sensitive? [Note: LUCIDites are now using another mail gateway: typical address is: edsel!jonl@labrea.stanford.edu] Our reasoning here at Lucid was similar to what you came up with -- namely that the language of CLtL, p. 443, very strongly implied the same semantics of macthing as the default for SEARCH, which is an EQL, rather than an EQUALP, test. Many of us also felt the need so strongly for a case-insensitive apropos that Lucid Common Lisp actually has two such functions hidden inside it: lucid::case-insensitive-apropos lucid::case-insensitive-apropos-list but they will probably be "shaken" out in the delivered 2.1 beta images. I feel that this issue should be presented to the "cleanup" sub-committee of the X3J13 standards committee. Perhaps SEF can prod Steve Handerson into writing up a proposal to them? Lucid might feel impelled to "expose" this hidden function if the committe were inclined towards the proposal. By the way, there are some other issues about apropos that might need "cleaning up", some of which were discussed on this list a couple of years ago (for "couple" mabye equal to one). For example, the documentation uses the term "available symbols", but in at least one instance, it ought to use "accessible symbols", for conformity to chapter 11 on packages. Also, the scope of do-all-symbols has been questioned by some; there have been at least two proposals on it: (1) to add a new "function" called, say do-most-symbols, that excluded certain packages (2) to add a global variable (or a special variable) called, say, *all-symbols-exclusions* which is a list of packages which the several "all-symbols" functions would skip [e.g., do-all-symbols, find-all-symbols, apropos, case-insensitive-apropos, etc] -- JonL --  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 20 Jul 87 14:50:16 EDT Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 20 Jul 87 11:32:10 PDT Received: from Semillon.ms by ArpaGateway.ms ; 20 JUL 87 11:30:55 PDT Date: Mon, 20 Jul 87 11:30:41 PDT From: Ken Kahn Subject: Re: Prolog In-Reply-To: <8707161309.AA01050@caen.engin.umich.edu> To: kanya@caen.engin.umich.edu (Kanya Likanasudh) cc: common-LISP@sail.stanford.edu Message-ID: <870720-113055-1588@Xerox> I've written one called CommonLog. Unfortunately Xerox hasn't decided yet what to do with it. Do you know about ZYX Prolog for HP? What other responses did you get to your message? References kanya@caen.engin.umich.edu's message of Thu, 16 Jul 87 9:09:39 EDT -- Prolog  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 17 Jul 87 13:41:44 EDT Received: from LABREA.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 17 Jul 87 10:25:56 PDT Received: by labrea.stanford.edu; Fri, 17 Jul 87 10:23:15 PDT Received: from bhopal.edsel.uucp by edsel.uucp (3.2/SMI-2.0) id AA03837; Thu, 16 Jul 87 18:32:33 PDT Received: by bhopal.edsel.uucp (3.2/SMI-3.2) id AA07740; Thu, 16 Jul 87 18:36:30 PDT Date: Thu, 16 Jul 87 18:36:30 PDT From: edsel!bhopal!jonl@labrea.stanford.edu (Jon L White) Message-Id: <8707170136.AA07740@bhopal.edsel.uucp> To: labrea!kempf.hplabsz%hplabs.HP.COM@labrea.stanford.edu, labrea!KMP%SCRC.Symbolics.COM@labrea.stanford.edu Cc: labrea!Common-Lisp%SAIL@labrea.stanford.edu In-Reply-To: Jim Kempf's message of Tue, 14 Jul 87 08:14:52 pdt <8707141514.AA25943@hplabsz.hpl.hp.com> Subject: Appropriate use of the Common-Lisp mailing list [Apologies again for replying several days late -- Lucid's link, at Stanford, to the Internet seems to have been wedged since last Friday.] Many other forums have seen fit to divide into two mailing lists -- one for imlementational questions and another for general "information". A paradigm might be the BUG- and INFO- lists that sprang up around MIT years ago (but maybe they weren't so successful? I dunno). On the other hand, I don't find the (unnanounced and informal) change in purpose of the Common-Lisp@SU-AI mailing list to be so bad; my reasons for tolerating it are: (1) It generates *** substantially less volume ** in my mail file than it did one year ago, when every apostle from the MIT-AI lab (myself included) who imagined he was designing the world's greatest language felt it necessary to publicly argue every little issue that came up. (2) Users, who are not implementors, frequently have a different point of view as to what the important issues are, and they often read standardized documentation in a way different from "wizards"; I want to remain informed as to what they are thinking. -- JonL --  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 16 Jul 87 19:44:09 EDT Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 16 Jul 87 16:29:59 PDT Received: ID ; Thu 16 Jul 87 19:28:53-EDT Date: Thu, 16 Jul 1987 19:28 EDT Message-ID: Sender: RAM@ From: Ram@C.CS.CMU.EDU To: Timothy Daly Cc: common-lisp@SAIL.STANFORD.EDU Subject: eval-when issues In-reply-to: Msg of 16 Jul 1987 10:12:53 EDT from Timothy Daly Date: 16 July 1987, 10:12:53 EDT From: Timothy Daly Re: pathnames, portability, ed, eval-when, compile-file, fasl files [...] Second question: Is there any *portable* way I can tell whether a macro is being expanded in the compile time environment or the top level command environment? Probably the answer is no. A macro can do different things in these circumstances using EVAL-WHEN, of course. Moving on out over thin ice, I would argue that a program that needs this information is broken, is in error, is not Common Lisp. The problem is that concepts such as "at compile time" are very hard to pin down given the wide range of legal Common Lisp implementation strategies such as "compile only", "interpret only", and all kinds of hybrid/incremental compilation schemes. That is, I need to set up certain compile time information for macros. These macros perform two functions. They generate forms for the compiler to compile into the file and they set up top level environment information. If they are expanded from compile-file in the compile-time environment, they modify the global state. If they are expanded at the top level they create and return forms that modify the global state redundantly. Truly tedious programming gets around this problem but one of two possible modifications to common lisp would solve *my* problem. It's hard to tell what you are trying to do, but sounds like you are writing your macros wrong. Macroexpansion should never have side-effects. You should get your "compile time" side-effects by using EVAL-WHEN. If you put the stuff in an EVAL-WHEN (COMPILE LOAD EVAL), then it will happen both at compile and load time, but only once when interpreted at top-level. First, export the state used by EVAL-WHEN so I can use it (eval-when does not seem to be available except at the top level, thus I have to hack a compiler:phase-1-hook property which is beyond my cutoff point for hacking this week). EVAL-WHEN (or equivalent) should work anywhere. The concept of "top-level form" doesn't belong in Common Lisp. This is currently an area of major lossage in the spec. I have a compiler cleanup proposal that replaces eval-when and banishes top-level forms. This proposal is supposedly being considered by the compiler cleanup committee. The second modification would be to allow me to write into a fasl file without using compile-file. That is, (compile 'foo :output-file pathname :if-exists :append) Gag my with a spoon! Hunh-uh... No way! fat chance, over my bloated corpse. Rob  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 16 Jul 87 19:23:18 EDT Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 16 Jul 87 16:09:04 PDT Received: ID ; Thu 16 Jul 87 19:07:58-EDT Date: Thu, 16 Jul 1987 19:07 EDT Message-ID: Sender: RAM@ From: Ram@C.CS.CMU.EDU To: Timothy Daly Cc: common-lisp@SAIL.STANFORD.EDU Subject: editor issues In-reply-to: Msg of 16 Jul 1987 10:12:53 EDT from Timothy Daly Date: 16 July 1987, 10:12:53 EDT From: Timothy Daly Re: pathnames, portability, ed, eval-when, compile-file, fasl files Is there any *portable* way to get the pathname of the file that is currently being compiled or loaded? No. I would like to be able to edit the file when an error occurs (similar to turbo pascal). That is, if someone types: (compile-file ">daly>foo.lisp") and my parser detects an error, I'd like to (ed ">daly>foo.lisp") I think you are trying to do too much that is properly part of the "programming environment", and inherently not portable (at least with the current Common Lisp design goals). A more portable alternative would be to have a SYNTAX-ERROR condition and an EDIT proceed function, or something like that. This would provide a portable interface to "editing errors", if that capability exists. [...] but there doesn't appear to be a get-current-pathname function defined anywhere. Does common lisp plan to add such a function when the 'debugging facilities' get expanded? Well, this was mentioned before, but I believe it was by you. Unless someone comes up with a formal proposal that convincingly argues that this is well-defined and useful, then it won't be adopted. Although you may think the semantics are obvious, it may be difficult to clearly define. Consider that code may be consed up and compiled without ever having been in a file, and that code can be read from places other than files. Actually, I'd like to be able to incant (progn (ed ">daly>foo.lisp") (ed-search arbitrary-text-string)) I think that anything of this sort is doomed in the absence of a standard editor/environment. As a practical matter this isn't very important either. Given that the editor exists and provides the functionality you want (which Common Lisp doesn't guarantee), you can have a trivial (but non-portable) code file that implements what you expect in terms of what is available. And, dreaming on, I'd like a definition of (ed-command arbitrary-but-implementation-dependent-editor-command) that is, I'd like the interface syntax to the editor command handler to be defined in a portable manner. [...] I could create editor scripts and assign them to implementation dependent variables. This is just silly. Your code isn't any more portable just because the first symbol in each form is the same. Since Lisp supports arbitrary functional values, you can stick "editor scripts" in variables just as easily as arbitrary code. Rob  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 16 Jul 87 14:38:19 EDT Received: from IBM.COM by SAIL.STANFORD.EDU with TCP; 16 Jul 87 11:23:20 PDT Date: 16 July 1987, 10:12:53 EDT From: Timothy Daly To: common-lisp@sail.stanford.edu Message-Id: <071687.101253.daly@ibm.com> Subject: pathnames, portability, ed, eval-when, compile-file, fasl files First question: Is there any *portable* way to get the pathname of the file that is currently being compiled or loaded? I would like to be able to edit the file when an error occurs (similar to turbo pascal). That is, if someone types: (compile-file ">daly>foo.lisp") and my parser detects an error, I'd like to (ed ">daly>foo.lisp") but there doesn't appear to be a get-current-pathname function defined anywhere. Does common lisp plan to add such a function when the 'debugging facilities' get expanded? Actually, I'd like to be able to incant (progn (ed ">daly>foo.lisp") (ed-search arbitrary-text-string)) which would leave the user in the editor and positioned at the error. It appears that this could be defined in a portable manner as every editor has a text search command. And, dreaming on, I'd like a definition of (ed-command arbitrary-but-implementation-dependent-editor-command) that is, I'd like the interface syntax to the editor command handler to be defined in a portable manner. I understand that the actual commands to perform the manipulations would be different across systems but I could create editor scripts and assign them to implementation dependent variables. Second question: Is there any *portable* way I can tell whether a macro is being expanded in the compile time environment or the top level command environment? That is, I need to set up certain compile time information for macros. These macros perform two functions. They generate forms for the compiler to compile into the file and they set up top level environment information. If they are expanded from compile-file in the compile-time environment, they modify the global state. If they are expanded at the top level they create and return forms that modify the global state redundantly. Truly tedious programming gets around this problem but one of two possible modifications to common lisp would solve *my* problem. First, export the state used by EVAL-WHEN so I can use it (eval-when does not seem to be available except at the top level, thus I have to hack a compiler:phase-1-hook property which is beyond my cutoff point for hacking this week). If I could get at the state I could conditionalize my code without using eval-when special forms. The second modification would be to allow me to write into a fasl file without using compile-file. That is, (compile 'foo :output-file pathname :if-exists :append) If I could write compiled objects I could create my own fasl file definition and write something portable that would get around the previous hacks. tim. DALY@IBM.COM T. J. Watson Research Center If I had ham, I could have ham and eggs, if I had eggs. Sigh.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 16 Jul 87 09:36:06 EDT Received: from CAEN.ENGIN.UMICH.EDU by SAIL.STANFORD.EDU with TCP; 16 Jul 87 06:24:49 PDT Received: by caen.engin.umich.edu (5.31/umix-2.0) id AA01050; Thu, 16 Jul 87 09:09:39 EDT Date: Thu, 16 Jul 87 09:09:39 EDT From: kanya@caen.engin.umich.edu (Kanya Likanasudh) Message-Id: <8707161309.AA01050@caen.engin.umich.edu> To: common-LISP@sail.stanford.edu Subject: Prolog Does anyone know of a Prolog interpreter written in Common Lisp? Any information about it would be appreciated. My network address is: kanya@caen.engin.umich.edu Thank you. -Kanya  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 16 Jul 87 02:32:31 EDT Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 15 Jul 87 23:12:53 PDT Received: from relay2.cs.net by RELAY.CS.NET id aa23577; 16 Jul 87 2:07 EDT Received: from cs.umass.edu by RELAY.CS.NET id ad02188; 16 Jul 87 1:57 EDT Date: Wed, 15 Jul 87 08:51 EDT From: Stride 440 User Subject: RE: Apropos case sensitive? To: Common-LISP@SAIL.STANFORD.EDU X-VMS-To: IN%"Common-LISP@sail.stanford.edu" I too think Lucid's case-sensitive apropos is wrong. After all, APROPOS is searching SYMBOL print-names for substring matches. In Common LISP, symbol print-names get converted to uppercase (unless enclosed with vertical bars or backslashed or "manually" created with intern). Thus (unless you make heavy use either vertical bars or backslashes), most of the print-names of the symbols typed in (or loaded from files) by users will have all uppercase names. Since most people using Common LISP are probably not using caps only terminals (such as the Teletype Model 33) or have the Caps-Lock key down, they will be entering expressions (either in files or interactively) using mostly lowercase letters. While it is posible to allways pass a SYMBOL to apropos, this has the side affect of actually creating a symbol which will match the symbol(s) sought (the one passed as the argument to apropos). This is probably tolerable (although posibly confusing to novices) for interactive queries. It can cause problems with functions using apropos-list (functions which do something to all symbols which have some special character sequence in them). The apropos function on both of the other Common LISPs I have used (DEC VAX/VMS VAX-LISP and TI Explorer LISP) is case-insensitive. In fact when I had need to mess with Lucid LISP on a loaner SUN, I put the case-insensitive version of apropos into the function slot of apropos in my init file (and later into the saved system). Also, there is in Common LISP a case-insensitve string compare function: EQUALP. (EQUALP "FOO" "foo") => T (last example, page 82 of CLtL). Robert Heller ARPANet: Heller@CS.UMass.EDU BITNET: Heller@UMass.BITNET BIX: Heller GEnie: RHeller FidoNet: 321/148 (Locks Hill BBS, Wendell, MA) CompuServe 71450,3432 Local PV VAXen: COINS::HELLER UCC Cyber/DG: Heller@CS