Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 4 Oct 84 23:47:13 PDT Received: ID ; Fri 5 Oct 84 02:46:06-EDT Date: Fri, 5 Oct 1984 02:46 EDT Message-ID: From: Rob MacLachlan To: "David A. Moon" Cc: common-lisp@SU-AI.ARPA, "Robert (LISPer 68K)Heller" Subject: Questions about OPEN In-reply-to: Msg of 5 Oct 1984 01:12-EDT from David A. Moon I concede those points, and was aware that, for example, Rename-File has somewhat different semantics on a stream than it has on the name. I can deal with that, since all we have to do in Spice Lisp to implement this is change the name we write the data out as when we close the file. You clarification, however, seems to assume that there is some concept of file identity independent of the file name. This is not true in Sesame, and is probably not true in many file systems. There is no way to keep track of a file across renamings and other operations. I guess we have several options here: 1] We can leave the manual the way it is, with the semantics of use of streams vis a vis pathnames largely unspecified. This would permit implementations to do arbitrarily whizzy things, but would make the use of stream arguments difficult in portable code, and thus dubious as a Common Lisp feature. 2] We can try to define the semantics. This course is fraught with peril, since capabilities of operating systems differ wildly. 3] We can punt and remove them. In many cases, the CLM seems to do 1, on the grounds that it would be nice to have a standard way to say X, given that X is possible. I have mixed feelings about this. In the case of the :If-Exists/:If-Does-Not-Exist arguments to Open, it seems reasonable, since even an inconceivably brain-damaged OS should be able to provide some sort of reasonable default action, and the program will still work. In the case of Rename-File, though, the call will error out, (or worse, simply quietly fail) if the capability to rename open files doesn't exist. A program counting on this feature would not work, and thus would not be portable. I think that this business of streams-as-files is especially problematical in our implementation, since there is no "file attached to the stream", only a memory buffer area where you are building up a file that you may write out when the stream is closed. Sesame is in fact a system such as you mentioned, in which it is impossible to determine the truename of an "open" file, since the version number is determined when the file is written. It seems to me that this argument could just as easily be used to support the position that the feature should be flushed as being impossible to specify in a implementation independent fashion. For us, the Probe-File and Truename functions are the most annoying. The Rename-File and Delete-File functions, which don't have to work right according to the CLM, are easily implementable. Currently, our implementation does not obey the (probe-file (open ...)) => t invariant. We could dummy it up so that it would return the pathname that it thinks it is going to write the file out to, but that would cause anomalous behavior such as: (probe-file stream) => (probe-file ) => nil Rob  Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 4 Oct 84 22:11:42 PDT Received: from SCRC-EUPHRATES by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 104028; Fri 5-Oct-84 01:11:53-EDT Date: Fri, 5 Oct 84 01:12 EDT From: "David A. Moon" Subject: Questions about OPEN To: Rob MacLachlan cc: common-lisp@SU-AI.ARPA, "Robert (LISPer 68K)Heller" In-Reply-To: Message-ID: <841005011201.3.MOON@EUPHRATES.SCRC.Symbolics> Date: Thu, 4 Oct 1984 22:33 EDT From: Rob MacLachlan Well, if it's constructive to flame about the file system interface at this point, then I will add that I agree the :direction :probe is silly. I also believe that requiring all of the file/pathname functions to accept streams as arguments is silly. It seems to me that this symbol/namestring/stream/pathname foolishness is a result of the confusion between streams and pathnames and strings and symbols that is present in earlier lisps because they lack some of the above. Not exactly. Many of these functions, when applied to a stream, do something slightly different than when applied to a pathname. Specifically, they operate on the exact file to which the stream is attached, which may not be the same file as the one you would get if you used the name by which the stream was opened (someone may have renamed something in the meantime, a new version of the file may have been created in the meantime, or the file to which the stream is attached may not be accessible any other way [in some file systems] because it is a newly-created output file, for example). This is an example of message-passing / generic-functions / object-oriented programming sneaking into Common Lisp in the guise of ordinary functions. I don't think that's bad. Historically I/O -is- where it tends to strike first. I think that it is totally silly to suggest that these operations work on closed streams, since a closed stream can have no semantics other than possibly its name, which could be better represented by a pathname. Ours have slightly more semantics than that; they have a property list of certain properties of the file that they used to be connected to when they were open. The main reason for this is what I mentioned before about some file systems not knowing the truename (among other properties) of an output file until it is closed. If we really want to do this sort of thing, then we should define a File-Stream-Name function that returns the pathname associated with a file stream so that people can get the name from a stream. Isn't that what the pathname and truename functions do, when applied to a stream? (There are two possible pathnames you could want from a stream, the one it was opened with and the one it is actually connected to). My opinon may be slightly biased by the lack of any concept of an open file in the Sesame filesystem that underlies Spice Lisp. One example of the enormous diversity of file systems that we are trying to squeeze into a single model so we can write portable programs. I do think that :direction :probe should be flushed, on the grounds that it is exposing an implementation-dependent mechanism and that the portable aspects of it are already available through probe-file. I also think that not all of Symbolics' experience in dealing with incompatible file systems in a generic way was distilled into the writeup in the Common Lisp manual, and a future second edition should incorporate more of that as well as other people's experiences, to make user's file-processing programs more likely to be truly portable.  Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 4 Oct 84 20:33:07 PDT Received: ID ; Thu 4 Oct 84 23:27:32-EDT Date: Thu, 4 Oct 1984 23:27 EDT Message-ID: Sender: FAHLMAN@CMU-CS-C.ARPA From: "Scott E. Fahlman" To: Rob MacLachlan Cc: common-lisp@SU-AI.ARPA Subject: Questions about OPEN In-reply-to: Msg of 4 Oct 1984 22:33-EDT from Rob MacLachlan I agree with both Moon's and Maclachlan's comments on the stream stuff. This seems to be one area in which we never got things untangled properly. Does anyone see a problem with the changes Rob proposes? If not, we should cast these into a formal proposal and have a vote -- I guess that's how we make changes official these days. -- Scott  Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 4 Oct 84 19:34:12 PDT Received: ID ; Thu 4 Oct 84 22:33:23-EDT Date: Thu, 4 Oct 1984 22:33 EDT Message-ID: From: Rob MacLachlan To: "David A. Moon" Cc: common-lisp@SU-AI.ARPA, "Robert (LISPer 68K)Heller" Subject: Questions about OPEN In-reply-to: Msg of 4 Oct 1984 21:28-EDT from David A. Moon Well, if it's constructive to flame about the file system interface at this point, then I will add that I agree the :direction :probe is silly. I also believe that requiring all of the file/pathname functions to accept streams as arguments is silly. It seems to me that this symbol/namestring/stream/pathname foolishness is a result of the confusion between streams and pathnames and strings and symbols that is present in earlier lisps because they lack some of the above. I think that it is totally silly to suggest that these operations work on closed streams, since a closed stream can have no semantics other than possibly its name, which could be better represented by a pathname. If we really want to do this sort of thing, then we should define a File-Stream-Name function that returns the pathname associated with a file stream so that people can get the name from a stream. My opinon may be slightly biased by the lack of any concept of an open file in the Sesame filesystem that underlies Spice Lisp. Rob  Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 4 Oct 84 19:14:13 PDT Received: from Xerox.ARPA by SU-SCORE.ARPA with TCP; Thu 4 Oct 84 19:11:50-PDT Received: from Semillon.ms by ArpaGateway.ms ; 04 OCT 84 19:11:56 PDT Date: 4 Oct 84 19:11 PDT From: JonL.pa@XEROX.ARPA Subject: Re: Questions about specification and possible implementations In-reply-to: Skef Wholey 's message of Thu, 4 Oct 84 20:43 EDT To: Wholey@CMU-CS-C.ARPA cc: JonL.pa@XEROX.ARPA, COMMON-LISP%SU-AI@SU-SCORE.ARPA, HEDRICK@RUTGERS.ARPA, Moon@SCRC-RIVERSIDE.ARPA, Rem%IMSSS@SU-SCORE.ARPA NOTINLINE isn't the issue -- it's knowing *who* needs to be so protected when one wants to ensure traceability. In fact, many major Interlisp-D operations are ambiguous at the compiler level -- the compiler merely emits an opcode with *may or may not* call the function of the corresponding name. I agree -- it's too bad that special forms and macros aren't traceable. But as you recognize, that isn't the source of the unTRACEability problem -- it's when the encapsulation function somehow depends on the function being traced. If encapsulation functions were always compiled (by possibly a super-fast non-optimizing compiler) then the space of untraceables would diminish dramatically. PDP10 MacLisp tried to do something like that -- using "hidden" copies of the systems functions which it used (like PRINT ...). Unfortunately it, like Interlisp, didn't "hide" QUOTE. Re the space cost of "double-compilation" (may I call the scheme you proposed that? the one to emit both code sequences for open and for closed formats, which is toggled by a runtime switch), and you comment ". . . but I don't think there are 'myriads' of calls to those functions". Did you examine the SpiceLisp implementation, or user application programs? -- JonL --  Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 4 Oct 84 18:27:41 PDT Received: from SCRC-EUPHRATES by SCRC-QUABBIN via CHAOS with CHAOS-MAIL id 88658; Thu 4-Oct-84 21:27:49-EDT Date: Thu, 4 Oct 84 21:28 EDT From: "David A. Moon" Subject: Questions about OPEN To: "Robert (LISPer 68K)Heller" cc: common-lisp@SU-AI.ARPA In-Reply-To: The message of 3 Oct 84 09:26-EDT from "Robert (LISPer 68K)Heller" Message-ID: <841004212821.9.MOON@EUPHRATES.SCRC.Symbolics> Date: Wed, 3 Oct 84 08:26 EST From: Robert (LISPer 68K)Heller I have some questions about what the function OPEN returns if :DIRECTION is :PROBE: 1) if the file exists, does OPEN return a closed stream? Well, it returns a stream that doesn't support any I/O operations, just things like file-write-date, file-author, file-length, and truename. This could be implemented as a special kind of stream or as a closed stream. Interestingly enough, the manual says that each of those four functions is only allowed for an open stream. Presumably this means to imply that you cannot use them on a stream returned by a probe-open. This in turn implies that probe-open might as well have been defined to return simply true or false. I contend that :direction :probe should never have been put into Common Lisp and only the probe-file function ought to exist. In some implementations, ours for instance, probe-file is implemented by calling open with the :direction :probe option, but I think that is an internal interface, not something that should be visible in the Common language. On the other hand, in some file systems the write-date, author, length, and truename cannot be determined for an output file until the file is closed, because the file system assigns them at that time. This suggests that it was a mistake for the manual to require that the stream passed to these functions be open. They ought to accept a stream that resulted from probe-open and also a stream that has been closed with the close function. 2) if the file does not exist and :IF-DOES-NOT-EXIST is :CREATE, what does OPEN do? create an empty and return a closed stream? We signal an error for an illegal combination of options. I can't tell whether the manual rules that out or not. Is Guy, or anyone, still recording possible ambiguities or errors in the manual for later correction? I don't plan to follow this up myself.  Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 4 Oct 84 17:44:59 PDT Received: from CMU-CS-C.ARPA by SU-SCORE.ARPA with TCP; Thu 4 Oct 84 17:42:50-PDT Received: ID ; Thu 4 Oct 84 20:43:06-EDT Date: Thu, 4 Oct 1984 20:43 EDT Message-ID: Sender: WHOLEY@CMU-CS-C.ARPA From: Skef Wholey To: JonL.pa@XEROX.ARPA Cc: COMMON-LISP%SU-AI@SU-SCORE.ARPA, HEDRICK@RUTGERS.ARPA, Moon@SCRC-RIVERSIDE.ARPA, Rem%IMSSS@SU-SCORE.ARPA Subject: Questions about specification and possible implementations Date: Thursday, 4 October 1984 19:01-EDT From: JonL.pa at XEROX.ARPA Hmmm, I think this discussion is beating around an important "bush" -- namely *exactly* which of the functions in the Common Lisp spec is it permissible to open-code in such a way that TRACE, BREAK, ADVISE, etc will not work? (DECLARE (NOTINLINE FOO)) is the way to make FOO traceable regardless of what the compiler might do. All implementations should grok that. Additionally, there may be other functions for which TRACE etc cannot work (there are a number of such functions in Interlisp-D -- QUOTE comes to mind -- and woe betide the poor loser who accidentally stumbles across one, for his machine will rapidly take a non-returnable vacation "South") QUOTE is a special form. The Common Lisp specification of TRACE indicates that it may be used to trace functions, not macros or special forms. I agree that tracing macros and special forms can be useful, but restricting TRACE to functions is an elegant way to avoid that problem. Indeed, there are some functions that probably can't be traced, but I believe the encapsulation code can figure out when it's being invoked recursively. Our TRACE endeavors to do this. Making the encapsulation code be compiled (easy and fun with lexical closures!) avoids the lossage that can happen when one traces EVAL, for example. I see Hedrick's complaint as continuing evidence of the tension in this community between the special-purpose microcoded machine adherents and the general-purpose stock hardware men. I'm with Chuck in thinking that it was a mistake to remove names of functions that are "there only for compiler optimizations" -- as long as Common Lisp is going to run on something other than a 3600 or a PERQ, more attention needs to be paid to these needs. (i.e., when Chuck says "I believe it to be a mistake to do these optimizations", I take him to mean that either you must compile a call to the documented function, or else provide a documented name of the right functionality that the user might put in his source code). If I were also involved in doing a stock-hardware implementation (which I am), I don't think I'd decide to do these things differently. I assume you meant that this quick check could be part of a microcoded instruction. If I implemented the scheme I outlined in my previous message, I would do so without introducing any new macroinstruction. I don't think it's worth the microcode. At one time, all such needs were swept into the bag of "it's only a compiler optimization, put it in a DECLARE" -- remember the RPG Memorial Vector Proposal -- but if these "compiler optimizations" are critically essential to any realistic implementation on stock hardware . . . Almost all of the "compiler optimizations" that make vector hacking cheap on stock hardware are very easy to do if the right information is around at the right time. Declarations are important in Common Lisp on stock hardware; if you're implementing Common Lisp on stock hardware, your compiler should be structured so that the information from the declarations is easily accessible in your code generator and optimizers. Incidentally, your solution of dynamic testing is similar to many speed optimizations that compilers sometimes emit (e.g., doing an open-coded EQ check before actually calling EQUAL), but I'd had to see it applied to all those "myriads" of functions that took any keyword -- think of the code-size bloat! If you're concerned about code size, do (DECLARE (OPTIMIZE SPACE)). I've spent a great deal of time in the past few weeks staring at assembly code listings, and I'm pretty sure that such a test on function calls to keywordized functions would not contribute significantly to code size. There are "myriads" of functions that take keyword args, but I don't think there are "myriads" of calls to those functions. --Skef  Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 4 Oct 84 17:38:59 PDT Received: from Xerox.ARPA by SU-SCORE.ARPA with TCP; Thu 4 Oct 84 16:34:43-PDT Received: from Semillon.ms by ArpaGateway.ms ; 04 OCT 84 16:35:41 PDT Date: 4 Oct 84 16:01 PDT From: JonL.pa@XEROX.ARPA Subject: Re: Questions about specification and possible implementations In-reply-to: Skef Wholey 's message of Thu, 4 Oct 84 17:43 EDT To: Wholey@CMU-CS-C.ARPA cc: HEDRICK@RUTGERS.ARPA, COMMON-LISP%SU-AI@SU-SCORE.ARPA, Moon@SCRC-RIVERSIDE.ARPA, Rem%IMSSS@SU-SCORE.ARPA Hmmm, I think this discussion is beating around an important "bush" -- namely *exactly* which of the functions in the Common Lisp spec is it permissible to open-code in such a way that TRACE, BREAK, ADVISE, etc will not work? Additionally, there may be other functions for which TRACE etc cannot work (there are a number of such functions in Interlisp-D -- QUOTE comes to mind -- and woe betide the poor loser who accidentally stumbles across one, for his machine will rapidly take a non-returnable vacation "South") I see Hedrick's complaint as continuing evidence of the tension in this community between the special-purpose microcoded machine adherents and the general-purpose stock hardware men. I'm with Chuck in thinking that it was a mistake to remove names of functions that are "there only for compiler optimizations" -- as long as Common Lisp is going to run on something other than a 3600 or a PERQ, more attention needs to be paid to these needs. (i.e., when Chuck says "I believe it to be a mistake to do these optimizations", I take him to mean that either you must compile a call to the documented function, or else provide a documented name of the right functionality that the user might put in his source code). At one time, all such needs were swept into the bag of "it's only a compiler optimization, put it in a DECLARE" -- remember the RPG Memorial Vector Proposal -- but if these "compiler optimizations" are critically essential to any realistic implementation on stock hardware . . . Incidentally, your solution of dynamic testing is similar to many speed optimizations that compilers sometimes emit (e.g., doing an open-coded EQ check before actually calling EQUAL), but I'd had to see it applied to all those "myriads" of functions that took any keyword -- think of the code-size bloat! -- JonL --  Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 4 Oct 84 17:29:35 PDT Received: from SCRC-EUPHRATES by SCRC-QUABBIN via CHAOS with CHAOS-MAIL id 88632; Thu 4-Oct-84 20:29:39-EDT Date: Thu, 4 Oct 84 20:30 EDT From: "David A. Moon" Subject: numbers, oh well. To: Richard Fateman cc: common-lisp@SU-AI.ARPA In-Reply-To: <8410041709.AA00759@ucbdali.ARPA> Message-ID: <841004203015.5.MOON@EUPHRATES.SCRC.Symbolics> Date: Thu, 4 Oct 84 10:09:14 pdt From: fateman%ucbdali@Berkeley (Richard Fateman) "There are no infinities in the standard numbers of Common Lisp" (this is repeated at the bottom of page 202 of aluminum edition.) is inconsistent with the statement on p 19 of the same edition, "... should approximate IEEE proposed standard ..." which has infinities. The first statement says that an implementation is not required to provide infinities, and therefore portable programs cannot rely upon infinite numbers. The second statement recommends that those implementations that have a choice should approximate IEEE numbers in their floating point, and thus some implementations are permitted and even encouraged to have infinite floating point numbers. I fail to see any inconsistency here. Keeping 1/0 is probably less trouble than making it an error. Floating point numbers and rational numbers are not the same. Particular implementations of Common Lisp and the Common Lisp language are not the same. I think we've been through this discussion quite enough times before. Let's work on something that matters. For those of you who might think that arithmetic has been settled in a correct and standard way in CL, I think that what has happened is that people who have practical experience with error analysis and scientific support have "tuned out" on CL, since it attempts to set a pseudo-standard which is at odds with the IEEE (nearly adopted) standard. I fail to find anything in the Common Lisp manual that forbids an implementation to conform to the IEEE proposed standard. I fail to find anything in the Common Lisp manual that requires me to change my machine, which currently conforms to the IEEE proposed standard, and make it cease conforming to that standard. Let's discuss something else.  Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 4 Oct 84 15:45:28 PDT Received: from Salvador.ms by ArpaGateway.ms ; 04 OCT 84 15:43:36 PDT Date: 4 Oct 84 15:38 PDT From: JonL.pa@XEROX.ARPA Subject: Re: How constant are defconstants? In-reply-to: masinter.pa's message of 4 Oct 84 14:22 PDT To: masinter.pa@XEROX.ARPA cc: JonL.pa@XEROX.ARPA, Meehan@YALE.ARPA, Common-Lisp@SU-AI.ARPA Sorry, I wasn't fully clear. "compile-time constants", when mentioned to the CommonLisp community, merely mean "constants", especially when encountered by the compiler. The common lisp term for what you are referring to is "Named constants" (sec 5.1.2 of manual), and I'm afraid you've just confused the two. The existing code with "runtime updates to compile-time constants" occurs even in older Interlisp code like this: (SETQ *FOO* (QUOTE (MY MESSAGE ABOUT *SOMETHING*))) . . . (RPLACA (CDDDR *FOO*) (QUOTE VARIABLES)) and in the context of the discussion, (QUOTE (MY MESSAGE ABOUT *SOMETHING*)) is a "compile time" constant. -- JonL --  Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 4 Oct 84 14:57:49 PDT Received: from CMU-CS-C.ARPA by SU-SCORE.ARPA with TCP; Thu 4 Oct 84 14:55:23-PDT Received: ID ; Thu 4 Oct 84 17:44:27-EDT Date: Thu, 4 Oct 1984 17:43 EDT Message-ID: Sender: WHOLEY@CMU-CS-C.ARPA From: Skef Wholey To: Charles Hedrick Cc: COMMON-LISP%SU-AI@SU-SCORE.ARPA, Moon@SCRC-RIVERSIDE.ARPA, Rem%IMSSS@SU-SCORE.ARPA Subject: Questions about specification and possible implementations In-reply-to: Msg of 4 Oct 1984 16:24-EDT from Charles Hedrick It is certainly alright to optimize BUILT-IN keyword functions, since "it is an error" to redefine them; it is alright to "open code" CAR for the same reason. If I were to put in code that tried to optimize ALL keyword functions, I would transform your call (foo :bogus-key 1) into something like (if (eq #'foo-intern-form '#) (foo-internal-form 1) (foo :bogus-key 1)), where that quoted unreadable thing is what the caller thought FOO's non-keywordized form was at the time of compilation. This is a correct transformation even in the case that you're worried about, and can be done efficiently on all machines I can think of. Those machines with hairy linkage mechanisms could perhaps do it a wee bit more efficiently. --Skef  Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 4 Oct 84 14:23:19 PDT Received: from Semillon.ms by ArpaGateway.ms ; 04 OCT 84 14:23:27 PDT Date: 4 Oct 84 14:22 PDT From: masinter.pa@XEROX.ARPA Subject: Re: How constant are defconstants? In-reply-to: JonL.pa's message of 4 Oct 84 12:47 PDT To: JonL.pa@XEROX.ARPA cc: Meehan@YALE.ARPA, Common-Lisp@SU-AI.ARPA Your message puzzles me; I've not seen "lots of existing code with runtime updates to compile-time constants". In fact, compile time constants were only added to Interlisp in the last couple of years (1981 or 1982, I believe), and didn't appear in the 1978 manual.  Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 4 Oct 84 13:34:16 PDT Received: from RUTGERS.ARPA by SU-SCORE.ARPA with TCP; Thu 4 Oct 84 13:23:02-PDT Date: 4 Oct 84 16:24:40 EDT From: Charles Hedrick Subject: Re: Questions about specification and possible implementations To: Moon@SCRC-RIVERSIDE.ARPA cc: Rem%IMSSS@SU-SCORE.ARPA, COMMON-LISP%SU-AI@SU-SCORE.ARPA In-Reply-To: Message from "Moon@SCRC-RIVERSIDE.ARPA" of 24 Sep 84 16:56:00 EDT I'm not sure I agree with the comment that all implementations will optimize keyword functions. It is certainly true that one can easily optimize them. However one of the nice things about Lisp is that it is possible to redefine functions on the fly. This allows things like TRACE, BREAK, and ADVISE, not to mention having users replace standard functions with their own versions. If the compiler turns (foo :bogus-key 1) into (foo-internal-form 1) then the user can't redefine foo and get the expected result. Thus I believe it to be a mistake to do these optimizations. I'm sure that this is a minority opinion. Most of the people involved in the Common Lisp language definition do not believe in this sort of thing, just as they do not believe in interpreters. But there are some implementors who want Common Lisp to be a dialect of Lisp. -------  Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 4 Oct 84 13:39:54 PDT Date: 4 October 1984 16:37-EDT From: Kent M Pitman Subject: *applyhook* To: Moon @ SCRC-RIVERSIDE cc: Common-Lisp @ SU-AI In-reply-to: Msg of Wed 26 Sep 84 23:05 EDT from Moon at SCRC-RIVERSIDE.ARPA By the way, in talking to GSB on this issue, I have been convinced to withdraw my objection to having the *APPLYHOOK* handler take the env argument of the caller. After all, if the arguments being inspected have been passed incorrectly, it would be handy to be able to compute new ones using the old environment. I agree with most of your remarks regarding creating ways of accessing parts of functions (name, env, params for sure; I'm not sure about body -- not clear to me exactly how that differs from interpreted to compiled code). Also, in the case of env, it may be the case that either the meaning of that will have to be left vague or else optimization may suffer. eg, hypothesizing that ENV-OF accessed a closure's environment, would (LAMBDA (Y) ((LAMBDA (X) (EQ X (EVAL 'X (ENV-OF #'(LAMBDA () X))))) Y)) and (LAMBDA (Y) (EQ Y (EVAL 'X (ENV-OF #'(LAMBDA () Y))))) be semantically equivalent expressions? In light of this, how exactly would you want the ENV-OF function to be used such that this sort of problem did not come up? -kmp  Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 4 Oct 84 12:48:04 PDT Received: from Semillon.ms by ArpaGateway.ms ; 04 OCT 84 12:47:27 PDT Date: 4 Oct 84 12:47 PDT From: JonL.pa@XEROX.ARPA Subject: Re: How constant are defconstants? In-reply-to: Jim Meehan 's message of Wed, 3 Oct 84 17:57:19 EDT To: Meehan@YALE.ARPA cc: Common-Lisp@SU-AI.ARPA I would assume that whereever one had written code like (FOO *PLANETS*) that he would get the same operational behaviour as if he had written (FOO '(MERCURY VENUS EARTH MARS JUPITER SATURN URANUS NEPTUNE PLUTO)) PDP10 MacLisp made it possible to convert all such constants into read-only areas -- with the view to catching unintended updates such as your example (SETF (CAR *PLANETS*) something) but I'm sure that Common Lisp can't enforce such a protective mechanism -- only permit it. Even MacLisp's solution is only partial, in that the constants are writeable until the explicit call to "convert" everything over. Interlisp has gone to the other extreme -- not only is there lots of existing code with runtime updates to compile-time constants, but in Interlisp-10 there is even the weird SETN to update "numbers". E.g. -> (SETQ TEM (SETQ PI 3.14)) 3.14 -> (SETN PI 3.14159) 3.14159 -> TEM 3.14159 Happily, Interlisp-D, didn't perpetuate the SETN lossage, but there is still a lot of resistance in the Interlisp community to giving up updatability of "constants". -- JonL --  Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 4 Oct 84 12:30:25 PDT Received: from SCRC-EUPHRATES by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 103716; Thu 4-Oct-84 15:24:51-EDT Redistributed-date: Thu, 4 Oct 84 15:25 EDT Redistributed-to: Common-Lisp@SU-AI.ARPA Redistributed-date: Sun, 30 Sep 84 22:14 EDT Redistributed-to: Common-Lisp@SU-AI.ARPA Date: Wed, 26 Sep 84 23:05 EDT From: Moon@SCRC-RIVERSIDE.ARPA Subject: applyhook To: Common-Lisp@SU-AI.ARPA In-Reply-To: <840831202452.2.MOON@EUPHRATES.SCRC.Symbolics>, The message of 7 Sep 84 19:00-EDT from WVANROGGEN at DEC-MARLBORO, The message of 10 Sep 84 03:24-EDT from GSB at MIT-MC Message-ID: <840926230531.1.MOON@EUPHRATES.SCRC.Symbolics> Date: Fri, 31 Aug 84 20:24 EDT From: "David A. Moon" APPLYHOOK should not take an &OPTIONAL ENV argument. Similarly *APPLYHOOK* should receive two arguments, not three arguments. An environment is not meaningful for the APPLY operation, only for the EVAL operation. Does anyone disagree? I won't bother everyone by including the whole conversation that resulted from this, just the final messages. Date: Fri 7 Sep 84 19:00:15-EDT From: "Walter van Roggen" Actually, I hadn't thought about the potential ambiguity of which environment would be passed to the apply hook function; I had just assumed that it would be the same as that passed to the eval hook function immediately before. It seems to me that the purpose of applyhook is to allow one to examine the actual function and the actual arguments it's about to be applied to. (I suppose you could get the effect of the applyhook by using the evalhook and simulating the evaluator--but that's what this mechanism should help avoid.) It's a lot easier to examine the environment of the function when it is handed to you. On the other hand you could argue that any debugging facility will always use both evalhook and applyhook simultaneously, but that shouldn't be necessary. Date: 10 September 1984 03:24-EDT From: Glenn S. Burke I think we've safely established that in order to just function properly, APPLYHOOK (and therefore the value of *APPLYHOOK*) does not need to be given an environment argument. As someone said, it makes no sense to pass one environment because there are two involved. To me, that means we should pass BOTH environments. After all, one of the purposes of having this is for debugging, from user code. If we did not want this we wouldn't have defined the hooks, just specified the existence of STEP like we have TRACE. *APPLYHOOK* should be given TWO environments: one is the current environment (as of when the hook is invoked -- like that given to *evalhook*). The other is an environment object gleaned from the function being applied. This is so that *applyhook* can examine either one. Possibly in the case of compiled or globally defined functions, the function-environment argument will be NIL, of course. So, what i propose is this: *APPLYHOOK* gets called on 4 arguments: (1) the function being applied (2) the list of arguments (3) the environment of the function (4) the current environment. APPLYHOOK takes only arguments of the function, arguments, evalhookfn, and applyhookfn. No environment argument at all -- the function carries the environment with it. Evaluation of a lambda combination ((lambda ...) ...) passes a function made (as if) by evaluating (function (lambda ...)). The function-environment argument to *applyhook* is deliberately redundant with the environment carried by the function, so that it may be an environment object just like the current-environment argument, and thus examined/whatever similarly. I feel fairly strongly that to not pass these environments to *applyhook* just because it looks now like we can get away with it will unnecessarily restrict any sort of debugging extensions in the future. And even within the present CL definition user code can do things with them by passing them to EVAL. This is probably right. Certainly you all talked me into believing the theory that *applyhook* should be passed the environment in which the arguments were evaluated, since some programs might need that and it's not easily accessible otherwise. As for whether the *applyhook* should also receive the environment in which forms in the body of the function will be evaluated, my feeling is: maybe, but wouldn't it be better to provide general facilities for accessing the various parts of a function (that is, an applicable object; that is, anything that can be the first argument to *applyhook* and also anything that can be the result of SYMBOL-FUNCTION). These parts include at least the name, the environment, the parameter list, and the body. For now, in my system, I decided to compromise and implement what it says in the manual (always a good default!). *applyhook* takes three arguments and applyhook takes five arguments (one of which is optional). As for what the manual doesn't say, the last argument to *applyhook* is the environment in which the arguments were evaluated, the last argument to applyhook is ignored.  Received: from UCB-VAX.ARPA by SU-AI.ARPA with TCP; 4 Oct 84 10:08:38 PDT Received: from ucbdali.ARPA by UCB-VAX.ARPA (4.24/4.31) id AA25397; Thu, 4 Oct 84 10:09:46 pdt Received: by ucbdali.ARPA (4.24/4.38) id AA00759; Thu, 4 Oct 84 10:09:14 pdt Date: Thu, 4 Oct 84 10:09:14 pdt From: fateman%ucbdali@Berkeley (Richard Fateman) Message-Id: <8410041709.AA00759@ucbdali.ARPA> To: Moon@SCRC-RIVERSIDE.ARPA, Rem@IMSSS Subject: numbers, oh well. Cc: common-lisp@su-ai "There are no infinities in the standard numbers of Common Lisp" (this is repeated at the bottom of page 202 of aluminum edition.) is inconsistent with the statement on p 19 of the same edition, "... should approximate IEEE proposed standard ..." which has infinities. Keeping 1/0 is probably less trouble than making it an error. For those of you who might think that arithmetic has been settled in a correct and standard way in CL, I think that what has happened is that people who have practical experience with error analysis and scientific support have "tuned out" on CL, since it attempts to set a pseudo-standard which is at odds with the IEEE (nearly adopted) standard.  Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 4 Oct 84 05:44:27 PDT Received: from SCRC-QUABBIN.ARPA (MIT-MC.ARPA.#Internet) by SU-SCORE.ARPA with TCP; Thu 4 Oct 84 05:43:10-PDT Received: from SCRC-EUPHRATES by SCRC-QUABBIN via CHAOS with CHAOS-MAIL id 87136; Mon 1-Oct-84 14:19:52-EDT Redistributed-date: Mon, 1 Oct 84 14:20 EDT Redistributed-to: Rem%IMSSS@SU-SCORE.ARPA, COMMON-LISP%SU-AI@SU-SCORE.ARPA Redistributed-date: Thu, 27 Sep 84 23:49 EDT Redistributed-to: Rem%IMSSS@SU-SCORE.ARPA, COMMON-LISP%SU-AI@SU-SCORE.ARPA Date: Mon, 24 Sep 84 16:56 EDT From: Moon@SCRC-RIVERSIDE.ARPA Subject: Questions about specification and possible implementations To: Rem%IMSSS@SU-SCORE.ARPA cc: COMMON-LISP%SU-AI@SU-SCORE.ARPA In-Reply-To: The message of 23 Sep 84 20:52-EDT from Rem at IMSSS Supersedes: <840924165534.2.MOON@EUPHRATES.SCRC.Symbolics> Message-ID: <840924165603.3.MOON@EUPHRATES.SCRC.Symbolics> Date: 23 Sep 1984 1752-PDT From: Rem@IMSSS In Common LISP there seems to be a strong dichotomy between functions (all arguments evaluated before call) and macros&SpecialForms, almost to the point of forbidding implementors to jump across the barrier. Yet some functions with all the &OPTIONAL and &KEY arguments may be difficult or inefficient to implement as true functions, and thus may be implemented as FEXPRs in the interpretor and MACROs in the compiler. It is impermissible for an implementation to implement something documented as a function as something other than a function. This doesn't rule out compiler optimizations, of course, and all the implementations I know about do compiler optimizations for the hairier and most common functions with &KEY arguments. The book says the set of special forms is fixed and no way is provided to make new ones. But is any way provided to define some of the special forms from LISP level in the first place, or must all be handcoded in assembly language or C etc.? Is any way provided to install bugfixes in special forms by overlaying the old definition with a new one? This is an issue for each implementation to address. The Common Lisp language is a portable subset, not a complete implementation. To take one example, in our implementation the interpreter routines for all of the special forms are defined in Lisp, using a special-form-defining-special-form that you won't find in the Common Lisp manual. The reason it would be inutile to provide a portable way to define special forms is that they have to be defined for both the interpreter and the compiler. While it's (almost) easy to define portable extensions to the interpreter, there is a wide variation in compiler techniques. Trying to standardize this would be a monumental task, and probably doomed anyway since compiler techniques are often dictated by the underlying hardware. At the front of the chapter on numbers it claims: (LET ((X Z) (Y Z)) (EQ X Y)) may be false if the value of Z is a number. I can't see a mechanism for this in any reasonable LISP unless Z is not only presently a number but has been declared a number and this is compiled code which represents the value of Z as a machine number instead of a LISP object, whereas X and Y are undeclared and thus LISP objects, so new objects must be constructed for X and Y to hold the value Z, and these new objects won't be EQ to each other. But could somebody who really knows tell me what the true explanation is?? The book leaves this a complete mystery. Try the following example in pdp10 Maclisp (compiled without declarations). (defun tst (z) (let ((x z) (y z)) (eq x y))) (defun tst2 (a b) (tst (+ a b))) (tst2 1234567 -1) => nil I don't think the book needs to explain the inner workings of this. Common Lisp, as a portable subset language, is allowed to contain freedoms for implementors even if no current implementors exploit those freedoms, if it's reasonable to assume that in the future someone may need those freedoms. Minor questions: In the introductory chapter, the Common-LISP book says semicolon causes all characters up to eol to be discarded, but doesn't say whether eol is kept or discarded. A comment is equivalent to whitespace. In Lisp syntax it doesn't matter whether whitespace is made out of spaces, carriage returns, or something else, it just serves to separate tokens. Ditto, doesn't say which characters inside "" are automatically letterified and which have their usual semantic effects and thus need explicit letterification to be treated as string text. Huh? Ditto, backslash at end of line does what? (Illegal, quote just the next character which may be half of a crlf on some systems, quote the eol token always?) This is a good issue. From the discussion on page 22 I think it is supposed to give a Newline character. Bug in the manual: the word "newline" does not appear in the index. Ditto, vertical-bar, same questions as for "". (If above questions are answered elsewhere in manual, need pointer from intro to where info given?) When COPY-SYMBOL is done, the pnames will be the same, but will they be EQ or just EQUAL? Presumably this should be undefined since there is little to be gained by defining it one way or the other and an implementation might want to do something strange. After all, it is not even defined whether calling SYMBOL-NAME twice on the -same- symbol yields EQ values! The book doesn't say what (/ 1 0) does. Is it an error, or does it signal an error, or does it return the ratio of 1/0 as a way of representing infinity, or what? Good question. There are no infinities in the standard numbers of Common Lisp, so it can't be required to return 1/0. My guess is that Common Lisp does not rule out a particular implementation deciding to return 1/0. In other words it "is an error" -- portable programs should not depend on what happens, and different implementations might do different things. If NIL is an element of an assoc list, does this element get skipped over by ASSOC et al or is it a stop flag? Second to last paragraph on page 279. How are the axis numbers of an array numbered, that is if you create an array by (MAKE-ARRAY 3 5 7) then will (ARRAY-DIMENSION array 0) return 3 or 7? Good point. It returns 3, but I don't see anything that says that explicitly.  Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 4 Oct 84 05:44:48 PDT Received: from SCRC-QUABBIN.ARPA (MIT-MC.ARPA.#Internet) by SU-SCORE.ARPA with TCP; Thu 4 Oct 84 05:43:35-PDT Received: from SCRC-EUPHRATES by SCRC-QUABBIN via CHAOS with CHAOS-MAIL id 87137; Mon 1-Oct-84 14:20:02-EDT Redistributed-date: Mon, 1 Oct 84 14:20 EDT Redistributed-to: COMMON-LISP%SU-AI@SU-SCORE.ARPA Redistributed-date: Thu, 27 Sep 84 23:49 EDT Redistributed-to: COMMON-LISP%SU-AI@SU-SCORE.ARPA Date: Mon, 24 Sep 84 16:55 EDT From: Moon@SCRC-RIVERSIDE.ARPA Subject: Questions about specification and possible implementations To: Rem@IMSSS cc: COMMON-LISP%SU-AI@SU-SCORE.ARPA In-Reply-To: The message of 23 Sep 84 20:52-EDT from Rem at IMSSS Message-ID: <840924165534.2.MOON@EUPHRATES.SCRC.Symbolics> Date: 23 Sep 1984 1752-PDT From: Rem@IMSSS In Common LISP there seems to be a strong dichotomy between functions (all arguments evaluated before call) and macros&SpecialForms, almost to the point of forbidding implementors to jump across the barrier. Yet some functions with all the &OPTIONAL and &KEY arguments may be difficult or inefficient to implement as true functions, and thus may be implemented as FEXPRs in the interpretor and MACROs in the compiler. It is impermissible for an implementation to implement something documented as a function as something other than a function. This doesn't rule out compiler optimizations, of course, and all the implementations I know about do compiler optimizations for the hairier and most common functions with &KEY arguments. The book says the set of special forms is fixed and no way is provided to make new ones. But is any way provided to define some of the special forms from LISP level in the first place, or must all be handcoded in assembly language or C etc.? Is any way provided to install bugfixes in special forms by overlaying the old definition with a new one? This is an issue for each implementation to address. The Common Lisp language is a portable subset, not a complete implementation. To take one example, in our implementation the interpreter routines for all of the special forms are defined in Lisp, using a special-form-defining-special-form that you won't find in the Common Lisp manual. The reason it would be inutile to provide a portable way to define special forms is that they have to be defined for both the interpreter and the compiler. While it's (almost) easy to define portable extensions to the interpreter, there is a wide variation in compiler techniques. Trying to standardize this would be a monumental task, and probably doomed anyway since compiler techniques are often dictated by the underlying hardware. At the front of the chapter on numbers it claims: (LET ((X Z) (Y Z)) (EQ X Y)) may be false if the value of Z is a number. I can't see a mechanism for this in any reasonable LISP unless Z is not only presently a number but has been declared a number and this is compiled code which represents the value of Z as a machine number instead of a LISP object, whereas X and Y are undeclared and thus LISP objects, so new objects must be constructed for X and Y to hold the value Z, and these new objects won't be EQ to each other. But could somebody who really knows tell me what the true explanation is?? The book leaves this a complete mystery. Try the following example in pdp10 Maclisp (compiled without declarations). (defun tst (z) (let ((x z) (y z)) (eq x y))) (defun tst2 (a b) (tst (+ a b))) (tst2 1234567 -1) => nil I don't think the book needs to explain the inner workings of this. Common Lisp, as a portable subset language, is allowed to contain freedoms for implementors even if no current implementors exploit those freedoms, if it's reasonable to assume that in the future someone may need those freedoms. Minor questions: In the introductory chapter, the Common-LISP book says semicolon causes all characters up to eol to be discarded, but doesn't say whether eol is kept or discarded. A comment is equivalent to whitespace. In Lisp syntax it doesn't matter whether whitespace is made out of spaces, carriage returns, or something else, it just serves to separate tokens. Ditto, doesn't say which characters inside "" are automatically letterified and which have their usual semantic effects and thus need explicit letterification to be treated as string text. Huh? Ditto, backslash at end of line does what? (Illegal, quote just the next character which may be half of a crlf on some systems, quote the eol token always?) This is a good issue. From the discussion on page 22 I think it is supposed to give a Newline character. Bug in the manual: the word "newline" does not appear in the index. Ditto, vertical-bar, same questions as for "". (If above questions are answered elsewhere in manual, need pointer from intro to where info given?) When COPY-SYMBOL is done, the pnames will be the same, but will they be EQ or just EQUAL? Presumably this should be undefined since there is little to be gained by defining it one way or the other and an implementation might want to do something strange. After all, it is not even defined whether calling SYMBOL-NAME twice on the -same- symbol yields EQ values! The book doesn't say what (/ 1 0) does. Is it an error, or does it signal an error, or does it return the ratio of 1/0 as a way of representing infinity, or what? Good question. There are no infinities in the standard numbers of Common Lisp, so it can't be required to return 1/0. My guess is that Common Lisp does not rule out a particular implementation deciding to return 1/0. In other words it "is an error" -- portable programs should not depend on what happens, and different implementations might do different things. If NIL is an element of an assoc list, does this element get skipped over by ASSOC et al or is it a stop flag? Second to last paragraph on page 279. How are the axis numbers of an array numbered, that is if you create an array by (MAKE-ARRAY 3 5 7) then will (ARRAY-DIMENSION array 0) return 3 or 7? Good point. It returns 3, but I don't see anything that says that explicitly.  Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 4 Oct 84 04:13:43 PDT Received: from SPA-RUSSIAN by SPA-Nimbus with CHAOS; Thu 4-Oct-84 01:27:16-PDT Date: Thu, 4 Oct 84 01:24 PDT From: Bill Gosper Subject: malnumeracy To: "common-lisp@SU-AI"@MIT-MC.ARPA Supersedes: The message of 25 Sep 84 22:31-PDT from Bill Gosper In aluminum edition, p. 18, 3.1010299957f-1 should be 3.010299957f-1. On p. 67, the comment in (defun discriminant . . .) is wrong unless the third sentence is preconditioned with "If a, b, and c are real,".  Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 3 Oct 84 17:17:57 PDT Received: ID ; Wed 3 Oct 84 20:18:15-EDT Date: Wed, 3 Oct 1984 20:18 EDT Message-ID: Sender: FAHLMAN@CMU-CS-C.ARPA From: "Scott E. Fahlman" To: Jim Meehan Cc: Common-Lisp@SU-AI.ARPA Subject: How constant are defconstants? In-reply-to: Msg of 3 Oct 1984 17:57-EDT from Jim Meehan Jim, The following is my own view on this issue. If anyone out there in net-land disagrees, speak up. The concept of enforced read-only data structures is not included in Common Lisp, because implementations on some machines and on some operating systems just couldn't hack that without an unacceptable penalty in performance. It "is an error" to mess with something declared to be a constant, which means that the compiler can play various tricks, but doesn't have to. An implemenations could build such a structure in some sort of read-only space and signal an error if you try to alter it, but again it doesn't have to. The same is true with :READ-ONLY slot options in Defstruct -- all this really guarantees is that no SETF form is created for this slot. So if you want to create a read-only structure that guarantees to signal an error if you touch it, there may be a way to do this in some implemenations, but there's no way to do this in portable Common Lisp. You might just as well create your structure with DEFVAR. -- Scott  Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 3 Oct 84 16:49:26 PDT Received: ID ; Wed 3 Oct 84 19:49:40-EDT Date: Wed, 3 Oct 1984 19:49 EDT Message-ID: From: Rob MacLachlan To: Jim Meehan Cc: Common-Lisp@SU-AI.ARPA Subject: How constant are defconstants? In-reply-to: Msg of 3 Oct 1984 17:57-EDT from Jim Meehan Although defconstants are second-rate constants as compared to literal constants inline in code, I think that previous decisions forbidding modification of constants would apply here. In any case, you can obtain the desired effect by specifying the contents at the time the array is created: (defconstant the-data (make-array n :initial-contents (list ...))) Rob  Received: from YALE.ARPA by SU-AI.ARPA with TCP; 3 Oct 84 15:18:38 PDT Received: by YALE-BULLDOG.YALE.ARPA; 3 Oct 84 18:11:59 EDT (Wed) Message-Id: <8410032211.AA00370@YALE-BULLDOG.YALE.ARPA> Date: Wed, 3 Oct 84 17:57:19 EDT From: Jim Meehan Subject: How constant are defconstants? To: Common-Lisp@SU-AI.ARPA The Manual, page 68: DEFCONSTANT is like DEFPARAMETER but does assert that the value of the variable "name" is fixed and does license the compiler to build assumptions into programs being compiled. (However, if the compiler chooses to replace references to the name of the constant by the value of the constant in code to be compiled, perhaps in order to allow further optimization, the compiler must take care that such "copies" appear to be EQL to the object that is the actual value of the constant. For example, the compiler may freely make copies of numbers but must exercise care when the value is a list.) Suppose I say (DEFCONSTANT *PLANETS* '(MERCURY VENUS EARTH MARS JUPITER SATURN URANUS NEPTUNE PLUTO)) [and assume I got those in the right order]. It is now presumably an error to say (SETQ *PLANETS* x) but what about (SETF (CAR *PLANETS*) x) ? It would seem problematic, since the compiler might want to compile (CAR *PLANETS*) or (NTH 0 *PLANETS*) as 'MERCURY, just as it might want to compile (CAR '(A B C)) as 'A. For simple constants like that, the SETF seems unreasonable, but what's a good way to create an array that is very expensive to initialize (i.e., where computing the initial values takes a long time), and which should be "read-only" thereafter (a la DEFSTRUCT)? I'm using (DEFCONSTANT *THE-DATA* (MAKE-ARRAY ...)) followed by lots of (SETF (AREF *THE-DATA* ...) ) forms, but that looks strange. I'd like constant references into *THE-DATA* to be replaced by the appropriate values, if possible, but I'm really more interested in the read-only nature of the array itself. -------  Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 3 Oct 84 07:36:12 PDT Received: from umass-cs by csnet-relay.csnet id ax03131; 3 Oct 84 10:11 EDT Date: Wed, 3 Oct 84 08:26 EST From: Robert (LISPer 68K)Heller To: common-lisp%su-ai.arpa@csnet-relay.arpa Subject: Questions about OPEN I have some questions about what the function OPEN returns if :DIRECTION is :PROBE: 1) if the file exists, does OPEN return a closed stream? 2) if the file does not exist and :IF-DOES-NOT-EXIST is :CREATE, what does OPEN do? create an empty and return a closed stream? I realize that the second case is somewhat pathological, but I want to implement something reasonable for OPEN. The manual (published edition) is not very clear about just what OPEN does with a :DIRECTION of :PROBE. It just says that OPEN does not really open the file, just tests for its existence. Robert Heller Heller%UMass-CS@CSNet-Relay  Date: 30 Sep 84 1327 PDT From: Dick Gabriel Subject: Archives To: Common-lisp@SU-AI.ARPA The archives of Common Lisp mail is located on the directory [COM,LSP] at SAIL. SAIL is a nickname for SU-AI. COMMON.MSG[COM,LSP] ;July 28, 1983 - present COMMON.3[COM,LSP] ;May 17, 1983 - July 28, 1983 COMMON.2[COM,LSP] ;Oct 2, 1982 - May 17, 1983 COMMON.1[COM,LSP] ;Dec 30, 1981 - Oct 1, 1982 SUBGRP.CL[COM,LSP] ;index to Common Lisp subgroup mailing lists CLOBOR.MSG[COM,LSP] ;Object Oriented subgroup archives CLWIND.MSG[COM,LSP] ;Window subgroup archives CLITER.MSG[COM,LSP] ;Iteration subgroup archives CLGRAP.MSG[COM,LSP] ;Graphics subgroup archives CLFOFU.MSG[COM,LSP] ;Foreign Function Call subgroup archives CLSUBS.MSG[COM,LSP] ;Subsets subgroup archives CLVALI.MSG[COM,LSP] ;Validation subgroup archives CLCHRT.MSG[COM,LSP] ;Charter subgroup archives CLERHA.MSG[COM,LSP] ;Error Handling subgroup archives CLMULT.MSG[COM,LSP] ;Multiprocessing subgroup archives You can FTP these files away without logging in. Also you can type page ranges with the monitor command: TYPE COMMON.MSG[COM,LSP](23:34). Page 1 of each file is a directory of the rest of the file. To search or otherwise read these files, you can use our editor, called E. Perhaps you can use the SAIL display service to do this. Say HELP DISPLAY and HELP E to find out about these possibilities. Also, SAIL supports the SUPDUP protocol, and you can use E much as we do at SAIL in this mode. SAIL TELNET supports DataMedia display service. Say HELP TELNET to find out about these possibilties. -rpg-  Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 29 Sep 84 14:25:21 PDT Received: from CMU-CS-C.ARPA by SU-SCORE.ARPA with TCP; Sat 29 Sep 84 14:21:56-PDT Received: ID ; Sat 29 Sep 84 17:23:40-EDT Date: Sat, 29 Sep 1984 17:23 EDT Message-ID: Sender: FAHLMAN@CMU-CS-C.ARPA From: "Scott E. Fahlman" To: Rem@MIT-MC.ARPA Cc: COMMON-LISP%SU-AI@SU-SCORE.ARPA Subject: Questions about specification and possible implementations I've been a bit busy, but since nobody else has popped up to answer your questions, I'll take a crack at them. I'll try to distinguish between cases where I think the standard is clear and cases where there is ambiguity and I am offering my own opinion as to how the ambiguity should be resolved. ... some functions with all the &OPTIONAL and &KEY arguments may be difficult or inefficient to implement as true functions, and thus may be implemented as FEXPRs in the interpretor and MACROs in the compiler. I don't see why you think that such a change would make things easier or more efficient. The question is, what will (FUNCTION foo) do if foo is the name of a MACRO or FEXPR? I think "it is an error" to call FUNCTION on a symbol with no definition or whose definition is not a true function. Some implementations may just return whatever is in the SYMBOL-FUNCTION cell without checking, but such a value cannot be used in APPLY. It is not possible, in general, to create a true function that does what the MACRO or special form does. The book says the set of special forms is fixed and no way is provided to make new ones. But is any way provided to define some of the special forms from LISP level in the first place, or must all be handcoded in assembly language or C etc.? Is any way provided to install bugfixes in special forms by overlaying the old definition with a new one? There is no way in Common Lisp to create new special forms. It would have been quite easy to define such a mechanism, but we deliberately left such a mechanism out in the belief that having only a small, fixed set of special forms makes it much easier to write various kinds of program-manipulation tools. It was also felt that macros are an adequate substitute for new special forms. If you are implementing a Common Lisp, you are free to think up any internal mechanism you like for defining special forms at Lisp level. In our Spice Lisp implemenation, we use a version of the old FEXPR mechanism to define most of these things, but we do not make this available at user level. At the front of the chapter on numbers it claims: (LET ((X Z) (Y Z)) (EQ X Y)) may be false if the value of Z is a number. I can't see a mechanism for this in any reasonable LISP unless Z is not only presently a number but has been declared a number and this is compiled code which represents the value of Z as a machine number instead of a LISP object, whereas X and Y are undeclared and thus LISP objects, so new objects must be constructed for X and Y to hold the value Z, and these new objects won't be EQ to each other. But could somebody who really knows tell me what the true explanation is?? The book leaves this a complete mystery. I'm not able to parse that sentence (PDL overflow), but what we had in mind was the case where Z is defined in a defconstant to be, say, a number or a character. In this case, we want it to be legal to substitute that constant value for Z. Now, if the object is immediate, X and Y would be EQ, but if the object is consed you might end up with X and Y pointing to distinct structures that are not EQ but that are EQL. In the introductory chapter, the Common-LISP book says semicolon causes all characters up to eol to be discarded, but doesn't say whether eol is kept or discarded. All of these are answered quite clearly in the I/O chapter -- the discussion in the intro was not meant to be definitive. In this case, the EOL is discarded. Ditto, doesn't say which characters inside "" are automatically letterified and which have their usual semantic effects and thus need explicit letterification to be treated as string text. Only double-quote and the single-escape character (normally backslash) need to be backslashed in a string. Ditto, backslash at end of line does what? (Illegal, quote just the next character which may be half of a crlf on some systems, quote the eol token always?) Quotes the Newline character which is virtually there, regardless of the system's usual conventions. This is poor and confusing practice in most situations, however. Use #\newline. Ditto, vertical-bar, same questions as for "". Only the single and multiple escape characters, normally vbar and backslash, need to be quoted. When COPY-SYMBOL is done, the pnames will be the same, but will they be EQ or just EQUAL? This is not clear in the manual. In my opinion, this should be left up to the implementor. The new pname may or may not be EQ to the old one. The book doesn't say what (/ 1 0) does. Is it an error, or does it signal an error, or does it return the ratio of 1/0 as a way of representing infinity, or what? Certainly it "is an error" in portable common Lisp. I would expect every implementation to signal an overflow or divide-by-zero error unless it has actually implemented some sort of non-standard extension to handle infinities and infinitesimals. If NIL is an element of an assoc list, does this element get skipped over by ASSOC et al or is it a stop flag? Didn't you even try looking in the manual? As it says on page 279, NIL is allowed to be an element of an A-list and is simply passed over. How are the axis numbers of an array numbered, that is if you create an array by (MAKE-ARRAY 3 5 7) then will (ARRAY-DIMENSION array 0) return 3 or 7? This is not stated, but seems obvious. The numbering is left-to-right, 0 to whatever. So in this case the answer is 3. -- Scott  Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 25 Sep 84 12:41:44 PDT Received: ID ; Tue 25 Sep 84 15:40:46-EDT Date: Tue, 25 Sep 1984 15:40 EDT Message-ID: Sender: FAHLMAN@CMU-CS-C.ARPA From: "Scott E. Fahlman" To: common-lisp@SU-AI.ARPA Subject: Kyoto Common Lisp There has been some confusion, partly my fault, about whether the Kyoto University version of Common Lisp is based on our portable Spice Lisp code. I have just received a letter from Taiichi Yuasa of Kyoto University which makes clear that their implemenation is TOTALLY INDEPENDENT of our code. They did receive some early drafts of the manual, papers, and benchmark code from us (by way of Nippon Data General), but they did not receive any Lisp system code from us until several months AFTER their implemenation was finished and running. I just wanted to set the record straight. They apparently got this implementation running from a standing start in five months with a team of four people, with no direct input at all from the Common Lisp designers -- an awesome performance. To further clarify things, Data General has their own implemenation for the Eclipse. This is the one that was demonstrated at AAAI, and it IS based on our code, though the task of porting it to Data General hardware was done with essentially no help from CMU. -- Scott  Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 23 Sep 84 18:00:22 PDT Received: from IMSSS by Score with Pup; Sun 23 Sep 84 17:51:03-PDT Date: 23 Sep 1984 1752-PDT From: Rem@IMSSS Subject: Questions about specification and possible implementations To: COMMON-LISP%SU-AI@SCORE Here's a terse list of major questions I have about Common LISP, with motivation included in some cases. If any questions are interesting yet ambiguous, feel free to ask for more info. I tend to be too verbose with my netmail, so I'm trying to be terse here. In Common LISP there seems to be a strong dichotomy between functions (all arguments evaluated before call) and macros&SpecialForms, almost to the point of forbidding implementors to jump across the barrier. Yet some functions with all the &OPTIONAL and &KEY arguments may be difficult or inefficient to implement as true functions, and thus may be implemented as FEXPRs in the interpretor and MACROs in the compiler. The question is, what will (FUNCTION foo) do if foo is the name of a MACRO or FEXPR? It's supposed to be the functional interpretation of foo, so does it make up a function that calls the MACRO or FEXPR even though inefficient, or does it totally break down because there's no functional interpretation for a MACRO or FEXPR? If (FUNCTION foo) does work, is the result suitable for passing to APPLY or MAP and does it have the expected semantics as if were really a function in the first place? The book says the set of special forms is fixed and no way is provided to make new ones. But is any way provided to define some of the special forms from LISP level in the first place, or must all be handcoded in assembly language or C etc.? Is any way provided to install bugfixes in special forms by overlaying the old definition with a new one? At the front of the chapter on numbers it claims: (LET ((X Z) (Y Z)) (EQ X Y)) may be false if the value of Z is a number. I can't see a mechanism for this in any reasonable LISP unless Z is not only presently a number but has been declared a number and this is compiled code which represents the value of Z as a machine number instead of a LISP object, whereas X and Y are undeclared and thus LISP objects, so new objects must be constructed for X and Y to hold the value Z, and these new objects won't be EQ to each other. But could somebody who really knows tell me what the true explanation is?? The book leaves this a complete mystery. Minor questions: In the introductory chapter, the Common-LISP book says semicolon causes all characters up to eol to be discarded, but doesn't say whether eol is kept or discarded. Ditto, doesn't say which characters inside "" are automatically letterified and which have their usual semantic effects and thus need explicit letterification to be treated as string text. Ditto, backslash at end of line does what? (Illegal, quote just the next character which may be half of a crlf on some systems, quote the eol token always?) Ditto, vertical-bar, same questions as for "". (If above questions are answered elsewhere in manual, need pointer from intro to where info given?) When COPY-SYMBOL is done, the pnames will be the same, but will they be EQ or just EQUAL? The book doesn't say what (/ 1 0) does. Is it an error, or does it signal an error, or does it return the ratio of 1/0 as a way of representing infinity, or what? If NIL is an element of an assoc list, does this element get skipped over by ASSOC et al or is it a stop flag? How are the axis numbers of an array numbered, that is if you create an array by (MAKE-ARRAY 3 5 7) then will (ARRAY-DIMENSION array 0) return 3 or 7? -------  Date: 23 Sep 84 1647 PDT From: Dick Gabriel Subject: Working Groups To: common-lisp@SU-AI.ARPA At the Monterey Common Lisp Meeting a number of working groups were established. They are considering the following topics: Object-Oriented Programming Windows Error handling Iteration Graphics Foreign Function-Call Subsets Validation Charter Multiprocessing The Charter working group is to establish the rules for making extensions to Common Lisp. That is, this group will propose the bureaucratic structure of Common Lisp for the future. If you have already received an `Introduction' letter for one of these subgroups, then you are already in that subgroup. If you did not and believe you ought to be, please send mail to RPG@SAIL. Also, you should let me know about any other interested parties who are not already on the COMMON-LISP mailing list. Later I will be splitting the COMMON-LISP mailing list into a discussion list and an implementation list. You should tell on which of these you would like to be. The discussion list is primarily for users and random discussion, and the implementation list is for implementors and other interested parties to discuss issues. -rpg-  Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 23 Sep 84 08:15:57 PDT Received: ID ; Sun 23 Sep 84 11:16:10-EDT Date: Sun, 23 Sep 1984 11:16 EDT Message-ID: Sender: FAHLMAN@CMU-CS-C.ARPA From: "Scott E. Fahlman" To: Rem%IMSSS@SU-SCORE.ARPA Cc: COMMON-LISP@SU-AI.ARPA Subject: Common-LISP book questions and errors? In-reply-to: Msg of 23 Sep 1984 00:34-EDT from Rem at IMSSS Right now, Common Lisp at SU-AI is indeed the proper mailing list for implemenation questions. Sometime soon, we plan to split this into separate lists for designers/implementors and for the user community. We also plan very soon to set up an online file where previously-answered questions and their answers (plus any discussion) will live, as well as a file containing all the current differences between the manual and TRUTH. This stuff will be announced on Common Lisp when it is ready. In general, any questions should be sent to the whole mailing list, since such issues are likely to be of interest to the whole community, and any answer received privately from just one individual will not be reliable or official. Of course, if the issue is merely a typo in the manual with no semantic content, mail to STEELE@CMU-CS-C will suffice. -- Scott  Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 23 Sep 84 05:02:49 PDT Received: ID ; Sun 23 Sep 84 08:03:39-EDT Date: Sun, 23 Sep 1984 08:03 EDT Message-ID: From: Rob MacLachlan To: AS%hplabs.csnet@CSNET-RELAY.ARPA Cc: AS@CSNET-RELAY.ARPA, Common-Lisp@SU-AI.ARPA Subject: more questions In-reply-to: Msg of 20 Sep 1984 18:51-EDT from AS%hplabs.csnet at csnet-relay.arpa Date: Thursday, 20 September 1984 18:51-EDT From: AS%hplabs.csnet at csnet-relay.arpa To: Common-Lisp at su-ai.arpa cc: AS at csnet-relay.arpa Re: more questions I have not been able to find (clear) answers to these questions in the manual. Clarification is requested. * What happens if the type name in a DEFTYPE or DEFSTRUCT is the name of an existing type (either primitive or user-defined)? Is redefinition allowed or prohibited, and in what circumstances? * What happens in a DEFSTRUCT if two slots have the same name? Is it an error, or is the extra slot definition ignored? * What happens in a DEFSTRUCT if a slot has the same name as an inherited slot? Is it an error, is the new slot definition ignored, are the two slot definitions "merged", or does the new slot "shadow" the inherited one? I would say that except for redefining a DEFTYPE with another DEFTYPE, all of these should be errors. Permitting any of these things would add complexity without adding any power. * The definition of *PRINT-CIRCLE* only says that the printer "will endeavor" to detect cycles. How hard must the printer try? Is an implementation that totally ignores *PRINT-CIRCLE* correct? * Are cycles involving structures (DEFSTRUCTs) handled by *PRINT-CIRCLE*? If so, how do DEFSTRUCT :print-functions interact with *PRINT-CIRCLE*? It is clearly possible, and not even very difficult, to detect cycles, thus I see not reason why the printer shouldn't do it. All you have to do is enter every object printed in a hashtable, clearing the hashtable at every top-level call to Print. Structure print functions add no substantial degree of complexity to this. Print simply needs to detect when it has been called from a print function, and not clear the hashtable in that case. Of course if the print-function itself breaks due to circularity in the structure, there is nothing that can be done. * May an implementation impose a fixed upper bound on the length of a symbol name? If so, is there a minimum such bound? Similar questions can be asked regarding the sizes of strings, vectors, and arrays, and the possible interrelationships among such limits. (It is important to make our assumptions explicit, as an implementor whose background is in conventional programming languages might not share these assumptions. Ideally, I would say that no fixed limit other than available free storage can be placed on any of these sizes.) There is Array-Total-Size-Limit, whose minimum value is 1024. Most likely, the real limit on total size will be different for different types of arrays, but this limit should be the minimum. Since for symbol functions no type specification is given for the pname other than that is a string, then any legal string must work. This would mean that the least limit on pname length would be 1024. * Must (EQ (SYMBOL-NAME 'FOO) (SYMBOL-NAME 'FOO)) be true, or may the function SYMBOL-NAME return a newly created copy of the name string each time it is called? (My reading of the definition is that there is a unique print name string for each symbol and that SYMBOL-NAME returns it; others have come to a different conclusion.) I would say that this should be left up to the implementation, since requiring this would constrain the implementor without buying any power. * DEFSTRUCT does not create named functions for altering components of a structure, but instead arranges to make SETF do "the right thing". Does this mean that the user cannot TRACE structure alteration or control the use of inline code for structure alteration (which might affect how the debugger describes the state of a computation)? (The general question: is not having named update functions for generalized variables really such a good idea?) I would say that it is currently clearly the case that setf methods cannot be traced. If function specifications are added to the language, then they could be used to fix this problem. Since a setf method has in the general case the semantics of a macro, it doesn't seem possible to declare a setf method not inline. Rob  Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 22 Sep 84 21:35:05 PDT Received: from IMSSS by Score with Pup; Sat 22 Sep 84 21:32:19-PDT Date: 22 Sep 1984 2134-PDT From: Rem@IMSSS Subject: Common-LISP book questions and errors? To: COMMON-LISP%SU-AI@SCORE I'm working on a project that might start implementing Common-LISP soon. I have a number of questions and some errata from the Common-LISP book. Is this the correct mailing list for such matters? Is there a database of already-answered questions and already-found errata that I should consult to avoid duplication? Are there individuals I should ask certain kinds of questions to and report errata to instead of dumping them on this whole mailing list, or should everything be reported to the whole mailing list so that everybody gets to see everything? Replies to REM%IMSSS@SCORE.ARPA or if that doesn't work then REM@MIT-MC.ARPA or REM@SU-AI.ARPA (or if you happen to be on SCORE or IMSSS you can use REM@IMSSS or just REM respectively) -- when name domains are implemented this may be simpler. -------  Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 22 Sep 84 16:57:15 PDT Received: From hplabs.csnet by csnet-relay; 22 Sep 84 19:37 EDT Received: by HP-VENUS id AA27329; Thu, 20 Sep 84 15:51:02 pdt Message-Id: <8409202251.AA27329@HP-VENUS> Date: 20 Sep 1984 1551-PDT From: AS%hplabs.csnet@csnet-relay.arpa Subject: more questions To: Common-Lisp@su-ai.arpa Cc: AS@csnet-relay.arpa Source-Info: From (or Sender) name not authenticated. I have not been able to find (clear) answers to these questions in the manual. Clarification is requested. * What happens if the type name in a DEFTYPE or DEFSTRUCT is the name of an existing type (either primitive or user-defined)? Is redefinition allowed or prohibited, and in what circumstances? * What happens in a DEFSTRUCT if two slots have the same name? Is it an error, or is the extra slot definition ignored? * What happens in a DEFSTRUCT if a slot has the same name as an inherited slot? Is it an error, is the new slot definition ignored, are the two slot definitions "merged", or does the new slot "shadow" the inherited one? * The definition of *PRINT-CIRCLE* only says that the printer "will endeavor" to detect cycles. How hard must the printer try? Is an implementation that totally ignores *PRINT-CIRCLE* correct? * Are cycles involving structures (DEFSTRUCTs) handled by *PRINT-CIRCLE*? If so, how do DEFSTRUCT :print-functions interact with *PRINT-CIRCLE*? * May an implementation impose a fixed upper bound on the length of a symbol name? If so, is there a minimum such bound? Similar questions can be asked regarding the sizes of strings, vectors, and arrays, and the possible interrelationships among such limits. (It is important to make our assumptions explicit, as an implementor whose background is in conventional programming languages might not share these assumptions. Ideally, I would say that no fixed limit other than available free storage can be placed on any of these sizes.) * Must (EQ (SYMBOL-NAME 'FOO) (SYMBOL-NAME 'FOO)) be true, or may the function SYMBOL-NAME return a newly created copy of the name string each time it is called? (My reading of the definition is that there is a unique print name string for each symbol and that SYMBOL-NAME returns it; others have come to a different conclusion.) * DEFSTRUCT does not create named functions for altering components of a structure, but instead arranges to make SETF do "the right thing". Does this mean that the user cannot TRACE structure alteration or control the use of inline code for structure alteration (which might affect how the debugger describes the state of a computation)? (The general question: is not having named update functions for generalized variables really such a good idea?) Alan Snyder snyder%hplabs@csnet-relay -------  Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 20 Sep 84 11:13:52 PDT Received: ID ; Thu 20 Sep 84 14:12:44-EDT Date: Thu, 20 Sep 1984 14:12 EDT Message-ID: Sender: WHOLEY@CMU-CS-C.ARPA From: Skef Wholey To: Common-Lisp@SU-AI.ARPA Subject: Sorry... Oops, I saw Common Lisp songs flying by on Info-Cobol, but sent mine to the Common-Lisp mailing list by mistake. Freudian slip indeed. Sorry to take such time on a ultra-high-bandwidth, very serious language-design forum.  Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 20 Sep 84 10:57:07 PDT Received: ID ; Thu 20 Sep 84 13:55:57-EDT Date: Thu, 20 Sep 1984 13:55 EDT Message-ID: Sender: WHOLEY@CMU-CS-C.ARPA From: Skef Wholey To: Common-Lisp@SU-AI.ARPA Subject: As long as we're sending out songs... Common LISP (to the tune of Dylan's "Maggie's Farm") I ain't gonna hack on Common LISP no more, I ain't gonna hack on Common LISP no more. See, it was spawned from MACLISP, And then they threw in Scheme, And now everybody's made it "just a little" short of clean. The language specification is insane. I ain't gonna hack on Guy Steele's LISP no more, I ain't gonna hack on Guy Steele's LISP no more. When you mail him a question, And then wait for a reply, Well you can sit for weeks now, And begin to think he's died. His MAIL.TXT is one great big black hole. I ain't gonna hack on Fahlman's LISP no more, I ain't gonna hack on Fahlman's LISP no more. Well he gives you an X-1, [1] And he puts you on a Perq, And he asks you with a grin, "Hey son, how much can you work?" If I reboot one more time I'll lose my brain. I ain't gonna hack on Dave Moon's LISP no more, I ain't gonna hack on Dave Moon's LISP no more. We had a simple SETF, But it choked on LDB. So Lunar Dave done fixed it: Go look at page eighty three. [2] The Gang of Five they didn't take a poll. [3] I ain't gonna hack on Common LISP no more, I ain't gonna hack on Common LISP no more. With its tons of sequence functions, And its lexical scoping, I've now begun to like it, But the users are moping: "Without EXPLODE my life is full of pain." [4] (harmonica and fade) ------------------------------------------------------------------------------- Notes: 1. An "X-1" is the key required to access CMU CSD facilities. 2. 83 was the page number describing Define-Setf-Method in the Mary Poppins edition. It's probably changed. 3. There aren't verses for Weinreb and Gabriel because the orginal song has only 3 verses about people. I couldn't think of anything clever to say about them, anyway. 4. Yes, we really had users complaining about the lack of EXPLODE and friends. No offense is intended towards any people named or unnamed.  Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 18 Sep 84 10:43:49 PDT Received: from SCRC-HARLEM by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 92685; Tue 18-Sep-84 09:33:05-EDT Date: Monday, 10 September 1984, 17:11-EDT From: Postmaster at SCRC-QUABBIN Subject: Unable to deliver letter To: Moon at SCRC-QUABBIN Resent-To: "common-lisp@su-ai"@MIT-MC.ARPA Resent-From: joseph@SCRC-QUABBIN.ARPA Resent-Date: Tue, 18 Sep 84 09:32 EDT Resent-Message-ID: <840918093215.9.JOSEPH@HARLEM.SCRC.Symbolics> Unable to deliver letter to the following recipient: Common-Lisp at SU-AI: Host not responding. ----- Text of letter follows ----- Received: from SCRC-EUPHRATES by SCRC-QUABBIN via CHAOS with CHAOS-MAIL id 79561; Fri 7-Sep-84 16:17:53-EDT Date: Fri, 7 Sep 84 16:18 EDT From: "David A. Moon" Subject: Sequence function predicate arg order To: "Bernard S. Greenberg" cc: Common-Lisp@SU-AI.ARPA, bug-clcp@SCRC-STONY-BROOK.ARPA, dla@SCRC-STONY-BROOK.ARPA In-Reply-To: <840907153454.7.BSG@CONCORD.SCRC.Symbolics> Message-ID: <840907161802.5.MOON@EUPHRATES.SCRC.Symbolics> Date: Friday, 7 September 1984, 15:34-EDT From: Bernard S. Greenberg The following issue was encountered today by David Andre. He wanted to find the position of first element in a string which was not an element of a list he had in hand.... Possible outcomes: 1. Magic keyword to sequence functions to reverse test arg order? ECCH! 2. More string-specific primitives. 3. Maybe he should have said :test #'(lambda (x y)(member y x)). Among your alternatives, I'd prefer #3, i.e. write (position list sequence :test-not #'(lambda (x y) (member y x))) I would actually write (position-if-not #'(lambda (item) (member item list)) sequence)  Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 15 Sep 84 16:32:58 PDT Received: ID ; Sat 15 Sep 84 19:30:59-EDT Date: Sat, 15 Sep 1984 19:30 EDT Message-ID: Sender: FAHLMAN@CMU-CS-C.ARPA From: "Scott E. Fahlman" To: fateman%ucbdali@Berkeley (Richard Fateman) Cc: common-lisp@SU-AI.ARPA Subject: several questions, some trivial In-reply-to: Msg of 14 Sep 1984 12:40-EDT from fateman%ucbdali at Berkeley (Richard Fateman) If we look at Maclisp with (declare (special t)), is it not the case that (nearly) identical semantics are used for the interpreter and compiler, given CORRECT programs? Sure, there are lots of special cases in which Maclisp's interpreted behavior matches its compiled behavior. The point is that few users want all of their variables to be special and that a LOT of Maclisp programs break when you compile them because of the different treatment of special and local variables. In Common Lisp, this big difference between compiled and interpreted code goes away, along with some lesser problems. That's what's being touted. I don't think this clean-up is of revolutionary importance, but it certainly eliminates a long-standing embarassment and a source of considerable confusion for new users. If people are touting this as a great advance in the theory and practice of programming, then they're guilty of exaggeration, but it is one small thing that Common Lisp does better than most earlier Lisps. Since most programs are, for most of their lives, "incorrect", aren't we open to the accusation of missing the main point here? I disagree with your premise. Most of my programs, for most of their lives, are correct, at least if by program you mean "Lisp function". Obviously, any sufficiently large system will have a couple of bugs in it somewhere, even after it is tested and released, but the point is that compilation does not normally change the program's behavior except at these few points, and probably only at a small minority of those. The new thing is that we have made it an explicit goal of the language design (though not the only goal) that compilation should not change behavior, and we have made a serious attempt to fulfill this goal. In particular, we eliminated the single largest violation of this principle that is present in most earlier Lisps. As you say, a user can still screw himself by doing really perverse things like redefining CAR at runtime, but I don't think I've ever seen a user screw himself by accident when he compiled a Common Lisp program, and this used to happen all the time in Maclisp and Franzlisp. -- Scott  Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 15 Sep 84 15:57:20 PDT Received: ID ; Sat 15 Sep 84 18:54:30-EDT Date: Sat, 15 Sep 1984 18:54 EDT Message-ID: Sender: FAHLMAN@CMU-CS-C.ARPA From: "Scott E. Fahlman" To: "Daniel L. Weinreb" , common-lisp@SU-AI.ARPA Subject: External symbols and inheritance If package A uses package B, and package B exports the symbol FOO, then is a reference to A:FOO supposed to get that symbol, or be an error? I agree with Rob Maclachlan on this: the symbol FOO is internal in package A, so A:FOO is an error. This behavior is clearly prescribed by the last full paragraph on page 177 of the manual, is it not? Or have we misunderstood your question? -- Scott  Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 14 Sep 84 16:34:40 PDT Received: ID ; Fri 14 Sep 84 19:31:43-EDT Date: Fri, 14 Sep 1984 19:31 EDT Message-ID: From: Rob MacLachlan To: "Daniel L. Weinreb" Cc: common-lisp@SU-AI.ARPA Subject: External symbols and inheritance In-reply-to: Msg of 14 Sep 1984 16:14-EDT from Daniel L. Weinreb It seems fairly clear to me that it is an error. The single-colon notation referrs to an external symbol in the named package. Use-Package makes the external symbols of the used package available as internal symbols. Externalness is a property of how the symbol is available in the package rather than an inherent attribute of the symbol. The semantics of the package system are fairly straightforward when thought of in terms of the obvious implementation of maintaining separate hashtables for each package and searching used packages to find inherited symbols. This implementation seems to be working quite well for Spice Lisp, and I would suggest that implementors try it to see whether Intern is a performance bottleneck before attempting a "better" algorithm. Rob  Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 14 Sep 84 13:13:05 PDT Received: from SCRC-CHICOPEE by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 91319; Fri 14-Sep-84 16:15:07-EDT Date: Fri, 14 Sep 84 16:14 EDT From: "Daniel L. Weinreb" Subject: External symbols and inheritance To: common-lisp@SU-AI.ARPA Message-ID: <840914161436.7.DLW@CHICOPEE.SCRC.Symbolics> If package A uses package B, and package B exports the symbol FOO, then is a reference to A:FOO supposed to get that symbol, or be an error?  Received: from UCB-VAX.ARPA by SU-AI.ARPA with TCP; 14 Sep 84 13:15:05 PDT Received: from ucbdali.ARPA by UCB-VAX.ARPA (4.24/4.31) id AA22328; Fri, 14 Sep 84 09:40:08 pdt Received: by ucbdali.ARPA (4.24/4.38) id AA08645; Fri, 14 Sep 84 09:40:12 pdt Date: Fri, 14 Sep 84 09:40:12 pdt From: fateman%ucbdali@Berkeley (Richard Fateman) Message-Id: <8409141640.AA08645@ucbdali.ARPA> To: common-lisp@su-ai Subject: several questions, some trivial Missing from the index of the CL manual: "argument" "rest" as in "&rest" and &others The issue of identical semantics for compiled and interpreted programs has been touted as an important step forward. If I understand the manual, (nearly) identical semantics pertain to CORRECT programs only. If there are declarations, those too must be CORRECT declarations. If we look at Maclisp with (declare (special t)), is it not the case that (nearly) identical semantics are used for the interpreter and compiler, given CORRECT programs? In Maclisp, if there are declarations which are correct, are not the semantics still (nearly) identical? (I suppose "nearly" because one could write self-modifying functions and other monstrosities in CL or Maclisp.) Since most programs are, for most of their lives, "incorrect", aren't we open to the accusation of missing the main point here? Leaving car of an atom as undefined (e.g.) means that compiled and interpreted versions of the same program can do different things. This can be just as subtle as dynamic/lexical binding.  Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 13 Sep 84 18:25:33 PDT Received: from SCRC-EUPHRATES by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 88224; Tue 11-Sep-84 12:54:12-EDT Redistributed-date: Tue, 11 Sep 84 12:53 EDT Redistributed-to: Common-Lisp@SU-AI.ARPA Date: Fri, 7 Sep 84 16:18 EDT From: Moon@SCRC-STONY-BROOK.ARPA Subject: Sequence function predicate arg order To: BSG@SCRC-STONY-BROOK.ARPA cc: Common-Lisp@SU-AI.ARPA, bug-clcp@SCRC-STONY-BROOK.ARPA, dla@SCRC-STONY-BROOK.ARPA In-Reply-To: <840907153454.7.BSG@CONCORD.SCRC.Symbolics> Message-ID: <840907161802.5.MOON@EUPHRATES.SCRC.Symbolics> Date: Friday, 7 September 1984, 15:34-EDT From: Bernard S. Greenberg The following issue was encountered today by David Andre. He wanted to find the position of first element in a string which was not an element of a list he had in hand.... Possible outcomes: 1. Magic keyword to sequence functions to reverse test arg order? ECCH! 2. More string-specific primitives. 3. Maybe he should have said :test #'(lambda (x y)(member y x)). Among your alternatives, I'd prefer #3, i.e. write (position list sequence :test-not #'(lambda (x y) (member y x))) I would actually write (position-if-not #'(lambda (item) (member item list)) sequence)  Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 13 Sep 84 18:22:27 PDT Received: from SCRC-CONCORD by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 88063; Tue 11-Sep-84 09:16:39-EDT Date: Tue, 11 Sep 84 09:18 EDT From: "Bernard S. Greenberg" Subject: Sequence function predicate arg order To: Common-Lisp@SU-AI.ARPA Supersedes: <840907153454.7.BSG@CONCORD.SCRC.Symbolics> Message-ID: <840911091813.0.BSG@CONCORD.SCRC.Symbolics> Our mailer just returned this as never having gotten to COMMON-LISP. I don't know if Moon's reply made it either: ----------- The following issue was encountered today by David Andre. He wanted to find the position of first element in a string which was not an element of a list he had in hand. This is Zetalisp's STRING-SEARCH-NOT-SET. The generic sequence searcher in Common Lisp, the only one that exist, is POSITION. POSITION item sequence &key :test-not ..... So he would have given #'MEMBER as :test-not, except that the language specifies that MEMBER will be called on arguments in the order of the representing objects in the original argument list, which is wrong for this application. The strict definition of argument order for tests of :test/:test-not is of course necessary for these functions to be useful with non-symmetric tests. Unfortunately, some tests cannot thus be used. Oops. Possible outcomes: 1. Magic keyword to sequence functions to reverse test arg order? ECCH! 2. More string-specific primitives. 3. Maybe he should have said :test #'(lambda (x y)(member y x)).  Received: from TL-20A.ARPA by SU-AI.ARPA with TCP; 13 Sep 84 10:35:08 PDT Received: ID ; Thu 13 Sep 84 13:37:57-EDT Date: Thu 13 Sep 84 13:37:51-EDT From: STEELE@TL-20A.ARPA To: common-lisp@SU-AI.ARPA The definitions of characters and strings in Common Lisp assume the English language and lexicographic ordering. Do you contemplate any changes to the definition to allow it to work better with other natural languages? Are you aware of any Lisp implementations which have addressed this issue? Thanks, Kathy Kwinn There are three issues I can think of here offhand. One is that certain alphabets contain extra (or different) letters, such as the Scandinavian slashed-O and AE ligature. Common LISP allows an implementation to extend the character set, and some of the extra characters may be alphabetic. Such extra characters may be of type string-char as well. So these should fit in nicely with the current definitions of such functions and alpha-char-p and string-capitalize. The primary difficulty here is that if one uses the standard ASCII code national variants, these extra letters use ASCII codes normally used in America for "[", "]", and so on, which are required standard Common LISP characters. The second issue is accents, such as the accents acute and grave, the circumflex, the cedilla, the umlaut, and so on. These cause difficulties no matter how you look at it, especially in string-capitalize, and Common LISP currently does not address these at all. (As noted in the manual, these cause problems in English, too: (string-capitalize "don't") => "Don'T", not "Don't".) The third issue is lexicographic ordering. The Common LISP ordering is actually relatively loose. I believe that lexicographic ordering for European languages is already difficult even using ASCII because of accents, extra letters, and special rules (such as "ch" being considered a single letter for ordering purposes in Spanish dictionaries). Common LISP does not solve these problems, but is no worse than existing practice. --Guy -------  Received: from CMU-CS-A.ARPA by SU-AI.ARPA with TCP; 12 Sep 84 23:08:58 PDT Date: 13 Sep 84 0159 EDT (Thursday) From: Guy.Steele@CMU-CS-A.ARPA To: common-lisp@SU-AI.ARPA Subject: German -> English translator wanted Herbert Stoyan has written a textbook on LISP in German, and would like to know whether anyone out there would be interested in undertaking a translation to English for publication. --Guy  Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 12 Sep 84 08:23:20 PDT Received: from SCRC-EUPHRATES by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 87488; Mon 10-Sep-84 14:35:22-EDT Date: Mon, 10 Sep 84 14:35 EDT From: "David A. Moon" Subject: [Postmaster at SCRC-STONY-BROOK: Unable to deliver letter] To: Common-Lisp@SU-AI.ARPA Message-ID: <840910143505.4.MOON@EUPHRATES.SCRC.Symbolics> No one but KMP saw this message the first time, which may have made for a mysterious-looking conversation. Hopefully it will go through this time. Date: Thu, 6 Sep 84 22:36 EDT From: "David A. Moon" Subject: More (unrelated) EVALHOOK issues To: Kent M Pitman cc: Common-Lisp@SU-AI.ARPA In-Reply-To: The message of 6 Sep 84 18:16-EDT from Kent M Pitman Message-ID: <840906223648.7.MOON@EUPHRATES.SCRC.Symbolics> Date: 6 September 1984 18:16-EDT From: Kent M Pitman While I'm thinking about it (something I should have brought up ages ago, but it might as well at least be on the books)... There's a problem with EVALHOOK in that it really wants to pass a locative to the piece of code that's being EVAL'd. Consider the problem of a display-oriented stepper, trying to evaluate: (LAMBDA (X) (+ X X)) when EVALHOOK traps on evaluating X, how can you know which X you are evaluating so as to highlight it. If you think it's fair to assume that the lexically first X is the one that leads you there, consider: (LAMBDA (X Y) (COND ((FOO) X) (T (+ X Y)))) It would have been nice if we had made it so the form passed in was a list whose CAR was the form to be evaluated rather than the form itself. That way, in the first example above, EVALHOOK could see (X X) and in the second, (X). Or perhaps that could be passed in as an extra arg, being NIL when there was no locative available. This shortcoming in the info provided by EVALHOOK has come up in several stepper projects at MIT, and I should have mentioned it before, but it should be thought about when time for revisions comes along. I don't see why the user hook function can't maintain its own evaluation stack, back which it can look. In general, of course, this requires it to understand special forms. Your scheme, on the other hand, would require EVAL to be completely remodularized, since it does not currently receive the arguments it would need to compute the information you want in any system I know of.  Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 10 Sep 84 00:23:33 PDT Date: 10 September 1984 03:24-EDT From: Glenn S. Burke Subject: applyhook and environments To: Common-Lisp @ SU-AI I think we've safely established that in order to just function properly, APPLYHOOK (and therefore the value of *APPLYHOOK*) does not need to be given an environment argument. As someone said, it makes no sense to pass one environment because there are two involved. To me, that means we should pass BOTH environments. After all, one of the purposes of having this is for debugging, from user code. If we did not want this we wouldn't have defined the hooks, just specified the existence of STEP like we have TRACE. *APPLYHOOK* should be given TWO environments: one is the current environment (as of when the hook is invoked -- like that given to *evalhook*). The other is an environment object gleaned from the function being applied. This is so that *applyhook* can examine either one. Possibly in the case of compiled or globally defined functions, the function-environment argument will be NIL, of course. So, what i propose is this: *APPLYHOOK* gets called on 4 arguments: (1) the function being applied (2) the list of arguments (3) the environment of the function (4) the current environment. APPLYHOOK takes only arguments of the function, arguments, evalhookfn, and applyhookfn. No environment argument at all -- the function carries the environment with it. Evaluation of a lambda combination ((lambda ...) ...) passes a function made (as if) by evaluating (function (lambda ...)). The function-environment argument to *applyhook* is deliberately redundant with the environment carried by the function, so that it may be an environment object just like the current-environment argument, and thus examined/whatever similarly. I feel fairly strongly that to not pass these environments to *applyhook* just because it looks now like we can get away with it will unnecessarily restrict any sort of debugging extensions in the future. And even within the present CL definition user code can do things with them by passing them to EVAL.  Received: from DEC-MARLBORO.ARPA by SU-AI.ARPA with TCP; 7 Sep 84 15:58:18 PDT Date: Fri 7 Sep 84 19:00:15-EDT From: "Walter van Roggen" Subject: Re: applyhook To: KMP@MIT-MC.ARPA cc: common-lisp@SU-AI.ARPA, WVANROGGEN@DEC-MARLBORO.ARPA In-Reply-To: Message from "Kent M Pitman " of Thu 6 Sep 84 18:10:00-EDT Actually, I hadn't thought about the potential ambiguity of which environment would be passed to the apply hook function; I had just assumed that it would be the same as that passed to the eval hook function immediately before. It seems to me that the purpose of applyhook is to allow one to examine the actual function and the actual arguments it's about to be applied to. (I suppose you could get the effect of the applyhook by using the evalhook and simulating the evaluator--but that's what this mechanism should help avoid.) It's a lot easier to examine the environment of the function when it is handed to you. On the other hand you could argue that any debugging facility will always use both evalhook and applyhook simultaneously, but that shouldn't be necessary. ---Walter -------  Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 7 Sep 84 13:38:50 PDT Date: 7 September 1984 16:35-EDT From: Kent M Pitman Subject: EVALHOOK maintaining independent evaluation stacks To: Moon @ SCRC-STONY-BROOK cc: Common-Lisp @ SU-AI References: Msg of of 6 Sep 84 18:16-EDT from Kent M Pitman In-Reply-To: <840906223648.7.MOON@EUPHRATES.SCRC.Symbolics> Date: Thu, 6 Sep 84 22:36 EDT From: David A. Moon Date: 6 September 1984 18:16-EDT From: Kent M Pitman While I'm thinking about it ... There's a problem with EVALHOOK in that it really wants to pass a locative to the piece of code that's being EVAL'd. Consider the problem of a display-oriented stepper, trying to evaluate: (LAMBDA (X) (+ X X)) ... If you think it's fair to assume that the lexically first X is the one that leads you there, consider: (LAMBDA (X Y) (COND ((FOO) X) (T (+ X Y)))) I don't see why the user hook function can't maintain its own evaluation stack, back which it can look. In general, of course, this requires it to understand special forms. Your scheme, on the other hand, would require EVAL to be completely remodularized, since it does not currently receive the arguments it would need to compute the information you want in any system I know of. In order to do this correctly, you must presuppose the complete semantics of the interpreter. You might as well write your own DEBUG-EVAL which doesn't use EVAL at all. Part of the idea of EVALHOOK is to let EVAL do what it wants (handling hard cases, etc) and leave the relevant (and incidentally much easier) stuff to the hook. Without understanding making all these assumptions, an evaluation history isn't going to tell you what X is being evaluated after the throw in: (BAR (*CATCH 'FOO (FOO (*THROW 'FOO NIL) X (FROB X))) X) In order to know that, you'd have to know about the semantics of catch/throw in a relatively intimate way. Similarly, you might get faked out by which X was being evaluated after the call to EVAL in (PROGN (EVAL '(+ X 3)) X) though APPLYHOOK might give you enough of a handle to get around this one. I'm not sure. Page 322 of the CL manual suggests that APPLYHOOK wouldn't help in the case of: (PROGN (MAPCAR #'EVAL '((+ X 3))) X) By the way, it does not affect my argument that the two X's in question are not in the same lexical contour. If anything, it strengthens the importance of the argument. Even in this example (from my last message), where we've just EVAL'd (FOO): (COND ((FOO) X Y) (T X)), you cannot which X is going to be evaluated without building into your EVALHOOK an assumption about what COND does. Does this help? I really believe that an explicit stack maintained by EVALHOOK doesn't work, or that the work involved in coercing it work is at least as great and probably more dangerous (in terms of being potentially wrong) than that of just writing another evaluator. We tried that and it fails in tricky code. Tricky code, by the way, is the sort of thing you most need steppers to work on, I might add. In heavily macrofied code, you can really get cases of throws out of arg positions, etc. that are completely meaningful and I think not unreasonable to want to support. -kmp  Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 7 Sep 84 11:04:48 PDT Received: ID ; Fri 7 Sep 84 14:03:51-EDT Date: Fri, 7 Sep 1984 14:03 EDT Message-ID: Sender: FAHLMAN@CMU-CS-C.ARPA From: "Scott E. Fahlman" To: Carl Hoffman Cc: Common-Lisp@SU-AI.ARPA Subject: &whole In-reply-to: Msg of 6 Sep 1984 22:23-EDT from Carl Hoffman I'm sure I've found times when not having the error-checking has been useful. For instance, suppose I have a long (or circular) list of triples. I might want to destructure the first two entries of that list like so. (DO () (NIL) (DESTRUCTURING-BIND ((A1 B1 C1) (A2 B2 C2)) LIST ...) (SETQ LIST (CDDR LIST))) But you can inhibit the error checking by putting an "&rest ignore" in there, and then you don't have to make a special non-error checking version. Isn't this exactly analogous to the discussion we just had about &whole ? -- Scott  Received: from USC-ISIB.ARPA by SU-AI.ARPA with TCP; 6 Sep 84 22:58:18 PDT Date: 6 Sep 1984 22:56:05 PDT Subject: Re: More (unrelated) EVALHOOK issues From: Dave Dyer To: Kent M Pitman cc: common-lisp@SU-AI.ARPA In-Reply-To: (Message from "Kent M Pitman " of 6 September 1984 18:16-EDT) I agree that this is a lack in EVALHOOK, but the same also occurs in debugging generally. The problem is that not enough state of the interpreter is available to analysis/error handling tools, of which an EVALHOOK routine is a good example. In Interlisp, this isn't a problem because the temporaries of the interpreter are explicitly available. -------  Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 6 Sep 84 15:16:23 PDT Date: 6 September 1984 18:16-EDT From: Kent M Pitman Subject: More (unrelated) EVALHOOK issues To: Common-Lisp @ SU-AI While I'm thinking about it (something I should have brought up ages ago, but it might as well at least be on the books)... There's a problem with EVALHOOK in that it really wants to pass a locative to the piece of code that's being EVAL'd. Consider the problem of a display-oriented stepper, trying to evaluate: (LAMBDA (X) (+ X X)) when EVALHOOK traps on evaluating X, how can you know which X you are evaluating so as to highlight it. If you think it's fair to assume that the lexically first X is the one that leads you there, consider: (LAMBDA (X Y) (COND ((FOO) X) (T (+ X Y)))) It would have been nice if we had made it so the form passed in was a list whose CAR was the form to be evaluated rather than the form itself. That way, in the first example above, EVALHOOK could see (X X) and in the second, (X). Or perhaps that could be passed in as an extra arg, being NIL when there was no locative available. This shortcoming in the info provided by EVALHOOK has come up in several stepper projects at MIT, and I should have mentioned it before, but it should be thought about when time for revisions comes along. -kmp  Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 6 Sep 84 15:11:57 PDT Date: 6 September 1984 18:10-EDT From: Kent M Pitman Subject: applyhook To: WVANROGGEN @ DEC-MARLBORO cc: common-lisp @ SU-AI, Moon @ SCRC-STONY-BROOK In-reply-to: Msg of Thu 6 Sep 84 11:28:26-EDT from Walter van Roggen Date: Thu 6 Sep 84 11:28:26-EDT From: Walter van Roggen And my point was there's no way to get the "environment" part of a closure explicitly. Sure, implementors don't have to use it because they have access to the internals; but CL users won'be able to evaluate forms in the environment current at the application otherwise. Unless there's some contorted hack you can pull using EVALHOOK.... Given: ((LAMBDA (Y) ((LAMBDA (X) (+ X Y)) 4)) 3) You can get traps at: Data Env Hook 1 ((LAMBDA (Y) ...) 4) () EVALHOOK 2 (LAMBDA (Y) ...), (4) none APPLYHOOK 3 ((LAMBDA (X) ...) 3) ((Y 4)) EVALHOOK 4 (LAMBDA (X) ...), (3) none APPLYHOOK 5 (+ X Y) ((X 3) (Y 4)) EVALHOOK The situation you're worried about is not having the environment at point 2 and 4. But since no destructive computation ever happens between situations like 2 and 3 or 4 and 5, it doesn't matter. Whatever code you intended to run at 2 and 4 can just as well run at 3 and 5 where the info is available. Really, though, APPLYHOOK and EVALHOOK are not as closely related as you are trying to make them seen. They're both useful in debugging, but for much different things. EVALHOOK is generally used to monitor the local state within a lexical contour, making sure that evaluation is proceeding correctly in that context. APPLYHOOK is used to monitor transitions between one lexical contour and another. When travelling through that path, the only information you carry with you is the parameters you pass (and special variables, which are available at all times anyway). It would be inappropriate for APPLYHOOK to get an ENV arg because it's between two contours; I am not even clear on whether you are asking for it to receive the contour of the state you're coming from or that of the state you're going to. In any case, I think it simply shouldn't get any at all. Do you agree with this? Can you suggest a non-contrived application which contradicts this line of reasoning? -kmp  Received: from DEC-MARLBORO.ARPA by SU-AI.ARPA with TCP; 6 Sep 84 08:27:14 PDT Date: Thu 6 Sep 84 11:28:26-EDT From: "Walter van Roggen" Subject: Re: applyhook To: Moon@SCRC-STONY-BROOK.ARPA cc: common-lisp@SU-AI.ARPA, WVANROGGEN@DEC-MARLBORO.ARPA In-Reply-To: Message from ""David A. Moon" " of Thu 6 Sep 84 01:20:28-EDT And my point was there's no way to get the "environment" part of a closure explicitly. Sure, implementors don't have to use it because they have access to the internals; but CL users won'be able to evaluate forms in the environment current at the application otherwise. Unless there's some contorted hack you can pull using EVALHOOK. ---Walter -------  Received: from [128.31.41.144] by SU-AI.ARPA with TCP; 6 Sep 84 06:13:52 PDT Received: from SCRC-CHICOPEE by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 85110; Thu 6-Sep-84 08:52:18-EDT Date: Thu, 6 Sep 84 08:52 EDT From: "Daniel L. Weinreb" Subject: &whole To: Fahlman@CMU-CS-C.ARPA cc: Common-Lisp@SU-AI.ARPA In-Reply-To: Message-ID: <840906085209.9.DLW@CHICOPEE.SCRC.Symbolics> I agree with you completely. We should be careful to define the error-checking behavior that this function must meet. The one presently installed on the Lisp Machine doesn't check if a list is too long NOR if a list is too short -- in the latter case the variable is bound to NIL. However, it does signal an error if it tries to CAR into an atom. I don't know whether this behavior is intentional or a bug.  Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 5 Sep 84 22:12:51 PDT Received: from SCRC-EUPHRATES by SCRC-QUABBIN via CHAOS with CHAOS-MAIL id 78852; Thu 6-Sep-84 01:06:21-EDT Date: Thu, 6 Sep 84 01:12 EDT From: "David A. Moon" Subject: Re: applyhook To: Walter van Roggen cc: common-lisp@SU-AI.ARPA In-Reply-To: The message of 5 Sep 84 17:23-EDT from Walter van Roggen Message-ID: <840906011237.5.MOON@EUPHRATES.SCRC.Symbolics> Date: Wed 5 Sep 84 17:23:17-EDT From: "Walter van Roggen" Seems to me you want to keep the environment argument with applyhook for the same reason it's there with evalhook: because you want an explicit handle on the environment so you can implement things like the stepper and the debugger. But my point is that there is no environment associated with the operation of applying a function to arguments.  Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 5 Sep 84 18:35:07 PDT Received: ID ; Wed 5 Sep 84 21:35:11-EDT Date: Wed, 5 Sep 1984 21:35 EDT Message-ID: Sender: FAHLMAN@CMU-CS-C.ARPA From: "Scott E. Fahlman" To: JonL.pa@XEROX.ARPA Cc: Common-Lisp@SU-AI.ARPA Subject: &whole In-reply-to: Msg of 5 Sep 1984 18:29-EDT from JonL.pa at XEROX.ARPA Yeah, I remember most of that discussion. My position was (and still is) that specific destructuring forms like DELET and DESETQ would be fine, if we could agree on the syntax and come up with better names than those, but that I was (and still am) adamantly opposed to any attempt to incorporate destructuring into existing forms like DEFUN, LET, and SETQ. One reason why we never made any progress on defining a set of standard destructuring operations is that every time the subject came up, it turned into an argument about whether to mess with Defun and all the other existing forms that might also be destructured. My vote would be to consider the proposed Destructuring-Bind by itself, without getting into those related issues yet again. I guess I don't see any need for a non-error checking version of this. Can anyone suggest a situation in which such a thing would be useful? -- Scott  Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 5 Sep 84 15:42:31 PDT Received: from Salvador.ms by ArpaGateway.ms ; 05 SEP 84 15:42:31 PDT Date: 5 Sep 84 15:29 PDT From: JonL.pa@XEROX.ARPA Subject: Re: &whole In-reply-to: "Scott E. Fahlman" 's message of Wed, 5 Sep 84 10:05 EDT To: Fahlman@CMU-CS-C.ARPA cc: Common-Lisp@SU-AI.ARPA You may remember that since 1979, MacLisp (and NIL too, I believe) have had DESETQ for a "destructuring" version of SETQ, and have extended DEFUN and LET to do full destructuring on their "lambda" lists. (ALAN may also have produced a version of these things for the Lisp Machine). There was a small amount of discussion on this point, oh maybe two years ago, in the Common Lisp mails, with one suggestion being to extend the notion of destructuring/lambda-binding to every position that is "analogous" -- this would mean in the lambda-list of DEFUN, in lambda applications like ((LAMBDA (...) ...) ...) as well as in LET. The idea died back then because enough people didn't see a compelling similarity between the argument "spreading" (Interlisp word!) in DEFMACRO and that in the other places like DEFUN. -- JonL --  Received: from DEC-MARLBORO.ARPA by SU-AI.ARPA with TCP; 5 Sep 84 14:21:20 PDT Date: Wed 5 Sep 84 17:23:17-EDT From: "Walter van Roggen" Subject: Re: applyhook To: common-lisp@SU-AI.ARPA Seems to me you want to keep the environment argument with applyhook for the same reason it's there with evalhook: because you want an explicit handle on the environment so you can implement things like the stepper and the debugger. ---Walter -------  Received: from [128.31.41.144] by SU-AI.ARPA with TCP; 5 Sep 84 13:45:26 PDT Received: from SCRC-EUPHRATES by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 84563; Wed 5-Sep-84 16:47:24-EDT Date: Wed, 5 Sep 84 16:45 EDT From: "David A. Moon" Subject: &whole To: "Scott E. Fahlman" cc: Common-Lisp@SU-AI.ARPA, masinter.pa@XEROX.ARPA In-Reply-To: File-References: MC: MOON; CL DSTRUC Message-ID: <840905164518.2.MOON@EUPHRATES.SCRC.Symbolics> Date: Wed, 5 Sep 1984 10:05 EDT From: "Scott E. Fahlman" I think destructuring bind would be a good thing to have in the language in any event. Maybe DBIND would be an adequate name? The part of the name I object to is the word "bind", not the word "destructuring"! To keep my criticism constructive, I'll propose DESTRUCTURE as a name. On the other hand, Common Lisp did not change the name of MULTIPLE-VALUE-BIND, which is an extremely analogous form that simply does a different kind of destructuring, so maybe DESTRUCTURING-BIND is not such a bad name. To avoid confusion, the arglist syntax would have to be exactly as in defmacro. Of course, you have to specify an object to be destructured, you cannot use &ENVIRONMENT, and DEFMACRO's magic cdr-ization of &WHOLE when seen at the top level is not performed. Otherwise it's the same as DEFMACRO. Incidentally, we put the argument pattern -before- the object to be destructured, rather than -after- (as in Masinter's recent message). This is based on the philosophy that special forms that bind variables should always have the variables at the front of the form. It might be desirable to have two forms, with and without error checking that the pattern matches the object in shape and length. Currently we have only the without-error-checking form, but the with-error-checking form would be more consistent with DEFMACRO. The two forms could either have two names (a la CASE, ECASE, CCASE) or could be distinguished by an & keyword (a la &optional and &allow-other-keys). Earlier proposals for DLET and DSETQ were tabled because there was substantial disagreement on the syntax for these, but a form that parallels arglist parsing in a defmacro would be conceptually clear and trivial to implement (given existing code for defmacro). Agreed. I can write a formal proposal after the Monterey meeting if there is interest. There are other possible kinds of destructuring besides this one, which should not affect adoption of this one, but may be of interest. The file referenced in the header of this message, which can be retrieved from MIT-MC with anonymous FTP, contains a discussion I wrote last year of some of the issues. It does not make any proposals, it only discusses. Those poor wretches who are stuck with a user FTP program that refuses to allow spaces in file names on the foreign host may send me mail and I will mail them a copy of the file.  Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 5 Sep 84 12:48:48 PDT Received: from SCRC-EUPHRATES by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 84522; Wed 5-Sep-84 15:51:21-EDT Date: Wed, 5 Sep 84 15:49 EDT From: "David A. Moon" Subject: applyhook To: Common-Lisp@SU-AI.ARPA In-Reply-To: Message-ID: <840905154916.0.MOON@EUPHRATES.SCRC.Symbolics> Date: Wed, 5 Sep 1984 10:24 EDT From: "Scott E. Fahlman" My only remaining question is whether it is worth the hassle to eliminate the env argument just because it is possible to do so. This seems to be a gratuitous change (not a clarification) from the published specification for no particularly compelling reason. It will cause confusion among implementors (and perhaps a few users) who are not on this mailing list and who do not hear about this change. Until some sort of formal means of announcing changes to the spec is set up, we should probably avoid incompatible changes unless the reason for making the change is really compelling. My point of view is that this is a correction of two typographical errors in the manual, rather than an incompatible change to the language; one place on page 322 implies that the function that is the value of *applyhook* receives only two arguments. I could well be wrong. Regardless of this particular issue, we do need to set up a mechanism for distribution of corrections to the manual (as opposed to changes to the language). This topic is missing from the agenda for the Monterey meeting, but it's certainly more important than some of the other things on that agenda (perhaps it is subsumed under "procedures for maintaining the CL standard") and we should talk about it anyway. See you there.  Received: from ISI-VAXA.ARPA by SU-AI.ARPA with TCP; 5 Sep 84 11:44:53 PDT Date: Wednesday, 5 Sep 1984 11:40-PDT TO: COMMON-LISP at SU-AI FROM: Goldman at ISI-VAXA SUBJECT: please add me to the mailing list  Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 5 Sep 84 07:24:31 PDT Received: ID ; Wed 5 Sep 84 10:24:10-EDT Date: Wed, 5 Sep 1984 10:24 EDT Message-ID: Sender: FAHLMAN@CMU-CS-C.ARPA From: "Scott E. Fahlman" To: "David A. Moon" Cc: Common-Lisp@SU-AI.ARPA Subject: applyhook In-reply-to: Msg of 4 Sep 1984 16:19-EDT from David A. Moon I'm not sure why GSB's mail about ((lambda ...) ...) being the reason for the env argument to applyhook is relevant and my note pointing out the same problem is not. I hope the various mailers are not losing things again. But anyway... If this is the only problem that people have found, and as far as I know it is, then Moon's suggestion of passing the lambda form in to the applyhook as an instant closure would work OK, and would not hurt performance in the normal case, since if there's a non-null applyhook a different calling sequence must be used in any event. (The args must go into a list rather than onto the stack.) My only remaining question is whether it is worth the hassle to eliminate the env argument just because it is possible to do so. This seems to be a gratuitous change (not a clarification) from the published specification for no particularly compelling reason. It will cause confusion among implementors (and perhaps a few users) who are not on this mailing list and who do not hear about this change. Until some sort of formal means of announcing changes to the spec is set up, we should probably avoid incompatible changes unless the reason for making the change is really compelling. -- Scott  Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 5 Sep 84 08:09:12 PDT Received: from SCRC-EUPHRATES by SCRC-QUABBIN via CHAOS with CHAOS-MAIL id 78183; Tue 4-Sep-84 21:27:16-EDT Date: Tue, 4 Sep 84 21:33 EDT From: "David A. Moon" Subject: (defmacro foo (&whole w) ...) To: Common-Lisp@SU-AI.ARPA In-Reply-To: <840829225336.4.MOON@EUPHRATES.SCRC.Symbolics>, <840830164339.6.MOON@EUPHRATES.SCRC.Symbolics>, The message of 2 Sep 84 21:46-EDT from Glenn S. Burke , The message of 2 Sep 84 23:56-EDT from JonL.pa at XEROX, , The message of 3 Sep 84 00:31-EDT from Glenn S. Burke , The message of 3 Sep 84 01:46-EDT from Alan Bawden , , The message of 3 Sep 84 18:51-EDT from Alan Bawden , , The message of 3 Sep 84 20:23-EDT from Alan Bawden , , The message of 3 Sep 84 21:24-EDT from Glenn S. Burke , The message of 4 Sep 84 02:42-EDT from masinter.pa at XEROX Message-ID: <840904213316.4.MOON@EUPHRATES.SCRC.Symbolics> Y'all convinced me that the presence of &WHOLE should have no effect on the number-of-subforms checking. Having to put in &REST IGNORE in six places in a large program is better than having an inconsistency in the language. This is consistent with the manual, which says nothing about number-of-subforms checking in defmacro, except at the bottom of p.147 where it says that an implementation "may" do it.  Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 5 Sep 84 08:00:31 PDT Received: from SCRC-EUPHRATES by SCRC-QUABBIN via CHAOS with CHAOS-MAIL id 78116; Tue 4-Sep-84 16:53:26-EDT Date: Tue, 4 Sep 84 16:59 EDT From: "David A. Moon" Subject: documentation strings To: Kent M Pitman , COMMON-LISP@SU-AI.ARPA In-Reply-To: The message of 2 Sep 84 17:03-EDT from Kent M Pitman Message-ID: <840904165927.5.MOON@EUPHRATES.SCRC.Symbolics> Date: 2 September 1984 17:03-EDT From: Kent M Pitman Date: Fri, 31 Aug 84 16:47 EDT From: "David A. Moon" Macros may expand into declarations. May macros expand into documentation strings? .... The only happy way around it is to require documentation strings to be visually apparent. I would support a move to allow a new declaration type called DOCUMENTATION such that a macro wanting to provide documentation could expand to (DECLARE (DOCUMENTATION "...")), which would not be ambiguous in the way that "..." at toplevel would be. A doc-string at toplevel could be magic shorthand for this declaration. This is more or less how we implement it anyway, so I'd support this too. Currently in my implementation macros may expand into documentation strings, just because that's the way the code happened to work out, but I think that this is a misfeature and will probably make the code more complex so that it will cease to recognize strings resulting from macroexpansion as documentation.  Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 5 Sep 84 07:06:11 PDT Received: ID ; Wed 5 Sep 84 10:05:48-EDT Date: Wed, 5 Sep 1984 10:05 EDT Message-ID: Sender: FAHLMAN@CMU-CS-C.ARPA From: "Scott E. Fahlman" To: "David A. Moon" Cc: Common-Lisp@SU-AI.ARPA, masinter.pa@XEROX.ARPA Subject: &whole In-reply-to: Msg of 4 Sep 1984 16:12-EDT from David A. Moon I'm ready to give up and go with total orthogonality for &whole. So (defmacro foo (&whole x) ...) would complain if there are any "arguments", and you have to put in an &rest if you want that complaint to go away. I think destructuring bind would be a good thing to have in the language in any event. Maybe DBIND would be an adequate name? To avoid confusion, the arglist syntax would have to be exactly as in defmacro. Earlier proposals for DLET and DSETQ were tabled because there was substantial disagreement on the syntax for these, but a form that parallels arglist parsing in a defmacro would be conceptually clear and trivial to implement (given existing code for defmacro). -- Scott  Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 5 Sep 84 01:18:13 PDT Received: from SCRC-EUPHRATES by SCRC-QUABBIN via CHAOS with CHAOS-MAIL id 78090; Tue 4-Sep-84 16:13:15-EDT Date: Tue, 4 Sep 84 16:19 EDT From: "David A. Moon" Subject: applyhook To: Common-Lisp@SU-AI.ARPA References: <840831202452.2.MOON@EUPHRATES.SCRC.Symbolics>, , , , , The message of 4 Sep 84 01:56-EDT from Guy.Steele at CMU-CS-A, <840904152033.7.MOON@EUPHRATES.SCRC.Symbolics> Message-ID: <840904161914.8.MOON@EUPHRATES.SCRC.Symbolics> Date: Fri, 31 Aug 84 20:24 EDT From: "David A. Moon" APPLYHOOK should not take an &OPTIONAL ENV argument. Similarly *APPLYHOOK* should receive two arguments, not three arguments. An environment is not meaningful for the APPLY operation, only for the EVAL operation. Does anyone disagree? The only RELEVANT remark among the mail I've received on the subject so far was from Glenn Burke, who suggested that this ENV argument to APPLYHOOK may be for the case of evaluating ((lambda ...) ...) which of course is supposed to be trapped by APPLYHOOK. My feeling is that the hook should see a lexical closure of the lambda, rather than getting the raw lambda and the environment as separate arguments. My system actually doesn't work that way, for stupid reasons; I am about to change it to work that way. Any opinions?  Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 5 Sep 84 01:16:27 PDT Received: from SCRC-EUPHRATES by SCRC-QUABBIN via CHAOS with CHAOS-MAIL id 78088; Tue 4-Sep-84 16:06:42-EDT Date: Tue, 4 Sep 84 16:12 EDT From: "David A. Moon" Subject: &whole To: masinter.pa@XEROX.ARPA cc: Common-Lisp@SU-AI.ARPA In-Reply-To: The message of 4 Sep 84 02:42-EDT from masinter.pa at XEROX Message-ID: <840904161240.7.MOON@EUPHRATES.SCRC.Symbolics> Date: 3 Sep 84 23:42:50 PDT From: masinter.pa@XEROX.ARPA one way around the dilemma of argument checking is to include a macro/special form: (destructure-args form (arg1 arg2 arg3) ...) which 'destructured' form, performed the same arg checking that macro expansion did, and then executed .... This is called destructuring-bind, but it's not in Common Lisp. Suggestions for better names are welcome. I think the lousy name is the reason why I didn't push for including it in Common Lisp.  Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 4 Sep 84 23:36:28 PDT Received: from SCRC-CHICOPEE by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 83908; Tue 4-Sep-84 16:17:50-EDT Date: Tue, 4 Sep 84 16:16 EDT From: "Daniel L. Weinreb" Subject: (defmacro foo (&whole w) ...) To: GSB@MIT-MC.ARPA, Fahlman@CMU-CS-C.ARPA cc: Common-Lisp@SU-AI.ARPA In-Reply-To: The message of 3 Sep 84 21:24-EDT from Glenn S. Burke Message-ID: <840904161614.2.DLW@CHICOPEE.SCRC.Symbolics> Date: 3 September 1984 21:24-EDT From: Glenn S. Burke It should be entirely self-consistent: (&whole w) should bind w to the macro form, and REQUIRE no arguments. If what you want is to hack with arbitrary arguments, just use (&rest args), and i bet you don't want the car of the form most the time then anyway. I agree. Common Lisp needs as much consistency and simplicity as it can get, at this point.  Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 4 Sep 84 15:51:36 PDT Received: from Semillon.ms by ArpaGateway.ms ; 04 SEP 84 15:51:06 PDT Date: 4 Sep 84 15:51 PDT From: JonL.pa@XEROX.ARPA Subject: Re: (defmacro foo (&whole w) ...) In-reply-to: "Scott E. Fahlman" 's message of Mon, 3 Sep 84 09:40 EDT To: Fahlman@CMU-CS-C.ARPA cc: ALAN@MIT-MC.ARPA, Common-Lisp@SU-AI.ARPA I may have been the first (long ago at MIT) to make extensive use of &whole. But that aside, none of my usages fit in the the two molds you suggest: [1] don't like default destructuring, or [2] want to know the code name that invoked the macro (your &first). It was primarily for the more proseaic reason that GSB (or ALAN?) suggested -- simply to give a direct handel on the offending form to the error handler. This is especially relevant when one takes to using precisely one expander function as the "macro" for, say, three different symbols (but &first could serve the functional part here ok). Mail subsequent to this note of yours seems to suggest to me that the "orthogonality" issue hasn't been fully understood. One should just pretend that DEFMACRO works exactly like it does before any consideration of &whole, but the macro body can fortuitously access the invoking form via some variable. This latter part is the one piece of functionality that DEFMACRO lacks when compared to MACRO; and I tend to agree with you that 95% (yea, 99%) of all correct macro usages can generally be expressed in the DEFMACRO format. -- JonL --  Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 3 Sep 84 23:42:53 PDT Received: from Chardonnay.ms by ArpaGateway.ms ; 03 SEP 84 23:43:21 PDT From: masinter.pa@XEROX.ARPA Date: 3 Sep 84 23:42:50 PDT Subject: &whole To: Common-Lisp@SU-AI.ARPA I usually try to stay out of these but... it seems that &whole is pretty much of a hack, but if you are gonna leave it in, there is no point in hacking it up further. &whole should be treated like &rest: does it make sense to say (lambda (a b &rest c d e) --) where c is bound to the tail and d and e are respectively the car and cadr of c with arg count checking turned on? one way around the dilemma of argument checking is to include a macro/special form: (destructure-args form (arg1 arg2 arg3) ...) which 'destructured' form, performed the same arg checking that macro expansion did, and then executed .... Where you would have the user write (defmacro foo (&whole whoarg a b ) ---) which is pretty confusing, he would write (defmacro foo (&whole whoarg) (destructure-arg whoarg (a b) --)) makes a little more sense, and doesn't rely on obscure rules about arglists etc. Sorry for intruding... Larry  Received: from CMU-CS-A.ARPA by SU-AI.ARPA with TCP; 3 Sep 84 22:56:54 PDT Date: 4 Sep 84 0156 EDT (Tuesday) From: Guy.Steele@CMU-CS-A.ARPA To: Rob MacLachlan Subject: '(lambda () a) CC: common-lisp@SU-AI.ARPA In-Reply-To: It is true that (let ((a 'foo)) (apply '(lambda () a) ())) need not yield the value foo when executed in Common LISP. However, it does have a valid interpretation. Sections 2.13 and 5.2 refer to the fact that a "raw lambda expression" may be used as a function; see also the description of the function APPLY. I remember that we decided that a raw lambda expression, when applied, is supposed to be implicitly closed in the null (that is, global) environment, but I cannot quickly find a place in the manual that actually says that. Gulp. --Guy  Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 3 Sep 84 18:24:06 PDT Date: 3 September 1984 21:24-EDT From: Glenn S. Burke Subject: (defmacro foo (&whole w) ...) To: Fahlman @ CMU-CS-C cc: Common-Lisp @ SU-AI Date: Mon, 3 Sep 1984 21:02 EDT Sender: FAHLMAN@CMU-CS-C.ARPA Now, what about arglists with ONLY an &whole argument? Should we adopt Moon's suggestion that these, as a special case, can accept any number of subforms, or should we require the explicit &rest arg here as well? This special case would eliminate most of the inconvenience I was objecting to before, and this use seems clear and intuitive to me, but it IS a special case. How muich does that bother people? Does anyone really want an automatically generated check to ensure that there are NO subforms? It should be entirely self-consistent: (&whole w) should bind w to the macro form, and REQUIRE no arguments. If what you want is to hack with arbitrary arguments, just use (&rest args), and i bet you don't want the car of the form most the time then anyway.  Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 3 Sep 84 18:02:35 PDT Received: ID ; Mon 3 Sep 84 21:02:51-EDT Date: Mon, 3 Sep 1984 21:02 EDT Message-ID: Sender: FAHLMAN@CMU-CS-C.ARPA From: "Scott E. Fahlman" To: Alan Bawden Cc: Common-Lisp@SU-AI.ARPA Subject: (defmacro foo (&whole w) ...) In-reply-to: Msg of 3 Sep 1984 20:23-EDT from Alan Bawden Well, OK. I don't think it is very important to mix &whole with other things, and if we do I don't think it's very important to catch too-many-args errors, let alone to signal them in the canonical way rather than in some other way. But I've got to admit that your way is cleaner. You win, as far as I'm concerned. Now, what about arglists with ONLY an &whole argument? Should we adopt Moon's suggestion that these, as a special case, can accept any number of subforms, or should we require the explicit &rest arg here as well? This special case would eliminate most of the inconvenience I was objecting to before, and this use seems clear and intuitive to me, but it IS a special case. How muich does that bother people? Does anyone really want an automatically generated check to ensure that there are NO subforms? -- Scott  Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 3 Sep 84 17:22:24 PDT Date: 3 September 1984 20:23-EDT From: Alan Bawden Subject: (defmacro foo (&whole w) ...) To: Fahlman @ CMU-CS-C cc: Common-Lisp @ SU-AI In-reply-to: Msg of Mon 3 Sep 1984 19:46 EDT from Scott E. Fahlman Date: Mon, 3 Sep 1984 19:46 EDT From: Scott E. Fahlman What, exactly, would become impossible if we turned off too-many-argument checking when an &whole is encountered? Looks to me like Common Lisp would still be more or less Turing equivalent. To me, the question is whether it is more of a pain for me to write "&REST IGNORE) (DECLARE (IGNORE IGNORE))" twice a year or for you to write (WHEN (> (LENGTH WHOLE-ARG) 7) (ERROR "Too many args to FOO.")) This is not an acceptable substitute for having defmacro perform the error checking automatically. It requires the user to count the number of arguments by hand; if he inserts a new argument, he has to remember to go and increment a number imbedded in his code. More importantly it assumes that the user can duplicate the way defmacro signals the error, which in general he cannot.  Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 3 Sep 84 16:46:11 PDT Received: ID ; Mon 3 Sep 84 19:46:24-EDT Date: Mon, 3 Sep 1984 19:46 EDT Message-ID: Sender: FAHLMAN@CMU-CS-C.ARPA From: "Scott E. Fahlman" To: Alan Bawden Cc: Common-Lisp@SU-AI.ARPA Subject: (defmacro foo (&whole w) ...) In-reply-to: Msg of 3 Sep 1984 18:51-EDT from Alan Bawden I don't buy any argument that says we have to make certain things impossible for users to do just because you find it a pain to have to write "&REST IGNORE) (DECLARE (IGNORE IGNORE))" twice a year. What, exactly, would become impossible if we turned off too-many-argument checking when an &whole is encountered? Looks to me like Common Lisp would still be more or less Turing equivalent. To me, the question is whether it is more of a pain for me to write "&REST IGNORE) (DECLARE (IGNORE IGNORE))" twice a year or for you to write (WHEN (> (LENGTH WHOLE-ARG) 7) (ERROR "Too many args to FOO.")) twice a century. As I said, if I'm off base on the relative frequencies of these things in other parts of the user community, then the orthogonal approach might be preferable. But I don't see any impossibility in either approach that would force us to choose the less convenient of the two. -- Scott  Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 3 Sep 84 15:50:36 PDT Date: 3 September 1984 18:51-EDT From: Alan Bawden Subject: (defmacro foo (&whole w) ...) To: Fahlman @ CMU-CS-C cc: Common-Lisp @ SU-AI In-reply-to: Msg of Mon 3 Sep 1984 09:40 EDT from Scott E. Fahlman Date: Mon, 3 Sep 1984 09:40 EDT From: Scott E. Fahlman Well, I guess what it boils down to for me is that in 95% of the cases where there is an &WHOLE in a macro, that's all there is, and it's a pain to have to write an explicit &REST argument when you could just take the cdr of the &WHOLE arg.... I don't buy any argument that says we have to make certain things impossible for users to do just because you find it a pain to have to write "&REST IGNORE) (DECLARE (IGNORE IGNORE))" twice a year. Excuse me for forgetting the "(DECLARE (IGNORE IGNORE))" before. If I had been able to have my way on that issue, you wouldn't ever have to write that. I don't go for this &FIRST idea either. I don't like introducing yet more silly &keywords when we could render &FIRST next to useless by simply defining &WHOLE not to gratuitously disable an error check.  Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 3 Sep 84 08:50:08 PDT Received: ID ; Mon 3 Sep 84 11:32:48-EDT Date: Mon, 3 Sep 1984 11:32 EDT Message-ID: Sender: FAHLMAN@CMU-CS-C.ARPA From: "Scott E. Fahlman" To: Rob MacLachlan Cc: common-lisp@SU-AI.ARPA Subject: applyhook In-reply-to: Msg of 3 Sep 1984 10:18-EDT from Rob MacLachlan Rob, I don't think the example you give has anything to do with *APPLYHOOK*. *APPLYHOOK* is supposed to intercept the implicit calls to apply that occur within EVAL. It is not supposed to handle explicit calls done by APPLY, FUNCALL, MAP, etc. See page 322. The name "applyhook" is a bit confusing because of this, but I can't think of any better name. I believe that the final decision on forms like (apply '(lambda (x) ... code ...) ...) was that they were allowed, but that the lambda was executed in the NULL lexical environment. As you say, if it has to use the current lexical environment there's no way to compile it in the general case where the lambda-form may be generated at runtime. However, I can't find any discussion of this in the manual and may be misremembering the decision. I do remember that discussions of this dragged on for quite awhile. -- Scott  Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 3 Sep 84 07:36:57 PDT Received: ID ; Mon 3 Sep 84 10:19:00-EDT Date: Mon, 3 Sep 1984 10:18 EDT Message-ID: From: Rob MacLachlan To: "Scott E. Fahlman" Cc: common-lisp@SU-AI.ARPA, "David A. Moon" Subject: applyhook In-reply-to: Msg of 3 Sep 1984 00:59-EDT from Scott E. Fahlman It's not clear that: (let ((a 'foo)) (apply '(lambda () a) ())) has to work in Common Lisp. The lambda should be #'ed, in which case it will be closed over. It is not totally clear in the CLM what the effect of using a quoted lambda is, but it would seem to dubious since it cannot be compiled properly and the compiler is required to implement the same semantics as the interpreter. Rob  Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 3 Sep 84 06:57:28 PDT Received: ID ; Mon 3 Sep 84 09:40:05-EDT Date: Mon, 3 Sep 1984 09:40 EDT Message-ID: Sender: FAHLMAN@CMU-CS-C.ARPA From: "Scott E. Fahlman" To: Alan Bawden Cc: Common-Lisp@SU-AI.ARPA Subject: (defmacro foo (&whole w) ...) In-reply-to: Msg of 3 Sep 1984 01:46-EDT from Alan Bawden Well, I guess what it boils down to for me is that in 95% of the cases where there is an &WHOLE in a macro, that's all there is, and it's a pain to have to write an explicit &REST argument when you could just take the cdr of the &WHOLE arg. By the way, your "&REST IGNORE" must be accompanied by (declare (ignore ignore)) in order to work in Common Lisp. The special-case treatment of variables named IGNORE got flushed in favor of the more uniform IGNORE declaration, I believe. The question is whether it is more trouble and more confusing to have to add that &REST arg and the IGNORE declaration in a lot of places, or to put in an explicit length check on the &WHOLE are in the rare case that you want the arglist to have some maximum length. Actually, I have seen &WHOLE used in only two ways: first, when you're in a macro with some sort of complex syntax and don't want the usual argument destructuring (in which case, it is best to disable the too-many-args check); second, in cases where you do want normal destructuring, but need to get at the CAR of the calling form. I'd like to see an additional form for that specialized purpose: something like &first (though I'd like to find a better name for it). That would clarify the programmer's intention and would not disable arg-count checking. Of course, if I am wrong about this and people are writing lots of code that mixes &whole (for some use other than getting at the car of the form) and hairy arglist destructuring, then &whole should be orthogonal after all. We may have a cultural difference here. -- Scott  Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 2 Sep 84 22:45:35 PDT Date: 3 September 1984 01:46-EDT From: Alan Bawden Subject: (defmacro foo (&whole w) ...) To: Fahlman @ CMU-CS-C cc: Common-Lisp @ SU-AI In-reply-to: Msg of Mon 3 Sep 1984 00:26 EDT from Scott E. Fahlman Date: Mon, 3 Sep 1984 00:26 EDT From: Scott E. Fahlman Once you've given the user a handle on the whole argument form with &whole, you shouldn't require him to add additional meaningless args just to confuse Defmacro into allowing subforms without complaining. That makes for confusing code. If the user actually wants to make use of the additional args, that's different. Huh? I don't understand what you are trying to say. Whats all this talk about "confusing" defmacro? Glenn's agrument is very simple: Suppose the user wants to get ahold of the original form, but also wants defmacro to take it apart for him. Why should the fact that he wants to include the whole form in an error message (for example) cause him to lose error checking on the syntax of the macro call? If he wants to allow any length form to be used, he can always add &REST IGNORE. I don't see anything meaningless or confusing about that, it says what it means quite clearly. BTW, Glenn also just convinced me that macros that expand into documentation strings are potentially hazardous, I think the idea of an explicit DOCUMENTATION declaration is clearly the right thing for macros that want to supply documentation strings. The idea of using strings like that was only a kludge to improve readability of the code anyway, macros don't have to expand into readable code.  Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 2 Sep 84 22:17:32 PDT Received: ID ; Mon 3 Sep 84 00:59:39-EDT Date: Mon, 3 Sep 1984 00:59 EDT Message-ID: Sender: FAHLMAN@CMU-CS-C.ARPA From: "Scott E. Fahlman" To: "David A. Moon" Cc: common-lisp@SU-AI.ARPA Subject: applyhook In-reply-to: Msg of 31 Aug 1984 20:24-EDT from David A. Moon OK, I'll bite. Why do you think that applyhook doesn't need an environment arg? Granted, the args have already been computed by the time the applyhook gets called, but the environment still might be needed while the function is running. Functions called by name in the usual way carry their lexical environment around with them -- either the null environment or a closure -- but the function being applied might be an interpreted lambda containing code that refers to free variables, lexicaly bound function names, and external GO and BLOCK tags. Such things are looked up in the current lexical environment during the application of the Lambda form to the args, right? Or am I confused about this? -- Scott  Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 2 Sep 84 21:44:23 PDT Received: ID ; Mon 3 Sep 84 00:26:54-EDT Date: Mon, 3 Sep 1984 00:26 EDT Message-ID: Sender: FAHLMAN@CMU-CS-C.ARPA From: "Scott E. Fahlman" To: JonL.pa@XEROX.ARPA Cc: Common-Lisp@SU-AI.ARPA, GSB@MIT-MC.ARPA Subject: (defmacro foo (&whole w) ...) In-reply-to: Msg of 2 Sep 1984 23:56-EDT from JonL.pa at XEROX.ARPA If by "orthogonal" you mean that too-many-argument checking remains in place, and that (defmacro foo (&whole x) ...) is required to have NO subforms in argument position, then I'm against this interpretation. Once you've given the user a handle on the whole argument form with &whole, you shouldn't require him to add additional meaningless args just to confuse Defmacro into allowing subforms without complaining. That makes for confusing code. If the user actually wants to make use of the additional args, that's different. I'm not too concerned with what the original intent in Maclisp was. Defmacro has evolved quite a bit since the first muddled attempts to do something reasonable with macros. About the time I left MIT, there were three or four defmacro-like packages in use by various people, all different. -- Scott  Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 2 Sep 84 21:32:09 PDT Date: 3 September 1984 00:31-EDT From: Glenn S. Burke Subject: Re: (defmacro foo (&whole w) ...); macros ==> documentation strings To: Common-Lisp @ SU-AI Yes, i am advocating &whole being orthogonal and not affecting the number- of-argument checking. As for macros expanding into documentation strings, i don't think that this is a good idea, because while DECLARE is not permitted to appear in arbitrary places, strings are. As a result, a misplaced macro expanding into a DECLARE form is an error, whereas a misplaced macro expanding into a documentation string is not, and might be interpreted incorrectly even if it isn't misplaced. If this calls for a DOCUMENTATION declaration, fine, add one.  Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 2 Sep 84 20:55:44 PDT Received: from Semillon.ms by ArpaGateway.ms ; 02 SEP 84 20:56:13 PDT Date: 2 Sep 84 20:56 PDT From: JonL.pa@XEROX.ARPA Subject: Re: (defmacro foo (&whole w) ...) In-reply-to: Glenn S. Burke 's message of 2 Sep 84 21:46 EDT To: GSB@MIT-MC.ARPA cc: Common-Lisp@SU-AI.ARPA You're right. &WHOLE, as originally conceived, was orthogonal to the other keywords. I recommend that approach (you are also recommending it, no?). -- JonL --  Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 2 Sep 84 18:45:31 PDT Date: 2 September 1984 21:46-EDT From: Glenn S. Burke Subject: (defmacro foo (&whole w) ...) To: Common-Lisp @ SU-AI The original intent of &whole when it was put into maclisp was for the macro to have a handle on the form being macroexpanded; in that light it is orthogonal to &rest or anything else, and even the case of (defmacro foo (&whole w) ...) is not degenerate. Similarly, embedded use of &whole gives one a pointer to a subform which is being further destructured, and which you wouldn't otherwise be able to get a handle on. If &whole inhibits too-many-arguments checking, then this functionality becomes useless because you cannot use it and enforce the structure at the same time.  Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 2 Sep 84 14:04:16 PDT Date: 2 September 1984 17:03-EDT From: Kent M Pitman Subject: documentation strings To: Moon @ SCRC-STONY-BROOK cc: COMMON-LISP @ SU-AI In-Reply-To:<840831164747.9.MOON@EUPHRATES.SCRC.Symbolics> Date: Fri, 31 Aug 84 16:47 EDT From: "David A. Moon" Macros may expand into declarations. May macros expand into documentation strings? I remember discussing this. I don't remember if there was an outcome and couldn't find it in Mary Poppins. The problem is that declarations identify themselves by the car of the form. Documentation strings don't. Hence, (DEFMACRO FOO () "Foo") (DEFUN BAR () (FOO) "Bar") is clear enough, but: (DEFMACRO DEFFROB (NAME &REST BODY) `(DEFUN ,(SYMBOLCONC NAME '-FROB) () ,@BODY)) (DEFFROB FOO (FOO)) might be confusing in that a bogus documentation string might be generated (assume the user doesn't know the implementation of either FOO or DEFFROB). If you think it's unambiguous because (FOO) is in a for-value situation, consider the conscientious macro-writer who knew that the return value of frob functions were always ignored, so had written instead: (DEFMACRO DEFFROB (NAME &REST BODY) `(DEFUN ,(SYMBOLCONC NAME '-FROB) () ,@BODY NIL)) to emphasize the fact. I find it distasteful to think that he'd have to write (DEFMACRO DEFFROB (NAME &REST BODY) `(DEFUN ,(SYMBOLCONC NAME '-FROB) () NIL ,@BODY NIL)) to be safe. Unfortunately, this would mean (FOO) could not expand into a declaration, which might have been desirable. His only alternative is to write code to check the first n forms in BODY for declarations/doc-strings, which is something of a pain to be doing everywhere. The only happy way around it is to require documentation strings to be visually apparent. I would support a move to allow a new declaration type called DOCUMENTATION such that a macro wanting to provide documentation could expand to (DECLARE (DOCUMENTATION "...")), which would not be ambiguous in the way that "..." at toplevel would be. A doc-string at toplevel could be magic shorthand for this declaration. -kmp  Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 1 Sep 84 21:56:44 PDT Received: from SCRC-MISSISSIPPI by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 83311; Sat 1-Sep-84 23:49:49-EDT Date: Sat, 1 Sep 84 23:48 EDT From: Bill Gosper Subject: "initial segments of the continued fraction lead to the best rational approximations" To: rz@MIT-MC.ARPA Cc: wholey@CMU-CS-C.ARPA, dlw%SPA-NIMBUS@SCRC-RIVERSIDE.ARPA, common-lisp@SU-AI.ARPA Yow, are you a lawyer yet? If "best rational approximations" are those which are closer than any with smaller denominator, then your "leads to" is misleading, since reducing the final term of a truncated cf by less than half its correct value still gives a "best" approximation. Reducing by fully one half is "best" in only about half of the (even) cases. The precise terms and conditions are intelligible by anyone who has recently passed a Bar exam, and I will inflict them only on the avowedly curious.  Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 1 Sep 84 18:41:53 PDT Received: ID ; Sat 1 Sep 84 21:24:14-EDT Date: Sat, 1 Sep 1984 21:24 EDT Message-ID: Sender: FAHLMAN@CMU-CS-C.ARPA From: "Scott E. Fahlman" To: "Earl A. Killian" Cc: common-lisp@SU-AI.ARPA Subject: Questions from M. Hagiya In-reply-to: Msg of 1 Sep 1984 19:03-EDT from Earl A. Killian Actually, the Spice Lisp compiler is driven almost entirely by modular transforms and code-generation functions that live on the property list of the form in question. The old Lisp Machine compiler was similar, and I think that Symbolics, at least, has stuck with this style. However, if you mess with really fundamental things like IF and QUOTE, you'll confuse an awful lot of macros and transforms that generate these expecting the old meaning to hold. Maybe instead of messing around with Lisp's IF special form, you should put your embedded language in its own package. Then you can do whatever you want with FOOBAR:IF and not confuse anyone's compiler. That's one of the applications we had in mind when designing the Common Lisp package system, and I think that all the necessary features are there for this kind of hackery. -- Scott  Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 1 Sep 84 16:44:48 PDT Date: 1 Sep 1984 1940-EDT From: Bernard S. Greenberg Subject: Re: Questions from M. Hagiya To: EAK%MIT-MC@SU-AI cc: DLW%SCRC-QUABBIN%MIT-MC@SU-AI, common-lisp@SAIL In-Reply-To: The message of 1 September 1984 19:03-EDT from Earl A. Killian Date: 1 September 1984 19:03-EDT From: Earl A. Killian Date: Sun, 26 Aug 84 21:11 EDT From: Daniel L. Weinreb If we evaluate (setf (symbol-function 'moshi) (symbol-function 'if)), does Common Lisp specify that this "works", i.e. that the symbol "moshi" (a Japanese word for "if") can now be used as the name-symbol of a special form, just as well as "if"? (I told him I thought the answer was "no", but it's not stated clearly in the manual.) I would tend to agree withj your "no"; on the other hand I feel strongly that there ought to be a *PORTABLE* way to do renaming. Obviously having MOSHI be a synonym for IF can easily be done by macros; the more interesting case is when you want to make MOSHI mean IF and IF then mean something else. Unfortunately most compilers seem to build the known function names right into the compiler source (e.g. (EQ F '+)) rather than using a database that can be rearranged (e.g. by using symbol property lists). Not just the gut of the compiler that does (EQ F '+), but macro packages and code-transformers inside and outside compilers expect `(+ ,x ,y) or whatever to generate a reference to the + that it knows about. If we follow your line (which is not without merit), it will be extremely difficult, if not impossible, to write macros that can be used with referential transparency in systems where renaming is taking place. -------  Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 1 Sep 84 16:02:49 PDT Date: 1 September 1984 19:03-EDT From: Earl A. Killian Subject: Questions from M. Hagiya To: DLW @ SCRC-QUABBIN cc: common-lisp @ SU-AI In-reply-to: Msg of Sun 26 Aug 84 21:11 EDT from Daniel L. Weinreb Date: Sun, 26 Aug 84 21:11 EDT From: Daniel L. Weinreb If we evaluate (setf (symbol-function 'moshi) (symbol-function 'if)), does Common Lisp specify that this "works", i.e. that the symbol "moshi" (a Japanese word for "if") can now be used as the name-symbol of a special form, just as well as "if"? (I told him I thought the answer was "no", but it's not stated clearly in the manual.) I would tend to agree withj your "no"; on the other hand I feel strongly that there ought to be a *PORTABLE* way to do renaming. Obviously having MOSHI be a synonym for IF can easily be done by macros; the more interesting case is when you want to make MOSHI mean IF and IF then mean something else. Unfortunately most compilers seem to build the known function names right into the compiler source (e.g. (EQ F '+)) rather than using a database that can be rearranged (e.g. by using symbol property lists). If something isn't done about this, then it is going to be difficult to experiment with future language design using Common Lisp implementations as a starting point.  Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 31 Aug 84 17:26:23 PDT Received: from SCRC-EUPHRATES by SCRC-QUABBIN via CHAOS with CHAOS-MAIL id 77493; Fri 31-Aug-84 20:21:38-EDT Date: Fri, 31 Aug 84 20:24 EDT From: "David A. Moon" Subject: applyhook To: common-lisp@SU-AI.ARPA Message-ID: <840831202452.2.MOON@EUPHRATES.SCRC.Symbolics> APPLYHOOK should not take an &OPTIONAL ENV argument. Similarly *APPLYHOOK* should receive two arguments, not three arguments. An environment is not meaningful for the APPLY operation, only for the EVAL operation. Does anyone disagree?  Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 31 Aug 84 16:12:45 PDT Received: from SCRC-EUPHRATES by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 83063; Fri 31-Aug-84 16:49:14-EDT Date: Fri, 31 Aug 84 16:47 EDT From: "David A. Moon" Subject: documentation strings To: Common-Lisp@SU-AI.ARPA Message-ID: <840831164747.9.MOON@EUPHRATES.SCRC.Symbolics> Macros may expand into declarations. May macros expand into documentation strings?  Received: from [128.31.41.144] by SU-AI.ARPA with TCP; 30 Aug 84 13:44:00 PDT Received: from SCRC-EUPHRATES by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 82391; Thu 30-Aug-84 16:44:36-EDT Date: Thu, 30 Aug 84 16:43 EDT From: "David A. Moon" Subject: (defmacro foo (&whole w) ...) To: "Scott E. Fahlman" cc: Common-Lisp@SU-AI.ARPA In-Reply-To: Message-ID: <840830164339.6.MOON@EUPHRATES.SCRC.Symbolics> Date: Thu, 30 Aug 1984 09:42 EDT From: "Scott E. Fahlman" In the current Spice Lisp implementation, &whole sets the same switch that &rest does. This leaves too-few-arguments checking in place, but disables too-many-arguments checking. So if there is an &whole anywhere in the arglist, you have to supply at least enough subforms to satisfy the required arguments (if any), but you are free to supply extras which the user can access by picking apart the &whole argument by hand. This seems intuitively right to me; it would be confusing to require &whole and &rest in the same arglist or to special-case the situation where &whole appears alone. This would give the same results as proposed by Moon, but (defmacro foo (&whole w a) ...) would require AT LEAST one subform, not EXACTLY one subform. It would be okay by me if the language were defined to make this the standard behavior.  Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 30 Aug 84 06:44:07 PDT Received: ID ; Thu 30 Aug 84 09:42:26-EDT Date: Thu, 30 Aug 1984 09:42 EDT Message-ID: Sender: FAHLMAN@CMU-CS-C.ARPA From: "Scott E. Fahlman" To: Common-Lisp@SU-AI.ARPA Subject: (defmacro foo (&whole w) ...) In-reply-to: Msg of 29 Aug 1984 22:53-EDT from David A. Moon In the current Spice Lisp implementation, &whole sets the same switch that &rest does. This leaves too-few-arguments checking in place, but disables too-many-arguments checking. So if there is an &whole anywhere in the arglist, you have to supply at least enough subforms to satisfy the required arguments (if any), but you are free to supply extras which the user can access by picking apart the &whole argument by hand. This seems intuitively right to me; it would be confusing to require &whole and &rest in the same arglist or to special-case the situation where &whole appears alone. This would give the same results as proposed by Moon, but (defmacro foo (&whole w a) ...) would require AT LEAST one subform, not EXACTLY one subform. -- Scott  Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 29 Aug 84 20:08:15 PDT Received: from SCRC-EUPHRATES by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 82003; Wed 29-Aug-84 22:54:19-EDT Date: Wed, 29 Aug 84 22:53 EDT From: "David A. Moon" Subject: (defmacro foo (&whole w) ...) To: Common-Lisp@SU-AI.ARPA In-Reply-To: <840826211121.0.DLW@CHICOPEE.SCRC.Symbolics> Message-ID: <840829225336.4.MOON@EUPHRATES.SCRC.Symbolics> Date: Sun, 26 Aug 84 21:11 EDT From: "Daniel L. Weinreb" T. Yuasa and M. Hagiya of Kyoto University independently implemented Common Lisp for the Data General MV/10000. They had a number of questions about the definition of Common Lisp, which they accumulated in a file.... In a defmacro argument list, (&whole w a b) presumably means that there must be exactly two arguments to the macro, which a and b will be bound to, and furthermore that w will be bound to the whole thing. By extension, (&whole w a) means that there must be exactly one argument, and so (&whole w) means that there must not be any arguments at all. If so, then the (&whole w) case is evidently useless, and if what you really want is to just have a macro that lets you examine the body yourself and doesn't play with argument lists, you need to do (&whole w &rest ignore) or something. Is this really the definition of Common Lisp? Due to a bug in our implementation, neither (defmacro foo (&whole w) ...) nor (defmacro foo () ...) checked the number of subforms, although all other cases of defmacro did. I decided that this was actually a feature in the &whole case, so when I fixed the bug I made the &whole case be treated specially and not check the number of subforms. This is certainly a wart, but it makes life easier for the user and I can't see how it hurts anything. In particular, I have some places where I want to depend on this myself. [By the way, the bug is only fixed in my private copy of defmacro currently.] I propose these rules for inclusion in the language: (defmacro foo () ...) requires that invocations of foo have no subforms. (defmacro foo (&whole w) ...), as a special case, allows any number of subforms. (defmacro foo (&whole w a) ...) requires that invocations of foo have exactly one subform. Opinions?  Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 28 Aug 84 12:14:38 PDT Received: from SCRC-CUYAHOGA by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 81147; Tue 28-Aug-84 15:10:23-EDT Date: Tue, 28 Aug 84 15:10 EDT From: "Robert A. Cassels" Subject: Rationalize To: DLW@SCRC-QUABBIN.ARPA, Wholey@CMU-CS-C.ARPA cc: Common-Lisp@SU-AI.ARPA In-Reply-To: <840828102337.8.DLW@CHICOPEE.SCRC.Symbolics> Message-ID: <840828151023.3.CASSELS@CUYAHOGA.SCRC.Symbolics> Date: Tue, 28 Aug 84 10:23 EDT From: "Daniel L. Weinreb" Just as another spot-check of portability, I tried out the slisp definition of "rationalize" in the Symbolics CLCP, and it works. However, on some hard cases (cases with large numerators and denominators), it gets different answers than ours. For example, both functions, given 1.6666666, return 5/3. However, if you lop off one 6 and try 1.666666, ours gets 798918/479351 whereas yours gets 873813/524288. In octal, that's 3030306/1650167 for ours and 3252525\2000000 for yours, which may be more revealing. Anyway, doing the divisions back, using double precision, ours gives 1.666666030883789d0 (3.088d0 error), and yours gives 1.666659712820042d0 (2.872d0 error). I'm not sure what the significance [I know] of this is. Either is acceptable to CL: "[RATIONALIZE] ... may return any rational number for which the floating-point number is the best available approximation of its format; ... it attempts to keep both numerator and denominator small." Ours is defined to be the fraction of smallest denominator which lies in the "floating-point interval" around the argument. It is definitely not the most accurate. But of course the most accurate rational approximation to a floating-point number F is (RATIONAL F). Ours derives from RWG's paper on continued fractions wherein he shows how to solve such important questions as, "If a baseball player is hitting .319, what is the smallest number of at-bats he could have had?" So we subscribe to the view that, "... RATIONALIZE goes to more trouble to produce a result that is more pleasant to view ...". You'll have to decide for yourself whether 798918/479351 is more pleasant than 873813/524288.  Received: from SCRC-QUABBIN.ARPA by SU-AI.ARPA with TCP; 28 Aug 84 08:15:39 PDT Received: from SCRC-CHICOPEE by SCRC-QUABBIN via CHAOS with CHAOS-MAIL id 76345; Tue 28-Aug-84 10:20:57-EDT Date: Tue, 28 Aug 84 10:23 EDT From: "Daniel L. Weinreb" Subject: Rationalize To: Wholey@CMU-CS-C.ARPA cc: Common-Lisp@SU-AI.ARPA In-Reply-To: Message-ID: <840828102337.8.DLW@CHICOPEE.SCRC.Symbolics> Just as another spot-check of portability, I tried out the slisp definition of "rationalize" in the Symbolics CLCP, and it works. However, on some hard cases (cases with large numerators and denominators), it gets different answers than ours. For example, both functions, given 1.6666666, return 5/3. However, if you lop off one 6 and try 1.666666, ours gets 798918/479351 whereas yours gets 873813/524288. In octal, that's 3030306/1650167 for ours and 3252525\2000000 for yours, which may be more revealing. Anyway, doing the divisions back, using double precision, ours gives 1.666666030883789d0 (3.088d0 error), and yours gives 1.666659712820042d0 (2.872d0 error). I'm not sure what the significance [I know] of this is.  Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 27 Aug 84 20:45:39 PDT Date: 27 August 1984 23:45-EDT From: Richard E. Zippel Subject: Rationalize To: Wholey @ CMU-CS-C cc: Common-Lisp @ SU-AI, DLW @ SCRC-QUABBIN, RWG @ SCRC-STONY-BROOK I thought I'd put my two cents since I had something to do with this stuff. First, unless my memory is massively wrong, I was the one whoe first implemented rationalize in Macsyma. I believe it was Bill Gosper that requested it. Bill correct me if I'm wrong. Second, while I have your attention let me explain the algorithm since it is really quite simple. All positive real numbers can be represented as a continued fraction, viz. alpha = a0 + 1/(a1 + 1/(a2 + ... 1/an) ... ) If alpha is not a rational number then the continued fraction does not terminate. Initial segments of the continued fraction lead to the best rational approximations to alpha. (This is proven in any book on elementary number theory.) The algorithm in rationalize consists of two parts that are melded together. First, one computes the sequence of partial quotients: a0, a1, a2, ... and then use them to compute rational approximations to alpha. The ai are easy to calculate, a0 is the floor (truncate) of alpha, a1 is the floor of 1/(alpha-a0), etc. Let alpha[0] = alpha, a0 = truncate(alpha[0]) and alpha[i] = 1/(alpha(i-1) - ai) then ai = truncate(alpha(i)). Computing the rational approximation is a little more complicated. Let p[0]/q[0] = a0/1, p[1]/q[1] = a0 + 1/a1, etc. (the rational approximations to alpha). Also let p[-1] = 0, q[-1] = 1. Then p[i] = ai p[i-1] + p[i-2] q[i] = ai q[i-1] + q[i-2]. It is also useful to know that each pair of p[i] and q[i] is relatively prime. The code given by Skef, intertwines the two phases of this algorithm to avoid consing or using the stack. Remember it was originally implemented for Macsyma which was terribly short on space.  Received: from SCRC-QUABBIN.ARPA by SU-AI.ARPA with TCP; 27 Aug 84 13:01:15 PDT Received: from SCRC-EUPHRATES by SCRC-QUABBIN via CHAOS with CHAOS-MAIL id 76086; Mon 27-Aug-84 15:47:03-EDT Date: Mon, 27 Aug 84 15:49 EDT From: "David A. Moon" Subject: Rationalize To: Skef Wholey cc: Common-Lisp@SU-AI.ARPA In-Reply-To: Message-ID: <840827154913.8.MOON@EUPHRATES.SCRC.Symbolics> Hmm, that definition of rationalize is completely different from ours, which was also written by Gosper but is not completely implementation-independent. Are you sure yours satisfies the axiom (float (rationalize x) x) = x? Am I sure ours does? Does anybody have a test suite for rationalize?  Received: from SCRC-QUABBIN.ARPA by SU-AI.ARPA with TCP; 27 Aug 84 12:44:29 PDT Received: from SCRC-EUPHRATES by SCRC-QUABBIN via CHAOS with CHAOS-MAIL id 76082; Mon 27-Aug-84 15:41:35-EDT Date: Mon, 27 Aug 84 15:43 EDT From: "David A. Moon" Subject: Questions from M. Hagiya To: Skef Wholey cc: "Daniel L. Weinreb" , common-lisp@SU-AI.ARPA In-Reply-To: Message-ID: <840827154344.7.MOON@EUPHRATES.SCRC.Symbolics> Date: Sun, 26 Aug 1984 23:03 EDT From: Skef Wholey Re: Questions from M. Hagiya While LOADing a file, what is the value of *standard-input*? (I told him that I thought for a character file it really ought to be the file stream, but the manual needs to say and doesn't. What should it be when the file is binary?) I don't think anything should happen to *Standard-Input*. Consider a program (i.e. a file of Lisp code) that wants to query the user when it is loaded. In that case, leaving *Standard-Input* as is is useful. I can't think of any useful thing one could do with having *Standard-Input* be bound to the file. Users must be queried over *query-io*, not *standard-input*.  Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 27 Aug 84 07:45:31 PDT Received: ID ; Mon 27 Aug 84 10:36:39-EDT Date: Mon, 27 Aug 1984 10:36 EDT Message-ID: Sender: WHOLEY@CMU-CS-C.ARPA From: Skef Wholey To: "Daniel L. Weinreb" Cc: Common-Lisp@SU-AI.ARPA Subject: Rationalize Sorry for broadcasting incorrect information about Gosper's place of employment -- the comment and the code below were written long ago. I found the comment while looking for the code and thought it amusing. So this isn't Info-Cobol. I believe the only piece of non-portability in it is the assumption that there are only two types of floats. (defun rationalize (x) (typecase x (rational x) (short-float (rationalize-float x short-float-epsilon)) (long-float (rationalize-float x long-float-epsilon)) (otherwise (error "~A is not a non-complex number" x)))) (defun rationalize-float (x eps) (cond ((minusp x) (- (rationalize (- x)))) ((zerop x) 0) (t (let ((y ()) (a ())) (do ((xx x (setq y (/ 1.0s0 (- xx (float a x))))) (num (setq a (truncate x)) (+ (* (setq a (truncate y)) num) onum)) (den 1 (+ (* a den) oden)) (onum 1 num) (oden 0 den)) ((and (not (zerop den)) (not (> (abs (/ (- x (/ (float num x) (float den x))) x)) eps))) (/ num den)))))))  Received: from SCRC-RIVERSIDE.ARPA by SU-AI.ARPA with TCP; 27 Aug 84 06:39:58 PDT Received: from SCRC-CHICOPEE by SCRC-RIVERSIDE via CHAOS with CHAOS-MAIL id 21540; Mon 27-Aug-84 09:40:07-EDT Date: Mon, 27 Aug 84 09:40 EDT From: "Daniel L. Weinreb" Subject: Questions from M. Hagiya To: Wholey@CMU-CS-C.ARPA cc: common-lisp@SU-AI.ARPA In-Reply-To: Message-ID: <840827094009.0.DLW@CHICOPEE.SCRC.Symbolics> Date: Sun, 26 Aug 1984 23:03 EDT From: Skef Wholey The manual explicitly states (on page 90) that is is an error to invoke the thing that symbol-function returns if macro-p or special-form-p of that symbol is true. That seems lucid enough. No, I don't think that has anything to do with it. The thing returned is not a function, but that doesn't mean that you can't stick it back into a symbol and use that symbol as the name of a special form. I don't know if that's a legal complex number (the components are of different types), but I believe it's just as easy (perhaps easier) to make a reader accept #c(0.0l0 #.pi) instead of scream about it. Whether it's easy to make the reader do it wasn't the question, though. The question is one of language definition. I strongly suspect that all of the existing Common Lisp readers will accept that definition, since they probably use READ to parse after #c. I don't think anything should happen to *Standard-Input*. Consider a program (i.e. a file of Lisp code) that wants to query the user when it is loaded. In that case, leaving *Standard-Input* as is is useful. I can't think of any useful thing one could do with having *Standard-Input* be bound to the file. In Maclisp, it was quite standard to put (read) into a file in order to get the next form and manipulate it. The main motivation for doing that has been eliminated by the introduction of eval-when, but Maclisp programmers certainly expect (read) in a file to read from the file. I don't feel strongly either way, but it really should be specified. Would you please mail me, under separate cover, the Spice Lisp definition of "rationalize", if that's OK? Thanks. By the way, Gosper hasn't been working for PARC for some time; he works for Symbolics currently. He was confused by the term "alphadigit" in Table 22-3, apparently not having read the fine print at the bottom. I presume that the function alpha-char-p needs to reference *read-base* in order to function properly? No. The definition of Alpha-Char-P is straightforward enough. At the end: "Of the standard characters, the letters A through Z and a though z are alphabetic." I don't see at all how frobbing *Read-Base* can change this. Aha, now I remember. The real problem Hagiya was having is that alpha-char-p uses the term "alphabetic" one way, and Table 22-3 uses it a completely different way. This really needs to be fixed.  Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 27 Aug 84 06:27:02 PDT Received: from MIT-LISPM-25 by MIT-OZ via Chaosnet; 27 Aug 84 09:25-EDT To: common-lisp at SU-AI.ARPA Subject: Questions from M. Hagiya From: Pinhead Date: Mon, 27 Aug 84 09:23 EDT Message-ID: [Yow-259] Date: Mon, 27 Aug 84 08:57 EDT From: Robert A. Cassels To: DLW at SCRC-QUABBIN.ARPA, common-lisp at SU-AI.ARPA Re: Questions from M. Hagiya Date: Sun, 26 Aug 84 21:11 EDT From: "Daniel L. Weinreb" T. Yuasa and M. Hagiya of Kyoto University independently implemented Common Lisp for the Data General MV/10000. They had a number of questions about the definition of Common Lisp, .... How do you implement "rationalize"? (I didn't know off hand. By the way, this makes me suspect that these folks don't have a copy of the CMU sources.) Send them each a copy of Bill Gosper's continued-fractions paper. Send them DEFECTIVE LIFESTYLE ACCESTORIES in PLAID SAMSONITE steamer trunks!  Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 27 Aug 84 05:57:54 PDT Received: from SCRC-CUYAHOGA by WAIKATO via CHAOS with CHAOS-MAIL id 48137; Mon 27-Aug-84 08:57:31-EDT Date: Mon, 27 Aug 84 08:57 EDT From: "Robert A. Cassels" Subject: Questions from M. Hagiya To: DLW@SCRC-QUABBIN.ARPA, common-lisp@SU-AI.ARPA In-Reply-To: <840826211121.0.DLW@CHICOPEE.SCRC.Symbolics> Message-ID: <840827085735.2.CASSELS@CUYAHOGA.SCRC.Symbolics> Date: Sun, 26 Aug 84 21:11 EDT From: "Daniel L. Weinreb" T. Yuasa and M. Hagiya of Kyoto University independently implemented Common Lisp for the Data General MV/10000. They had a number of questions about the definition of Common Lisp, .... How do you implement "rationalize"? (I didn't know off hand. By the way, this makes me suspect that these folks don't have a copy of the CMU sources.) Send them each a copy of Bill Gosper's continued-fractions paper.  Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 26 Aug 84 20:25:35 PDT Received: ID ; Sun 26 Aug 84 23:03:48-EDT Date: Sun, 26 Aug 1984 23:03 EDT Message-ID: Sender: WHOLEY@CMU-CS-C.ARPA From: Skef Wholey To: "Daniel L. Weinreb" Cc: common-lisp@SU-AI.ARPA Subject: Questions from M. Hagiya Re: Questions from M. Hagiya If we evaluate (setf (symbol-function 'moshi) (symbol-function 'if)), does Common Lisp specify that this "works", i.e. that the symbol "moshi" (a Japanese word for "if") can now be used as the name-symbol of a special form, just as well as "if"? (I told him I thought the answer was "no", but it's not stated clearly in the manual.) The manual explicitly states (on page 90) that is is an error to invoke the thing that symbol-function returns if macro-p or special-form-p of that symbol is true. That seems lucid enough. Is this an example of legal syntax: #c(0 #.pi) I don't know if that's a legal complex number (the components are of different types), but I believe it's just as easy (perhaps easier) to make a reader accept #c(0.0l0 #.pi) instead of scream about it. Should the streams that are arguments to make-broadcast-stream, make-concatenated-stream, or make-echo-stream be of the same element type? I would say no. One can imagine that reading from a concatenated stream made of different bytes sizes could be put to some good use. What is the element type of "bit sink" (that is, make-broadcast-stream of no arguments)? (I told him that T seemed right to me, but agreed that the point needs clarification.) Also, what is the element type of a concatenated stream made of no streams? (I'm not sure it matters.) Using the AND'ing of types that Spice Lisp does, a Make-Broadcast-Stream of no streams can be thought to have an element type of (AND), which simplifies to T. AND of no arguments as a type specifier is not described, but interpreting the identity of that type specifier to be T seems right. If the reader sees a close-paren at top-level, must this signal an error, may it be ignored, or what? As a user, I would like to have this behavior on a switch. Spice Lisp ignores them, but Zetalisp (and the CLCP) signal errors. I've found the Zetalisp behavior generally annoying but sometimes helpful. While LOADing a file, what is the value of *standard-input*? (I told him that I thought for a character file it really ought to be the file stream, but the manual needs to say and doesn't. What should it be when the file is binary?) I don't think anything should happen to *Standard-Input*. Consider a program (i.e. a file of Lisp code) that wants to query the user when it is loaded. In that case, leaving *Standard-Input* as is is useful. I can't think of any useful thing one could do with having *Standard-Input* be bound to the file. Can a symbol be a function and a macro at the same time? (Of course I told him no. His internal representation is actually sort of set up to allow this, but of course the interpreter has to do exactly one thing with a form, so actually his implementation doesn't do anything unusual.) Allowing a symbol to be both a special form and a macro is useful however, so that things can be interepreted quickly and a portable code-analyzer can pick them apart. How do you implement "rationalize"? (I didn't know off hand. By the way, this makes me suspect that these folks don't have a copy of the CMU sources.) Perhaps they didn't dig far enough into SPNUM, which has other things like lisp-level code for bignum arithmetic that wouldn't necessarily interest other implementors. It's there, preceded by this comment: ;;; Thanks to Kim Fateman, who stole this function rationalize-float ;;; from macsyma's rational. Macsyma'a rationalize was written ;;; by the legendary Gosper (rwg). Gosper is now working for xerox ;;; at parc. Guy Steele said about Gosper, "He has been called the ;;; only living 17th century mathematician and is also the best ;;; pdp-10 hacker I know." So, if you can understand or debug this ;;; code you win big. He was confused by the term "alphadigit" in Table 22-3, apparently not having read the fine print at the bottom. I presume that the function alpha-char-p needs to reference *read-base* in order to function properly? No. The definition of Alpha-Char-P is straightforward enough. At the end: "Of the standard characters, the letters A through Z and a though z are alphabetic." I don't see at all how frobbing *Read-Base* can change this.  Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 26 Aug 84 18:40:58 PDT Received: from SCRC-CHICOPEE by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 79878; Sun 26-Aug-84 21:12:56-EDT Date: Sun, 26 Aug 84 21:11 EDT From: "Daniel L. Weinreb" Subject: Questions from M. Hagiya To: common-lisp@SU-AI.ARPA Message-ID: <840826211121.0.DLW@CHICOPEE.SCRC.Symbolics> T. Yuasa and M. Hagiya of Kyoto University independently implemented Common Lisp for the Data General MV/10000. They had a number of questions about the definition of Common Lisp, which they accumulated in a file. Hagiya presented me a hardcopy of this file when I visited them in Kyoto last month. I answered some of the questions, but there were others whose answer I either didn't know, or considered undefined. I told Hagiya that I would pass these questions through to the other Common Lisp designers, and that if there were an answer I would try to get it back to him. I have paraphrased most of the questions, both to correct the English and to clarity the intent (I discussed each question with Hagiya). (His English isn't bad at all; he even got the "BOA constructor" joke!) First, the questions that I think might reflect problems or ambiguities with the Common Lisp definition: If we evaluate (setf (symbol-function 'moshi) (symbol-function 'if)), does Common Lisp specify that this "works", i.e. that the symbol "moshi" (a Japanese word for "if") can now be used as the name-symbol of a special form, just as well as "if"? (I told him I thought the answer was "no", but it's not stated clearly in the manual.) In a defmacro argument list, (&whole w a b) presumably means that there must be exactly two arguments to the macro, which a and b will be bound to, and furthermore that w will be bound to the whole thing. By extension, (&whole w a) means that there must be exactly one argument, and so (&whole w) means that there must not be any arguments at all. If so, then the (&whole w) case is evidently useless, and if what you really want is to just have a macro that lets you examine the body yourself and doesn't play with argument lists, you need to do (&whole w &rest ignore) or something. Is this really the definition of Common Lisp? Is this an example of legal syntax: #c(0 #.pi) What do equal and equalp do for structures? (The same question came up on this mailing list recently. Hagiya asked "Are they obvious?", and since he and I agreed what the obvious definition must be, I told him yes. However, as we discussed, the manual doesn't tell.) Suppose we redeclare a structure (evaluate defstruct for a structure we've already defined), and a slot that had originally been declared non-read-only is redeclared to be read-only. Should the access function for that slot be deleted (fmakunbound'ed)? Should the streams that are arguments to make-broadcast-stream, make-concatenated-stream, or make-echo-stream be of the same element type? What is the element type of "bit sink" (that is, make-broadcast-stream of no arguments)? (I told him that T seemed right to me, but agreed that the point needs clarification.) Also, what is the element type of a concatenated stream made of no streams? (I'm not sure it matters.) If the reader sees a close-paren at top-level, must this signal an error, may it be ignored, or what? If only line-by-line I/O is supported, may the function "print" do a terpri after printing a form rather than before? (I am not completely sure what he means here, but I think the point was that the DG operating system is only allowing him to do line-at-a-time I/O, and the definition of "print" was not completely implementable in this framework.) While LOADing a file, what is the value of *standard-input*? (I told him that I thought for a character file it really ought to be the file stream, but the manual needs to say and doesn't. What should it be when the file is binary?) Now, in addition to these questions, he also had some particular comments, and some questions that I had no trouble answering but might indicate points at which the manual needs to be more explicit. The rest of this message consists of these comments and points; I consider these less important than the above, so if you're tired you can stop reading at this point. He feels that the algorithm to determine whether a type is a sub-type of another is vague, and feels it should be spelled out more. He says that it is specified that any structure is a sub-type of "structure", but "structure" is not in Table 4-1. The latter is true but I can't find where the former is stated. In 17.4, the parameters are referred to as "bit-array", although the data type specifier used in chapter 4 is "bit-vector". There is no error here as far as I can see, but apparantly Hagiya found it inconsistent. Can a symbol be a function and a macro at the same time? (Of course I told him no. His internal representation is actually sort of set up to allow this, but of course the interpreter has to do exactly one thing with a form, so actually his implementation doesn't do anything unusual.) Recovery from a name conflict in packages seems to be implementation-dependent. Can it be a fatal error? (Yes.) Can the value of the parameter "package" for package functions be a symbol or a string? (Yes, the manual is quite explicit about this.) How about *package*? (It has to be a package object, as returned by find-package. The manual is not particularly unclear, but might emphasize this point.) How do you implement "rationalize"? (I didn't know off hand. By the way, this makes me suspect that these folks don't have a copy of the CMU sources.) He had some confusion about parsing after #\. I do think the manual could be more explicit about the algorithm for deciding where the break after seeing #\. If the character set is ASCII, how do we represent ASCII control characters? (Implementation dependent. Their implementation currently uses #\^A, and I told him that I thought other implementations probably did exactly that as well.) He was confused by the term "alphadigit" in Table 22-3, apparently not having read the fine print at the bottom. I presume that the function alpha-char-p needs to reference *read-base* in order to function properly? What is the initial value of *default-pathname-defaults*? (Implementation dependent; the manual should say so explicitly.) They were also both quite confused about how to implement #,. I belive that the problems they were having are based on the issues that were discussed on this list recently. #, definitely needs better explanation.  Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 25 Aug 84 06:20:42 PDT Received: ID ; Sat 25 Aug 84 09:15:04-EDT Date: Sat, 25 Aug 1984 09:15 EDT Message-ID: Sender: FAHLMAN@CMU-CS-C.ARPA From: "Scott E. Fahlman" To: "Bernard S. Greenberg" Cc: alan@MIT-MC.ARPA, common-lisp@SU-AI.ARPA, guy.steele@CMU-CS-A.ARPA, Robert.Frederking@CMU-CS-CAD.ARPA Subject: Painful retraction In-reply-to: Msg of 23 Aug 1984 15:04-EDT from Bernard S. Greenberg What do you (Scott) think are similar situations "that would otherwise be an error" that are really parallel? For example, those implementations that add a new Instance data type to support flavors have to extend several of the basic operators to cover this new type. Implementations that have extra I/O options must extend the stream operators to take new keywords. Implemenations with new number types (continued fractions, anyone?) have to overload the arithmetic operators. And so on. It seems to me that the spirit of Common Lisp says that everything legal according to the manual ought to work in all implementations, and that the way you create a superset is to make combinations that are otherwise undefined work in some particular way. So it seems to me that Frederking's extension is technically legal, in that it wouldn't break any portable code and wouldn't fail to signal an error in those cases that are specifically required to signal an error. I also feel that it is unwise, because in the cases cited above it will be very clear to users that they are delaing with entities or combinations outside the base language, while users doing (SHIP-CAPTAIN NIL) might imagine that they are still within the portable standard. -- Scott  Received: from SCRC-RIVERSIDE.ARPA by SU-AI.ARPA with TCP; 24 Aug 84 15:28:41 PDT Received: from SCRC-CONCORD by SCRC-RIVERSIDE via CHAOS with CHAOS-MAIL id 21266; Thu 23-Aug-84 15:04:22-EDT Date: Thu, 23 Aug 84 15:04 EDT From: "Bernard S. Greenberg" Subject: Painful retraction To: Fahlman@CMU-CS-C.ARPA, Robert.Frederking@CMU-CS-CAD.ARPA cc: alan@MIT-MC.ARPA, common-lisp@SU-AI.ARPA, guy.steele@CMU-CS-A.ARPA In-Reply-To: Message-ID: <840823150432.6.BSG@CONCORD.SCRC.Symbolics> Date: Thu, 23 Aug 1984 13:56 EDT From: "Scott E. Fahlman" I don't think it would violate the standard for a particular implementation to return nil in this case -- this sort of extension in a situation that would otherwise be an error is generally allowed -- but I would strongly advocate that no implementor do this without a very good reason. Users of his system will come to depend on this trick, sacrificing portability without realizing it. I don't see any justification for such an extension. Extend CDR to take the successor of a number... how is that different? NIL is clearly not defined to be "a member of all data types" or similar. I think the proposed extension violates the spirit of Lisp. What do you (Scott) think are similar situations "that would otherwise be an error" that are really parallel?  Received: from SCRC-QUABBIN.ARPA by SU-AI.ARPA with TCP; 24 Aug 84 10:02:55 PDT Received: from SCRC-YANGTZE by SCRC-QUABBIN via CHAOS with CHAOS-MAIL id 74827; Thu 23-Aug-84 22:29:24-EDT Date: Thu, 23 Aug 84 22:30 EDT From: Carl Hoffman Subject: Type-checking structure references To: Robert.Frederking@CMU-CS-CAD.ARPA cc: Alan@MIT-MC.ARPA, Common-Lisp@SU-AI.ARPA, Guy.Steele@CMU-CS-A.ARPA In-Reply-To: Message-ID: <840823223017.2.CWH@YANGTZE.SCRC.Symbolics> Alan Bawden's version of defstruct has a feature whereby you can define new types from which to build structures, which can then be used as arguments to the defstruct :type option. You do this by telling defstruct how to construct, read from, and store into these types. So you could define your own defstruct type in which (ship-captain foo) turned into (if (null foo) nil (svref foo 7)) or whatever. Unfortunately, the defstruct :type option in Common Lisp is not extensible.  Received: from SCRC-QUABBIN.ARPA by SU-AI.ARPA with TCP; 24 Aug 84 09:30:24 PDT Received: from SCRC-EUPHRATES by SCRC-QUABBIN via CHAOS with CHAOS-MAIL id 74613; Thu 23-Aug-84 14:31:44-EDT Date: Thu, 23 Aug 84 14:32 EDT From: "David A. Moon" Subject: Painful retraction To: Robert.Frederking@CMU-CS-CAD.ARPA cc: guy.steele@CMU-CS-A.ARPA, common-lisp@SU-AI.ARPA, alan@MIT-MC.ARPA In-Reply-To: <1984.8.23.15.25.12.Robert.Frederking@cmu-cs-cad.arpa> Message-ID: <840823143232.2.MOON@EUPHRATES.SCRC.Symbolics> Date: Thursday, 23 August 1984 11:34:34 EDT From: Robert.Frederking@cmu-cs-cad.arpa I made the mental equivalent of a typo in my original question to Guy Steele, thus inadvertantly slandering DEC. What I meant to inquire about was that the *access functions* give fatal errors if handed nil, which is a more reasonable behavior (if still personally annoying). Thus, (ship-name nil) blows up, whereas I would prefer it to just return nil. I.e., it would be nice if nil were the "null structure", even though structures aren't (in VaxLisp) implemented as lists. So, I'll make a corrected version of my original question: would it be against the CommonLisp standard for an implementor to allow nils to pass through the automatically-defined access functions, even if structures are not implemented as lists? (A much less exciting question, I'm afraid.) Sounds like a bad idea to me. And why single out NIL? If this were done, it certainly should be an option to DEFSTRUCT that is not turned on by default, because only specialized applications would want it, and everyone else would prefer not to lose the error-checking.  Received: from CMU-CS-A.ARPA by SU-AI.ARPA with TCP; 23 Aug 84 19:35:05 PDT Date: 23 Aug 84 2234 EDT (Thursday) From: Guy.Steele@CMU-CS-A.ARPA To: frederking@CMU-CS-CAD.ARPA Subject: Retraction CC: common-lisp@SU-AI.ARPA Well, the others on this mailing list have provided various rationales for what *should* be the case. I will speak to the slightly different question of what *is* the case, which fortunately results in the same answer this time. I interpret the text explaining the ship example on page 306 of the Common LISP Manual as explicitly indicating that ship-x-position must have a ship as its argument. The manual fails to state the obvious generalization of thislater on (this is a general weakness of the way this chapter is organized, for which I am sorry). Nevertheless, I draw the indirect inference that a structure access function must receive an argument that is the type of structure for which it was defined, and anything else is an error. This means (page 5) that an implementation may do anything it chooses if a structure acess function is given a NIL, including returning NIL (though an error message is recommended), but no valid Common LISP program may depend on any particular behavior resulting from this situation. In practical terms, if you write code that depends on (ship-x-position nil) => nil, it will not be guaranteed portable. --Guy  Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 23 Aug 84 17:56:25 PDT Received: from Semillon.ms by ArpaGateway.ms ; 23 AUG 84 17:54:30 PDT Date: 23 Aug 84 17:51 PDT From: JonL.pa@XEROX.ARPA Subject: Re: Painful retraction In-reply-to: "Scott E. Fahlman" 's message of Thu, 23 Aug 84 13:56 EDT To: Fahlman@CMU-CS-C.ARPA cc: Robert.Frederking@CMU-CS-CAD.ARPA, alan@MIT-MC.ARPA, common-lisp@SU-AI.ARPA, guy.steele@CMU-CS-A.ARPA Your arguments about not wanting to do in-line type checking on stock hardware are valid in general, but one could probably special-case the NIL case without much loss. E.g. (ship-captain NIL) ==> exception handling. The real question is, would it be worth it just for NIL. If one implementation did it, there would be the strong temptation to write non-portable code, i.e., depending on (ship-captain NIL) ==> NIL, and such code couldn't be mechanically fixed. In view of this, either the standard should permit this exception case, or we should lobby hard to prevent it from being implemented in Common Lisp "dialects". -- JonL --  Received: from DEC-MARLBORO.ARPA by SU-AI.ARPA with TCP; 23 Aug 84 14:33:42 PDT Date: Thu 23 Aug 84 17:34:25-EDT From: "Walter van Roggen" Subject: structure references To: Robert.Frederking@CMU-CS-CAD.ARPA cc: common-lisp@SU-AI.ARPA With the proper declarations, something like SHIP-LENGTH does turn into one VAX instruction, and for speed cannot check for illegal or unusual arguments. Normally though it only checks that the arguments are structures (or simple-vectors). It would have checked that the type was correct, but since the type slot of a structure might only be a subtype of the type assumed in the reference, it would have had to do a SUBTYPEP (or the equivalent). ---Walter -------  Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 23 Aug 84 11:12:34 PDT Date: 23 August 1984 14:10-EDT From: Alan Bawden Subject: Painful retraction To: Robert.Frederking @ CMU-CS-CAD cc: common-lisp @ SU-AI, guy.steele @ CMU-CS-A In-reply-to: Msg of 23 Aug 1984 11:34:34 EDT from Robert.Frederking at cmu-cs-cad.arpa Date: Thursday, 23 August 1984 11:34:34 EDT From: Robert.Frederking at cmu-cs-cad I made the mental equivalent of a typo in my original question to Guy Steele, thus inadvertantly slandering DEC. I am in the habit of calling this a "thinko" or a "braino". What I meant to inquire about was that the *access functions* give fatal errors if handed nil, which is a more reasonable behavior (if still personally annoying).... I would oppose contracting access functions to any kind of behavior when not handed an actual instance of the structure. In some mail that just arrived this instant, I see that Fahlman has spared me the trouble of giving the arguments against it here.  Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 23 Aug 84 11:04:13 PDT Received: ID ; Thu 23 Aug 84 13:57:11-EDT Date: Thu, 23 Aug 1984 13:56 EDT Message-ID: Sender: FAHLMAN@CMU-CS-C.ARPA From: "Scott E. Fahlman" To: Robert.Frederking@CMU-CS-CAD.ARPA Cc: alan@MIT-MC.ARPA, common-lisp@SU-AI.ARPA, guy.steele@CMU-CS-A.ARPA Subject: Painful retraction In-reply-to: Msg of 23 Aug 1984 11:34-EDT from Robert.Frederking at cmu-cs-cad.arpa The access questions are another story. On stock hardware such as a Vax, it is essential that (ship-captain foo) expand into something tense like (svref foo 7), without supplying any helpful type-checking. IF the access code is not as fast as the user could get by hand, users will bypass the defstruct package altogether and revert to doing ugly things by hand. So it is not reasonable on a machine like the Vax to have (ship-captain nil) return nil and portable code should not depend on this. I don't think it would violate the standard for a particular implementation to return nil in this case -- this sort of extension in a situation that would otherwise be an error is generally allowed -- but I would strongly advocate that no implementor do this without a very good reason. Users of his system will come to depend on this trick, sacrificing portability without realizing it. -- Scott  Received: from CMU-CS-CAD.ARPA by SU-AI.ARPA with TCP; 23 Aug 84 08:36:17 PDT Date: Thursday, 23 August 1984 11:34:34 EDT From: Robert.Frederking@cmu-cs-cad.arpa To: guy.steele@cmu-cs-a.arpa cc: common-lisp@su-ai.arpa, alan@mit-mc.arpa Subject: Painful retraction Message-ID: <1984.8.23.15.25.12.Robert.Frederking@cmu-cs-cad.arpa> I made the mental equivalent of a typo in my original question to Guy Steele, thus inadvertantly slandering DEC. What I meant to inquire about was that the *access functions* give fatal errors if handed nil, which is a more reasonable behavior (if still personally annoying). Thus, (ship-name nil) blows up, whereas I would prefer it to just return nil. I.e., it would be nice if nil were the "null structure", even though structures aren't (in VaxLisp) implemented as lists. So, I'll make a corrected version of my original question: would it be against the CommonLisp standard for an implementor to allow nils to pass through the automatically-defined access functions, even if structures are not implemented as lists? (A much less exciting question, I'm afraid.) Sorry for the confusion. (Blush.) Bob  Received: from CMU-CS-A.ARPA by SU-AI.ARPA with TCP; 21 Aug 84 19:37:15 PDT Date: 21 Aug 84 2236 EDT (Tuesday) From: Guy.Steele@CMU-CS-A.ARPA To: Robert.Frederking@cmu-cs-cad.arpa Subject: Re: CommonLisp (vs. VaxLisp) question CC: common-lisp@SU-AI.ARPA In-Reply-To: <1984.8.20.18.1.32.Robert.Frederking@cmu-cs-cad.arpa> I have to agree that the manual needs clarification on the point of the behavior of DEFSTRUCT-defined predicates. I would intrepret the penultimate paragraph on page 306 as indicating by example that any object whatsoever may be given to SHIP-P (and by extension to any DEFSTRUCT-defined predicate). It would follow that the VaxLISP implementation is at fault. --Guy  Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 21 Aug 84 19:34:57 PDT Date: 21 August 1984 22:34-EDT From: Alan Bawden Subject: From Frederking To: common-lisp @ SU-AI, Robert.Frederking @ CMU-CS-CAD In-reply-to: Msg of 21 Aug 84 2201 EDT () from Guy.Steele at CMU-CS-A.ARPA In my original defstruct implementation of the predicate feature I naturally assumed that (SHIP-P NIL) would return NIL. It also seems quite clear to me that the manual requires this to be the case. I would say DEC VaxLisp defstruct has a bug.  Received: from CMU-CS-A.ARPA by SU-AI.ARPA with TCP; 21 Aug 84 19:01:29 PDT Date: 21 Aug 84 2201 EDT (Tuesday) From: Guy.Steele@CMU-CS-A.ARPA To: common-lisp@SU-AI.ARPA Subject: From Frederking - - - - Begin forwarded message - - - - Return-Path: Received: from CMU-CS-CAD.ARPA by CMU-CS-A.ARPA; 20 Aug 84 14:14:32 EDT Date: Monday, 20 August 1984 14:09:26 EDT From: Robert.Frederking@cmu-cs-cad.arpa To: guy.steele@cmu-cs-a.arpa Subject: CommonLisp (vs. VaxLisp) question Message-ID: <1984.8.20.18.1.32.Robert.Frederking@cmu-cs-cad.arpa> Hi. I've been doing some programming in DEC VaxLisp, and have found something annoying about the way they do structures. The way that the automatically-defined type predicates work, you get an error if you pass them nil. So, if you define a structure "ship", (ship-p nil) gives you an error. What I was wondering was whether this is required by the CommonLisp standard, or whether an implementor could allow nil to be the null structure. I can't really tell from the CommonLisp manual. The reason this is annoying is that I (and others) have a tendency to write code so that nils pass through without being detected. Getting errors when testing nils requires one either to screen for them, or write a predicate that screens out nils and calls the built-in predicate (kind of defeating its purpose). This has been the main problem in converting code to use structures that originally used lists. Let me know what you think. Thanks. Bob - - - - End forwarded message - - - -  Received: from TL-20A.ARPA by SU-AI.ARPA with TCP; 21 Aug 84 10:25:02 PDT Received: ID ; Tue 21 Aug 84 13:20:49-EDT Date: Tue 21 Aug 84 13:20:48-EDT From: STEELE@TL-20A.ARPA Subject: Strange encounter on the Indiana Tollway To: common-lisp@SU-AI.ARPA, phw@MIT-MC.ARPA, bkph@MIT-MC.ARPA At a rest stop on my way back from Chicago, I encountered an instance of yet another shoot-the-robots video arcade game by Williams called "Robotron 2084". Its idle (demo) mode included a lot of prose to set up the scenario as well as the usual flashy pictures. The general idea is that the nasty robotrons are out to kill all humans, and exactly one human family remains, consisting of Mommy, Daddy, and Mikey. You are a superhuman genetic mutant capable of shooting robots, and must save the last human family. There are half a dozen types of robotrons, and lurid text in shifting colors describes them in terms as titillating as possible while their abilities are demonstrated pictorially. For example, the ROBOTRONS attempt to destroy you. The HULK ROBOTRONS seek out and eliminate the last human family. The SPHEREOIDS [sic] and QUARKS manufacture ENFORCER and TANK ROBOTRONS. I will now quote the last frame verbatim: Beware the ingenious BRAIN ROBOTRONS which have the power to reprogram humans into sinister PROGS! --Guy -------  Received: from DEC-MARLBORO.ARPA by SU-AI.ARPA with TCP; 20 Aug 84 20:27:10 PDT Date: Mon 20 Aug 84 23:26:55-EDT From: "Walter van Roggen" Subject: Re: Requests for clarification To: RAM@CMU-CS-C.ARPA cc: STEELE@TL-20A.ARPA, common-lisp@SU-AI.ARPA, WVANROGGEN@DEC-MARLBORO.ARPA In-Reply-To: Message from "Rob MacLachlan " of Sat 18 Aug 84 19:25:45-EDT In general CLOSE should not close the component streams of a multiple stream. A typical case I've run across is when one briefly creates a broadcast stream that includes the terminal and a file. When the broadcast stream is closed, the component streams do not want to be closed, since they are likely to have uses beyond that of the broadcast stream. What's needed here is a function that takes a stream and returns a list of component streams (if any). ---Walter -------  Received: from SRI-SPAM.ARPA by SU-AI.ARPA with TCP; 20 Aug 84 11:39:20 PDT Received: by sri-spam.ARPA (4.22/4.16) id AA20096; Mon, 20 Aug 84 11:38:17 pdt Date: Mon, 20 Aug 84 11:38:17 pdt From: Scott J. Kramer Message-Id: <8408201838.AA20096@sri-spam.ARPA> Reply-To: sjk@sri-spam To: common-lisp@su-ai Subject: mailing list Can you please add "common-lisp@sri-spam" to your mailing list? Thanx! scott  Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 18 Aug 84 21:38:13 PDT Received: from SCRC-EUPHRATES by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 74303; Sun 19-Aug-84 00:38:27-EDT Date: Sun, 19 Aug 84 00:37 EDT From: "David A. Moon" Subject: Requests for clarification To: STEELE@TL-20A.ARPA cc: common-lisp@SU-AI.ARPA In-Reply-To: The message of 14 Aug 84 13:54-EDT from STEELE at TL-20A Message-ID: <840819003720.7.MOON@EUPHRATES.SCRC.Symbolics> Date: Tue 14 Aug 84 13:54:45-EDT From: STEELE@TL-20A.ARPA Some statement about "constant" list structures in compiled code needs to be made. Many implementations would like to place constant list structure, particularly constants in compiled code, in read-only memory. (MacLISP does this.) This would mean that an expression such as (nconc '(a b c) x) would be illegal, at least in a program to be compiled. I suggest that this be explicitly forbidden. I don't think the compiler should undertake to guarantee how much sharing of constant list structure with constants in the same or other functions it will do or not do. I also suggest that even constants created with #, be explicitly forbidden to be modified since after load time they cannot be distinguished from normal constants. Constants should not be used as a substitute for global variables, in my opinion.  Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 18 Aug 84 21:34:13 PDT Received: from SCRC-EUPHRATES by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 74301; Sun 19-Aug-84 00:34:22-EDT Date: Sun, 19 Aug 84 00:33 EDT From: "David A. Moon" Subject: Requests for clarification To: Rob MacLachlan cc: STEELE@TL-20A.ARPA, common-lisp@SU-AI.ARPA In-Reply-To: Message-ID: <840819003302.6.MOON@EUPHRATES.SCRC.Symbolics> Date: Sat, 18 Aug 1984 19:19 EDT From: Rob MacLachlan We haven't bothered too much yet about implementing the four types of multiple streams (broadcast, concatenated, two-way, and echo) since they are ill-specified and not terribly useful (i.e. we'll do them, but they aren't high priority). For a stream constructed with make-two-way-stream, what is the result of applying stream-element-type to the stream, especially if the element-types of the two underlying streams are different? In Spice Lisp, Stream-Element-Type returns an Or of the distinct stream element types for the component streams if they are different. obviously lazy implementor could return T. This seems reasonable to me. How does the close function operate on various non-primitive streams? For example, does close of a two-way stream close the two underlying streams? What about close of a concatenated stream? In Spice Lisp, closing any multiple stream results in closing all of the component streams. This seems reasonable to me, although I can think of arguments (from experience on Multics for instance) against it. As a concatenated stream hits eof on each subsidiary stream, are those subsidiary streams closed? Spice Lisp doesn't do this, and I think that's the right thing to do. In the case of a file stream, hitting eof doesn't necessarily make the stream useless, so you don't want to go around automatically closing the things. I assume that if you try to read past EOF on a subsidiary stream it advances to the next stream, but lets you FILE-POSITION back into earlier streams? Then none of the component streams are closed until the concatenated stream is closed. This seems reasonable. An explicit statement should be made as to how equal and equalp treat structures. DO structures fall under the general heading of "objects that have components"? There better dammn well be some predicate that works on structures, so I guess it's got to be equalp. I guess we could make equal work on structures as a special case, but that would have interactions with structure typedness. In our system EQUAL and EQUALP treat structures the same as arrays. This seems the most consistent with the manual pp.80-82. Thus EQUAL is never true for structures unless EQ is, and EQUALP is true for structures of the same type with the same components. This is all assuming you don't use the :TYPE option to DEFSTRUCT.  Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 18 Aug 84 16:21:59 PDT Received: ID ; Sat 18 Aug 84 19:20:03-EDT Date: Sat, 18 Aug 1984 19:19 EDT Message-ID: From: Rob MacLachlan To: STEELE@TL-20A.ARPA Cc: common-lisp@SU-AI.ARPA Subject: Requests for clarification In-reply-to: Msg of 14 Aug 1984 13:54-EDT from STEELE at TL-20A.ARPA For a stream constructed with make-two-way-stream, what is the result of applying stream-element-type to the stream, especially if the element-types of the two underlying streams are different? In Spice Lisp, Stream-Element-Type returns an Or of the distinct stream element types for the component streams if they are different. obviously lazy implementor could return T. How does the close function operate on various non-primitive streams? For example, does close of a two-way stream close the two underlying streams? What about close of a concatenated stream? In Spice Lisp, closing any multiple stream results in closing all of the component streams. As a concatenated stream hits eof on each subsidiary stream, are those subsidiary streams closed? Spice Lisp doesn't do this, and I think that's the right thing to do. In the case of a file stream, hitting eof doesn't necessarily make the stream useless, so you don't want to go around automatically closing the things. An explicit statement should be made as to how equal and equalp treat structures. DO structures fall under the general heading of "objects that have components"? There better dammn well be some predicate that works on structures, so I guess it's got to be equalp. I guess we could make equal work on structures as a special case, but that would have interactions with structure typedness. Rob  Received: from SCRC-QUABBIN.ARPA by SU-AI.ARPA with TCP; 18 Aug 84 11:23:53 PDT Received: from SCRC-EUPHRATES by SCRC-QUABBIN via CHAOS with CHAOS-MAIL id 72691; Sat 18-Aug-84 14:23:25-EDT Date: Sat, 18 Aug 84 14:23 EDT From: "David A. Moon" Subject: declarations in body of LABELS To: Steele@TL-20B.ARPA cc: Common-Lisp@SU-AI.ARPA Message-ID: <840818142354.4.MOON@EUPHRATES.SCRC.Symbolics> Pages 113 and 154 disagree about whether a declaration may appear in the body of a LABELS (or FLET or MACROLET). These forms do not bind variables, but I assume that page 154 is correct. Example: (LABELS ((FOO (X Y) (IF X (LIST X Y) Y))) (DECLARE (INLINE FOO)) (COND ((... (FOO 1 2) ...))))  Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 15 Aug 84 18:21:14 PDT Received: from Semillon.ms by ArpaGateway.ms ; 15 AUG 84 18:18:31 PDT Date: 15 Aug 84 18:18 PDT From: JonL.pa@XEROX.ARPA Subject: Re: bug in assoc In-reply-to: "smh@mit-ems"@MIT-MC.ARPA's message of 14 Aug 84 17:13:29 EDT To: "smh@mit-ems"@MIT-MC.ARPA cc: "mcgeer@ucbkim"@UCB-VAX.ARPA, franz-friends@UCB-VAX.ARPA, "jmiller@ct.csnet@udel-relay"@MIT-MC.ARPA, Common-Lisp@SU-AI.ARPA Common Lisp also faces the possibility of inconsistent system code due to the handling of cases marked "is an error" (see Manual, sec. 1.2.4); that is, it is undefined as to what happens if you apply CAR to a non-LISTP. All portable system code should therefore certify the type of a datum before taking car or cdr. ASSOC (and ASSQ) from the Franz sources clearly doesn't check the type of the arguments before carcdring away on them. Well, why not "all system code should certify the type before taking car/cdr . . . " -- it certainly can't hurt to "signal an error" rather than fall into some undefined morass. -- JonL --  Received: from TL-20A.ARPA by SU-AI.ARPA with TCP; 14 Aug 84 10:58:47 PDT Received: ID ; Tue 14 Aug 84 13:54:47-EDT Date: Tue 14 Aug 84 13:54:45-EDT From: STEELE@TL-20A.ARPA Subject: Requests for clarification To: common-lisp@SU-AI.ARPA The following requests for clarification were received from a few people at Data General: For a stream constructed with make-two-way-stream, what is the result of applying stream-element-type to the stream, especially if the element-types of the two underlying streams are different? Under make-concatenated-stream, it should be made clear (if it is indeed the case) that the resulting stream delivers to its clients only one eof, after the contents of all the subsidiary streams have been deleivered; the eofs from all but the last stream are not delivered. How does the close function operate on various non-primitive streams? For example, does close of a two-way stream close the two underlying streams? What about close of a concatenated stream? As a concatenated stream hits eof on each subsidiary stream, are those subsidiary streams closed? Some statement about "constant" list structures in compiled code needs to be made. Many implementations would like to place constant list structure, particularly constants in compiled code, in read-only memory. (MacLISP does this.) This would mean that an expression such as (nconc '(a b c) x) would be illegal, at least in a program to be compiled. An explicit statement should be made as to how equal and equalp treat structures. DO structures fall under the general heading of "objects that have components"? --Guy -------  Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 13 Aug 84 09:52:25 PDT Received: from SCRC-EUPHRATES by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 71058; Mon 13-Aug-84 00:57:57-EDT Date: Mon, 13 Aug 84 00:56 EDT From: "David A. Moon" Subject: Timezones offset by non-integral hours To: Common-Lisp@SU-AI.ARPA, decvax!mulga!bruce.csirovlsi@UCB-VAX.ARPA, bug-lispm@SCRC-RIVERSIDE.ARPA cc: common-lisp@SU-AI.ARPA In-Reply-To: Message-ID: <840813005637.1.MOON@EUPHRATES.SCRC.Symbolics> Date: Sat, 4 Aug 1984 02:56 EDT From: "Scott E. Fahlman" Date: Friday, 3 August 1984 02:29-EDT From: decvax!mulga!bruce.csirovlsi at Berkeley Re: Apparent Commonlisp stupidity On page 444 of "Common Lisp," the representation of timeZone in decoded time is defined as an integer specifying the number of hours west of GMT. However, significant parts of Australia and PNG are at +10:30, ie, on a half-hour boundary. Further, other parts of Australia, and some Pacific nations, are on 15 and 20 minute boundaries. Finally, at one time Tonga was +12:19:12, so that "The sun rose first on Tonga" and so that sol was directly and precisely overhead (on the mean) at noon. I believe that Common Lisp ought to allow the timezone to be a non-integral number of hours, accepting either a floating-point number or a ratio, as our implementation does. BUG-LISPM: Too bad this doesn't actually work in our implementation! The code looks like it used to work, and then someone "improved" the code for TIME:DECODE-UNIVERSAL-TIME-WITHOUT-DST to try to avoid excess consing by using fixnum-specific operations. We need to fix this. ...Perhaps what is needed is a formal zone name (integers fine; characters better) and also the local offset (hrs:mins:secs). We have some approximation to this, which has succeeded in convincing me that the world is not in sufficient agreement on names of timezones to justify enshrining any particular set of names in a standard language specification. On a lesser note, I believe that decoded time should include dayOfYear, weekOfYear, and leapYearP, because they were necessarily computed (or already available) to decode UT. Be complete and consistent when there's no extra cost, eh? I have no particular opinion about this. Also, I find that, in EncodeUT and DecodeUT, the treatment of daylight time and (local and other) zones is inconsistent. I agree and have already complained to Guy about this. I suspect it's just typographical errors in the manual, but he didn't reply to my queries. When we're done with this discussion we can address parameterization of the dates when daylight savings time turns on and off!  Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 13 Aug 84 09:52:25 PDT Received: from SCRC-EUPHRATES by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 71058; Mon 13-Aug-84 00:57:57-EDT Date: Mon, 13 Aug 84 00:56 EDT From: "David A. Moon" Subject: Timezones offset by non-integral hours To: Common-Lisp@SU-AI.ARPA, decvax!mulga!bruce.csirovlsi@UCB-VAX.ARPA, bug-lispm@SCRC-RIVERSIDE.ARPA cc: common-lisp@SU-AI.ARPA In-Reply-To: Message-ID: <840813005637.1.MOON@EUPHRATES.SCRC.Symbolics> Date: Sat, 4 Aug 1984 02:56 EDT From: "Scott E. Fahlman" Date: Friday, 3 August 1984 02:29-EDT From: decvax!mulga!bruce.csirovlsi at Berkeley Re: Apparent Commonlisp stupidity On page 444 of "Common Lisp," the representation of timeZone in decoded time is defined as an integer specifying the number of hours west of GMT. However, significant parts of Australia and PNG are at +10:30, ie, on a half-hour boundary. Further, other parts of Australia, and some Pacific nations, are on 15 and 20 minute boundaries. Finally, at one time Tonga was +12:19:12, so that "The sun rose first on Tonga" and so that sol was directly and precisely overhead (on the mean) at noon. I believe that Common Lisp ought to allow the timezone to be a non-integral number of hours, accepting either a floating-point number or a ratio, as our implementation does. BUG-LISPM: Too bad this doesn't actually work in our implementation! The code looks like it used to work, and then someone "improved" the code for TIME:DECODE-UNIVERSAL-TIME-WITHOUT-DST to try to avoid excess consing by using fixnum-specific operations. We need to fix this. ...Perhaps what is needed is a formal zone name (integers fine; characters better) and also the local offset (hrs:mins:secs). We have some approximation to this, which has succeeded in convincing me that the world is not in sufficient agreement on names of timezones to justify enshrining any particular set of names in a standard language specification. On a lesser note, I believe that decoded time should include dayOfYear, weekOfYear, and leapYearP, because they were necessarily computed (or already available) to decode UT. Be complete and consistent when there's no extra cost, eh? I have no particular opinion about this. Also, I find that, in EncodeUT and DecodeUT, the treatment of daylight time and (local and other) zones is inconsistent. I agree and have already complained to Guy about this. I suspect it's just typographical errors in the manual, but he didn't reply to my queries. When we're done with this discussion we can address parameterization of the dates when daylight savings time turns on and off!  Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 13 Aug 84 09:42:40 PDT Received: from SCRC-EUPHRATES by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 71053; Mon 13-Aug-84 00:44:21-EDT Date: Mon, 13 Aug 84 00:43 EDT From: "David A. Moon" Subject: *print-case* and *print-escape* To: Rob MacLachlan cc: common-lisp@SU-AI.ARPA In-Reply-To: Message-ID: <840813004306.0.MOON@EUPHRATES.SCRC.Symbolics> Date: Sun, 5 Aug 1984 14:09 EDT From: Rob MacLachlan Should *print-case* and *print-escape* interact? In says in the CLM is several places that when *print-escape* is NIL, a symbol is printed simply as the characters in its name. My belief is that this is just an oversight in the manual (text not updated when *print-case* was installed) and that the printer option variables should be handled orthogonally as much as possible. Thus (write 'foo :escape nil :case :downcase) should print a lowercase foo, as it does in our implementation. If I set *print-case* to :downcase because I like Unix and then do a (princ '|This is a program ported from MACLISP.|) should that print as: this is a program ported from maclisp. Yes. It's not Maclisp-compatible if *print-case* isn't :upcase.  Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 5 Aug 84 11:10:38 PDT Received: ID ; Sun 5 Aug 84 14:09:57-EDT Date: Sun, 5 Aug 1984 14:09 EDT Message-ID: From: Rob MacLachlan To: common-lisp@SU-AI.ARPA Subject: *print-case* and *print-escape* Should *print-case* and *print-escape* interact? In says in the CLM is several places that when *print-escape* is NIL, a symbol is printed simply as the characters in its name. If I set *print-case* to :downcase because I like Unix and then do a (princ '|This is a program ported from MACLISP.|) should that print as: this is a program ported from maclisp. Rob  Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 3 Aug 84 23:56:35 PDT Received: ID ; Sat 4 Aug 84 02:56:36-EDT Date: Sat, 4 Aug 1984 02:56 EDT Message-ID: Sender: FAHLMAN@CMU-CS-C.ARPA From: "Scott E. Fahlman" To: common-lisp@SU-AI.ARPA Subject: [decvax!mulga!bruce.csirovlsi: Apparent Commonlisp stupidity] Date: Friday, 3 August 1984 02:29-EDT From: decvax!mulga!bruce.csirovlsi at Berkeley Re: Apparent Commonlisp stupidity Apparently-To: fahlman@cmu-cs-a.arpa Scott, Please pass this on to the right forum. I think you'll find it sensible. On page 444 of "Common Lisp," the representation of timeZone in decoded time is defined as an integer specifying the number of hours west of GMT. However, significant parts of Australia and PNG are at +10:30, ie, on a half-hour boundary. Further, other parts of Australia, and some Pacific nations, are on 15 and 20 minute boundaries. Finally, at one time Tonga was +12:19:12, so that "The sun rose first on Tonga" and so that sol was directly and precisely overhead (on the mean) at noon. This is no laughing matter. If Arpa standards have defined Commonlisp's definition of timeZone, then we can blame them when a Commonlisp-based early-warning system at Pine Gap causes a launch-on-warning attack 1/2 hour before the Pentagon is notified. (Pine Gap, near the Alice, and Exmouth, on the Northwest Cape, are America's two shoot-first, ask-later bases in Oz.) No, I don't think this would really happen. But unless Arpa has constrained the definition, I think that Commonlisp's developers need to review timeZones using global time considerations. Perhaps what is needed is a formal zone name (integers fine; characters better) and also the local offset (hrs:mins:secs). Closer to reality, DEC's Commonlisp implementation will soon be running in a place with a half-hour offset. It will necessarily lie about its zone, and this will make it impossible to compute time differences properly. (Consider, for example, that the EST in this message is Australian, not Yank.) For comic relief, we can note that VMS is sucking even more air than usual here, as it STILL has no notion of zone or offset after six brain-damaged years. On a lesser note, I believe that decoded time should include dayOfYear, weekOfYear, and leapYearP, because they were necessarily computed (or already available) to decode UT. Be complete and consistent when there's no extra cost, eh? Also, I find that, in EncodeUT and DecodeUT, the treatment of daylight time and (local and other) zones is inconsistent. Despite the occasional levity, Scott, my tone is serious. It's easy to be parochial about time when there's three hours difference in an essentially closed world. Living outside the US has given me tremendous insight here. I'm ready for flak, but you'll miss unless you shoot on the half-hour. Cheers, Bruce (Nelson)  Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 27 Jul 84 12:44:23 PDT Received: from SCRC-EUPHRATES by SCRC-QUABBIN via CHAOS with CHAOS-MAIL id 67077; Fri 27-Jul-84 15:21:22-EDT Redistributed-date: Fri, 27 Jul 84 15:22 EDT Redistributed-to: common-lisp@SU-AI.ARPA Date: Fri, 27 Jul 84 13:38 EDT From: Moon@SCRC-RIVERSIDE.ARPA Subject: validation suite (Steve Ford) To: G.TI.CSL@UTEXAS-20.ARPA cc: common-lisp@SU-AI.ARPA In-Reply-To: The message of 27 Jul 84 09:23-EDT from G.TI.CSL at UTEXAS-20 Message-ID: <840727133853.7.MOON@EUPHRATES.SCRC.Symbolics> Date: Fri 27 Jul 84 08:23:35-CDT From: G.TI.CSL@UTEXAS-20.ARPA I am looking for programs developed to VALIDATE an implementation's conformance to the Common Lisp specification. Those with an aura of OFFICIALness, whatever that means, are preferable, but I will gladly accept all information, even rumors, about any such programs. I sent an unoffical program that checks just the division functions (of which there are more than ten in Common Lisp) to Richard Gabriel (RPG at SU-AI) for the yellow pages about ten months ago. You can ask him what happened to it. Thanks, Steve Ford G.TI.CSL@UTEXAS (Please include my name in the subject field of your reply.) Since most reply commands copy the subject, in the future you should include your name in the subject field of -your- message.  Received: from UTEXAS-20.ARPA by SU-AI.ARPA with TCP; 27 Jul 84 06:23:42 PDT Date: Fri 27 Jul 84 08:23:35-CDT From: G.TI.CSL@UTEXAS-20.ARPA Subject: validation suite To: common-lisp@SU-AI.ARPA I am looking for programs developed to VALIDATE an implementation's conformance to the Common Lisp specification. Those with an aura of OFFICIALness, whatever that means, are preferable, but I will gladly accept all information, even rumors, about any such programs. Thanks, Steve Ford G.TI.CSL@UTEXAS (Please include my name in the subject field of your reply.) -------  Received: from DEC-MARLBORO.ARPA by SU-AI.ARPA with TCP; 17 Jul 84 06:12:42 PDT Date: Tue 17 Jul 84 09:11:23-EDT From: "Walter van Roggen" Subject: Re: #, To: Fahlman@CMU-CS-C.ARPA cc: common-lisp@SU-AI.ARPA, WVANROGGEN@DEC-MARLBORO.ARPA In-Reply-To: Message from ""Scott E. Fahlman" " of Sun 15 Jul 84 12:49:24-EDT I think you misunderstood what I thought #, does. I didn't say that #, is self-quoting. Just as reading the number 3 isn't self-quoting, neither does #, have to be. I believe #,form represents the object returned by evaluating form at load time, not some expression which may evaluate to some object at load time. The problem here is that people have drawn the parallel with #. a bit too far. Unlike #. and other read macros, it isn't clear what #, expands int. I think we all agree what #, does inside data structures and that it's illegal as the first thing in a LET, for example. Allowing a #, where one would expect to evaluate an expression seems perfectly reasonable if one thinks of the #, modifying when and how often the form gets evaluate One might think of #, expanding into a form which the compiler can treat as a reference to a variable that gets initialized at load time. On a related issue, what does EVAL-WHEN return, when it did evaluate something, and when it didn't? ---Walter -------  Received: from CMU-CS-A.ARPA by SU-AI.ARPA with TCP; 16 Jul 84 20:57:22 PDT Date: 16 Jul 84 2357 EDT (Monday) From: Guy.Steele@CMU-CS-A.ARPA To: SCHUMACHER%hp-labs.csnet@csnet-relay.arpa Subject: Re: t, nil & the package system. CC: common-lisp@SU-AI.ARPA In-Reply-To: <8407092303.AA07498@HP-VENUS> I believe that t and nil, like all other symbols defined in the Common LISP Manual, must be in the lisp package (or at least accessible from it). It certainly is possible to shadow them, just as one may shadow CAR or COND. --Guy  Received: from CMU-CS-A.ARPA by SU-AI.ARPA with TCP; 16 Jul 84 20:55:51 PDT Date: 16 Jul 84 2355 EDT (Monday) From: Guy.Steele@CMU-CS-A.ARPA To: common-lisp@SU-AI.ARPA Subject: Forwarded mail - - - - Begin forwarded message - - - - Return-Path: Received: from CSNET-RELAY.ARPA by CMU-CS-A.ARPA; 10 Jul 84 13:33:56 EDT Received: From hp-labs.csnet by csnet-relay; 10 Jul 84 12:59 EDT Received: by HP-VENUS id AA07498; Mon, 9 Jul 84 16:03:06 pdt Message-Id: <8407092303.AA07498@HP-VENUS> Date: Mon 9 Jul 84 16:03:03-PDT From: SCHUMACHER%hp-labs.csnet@csnet-relay.arpa Subject: t, nil & the package system. To: guy.steele%cmu-cs-a@csnet-relay.arpa Source-Info: From (or Sender) name not authenticated. Guy, What is the home package of t and nil ?? Presuming that this package is in fact the lisp package, what happens when *package* is bound to package foo, which doesn't have the lisp package on its use-list ?? Will t print as lisp:t ?? Is it legal to shadow t or nil ?? -Lee (you can respond to les@cmu-c, I have the mail forwarding set...) ------- - - - - End forwarded message - - - -  Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 15 Jul 84 09:51:35 PDT Received: ID ; Sun 15 Jul 84 12:50:23-EDT Date: Sun, 15 Jul 1984 12:50 EDT Message-ID: Sender: FAHLMAN@CMU-CS-C.ARPA From: "Scott E. Fahlman" To: Walter van Roggen Cc: common-lisp@SU-AI.ARPA Subject: #, In-reply-to: Msg of 15 Jul 1984 11:54-EDT from Walter van Roggen Moon's proposal for #, and van Roggen's are both equally restricitve, I think. The question is simply one of whether the user is required to quote the expression containing the #, or whether #, quotes itself implicitly. It seems to me that Moon's proposal wins on three counts: 1. Under Moon's scheme, #, could be used in any context that wants a constant, not just within a (QUOTE ...) form. If #, supplies an implicit quote, that leads to double quoting if you use it in already-quoted contexts. 2. As Moon says, this is already in use in Zetalisp, so we may as well remain compatible with their convention. 3. If #, were to supply an implicit quote, it would no longer be analogous to #. Bugs and confusion would result. -- Scott  Received: from DEC-MARLBORO.ARPA by SU-AI.ARPA with TCP; 15 Jul 84 08:55:39 PDT Date: Sun 15 Jul 84 11:54:24-EDT From: "Walter van Roggen" Subject: #, To: common-lisp@SU-AI.ARPA "The intention is that #, can only be used in constants, not in forms." This seems unnecessarily restrictive. #, should act like a load-time constant. It can be used wherever a form would normally be evaluated. The form has to be evaluated at top-level. (DEFUN FOO (X) `(,X #,(PRINT "This prints at load time.") NON-EVALUATED)) (DEFUN BAR (X) (LIST X #,(PRINT "This too.") 'EVALUATED)) When loading these functions, it prints the messages, and then (FOO 3) ==> (3 "This prints at load time." NON-EVALUATED) (BAR 3) ==> (3 "This too." EVALUATED) The loader evaluates the form and stuffs the value as a constant in the compiled function object. ---Walter -------  Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 13 Jul 84 19:25:42 PDT Received: from SCRC-EUPHRATES by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 60666; Fri 13-Jul-84 22:26:49-EDT Date: Fri, 13 Jul 84 22:26 EDT From: "David A. Moon" Subject: the meaning of #, To: AS%hp-labs.csnet@CSNET-RELAY.ARPA Cc: COMMON-LISP@SU-AI.ARPA, AS@CSNET-RELAY.ARPA In-reply-to: <8407132020.AA10552@HP-VENUS> Date: 13 Jul 1984 1320-PDT From: AS%hp-labs.csnet@csnet-relay.arpa I am having a lot of trouble understanding the intended meaning of "#," in compiled code. I find it hard to believe that it is really intended to be like "#.", as the manual implies. In particular, the result of "#." in a form becomes PART OF the form. Thus, for example, you can do (DEFMACRO FOO #.(MUMBLE) ...) and the result of invoking MUMBLE is used as the parameter list to DEFMACRO. Similarly, if I say (SETQ X #.(MUMBLE)) and MUMBLE returns a list, then the list will be evaluated. Is the intent that "#," can be used this way (in compiled code), or can it be used only within quoted structures? Implementors: How have you implemented "#,"? Are there are restrictions on its use? If so, can they be stated clearly? This feature was taken from the Lisp Machine. The intention is that #, can only be used in constants, not in forms. For example, compiling a file containing the form (DEFUN FOO () #,BAR) gives an error. (DEFUN FOO () '#,BAR) works. Anything that the compiler actually has to process at compile time cannot be a #, since such objects do not exist until load time. I see what you mean about having a lot of trouble understanding it: the writeup on #, in the Common Lisp manual is even worse than the writeup on it in the Lisp Machine Manual.  Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 13 Jul 84 14:25:26 PDT Received: From hp-labs.csnet by csnet-relay; 13 Jul 84 17:21 EDT Received: by HP-VENUS id AA10552; Fri, 13 Jul 84 13:20:11 pdt Message-Id: <8407132020.AA10552@HP-VENUS> Date: 13 Jul 1984 1320-PDT From: AS%hp-labs.csnet@csnet-relay.arpa Subject: the meaning of #, To: COMMON-LISP@su-ai.arpa Cc: AS@csnet-relay.arpa Source-Info: From (or Sender) name not authenticated. I am having a lot of trouble understanding the intended meaning of "#," in compiled code. I find it hard to believe that it is really intended to be like "#.", as the manual implies. In particular, the result of "#." in a form becomes PART OF the form. Thus, for example, you can do (DEFMACRO FOO #.(MUMBLE) ...) and the result of invoking MUMBLE is used as the parameter list to DEFMACRO. Similarly, if I say (SETQ X #.(MUMBLE)) and MUMBLE returns a list, then the list will be evaluated. Is the intent that "#," can be used this way (in compiled code), or can it be used only within quoted structures? Implementors: How have you implemented "#,"? Are there are restrictions on its use? If so, can they be stated clearly? Thank you. -------  Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 13 Jul 84 14:23:43 PDT Received: From hp-labs.csnet by csnet-relay; 13 Jul 84 17:19 EDT Received: by HP-VENUS id AA08670; Fri, 13 Jul 84 11:17:35 pdt Message-Id: <8407131817.AA08670@HP-VENUS> Date: 13 Jul 1984 1118-PDT From: AS%hp-labs.csnet@csnet-relay.arpa Subject: extended tokens? To: Common-Lisp@su-ai.arpa Cc: AS@csnet-relay.arpa Source-Info: From (or Sender) name not authenticated. Section 22.1 sometimes talks about "extended tokens" which are presumably different than "tokens", but I do not see any explanation of what the difference is. Is a concept of "extended tokens" meaningful and useful or is this an artifact? -------  Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 11 Jul 84 19:26:27 PDT Received: from SCRC-EUPHRATES by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 60121; Wed 11-Jul-84 22:28:25-EDT Date: Wed, 11 Jul 84 22:25 EDT From: "David A. Moon" Subject: Pathname Questions To: Stan Shebs cc: common-lisp@SU-AI.ARPA In-Reply-To: The message of 30 Jun 84 18:24-EDT from Stan Shebs Message-ID: <840711222507.6.MOON@EUPHRATES.SCRC.Symbolics> Date: Sat 30 Jun 84 16:24:43-MDT From: Stan Shebs (Pardon this if it's been fixed since Excelsior, we don't have anything more recent here) You should go out to your nearest bookstore (that carries Digital Press books) and buy a few copies before they run out. Excelsior defines the pathname merging operation as taking a pathname, a defaults pathname, default type, and default version, while the merge-pathnames function does not take a default type as an option. Is this a mistake? If not, then how does one specify a default type for merging? These sound like typos; no doubt they're fixed in newer versions. Also, *load-pathname-defaults* is supposedly only a single pathname, however, it's very convenient to have a list of pathnames to search. This is very handy in PSL for loading modules, since you can search your own directory, the directory of new hacks, and the standard load module directory, in that order. Does the CL spec preclude using a list of pathnames in *load-pathname-defaults*? See the documentation of REQUIRE. LOAD is an operation on single files.  Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 10 Jul 84 10:04:27 PDT Received: From hp-labs.csnet by csnet-relay; 10 Jul 84 12:53 EDT Received: by HP-VENUS id AA29000; Mon, 9 Jul 84 09:55:49 pdt Message-Id: <8407091655.AA29000@HP-VENUS> Date: 9 Jul 1984 0955-PDT From: AS%hp-labs.csnet@csnet-relay.arpa Subject: Re: Query about IN-PACKAGE To: Guy.Steele%cmu-cs-a.arpa@csnet-relay.arpa Cc: AS@csnet-relay.arpa, Common-Lisp@su-ai.arpa In-Reply-To: Your message of 6-Jul-84 Source-Info: From (or Sender) name not authenticated. On second reading, I would no longer claim what I said in my previous message, although the text (pg. 183) probably should make it clearer that the :USE parameter to IN-PACKAGE defaults to '("LISP") ONLY if the package does not already exist, and otherwise defaults to NIL. The source of the confusion is the (conditional) statement that IN-PACKAGE is similar to MAKE-PACKAGE, which states that "if not supplied, :USE defaults to a list of one package, the LISP package". -------