Received: from SU-AI.ARPA by MIT-MC.ARPA; 8 MAY 85 14:33:59 EDT Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 8 May 85 11:20:35 PDT Received: ID ; Wed 8 May 85 14:19:28-EDT Date: Wed, 8 May 1985 14:19 EDT Message-ID: Sender: FAHLMAN@CMU-CS-C.ARPA From: "Scott E. Fahlman" To: Jon White Cc: common-lisp@SU-AI.ARPA Subject: ... point on a different point In-reply-to: Msg of 8 May 1985 12:19-EDT from Jon White Isn't the right decomposition of functionality here to have a system-supplied function called, say, READ-AND-DO-FILE-ATTRIBUTES; then LOAD would call it on source files, and lusers who have random data files would make the determination of attribute-information or data programmatically. If by "system-supplied" you mean a part of the Common Lisp specification, I don't think that we should elevate the current concept of file attributes and mode lines to the status of a language feature if we can possibly avoid this. To establish this convention by treaty among the suppliers of Common Lisps with Lisp-Machine-like environments would be OK, however. -- Scott  Received: from SU-AI.ARPA by MIT-MC.ARPA; 8 MAY 85 12:27:58 EDT Date: 08 May 85 0919 PDT From: Jon White Subject: ... point on a different point To: kmp@MIT-MC.ARPA CC: common-lisp@SU-AI.ARPA Re your message of 7-May-85 16:43 EDT in your defense of ;;; -*- Package:... ;;; my data file over ;;; my data file (in-package ...) you seem to be arguing as though the former happens at a level below READ, and is thus unambiguous, whereas th latter is ambiguous since the form (in-package ...) could be data for the application program. I don't see any such permission for READ mentioned in th CL manual. In fact, I have on numerous ocasions wanted to open a file and read character-by-character to get a "close" look at the first few lines; and then call READ. Isn't the right decomposition of functionality here to have a system-supplied function called, say, READ-AND-DO-FILE-ATTRIBUTES; then LOAD would call it on source files, and lusers who have random data files would make the determination of attribute-information or data programmatically. I.e., the mere act of opening a file, or reading from it, would not, by itself, do the READ-AND-DO-FILE-ATTRIBUTES; but th luser can call it, either at top-level, or from some lower-level program. -- JonL --  Received: from SU-AI.ARPA by MIT-MC.ARPA; 8 MAY 85 12:09:06 EDT Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 8 May 85 08:52:55 PDT Received: from CROW.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 232642; Wed 8-May-85 11:48:51-EDT Date: Wed, 8 May 85 11:53 EDT From: Robert W. Kerns Subject: Macros -> declarations To: Scott E. Fahlman cc: Kent M Pitman , common-lisp@SU-AI.ARPA In-Reply-To: Message-ID: <850508115301.3.RWK@CROW.SCRC.Symbolics.COM> Date: Tue, 7 May 1985 22:50 EDT From: "Scott E. Fahlman" Is there any hope that we can all agree on flushing macro -> declaration expansion and replacing it with something like Skef's "declaration macro" proposal? You state that this is the minimum acceptable position (minimun acceptable amount of hair, I guess), and for me it's about the maximum acceptable position. It would seem to cover about 99% of the cases where people claim that they need the macro expansion. Might I suggest another proposal that I think adds less complexity for the same gain (for either side of the issue)? Instead of DECLARE forms being allowed to be macros, why not allow the forms INSIDE declare forms be macros? Using macros rather than "declaration macros" lets you then use macrolet, and avoids the need for any new "DEFDECLARE" special forms to document or implement. This doesn't quite cover the bases, though, unless we also deal with expanding into multiple declarations [i.e. (REGISTER X) -> (SPECIAL X) (FIXNUM X)]. I'll propose two ways to deal with that. 1) Allow (DECLARE (FOO X) ((SPECIAL X) (FIXNUM X))) to mean the same as (DECLARE (FOO X) (SPECIAL X) (FIXNUM X)) 2) Allow (DECLARE (FOO X) (DECLARE (SPECIAL X) (FIXNUM X))). I.e. Allow DECLARE as a declaration containing declarations.  Received: from SU-AI.ARPA by MIT-MC.ARPA; 8 MAY 85 11:52:09 EDT Date: 08 May 85 0835 PDT From: Jon White Subject: PARSE-BODY To: gls%aquinas@THINK.ARPA CC: common-lisp@SU-AI.ARPA Re your message of 6-May-85 11:43 EDT About a year and a half ago, I wrote such a internal utility for Interlisp-D. Then I discovered that Ron Kaplan had also written a similar utility a year or two prior. The unfortunate thing is that neither of us managed to get our "utilty" promoted to user-level status, and docmented for all to use and not re-invent. Isn't it about time for somebody in the Common Lisp community to implement it, and put it into (at least) the yellow pages? Once that is done, then the only argument against macro-expansions producing DECLAREs and docmentation-strings is the potential for confusion with side-effect-producing macros. I'm in favor of ignoreing this problem (worrying about multiple side-effects from macro expansions) but some others are more concerned. -- JonL --  Received: from SU-AI.ARPA by MIT-MC.ARPA; 8 MAY 85 01:46:16 EDT Received: from NRL-AIC.ARPA by SU-AI.ARPA with TCP; 7 May 85 22:37:04 PDT Message-Id: <8505080536.AA10133@nrl-aic> Date: 7 May 1985 22:16:42 EDT (Tue) From: Dan Hoey Subject: Re: SETF of APPLY To: common-lisp@SU-AI.ARPA I like Guy's new text much more than the existing page 96, and after reading Moon's code I believe it almost states the criterion for a setf-applyable function correctly. The problem is that it obscures with faint emphasis its major point. I read the statement: The SETF method for the function must be such that the expansion of (SETF ( ... ) ) uses the form (or the generated variable that fronts for it) only as the last argument in some number of function calls ( ... ) <1> as the definition for a setf-applyable function, and the statement Every such function call in the expansion is altered to be (APPLY #' ... ) <2> as the beginning of an explanation of what it does. But by examining the code I realize that the latter statement is the main point: that when those forms <1> get alterated to <2> their semantics must change analogously to the alteration of ( ... ) to (APPLY #' ... ) or the SETF will do something bizarre. For instance, if has required arguments and turns out to be NIL, the expansion will be in error. Forgive the impulsive radicality of a neophyte but I think this restriction needs an explanation that is not feasible until SETF methods are introduced. I would much rather see page 96 say something like o A call to APPLY of the form (APPLY #' {arg}* ) where , has a ``SETF method'' amenable to APPLY, as described at the end of this section. The only functions whose SETF expansions are defined by Common Lisp to have this form are AREF, BIT, and SBIT. As an example, suppose that the variable INDEXES .... Then somewhere around page 106 the real bag of worms can be dumped on the table: When (APPLY #' ... ) is used as a generalized variable, the SETF method for APPLY will access the SETF method for with exactly arguments: (GET-SETF-METHOD '( ... )) that is, with the final argument to APPLY--and thus a list of final arguments to --replaced by a single final argument to . The storing and accessing forms returned by the SETF method must refer to the temporary variable corresponding to only as the last argument to a function: ( ... ) Each such function call will be altered when used in the SETF method of APPLY to be (APPLY #' ... ) replacing the final argument to by a list of final arguments. For (APPLY #' ... ) to be used as a generalized variable to be meaningful, the transformation described above must produce a correct SETF method for it. I think it important that ... be guaranteed to be passed verbatim in case their structure matters. It might help to put the actual code for the APPLY SETF method in. Further desiderata: I wish there were some way for the author to declare that a SETF method is or is not amenable to APPLY, and for a SETF method to determine whether it is expanding for APPLY. This might be done by promising that APPLY's SETF method will use `(:MORE-ARGS ,(gensym)) for above. Shouldn't 's SETF method to be restricted to at most required and optional arguments, modulo destructuring? Should (SETF (APPLY #'AREF (CONS FOO INDEXES)) NEWVALUE) be allowed, or should it be required to be written (SETF (APPLY #'AREF FOO INDEXES) NEWVALUE) as on page 97? As it is, the code apparently works for the former only by the accident that the SETF method for AREF could be (or is?) defined with only an &REST argument: (DEFINE-SETF-METHOD AREF (&REST AREF-FORM) (LET ((STORE (GENSYM)) (AREF-FORM-TEMP (LOOP FOR ARGUMENT IN AREF-FORM COLLECT (GENSYM)))) (VALUES AREF-FORM-TEMP AREF-FORM (LIST STORE) `(ASET ,STORE ,@AREF-FORM-TEMP) `(AREF ,@AREF-FORM-TEMP)))) Dan  Received: from SU-AI.ARPA by MIT-MC.ARPA; 7 MAY 85 22:58:10 EDT Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 7 May 85 19:50:50 PDT Received: ID ; Tue 7 May 85 22:50:34-EDT Date: Tue, 7 May 1985 22:50 EDT Message-ID: Sender: FAHLMAN@CMU-CS-C.ARPA From: "Scott E. Fahlman" To: Kent M Pitman Cc: common-lisp@SU-AI.ARPA Subject: Macros -> declarations In-reply-to: Msg of 7 May 1985 15:17-EDT from Kent M Pitman OK, I never doubted that people could make up cases where this macro -> declare expansion appears to be useful. I just doubted that it really would be an important mechanism in practice, or at least important enough to justify the pain it causes. Is there any hope that we can all agree on flushing macro -> declaration expansion and replacing it with something like Skef's "declaration macro" proposal? You state that this is the minimum acceptable position (minimun acceptable amount of hair, I guess), and for me it's about the maximum acceptable position. It would seem to cover about 99% of the cases where people claim that they need the macro expansion. I agree that if taken to the logical extreme, this proliferation of specialized macro-like forms is bad news. On the other hand, one might argue that macroexpanding potential declarations is also the start of a slippery slide that, if taken to the logical extreme, could be equally disastrous. Maybe we could try to solve the problem at hand and agree that taking things to their logical extremes is probably a bad idea in a language this complex and this full of compromises. -- Scott  Received: from SU-AI.ARPA by MIT-MC.ARPA; 7 MAY 85 17:02:03 EDT Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 7 May 85 13:49:52 PDT Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 232132; Tue 7-May-85 16:43:19-EDT Date: Tue, 7 May 85 16:44 EDT From: Kent M Pitman Subject: Read macros vs. macro-->declare To: Rem%IMSSS@SU-SCORE.ARPA, COMMON-LISP@SU-AI.ARPA In-Reply-To: The message of 7 May 85 16:19-EDT from Rem@IMSSS Message-ID: <850507164439.9.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> Date: 7 May 1985 1319-PDT From: Rem@IMSSS Subject: Read macros vs. macro-->declare To: COMMON-LISP%SU-AI@SCORE ... would it be feasible to have a continuation read-macro that produces a scheme-style continuation that gets evaluated the first time anybody tries to perform an operation upon it, even a trivial one like PAIRP? You're already (implicitly) performing "an operation" upon it if you assume the expression is code at all. The bad part about readmacros is that they force me to think "language semantics" at times when I might only want to think "symbol manipulation". eg, I can't write an editor utility which calls normal READ to get (DEFUN FOO (X) #+LISPM X #-LISPM (1- X)) out of the buffer, manipulate the expression, and PRINT it back into the buffer with any hope it that it will run on a system with different characteristics than those I used to edit it. Here the expression is not code but data. Something along the lines of (DEFUN FOO (X) (IF-FEATURE LISPM X (1- X))) works much better because you can READ-manipulate-PRINT it all day without worrying that it's code, then can READ-COMPILE-FASDUMP or READ-ABSORB-EXECUTE the processed code in some other system than you did the original processing in without fear that you've lost a read conditional. By the way, this made me think of an interesting point on a slightly different point, which is that one might imagine files full of (non-program) symbolic data which want to be read in certain package, but which because it will never be EVAL cannot use the IN-PACKAGE strategy. That's another example of inferring too strongly that anything that will be seen by READ must be code and another argument for -*- ... Package: ... -*- rather than IN-PACKAGE. ie, I'd rather use ;;; -*- Package: KEYWORD; -*- ;;; My data file (3 FOO BAR 7) (16.0 3/7 (X Y Z)) and be able to just repeatedly call READ on the file contents than continually do some kludge to look for an IN-PACKAGE form at the head of data files, as in: ;;; My data file (IN-PACKAGE "KEYWORD") (3 FOO BAR 7) (16.0 3/7 (X Y Z)) or worse (IN-PACKAGE "JOE") (EXPORT '(...)) (3 FOO BAR 7) where it might be ambiguous whether EXPORT, etc. are part of the package spec or part of the data. -kmp  Received: from SU-AI.ARPA by MIT-MC.ARPA; 7 MAY 85 16:28:26 EDT Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 7 May 85 13:19:18 PDT Received: from IMSSS by Score with Pup; Tue 7 May 85 13:19:08-PDT Date: 7 May 1985 1319-PDT From: Rem@IMSSS Subject: Read macros vs. macro-->declare To: COMMON-LISP%SU-AI@SCORE I agree that read macros aren't the right thing, i.e. something like #(FOO ...) expanding at read time into (DECLARE (SPECIAL FROB) (INTEGER FROB)) loses because it forces the macro-expansion environment to be the read environment instead of the compiler environment, which may not be exactly the same. But would it be feasible to have a continuation read-macro that produces a scheme-style continuation that gets evaluated the first time anybody tries to perform an operation upon it, even a trivial one like PAIRP? Then you could with this single facility have macros that expanded into arglists, or into declarations, or into arbitrary sequences of forms spliced into bodies of functions, or into COND clauses, or into function names, or into type names, or into any other sub-expression or splice-list? The programmer would have to be careful not to try to do an operation on the continuation-ptr until such time as the correct macro-expansion operation is in effect. -------  Received: from SU-AI.ARPA by MIT-MC.ARPA; 7 MAY 85 15:31:27 EDT Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 7 May 85 12:20:52 PDT Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 232005; Tue 7-May-85 15:16:41-EDT Date: Tue, 7 May 85 15:17 EDT From: Kent M Pitman Subject: Macros -> declarations To: Fahlman@CMU-CS-C.ARPA, BSG@TENEX.SCRC.Symbolics.COM cc: common-lisp@SU-AI.ARPA In-Reply-To: Message-ID: <850507151759.3.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> Date: Tue, 7 May 1985 10:18 EDT From: "Scott E. Fahlman" Date: Tue, 7 May 85 08:51 EDT From: Bernard S. Greenberg I don't buy this as a counterargument to what KMP said. Subsitute "DEFUN" for "DECLARE" in the above paragraph. You can only define functions with DEFUN -- (generic)Lisp provides no other way. Yet, we have the whole top-level macro mechanism to allow you to define application-language-embedded function-definers, calls to whom are expanded at top-level to ultimately produce DEFUNs. DECLARE is the only way to declare things lexically. The same arguments apply. I guess I didn't make myself clear. I understand that macros are able to provide suitable disguises for anything that takes the form of a list to be evaluated, such as DEFUN, and that this is useful in creating embedded sublanguages with a LIsp-like syntax. My point was that we do not have anything like macros for disguising "structural" items that are not in the form of lists to be evaluated: argument lists, things like &optional, T and NIL, certain keywords, declarations, components of declarations, doc strings, and so on. Various parts of the interpreter look for such things verbatim, without doing any macro-expansion of objects or structures that might turn into the item being sought. I guess the issue is whether you think of DECLARE as "structural". Consider: (DEFMACRO FROB (WIDGET) (COND ((> MOST-NEGATIVE-FIXNUM something) ...expansion that assumes WIDGET was represented as a fixnum...) (T ...expansion that assumes WIDGET was represented as a list...))) (DEFMACRO DECLARE-WIDGET (&REST NAMES) `(DECLARE (TYPE ,(IF (> MOST-NEGATIVE-FIXNUM something) 'FIXNUM 'LIST) ,@NAMES))) (DEFUN FOO (X) (DECLARE-WIDGET X) ... (FROB X) ...) Certainly I need as a minimum the ability to do this. It is not reasonable (as you seem to be proposing) that I should have to do: (DEFMACRO DEFINE-WIDGET-OPERATION (NAME BVL &BODY FORMS) `(DEFUN FOO ,BVL (DECLARE ...hair to parse &WIDGET keywords in BVL or DECLARE-WIDGET magic at head of FORMS...) ,@FORMS)) since it is not compositional -- ie, if I have a similar DEFINE-GIZMO-OPERATION macro, I cannot easily define something which frobs both gizmos and widgets. Hence, I claim the declaration is not structural in the sense that, for example, a COND clause is. By the way, Macsyma does this sort of thing with read-conditionals because languages don't allow it the flexibility to do it any other way. I hope I don't have to explain to you how and why this offends me. By the way, Skef's proposal (for "declaration macros") handles this problem, too. I'm just a little skeptical about a special-purpose declaration macro just for this context. Certainly it is the minimum potentially acceptable position, since it at least tries to address the issues I'm raising rather than sweeping them under the rug. I'm a little afriad that next people will want COND macros and LAMBDA macros (oops, the LispM has them already) and ... but I might yet be willing to yield to the suggestion of these declaration macros -- I'm still thinking about it in light of some of the problems I mentioned in my last message. That's good for efficiency, particularly in the presence of MACROLET, and gives the human reader of Lisp code at least a few stable landmarks to hold on to. The price is that if you really want to monkey around with these structural things in an embedded language, you have to transform the whole surrounding form and not just the item itself. To me that seems like a reasonable price for those people who want an embedded language that departs from Lisp syntax in such a deep way. If you get rid of parentheses or prefix notation or argument lists, you'll have to do a transformation on the whole form anyway; I'm just saying that we could reasonably consider declarations to be something basic to the syntax of the language, like argument lists, rather than thinking of them as a funny kind of body form. Just because (DECLARE ...) looks like any old lisp form, that doesn't mean we have to treat it as one. I just don't buy this claim that it's an efficiency issue. Moon's recent messages claims this was done efficiently on the Lisp Machine. Experience with Scheme likewise suggests this can be done efficiently. You only have to do it once when the form is first seen by the interpreter and never again. There's no loss of efficiency there. In fact (leaving aside the question of macrofied declares for the context of this sentence), if you are lazily or repeatedly expanding macros, you're risking having a function change its behavior in midstream on any expression involving macros, which I'd claim is a violation of the maxim that interpreted and compiled code should execute the same for legal expressions.  Received: from SU-AI.ARPA by MIT-MC.ARPA; 7 MAY 85 14:49:46 EDT Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 7 May 85 11:38:56 PDT Received: ID ; Tue 7 May 85 14:08:50-EDT Date: Tue, 7 May 1985 10:18 EDT Message-ID: Sender: FAHLMAN@CMU-CS-C.ARPA From: "Scott E. Fahlman" To: "Bernard S. Greenberg" Cc: common-lisp@SU-AI.ARPA Subject: Macros -> declarations In-reply-to: Msg of 7 May 1985 08:51-EDT from Bernard S. Greenberg I don't buy this as a counterargument to what KMP said. Subsitute "DEFUN" for "DECLARE" in the above paragraph. You can only define functions with DEFUN -- (generic)Lisp provides no other way. Yet, we have the whole top-level macro mechanism to allow you to define application-language-embedded function-definers, calls to whom are expanded at top-level to ultimately produce DEFUNs. DECLARE is the only way to declare things lexically. The same arguments apply. I guess I didn't make myself clear. I understand that macros are able to provide suitable disguises for anything that takes the form of a list to be evaluated, such as DEFUN, and that this is useful in creating embedded sublanguages with a LIsp-like syntax. My point was that we do not have anything like macros for disguising "structural" items that are not in the form of lists to be evaluated: argument lists, things like &optional, T and NIL, certain keywords, declarations, components of declarations, doc strings, and so on. Various parts of the interpreter look for such things verbatim, without doing any macro-expansion of objects or structures that might turn into the item being sought. That's good for efficiency, particularly in the presence of MACROLET, and gives the human reader of Lisp code at least a few stable landmarks to hold on to. The price is that if you really want to monkey around with these structural things in an embedded language, you have to transform the whole surrounding form and not just the item itself. To me that seems like a reasonable price for those people who want an embedded language that departs from Lisp syntax in such a deep way. If you get rid of parentheses or prefix notation or argument lists, you'll have to do a transformation on the whole form anyway; I'm just saying that we could reasonably consider declarations to be something basic to the syntax of the language, like argument lists, rather than thinking of them as a funny kind of body form. Just because (DECLARE ...) looks like any old lisp form, that doesn't mean we have to treat it as one. -- Scott  Received: from SU-AI.ARPA by MIT-MC.ARPA; 7 MAY 85 14:27:40 EDT Received: from SCRC-RIVERSIDE.ARPA by SU-AI.ARPA with TCP; 7 May 85 11:17:45 PDT Received: from CONCORD.SCRC.Symbolics.COM by SCRC-RIVERSIDE.ARPA via CHAOS with CHAOS-MAIL id 38048; Tue 7-May-85 08:47:43-EDT Date: Tue, 7 May 85 08:51 EDT From: Bernard S. Greenberg Subject: Macros -> declarations To: Fahlman@CMU-CS-C.ARPA, KMP@STONY-BROOK.SCRC.Symbolics.COM cc: common-lisp@SU-AI.ARPA In-Reply-To: Message-ID: <850507085122.9.BSG@CONCORD.SCRC.Symbolics.COM> Date: Mon, 6 May 1985 21:56 EDT From: "Scott E. Fahlman" The business about wanting to be able to shadow LISP:DECLARE seems pretty weak to me. He's hardly shadowing Lisp:declare.... It seems reasonable to me that if people want to redefine the essential structural symbols like DECLARE out from under Common Lisp, then they should either be willing to say something like LISP:DECLARE to get the old version or do a source-level transformation on the surrounding form. There are a number of other structural symbols, in addition to DECLARE, that are known to the interpreter, and we can't very well macroexpand everything in sight in order to see if we have one of these. -- Scott I don't buy this as a counterargument to what KMP said. Subsitute "DEFUN" for "DECLARE" in the above paragraph. You can only define functions with DEFUN -- (generic)Lisp provides no other way. Yet, we have the whole top-level macro mechanism to allow you to define application-language-embedded function-definers, calls to whom are expanded at top-level to ultimately produce DEFUNs. DECLARE is the only way to declare things lexically. The same arguments apply.  Received: from SU-AI.ARPA by MIT-MC.ARPA; 6 MAY 85 22:05:01 EDT Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 6 May 85 18:57:04 PDT Received: ID ; Mon 6 May 85 21:56:46-EDT Date: Mon, 6 May 1985 21:56 EDT Message-ID: Sender: FAHLMAN@CMU-CS-C.ARPA From: "Scott E. Fahlman" To: Kent M Pitman Cc: common-lisp@SU-AI.ARPA Subject: Macros -> declarations In-reply-to: Msg of 6 May 1985 20:41-EDT from Kent M Pitman The business about wanting to be able to shadow LISP:DECLARE seems pretty weak to me. It seems reasonable to me that if people want to redefine the essential structural symbols like DECLARE out from under Common Lisp, then they should either be willing to say something like LISP:DECLARE to get the old version or do a source-level transformation on the surrounding form. There are a number of other structural symbols, in addition to DECLARE, that are known to the interpreter, and we can't very well macroexpand everything in sight in order to see if we have one of these. -- Scott  Received: from SU-AI.ARPA by MIT-MC.ARPA; 6 MAY 85 21:41:37 EDT Received: from RUTGERS.ARPA by SU-AI.ARPA with TCP; 6 May 85 18:28:55 PDT Date: 6 May 85 21:29:06 EDT From: Charles Hedrick Subject: Re: SETF (APPLY To: Moon@SCRC-STONY-BROOK.ARPA cc: common-lisp@SU-AI.ARPA In-Reply-To: Message from "David A. Moon " of 6 May 85 21:04:00 EDT I believe that we have two separate cases, each of which can be described without implementation-dependent cruft: (1) builtin SETF things. In this case there is a finite list, and we should say which of these forms should work with SETF (APPLY. (2) user defined SETF's. I believe that the most common cases are those where the original language as in the manual works, except instead of saying that they expand to the form (storefn zi1 .. zm), say that the expansion is defined by a DEFSETF whose body is of that form. (Probably that is what the original author was thinking.) Again, you may want to suggest that other forms may be supported if possible, but I believe the definition should be in terms of what the user writes, not the actual expansion. -------  Received: from SU-AI.ARPA by MIT-MC.ARPA; 6 MAY 85 21:12:34 EDT Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 6 May 85 18:04:38 PDT Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 231446; Mon 6-May-85 21:00:53-EDT Date: Mon, 6 May 85 21:04 EDT From: David A. Moon Subject: SETF (APPLY To: Charles Hedrick cc: common-lisp@SU-AI.ARPA In-Reply-To: The message of 6 May 85 20:44-EDT from Charles Hedrick Message-ID: <850506210428.6.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: 6 May 85 20:44:26 EDT From: Charles Hedrick The problem with the current definition is that it depends upon the implementation. Rather than kludging up the definition more so that it properly describes hairier implementations of SETF, how about simply saying that SETF (APPLY must work for AREF, BITS, and SBITS, if those are the only useful cases. Wait a minute. Those may be the only useful cases among the functions listed in Common Lisp: The Language, but that doesn't mean that there aren't user-defined functions that are equally as useful to SETF APPLY. This is Lisp, the supposedly extensible and consistent language.  Received: from SU-AI.ARPA by MIT-MC.ARPA; 6 MAY 85 21:12:12 EDT Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 6 May 85 17:58:29 PDT Received: ID ; Mon 6 May 85 20:58:16-EDT Date: Mon, 6 May 1985 20:58 EDT Message-ID: Sender: WHOLEY@CMU-CS-C.ARPA From: Skef Wholey To: Kent M Pitman Cc: common-lisp@SU-AI.ARPA, gls%AQUINAS@THINK.ARPA, Moon@SCRC-STONY-BROOK.ARPA Subject: Macros -> declarations In-reply-to: Msg of 6 May 1985 20:41-EDT from Kent M Pitman Date: Monday, 6 May 1985 20:41-EDT From: Kent M Pitman Re: Macros -> declarations For example, you couldn't use MACROLET to create a local declaration type. We'd either need a DECLARATION-LET special form or we'd have to say that all declaration types have to be global. I'm not taking a stand on that issue; just pointing it out. Right -- there is no TYPE-LET special form, either, and that no one has missed it! (I won't tell them if you don't.)  Received: from SU-AI.ARPA by MIT-MC.ARPA; 6 MAY 85 20:54:03 EDT Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 6 May 85 17:44:51 PDT Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 231431; Mon 6-May-85 20:40:24-EDT Date: Mon, 6 May 85 20:41 EDT From: Kent M Pitman Subject: Macros -> declarations To: Wholey@CMU-CS-C.ARPA, KMP@SCRC-STONY-BROOK.ARPA cc: common-lisp@SU-AI.ARPA, gls%AQUINAS@THINK.ARPA, Moon@SCRC-STONY-BROOK.ARPA In-Reply-To: Message-ID: <850506204139.5.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> Date: Mon, 6 May 1985 20:20 EDT From: Skef Wholey Date: Monday, 6 May 1985 19:39-EDT From: Kent M Pitman Re: Macros -> declarations By the way, abstractions like my DECLARE-BIT-REGISTER do not provide "room for" other declarations. Eg, consider: (DEFUN FOO (REG) (DECLARE-BIT-REGISTER REG) (DECLARE (SPECIAL *FOO*)) ...) There is no way (without violating the BIT-REGISTER abstraction) to not write two leading DECLAREs. So what's really wanted is a DEFDECLARATION or somesuch that works like DEFTYPE in defining a macro-like thing that expands into a list of declare forms. Although a scheme like this wouldn't eliminate the need for a body parser to "macroexpand" stuff at runtime, it would eliminate the screw that was the last straw to Rob MacLachlan -- the need for all macro writers to do &environment hacking whenever parsing bodies. (defdeclaration bit-register (&rest guys) (mapcan #'(lambda (guy) `((special ,guy) (fixnum ,guy))) guys)) (defun foo (reg) (declare (bit-register reg) (special *foo*)) ...) Note that there is no way to scope DEFTYPE's. With the above suggestion, there would be no way to scope DEFDECLARATION's either. An alternate solution, which requires only a one-word change to the language spec, is to restrict macros that can expand into declarations to GLOBAL macros. This solution would handle all of the imaginative uses for this feature that people here have come up with, while removing the big ball of hair that makes it hard for users to write correct macros. This latter suggestion is ugly, I agree. A completely separate macro-like mechanism is provided for types, and happens to prevent the definition of local types, so why not have a similar mechanism for declarations? --Skef Well, that would certainly help a lot... but I'm not sure it would handle all the useful cases. For example, you couldn't use MACROLET to create a local declaration type. We'd either need a DECLARATION-LET special form or we'd have to say that all declaration types have to be global. I'm not taking a stand on that issue; just pointing it out. Another odd situation to consider is that you might be working in a package on which it was desirable to shadow the symbol DECLARE for some reason. Rather than have to write (LISP:DECLARE ...) everywhere, you could imagine wanting to do: (DEFMACRO MY:DECLARE (&REST DECLS) `(LISP:DECLARE ,@DECLS)) I don't expect this situation to be common early-on, but if people get into writing embedded languages as macrofied extensions making heavy use of the package system, they might well want such a provision ... or possibly something like: (DEFMACRO MY:DECLARE (&REST DECLS) `(LISP:DECLARE ,@(MY:TRANSLATE DECLS))) It turns out that if anyone ever wants to recycle any of the names CL defines as usable in declarations (like INTEGER, etc) to mean anything else in an embedded language, they will need this sort of hook in order to avoid having to provide an intermediate translator from their language to CL. I could imagine Macsyma possibly wanting to play games like this if it were ever really made to run "natively" in Common Lisp ... right now it has a lot of intermediate translators that should not really be needed if the macro facility of the underlying language is appropriately powerful. By the way, I don't think that the frequency of parsing bodies (as opposed to just propagating them) is so high as to make it offensive to have to use &ENVIRONMENT in those situations.  Received: from SU-AI.ARPA by MIT-MC.ARPA; 6 MAY 85 20:52:16 EDT Received: from RUTGERS.ARPA by SU-AI.ARPA with TCP; 6 May 85 17:44:05 PDT Date: 6 May 85 20:44:26 EDT From: Charles Hedrick Subject: SETF (APPLY To: common-lisp@SU-AI.ARPA The problem with the current definition is that it depends upon the implementation. Rather than kludging up the definition more so that it properly describes hairier implementations of SETF, how about simply saying that SETF (APPLY must work for AREF, BITS, and SBITS, if those are the only useful cases. You might also say that it is suggested that the implementation be such that this construct should work for as many additional cases as possible. But I would much rather have a specific list of those cases where it is supposed to work than a description whose interpretation is implementation- dependent. Currently, I can claim that I have implemented SETF (APPLY correctly, since in my implementation there is no case where the precondition would apply. I recently added special-case code to handle AREF, and if people agree that BITS and SBITS are also useful, I will add them too. I will use a strategy similar to VanRoggen's suggested APPLY-BUT-LAST. -------  Received: from SU-AI.ARPA by MIT-MC.ARPA; 6 MAY 85 20:30:54 EDT Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 6 May 85 17:21:06 PDT Received: ID ; Mon 6 May 85 20:20:52-EDT Date: Mon, 6 May 1985 20:20 EDT Message-ID: Sender: WHOLEY@CMU-CS-C.ARPA From: Skef Wholey To: Kent M Pitman Cc: common-lisp@SU-AI.ARPA, gls%AQUINAS@THINK.ARPA, Moon@SCRC-STONY-BROOK.ARPA Subject: Macros -> declarations In-reply-to: Msg of 6 May 1985 19:39-EDT from Kent M Pitman Date: Monday, 6 May 1985 19:39-EDT From: Kent M Pitman Re: Macros -> declarations By the way, abstractions like my DECLARE-BIT-REGISTER do not provide "room for" other declarations. Eg, consider: (DEFUN FOO (REG) (DECLARE-BIT-REGISTER REG) (DECLARE (SPECIAL *FOO*)) ...) There is no way (without violating the BIT-REGISTER abstraction) to not write two leading DECLAREs. So what's really wanted is a DEFDECLARATION or somesuch that works like DEFTYPE in defining a macro-like thing that expands into a list of declare forms. Although a scheme like this wouldn't eliminate the need for a body parser to "macroexpand" stuff at runtime, it would eliminate the screw that was the last straw to Rob MacLachlan -- the need for all macro writers to do &environment hacking whenever parsing bodies. (defdeclaration bit-register (&rest guys) (mapcan #'(lambda (guy) `((special ,guy) (fixnum ,guy))) guys)) (defun foo (reg) (declare (bit-register reg) (special *foo*)) ...) Note that there is no way to scope DEFTYPE's. With the above suggestion, there would be no way to scope DEFDECLARATION's either. An alternate solution, which requires only a one-word change to the language spec, is to restrict macros that can expand into declarations to GLOBAL macros. This solution would handle all of the imaginative uses for this feature that people here have come up with, while removing the big ball of hair that makes it hard for users to write correct macros. This latter suggestion is ugly, I agree. A completely separate macro-like mechanism is provided for types, and happens to prevent the definition of local types, so why not have a similar mechanism for declarations? --Skef  Received: from SU-AI.ARPA by MIT-MC.ARPA; 6 MAY 85 19:52:34 EDT Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 6 May 85 16:42:24 PDT Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 231404; Mon 6-May-85 19:38:28-EDT Date: Mon, 6 May 85 19:39 EDT From: Kent M Pitman Subject: Macros -> declarations To: Moon@SCRC-STONY-BROOK.ARPA, gls%AQUINAS@THINK.ARPA cc: common-lisp@SU-AI.ARPA In-Reply-To: <850506174305.1.MOON@EUPHRATES.SCRC.Symbolics.COM> Message-ID: <850506193941.1.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> Date: Mon, 6 May 85 17:43 EDT From: David A. Moon Date: Monday, 6 May 1985, 11:43-EDT From: Guy Steele I would be not at all unhappy if this feature were to go away... I have no opinion one way or the other about whether the feature of macros expanding into DECLARE forms should be retained or flushed. Maybe we'll hear from KMP what he had in mind when he suggested it, back in 1982 or thereabouts, before we make a decision. ... Thanks for reminding me about this. Indeed, I did have reasons other than the ones I've seen mentioned thus far. I think that at least one possible use I had in mind was for allowing macros so that you could create alternate syntax for declarations. eg, suppose a BIT-REGISTER was some abstraction on special variables that hold fixnums. Then (DEFMACRO DECLARE-BIT-REGISTER (&REST NAMES) `(DECLARE (SPECIAL ,@NAMES) (FIXNUM ,@NAMES))) might be something you could imagine writing and (DEFUN FROB (REG) (DECLARE-BIT-REGISTER REG) (FROB-1)) (DEFUN FROB-1 () (DECLARE-BIT-REGISTER REG) ...) might be a sample usage. Note that in this situation it is not the case that DEFVAR or the like is called for, since we're only communicating between two functions. Also, one may not want to write: (DEFUN FROB (REG) (DECLARE (SPECIAL REG) (FIXNUM REG)) (FROB-1)) (DEFUN FROB-1 () (DECLARE (SPECIAL REG) (FIXNUM REG)) ...) because that loses an abstraction level. By the way, abstractions like my DECLARE-BIT-REGISTER do not provide "room for" other declarations. Eg, consider: (DEFUN FOO (REG) (DECLARE-BIT-REGISTER REG) (DECLARE (SPECIAL *FOO*)) ...) There is no way (without violating the BIT-REGISTER abstraction) to not write two leading DECLAREs.  Received: from SU-AI.ARPA by MIT-MC.ARPA; 6 MAY 85 19:14:00 EDT Received: from THINK.ARPA by SU-AI.ARPA with TCP; 6 May 85 13:47:06 PDT Received: by THINK.ARPA with CHAOS id AA01781; Mon, 6 May 85 16:45:33 edt Date: Monday, 6 May 1985, 16:45-EDT From: Guy Steele Subject: local declarations To: vanroggen@DEC-HUDSON@THINK.ARPA, fahlman@cmu-cs-c Cc: common-lisp@su-ai, gls%AQUINAS@THINK.ARPA In-Reply-To: The message of 6 May 85 12:53-EDT from vanroggen at DEC-HUDSON at think Message-Id: <850506164554.4.GLS@DESIDERIUS.THINK> Date: Mon, 06 May 85 12:53:00 EDT From: vanroggen@DEC-HUDSON@think What I was complaining about was the implication in the manual that the following code was "not meaningful": (TYPECASE X (SIMPLE-STRING (LOCALLY (DECLARE (SIMPLE-STRING X)) ...)) ...) This local declaration isn't "off in left field somehwere"; it's quite lexical. (I'm assuming X isn't SPECIAL; that problem has been aired a number of times now.) ---Walter "Any REALLY good compiler" could figure this case out without needing the explicit declaration. (But of course it can't figure out general cases.) You can get around this somewhat either by using LET or by using THE: (TYPECASE X (SIMPLE-STRING ... (CHAR (THE SIMPLE-STRING X) 43) ...) ...) For true hair, use MACROLET: (TYPECASE X (SIMPLE-STRING (MACROLET ((X () '(THE SIMPLE-STRING X))) ... (CHAR (X) 43) ...)) ...) [Yuk.] --Guy  Received: from SU-AI.ARPA by MIT-MC.ARPA; 6 MAY 85 19:05:37 EDT Received: from USC-ISI.ARPA by SU-AI.ARPA with TCP; 6 May 85 12:41:00 PDT Date: 6 May 1985 15:40-EDT Sender: OLDMAN@USC-ISI.ARPA Subject: defconstant vs. lexical variables From: OLDMAN@USC-ISI.ARPA To: common-lisp@SU-AI.ARPA Message-ID: <[USC-ISI.ARPA] 6-May-85 15:40:52.OLDMAN> Page 69 of the CLM states: "Once a name has been declared by defconstant to be constant, any further assignment to or binding of that special variable is an error. ... A compiler may also choose to issue warnings about bindings of the lexical variable of the same name." Question: How can I make a lexical binding of the thing if it's implicitly proclaimed special by the defconstant? Alternate question: Why don't we have a way of declaring something locally lexical? --Dan Oldman {Data General}  Received: from SU-AI.ARPA by MIT-MC.ARPA; 6 MAY 85 19:01:59 EDT Received: from SCRC-YUKON.ARPA by SU-AI.ARPA with TCP; 6 May 85 12:35:16 PDT Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-YUKON.ARPA via CHAOS with CHAOS-MAIL id 123937; Mon 6-May-85 15:35:04-EDT Date: Mon, 6 May 85 15:34 EDT From: David A. Moon Subject: SETF of APPLY To: Guy Steele cc: common-lisp@SU-AI.ARPA In-Reply-To: <850506113354.1.GLS@DESIDERIUS.THINK> Message-ID: <850506153459.6.MOON@EUPHRATES.SCRC.Symbolics.COM> I agree with your proposed revised description of SETF of APPLY. The specific code in our implementation of APPLY's SETF-method follows; it may be useful in constructing the English description. This is not the whole SETF-method, just the relevant code fragment. (DEFINE-SETF-METHOD APPLY (FUNCTION &REST ARGS) .... (SETQ FUNCTION (SECOND FUNCTION)) (MULTIPLE-VALUE-BIND (VARS VALS STORE-VARS STORE-FORM ACCESS-FORM) (GET-SETF-METHOD-MULTIPLE-VALUE (CONS FUNCTION ARGS)) (LET ((LIST-VAR (LOOP FOR VAR IN VARS AND VAL IN VALS WHEN (EQ VAL (CAR (LAST ARGS))) RETURN VAR))) (OR (AND LIST-VAR (EQ (CAR (LAST ACCESS-FORM)) LIST-VAR) (EQ (CAR (LAST STORE-FORM)) LIST-VAR)) (ERROR "APPLY of ~S not understood as a generalized variable" FUNCTION)) While SETF of APPLY of AREF could be implemented some other way, not involving the last argument to the original form remaining last in the access-form and store-form, I think it is necessary for SETF of APPLY of a user-defined function to work this way. This is all certainly ugly, but I still think the alternative (a separate DEFSETF system for functions seen inside APPLY) would be a lot worse.  Received: from SU-AI.ARPA by MIT-MC.ARPA; 6 MAY 85 17:56:34 EDT Received: from SCRC-QUABBIN.ARPA by SU-AI.ARPA with TCP; 6 May 85 14:43:20 PDT Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-QUABBIN.ARPA via CHAOS with CHAOS-MAIL id 161094; Mon 6-May-85 17:40:21-EDT Date: Mon, 6 May 85 17:43 EDT From: David A. Moon Subject: Macros -> declarations To: Guy Steele cc: common-lisp@SU-AI.ARPA In-Reply-To: <850506114342.2.GLS@DESIDERIUS.THINK> Message-ID: <850506174305.1.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Monday, 6 May 1985, 11:43-EDT From: Guy Steele I would be not at all unhappy if this feature were to go away. I agree that Scott's assessment that it is unlikely that any existing code (outside of diagnostic tests for this very feature) would be harmed. I have no opinion one way or the other about whether the feature of macros expanding into DECLARE forms should be retained or flushed. Maybe we'll hear from KMP what he had in mind when he suggested it, back in 1982 or thereabouts, before we make a decision. I would like to point out, though, that anyone claiming that no one uses the feature is on very thin ice. A hell of a lot of copies of Common Lisp: The Language have been sold. I have heard of more than one implementation existing "off in left field". My experience has been that users will often use features that you wouldn't have expected them to use, or even discover, and then will get mad when you remove the feature. The worst case of this, of course, is when the user thought it was a feature and the implementor thought it was a bug. I am persuaded not at all by the argument that it is hard to implement. I am mildly swayed by the efficiency considerations for the interpreter. I found it easy enough to implement an interpreter that handles these efficiently. It pre-processes certain special forms the first time it encounters them. No big deal. The convincing point to me, however, is that the facility is likely to confuse macro-writers (who do, indeed, frequently find it necessary to find the division point between declarations/documentation and body). As a proposal separate from the question of eliminating the expansion of macros into declarations, I suggest the following primitive for consideration: PARSE-BODY list The list is treated as a body (a list of forms) that may have declarations and a documentation string at its head. Three values are returned. The first is some tail of the list, the executable part of the body. The second value is a list of declarations (lists whose car is DECLARE) at the head of the body. The third value is the documentation string, or NIL if there was no documentation string. This is a good suggestion. We already have this, but haven't documented it pending standardization or other reasons why we might want to change it. Our implementation of this raises some points: - It needs to take a lexical environment argument so it can expand macros so it can look for declarations. - It needs to take an argument that tells it whether documentation strings are allowed in this kind of body. - It's convenient for the caller if PARSE-BODY peels off the DECLARE's and simply returns a one-level list of declarations. The caller can cons DECLARE back onto the front of this list if desired. - For our system's applications, we found it convenient to split the declarations into four kinds returned as separate lists. I don't know that it would make sense to standardize this in Common Lisp, though. The four kinds were SPECIAL declarations, type declarations, declarations that need to be saved until run time for the Debugger (not a portable concept), and all others.  Received: from SU-AI.ARPA by MIT-MC.ARPA; 6 MAY 85 15:17:11 EDT Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 6 May 85 11:58:50 PDT Received: ID ; Mon 6 May 85 14:58:12-EDT Date: Mon, 6 May 1985 14:58 EDT Message-ID: Sender: FAHLMAN@CMU-CS-C.ARPA From: "Scott E. Fahlman" To: Guy Steele Cc: common-lisp@SU-AI.ARPA Subject: SETF of APPLY In-reply-to: Msg of 6 May 1985 11:33-EDT from Guy Steele I like Guy's new formulation for the SETF of APPLY stuff. One other thing that should be said is that SETF of APPLY of AREF is required to work, regardless of how the AREF-setting function is implemented internally. The main object of this stuff is to get this one case to work, and yet an implementation is technically permitted to implement the AREF setter in some way that does not fit into the framework described. -- Scott  Received: from SU-AI.ARPA by MIT-MC.ARPA; 6 MAY 85 14:58:26 EDT Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 6 May 85 11:48:05 PDT Received: ID ; Mon 6 May 85 14:48:02-EDT Date: Mon, 6 May 1985 14:47 EDT Message-ID: Sender: FAHLMAN@CMU-CS-C.ARPA From: "Scott E. Fahlman" To: vanroggen@DEC-HUDSON.ARPA Cc: common-lisp@SU-AI.ARPA Subject: local declarations In-reply-to: Msg of 6 May 1985 12:53-EDT from vanroggen at DEC-HUDSON Ah, I misunderstood what you were suggesting. Yes, to somehow be able to specify the type of a lexical variable within a subset of that variable's scope is indeed something that would be useful (though doing one quick copy into a type-restricted LET variable doesn't seem too bad). It also was not totally clear whether you were areguing for keeping themacro-to-declaration lossage or flushing it. Glad to hear you're on the side of sanity. -- Scott  Received: from SU-AI.ARPA by MIT-MC.ARPA; 6 MAY 85 14:02:13 EDT Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 6 May 85 10:52:23 PDT Received: ID ; Mon 6 May 85 13:52:00-EDT Date: Mon, 6 May 1985 13:51 EDT Message-ID: Sender: WHOLEY@CMU-CS-C.ARPA From: Skef Wholey To: Charles Hedrick Cc: common-lisp@SU-AI.ARPA, GSB@MIT-MC.ARPA Subject: (setf (apply #'foo ...) ...) Just for the record (and to maybe make things epsilon easier for other implementors), (setf (apply #'aref ...) ...) in Spice Lisp turns into a call to Lisp::%Aset, which takes its arguments in the new-element-is-last order, instead of the Zetalisp order. That turned out to be just as easy for us. Also, the Let bindings that Setf produces that it can't prove can go away are examined by a general-purpose "Let optimizer" in our compiler, which does a more thorough job of removing spurious bindings. --Skef  Received: from SU-AI.ARPA by MIT-MC.ARPA; 6 MAY 85 13:51:40 EDT Received: from DEC-HUDSON.ARPA by SU-AI.ARPA with TCP; 6 May 85 10:43:01 PDT Date: Mon, 06 May 85 13:44:06 EDT From: vanroggen@DEC-HUDSON Subject: SETF APPLY ... To: hedrick@rutgers Cc: common-lisp@su-ai BIT and SBIT are two other Common Lisp functions which should work inside SETF of APPLY, but they're the only other ones. It seems to me that we could have both the newvalue passed as the last arg of the setting function and the ability to do SETF of APPLY if we would admit to a function, that I'll call APPLY-BUT-LAST, that's just like APPLY, except that it's the next-to-last argument that must be a list, and the last argument is just passed as the last argument to the applied function. This won't help with multiple-value-setfs (which I think don't belong in Common Lisp), but it will allow SETF of APPLY of other named SETFable forms. ---Walter  Received: from SU-AI.ARPA by MIT-MC.ARPA; 6 MAY 85 13:04:36 EDT Received: from DEC-HUDSON.ARPA by SU-AI.ARPA with TCP; 6 May 85 09:51:59 PDT Date: Mon, 06 May 85 12:53:00 EDT From: vanroggen@DEC-HUDSON Subject: local declarations To: fahlman@cmu-cs-c Cc: common-lisp@su-ai What I was complaining about was the implication in the manual that the following code was "not meaningful": (TYPECASE X (SIMPLE-STRING (LOCALLY (DECLARE (SIMPLE-STRING X)) ...)) ...) This local declaration isn't "off in left field somehwere"; it's quite lexical. (I'm assuming X isn't SPECIAL; that problem has been aired a number of times now.) ---Walter  Received: from SU-AI.ARPA by MIT-MC.ARPA; 6 MAY 85 12:57:46 EDT Received: from DEC-HUDSON.ARPA by SU-AI.ARPA with TCP; 6 May 85 09:47:30 PDT Date: Mon, 06 May 85 12:48:36 EDT From: vanroggen@DEC-HUDSON Subject: macros --> declarations To: ram@cmu-cs-c Cc: common-lisp@su-ai I think others have provided examples of their usefulness. However, usefulness is not a sufficient criterion for inclusion in the language (fortunately!). I don't understand why you ask me to provide an example when I'd also like to have the feature removed. ---Walter  Received: from SU-AI.ARPA by MIT-MC.ARPA; 6 MAY 85 12:03:12 EDT Received: from THINK.ARPA by SU-AI.ARPA with TCP; 6 May 85 08:54:39 PDT Received: by THINK.ARPA with CHAOS id AA14309; Mon, 6 May 85 11:47:28 edt Date: Monday, 6 May 1985, 11:47-EDT From: Guy Steele Subject: PROCLAIM and type declarations To: common-lisp@sail Cc: gls%AQUINAS@THINK.ARPA Message-Id: <850506114744.3.GLS@DESIDERIUS.THINK> I believe that the sentences from page 156 about PROCLAIM covers the case currently under debate: Any variable names mentioned are assumed to refer to the dynamic values of the variable.... Similarly, any function names mentioned are assumed to refer to the global function definition. In a later paragraph it is noted that PROCLAIM of SPECIAL is given an unusual interpretation. --Guy  Received: from SU-AI.ARPA by MIT-MC.ARPA; 6 MAY 85 11:55:07 EDT Received: from THINK.ARPA by SU-AI.ARPA with TCP; 6 May 85 08:45:14 PDT Received: by THINK.ARPA with CHAOS id AA14271; Mon, 6 May 85 11:43:25 edt Date: Monday, 6 May 1985, 11:43-EDT From: Guy Steele Subject: Macros -> declarations To: common-lisp@sail Cc: gls%AQUINAS@THINK.ARPA Message-Id: <850506114342.2.GLS@DESIDERIUS.THINK> I would be not at all unhappy if this feature were to go away. I agree that Scott's assessment that it is unlikely that any existing code (outside of diagnostic tests for this very feature) would be harmed. I am persuaded not at all by the argument that it is hard to implement. I am mildly swayed by the efficiency considerations for the interpreter. The convincing point to me, however, is that the facility is likely to confuse macro-writers (who do, indeed, frequently find it necessary to find the division point between declarations/documentation and body). As a proposal separate from the question of eliminating the expansion of macros into declarations, I suggest the following primitive for consideration: PARSE-BODY list The list is treated as a body (a list of forms) that may have declarations and a documentation string at its head. Three values are returned. The first is some tail of the list, the executable part of the body. The second value is a list of declarations (lists whose car is DECLARE) at the head of the body. The third value is the documentation string, or NIL if there was no documentation string. --Guy  Received: from SU-AI.ARPA by MIT-MC.ARPA; 6 MAY 85 11:43:10 EDT Received: from THINK.ARPA by SU-AI.ARPA with TCP; 6 May 85 08:34:41 PDT Received: by THINK.ARPA with CHAOS id AA14159; Mon, 6 May 85 11:33:39 edt Date: Monday, 6 May 1985, 11:33-EDT From: Guy Steele Subject: SETF of APPLY To: common-lisp@sail Cc: gls%AQUINAS@THINK.ARPA Message-Id: <850506113354.1.GLS@DESIDERIUS.THINK> Hedrick is quite correct that there is a glaring inconsistency in what the manual says about SETF of APPLY. I think that what it says ought to be approximately the truth, but it needs to be hedged with something about the need to use LET to get the evaluation order straight. It is of course precisely to avoid such messy details that SETF is a canned primitive in the first place. What would you think of the more complex strategy outlined below as a replacement for some of the text on page 96? The SETF method for the function must be such that the expansion of (SETF ( ... ) ) uses the form (or the generated variable that fronts for it) only as the last argument in some number of function calls ( ... ) Every such function call in the expansion is altered to be (APPLY #' ... ) For example, suppose that (SETF (AREF FOO (P) (Q) (R)) X) were to expand to (LET* ((#:G0018 FOO) (#:G0019 (P)) (#:G0020 (Q)) (#:G0021 (R))) (ASET X #:G0018 #:G0019 #:G0020 #:G0021)) Then the expansion of (SETF (APPLY #'AREF FOO (P) (Q) (R)) X) would be (LET* ((#:G0018 FOO) (#:G0019 (P)) (#:G0020 (Q)) (#:G0021 (R))) (APPLY #'ASET X #:G0018 #:G0019 #:G0020 #:G0021)) --Guy  Received: from SU-AI.ARPA by MIT-MC.ARPA; 6 MAY 85 01:58:41 EDT Received: from RUTGERS.ARPA by SU-AI.ARPA with TCP; 5 May 85 22:51:54 PDT Date: 6 May 85 01:52:04 EDT From: Charles Hedrick Subject: Re: (setf (apply #'foo ...) ...) To: GSB@MIT-MC.ARPA cc: common-lisp@SU-AI.ARPA In-Reply-To: Message from "Glenn S. Burke " of 6 May 85 00:01:39 EDT We use the Spice Lisp SETF. -------  Received: from SU-AI.ARPA by MIT-MC.ARPA; 5 MAY 85 23:08:49 EDT Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 5 May 85 20:01:11 PDT Date: Sun, 5 May 85 23:01:39 EST From: Glenn S. Burke Subject: (setf (apply #'foo ...) ...) To: HEDRICK@RUTGERS cc: common-lisp@SU-AI Message-ID: <[MIT-MC].486573.850505.GSB> [oohhh, unbalanced parentheses hurt my eyes!!! Was that message complete?] What you say is true, but... The primary utility of SETF of APPLY is with those things like AREF which take a variable number of arguments; as a result, the inversion functions for them typically take the value first rather than last, e.g. (SETF (AREF a i j k ...) v) ==> (ASET v a i j k ...) so you sort of get stuck with having to do the LET-binding hair anyway. I don't know what your SETF code is like. NIL uses a SETF i wrote which utilizes a slightly hacked version of the moon/bawden code analysis and variable-substitution stuff. My experience is that it does sufficiently well to rarely produce completely superfluous bindings, and the rest are usually necessary or worthwhile. Should i take it that your setf makes no use of code analysis/simplification stuff?  Received: from SU-AI.ARPA by MIT-MC.ARPA; 5 MAY 85 22:56:36 EDT Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 5 May 85 19:48:27 PDT Received: ID ; Sun 5 May 85 22:48:23-EDT Date: Sun, 5 May 1985 22:48 EDT Message-ID: Sender: FAHLMAN@CMU-CS-C.ARPA From: "Scott E. Fahlman" To: Richard Mlynarik Cc: common-lisp@SU-AI.ARPA Subject: Misfeature: macros expanding into declarations It is probably not worthwhile to argue over whether the macro expansion misfeature makes life MUCH harder or just somewhat harder for implementors and macro-writers, and how kind we want to be to "wimpy" implementors. I am curious to find out if the people who think this is not very hard have really handled the problem correctly; after several iterations on the Spice Lisp interpreter and assorted macros, we've still got some problems, so it doesn't look easy to us. The fact remains that this misfeature slows down the interpreter and it has been the source of a steady stream of bugs. The people responsible for these bugs include assorted users trying to write macros and some fairly experienced Common Lisp implementors (including me). Given that, I still think that if nobody comes forward with a better argument for this stuff than the examples we've seen so far, it should be flushed. To let something this hairy into the language just because it is "not without some utility" was a serious mistake, and one that we can correct now with very little impact on existing code. -- Scott  Received: from SU-AI.ARPA by MIT-MC.ARPA; 5 MAY 85 21:56:44 EDT Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 5 May 85 18:49:10 PDT Date: Sun, 5 May 85 21:48:38 EST From: Richard Mark Soley Subject: Restrictions on what macros may call, to avoid needing to preload file To: REM%IMSSS@SU-SCORE cc: Common-LISP@SU-AI In-reply-to: Msg of 1985 May 05 17:24:22 PST (=GMT-8hr) from Robert Elton Maas Message-ID: <[MIT-MC].486449.850505.SOLEY> Date: 1985 May 05 17:24:22 PST (=GMT-8hr) From: Robert Elton Maas Sender: REM%IMSSS at SU-SCORE.ARPA (for undeliverable-mail notifications) Reply-To: REM%IMSSS at SU-SCORE.ARPA (temporary until nameservers up) To: Common-LISP at SU-AI.ARPA Re: Restrictions on what macros may call, to avoid needing to preload file Today somebody mentionned the problem of having to preload a file of macros interpreted (in the compiler environment) before being able to compile that same file, because of the macros needing themselves. I encountered a more subtle problem which likewise requires preloading the file of macros. In my case I was being careful not to have a macro depend on itself, but it did depend on EXPRs in the same file. . . . EXPRs are merely compiled and written to output, not also loaded. . . I'm on the verge of rewriting all my macros that have subfunctions to avoid subfunctions entirely, . . . What's wrong with (defmacro burble (blah ...) (burble-internal blah ...)) (EVAL-WHEN (EVAL COMPILE LOAD) (defun burble-internal ...) ) I use it all the time for exactly the problem you mentioned. -- Richard  Received: from SU-AI.ARPA by MIT-MC.ARPA; 5 MAY 85 21:53:59 EDT Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 5 May 85 18:44:12 PDT Date: Sun, 5 May 85 21:44:43 EST From: Richard Mark Soley Subject: Misfeature: macros expanding into declarations To: MLY@MIT-MC cc: common-lisp@SU-AI In-reply-to: Msg of Sun 5 May 85 21:37:38 EST from Richard Mlynarik Message-ID: <[MIT-MC].486436.850505.SOLEY> Date: Sun, 5 May 85 21:37:38 EST From: Richard Mlynarik To: SOLEY, common-lisp at SU-AI Re: Misfeature: macros expanding into declarations [with additional comments by gsb@mc] Date: Sun, 5 May 85 20:42:51 EST From: Richard Mark Soley Date: Sat, 4 May 85 18:26:24 EST From: Tim McNerney Date: Sat, 4 May 1985 07:36 EDT From: Rob MacLachlan The Common Lisp feature of allowing a macro to expand into declarations ought to be flushed; it complicates much code while giving no useful return. Although this "misfeature" makes life much harder on the Lisp implementor and the macro writer... Only the wimpy ones. I agree, and I don't care to heavily support wimpy implementors (wimplementors?). My point is that we SHOULD support wimpy macro writers. Anyway, at LEAST if we're going to continue to have this feature, there must be some flag that is set when we're doing "early" macro expansion so that the macro writer can tell how to expand, i.e., *EXPANDING-FOR-DECLARATIONS*. I don't understand exactly what this means at all. If the macro expands into "(declare ...)" then it is "exanding for declarations" as far as I can tell. [gsb: i don't understand the point of this either, particularly. I can see a potential for lossage when there is pre-parsing and thus macroexpansion performed at definition time rather than at runtime in interpreted code.] Exactly. The point is, there are macros that don't want to be expanded at interpreter-load (eval) time [i.e., when the DEFUN is loaded], but only when the defun is compiled. REGARDLESS of the fact that no DECLARE is returned. What -is- useful for a macro to know is whether it is being expanded by the compiler or the interpreter or for some other random purpose (mainly in order to make use of different error-reporting techniques, particularly those of the compiler) This information is part of the environment passed to the macroexpansion function and has been in NIL and the LMIT Lispm software for some time. Exactly what I was proposing. But this sucker would have to be well documented. -- Richard  Received: from SU-AI.ARPA by MIT-MC.ARPA; 5 MAY 85 21:45:26 EDT Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 5 May 85 18:37:15 PDT Date: Sun, 5 May 85 21:37:38 EST From: Richard Mlynarik Subject: Misfeature: macros expanding into declarations To: SOLEY@MIT-MC, common-lisp@SU-AI Message-ID: <[MIT-MC].486426.850505.MLY> [with additional comments by gsb@mc] Date: Sun, 5 May 85 20:42:51 EST From: Richard Mark Soley Date: Sat, 4 May 85 18:26:24 EST From: Tim McNerney Date: Sat, 4 May 1985 07:36 EDT From: Rob MacLachlan The Common Lisp feature of allowing a macro to expand into declarations ought to be flushed; it complicates much code while giving no useful return. It isn't that hard. It has at least some utility. I did it quite some time ago when this whole mess originally came up n months ago (and implemented the DOCUMENTATION declaration at the same time for reasons which were discussed then). Let's not rehash things discussed before, which is where the present discussion seems to be leading. Although this "misfeature" makes life much harder on the Lisp implementor and the macro writer... Only the wimpy ones. [gsb: I don't actually see how this makes life "much" harder. The whole deal of declaration parsing (or separation from the "body") is enough of a pain, that adding in macroexpansion was fairly trivial. Of course, NIL has its own set of internal "language tools" which handle various levels of declaration hacking, but they don't really amount to all that much. Obviously what we are lacking in CL are some additional tools for dealing with declarations, macroexpansion, etc.] Anyway, at LEAST if we're going to continue to have this feature, there must be some flag that is set when we're doing "early" macro expansion so that the macro writer can tell how to expand, i.e., *EXPANDING-FOR-DECLARATIONS*. I don't understand exactly what this means at all. If the macro expands into "(declare ...)" then it is "exanding for declarations" as far as I can tell. [gsb: i don't understand the point of this either, particularly. I can see a potential for lossage when there is pre-parsing and thus macroexpansion performed at definition time rather than at runtime in interpreted code.] What -is- useful for a macro to know is whether it is being expanded by the compiler or the interpreter or for some other random purpose (mainly in order to make use of different error-reporting techniques, particularly those of the compiler) This information is part of the environment passed to the macroexpansion function and has been in NIL and the LMIT Lispm software for some time. [gsb: NIL uses the environment given to macro functions as a pointer to more information than just the current set of macro definitions. For instance, it is used by SETF which keeps separate databases for runtime and compiletime definitions. We have a set of utilities for dealing with this sort of thing trivially, and basically all one has to do is pass around the macroexpansion-environment to keep the context straight.]  Received: from SU-AI.ARPA by MIT-MC.ARPA; 5 MAY 85 21:35:03 EDT Sent: to SU-AI.ARPA by IMSSS.? via ETHERNET with PUPFTP; 1985-May-05 17:26:23 PST (=GMT-8hr) Date: 1985 May 05 17:24:22 PST (=GMT-8hr) Message-id: SU-IMSSS.REM.A132157012100.G0353 From: Robert Elton Maas To:Common-LISP@SU-AI.ARPA Subject:Restrictions on what macros may call, to avoid needing to preload file Sender: REM%IMSSS@SU-SCORE.ARPA (for undeliverable-mail notifications) Reply-to: REM%IMSSS@SU-SCORE.ARPA (temporary until nameservers up) Today somebody mentionned the problem of having to preload a file of macros interpreted (in the compiler environment) before being able to compile that same file, because of the macros needing themselves. I encountered a more subtle problem which likewise requires preloading the file of macros. In my case I was being careful not to have a macro depend on itself, but it did depend on EXPRs in the same file. Loading the macro interpreted was fine, because first the macro and all needed EXPRs were loaded, and then any use of the macro occurred, so at that point everything needed to expand the macro-form was available. But when compiling, only macros are loaded into the compiler environment, EXPRs are merely compiled and written to output, not also loaded. Thus when it came time to compile a function which contained the macro-form, only the toplevel macro-expander, not the EXPRs called by the macro-expander, were available. I found I had to pre-load the file interpreted, then compile it. But then every time a macro was compiled the second time around the compiler complained about duplicate macro definitions. (This is with PSL, but the same general problem would probably happen with any LISP.) I'm on the verge of rewriting all my macros that have subfunctions to avoid subfunctions entirely, hacking the same effect by generating forms that contain sub-macros within them, thus the calling of sub-expanders happens via the macro mechanism after the toplevel macro-expander has returned a form to re-expand, rather than from within the body of the toplevel macro-expander, and the sub-expanders are all macros instead of EXPRs and thus automatically loaded into the compiler environment without needing to be pre-loaded interpreted. Is this change the best approach to avoid compiler hassles, or does CL provide a way to assure that certain EXPRs will both be compiled to the output file and loaded into the compiler environment so that one wouldn't have to do my proposed change?  Received: from SU-AI.ARPA by MIT-MC.ARPA; 5 MAY 85 20:50:09 EDT Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 5 May 85 17:42:18 PDT Date: Sun, 5 May 85 20:42:51 EST From: Richard Mark Soley Subject: Misfeature: macros expanding into declarations To: TIM@MIT-MC cc: common-lisp@SU-AI, Fahlman@CMU-CS-C, RAM@CMU-CS-C, isrlist@GYRE, sgr@SCRC-STONY-BROOK In-reply-to: Msg of Sat 4 May 85 18:26:24 EST from Tim McNerney Message-ID: <[MIT-MC].486343.850505.SOLEY> Date: Sat, 4 May 85 18:26:24 EST From: Tim McNerney To: Fahlman at CMU-CS-C cc: TIM, common-lisp at SU-AI, RAM at CMU-CS-C Re: Misfeature: macros expanding into declarations Date: Sat, 4 May 1985 07:36 EDT From: Rob MacLachlan The Common Lisp feature of allowing a macro to expand into declarations ought to be flushed; it complicates much code while giving no useful return. Although this "misfeature" makes life much harder on the Lisp implementor and the macro writer, its semantics are not without utility. Let me illustate this with a couple of simple examples: Implementor, shmimplementor! I don't think we're trying to optomize things for the implementor, but CERTAINLY we care about the macro writer, 'cause that's EVERYBODY! One thing this feature overlooks is the (admittedly bad) behavior of some macro writers that write overly-circular code, in which too-early expansion of macros kills the program. We've all seen the garbage codes that must be loaded interpreted first and THEN compiled; I've ported a couple of systems that depended on this rubbish and had troubles because of the early macro expansion (which I eventually had to turn off). I'll send anyone who cares my wonderful Symbolics Common Lisp function SI:BREAK-THE-SYSTEM-FOR-THE-SAKE-OF-NISP. Anyway, at LEAST if we're going to continue to have this feature, there must be some flag that is set when we're doing "early" macro expansion so that the macro writer can tell how to expand, i.e., *EXPANDING-FOR-DECLARATIONS*. -- Richard Soley  Received: from SU-AI.ARPA by MIT-MC.ARPA; 5 MAY 85 20:47:02 EDT Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 5 May 85 17:39:26 PDT Received: ID ; Sun 5 May 85 20:38:55-EDT Date: Sun, 5 May 1985 20:38 EDT Message-ID: Sender: FAHLMAN@CMU-CS-C.ARPA From: "Scott E. Fahlman" To: Kent M Pitman Cc: Common-Lisp@SU-AI.ARPA Subject: mysterious declarations off in left field In-reply-to: Msg of 5 May 1985 19:30-EDT from Kent M Pitman Or SPECIAL! I've already had problems in Macsyma source code with closures that didn't "close" because someone decided STRING should be a special variable. Well, in any future MACSYMA, that special would be named *STRING* and would therefore be harmless, assuming that the author of the code follows the suggested conventions. Quick conversions of old code are unlikely to observe such restrictions, however, and for compatibility reasons we stopped short of actually requiring specials to have funny names or funny syntax around them. Actually, I wonder if we shouldn't have said that type proclamations should pertain only to special variables. eg, (PROCLAIM '(TYPE FLOAT TOLERANCE)) might have only applied to special occurrences of TOLERANCE. This would mean that people using variables lexically in other modules would be far less likely to find irrelevant declarations affecting them... I think we did say that. The description of (PROCLAIM '(TYPE ...)) on page 156 says that "any variable names mentioned are assumed to refer to the dynamic values of the variable. So a lexical binding of TOLERANCE would not inherit this type restriction. -- Scott  Received: from SU-AI.ARPA by MIT-MC.ARPA; 5 MAY 85 19:40:30 EDT Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 5 May 85 16:33:05 PDT Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 230444; Sun 5-May-85 19:31:32-EDT Date: Sun, 5 May 85 19:30 EDT From: Kent M Pitman Subject: mysterious declarations off in left field To: Fahlman@CMU-CS-C.ARPA cc: Common-Lisp@SU-AI.ARPA In-Reply-To: Message-ID: <850505193039.6.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> Date: Sun, 5 May 1985 14:12 EDT From: "Scott E. Fahlman" Don't packages offer an alternative way of scoping declarations? Sure, but packages normally function at a very large grain size. Sometimes you want to add something to a package without having to scan the whole package definition to ensure that some fool has not declared X to be a quadruple-float. Or SPECIAL! I've already had problems in Macsyma source code with closures that didn't "close" because someone decided STRING should be a special variable. I guess you can imagine how that would be a pretty high-probability variable name and a poor choice of special name ... Consider too that names like LIST, STRING, etc. are not likely to be private -- nearly everyone is going to inherit them from GLOBAL -- so the first time anyone in any "package" declares one of them to be special, it screws everyone else who tries to do compilations in that environment. If I bind a lexical X, that's my X and I'm not interested in anyone else's views about what type X's in general should be. Indeed. Actually, I wonder if we shouldn't have said that type proclamations should pertain only to special variables. eg, (PROCLAIM '(TYPE FLOAT TOLERANCE)) might have only applied to special occurrences of TOLERANCE. This would mean that people using variables lexically in other modules would be far less likely to find irrelevant declarations affecting them... In cases where people wanted to make assertions about lexical variables, they should perhaps have to scope such declarations lexically. Although obviously such a change is somewhat incompatible, we might consider it (or something like it) for the next round of revisions. (An alternate approach which would achieve the same end would be to introduce a new declaration operator which had the property of applying only to special occurrences so that people could choose which style they wanted.) Of course this doesn't solve the problem I alluded to earlier of having people declare things special behind my back...  Received: from SU-AI.ARPA by MIT-MC.ARPA; 5 MAY 85 14:19:31 EDT Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 5 May 85 11:12:26 PDT Received: ID ; Sun 5 May 85 14:12:19-EDT Date: Sun, 5 May 1985 14:12 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: mysterious declarations off in left field In-reply-to: Msg of 5 May 1985 13:37-EDT from fateman%ucbdali at Berkeley (Richard Fateman) Don't packages offer an alternative way of scoping declarations? Sure, but packages normally function at a very large grain size. Sometimes you want to add something to a package without having to scan the whole package definition to ensure that some fool has not declared X to be a quadruple-float. If I bind a lexical X, that's my X and I'm not interested in anyone else's views about what type X's in general should be. -- Scott  Received: from SU-AI.ARPA by MIT-MC.ARPA; 5 MAY 85 13:43:27 EDT Received: from UCB-VAX.ARPA by SU-AI.ARPA with TCP; 5 May 85 10:36:43 PDT Received: from ucbdali.ARPA by UCB-VAX.ARPA (4.24/4.46) id AA15145; Sun, 5 May 85 10:35:39 pdt Received: by ucbdali.ARPA (4.24/4.46) id AA26300; Sun, 5 May 85 10:37:51 pdt Date: Sun, 5 May 85 10:37:51 pdt From: fateman%ucbdali@Berkeley (Richard Fateman) Message-Id: <8505051737.AA26300@ucbdali.ARPA> To: Fahlman@CMU-CS-C.ARPA, vanroggen@DEC-HUDSON.ARPA Subject: mysterious declarations off in left field Cc: common-lisp@SU-AI.ARPA Don't packages offer an alternative way of scoping declarations?  Received: from SU-AI.ARPA by MIT-MC.ARPA; 5 MAY 85 13:00:44 EDT Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 5 May 85 09:53:21 PDT Received: ID ; Sun 5 May 85 12:53:23-EDT Date: Sun, 5 May 1985 12:53 EDT Message-ID: Sender: FAHLMAN@CMU-CS-C.ARPA From: "Scott E. Fahlman" To: Rob MacLachlan Cc: common-lisp@SU-AI.ARPA Subject: macr --> declares Oops, looks like I'm confused again (with a little help from the manual). There it is, right there on page 156: a type proclamation, big as life. The text on page 158 describing the TYPE declaration specifier seems to deny that such a thing is possible, since it says that this specifier applies only to variable BINDINGS, but I think we ought to go with page 156, since (as I was just arguing) this mechanism is clearly useful. I believe that our current Slisp compiler, and probably several compilers derived from it, do not currently do anything with TYPE proclamations, but it's a five-minute change to add this (I think). In fact, type-restricted global specials were in there at one time, but were ripped out when PROCLAIM came along. -- Scott  Received: from SU-AI.ARPA by MIT-MC.ARPA; 5 MAY 85 12:25:51 EDT Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 5 May 85 09:19:08 PDT Received: ID ; Sun 5 May 85 12:19:02-EDT Date: Sun, 5 May 1985 12:18 EDT Message-ID: Sender: FAHLMAN@CMU-CS-C.ARPA From: "Scott E. Fahlman" To: Tim McNerney Cc: common-lisp@SU-AI.ARPA Subject: Misfeature: macros expanding into declarations In-reply-to: Msg of 4 May 1985 19:26-EDT from Tim McNerney Although this "misfeature" makes life much harder on the Lisp implementor and the macro writer, its semantics are not without utility. Let me illustate this with a couple of simple examples: If it were just a matter of making life harder on the Lisp implementor, simple utility would probably be a sufficient argument. It is a fact, lamented by some, that in the original Common Lisp design we were quite willing to make the implementor go through incredible gyrations in order to make things slightly more uniform or useful at the user level. This has generally been accepted since, in many cases, this implementation effort only had to be done once, in some public-domain implementaiton, and all the others could then just copy the solution. It hasn't always worked that way, but that was the motivation for letting certain hard-to-implement things into the language. This macro-expansion business is not just a one-shot implementation problem, however. It is a rich source of bugs whose flow has shown no sign of diminishing over time. It affects not just the hard-core implementors, but anyone who wants to write macros or other source-level tranformation or analysis tools. Not many people working at user level understand everything you need to understand in order to do this right. I'm not even 100% certain myself that a correct implementation is possible. We keep finding subtle problems. In addition to the problem of recurring bugs, it is clear that this is a major contributor to poor performance in Common Lisp interpreters. Given these problems, I think that we should only keep this mechanism if people come up with important, non-imaginary uses for it that cannot easily be done any other way. It seems a shame to keep such an evil machanism in the language just because people can think up some clever ways of using it. -- Scott  Received: from SU-AI.ARPA by MIT-MC.ARPA; 5 MAY 85 12:15:53 EDT Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 5 May 85 09:09:45 PDT Received: ID ; Sun 5 May 85 12:09:47-EDT Date: Sun, 5 May 1985 12:09 EDT Message-ID: From: Rob MacLachlan To: "Scott E. Fahlman" Cc: common-lisp@SU-AI.ARPA, vanroggen@DEC-HUDSON.ARPA Subject: macr --> declares In-reply-to: Msg of 5 May 1985 11:53-EDT from Scott E. Fahlman The CLM seems to believe that type proclamations are legal. The following example is on page 156: (proclaim '(type float tolerance)) Rob  Received: from SU-AI.ARPA by MIT-MC.ARPA; 5 MAY 85 11:59:33 EDT Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 5 May 85 08:53:09 PDT Received: ID ; Sun 5 May 85 11:53:10-EDT Date: Sun, 5 May 1985 11:53 EDT Message-ID: Sender: FAHLMAN@CMU-CS-C.ARPA From: "Scott E. Fahlman" To: vanroggen@DEC-HUDSON.ARPA Cc: common-lisp@SU-AI.ARPA Subject: macr --> declares In-reply-to: Msg of 4 May 1985 18:44-EDT from vanroggen at DEC-HUDSON While we're into complaining about declarations, I'd like to grouse about type declarations not being meaningful when not applied to a binding in the immediate special form or macro. The ability to say that a variable will always be a certain type within a small body of code is very useful and very common. Officially, requiring one to write a LET or the like just so one can write a type declaration is very annoying. It would be even more annoying to find that you've created a nice, local, lexical variable binding and that its type is being mysteriously restricted by some declaration off in left field somewhere. I think that it is clear that we want all of the declarations relevant to a lexical variable binding to be present right there with the binding. Of course, a SPECIAL proclamation can have non-local effects on what would otherwise be lexical bindings, but at least we try to minimize the bug-creation potential of this by encouraging people to use the *foo* convention for such globally-special variables. What does seem to be reasonable is to allow pervasive type declarations for global special variables. It seems reasonable to allow something like the following: (proclaim (special *foo*)) (proclaim (integer *foo*)) or (defvar *foo* 27 "Number of FOOs still to be used." 'integer) This seems quite useful to me, and doesn't ruin the locality of lexical bindings. -- Scott  Received: from SU-AI.ARPA by MIT-MC.ARPA; 5 MAY 85 04:51:02 EDT Received: from RUTGERS.ARPA by SU-AI.ARPA with TCP; 5 May 85 01:44:54 PDT Date: 5 May 85 02:59:26 EDT From: Charles Hedrick Subject: (setf (apply #'foo To: common-lisp@SU-AI.ARPA According to the manual, (setf (apply #'foo x y) z) is defined only when (setf (foo x y) z) expands to something of the form (set-foo z x y). In this case the original SETF expands to (apply #'set-foo z x y). I claim that this statement is vacuous. The problem is that no SETF form can expand in this way. To do so would violate the provision that SETF must preserve left to right evaluation. Certainly left to right evaluation can be preserved by complex patterns involving LET, etc. However in the case where SETF expands to a simple function call, it is clear that the arguments must be in the same order as the arguments to the original SETF. In that case, the new value must be last, which violates the preconditions for (SETF (APPLY -------  Received: from SU-AI.ARPA by MIT-MC.ARPA; 4 MAY 85 19:03:32 EDT Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 4 May 85 15:57:07 PDT Received: ID ; Sat 4 May 85 18:57:23-EDT Date: Sat, 4 May 1985 18:57 EDT Message-ID: From: Rob MacLachlan To: vanroggen@DEC-HUDSON.ARPA Cc: common-lisp@SU-AI.ARPA Subject: macr --> declares In-reply-to: Msg of 4 May 1985 18:44-EDT from vanroggen at DEC-HUDSON I complained about this a while ago, and at the time, no one seemed to think it worth changing the language definition. But it is a useful feature, and not having macros expand into declarations won't avoid having some macros needing to parse declarations. It won't eliminate the need for *any* macro's declaration parsing; it will make it easier to do correctly. I suspect that at the time, nobody had implemented a macro that parsed declarations correctly, and it is entirely possibly that this is still the case. I challenge you assertion that it is a useful feature---show me. Rob  Received: from SU-AI.ARPA by MIT-MC.ARPA; 4 MAY 85 18:56:37 EDT Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 4 May 85 15:49:30 PDT Received: ID ; Sat 4 May 85 18:49:56-EDT Date: Sat, 4 May 1985 18:49 EDT Message-ID: From: Rob MacLachlan To: Tim McNerney Cc: common-lisp@SU-AI.ARPA, Fahlman@CMU-CS-C.ARPA Subject: Misfeature: macros expanding into declarations In-reply-to: Msg of 4 May 1985 19:26-EDT from Tim McNerney I think both of your examples are better handled by other mechanisms that already exist. In you (declare (special ...)) example, I suspect that making the variables globally special would work better. The only time it wouldn't work was if you were actually binding the variables, and sometimes bound them specially and sometimes not. I doubt that anyone does this, and if they do, it should probably be glaringly obvious. As for the second example, I suggest: (defun %eq-seconds-p (list-1 list-2) #-debugging-p (declare (inline car cdr eq))) (eq (cadr list-1) (cadr list-2))) Are these samples of real code, or are they just contrived examples? Rob  Received: from SU-AI.ARPA by MIT-MC.ARPA; 4 MAY 85 18:49:42 EDT Received: from DEC-HUDSON.ARPA by SU-AI.ARPA with TCP; 4 May 85 15:43:01 PDT Date: Sat, 04 May 85 18:44:06 EDT From: vanroggen@DEC-HUDSON Subject: macr --> declares To: common-lisp@su-ai Cc: vanroggen I complained about this a while ago, and at the time, no one seemed to think it worth changing the language definition. But it is a useful feature, and not having macros expand into declarations won't avoid having some macros needing to parse declarations. While we're into complaining about declarations, I'd like to grouse about type declarations not being meaningful when not applied to a binding in the immediate special form or macro. The ability to say that a variable will always be a certain type within a small body of code is very useful and very common. Officially, requiring one to write a LET or the like just so one can write a type declaration is very annoying. ---Walter  Received: from SU-AI.ARPA by MIT-MC.ARPA; 4 MAY 85 18:37:55 EDT Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 4 May 85 15:29:25 PDT Date: Sat, 4 May 85 18:26:24 EST From: Tim McNerney Subject: Misfeature: macros expanding into declarations To: Fahlman@CMU-CS-C cc: TIM@MIT-MC, common-lisp@SU-AI, RAM@CMU-CS-C In-reply-to: Msg of Sat 4 May 1985 15:09 EDT from Scott E. Fahlman Message-ID: <[MIT-MC].485362.850504.TIM> Date: Sat, 4 May 1985 07:36 EDT From: Rob MacLachlan The Common Lisp feature of allowing a macro to expand into declarations ought to be flushed; it complicates much code while giving no useful return. Although this "misfeature" makes life much harder on the Lisp implementor and the macro writer, its semantics are not without utility. Let me illustate this with a couple of simple examples: ;;; Example 1 (defmacro declare-my-specials () '(declare (special *foo* *bar* *baz)) ;; Once this is done, you can use this in all the functions which ;; use these special variables like so: (defun frob1! (a b) (declare-my-specials) ...) (defun frob2 (x) (declare-my-specials) ...) ;;; Example 2 (defmacro declare-inlines () (declare (special *debugging-p*)) (if *debugging-p* ;Compile time flag '(declare (notinline car cdr) '(declare (inline car cdr eq))) ;; Then this declaration macro can be used is time-critical code like so: (defun %eq-seconds-p (list-1 list-2) (declare-inlines) (eq (cadr list-1) (cadr list-2))) I am not saying that permitting macros to expand into declarations as stated on p. 154 is a good mechanism for achieving this effect, but there should be some way of getting the functionality suggested in the above examples. From: Scott E. Fahlman Note that we are not arguing against the ability of a macro to turn into some top-level form such as a DO that, among other things, contains declarations. We are arguing for the elimination of the feature described on page 154, in the paragraph starting "It is permissible..." I don't think that is reasonable to require the programmer to define macros like DEFUN-WITH-MY-SPECIALS or DEFUN-WITH-DEBUGGABLE-INLINES or anything of the sort. At top level, these stand a good chance of confusing editors and human readers. For the sake of Lisp implementers and macro writers, I would suggest that this mechanism be flushed in favor of a user-extensible DECLARE. The DEFTYPE macro is seriously deficient in this role. Rather than using (DECLARE-MY-SPECIALS) above, I could use (DECLARE (MY-SPECIALS)) or something of the sort after defining MY-SPECIALS in some way. From: Rob MacLachlan The largest issue that I see is that writing macros that parse declarations becomes much more complicated. Every macro writer must duplicate the non-trivial code which expands macros looking for declarations. If this feature must remain, then there should be standard functions for parsing declarations in the language. This might not be a bad idea anyway... This is a great suggestion! This would save a lot of duplicated effort. Case in point: ;Insert form after any declarations. This is about the fifth place ;in the system that knows how to do this; somebody fix this. (DEFUN INSERT-INTO-BODY (FORM BODY) (LOOP WHILE (AND (CDR BODY) (OR (STRINGP (CAR BODY)) (AND (LISTP (CAR BODY)) (EQ (CAAR BODY) 'DECLARE)))) COLLECT (POP BODY) INTO DECLARATIONS FINALLY (RETURN (NCONC DECLARATIONS (NCONS FORM) BODY)))) --From sys:sys2;flavor.lisp.564 (c) 1985 Symbolics, Inc. Of course the common lisp version would be much hairier if the "misfeature" were allowed to remain. Tim  Received: from SU-AI.ARPA by MIT-MC.ARPA; 4 MAY 85 15:16:37 EDT Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 4 May 85 12:09:13 PDT Received: ID ; Sat 4 May 85 15:09:43-EDT Date: Sat, 4 May 1985 15:09 EDT Message-ID: Sender: FAHLMAN@CMU-CS-C.ARPA From: "Scott E. Fahlman" To: Rob MacLachlan Cc: common-lisp@SU-AI.ARPA Subject: Misfeature: macros expanding into declarations In-reply-to: Msg of 4 May 1985 07:36-EDT from Rob MacLachlan I agree with Rob: we should eliminate the ability of a macro in certain places to expand into a declaration. I cannot think of anything essential that this feature buys us, and it certainly has caused many bugs and lots of inefficiency in the various interpreters that I've seen. Code analysis tools would all have similar problems with this. If I remember the original debate on this, it was a "what the hell, it might be useful someday, let's add it" sort of decision, whose consequeces we didn't totally appreciate. If there's some important case that really needs this feature, that's different, but I don't think that there is. Nor do I believe that there are more than ten lines of Common Lisp code anywhere in the world (outside of validation tests) that depend on this feature, so taking it out at this late date wouldn't cause major upheavals. Note that we are not arguing against the ability of a macro to turn into some top-level form such as a DO that, among other things, contains declarations. We are arguing for the elimination of the feature described on page 154, in the paragraph starting "It is permissible..." -- Scott  Received: from SU-AI.ARPA by MIT-MC.ARPA; 4 MAY 85 11:45:45 EDT Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 4 May 85 08:38:27 PDT Received: ID ; Sat 4 May 85 11:08:50-EDT Date: Sat, 4 May 1985 07:36 EDT Message-ID: From: Rob MacLachlan To: common-lisp@SU-AI.ARPA Subject: Misfeature: macros expanding into declarations The Common Lisp feature of allowing a macro to expand into declarations ought to be flushed; it complicates much code while giving no useful return. I suspect some of the complications were not forseen when this feature was added to the language. I believe that the original purpose of this feature is subsumed by Deftype (which was added later). The largest issue that I see is that writing macros that parse declarations becomes much more complicated. Every macro writer must duplicate the non-trivial code which expands macros looking for declarations. Even if the macro writer goes to this trouble, a subtlety that he is sure to miss is supplying the &environment keyword to defmacro so that he can pass the lexical environment to macroexpand. If this feature must remain, then there should be standard functions for parsing declarations in the language. This might not be a bad idea anyway, but if the misfeature was eliminated there would be no need to pass in the lexical environment. I won't even discuss the hair & inefficiency that this misfeature adds to the system for fear of being accused of being a wimp or interpreter weenie; anyone who has implemented a Common Lisp knows it all too well. Rob  Received: from SU-AI.ARPA by MIT-MC.ARPA; 30 APR 85 10:44:18 EDT Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 30 Apr 85 07:35:18 PDT Received: from CHICOPEE.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 226352; Tue 30-Apr-85 10:34:29-EDT Date: Tue, 30 Apr 85 10:38 EDT From: Daniel L. Weinreb Subject: wimpy COERCE function To: Common-Lisp@SU-AI.ARPA In-Reply-To: <850429160029.5.MOON@EUPHRATES.SCRC.Symbolics.COM> Message-ID: <850430103856.8.DLW@CHICOPEE.SCRC.Symbolics.COM> I'd say it's clear that both the letter and the spirit of the manual say that this should signal an error. I feel that this is the right thing. The name MOD appears to be a pun capable of confusing people: it's just an abbreviation.  Received: from SU-AI.ARPA by MIT-MC.ARPA; 29 APR 85 20:27:39 EDT Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 29 Apr 85 17:13:51 PDT Received: from CROW.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 226043; Mon 29-Apr-85 20:12:59-EDT Date: Mon, 29 Apr 85 20:13 EDT From: Robert W. Kerns Subject: More on (B): the editor's "reading" of files To: David A. Moon cc: Jon White , common-lisp@SU-AI.ARPA In-Reply-To: <850425180639.0.MOON@EUPHRATES.SCRC.Symbolics.COM> Message-ID: <850429201354.0.RWK@CROW.SCRC.Symbolics.COM> Date: Thu, 25 Apr 85 18:06 EST From: David A. Moon Date: 25 Apr 85 0343 PST From: Jon White ....By the bye, I'm not sure if your reply laid to rest my "fear" that one can produce an almost-correct common lisp source file which the zetalisp editor can't even bring in to a buffer (previous note used "load") because it dies trying to READ some little part of it that happens to be total garbage. What's the scoop? We provide and document a command that reads a file into the editor without looking at its attributes. You are then editing the file in Fundamental Mode, and the editor makes no attempt to do anything language-specific. Also, we make use of our error system to trap such errors, report the problem gracefully, and then read it in in Fundamental Mode.  Received: from SU-AI.ARPA by MIT-MC.ARPA; 29 APR 85 16:08:52 EDT Received: from SCRC-VALLECITO.ARPA by SU-AI.ARPA with TCP; 29 Apr 85 13:00:31 PDT Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-VALLECITO.ARPA via CHAOS with CHAOS-MAIL id 10269; Mon 29-Apr-85 16:00:33-EDT Date: Mon, 29 Apr 85 16:00 EDT From: David A. Moon Subject: wimpy COERCE function To: Niels Lauritzen cc: BUG-LISPM%MIT-SPEECH@MIT-MC.ARPA, Common-Lisp@SU-AI.ARPA In-Reply-To: <850428192527.1.LAURITZEN@YOGI.MIT> Message-ID: <850429160029.5.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Sunday, 28 April 1985, 19:25-EDT From: Niels Lauritzen In Symbolics 3670 Release 6.0 >>Error: I don't know how to coerce an object to an integer modulo 3 Hey, any computer ought to know how to coerce integers to integers modulo N. COERCE: (P.C. = 22) Arg 0 (OBJECT): 45 Arg 1 (TO-TYPE): (MOD 3) I agree that this coercion would be easy to implement, provided you could get everyone to agree that what you meant was (MOD 45 3) rather than signalling an error that 45 was out of range. On the other hand, if you read the documentation of COERCE in the Common Lisp manual, this is not one of the coercions that it lists as permissible. I'm cc'ing this to the Common-Lisp mailing list in case anyone there wants to discuss the pros and cons of what Common Lisp specifies for COERCE. That discussion should not include the other recipients, please.  Received: from SU-AI.ARPA by MIT-MC.ARPA; 28 APR 85 17:06:29 EDT Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 28 Apr 85 13:59:55 PDT Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 225397; Sun 28-Apr-85 16:59:17-EDT Date: Sun, 28 Apr 85 17:00 EDT From: David A. Moon Subject: Any complete CL implementations?? To: Rem%IMSSS@SU-SCORE.ARPA cc: COMMON-LISP@SU-AI.ARPA In-Reply-To: The message of 5 Apr 85 15:24-EST from Rem@IMSSS Message-ID: <850428170009.6.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: 5 Apr 1985 1224-PST From: Rem@IMSSS At this time, has anybody completely 100% implemented Common LISP on any machine at all? .... I guess no one at Symbolics has answered this. Our implementation of Common Lisp, included in Release 6.0 of our 3600 software, is intended to be complete and correct. I'm sure there are still bugs that have not yet been found and fixed. In addition, there is a brief list of known deviations from the standard, which can be found in volume 2 of the Release 6 documentation set. The functions and features that are not implemented, according to that list, are integers as GO tags, certain declarations, row-major-order arrays, ARRAY-ROW-MAJOR-INDEX, MAKE-CONCATENATED-STREAM, MAKE-ECHO-STREAM, and ~E and ~G in FORMAT. The other deviations are minor: for details, find a 3600 installation and ask to look at their Release 6 documentation.  Received: from SU-AI.ARPA by MIT-MC.ARPA; 27 APR 85 14:52:22 EST Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 27 Apr 85 11:42:32 PST Date: Sat, 27 Apr 85 14:42:44 EST From: Tim McNerney Subject: Editing multiple package files To: DLW@SCRC-STONY-BROOK cc: Common-Lisp@SU-AI Message-ID: <[MIT-MC].472449.850427.TIM> Date: Thu, 18 Apr 85 13:10 EST From: Daniel L. Weinreb To: TIM at MC.MIT cc: common-lisp at SU-AI.ARPA Re: Compilation and package system, an addendum Date: Thu,18 Apr 85 01:22:26 EST From: Tim McNerney Yes, there could be an arbitrary amount of hair, but there is a big difference between assuming that an entire file will be read in the package declared by the -*- line and supporting lusers who want to generate the screw cases you allude to above. Once the package environment is established, simply having the ZMACS keep a package attribute for each section will support editing files like patch files which need to be read in a number of different packages. You seem to be saying that the high cost can be avoided by not supporting "lusers" who generate the "screw cases". In other words, the editor should not actually parse the entire file, because that costs too much, and it's OK if it does the wrong thing for the screw cases. I could be convinced of that principle. So, what is your counterproposal? Exactly what will the editor do when a file is read in, such that it does all the right things except in "screw cases"? How does it know where to stop parsing? And if you expect the editor to work correctly on files like patch files, with different package environments in each section, then you certainly do need to scan the entire file. If you disagree, what's your countersuggestion? No, not at all. You seem to have misunderstood me completely (This probably stems from your not having read the message that my message (above) was an addendum to). The original message merely suggested that since the editor has to scan the file at least once, namely when the file is first being read into the buffer (during "sectionization" in Zmacs' case), that the editor record the package for each definition at that time. The "screw cases" that I refer to are those where a NON-TRIVIAL package environment is set up BY THE FILE BEING READ IN. As I said, once the package environment is stable, having the editor support multiple package files is more tractable.  Received: from SU-AI.ARPA by MIT-MC.ARPA; 26 APR 85 18:03:05 EST Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 26 Apr 85 14:52:38 PST Date: Fri, 26 Apr 85 17:47:24 EST From: Glenn S. Burke Subject: package names, consistency To: common-lisp@SU-AI Message-ID: <[MIT-MC].471684.850426.GSB> Date: Thu, 25 Apr 1985 22:35 EST From: "Scott E. Fahlman" . . . If we are going to discuss changes, right now it sounds reasonable to me to allow package names in most of the places that are documented to take packages -- all except *package*, package-name, and package-nicknames -- as you suggest. I can't construct a good argument against this right now. This sounds reasonable. If one wants to draw comparisons, however, the various PATHNAME "accessors", such as pathname-host, pathname-name, all take anything which can be coerced to a pathname... There are a few other things, mostly nomenclature inconsistencies, which i have found myself explaining more than once. One of the worst appears to be simple-vector. It should have been left as simple-general-vector in spite of the verbiage.  Received: from SU-AI.ARPA by MIT-MC.ARPA; 26 APR 85 15:24:37 EST Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 26 Apr 85 12:11:22 PST Received: ID ; Fri 26 Apr 85 15:11:22-EST Date: Fri, 26 Apr 1985 15:11 EST Message-ID: From: Rob MacLachlan To: Jon White Cc: common-lisp@SU-AI.ARPA Subject: What package are feature names resident in? In-reply-to: Msg of 25 Apr 1985 07:19-EST from Jon White I believe that the issue discussed was "Should features always be keywords?" The conclusion was "No, but they can be." An implication of this decision is that features are packaged symbols. Rob  Received: from SU-AI.ARPA by MIT-MC.ARPA; 26 APR 85 03:01:40 EST Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 25 Apr 85 19:35:11 PST Received: ID ; Thu 25 Apr 85 22:35:31-EST Date: Thu, 25 Apr 1985 22:35 EST Message-ID: Sender: FAHLMAN@CMU-CS-C.ARPA From: "Scott E. Fahlman" To: Jon White Cc: common-lisp@SU-AI.ARPA Subject: When is a package name equivalent to a package? In-reply-to: Msg of 25 Apr 1985 03:54-EST from Jon White In the earlier messages we were discussing what the current situation is, according to the manual. I don't have time to search the archives, but it seems to me that where we said "package", we meant "package". We might even have had a good reason for this. If we are going to discuss changes, right now it sounds reasonable to me to allow package names in most of the places that are documented to take packages -- all except *package*, package-name, and package-nicknames -- as you suggest. I can't construct a good argument against this right now. -- Scott  Received: from SU-AI.ARPA by MIT-MC.ARPA; 26 APR 85 02:32:17 EST Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 25 Apr 85 15:06:49 PST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 224275; Thu 25-Apr-85 18:06:30-EST Date: Thu, 25 Apr 85 18:06 EST From: David A. Moon Subject: More on (B): the editor's "reading" of files To: Jon White cc: common-lisp@SU-AI.ARPA In-Reply-To: The message of 25 Apr 85 06:43-EST from Jon White Message-ID: <850425180639.0.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: 25 Apr 85 0343 PST From: Jon White ....By the bye, I'm not sure if your reply laid to rest my "fear" that one can produce an almost-correct common lisp source file which the zetalisp editor can't even bring in to a buffer (previous note used "load") because it dies trying to READ some little part of it that happens to be total garbage. What's the scoop? We provide and document a command that reads a file into the editor without looking at its attributes. You are then editing the file in Fundamental Mode, and the editor makes no attempt to do anything language-specific.  Received: from SU-AI.ARPA by MIT-MC.ARPA; 26 APR 85 01:47:32 EST Received: from UCB-VAX.ARPA by SU-AI.ARPA with TCP; 25 Apr 85 15:23:19 PST Received: from ucbdali.ARPA by UCB-VAX.ARPA (4.24/4.46) id AA05204; Thu, 25 Apr 85 15:22:11 pst Received: by ucbdali.ARPA (4.24/4.46) id AA13833; Thu, 25 Apr 85 15:23:59 pst Date: Thu, 25 Apr 85 15:23:59 pst From: fateman%ucbdali@Berkeley (Richard Fateman) Message-Id: <8504252323.AA13833@ucbdali.ARPA> To: rpg@su-ai Subject: RPG's benchmarks coming out as an MIT press book Cc: common-lisp@su-ai If the benchmarks which I submitted are going to appear in a copyrighted book, I would like explicit permission to appear that says that reproduction of the code, and reprinting of the tables with additional data, and similar modifications or corrections can be done without copyright hassles. If it appears that I will lose control of programs that I wrote as a consequence of RPG's paper, I would prefer to withdraw my benchmark. Although I think that an MIT press copyright of such a program would be invalid, let's try to set the correct precedent this time. We messed up royally on CLTL and Digital Press, in my opinion.  Received: from SU-AI.ARPA by MIT-MC.ARPA; 25 APR 85 09:49:30 EST Received: from DEC-HUDSON.ARPA by SU-AI.ARPA with TCP; 25 Apr 85 06:42:05 PST Date: Thu, 25 Apr 85 09:42:03 EST From: greek@DEC-HUDSON Subject: Code Generated by Macros To: common-lisp@su-ai Dave Plummer - Yes, I understand that you can write named DOs, and that Common LISP should probably have one (and maybe not the DO we actually have). I was simply pointing out that standard Common LISP macros could potentially be written incorrectly. That macro you supplied, DOTIMES-NAMED, doesn't seem to work. Glenn Burke - Huh? I'm not at all sure what you are trying to say. PROG is, in fact, no good for this problem since it generates a NIL block. Dave Moon - Thank you for that succinct summary. In fact, we DID have a problem with DO-ALL-SYMBOLS, because it used DO-SYMBOLS, so that two NIL blocks were generated and a RETURN would not quite get all the way out. That's what I was trying to say. - Paul  Received: from SU-AI.ARPA by MIT-MC.ARPA; 25 APR 85 07:29:38 EST Date: 25 Apr 85 0419 PST From: Jon White Subject: What package are feature names resident in? To: common-lisp@SU-AI.ARPA Bottom of page 358 clearly suggests that #+ should READ in the expression following the +, and obtain symbols which are tested for MEMBERship in the *features* list. So what should happen from the following fragment: (in-package "LUSER") (push 'dull *features*) (in-package "WINNER") (push 'snazzy *features*) (in-package "USER") '(a #+dull b #+snazzy c ) Now, how long a list is the last form read? Consider when package LUSER is, and is not, a user of package LISP; and when "dull" is, and is not, an external symbol of the LISP package. I believe I see two schools of thought, exemplified in the several implemetations I've looked at so far. One says that feature names can be any lisp objects, and since luser:snazzy and winner:snazzy are two separate features, you have to be careful about which one you really mean. The other school says that feature names are analogous to the names of packages -- a kind of global namespace -- and will probably implement #+ by binding *package* to some canonical place (like, the keyword package). I'm not sure I can give an adequate defense of either position, but the fact that two different implementations initialize their *features* lists to symbols in different packages makes it difficult to interpret forms like #+Lispm (do-this) because you don't which symbol the "Lispm" will turn into. Should you have to say #+:Lispm (do-this) I don't think this was intended (to have to put package qualifiers for feature names), but if there are two differing implemetations . . . Some folks here at Lucid think there was discussion on the matter a couple years ago, but no one seems sure if a resolution was achieved. Any commets? -- JonL -- P.S. The problem isnt IN-PACKAGE -- as someone pointed out already, it is so trivial as to be almost redundant. Most usages of it would be equivalent to (setq *package* (find-package )).  Received: from SU-AI.ARPA by MIT-MC.ARPA; 25 APR 85 07:00:36 EST Date: 25 Apr 85 0343 PST From: Jon White Subject: More on (B): the editor's "reading" of files To: moon@SCRC-STONY-BROOK.ARPA CC: common-lisp@SU-AI.ARPA In-reply-to: your message of 24-Apr-85 23:57 EST OK, I buy the argument that the editor wants to be able to distinguish various language types [egad, some even do so by looking at the "extension" field of the file name]; but after having made that distinction, wouldn't it be reasonable to dispatch off to a programmable attribute-parser that could be quite different from one language to another? That is, given that you know that a file is in Common Lisp syntax (as opposed to, say, Franz, or Fortran, or random text), then some flavor of specialized parser would rip along and find out attributes that are possibly unique to common lisp and possibly shared with other lisps. One of the problems with the ;;; -*- convention is its lack of "tailor-ability" by the user; and as this whole line of discussions has brought out, there are more and more things that seem to want to be in the attributes lines. Of course, these are only conventions for the initial, or default, settings of various user-accessible switches on the READer -- as DLW pointed out, one may still have to process the file "in order", form by form, to be 100% sure of the correct state at any paticular point in the file. Yet, if some convention like this isn't adopted, then will CL be substandard compared to zetalisp or spicelisp? One of the latter two conventions could be adopted bodily into CL; I'm sure you have a preference here. Interlisp has a number of internal, non-READ parsers that inspect the first portion of a file for certain information. But it is mainly a time-saving hack that READ isn't used, because such source files are virtually always mechaniclly produced, and have a very rigid format; in Interlisp, you can *always* READ the first expression or so of the file and look at it with CAR and CDR etc, because the Interlisp reader has no errors other than premature end of file. [well, almost *no* errors -- there is the problem that symbols are limited to 256 characters. I fixed a bug related to this limitation sometime last year.] By the bye, I'm not sure if your reply laid to rest my "fear" that one can produce an almost-correct common lisp source file which the zetalisp editor can't even bring in to a buffer (previous note used "load") because it dies trying to READ some little part of it that happens to be total garbage. What's the scoop? -- JonL --  Received: from SU-AI.ARPA by MIT-MC.ARPA; 25 APR 85 04:20:40 EST Date: 25 Apr 85 0054 PST From: Jon White Subject: When is a package name equivalent to a package? To: fahlman@CMU-CS-C.ARPA, moon@SCRC-STONY-BROOK.ARPA CC: common-lisp@SU-AI.ARPA In-reply-to: your messge of 24-Apr-85 22:04 EST There are only three places I can remember that explicitly say "... must be a package": the definition of *package*, the argument to package-name, and the argment to package-nicknames. It would seem reasonable to me to let all other arguments called "package" be coercible from symbols, strings, and packages. I can't say that requireing the arguments to package-name and package-nicknames to be "a package" achieves anything; I'd be happier with Moon's suggestion to let all function args be coercible. Actually, another constraint has been bugging me recently -- the argument to in-package is constrained to be a "name"; why not let it be a package also? If you did so, it would have no bearing one way or other on the advisibility of using a form like (IN-PACKAGE "USER") as a CL minor-mode specifier.  Received: from SU-AI.ARPA by MIT-MC.ARPA; 25 APR 85 00:06:29 EST Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 24 Apr 85 20:57:17 PST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 223602; Wed 24-Apr-85 23:56:50-EST Date: Wed, 24 Apr 85 23:57 EST From: David A. Moon Subject: Problems with packages? To: Jon White cc: common-lisp@SU-AI.ARPA In-Reply-To: The message of 23 Apr 85 05:34-EST from Jon White Message-ID: <850424235711.7.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: 23 Apr 85 0234 PST From: Jon White ....I think we can best spend our broadcasted mail time focusing on questions like the following: (A) What else besides the default setting of *package* should be added to the set of conventions? is the ZetaLisp "Syntax:" command adequate? Of course there is *read-base*, but what else? (B) Must the editor settle all parsing/syntax related settings before even "loading" in the file ? or can it wait until a READ operation is applied to some part of the buffer? a "lazy" parsing. (C) What are reasonable conventions for scoping a database configuration? Is a file the appropriate scope? What about streams that arent files? (B): In our editor, "loading" in a file applies READ operations to parts of it. How else is it supposed to know what functions are defined in the file? The READ operation used is of course parameterized by the language and dialect the file is written in, along with language-dependent parameters such as the package. Regarding (B), one may well ask why a line like (IN-PACKAGE "FOO") is any more mysterious to a default-context parser than the line ;;; Package: FOO I explained earlier that some editors, such as ours, need to support multiple languages. Not all languages have the same syntax for statements in the language itself (clearly!), but every language that we've heard of has comments and the same syntax of file attribute line (the line with the -*-) can be used inside the comments of every language that we've heard of. To give a concrete example of the issues: of the three dialects of Lisp we support, only one contains a function named IN-PACKAGE. Dill seemed to be asking this question in his note last week; one needn't think that the former line has to be subjected to READ any more than the latter one. But the more lispy looking line *can* be interpreted by the simple-minded read-eval-print loaded. It would be possible to make an editor that understands package specifications in some clearly defined syntax besides the clearly defined syntax of the file attribute line, and looks for that syntax if it doesn't find a file attribute line. Common Lisp does not begin to specify such a syntax, it merely suggests (p.182) that "all of the package setup forms appear near the start of the file." I'm not interested in spending my limited energies making this specification concrete enough that it could be useful to a program, but perhaps others are.  Received: from SU-AI.ARPA by MIT-MC.ARPA; 24 APR 85 22:41:06 EST Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 24 Apr 85 19:32:38 PST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 223559; Wed 24-Apr-85 22:32:34-EST Date: Wed, 24 Apr 85 22:32 EST From: David A. Moon Subject: When is a package name equivalent to a package? To: Scott E. Fahlman cc: common-lisp@SU-AI.ARPA In-Reply-To: Message-ID: <850424223253.7.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Wed, 24 Apr 1985 22:04 EST From: "Scott E. Fahlman" From: Moon I think the manual is quite clear. p.183 requires that the value of *package* be a package. p.182 specifies that certain functions, including INTERN, shall accept strings and symbols in place of packages. As is unfortunately typical of the CLM, this specification is not repeated in the documentation of each of the affected functions, so it's quite easy to overlook. Are we looking at the same page 182? Where does it say that? In the last paragraph it says that "Any argument described as a PACKAGE NAME may be either a string or a symbol." Is that waht you're thinking of? Intern takes a package argument, but says nothing about taking a package name instead. You're absolutely right. I didn't read the manual carefully enough and missed the word "name" after "package", especially since two sentences earlier in the same paragraoh it was talking about arguments named @I[package]. The wording could use some improvement here, I think. In fact page 182, now that I am reading it carefully, says nothing about what values are legal to pass to an argument named package. Now I have to ask if there is any significance to the fact that the argument to FIND-PACKAGE is called name rather than package-name. Obviously I should withdraw the first sentence of my earlier message! Our implementation of these functions (INTERN, USE-PACKAGE, IMPORT, etc.) accepts a package name as an argument where a package is required. It seems natural, and doesn't cost anything if you were doing error-checking anyway (and blithely assuming that the argument is a package seems extra-dangerous here!). However, I won't advocate that every implementation be required to accept a package name in place of a package.  Received: from SU-AI.ARPA by MIT-MC.ARPA; 24 APR 85 22:13:18 EST Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 24 Apr 85 19:04:28 PST Received: ID ; Wed 24 Apr 85 22:04:42-EST Date: Wed, 24 Apr 1985 22:04 EST Message-ID: Sender: FAHLMAN@CMU-CS-C.ARPA From: "Scott E. Fahlman" To: "David A. Moon" Cc: common-lisp@SU-AI.ARPA Subject: When is a package name equivalent to a package? In-reply-to: Msg of 24 Apr 1985 20:50-EST from David A. Moon I think the manual is quite clear. p.183 requires that the value of *package* be a package. p.182 specifies that certain functions, including INTERN, shall accept strings and symbols in place of packages. As is unfortunately typical of the CLM, this specification is not repeated in the documentation of each of the affected functions, so it's quite easy to overlook. Are we looking at the same page 182? Where does it say that? In the last paragraph it says that "Any argument described as a PACKAGE NAME may be either a string or a symbol." Is that waht you're thinking of? Intern takes a package argument, but says nothing about taking a package name instead. -- Scott  Received: from SU-AI.ARPA by MIT-MC.ARPA; 24 APR 85 21:55:39 EST Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 24 Apr 85 18:29:19 PST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 223514; Wed 24-Apr-85 21:29:10-EST Date: Wed, 24 Apr 85 21:29 EST From: David A. Moon Subject: Code Generated by Macros To: greek@DEC-HUDSON.ARPA cc: common-lisp@SU-AI.ARPA In-Reply-To: The message of 24 Apr 85 12:58-EST from greek@DEC-HUDSON Message-ID: <850424212930.6.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Wed, 24 Apr 85 12:58:16 EST From: greek@DEC-HUDSON We found that the following "macros" generated loops that hid a surrounding NIL block: CCASE CTYPECASE DO-SYMBOLS et al lots of compiler transformations (e.g., that turned a map into a loop) DO-SYMBOLS is clearly documented to create a block named NIL. You're right that the others are errors. Our implementation handles these correctly, but perhaps you were talking about macro definitions in some other implementation, such as Spice Lisp. It's quite easy to do them right. Also, of course, plenty of macros written by users can inadvertently cause the problem. The simplest way around is to only generate TAGBODYs. Even PROG establishes a NIL block. A good rule of thumb is never to use PROG under any circumstances for anything. The real problem is DO, which you would often like to use, but have to be careful about whether you intended to create a block or not. A good rule of thumb is to write macros whose name does not start with "DO" in terms of BLOCK, LET, and TAGBODY only -- then everything is explicit.  Received: from SU-AI.ARPA by MIT-MC.ARPA; 24 APR 85 21:33:39 EST Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 24 Apr 85 18:21:54 PST Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 223510; Wed 24-Apr-85 21:21:31-EST Date: Wed, 24 Apr 85 21:21 EST From: Kent M Pitman Subject: When is a package name equivalent to a package? To: Moon@STONY-BROOK.SCRC.Symbolics.COM, RAM@CMU-CS-C.ARPA cc: JLW@SU-AI.ARPA, common-lisp@SU-AI.ARPA In-Reply-To: <850424205010.3.MOON@EUPHRATES.SCRC.Symbolics.COM> Message-ID: <850424212146.1.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> Return-path: <@MIT-MC.ARPA,@SU-AI.ARPA:Moon@STONY-BROOK.SCRC.Symbolics.COM> Received: from MIT-MC.ARPA by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 223502; 24 Apr 85 21:10:54-EST Received: from SU-AI.ARPA by MIT-MC.ARPA; 24 APR 85 21:00:04 EST Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 24 Apr 85 17:50:03 PST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 223474; Wed 24-Apr-85 20:49:47-EST Date: Wed, 24 Apr 85 20:50 EST From: David A. Moon Subject: When is a package name equivalent to a package? To: Rob MacLachlan cc: Jon White , common-lisp@SU-AI.ARPA In-Reply-To: Message-ID: <850424205010.3.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Wed, 24 Apr 1985 10:13 EST From: Rob MacLachlan Date: Tuesday, 23 April 1985 01:30-EST From: Jon White There is such consistency in this choice of phraseology that I take it to mean that unless there is a clear statement that the argment must be a package datatype, then it is permissible for it to be anything reasonably coerceible to a package. In this case, (intern ... 'KEYWORD) is the same as (intern ... "KEYWORD") and (intern ... (find-package "KEYWORD")) Does everyone agree that this is correct? If this is the case, then may *package* be random things also? Currently Spice Lisp requires every package argument to be a package. I think the manual is quite clear. p.183 requires that the value of *package* be a package. p.182 specifies that certain functions, including INTERN, shall accept strings and symbols in place of packages. As is unfortunately typical of the CLM, this specification is not repeated in the documentation of each of the affected functions, so it's quite easy to overlook. I wonder if it wouldn't be worth introducing a PACKAGE-BIND special form, as in: (DEFMACRO PACKAGE-BIND (PACKAGE &BODY FORMS) `(LET ((*PACKAGE* (FIND-PACKAGE ,PACKAGE))) ,@FORMS)) just so users would never need to explicitly call FIND-PACKAGE. Sure enough, I just checked and there's an SI:PKG-BIND special form which does exactly that on the LispM so someone must have agreed with this suggestion...  Received: from SU-AI.ARPA by MIT-MC.ARPA; 24 APR 85 20:59:33 EST Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 24 Apr 85 17:50:03 PST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 223474; Wed 24-Apr-85 20:49:47-EST Date: Wed, 24 Apr 85 20:50 EST From: David A. Moon Subject: When is a package name equivalent to a package? To: Rob MacLachlan cc: Jon White , common-lisp@SU-AI.ARPA In-Reply-To: Message-ID: <850424205010.3.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Wed, 24 Apr 1985 10:13 EST From: Rob MacLachlan Date: Tuesday, 23 April 1985 01:30-EST From: Jon White There is such consistency in this choice of phraseology that I take it to mean that unless there is a clear statement that the argment must be a package datatype, then it is permissible for it to be anything reasonably coerceible to a package. In this case, (intern ... 'KEYWORD) is the same as (intern ... "KEYWORD") and (intern ... (find-package "KEYWORD")) Does everyone agree that this is correct? If this is the case, then may *package* be random things also? Currently Spice Lisp requires every package argument to be a package. I think the manual is quite clear. p.183 requires that the value of *package* be a package. p.182 specifies that certain functions, including INTERN, shall accept strings and symbols in place of packages. As is unfortunately typical of the CLM, this specification is not repeated in the documentation of each of the affected functions, so it's quite easy to overlook.  Received: from SU-AI.ARPA by MIT-MC.ARPA; 24 APR 85 19:57:35 EST Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 24 Apr 85 12:07:28 PST Received: from NEPONSET.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 223090; Wed 24-Apr-85 15:07:14-EST Date: Wed, 24 Apr 85 15:07 EST From: David C. Plummer in disguise Subject: Code Generated by Macros To: greek@DEC-HUDSON.ARPA, common-lisp@SU-AI.ARPA In-Reply-To: The message of 24 Apr 85 09:54-EST from greek at DEC-HUDSON References: The message of 24 Apr 85 09:54-EST from greek at DEC-HUDSON, Message-ID: <850424150703.5.NFEP@NEPONSET.SCRC.Symbolics.COM> Date: Wed, 24 Apr 85 09:54:41 EST From: greek@DEC-HUDSON Did anyone out there write any of the Common LISP macro definitions so that they generate DO, DOTIME, DOLIST or the like? Oops. If the programmer uses a macro inside a construct that establishes a block named NIL, and then does a RETURN from inside the macro, there had better not be any blocks named NIL generated by the macro, or the RETURN will return to the wrong place. Not an obvious problem, and we blew it. Or maybe the idea of a block named NIL is bogus. I know what you are talking about, but I can't come up with an example that can't be programmed around. For example, (defmacro dotimes-named (name (var form) &body body) `(block ,name (return-from nil (block do-return-from-nil (return-from ,name (dotimes (,var ,form) (block dont-return-from-nil (return-from do-return-from-nil (block nil ,@body (return-from dont-return-from-nil)))))))))) It isn't pretty, but it does work. I don't know if there are easier ways to do this particular things. I have seen easier ways to other similar things. Perhaps it is for reasons like this that Lisp Machine Lisp has DO-NAMED? That is, perhaps DO-NAMED is the prefered thing to expand into instead of DO, since it won't accidentally steal the block named NIL? Another way out is to document your macros as "having an implicit block named NIL".  Received: from SU-AI.ARPA by MIT-MC.ARPA; 24 APR 85 19:38:31 EST Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 24 Apr 85 16:28:38 PST Date: Wed, 24 Apr 85 19:18:08 EST From: Glenn S. Burke Subject: Code Generated by Macros To: common-lisp@SU-AI Message-ID: <[MIT-MC].468518.850424.GSB> Date: Wed, 24 Apr 85 12:58:16 EST From: greek@DEC-HUDSON We found that the following "macros" generated loops that hid a surrounding NIL block: CCASE CTYPECASE DO-SYMBOLS et al lots of compiler transformations (e.g., that turned a map into a loop) Also, of course, plenty of macros written by users can inadvertently cause the problem. The simplest way around is to only generate TAGBODYs. Even PROG establishes a NIL block. Oh come on. This is what BLOCK and GENSYM are good for. This is why named PROGs have been useful in the past (in NIL and Zetalisp). GENSYM is also good for generating tags within your tagbody -- you still need to worry about uniqueness there.  Received: from SU-AI.ARPA by MIT-MC.ARPA; 24 APR 85 18:05:23 EST Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 24 Apr 85 08:36:03 PST Received: ID ; Wed 24 Apr 85 11:35:57-EST Date: Wed, 24 Apr 1985 11:35 EST Message-ID: Sender: WHOLEY@CMU-CS-C.ARPA From: Skef Wholey To: greek@DEC-HUDSON.ARPA Cc: common-lisp@SU-AI.ARPA Subject: Code Generated by Macros In-reply-to: Msg of 24 Apr 1985 09:54-EST from greek at DEC-HUDSON Yeah, I went through a little bit of contortion to make Do-All-Symbols and friends be efficient and maintain the right block structure. I don't remember any other macros in the language that require bending over backwards to do this sort of thing. Do you have a list of such things that you ran into for the rest of us? Zetalisp has some stuff to get around this problem (which makes it easier for users to write iteration macros that do the right thing), but I doubt it could be easily added to the Common Lisp language. Since Common Lisp programs are supposed to be easily machine-analyzable, one might write a portable thing that mangles the Returns inside a piece of code to return to a block of one's choice. It might be worth a sentence or two in the manual to point out to implementors and users alike that one may have to resort to writing hairy Progs to retain the "returnability" feature. Implementors are, of course, required to do so for things specified in CLTL, and users should be encouraged to do so. --Skef  Received: from SU-AI.ARPA by MIT-MC.ARPA; 24 APR 85 17:25:34 EST Received: from DEC-HUDSON.ARPA by SU-AI.ARPA with TCP; 24 Apr 85 09:58:21 PST Date: Wed, 24 Apr 85 12:58:16 EST From: greek@DEC-HUDSON Subject: Code Generated by Macros To: common-lisp@su-ai We found that the following "macros" generated loops that hid a surrounding NIL block: CCASE CTYPECASE DO-SYMBOLS et al lots of compiler transformations (e.g., that turned a map into a loop) Also, of course, plenty of macros written by users can inadvertently cause the problem. The simplest way around is to only generate TAGBODYs. Even PROG establishes a NIL block. - Paul  Received: from SU-AI.ARPA by MIT-MC.ARPA; 24 APR 85 16:19:09 EST Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 24 Apr 85 07:50:03 PST Received: ID ; Wed 24 Apr 85 10:50:09-EST Date: Wed, 24 Apr 1985 10:49 EST Message-ID: Sender: FAHLMAN@CMU-CS-C.ARPA From: "Scott E. Fahlman" To: Rob MacLachlan Cc: common-lisp@SU-AI.ARPA, Jon White Subject: Bug in CLM? In-reply-to: Msg of 24 Apr 1985 10:13-EST from Rob MacLachlan I seem to have misplaced JONL's original message, so I'm not sure what "consistency of terminology" he is referring to. I think that any consistency in the manual is purely coincidental. :-} I believe that in writing the package chapter we were careful to say that an argument could be "a package or package name" where that is what we meant. (A package name can be either a string or a symbol.) When we don't say that, as in INTERN, "package" means an object of type package and nothing else. It certainly is not the case that *package* can be anything but a true package. See page 174, the first sentence after the heading for section 11.3, for a definitive statement of this. -- Scott  Received: from SU-AI.ARPA by MIT-MC.ARPA; 24 APR 85 10:27:14 EST Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 24 Apr 85 07:14:05 PST Received: ID ; Wed 24 Apr 85 10:14:03-EST Date: Wed, 24 Apr 1985 10:13 EST Message-ID: From: Rob MacLachlan To: Jon White Cc: common-lisp@SU-AI.ARPA Subject: Bug in CLM? In-reply-to: Msg of 23 Apr 1985 01:30-EST from Jon White Date: Tuesday, 23 April 1985 01:30-EST From: Jon White cc: common-lisp at SU-AI.ARPA Re: Bug in CLM? There is such consistency in this choice of phraseology that I take it to mean that unless there is a clear statement that the argment must be a package datatype, then it is permissible for it to be anything reasonably coerceible to a package. In this case, (intern ... 'KEYWORD) is the same as (intern ... "KEYWORD") and (intern ... (find-package "KEYWORD")) Does everyone agree that this is correct? If this is the case, then may *package* be random things also? Currently Spice Lisp requires every package argument to be a package. Rob  Received: from SU-AI.ARPA by MIT-MC.ARPA; 24 APR 85 10:08:21 EST Received: from DEC-HUDSON.ARPA by SU-AI.ARPA with TCP; 24 Apr 85 06:54:42 PST Date: Wed, 24 Apr 85 09:54:41 EST From: greek@DEC-HUDSON Subject: Code Generated by Macros To: common-lisp@su-ai Did anyone out there write any of the Common LISP macro definitions so that they generate DO, DOTIME, DOLIST or the like? Oops. If the programmer uses a macro inside a construct that establishes a block named NIL, and then does a RETURN from inside the macro, there had better not be any blocks named NIL generated by the macro, or the RETURN will return to the wrong place. Not an obvious problem, and we blew it. Or maybe the idea of a block named NIL is bogus. - Paul  Received: from SU-AI.ARPA by MIT-MC.ARPA; 23 APR 85 05:51:07 EST Date: 23 Apr 85 0234 PST From: Jon White Subject: Problems with packages? To: common-lisp@SU-AI.ARPA Just to review, do we all agree that (1) readtables, (2) packages, (3) dynamic variables *read-base* and *read-suppress* etc all form part of a global database affecting the reader syntax, and that it is a unique featue of Lisp that this database may be modified dynamically by the user? Perhaps a fourth point ought to be added: (4) packages do not solve, nor even address, the problem of lexicality. Too often in the past several years I've seen persons who "come up" with a solution to the problem of lexical variables by "putting them in separate packages". It takes a lot of explaining to separate out the difference between syntax parsing and program semantics; perhaps it is because Lisp is so lividly dynamic that this confusion is so easy to make. On the other hand, the spate of conjectures as to what "lexical packages" might possibly mean leads to a situation, a variant of (4), which could be stated as: (5) lexicality does not solve, nor even address, the problem of packages. Given this background, and the fact that the "lexical packages" discussion seems to have been started by a misunderstanding of "lexical" or "packages" or both, then I think we can best spend our broadcasted mail time focusing on questions like the following: (A) What else besides the default setting of *package* should be added to the set of conventions? is the ZetaLisp "Syntax:" command adequate? Of course there is *read-base*, but what else? (B) Must the editor settle all parsing/syntax related settings before even "loading" in the file ? or can it wait until a READ operation is applied to some part of the buffer? a "lazy" parsing. (C) What are reasonable conventions for scoping a database configuration? Is a file the appropriate scope? What about streams that arent files? Regarding (B), one may well ask why a line like (IN-PACKAGE "FOO") is any more mysterious to a default-context parser than the line ;;; Package: FOO Dill seemed to be asking this question in his note last week; one needn't think that the former line has to be subjected to READ any more than the latter one. But the more lispy looking line *can* be interpreted by the simple-minded read-eval-print loaded. Weinreb seemed to summarize the differences between th ZetaLisp approach and the SpiceLisp approach as the amount of importance attached to the editor context problem. I hope it will never be the case, such as it is now in Interlisp, that one can create files which the standard system tools cannot parse well enough to be able to edit (and, hence to fix the silly little bug that managed to creep into them). Admittedly it doesn't happen often, but on those ocasions one must abandon the standard program/file editor (in Interlisp) and drop down to some kind of text editor to repair the damage. [It is not, repeat not, such a simple thing to do to an Interlisp program file, for generally lots of low-level things you never really wanted to know about will break when you "hand- edit" a file, and you'll spend half an hour to half a day trying to figure out random messages about "file maps" and so on.] -- JonL --  Received: from SU-AI.ARPA by MIT-MC.ARPA; 23 APR 85 01:45:35 EST Date: 22 Apr 85 2230 PST From: Jon White Subject: Bug in CLM? To: ram@CMU-CS-A.ARPA CC: common-lisp@SU-AI.ARPA Regarding the second of your two bugs -- I notice a difference in terminology in the manual between some functions of chapter 11 and others. In particular, some functions are documented like 'package-name' is, namely it specifies that "The argument must be a package". But others, such as 'intern' for example, lack any such constraint, and use phrases like "the specified package". There is such consistency in this choice of phraseology that I take it to mean that unless there is a clear statement that the argment must be a package datatype, then it is permissible for it to be anything reasonably coerceible to a package. In this case, (intern ... 'KEYWORD) is the same as (intern ... "KEYWORD") and (intern ... (find-package "KEYWORD")) -- JonL --  Received: from SU-AI.ARPA by MIT-MC.ARPA; 21 APR 85 07:04:30 EST Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 21 Apr 85 03:57:37 PST Received: ID ; Sun 21 Apr 85 06:57:44-EST Date: Sun, 21 Apr 1985 06:57 EST Message-ID: From: Rob MacLachlan To: common-lisp@SU-AI.ARPA Subject: Bug in CLM. In CLTL, the description of #S on page 357 refers to the defstruct constructor macro, when there is no such thing. Obviously what is meant here is a keyword (as opposed to BOA) constructor function. The same description also appears to have an erroneous piece of lisp code. The symbol KEYWORD is passed to intern to indicate that the symbol is interned in the keyword package. The manual says that the package argument "must be a package". Rob  Received: from SU-AI.ARPA by MIT-MC.ARPA; 20 APR 85 00:40:33 EST Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 19 Apr 85 21:32:47 PST Received: from SCRC-CHICOPEE by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 218506; Sat 20-Apr-85 00:32:28-EST Date: Sat, 20 Apr 85 00:34 EST From: Daniel L. Weinreb Subject: "lexical" packages To: masinter.pa@XEROX.ARPA, Common-Lisp@SU-AI.ARPA In-Reply-To: The message of 17 Apr 85 20:20-EST from masinter.pa@XEROX.ARPA Message-ID: <850420003442.2.DLW@CHICOPEE.SCRC.Symbolics.COM> One other thing: you still have to let some of these things work from interactive Lisp top level, or else it will be hard for programmers to try things out, learn, interactively debug, and so on. I don't think in-package is needed, but I think most of the others are. By the way, our implementation doesn't actually forbid you from typing a (declare ...) form at top level. It just returns the symbol DECLARE, as Maclisp did. The interpreter does this with declare forms inside programs, as well. The compiler gives you a warning, saying that the declare doesn't belong there, and ignores it. Your proposal uses the term "special form" in a non-standard way; COND and DEFUN are special forms. In fact, I think the CLRM is wrong when it refers to DECLARE as a special form; in fact, (DECLARE ---) isn't a form at all, the way that the CLRM defines it. This is probably what led to the ambiguity.  Received: from SU-AI.ARPA by MIT-MC.ARPA; 20 APR 85 00:36:05 EST Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 19 Apr 85 21:28:19 PST Received: from SCRC-CHICOPEE by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 218502; Sat 20-Apr-85 00:28:00-EST Date: Sat, 20 Apr 85 00:30 EST From: Daniel L. Weinreb Subject: "lexical" packages To: masinter.pa@XEROX.ARPA, Common-Lisp@SU-AI.ARPA In-Reply-To: The message of 17 Apr 85 20:20-EST from masinter.pa@XEROX.ARPA Message-ID: <850420003003.1.DLW@CHICOPEE.SCRC.Symbolics.COM> If you recall my four-point message (of Tue, 16 Apr 85 17:20 EST, replying to Skef), your proposal indeed meets all four points. It also solves the editor-scanning problem, since as soon as the editor sees any normal forms it can stop scanning. It also solves all those other problems I mentioned about evaluating those things inside various forms or functions, since they can no longer appear there. Only one problem comes to mind, and it's not hard to solve. Sometimes you have a system made up of many files that are all in the same package, and all have the same package environement. (In fact, almost all of the software that we work on here is big enough that we handle it this way.) It would be inconvenient and error-prone to have to duplicate the package setup information in each of the files, since it needs to be modified from time to time. There needs to be some kind of indirection feature that lets you have one centralized file holding the package setup. The editor would have to read this centralized file when the original file is read in. This leads to problems inherent in storing absolute pathnames inside of files. On the Lisp Machine, we would store logical pathnames, so that if the whole group of files were installed at some other site, the embedded pathname would still work. This is outside the realm of CLTL as currently defined, but for us it should suffice. There may be other problems with embedded pathnames that aren't coming to mind, however. I'd like to hear other comments.  Received: from SU-AI.ARPA by MIT-MC.ARPA; 18 APR 85 22:19:18 EST Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 18 Apr 85 19:07:24 PST Date: Thu,18 Apr 85 22:01:15 EST From: Kent M Pitman Subject: "lexical" packages To: Common-Lisp@SU-AI, Masinter.PA@XEROX, Fahlman@CMU-CS-C, Moon@SCRC-STONY-BROOK Message-ID: <[MIT-MC].460578.850418.KMP> I'd prefer to see the sort of lexicality I think you're talking about handled through OPEN rather than READ, but agree it's worth thinking about..  Received: from SU-AI.ARPA by MIT-MC.ARPA; 18 APR 85 21:56:49 EST Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 18 Apr 85 18:47:32 PST Received: from SCRC-EUPHRATES by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 217657; Thu 18-Apr-85 21:47:29-EST Date: Thu, 18 Apr 85 21:44 EST From: David A. Moon Subject: "lexical" packages To: masinter.pa@XEROX.ARPA cc: Common-Lisp@SU-AI.ARPA In-Reply-To: The message of 17 Apr 85 20:20-EST from masinter.pa at XEROX Message-ID: <850418214445.5.MOON@EUPHRATES.SCRC.Symbolics.COM> I understand now that what you meant was not at all what you seemed to be saying. This will bear some thinking about. More from me on this later, perhaps.  Received: from SU-AI.ARPA by MIT-MC.ARPA; 18 APR 85 16:04:36 EST Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 18 Apr 85 12:52:55 PST Received: from IMSSS by Score with Pup; Thu 18 Apr 85 12:39:03-PST Date: 18 Apr 1985 1235-PST From: Rem@IMSSS Subject: What is a "file"? Lexical package usage? To: COMMON-LISP%SU-AI@SCORE A file signals its end by an end-of-file marker of some kind (I'd have to look in the CL manual to remind myself what it is in CL). The beginning of a file is indicated by being right after you have done some kind of OPEN, and is lexical extent is from that point unti the end-of-file marker occurs. Perhaps if lexical packages are implemented, other streams can issue package and other start-of-file stuff right after they are "opened" whatever that means for the stream, and can signal the end of a lexical segment by an end-of-file marker? For terminal-input and other infinite streams, the interpretor can immediately re-open them after noting the lexical break caused by end-of-file, flushing any info it had about the package state from the just-now-closed segment and preparing to accept new package declarations from the new segment to arrive next on the re-opened stream. Would that solve the problem with "IN A FILE" being a special case? -------  Received: from SU-AI.ARPA by MIT-MC.ARPA; 18 APR 85 13:25:41 EST Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 18 Apr 85 10:10:21 PST Received: from SCRC-CHICOPEE by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 216975; Thu 18-Apr-85 13:09:26-EST Date: Thu, 18 Apr 85 13:10 EST From: Daniel L. Weinreb Subject: Compilation and package system, an addendum To: TIM@MC.MIT cc: common-lisp@SU-AI.ARPA In-Reply-To: <[MIT-MC].459123.850418.TIM> Message-ID: <850418131043.2.DLW@CHICOPEE.SCRC.Symbolics.COM> Date: Thu,18 Apr 85 01:22:26 EST From: Tim McNerney Yes, there could be an arbitrary amount of hair, but there is a big difference between assuming that an entire file will be read in the package declared by the -*- line and supporting lusers who want to generate the screw cases you allude to above. Once the package environment is established, simply having the ZMACS keep a package attribute for each section will support editing files like patch files which need to be read in a number of different packages. You seem to be saying that the high cost can be avoided by not supporting "lusers" who generate the "screw cases". In other words, the editor should not actually parse the entire file, because that costs too much, and it's OK if it does the wrong thing for the screw cases. I could be convinced of that principle. So, what is your counterproposal? Exactly what will the editor do when a file is read in, such that it does all the right things except in "screw cases"? How does it know where to stop parsing? And if you expect the editor to work correctly on files like patch files, with different package environments in each section, then you certainly do need to scan the entire file. If you disagree, what's your countersuggestion?  Received: from SU-AI.ARPA by MIT-MC.ARPA; 17 APR 85 21:05:31 EST Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 17 Apr 85 17:51:50 PST Received: ID ; Wed 17 Apr 85 20:51:55-EST Date: Wed, 17 Apr 1985 20:51 EST Message-ID: Sender: FAHLMAN@CMU-CS-C.ARPA From: "Scott E. Fahlman" To: masinter.pa@XEROX.ARPA Cc: Common-Lisp@SU-AI.ARPA Subject: "lexical" packages In-reply-to: Msg of 17 Apr 1985 20:20-EST from masinter.pa at Xerox.ARPA Larry, OK, now I think I understand what you're saying, as far as it goes. This is very similar to what the Symbolics people were just arguing for: that all of the package stuff happens at the start of a file, and the "scope" within which a package is the default for the reader is one file. I'm basically in sympathy with the idea that you don't change the package environment in the middle of a file. Right now, I can't think of any situation in which I'd really want to change packages within a file. So far, so good. I think that I would often want to load N files, some of which go into package A and some of which go into package B in any order. There's no problem with this as long as each file going into a certain package has identical (or maybe just compatible) package stuff at the start. To me, this isn't exactly lexical, as I understand the term, but there's no point in quibbling about terminology. What I don't understand about your proposal is how one deals with input to the reader that is not in the form of a file, with its natural lexical boundaries. How do we handle terminal input, input from streams whose source is unknown to the Lisp, and so on, if not dynamically? If the essence of your proposal is that we handle packages more as less as we do now, except that IN FILES the package forms must all occur at the start and the system can take their scope to be the whole file, that's worth some careful study. It certainly is good style in all the situations I can think of, so maybe enforcing it wouldn't be so bad. However, this sort of messes up the abstraction that Lisp just sucks streams into the reader and that the reader doesn't care where the stuff is coming from. -- Scott  Received: from SU-AI.ARPA by MIT-MC.ARPA; 17 APR 85 20:36:02 EST Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 17 Apr 85 17:22:19 PST Received: from Semillon.ms by ArpaGateway.ms ; 17 APR 85 17:20:45 PST Date: 17 Apr 85 17:20 PST From: masinter.pa@Xerox.ARPA Subject: "lexical" packages To: Common-Lisp@SU-AI.ARPA Rebuttals: Fahlman: "When we're speaking of the scope variables, lexical scoping means that the scope of the variable is one contiguous chunk in the file being read, and once you leave the lexical block you can never again get hold of that variable by using its name (though function closures defined within the block can still get at the variable). You cannot sneak in one more function later that refers to the same X. That's awkward at times, but also an advantage, since the compiler can be sure that after it has reached the end of a block, it knows all about how a lexical variable in that block can be referenced." Of course this isn't true, lest we be reduced to using core dumps to debug. Of course, the debugger and the environment can reasonably be expected to provide a way to access "lexical" variables. But such mechanisms are part of CLTE rather than CLTL. The language has semantics with invariants (if you (setq x --) here and call a function, you can still expect x to have the same value), and the environment gives you tools to break those invariants. Thus, while I propose making the "package" a lexical property (more on that later), any reasonable environment would provide ways of dynamically switching. Moon: "T has some reasonable responses to these issues, and I think if Common Lisp were being designed in 1987 we might decide differently after studying languages such as T and how their users use them. But Common Lisp was designed in 1982. We decided to go with the well-understood package philosophy that the Lisp machine had been using since about 1978, substantially redesigned to fix its well-understood bugs without radically changing the whole philosophy. It's hard to achieve perfection in this mortal vale. For additional insight, see the James Madison quotation on the second page of the manual." This is one of the weakest arguments to make -- it can be applied to any of the discussions on this or any of the other mailing lists about Common Lisp. If there's no chance to remove some of the mistakes in Common Lisp, there seems to be no grounds for further discussion. - - - - - - - Restatement of proposal: Packages should rightfully be lexical (determined by character sequences in the file) rather than a dynamic (determined by what you've recently executed). Let me make a specific proposal: Just as (DECLARE --) is a special form, and "it is an error" to attempt to evaluate a declaration, I propose that provide, in-package, shadow, export, require, use-package, import all be documented as as special forms; they may only occur at the beginnings of files. They are special markers that load, the compiler, and the editor etc. can look for. (The wording for this can be taken almost directly from the documentation of "declare" in CLTL p 153). This turns what was formally a convention into a requirement. It means that editors/file packages/etc. can actually look at a file and determine (by scanning the beginning of the file) what packages might be used/exported/etc. by the file. It makes illegal most of the odd (bad programming practice) things that can go wrong with the package system. It removes the requirement that the whole file be read, parsed and executed in order to get a particular function. Many of the caveats in the package section could be removed. For those who already have an implementation of the current package mechanism, the burden of this new scheme is minimal -- they can add error checking, but need not.  Received: from SU-AI.ARPA by MIT-MC.ARPA; 17 APR 85 11:51:48 EST Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 17 Apr 85 08:40:54 PST Date: Wed,17 Apr 85 11:40:48 EST From: Glenn S. Burke Subject: Re: Compilation and package system To: Moon@SCRC-STONY-BROOK cc: Common-lisp@SU-AI Message-ID: <[MIT-MC].458008.850417.GSB> From: David A. Moon Side-comment: I know of three other (besides Symbolics) Lisps that use the -*- convention for file attributes and have representatives on this mailing list. I'm mildly surprised that none of them have spoken up so far. I had thought i had sent a request to my PR department to send the standard file-attribute-list blurb off to the common-lisp people, but they must have slipped up. Oh well -- you know what it's like in these huge organizations. NIL uses file attribute lists quite heavily. The method in which they are defined is (or at least was a year ago) an extension of how it was done in Zetalisp, too. They are most commonly used for package specification, and secondarily for specifying the reader syntax, since NIL has been incrementally converted to common-lisp reader syntax. (This doesn't count "editor mode", but that's almost invariably "lisp" for lisp code anyway.)  Received: from SU-AI.ARPA by MIT-MC.ARPA; 17 APR 85 11:13:29 EST Received: from SCRC-QUABBIN.ARPA by SU-AI.ARPA with TCP; 17 Apr 85 08:00:10 PST Received: from SCRC-CHICOPEE by SCRC-QUABBIN via CHAOS with CHAOS-MAIL id 154375; Wed 17-Apr-85 11:00:10-EST Date: Wed, 17 Apr 85 11:01 EST From: Daniel L. Weinreb Subject: Package system To: David.Dill@CMU-CS-A.ARPA, common-lisp@SU-AI.ARPA In-Reply-To: <16Apr85.205840.DD60@CMU-CS-A.ARPA> Message-ID: <850417110105.7.DLW@CHICOPEE.SCRC.Symbolics.COM> Date: Tue, 16 Apr 85 20:58 EST From: David.Dill@CMU-CS-A.ARPA (L170DD60) Why does the editor problem have to be so hard? It seems to me that if programmers would make the call to in-package be the first lisp form in the file, the editor would have no more trouble setting up the proper package context than it would with the magic comment crock. What if there are some IMPORT forms following the IN-PACKAGE form? What if there are some IMPORT forms 3/4 of the way into the file? How does the editor know when to stop scanning for such forms?  Received: from SU-AI.ARPA by MIT-MC.ARPA; 17 APR 85 01:33:58 EST Received: from CMU-CS-A.ARPA by SU-AI.ARPA with TCP; 16 Apr 85 18:08:32 PST Date: Tue, 16 Apr 85 20:58 EST From: David.Dill@CMU-CS-A.ARPA (L170DD60) To: common-lisp@su-ai.arpa Subject: Package system Message-Id: <16Apr85.205840.DD60@CMU-CS-A.ARPA> One must use the package system in a very restricted way in order for compilers, editors, and other (mostly not-yet-existent) program transformation tools to do reasonable things. During the design of the package system, I don't think that anyone was under the delusion that arbitrary common lisp code sequences that manipulate the package system (or do a large number of other things) would behave the same compiled as interpreted. The package chapter should probably have had more to say about this, and should not have documented the "conventional use of the package system", which is very important for preserving sanity, in the "example" subsection. Somewhere, relatively simple restrictions on the use of the package system should be precisely described, so that users can distinguish code that will work from code that might not, and portable code from non-portable code. Why does the editor problem have to be so hard? It seems to me that if programmers would make the call to in-package be the first lisp form in the file, the editor would have no more trouble setting up the proper package context than it would with the magic comment crock. I also think that if complex package structures turn out to be really necessary (which I am not convinced of), a number of standard ways to deal with them could be developed so that a user could be reasonably assured of not getting screwed, AND editors, compilers, and so on, would be able to understand what is going on, all within CL.  Received: from SU-AI.ARPA by MIT-MC.ARPA; 17 APR 85 00:59:01 EST Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 16 Apr 85 14:33:03 PST Received: from SCRC-CHICOPEE by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 215535; Tue 16-Apr-85 17:20:07-EST Date: Tue, 16 Apr 85 17:20 EST From: Daniel L. Weinreb Subject: Compilation and package system To: Wholey@CMU-CS-C.ARPA cc: Common-lisp@SU-AI.ARPA, perdue%hplabs.csnet@CSNET-RELAY.ARPA In-Reply-To: , The message of 9 Apr 85 22:14-EST from Wholey@CMU-CS-C.ARPA, , The message of 10 Apr 85 22:33-EST from Moon@STONY-BROOK.SCRC.Symbolics.COM, <850410223354.7.MOON@EUPHRATES.SCRC.Symbolics.COM>, The message of 10 Apr 85 23:51-EST from Wholey@CMU-CS-C.ARPA, , The message of 11 Apr 85 00:35-EST from KMP@STONY-BROOK.SCRC.Symbolics.COM, <850411003554.2.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>, , The message of 11 Apr 85 03:41-EST from Wholey@CMU-CS-C.ARPA, Message-ID: <850416172034.2.DLW@CHICOPEE.SCRC.Symbolics.COM> To summarize this discussion, the desired solution that would satisfy everyone would have the following properties: (1) Package specifications should not use the -*- stuff at all, because there's nothing about -*- in the Common Lisp manual. Not only does this make it easier to port programs, but it's necessary to allow the building of portable programs that understand files of Common Lisp code (e.g. cross referencers). It's OK to have the -*- in ADDITION to the portable forms that specify package setups, but it's purely optional from the point of view of the Common Lisp evaluator and compiler. (Possibly we could back off and have a yellow-pages package that Symbolics provides and other implementations pick up.) (2) The editor needs as much information about packages as the compiler and the loader. All programs that read Lisp forms from files must get the package information from the same place, and work consistently. Furthermore, it is out of the question for you to have to manually evaluate forms out of the buffer before you can edit properly. (3) It should not be required that complex package setups be in their own file, since you want to be able to use packages flexibly even in programs that fit in one file. Use of packages shouldn't force you to have to split your program into many files, with associated pain in copying them, etc, etc. (4) If Symbolics Common Lisp and its editor are to work correctly on ported unmodified Common Lisp source files, it must be prepared to deal with CMU files, which use -*- lines that refer to packages that aren't created until that very file is evaluated. Right now, the CLCP user at CMU gets an error. Strictly speaking, the program is valid Common Lisp, because Common Lisp doesn't ever look inside comments, and so the CLCP is technically in error. As far as I can tell, the only way to meet the first three constraints is to require the editor to parse through the entire file, finding all of the package-related forms such as IMPORT, when the file is read in. It's a bit harder than that, since those forms might be inside of EVAL-WHEN forms. Or COND forms. Or there might be a function defined in the file and later called at top-level that does an IMPORT. Worse yet, the "package environment" might be different at different parts of the file, as various package-related forms are sprinkled among the function definitions. I don't think this is feasible. Zetalisp has basically taken the stance that each file has exactly one "package environment" that's the same throughout the file, and the information that sets up this environment is essentially declarative, rather than imperative. These restrictions have not turned out to be a problem, based on large volumes of sophisticated code turned out over several years. In exchange for them, we get point (2) above. Perhaps it is our disagreement over (2)'s importance that is really at the bottom of this discussion.  Received: from SU-AI.ARPA by MIT-MC.ARPA; 17 APR 85 00:21:08 EST Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 16 Apr 85 15:56:21 PST Received: from SCRC-EUPHRATES by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 215600; Tue 16-Apr-85 18:56:32-EST Date: Tue, 16 Apr 85 18:53 EST From: David A. Moon Subject: Compilation and package system To: Common-lisp@SU-AI.ARPA References: <850416172034.2.DLW@CHICOPEE.SCRC.Symbolics.COM> Message-ID: <850416185341.0.MOON@EUPHRATES.SCRC.Symbolics.COM> Side-comment: I know of three other (besides Symbolics) Lisps that use the -*- convention for file attributes and have representatives on this mailing list. I'm mildly surprised that none of them have spoken up so far.  Received: from SU-AI.ARPA by MIT-MC.ARPA; 17 APR 85 00:08:23 EST Received: from DEC-HUDSON.ARPA by SU-AI.ARPA with TCP; 16 Apr 85 07:40:28 PST Date: Tue, 16 Apr 85 10:40:28 EST From: greek@DEC-HUDSON Subject: Packages and the Compiler To: common-lisp@su-ai Yes, I guess we've exhausted this subject pretty much. I think compiling in one package and loading into another is useful. I always debug a new subsystem, say FORMAT, by working in a temporary FORMAT package and then finally loading the file into SYSTEM and running the tests. Why should I have to recompile it again to do that? Anyway, we basically agree that compiling in one package and loading into another is ill-defined. - Paul  Received: from SU-AI.ARPA by MIT-MC.ARPA; 16 APR 85 23:46:00 EST Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 16 Apr 85 19:21:13 PST Received: ID ; Tue 16 Apr 85 22:20:44-EST Date: Tue, 16 Apr 1985 22:20 EST Message-ID: Sender: FAHLMAN@CMU-CS-C.ARPA From: "Scott E. Fahlman" To: "Daniel L. Weinreb" Cc: Common-lisp@SU-AI.ARPA Subject: Compilation and package system (1)... It's OK to have the -*- in ADDITION to the portable forms that specify package setups, but it's purely optional from the point of view of the Common Lisp evaluator and compiler. Right! I'm not sure what all gets tangled up in the Zetalisp compiler when CLCP is turned on, but maybe something like the following would fly: Use a slightly different notation in the comment line for each of the three cases of interest: A. This is a Zetalisp-style file comment, and the editor can get all that it needs right here in this comment line. B. This is vanilla Common Lisp, but it follows the convention (as in Zetalisp and the vast majority of Spice Lisp code) that the whole file fits into one package environment that is set by in the first few forms in the file. The first time the user asks for some form in the buffer to be read into Lisp or compiled, the system would first execute these opeing forms, stopping when it hits something non-package-related. (Or we could use some explicit marker telling the system when to stop.) In this case, if there is a "Package:Foo" in the -*- line, that is shorthand for "Don't bother reading anything in the file -- all you need to know is that the first statement is a simple (in-package "FOO"). C. This is vanilla Common Lisp with no guarantees about the package structure in the file. If the user actually asks for something in the buffer to be read into Lisp or compiled, the system must first read everything up to that point in order to be sure that the environment is right. The system could query him to see if he wants to go through with this. Note that this is not an extension to Common Lisp, but merely a convention that those implementations with embedded Emacs-like editors might adopt to make code-sharing easier. -- Scott  Received: from SU-AI.ARPA by MIT-MC.ARPA; 15 APR 85 21:51:27 EST Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 15 Apr 85 18:43:33 PST Received: ID ; Mon 15 Apr 85 21:43:39-EST Date: Mon, 15 Apr 1985 21:43 EST Message-ID: Sender: FAHLMAN@CMU-CS-C.ARPA From: "Scott E. Fahlman" To: common-lisp@SU-AI.ARPA Subject: probe-file In-reply-to: Msg of 15 Apr 1985 16:10-EST from Daniel L. Weinreb As I said earlier, it probably is best to handle this on an ad hoc basis until we get an error system defined. We're not going to make much progress as long as some of us view the error system as warm and fuzzy and others of us view it as something to be avoided at all costs. -- Scott  Received: from SU-AI.ARPA by MIT-MC.ARPA; 15 APR 85 20:30:01 EST Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 15 Apr 85 17:18:32 PST Received: from SCRC-CHICOPEE by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 214964; Mon 15-Apr-85 16:55:53-EST Date: Mon, 15 Apr 85 16:55 EST From: Daniel L. Weinreb Subject: PROBE-FILE To: KMP@STONY-BROOK.SCRC.Symbolics.COM, greek@DEC-HUDSON.ARPA, common-lisp@SU-AI.ARPA Message-ID: <850415165553.6.DLW@CHICOPEE.SCRC.Symbolics.COM> Date: Thu, 11 Apr 85 14:26 EST From: Kent M Pitman So, perhaps surprisingly, I'm suggesting that using error signalling may simplify (rather than complicate) the look of code and maybe people with hairy-construct phobias will actually like this... -kmp I agree completely and strongly with Kent's point. In my earlier reply to Masinter, this is what I was trying to get at.  Received: from SU-AI.ARPA by MIT-MC.ARPA; 15 APR 85 20:29:55 EST Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 15 Apr 85 17:17:43 PST Received: from SCRC-CHICOPEE by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 214940; Mon 15-Apr-85 16:10:40-EST Date: Mon, 15 Apr 85 16:10 EST From: Daniel L. Weinreb Subject: probe-file To: masinter.pa@XEROX.ARPA, common-lisp@SU-AI.ARPA In-Reply-To: The message of 11 Apr 85 22:27-EST from masinter.pa@Xerox.ARPA Message-ID: <850415161032.9.DLW@CHICOPEE.SCRC.Symbolics.COM> Date: 11 Apr 85 19:27 PST From: masinter.pa@Xerox.ARPA I understand your point and disagree. We gave this a great deal of thought when we were designing our error system. Note that there is some mutual property of these two functions, in that either is relatively simple to implement in terms of the other, given an error system of the imagined complexity of the Common Lisp error system. Indeed. In Symbolics Common Lisp, probe-file-that-generates-errors is just probe-file, and probe-file-without-errors can be defined as (defun probe-file-without-errors (pathname) (condition-case (error-object) (probe-file pathname) (error (values nil error-object)))) Which would you prefer to have in the "standard" Common Lisp? Both? Which would fit well with "most programs"? Which would "most programmers" naturally chose if they had both available in their library? Given a good error-handler system such as ours, I think the "generates-errors" is the one that should be provided. In my experience, doing it the way you suggest (returning error codes) means that either every function call has to be surrounded by all these forms to receive the value and test it and so on, or else the programmers get lazy, leave that stuff out, and when the error conditions happen the programs plow right along doing all kinds of incorrect things. In our system, if the programmers have something in particular that they'd like to do in the face of errors, they can express these things concisely and clearly, and if they aren't thinking about errors or are just lazy, then unanticipated errors put the program into an interactive debugger before they go off and cause more damage. We've been using this error system for a couple of years and are quite happy with it.  Received: from SU-AI.ARPA by MIT-MC.ARPA; 15 APR 85 20:28:59 EST Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 15 Apr 85 17:18:14 PST Received: from SCRC-CHICOPEE by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 214948; Mon 15-Apr-85 16:24:26-EST Date: Mon, 15 Apr 85 16:24 EST From: Daniel L. Weinreb Subject: Common Lisp should use lexical scoping To: masinter.pa@XEROX.ARPA, Common-Lisp@SU-AI.ARPA Message-ID: <850415162426.1.DLW@CHICOPEE.SCRC.Symbolics.COM> Date: 11 Apr 85 18:42 PST From: masinter.pa@Xerox.ARPA Of course, I'm not talking about the scoping of variables, but rather of packages. The "package" of a piece of code is really a lexical property of the code. The fact that packages are dynamic in extent rather than lexical has led to almost all of the problems in defining what happens to packages and the compiler. Packages aren't dynamic in extent. They have indefinite extent. See Chapter 3. I'm not sure that the analogy to the "lexical versus dynamic" dichotomy is a very good way of looking at this, since nothing in question has dynamic extent. ("Dynamic scope" really means indefinite scope and dynamic extent.) In any case, I'm wondering the same things as Scott. Could you please elaborate on your proposal?  Received: from SU-AI.ARPA by MIT-MC.ARPA; 15 APR 85 20:25:51 EST Received: from SCRC-QUABBIN.ARPA by SU-AI.ARPA with TCP; 15 Apr 85 17:12:52 PST Received: from SCRC-EUPHRATES by SCRC-QUABBIN via CHAOS with CHAOS-MAIL id 153861; Mon 15-Apr-85 17:00:44-EST Date: Mon, 15 Apr 85 16:57 EST From: David A. Moon Subject: A-Packaging we will go... To: greek@DEC-HUDSON.ARPA cc: common-lisp@SU-AI.ARPA In-Reply-To: The message of 12 Apr 85 10:00-EST from greek at DEC-HUDSON Message-ID: <850415165739.8.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Fri, 12 Apr 85 10:00:19 EST From: greek@DEC-HUDSON [My new comments are in square brackets -- Paul.] Well, Mr. Moon, I gave your comment some thought. It was a bit terse, but perhaps this is what you meant: What happens if a macro calls a function during the expansion of a macro call? If that function is in, say, the "USER" package, and the compiler were to make the current package "SPECIAL-COMPILER-PACKAGE- THAT-NO-ONE-ELSE-USES", then indeed the function wouldn't be found at compile time. What if the function was in the LISP package? Does your special compiler package inherit from there or doesn't it? If it doesn't, macros can't run. If it does, you can't tell whether a symbol came from there via package prefix or via inheritance. [Well, as you say, it must inherit from the LISP package. But why do I care whether the compiler can tell that the symbol had a package prefix or inherited the symbol? The fact is that the symbol is in the LISP package, so the fast loader better find it there.] I thought the whole point of your suggestion for a special compiler package was that you cared. But then again, it wouldn't be found if the user didn't happen to be in the "USER" package when compiling the program. If the program must be compiled in the "USER" package, it ought to do an IN-PACKAGE at the top. If I read you wrong, please let me know. By the way, here's what VAX LISP currently does: If the compiler goes to dump a symbol which is in the current package (not any special compiler package), then it dumps it without a package. This means it will be loaded into the current package at the time of loading. In other words, it does the same thing as PRINT. This is what our compiler does, too. [But do we agree that's correct?] I believe that it is inherently the best thing that can be done, if you grant the compiler uses the Lisp READ function as its lexical analyzer. I don't think this is quite right, since it means that if I'm in the "FOO" package when I compile, and I say FOO::SYM, and then I'm in "BAR" when I load it, SYM will end up in "BAR" rather than "FOO". To avoid this problem, I think you need the special compiler package. A better approach is for the compiler to tell the loader what the value of *PACKAGE* was when the file was compiled. If the loader binds *PACKAGE* to the same value (that is, to a package with the same name) when the file is loaded, symbol names in the compiled file will be interpreted as the compiler intended when it dumped them. This approach works well for us. Of course the user can get into arbitrary amounts of trouble by changing package definitions between the time a file is compiled and the time it is loaded, but that is inherently unavoidable. For instance, if the source file referenced FOO::SYM, and SYM was imported or inherited by the source file's package at compile time, but not at load time, then the wrong SYM will be referenced. [I don't see how this solves the problem I described above with the FOO and BAR packages. Seems to me that SYM would end up in the FOO package alright, but so would an unqualified symbol, say SYM2. But SYM2 ought to end up in BAR, the current package at load time. To summarize: source file, compiled when FOO is current package: FOO::SYM1 SYM2 fastload file, loaded when BAR is current package: FOO::SYM1 ; Better end up in FOO. SYM2 ; Better end up in BAR. ] This problem derives entirely from the (doomed) attempt to compile a file in one package and load it into another. You cannot expect reasonable results from this. Hence my suggestion for the loader to ensure that the file is loaded into the correct package. If FOO was not the correct package, why did you compile it in that package? Or, to ask the question another way, why did your compiler compile it in the wrong package? This relates to the other discussion about the file attribute convention (-*-). This piece of mail is getting rather long. I suggest that if we need to discuss this further, we should prune it. I myself don't have anything further to say.  Received: from SU-AI.ARPA by MIT-MC.ARPA; 15 APR 85 20:24:41 EST Received: from SCRC-QUABBIN.ARPA by SU-AI.ARPA with TCP; 15 Apr 85 17:12:26 PST Received: from SCRC-EUPHRATES by SCRC-QUABBIN via CHAOS with CHAOS-MAIL id 153822; Mon 15-Apr-85 15:33:51-EST Date: Mon, 15 Apr 85 15:30 EST From: David A. Moon Subject: Common Lisp should use lexical scoping To: masinter.pa@XEROX.ARPA, Scott E. Fahlman , Steven cc: Common-Lisp@SU-AI.ARPA In-Reply-To: The message of 11 Apr 85 21:42-EST from masinter.pa@Xerox.ARPA, , Message-ID: <850415153047.1.MOON@EUPHRATES.SCRC.Symbolics.COM> The subject of this conversation is rather a misnomer. I believe that what you are really suggesting is that packages should affect the mapping from symbols to named entities (variables, functions, etc.) rather than the mapping from print-names to symbols. That is certainly a reasonable position to take, and some other languages (Scheme, T, Lisp 2) have taken it with varying degrees of success. As I recall, we considered this when designing Common Lisp but decided that the technical risk was too high. One thing to think about is that there are many different mappings from symbols to named entities, some of them implemented by user programs; the "et cetera" in my first paragraph is hiding a multitude of things. Sticking to Common Lisp, there are data types, defstructs, declarations, properties, and keywords. Going outside of Common Lisp brings in such named objects as flavors, messages, editor commands, and any number of user-defined spaces of named objects. Which of these should be affected by packages and which should not? And should the implementation of a mapping by the property list or by some other mechanism be exposed in the semantics of that mapping with respect to packages? T has some reasonable responses to these issues, and I think if Common Lisp were being designed in 1987 we might decide differently after studying languages such as T and how their users use them. But Common Lisp was designed in 1982. We decided to go with the well-understood package philosophy that the Lisp machine had been using since about 1978, substantially redesigned to fix its well-understood bugs without radically changing the whole philosophy. It's hard to achieve perfection in this mortal vale. For additional insight, see the James Madison quotation on the second page of the manual.  Received: from SU-AI.ARPA by MIT-MC.ARPA; 13 APR 85 17:20:16 EST Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 13 Apr 85 14:10:28 PST Received: ID ; Sat 13 Apr 85 17:10:36-EST Date: Sat, 13 Apr 1985 17:10 EST Message-ID: From: Steven To: "Scott E. Fahlman" Cc: common-lisp@SU-AI.ARPA, masinter.pa@XEROX.ARPA Subject: Common Lisp should use lexical scoping In-reply-to: Msg of 12 Apr 1985 22:29-EST from Scott E. Fahlman I think that the reason for this property (that an environment is created once and never altered) is so that you can assign positions in a vector to the variables, for runtime efficiency. If you have an alist, there's no reason why you couldn't create a scheme where you could push things onto it etc. and have it do the right thing. For interning symbols, you could probably afford to do a hairy loadtime search to find where the symbol is, since once you find it, you have this physical object to refer to. The package specification would just look something like a pathname. Of course, I think one of the problems with packages might be that adding a variable FOO to a shadowing packages doesn't shadow an already-loaded symbol. I dunno. -- Steve  Received: from SU-AI.ARPA by MIT-MC.ARPA; 12 APR 85 22:39:10 EST Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 12 Apr 85 19:29:15 PST Received: ID ; Fri 12 Apr 85 22:29:23-EST Date: Fri, 12 Apr 1985 22:29 EST Message-ID: Sender: FAHLMAN@CMU-CS-C.ARPA From: "Scott E. Fahlman" To: masinter.pa@XEROX.ARPA Cc: common-lisp@SU-AI.ARPA Subject: Common Lisp should use lexical scoping In-reply-to: Msg of 12 Apr 1985 19:09-EST from masinter.pa at Xerox.ARPA Larry, Maybe I misunderstand what you mean by "lexical scoping" of packages, since your proposal was not spelled out in detail. But here's what I am worried about: When we're speaking of the scope variables, lexical scoping means that the scope of the variable is one contiguous chunk in the file being read, and once you leave the lexical block you can never again get hold of that variable by using its name (though function closures defined within the block can still get at the variable). You cannot sneak in one more function later that refers to the same X. That's awkward at times, but also an advantage, since the compiler can be sure that after it has reached the end of a block, it knows all about how a lexical variable in that block can be referenced. In lexically scoped packages, presumably this property would be preserved. So you would have to load all of the contents of a package in a single chunk, even if this stuff comes form several files. After you exit the lexical scope of a package, presumably you could never again go back and add a new symbol to it, though I suppose the reader could still refer to existing symbols in that package. (Otherwise, the whole package could just be thrown out after you exit the scope.) That might possible make sense if you are thinking only of reading a bunch of existing files into the Lisp, but when you are developing code that perhaps lives in several packages, you need to be able to bounce back and forth between packages, adding new stuff to each package. I don't see any way to do this without some sort of dynamic scoping of packages. Perhaps I have totally misunderstood your proposal? -- Scott  Received: from SU-AI.ARPA by MIT-MC.ARPA; 12 APR 85 21:45:52 EST Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 12 Apr 85 18:04:51 PST Received: from Semillon.ms by ArpaGateway.ms ; 12 APR 85 18:01:41 PST Date: 12 Apr 85 18:01 PST From: card.pa@Xerox.ARPA Subject: Re: Arg cont checking, optionals, keywords, etc In-reply-to: Jon White 's message of 09 Apr 85 17:22 PST To: JLW@SU-AI.ARPA cc: Card.pa@Xerox.ARPA, bug-1100@SUMEX-AIM.ARPA, common-lisp@SU-AI.ARPA I believe the Common Lisp syntax untimately derives from Muddle. There is of course virtue, if the change were to occur in Interlisp-D, adopting a syntax compatible with Common Lisp. For my taste, however, I would prefer one compatible with Interlisp-D DECL DLAMBDAs as in my earlier examples. This allows (at the option of the programmer) stronger error checking than argument counting alone as well as self-documentation of the variables. Both syntaxes could be available in this case and could compile to the same code. Stu  Received: from SU-AI.ARPA by MIT-MC.ARPA; 12 APR 85 21:16:34 EST Date: 12 Apr 85 1755 PST From: Jon White Subject: Two PROBE-FILE questions To: RAM@CMU-CS-C.ARPA CC: common-lisp@SU-AI.ARPA In-reply-to: your Msg of 10-Apr-85 14:56 EST I think you've elucidated, in the second paragraph, the main difficulty of a non-opening probe-file. True, one of these problems isn't unique to probe-for-output -- that of asynchronous change in th file system by some other process -- but that doesn't lessen the importance. The second one (that I was thinking of) is simply the problem of TRUENAME -- unless you actually open-for-output, then there's a high probability that you can't find exactly th fully-qualified pathname that the file system would have returned. Version numbers is one of the problems; following links may be another; and finaly (for me, at least) there is the confusion as to whether the result of a direction-output call is a "file name" or merely a very hypothetical pathname -- e.g., "this pathname is NOT a file, but if you had called open instead of probe-file, then this would have been the name of the file so opened". Say, Rob, do you get the same sense that I do that something went astray with this discussion? In my note of 9-Apr-85, I thought I was arguing the case for using OPEN directly, rather than preceeding it by a call to PROBE-FILE; this led to the suggestion to continue the development of "signals" *** in order to field the file-not-found error from OPEN *** But it looks like the discussion centered around fielding error signals from probe-file. foo. If I wasn't clear about my bias before, let me state it now; I don't see much use for direction-output for probe-file. Let probe-file remain a simple function, such as DZG wants, with an informational nature, and let us discourage users from imagining it to be some kind of file system semaphore. -- JonL --  Received: from SU-AI.ARPA by MIT-MC.ARPA; 12 APR 85 17:27:11 EST Received: from MIT-MULTICS.ARPA by SU-AI.ARPA with TCP; 12 Apr 85 14:15:56 PST Date: Fri, 12 Apr 85 17:11 EST From: Nick Gall Subject: Re: PROBE-FILE To: common-lisp@SU-AI.ARPA In-Reply-To: Message of 12 Apr 85 10:03 EST from "Scott E. Fahlman" Message-ID: <850412221124.132617@MIT-MULTICS.ARPA> Date: 12 April 1985 10:03 est From: Scott E. Fahlman Subject: PROBE-FILE A problem with your suggestion is that in most of the distributed, heterogenous environments that people are moving to now, there's not a clear separation between syntactic and semantic problems with a namestring. Add a unix system to your search-list, and suddenly the slash character turns from syntactic garbage to an essential part of an address. So I wouldn't want the error/no-error distinction to depend on whether the string was ill-formed or merely happened not to point to a reasonable place in the current environment. - Scott My suggestion is based on the `clear separation' that the CLRM itself makes between an `ill-formed' namestring and a namestring that is well-formed but meaningless. This distinction is explicitly made in the definition of PARSE-NAMESTRING (pg. 414): An error is signalled if the [name]string does not consist entirely of the representation of a pathname. 1. IF one agrees that PARSE-NAMESTRING signals an error when given an ill-formed namestring, but does not signal an error when given a well-formed namestring (regardless of its meaningfulness) 2. AND IF one agrees that any function (call it FOO) that takes a namestring argument implicity calls PARSE-NAMESTRING (perhaps via PATHNAME) to transform the namestring into a pathname 3. AND IF one agrees that any error signalled by the implicit call to PARSE-NAMESTRING is propagated by FOO THEN one should agree that PROBE-FILE must signal an error if (but not necessarily only if) given an ill-formed namestring. My suggestion boils down to making points 2 and 3 EXPLICIT in the CLRM, based on my belief that these two points are already IMPLIED in the CLRM. P.S. I'm not sure I understand the comment about adding a unix system to my search list, but I believe that namestrings are usually parsed `with reference to a particular file name syntax of several avaialable in the implementation' (pg. 414). And the Host component is `used to determine the syntax convention' (pg. 414). Doesn't this take care of the slashes?  Received: from SU-AI.ARPA by MIT-MC.ARPA; 12 APR 85 14:18:12 EST Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 12 Apr 85 11:03:18 PST Received: from SCRC-RIO-DE-JANEIRO by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 214170; Fri 12-Apr-85 13:58:44-EST Date: Fri, 12 Apr 85 13:58 EST From: Kent M Pitman Subject: Probe-file and errors To: dzg@CMU-CS-SPICE.ARPA, common-lisp@SU-AI.ARPA In-Reply-To: <6595.160879383.> Message-ID: <850412135811.0.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> Date: Thu 11 Apr 85 15:41:18-EST From: dzg@CMU-CS-SPICE.ARPA What seems to be impossible, for some reason, is to make simple things simple. ... My code just wants to do (cond ((probe-file "/usr/foo/bar") ...) ((probe-file "/user/may/be") ...) ((probe-file "/yet/another/one") ...) (t ... cannot find it. Bye. ...)) Simple as that. I do not (DO NOT!) want to handle an error... In LispM lisp, you would write: (cond ((ignore-errors (probe-file "/usr/foo/bar")) ...) ...etc) It seems to me that this is not an unreasonable thing and has the advantage of making it nicely explicit that you in fact don't care what happens in the failing cases. IGNORE-ERRORS is not in my error proposal but could be added. -kmp  Received: from SU-AI.ARPA by MIT-MC.ARPA; 12 APR 85 10:15:16 EST Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 12 Apr 85 07:03:54 PST Received: ID ; Fri 12 Apr 85 10:03:47-EST Date: Fri, 12 Apr 1985 10:03 EST Message-ID: Sender: FAHLMAN@CMU-CS-C.ARPA From: "Scott E. Fahlman" To: Nick Gall Cc: common-lisp@SU-AI.ARPA Subject: PROBE-FILE In-reply-to: Msg of 12 Apr 1985 00:21-EST from Nick Gall A problem with your suggestion is that in most of the distributed, heterogenous environments that people are moving to now, there's not a clear separation between syntactic and semantic problems with a namestring. Add a unix system to your search-list, and suddenly the slash character turns from syntactic garbage to an essential part of an address. So I wouldn't want the error/no-error distinction to depend on whether the string was ill-formed or merely happened not to point to a reasonable place in the current environment. - Scott  Received: from SU-AI.ARPA by MIT-MC.ARPA; 12 APR 85 10:13:23 EST Received: from DEC-HUDSON.ARPA by SU-AI.ARPA with TCP; 12 Apr 85 07:00:12 PST Date: Fri, 12 Apr 85 10:00:19 EST From: greek@DEC-HUDSON Subject: A-Packaging we will go... To: common-lisp@su-ai [My new comments are in square brackets -- Paul.] Well, Mr. Moon, I gave your comment some thought. It was a bit terse, but perhaps this is what you meant: What happens if a macro calls a function during the expansion of a macro call? If that function is in, say, the "USER" package, and the compiler were to make the current package "SPECIAL-COMPILER-PACKAGE- THAT-NO-ONE-ELSE-USES", then indeed the function wouldn't be found at compile time. What if the function was in the LISP package? Does your special compiler package inherit from there or doesn't it? If it doesn't, macros can't run. If it does, you can't tell whether a symbol came from there via package prefix or via inheritance. [Well, as you say, it must inherit from the LISP package. But why do I care whether the compiler can tell that the symbol had a package prefix or inherited the symbol? The fact is that the symbol is in the LISP package, so the fast loader better find it there.] But then again, it wouldn't be found if the user didn't happen to be in the "USER" package when compiling the program. If the program must be compiled in the "USER" package, it ought to do an IN-PACKAGE at the top. If I read you wrong, please let me know. By the way, here's what VAX LISP currently does: If the compiler goes to dump a symbol which is in the current package (not any special compiler package), then it dumps it without a package. This means it will be loaded into the current package at the time of loading. In other words, it does the same thing as PRINT. This is what our compiler does, too. [But do we agree that's correct?] I don't think this is quite right, since it means that if I'm in the "FOO" package when I compile, and I say FOO::SYM, and then I'm in "BAR" when I load it, SYM will end up in "BAR" rather than "FOO". To avoid this problem, I think you need the special compiler package. A better approach is for the compiler to tell the loader what the value of *PACKAGE* was when the file was compiled. If the loader binds *PACKAGE* to the same value (that is, to a package with the same name) when the file is loaded, symbol names in the compiled file will be interpreted as the compiler intended when it dumped them. This approach works well for us. Of course the user can get into arbitrary amounts of trouble by changing package definitions between the time a file is compiled and the time it is loaded, but that is inherently unavoidable. For instance, if the source file referenced FOO::SYM, and SYM was imported or inherited by the source file's package at compile time, but not at load time, then the wrong SYM will be referenced. [I don't see how this solves the problem I described above with the FOO and BAR packages. Seems to me that SYM would end up in the FOO package alright, but so would an unqualified symbol, say SYM2. But SYM2 ought to end up in BAR, the current package at load time. To summarize: source file, compiled when FOO is current package: FOO::SYM1 SYM2 fastload file, loaded when BAR is current package: FOO::SYM1 ; Better end up in FOO. SYM2 ; Better end up in BAR. ]  Received: from SU-AI.ARPA by MIT-MC.ARPA; 12 APR 85 00:52:51 EST Received: from MIT-MULTICS.ARPA by SU-AI.ARPA with TCP; 11 Apr 85 21:39:17 PST Posted-Date: 12 Apr 85 00:23 EST Date: Fri, 12 Apr 85 00:21 EST From: Nick Gall Subject: Re: PROBE-FILE To: common-lisp@SU-AI.ARPA In-Reply-To: Message of 11 Apr 85 14:55 EST from "Scott E. Fahlman" Message-ID: <850412052150.000502@MIT-MULTICS.ARPA> Date: 11 April 1985 14:55 est From: Scott E. Fahlman Subject: PROBE-FILE I've avoided stepping into this particular discussion (and probably will regret doing so now) but it looks to me like it might be time to try to close the issue, for now at least. Let me toss out the following suggestions to see if they are acceptable to everyone: 1. It is allowable for a Common Lisp system to signal an error on probef if the file name is malformed in some way, or if the file is not found for other than the usual reasons. 2. Implementations that don't want to handle this with an error, perhaps because they lack an error-handling system of sufficient power, can for now do something compatible but non-portable about this, such as taking a special keyword or returning an extra value describing what went wrong. 3. We should try again for a clean, fully portable solution to this problem after we have reached some consensus on a standard signal/error-handling system. At that point, we'll be able to see much more clearly whether this is a good way to deal with this sort of situation. -- Scott I think the signalling of an error in the case of a namestring that is syntactically illegal is an entirely separate issue that applies to most of the file system interface function. Many functions besides PROBE-FILE can take a namestring as an argument (e.g., PATHNAME, OPEN, RENAME-FILE,DELETE-FILE). Nowhere does the CLRM define what occurs if one of these functions is given a syntactically illegal namestring. Only PARSE-NAMESTRING is explicitly defined to signal an error "if the [name]string does not consist entirely of the representation of a pathname." My suggestions are as follows: 1. The function PATHNAME be defined to signal an error if given a syntactically illegal namestring. 2. The parameter names FILE, FILENAME, and THING be flushed and replaced with PATHNAME. 3. Explicity state that all functions that take a PATHNAME argument implicity apply the function PATHNAME to the argument. This would mean that PROBE-FILE WOULD signal an error if given a syntactically illegal namestring. Otherwise, if PROBE-FILE is given a legal namestring, it should NOT signal an error if the pathname is SEMANTICALLY illegal (e.g., non-existent dir.), I assumed this is what TRUENAME was for. (If this is not the case, what IS the dif. between PROBE-FILE and TRUENAME).  Received: from SU-AI.ARPA by MIT-MC.ARPA; 12 APR 85 00:35:19 EST Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 11 Apr 85 21:27:22 PST Received: from Semillon.ms by ArpaGateway.ms ; 11 APR 85 21:24:34 PST Date: 11 Apr 85 21:24 PST From: masinter.pa@Xerox.ARPA Subject: Re: PROBE-FILE In-reply-to: various messages To: common-lisp@SU-AI.ARPA I missed some of the mail on probe-file before firing off my suggestion. I think deferring discussion until after resolution of some of the error system questions sounds reasonable.  Received: from SU-AI.ARPA by MIT-MC.ARPA; 11 APR 85 22:56:29 EST Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 11 Apr 85 19:27:46 PST Received: from Semillon.ms by ArpaGateway.ms ; 11 APR 85 19:27:54 PST Date: 11 Apr 85 19:27 PST From: masinter.pa@Xerox.ARPA Subject: probe-file To: common-lisp@su-ai.ARPA Probe-file is useful but necessarily heuristic, even for output mode. (The Interlisp equivalent is called OUTFILEP, and hasn't been flushed.) Let us suppose a that we had probe-file-that-generates-errors. This is the one that does the probe-file, but generates errors if the file name has illegal syntax, the server is down, etc. Lets suppose for a moment that the error string in the error is always (kind of error: additional information), e.g. "file server not responding: name-of-server". Let me define a new function probe-file-without-errors, defined to return the value of probe-file-that-generates-errors if the latter returns non-NIL without errors, or else NIL and an optional second argument, which is the "error code". Lets say that the error code is a list of strings. Note that there is some mutual property of these two functions, in that either is relatively simple to implement in terms of the other, given an error system of the imagined complexity of the Common Lisp error system. Which would you prefer to have in the "standard" Common Lisp? Both? Which would fit well with "most programs"? Which would "most programmers" naturally chose if they had both available in their library? Given that probe-file is, on any machine except stand-alone single-process systems, a heuristic at best, I'd claim that probe-file-without-errors is more useful. I would claim that "can't tell" is also a reasonable "error" code, and that it would be legitimate (but not particularly useful) for an implementation to always return NIL to probe-file, with "can't tell" as the reason.  Received: from SU-AI.ARPA by MIT-MC.ARPA; 11 APR 85 22:46:43 EST Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 11 Apr 85 19:37:40 PST Received: ID ; Thu 11 Apr 85 22:37:47-EST Date: Thu, 11 Apr 1985 22:37 EST Message-ID: Sender: FAHLMAN@CMU-CS-C.ARPA From: "Scott E. Fahlman" To: masinter.pa@XEROX.ARPA Cc: Common-Lisp@SU-AI.ARPA Subject: Common Lisp should use lexical scoping In-reply-to: Msg of 11 Apr 1985 21:42-EST from masinter.pa at Xerox.ARPA Interesting suggestion if packages are used only for loading chunks of already-developed code, but it's not clear to me that lexically scoped packages would work out for interactive program development, where you sometimes need to bop back and forth from one package environment to another, adding code incrementally. -- Scott  Received: from SU-AI.ARPA by MIT-MC.ARPA; 11 APR 85 22:02:26 EST Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 11 Apr 85 18:46:35 PST Received: from Semillon.ms by ArpaGateway.ms ; 11 APR 85 18:42:42 PST Date: 11 Apr 85 18:42 PST From: masinter.pa@Xerox.ARPA Subject: Common Lisp should use lexical scoping To: Common-Lisp@SU-AI.ARPA I think Common Lisp should use lexical scoping and not dynamic scoping. Dynamic scoping is the cause of some subtle incompatibilities between compiled and interpreted code. Of course, I'm not talking about the scoping of variables, but rather of packages. The "package" of a piece of code is really a lexical property of the code. The fact that packages are dynamic in extent rather than lexical has led to almost all of the problems in defining what happens to packages and the compiler. I believe that lexical scoping for packages would require some extra syntax. I'm not sure I'm up for proposing what that syntax should be, but I'd guess that some kind of reader macro(s) would be appropriate replacements for the Extremely Random User Interface Commands. (Imagine "#;;;-*- Package:" as a reader macro.) It would then be reasonable to expect the compiler to preserve the lexical scoping of packages, but the mechanism can now be part of the implementation. It would remove the odd restrictions on the compiler mechanisms (as suggested by the implementation note in CLTL p 182) and much of the necessity for having some of the more arcane features of the Packages chapter.  Received: from SU-AI.ARPA by MIT-MC.ARPA; 11 APR 85 20:13:43 EST Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 11 Apr 85 17:02:21 PST Received: from SCRC-EUPHRATES by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 213672; Thu 11-Apr-85 20:01:29-EST Date: Thu, 11 Apr 85 20:02 EST From: David A. Moon Subject: The compiler and packages. To: greek@DEC-HUDSON.ARPA cc: common-lisp@SU-AI.ARPA In-Reply-To: The message of 11 Apr 85 15:35-EST from greek at DEC-HUDSON Message-ID: <850411200255.5.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Thu, 11 Apr 85 15:35:16 EST From: greek@DEC-HUDSON Well, Mr. Moon, I gave your comment some thought. It was a bit terse, but perhaps this is what you meant: What happens if a macro calls a function during the expansion of a macro call? If that function is in, say, the "USER" package, and the compiler were to make the current package "SPECIAL-COMPILER-PACKAGE- THAT-NO-ONE-ELSE-USES", then indeed the function wouldn't be found at compile time. What if the function was in the LISP package? Does your special compiler package inherit from there or doesn't it? If it doesn't, macros can't run. If it does, you can't tell whether a symbol came from there via package prefix or via inheritance. But then again, it wouldn't be found if the user didn't happen to be in the "USER" package when compiling the program. If the program must be compiled in the "USER" package, it ought to do an IN-PACKAGE at the top. If I read you wrong, please let me know. By the way, here's what VAX LISP currently does: If the compiler goes to dump a symbol which is in the current package (not any special compiler package), then it dumps it without a package. This means it will be loaded into the current package at the time of loading. In other words, it does the same thing as PRINT. This is what our compiler does, too. I don't think this is quite right, since it means that if I'm in the "FOO" package when I compile, and I say FOO::SYM, and then I'm in "BAR" when I load it, SYM will end up in "BAR" rather than "FOO". To avoid this problem, I think you need the special compiler package. A better approach is for the compiler to tell the loader what the value of *PACKAGE* was when the file was compiled. If the loader binds *PACKAGE* to the same value (that is, to a package with the same name) when the file is loaded, symbol names in the compiled file will be interpreted as the compiler intended when it dumped them. This approach works well for us. Of course the user can get into arbitrary amounts of trouble by changing package definitions between the time a file is compiled and the time it is loaded, but that is inherently unavoidable. For instance, if the source file referenced FOO::SYM, and SYM was imported or inherited by the source file's package at compile time, but not at load time, then the wrong SYM will be referenced.  Received: from SU-AI.ARPA by MIT-MC.ARPA; 11 APR 85 19:20:33 EST Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 11 Apr 85 16:11:36 PST Received: from SCRC-EUPHRATES by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 213650; Thu 11-Apr-85 19:07:53-EST Date: Thu, 11 Apr 85 19:09 EST From: David A. Moon Subject: PROBE-FILE To: Scott E. Fahlman cc: common-lisp@SU-AI.ARPA In-Reply-To: Message-ID: <850411190901.3.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Thu, 11 Apr 1985 14:55 EST From: "Scott E. Fahlman" ....Let me toss out the following suggestions to see if they are acceptable to everyone.... Fine with me.  Received: from SU-AI.ARPA by MIT-MC.ARPA; 11 APR 85 16:13:42 EST Received: from CMU-CS-SPICE.ARPA by SU-AI.ARPA with TCP; 11 Apr 85 13:01:41 PST Apparently-From: dzg@CMU-CS-SPICE Date: Thu 11 Apr 85 15:41:18-EST From: dzg@CMU-CS-SPICE.ARPA To: common-lisp@SU-AI.ARPA Subject: Probe-file and errors Message-ID: <6595.160879383.> What seems to be impossible, for some reason, is to make simple things simple. Here is the original application I had in mind: - I need to find a dictionary file that is the key to everything else. Access is to a remote machine of unspecified nature. - Depending on the remote file system, the dictionary file may be under different paths (e.g. /usr/xxx for a Unix machine, and so on). - There are only two or three possible remote paths, one per machine, maybe. - My code just wants to do (cond ((probe-file "/usr/foo/bar") ...) ((probe-file "/user/may/be") ...) ((probe-file "/yet/another/one") ...) (t ... cannot find it. Bye. ...)) Simple as that. I do not (DO NOT!) want to handle an error. This is the simplest possible thing I can ask of a file system. Do you have it or not? I couldn't care less that the pathname is malformed because Unix directories must sit under /usr/. I just want to see whether the file is there. I understand there may be serious cases when one wants to "stop dead in the tracks". I am willing to believe one really cares to find out why the file system thinks there is no such file because the color of the third bit in the filename is not blue. But I do want to have a simple call. I have seen many systems that use exception handling as a way of passing arguments, and they are NOT the clearest systems I have seen. - Dario -  Received: from SU-AI.ARPA by MIT-MC.ARPA; 11 APR 85 15:47:23 EST Received: from DEC-HUDSON.ARPA by SU-AI.ARPA with TCP; 11 Apr 85 12:35:10 PST Date: Thu, 11 Apr 85 15:35:16 EST From: greek@DEC-HUDSON Subject: The compiler and packages. To: common-lisp@su-ai Well, Mr. Moon, I gave your comment some thought. It was a bit terse, but perhaps this is what you meant: What happens if a macro calls a function during the expansion of a macro call? If that function is in, say, the "USER" package, and the compiler were to make the current package "SPECIAL-COMPILER-PACKAGE- THAT-NO-ONE-ELSE-USES", then indeed the function wouldn't be found at compile time. But then again, it wouldn't be found if the user didn't happen to be in the "USER" package when compiling the program. If the program must be compiled in the "USER" package, it ought to do an IN-PACKAGE at the top. If I read you wrong, please let me know. By the way, here's what VAX LISP currently does: If the compiler goes to dump a symbol which is in the current package (not any special compiler package), then it dumps it without a package. This means it will be loaded into the current package at the time of loading. I don't think this is quite right, since it means that if I'm in the "FOO" package when I compile, and I say FOO::SYM, and then I'm in "BAR" when I load it, SYM will end up in "BAR" rather than "FOO". To avoid this problem, I think you need the special compiler package. - Paul  Received: from SU-AI.ARPA by MIT-MC.ARPA; 11 APR 85 15:45:51 EST Received: from DEC-HUDSON.ARPA by SU-AI.ARPA with TCP; 11 Apr 85 12:37:08 PST Date: Thu, 11 Apr 85 15:37:13 EST From: greek@DEC-HUDSON Subject: PROBE-FILE To: common-lisp@su-ai That's not to say that I like handling errors with a signaling facility, but I guess I'm willing to change... - Paul  Received: from SU-AI.ARPA by MIT-MC.ARPA; 11 APR 85 15:35:30 EST Received: from DEC-HUDSON.ARPA by SU-AI.ARPA with TCP; 11 Apr 85 12:27:39 PST Date: Thu, 11 Apr 85 15:27:49 EST From: greek@DEC-HUDSON Subject: PROBE-FILE To: common-lisp@su-ai Scott's suggestion seems reasonable to me. We should avoid getting bogged down in specific error-handling problems until we think about a general signaling mechanism. - Paul  Received: from SU-AI.ARPA by MIT-MC.ARPA; 11 APR 85 15:10:16 EST Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 11 Apr 85 11:56:14 PST Received: ID ; Thu 11 Apr 85 14:56:03-EST Date: Thu, 11 Apr 1985 14:55 EST Message-ID: Sender: FAHLMAN@CMU-CS-C.ARPA From: "Scott E. Fahlman" To: common-lisp@SU-AI.ARPA Subject: PROBE-FILE In-reply-to: Msg of 11 Apr 1985 14:26-EST from Kent M Pitman I've avoided stepping into this particular discussion (and probably will regret doing so now) but it looks to me like it might be time to try to close the issue, for now at least. Let me toss out the following suggestions to see if they are acceptable to everyone: 1. It is allowable for a Common Lisp system to signal an error on probef if the file name is malformed in some way, or if the file is not found for other than the usual reasons. 2. Implementations that don't want to handle this with an error, perhaps because they lack an error-handling system of sufficient power, can for now do something compatible but non-portable about this, such as taking a special keyword or returning an extra value describing what went wrong. 3. We should try again for a clean, fully portable solution to this problem after we have reached some consensus on a standard signal/error-handling system. At that point, we'll be able to see much more clearly whether this is a good way to deal with this sort of situation. -- Scott  Received: from SU-AI.ARPA by MIT-MC.ARPA; 11 APR 85 14:48:55 EST Received: from SCRC-YUKON.ARPA by SU-AI.ARPA with TCP; 11 Apr 85 11:28:00 PST Received: from SCRC-RIO-DE-JANEIRO by SCRC-YUKON via CHAOS with CHAOS-MAIL id 118912; Thu 11-Apr-85 14:28:52-EST Date: Thu, 11 Apr 85 14:26 EST From: Kent M Pitman Subject: PROBE-FILE To: greek@DEC-HUDSON.ARPA, common-lisp@SU-AI.ARPA In-Reply-To: The message of 11 Apr 85 09:07-EST from greek at DEC-HUDSON Message-ID: <850411142639.8.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> Date: Thu, 11 Apr 85 09:07:38 EST From: greek@DEC-HUDSON ... I agree with Kent that there is no pleasant way of returning all the possible errors from PROBE-FILE, and that some kind of objecty signalling facility is probably the right way to go. However, I just really have a problem with handling "normal" errors using an error system. I can barely keep from gagging when I have to wrap an UNWIND-PROTECT around something every six months or so. To have to wrap various signal-handling forms all over the place... Well, in fact one of the "nice" things about this is that because you know you'll get thrown into the error handler if something funny happens, you can sometimes write your code without the error handling and add it lazily if it's ever needed. In dialects where PROBEF can fail due to other than file-not-found, you may have the problem that the program will "finish" but not correctly. At least if an error is not signalled, you know things worked correctly. For many applications, this means writing (COND ((NOT (PROBEF ...)) ;File is not found ...) (T ;File is found ...)) where formerly (with a PROBEF that refuses to err) you might really have been forced into doing something like: (COND ((NOT (PROBEF ...)) ;Hmmm... File is either not found ;or not available or not correctly named or ... (COND (...hair to figure out what to do if name was bad...) (...hair to figure out what to do if not accessible... machine down? drive offline? file write opened in append mode by someone else and therefore locked? no more of some needed system resource? ...) (T ...the only part i really cared about...))) (T ;File is found ...)) in order to be able to get to sleep at night with a clean conscience. I guess what I'm saying is that in Maclisp, I've always considered programmers irresponsible if they wrote "simplified" code that didn't handle the hairy cases because they were just setting up to cause lossage when someone ran their program in unusual circumstances. On the other, Lisp Machine Lisp programmers that don't write code to handle the hairy cases are often being sensible. They can have some sense of confidence that if an unusual situation arises, the program will stop dead in its tracks instead of producing bad data. Given the choice between a buggy program that enters the error handler and a buggy program which just continues to run blindly, I nearly always prefer the former. So, perhaps surprisingly, I'm suggesting that using error signalling may simplify (rather than complicate) the look of code and maybe people with hairy-construct phobias will actually like this... -kmp  Received: from SU-AI.ARPA by MIT-MC.ARPA; 11 APR 85 14:15:46 EST Received: from USC-ISI.ARPA by SU-AI.ARPA with TCP; 11 Apr 85 11:02:13 PST Date: 11 Apr 1985 14:01-EST Sender: OLDMAN@USC-ISI.ARPA Subject: Data General Common LISP From: OLDMAN@USC-ISI.ARPA To: Common-Lisp@SU-AI.ARPA Message-ID: <[USC-ISI.ARPA]11-Apr-85 14:01:51.OLDMAN> DG has recently released Common LISP running on its 32 bit family of machines. A brief summary of the implementation and a list of benchmark timings is available on USC-ISI in: ps:dg-common-lisp -- Dan Oldman  Received: from SU-AI.ARPA by MIT-MC.ARPA; 11 APR 85 14:08:06 EST Received: from SCRC-QUABBIN.ARPA by SU-AI.ARPA with TCP; 11 Apr 85 10:52:26 PST Received: from SCRC-EUPHRATES by SCRC-QUABBIN via CHAOS with CHAOS-MAIL id 152716; Thu 11-Apr-85 13:38:26-EST Date: Thu, 11 Apr 85 13:38 EST From: David A. Moon Subject: A comment on packages (at the risk of being a fool) To: greek@DEC-HUDSON.ARPA cc: common-lisp@SU-AI.ARPA In-Reply-To: The message of 11 Apr 85 09:11-EST from greek at DEC-HUDSON Message-ID: <850411133853.5.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Thu, 11 Apr 85 09:11:31 EST From: greek@DEC-HUDSON We've had lots of discussion on the differences being interpreting and compiling when using symbols without package prefixes. I believe the rule with the slow loader is that an unqualified symbol is loaded into the current package, which may or may not have been established with an IN-PACKAGE at the top of the file. Why doesn't the compiler simply do the same thing? Namely, it sets the current package to "SPECIAL-COMPILER-PACKAGE-NO-ONE- ELSE-CAN-USE". Then it read/compiles the file and arranges that any symbols in that special package will be fast loaded into what is then the current package. If the user has an IN-PACKAGE at the top of the file, then no symbols will end up in that special package -- fine. Am I missing something? Think about executing, at compile time, the bodies of macros defined in the file.  Received: from SU-AI.ARPA by MIT-MC.ARPA; 11 APR 85 09:56:48 EST Received: from DEC-HUDSON.ARPA by SU-AI.ARPA with TCP; 11 Apr 85 06:49:00 PST Date: Thu, 11 Apr 85 09:11:31 EST From: greek@DEC-HUDSON Subject: A comment on packages (at the risk of being a fool) To: common-lisp@su-ai We've had lots of discussion on the differences being interpreting and compiling when using symbols without package prefixes. I believe the rule with the slow loader is that an unqualified symbol is loaded into the current package, which may or may not have been established with an IN-PACKAGE at the top of the file. Why doesn't the compiler simply do the same thing? Namely, it sets the current package to "SPECIAL-COMPILER-PACKAGE-NO-ONE- ELSE-CAN-USE". Then it read/compiles the file and arranges that any symbols in that special package will be fast loaded into what is then the current package. If the user has an IN-PACKAGE at the top of the file, then no symbols will end up in that special package -- fine. Am I missing something? - Paul  Received: from SU-AI.ARPA by MIT-MC.ARPA; 11 APR 85 09:14:22 EST Received: from DEC-HUDSON.ARPA by SU-AI.ARPA with TCP; 11 Apr 85 06:07:30 PST Date: Thu, 11 Apr 85 09:07:38 EST From: greek@DEC-HUDSON Subject: PROBE-FILE To: common-lisp@su-ai At the risk of continuing a well-beaten subject: I agree with Kent that there is no pleasant way of returning all the possible errors from PROBE-FILE, and that some kind of objecty signalling facility is probably the right way to go. However, I just really have a problem with handling "normal" errors using an error system. I can barely keep from gagging when I have to wrap an UNWIND-PROTECT around something every six months or so. To have to wrap various signal-handling forms all over the place... - Paul  Received: from SU-AI.ARPA by MIT-MC.ARPA; 11 APR 85 03:52:43 EST Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 11 Apr 85 00:41:22 PST Received: ID ; Thu 11 Apr 85 03:41:09-EST Date: Thu, 11 Apr 1985 03:41 EST Message-ID: Sender: WHOLEY@CMU-CS-C.ARPA From: Skef Wholey To: Kent M Pitman Cc: Common-lisp@SU-AI.ARPA, Moon@SCRC-STONY-BROOK.ARPA Subject: Compilation and package system In-reply-to: Msg of 11 Apr 1985 00:35-EST from Kent M Pitman Date: Thursday, 11 April 1985 00:35-EST From: Kent M Pitman Don't be silly. Common Lisp programs don't have to run gracefully in all implementations, they just have to run. If a person has written -*- ... -*- and not put (IN-PACKAGE ...), he has not written a common lisp program. Right. That was what I said in the last paragraph in my original message on this topic. The Lisp Machine simply (and reasonably) suggests that in order to work compatibly with non-Common-Lisp utilities and still be portable, you should do -*- ... -*- and (IN-PACKAGE ...), redundantly. Right. That's the way Spice Lisp works, too, more or less, as I've explained. The difference in the two implementations comes up in only one case, but a very common one. If, in CLCP, I load or compile a file with a -*- comment that puts it in package FOO, and package FOO does not exist, then I get an error. Every time this has happened to me, it has been the case that the first form of FOO would have created the package. Of course, for this sort of thing I usually just write:there's the alternate syntax: ;;; -*- Package: ("HACK" :USE ("LISP" "ACCINT" "SAPPH" "SESAME")) -*- which seems to work OK... What about IMPORT and friends? Those matter, too. Putting it in a comment is mostly likely to win in all languages since nearly every language has a comment syntax and I know of no languages for which the comment syntax is not compatible with -*- ... -*-. The example I gave above, with the FOO package, leads to a situation where the Lisp Machine signals an error when handed a valid program. That would suggest that Common Lisp is a language which is not compatible with -*- comments, as interpreted the Lisp Machine way. If you think this is nitpicking, fine: we'll drop it. I doubt many man-years will be lost fixing headers while porting between Common Lisp dialects. The problem has annoyed at least one Common Lisp programmer, however. --Skef  Received: from SU-AI.ARPA by MIT-MC.ARPA; 11 APR 85 00:49:23 EST Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 10 Apr 85 21:37:00 PST Received: from SCRC-RIO-DE-JANEIRO by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 212797; Thu 11-Apr-85 00:37:00-EST Date: Thu, 11 Apr 85 00:35 EST From: Kent M Pitman Subject: Compilation and package system To: Wholey@CMU-CS-C.ARPA, Moon@SCRC-STONY-BROOK.ARPA cc: Common-lisp@SU-AI.ARPA In-Reply-To: Message-ID: <850411003554.2.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> Date: Wed, 10 Apr 1985 23:51 EST Message-ID: Sender: WHOLEY@CMU-CS-C.ARPA From: Skef Wholey To: "David A. Moon" Cc: Common-lisp@SU-AI.ARPA Subject: Compilation and package system Date: Wednesday, 10 April 1985 22:33-EST From: David A. Moon Date: Tue, 9 Apr 1985 22:14 EST From: Skef Wholey First of all, it [the -*- comment convention] is not portable. I guess it's a matter of viewpoint which way is non-portable, depending on which way you're trying to port. But let's not get into that. Let's get into that for just one paragraph. Nothing in CLTL says anything about -*- comments. Files with those comments will have the effect that you (Dave Moon) expect them to in only one Common Lisp implementation: the Symbolics CLCP. The implementations done by DEC, DG, Rutgers, Kyoto University, and CMU will not understand them. I realize that (by itself) this kind of survey is a bad way to decide language design issues, but the reason that those implementations do not hack -*- the Lisp Machine way is that there's nothing in the spec that says they should. Don't be silly. Common Lisp programs don't have to run gracefully in all implementations, they just have to run. If a person has written -*- ... -*- and not put (IN-PACKAGE ...), he has not written a common lisp program. But that doesn't mean the Lisp Machine doesn't support IN-PACKAGE. If a person has put (IN-PACKAGE ...) but no -*- ... -*- that means his program will run in the way Common Lisp says it will, but that doesn't mean it will interface gracefully to parts of the system not specified by Common Lisp. The Lisp Machine simply (and reasonably) suggests that in order to work compatibly with non-Common-Lisp utilities and still be portable, you should do -*- ... -*- and (IN-PACKAGE ...), redundantly. In fact, I suspect that users will be content to use simply -*- ... -*- and add (IN-PACKAGE ...) only when they get around to actually shipping files but that shouldn't matter. We believe that complex package setups should go in their own files. I have two programs that I've run on both Perqs and 3600's. One is a Common Lisp version of OPS-5, and another is the Spice Lisp microcode assembler. Each are contained in exactly one file, and are thus easy to move from system to system. Why should I need to double the number of files in such systems? For us, "complex package setups" are a way of life, because we've chosen to put the code for communicating with each OS server in its own file. When I sit down to write a graphics hack, I begin a file with ;;; -*- Package: Hack -*- (in-package "HACK" :use '("LISP" "ACCINT" "SAPPH" "SESAME")). I suppose our differences may stem from the fact that we Spice Lispers don't think that packages are very expensive. Packages can be used for little hacks as well as big systems. In the former case, one shouldn't need to stash this information in a separate file that then must be loaded by hand (or in my init file (or by some hook I frob in my init file)). Of course, for this sort of thing I usually just write:there's the alternate syntax: ;;; -*- Package: ("HACK" :USE ("LISP" "ACCINT" "SAPPH" "SESAME")) -*- which seems to work OK... The editor knows which package to associate with a buffer created when visiting this file, but the compiler and loader and everyone else just read Lisp forms, the way Father Lisp wanted them to. This all sounds at first like it makes a lot of sense, but wait a minute. I fail to see how the editor needs any less information about packages than the compiler and the loader. How does the editor know the names of the functions in the file if it doesn't know what package they are relative to? I guess I was being unclear. The editor interprets -*- comments, and associates a package with the buffer the file was read into. This package is made the default package (i.e. *package* is bound to it) whenever the editor parses code in the file (e.g. for incremental compilation) or the echo area (e.g. when asked to list the argument names of a given function). If the package does not exist, then the user is asked if it should be created. If that package uses packages other than LISP, then the user must evaluate the In-Package or Use-Package or Import or whatever himself before counting on the editor to parse code correctly. This last step could be automated, but we haven't done it. In our system all programs that read Lisp forms from files get the package information from the same place and they all work consistently. Ah, but all those programs have to do some magic thing (not part of the Common Lisp language) to interpret the stuff between -*-'s in the first line of the file. Should a user be able to write a portable slow-loader (that just reads forms from a given file) or not? I think he should. People should be able to write things like program cross-referencers in Common Lisp. Portable Common Lisp (whatever that means). Don't forget the Lisp Machine uses -*- ... -*- for other languages besides lisp. (IN-PACKAGE ...) would not work at the top of files in other languages besides lisp and we don't have hands in design groups for every existing language so cannot always get those languages to add a syntax for specifying the package. Putting it in a comment is mostly likely to win in all languages since nearly every language has a comment syntax and I know of no languages for which the comment syntax is not compatible with -*- ... -*-. IN-PACKAGE was put into Common Lisp over my dead body. The rumors of your death have been greatly exaggerated. It might be worth some effort to standardize the semantics of -*-. How about this: Symbolics could provide a portable -*- comment hacking package. This would be made part of the yellow pages, and all implementations could "voluntarily" adopt it as a thing that gets called by Load, Compile-File, etc. This might then be adopted in Common Lisp Mark II (it's really no worse than FORMAT, I guess). I'm still personally biased against this idea (I really do believe that a slow-loader should just read forms out of a file), but portable code would make the Lisp Machine convention a lot easier to swallow. On the other hand, we could decide that -*-'s don't port, and warn users about differences from system to system. Rob MacLachlan has suggested a very sinister solution to the problem: conditionalized constructs in -*- coments... -*- #+LISPM{Syntax: Common-Lisp; Uppercase: Mostly;} Package: Zippy -*- --Skef  Received: from SU-AI.ARPA by MIT-MC.ARPA; 11 APR 85 00:03:40 EST Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 10 Apr 85 20:51:22 PST Received: ID ; Wed 10 Apr 85 23:51:08-EST Date: Wed, 10 Apr 1985 23:51 EST Message-ID: Sender: WHOLEY@CMU-CS-C.ARPA From: Skef Wholey To: "David A. Moon" Cc: Common-lisp@SU-AI.ARPA Subject: Compilation and package system Date: Wednesday, 10 April 1985 22:33-EST From: David A. Moon Date: Tue, 9 Apr 1985 22:14 EST From: Skef Wholey First of all, it [the -*- comment convention] is not portable. I guess it's a matter of viewpoint which way is non-portable, depending on which way you're trying to port. But let's not get into that. Let's get into that for just one paragraph. Nothing in CLTL says anything about -*- comments. Files with those comments will have the effect that you (Dave Moon) expect them to in only one Common Lisp implementation: the Symbolics CLCP. The implementations done by DEC, DG, Rutgers, Kyoto University, and CMU will not understand them. I realize that (by itself) this kind of survey is a bad way to decide language design issues, but the reason that those implementations do not hack -*- the Lisp Machine way is that there's nothing in the spec that says they should. We believe that complex package setups should go in their own files. I have two programs that I've run on both Perqs and 3600's. One is a Common Lisp version of OPS-5, and another is the Spice Lisp microcode assembler. Each are contained in exactly one file, and are thus easy to move from system to system. Why should I need to double the number of files in such systems? For us, "complex package setups" are a way of life, because we've chosen to put the code for communicating with each OS server in its own file. When I sit down to write a graphics hack, I begin a file with ;;; -*- Package: Hack -*- (in-package "HACK" :use '("LISP" "ACCINT" "SAPPH" "SESAME")). I suppose our differences may stem from the fact that we Spice Lispers don't think that packages are very expensive. Packages can be used for little hacks as well as big systems. In the former case, one shouldn't need to stash this information in a separate file that then must be loaded by hand (or in my init file (or by some hook I frob in my init file)). The editor knows which package to associate with a buffer created when visiting this file, but the compiler and loader and everyone else just read Lisp forms, the way Father Lisp wanted them to. This all sounds at first like it makes a lot of sense, but wait a minute. I fail to see how the editor needs any less information about packages than the compiler and the loader. How does the editor know the names of the functions in the file if it doesn't know what package they are relative to? I guess I was being unclear. The editor interprets -*- comments, and associates a package with the buffer the file was read into. This package is made the default package (i.e. *package* is bound to it) whenever the editor parses code in the file (e.g. for incremental compilation) or the echo area (e.g. when asked to list the argument names of a given function). If the package does not exist, then the user is asked if it should be created. If that package uses packages other than LISP, then the user must evaluate the In-Package or Use-Package or Import or whatever himself before counting on the editor to parse code correctly. This last step could be automated, but we haven't done it. In our system all programs that read Lisp forms from files get the package information from the same place and they all work consistently. Ah, but all those programs have to do some magic thing (not part of the Common Lisp language) to interpret the stuff between -*-'s in the first line of the file. Should a user be able to write a portable slow-loader (that just reads forms from a given file) or not? I think he should. People should be able to write things like program cross-referencers in Common Lisp. Portable Common Lisp (whatever that means). IN-PACKAGE was put into Common Lisp over my dead body. The rumors of your death have been greatly exaggerated. It might be worth some effort to standardize the semantics of -*-. How about this: Symbolics could provide a portable -*- comment hacking package. This would be made part of the yellow pages, and all implementations could "voluntarily" adopt it as a thing that gets called by Load, Compile-File, etc. This might then be adopted in Common Lisp Mark II (it's really no worse than FORMAT, I guess). I'm still personally biased against this idea (I really do believe that a slow-loader should just read forms out of a file), but portable code would make the Lisp Machine convention a lot easier to swallow. On the other hand, we could decide that -*-'s don't port, and warn users about differences from system to system. Rob MacLachlan has suggested a very sinister solution to the problem: conditionalized constructs in -*- coments... -*- #+LISPM{Syntax: Common-Lisp; Uppercase: Mostly;} Package: Zippy -*- --Skef  Received: from SU-AI.ARPA by MIT-MC.ARPA; 10 APR 85 23:48:25 EST Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 10 Apr 85 12:22:39 PST Received: ID ; Wed 10 Apr 85 15:16:32-EST Date: Wed, 10 Apr 1985 15:16 EST Message-ID: From: Rob MacLachlan To: perdue%hplabs.csnet@CSNET-RELAY.ARPA Cc: Common-lisp@SU-AI.ARPA Subject: Compilation and package system In-reply-to: Msg of 8 Apr 1985 18:03-EST from perdue%hplabs.csnet at csnet-relay.arpa Yep, that's true. In the hurry to say that compiling code has no effects on its semantics, the CLM glossed over some uglies that are unlikely to go away. One is the problem that you mention: reading throws away information, so the load-time semantics cannot be the same with compiled code. It would be nice if someone could decide what should be guaranteed about the package semantics of symbols in compiled code. Another problem involves the constraints placed on objects that can be function constants. 1] Can any type of object be dumped? Compiled functions, hashtables, streams? The answer is almost certainly no, but nowhere is it specified what you can dump. A conservative rule would be to only guarantee that readable objects can be dumped. 2] Is sharing and non-sharing preserved? Probably not. 3] Can circular structures can dumped? Note that they can be read and printed. Rob  Received: from SU-AI.ARPA by MIT-MC.ARPA; 10 APR 85 23:47:12 EST Received: from SCRC-VALLECITO.ARPA by SU-AI.ARPA with TCP; 10 Apr 85 10:24:09 PST Received: from SCRC-NEPONSET by SCRC-VALLECITO via CHAOS with CHAOS-MAIL id 6908; Wed 10-Apr-85 13:22:59-EST Date: Wed, 10 Apr 85 13:24 EST From: David C. Plummer in disguise Subject: What are we talking about anyway? To: Dave Dyer , common-lisp@SU-AI.ARPA In-Reply-To: The message of 10 Apr 85 13:12-EST from Dave Dyer Message-ID: <850410132431.9.NFEP@NEPONSET.SCRC.Symbolics.COM> Date: 10 Apr 1985 10:12:15 PST From: Dave Dyer Received: from SCRC-STONY-BROOK by SCRC-QUABBIN via CHAOS with CHAOS-MAIL id 152301; Wed 10-Apr-85 13:15:37-EST Received: from SU-AI.ARPA by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 212320; 10 Apr 85 13:13:52-EST Received: from USC-ISIB.ARPA by SU-AI.ARPA with TCP; 10 Apr 85 10:12:47 PST FYI: Adding mandatory/optional argument checking to Interlisp-VAX would be easy, and incur no additional overhead. ReSent-Date: 10 Apr 1985 10:12:15 PST ReSent-From: Dave Dyer ReSent-To: common-lisp@SU-AI.ARPA Where did THAT header come from? There is no To: or From: fields. Default values for &optional args would require a substantial rethinking of the function call mechanism, as would &rest and &key. Point of information: Why are people discussing various implementations of the Interlisp calling strategies on the common-lisp mailing list? As I remember, this whole thing started because somebody didn't realize what keyword arguments (in Common Lisp) are for.  Received: from SU-AI.ARPA by MIT-MC.ARPA; 10 APR 85 23:14:04 EST Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 10 Apr 85 20:05:46 PST Date: Wed,10 Apr 85 23:04:40 EST From: Glenn S. Burke Subject: Meaning of PROBE-FILE for direction output To: common-lisp@SU-AI Message-ID: <[MIT-MC].450268.850410.GSB> Another timing problem with this is that any way of doing it which involves actually doing the open might leave an entry in the filesystem, even though only temporarily. I would not want to have to simulate any hairy (tops-20, vms, especially version 4) operating system's algorithm for determining if i had access -- ergo, i would implement it by doing the open to see if it succeeds.  Received: from SU-AI.ARPA by MIT-MC.ARPA; 10 APR 85 22:48:54 EST Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 10 Apr 85 19:33:06 PST Received: from SCRC-EUPHRATES by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 212741; Wed 10-Apr-85 22:33:05-EST Date: Wed, 10 Apr 85 22:33 EST From: David A. Moon Subject: Compilation and package system To: Skef Wholey cc: Common-lisp@SU-AI.ARPA In-Reply-To: Message-ID: <850410223354.7.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Tue, 9 Apr 1985 22:14 EST From: Skef Wholey There are a number of ways to let the compiler know about the package that a file will be loaded into. The portable, Common Lisp way to do this is with a call to In-Package at the beginning of a file, as suggested in CLTL, on page 189. The Lisp Machine -*- file comment hack (which is used by the editor, compiler, and loader) has a few drawbacks. First of all, it is not portable. People write Common Lisp programs with a -*- package specification, but these programs must be modified (by adding a real In-Package to the program text) when they are moved to non-Lisp Machine Common Lisps. I guess it's a matter of viewpoint which way is non-portable, depending on which way you're trying to port. But let's not get into that. Secondly, one cannot put all of the information about the packages Use'd or symbols Import'ed in the file comment. One cannot accurately fix up the package environment by looking at the file comment. I suppose one could hair it up to include imports and shadows and whatnot (maybe someone already has), but that just leaves one with more stuff to "translate into Common Lisp" when he moves his program off of the Lisp Machine. We believe that complex package setups should go in their own files. Finally, the Symbolics Common Lisp Compatibility Package will give an error when one attempts to load or compile a file with a header something like that presented below, because it interprets the file comment, and wants to find any package specified there before reading anything in the file. In fact, the first form read may be the one that creates the package, so it may not be there for the file comment gremlin to interpret. In-Package is a nice language feature that Does The Right Thing, but has been rendered useless on the Lisp Machine by zealous use of file comment magic. I don't think it would be constructive for me to respond to the above paragraph in the same tone as it was written, so I will refrain. We have adopted the convention that any -*- package specification is for the editor only, and that the compiler and friends should get stuff out of Lisp forms. Thus, a typical Spice Lisp system file might begin with something like: ;;; -*- Package: Lisp; Log: Code.Log -*- ;;; ;;; ...blah blah blah... ;;; (in-package "LISP" :use '("SYSTEM")) (export '(things that this file defines)) The editor knows which package to associate with a buffer created when visiting this file, but the compiler and loader and everyone else just read Lisp forms, the way Father Lisp wanted them to. This all sounds at first like it makes a lot of sense, but wait a minute. I fail to see how the editor needs any less information about packages than the compiler and the loader. How does the editor know the names of the functions in the file if it doesn't know what package they are relative to? How can the editor understand forms in the file, telling you about arguments wanted by functions, documentation of variables, syntax of macros, and so forth, if it can't intern symbols whose printed representations it finds there? How can you incrementally compile or load portions of the file being edited if the machine doesn't know what package to read the forms in? Or does you editor make a special pass through the file when it reads it in, looking for "(IN-PACKAGE "? In our system all programs that read Lisp forms from files get the package information from the same place and they all work consistently. Since the -*- convention is not part of Common Lisp (and perhaps for good reason), I would encourage EVERYONE writing Common Lisp programs to begin each file in the way suggested in CLTL. Smart editors need to know things like the package (so that functions compiled in the text editor end up in the right package, for example), however, so it might be worth some effort to standardize the semantics of -*- file comments. Unfortunately, I imagine neither the Lisp Machine community nor the Spice Lisp community is willing to give in. Probably not, considering that IN-PACKAGE was put into Common Lisp over my dead body. This is my fault for not doing an adequate job of explaining why it was a bad idea and only workable in the short run. As you say, it might be worth some effort to standardize the semantics of -*-.  Received: from SU-AI.ARPA by MIT-MC.ARPA; 10 APR 85 22:41:18 EST Received: from MIT-EDDIE.ARPA by SU-AI.ARPA with TCP; 10 Apr 85 11:11:57 PST Received: by mit-eddie.ARPA (4.12/4.8) id AA09669; Wed, 10 Apr 85 14:04:48 est Date: Wed, 10 Apr 85 14:04:48 est From: Steven M. Haflich Message-Id: <8504101904.AA09669@mit-eddie.ARPA> To: Common-Lisp@SU-AI.ARPA Subject: defstruct slot names I hope this wasn't discussed in the distant past. The CLTL definition of the defstruct macro (p.308) has a hole which deserves plugging. Each slot-name in the defstruct form is required only to be a symbol. It would seem that the following is perfectly legal, even if it has no clear motivation: (defstruct automobile engine:horsepower insurance:dollar-value) It is reasonable to assume that the constructor function can only ignore the package of a slot-name regardless whether it is the same package as the structure name. So this is OK: (make-automobile :horsepower 289 :dollar-value 14500) Anyway, this is probably what would happen in any obvious implementation which had given this issue no thought at all. But consider: (defstruct automobile engine:horsepower liability-insurance:dollar-value collision-insurance:dollar-value) While there is no requirement that slot-names be distinct, it is reasonable that identical slot names should be an error. But the two dollar-value slots are distinct even though they herniate the naming scheme for constructor keywords and access-functions. The problem is that slot names are semantically scoped within the structure containing them, so packages are irrelevant. The ways in which slot names are used rather assumes this, but the assumption is nowhere explicit. Can anyone think of a legitimate use for packages in slots names? If not, I propose the manual should explicitly state that defstruct interns all slot names in the keyword package. Compare the definition of the #S(name slot1 'value ...) reader syntax (p.357). This issue will likely also affect active objects.  Received: from SU-AI.ARPA by MIT-MC.ARPA; 10 APR 85 22:39:24 EST Received: from USC-ISIB.ARPA by SU-AI.ARPA with TCP; 10 Apr 85 10:12:47 PST FYI: Adding mandatory/optional argument checking to Interlisp-VAX would be easy, and incur no additional overhead. ReSent-Date: 10 Apr 1985 10:12:15 PST ReSent-From: Dave Dyer ReSent-To: common-lisp@SU-AI.ARPA Default values for &optional args would require a substantial rethinking of the function call mechanism, as would &rest and &key.  Received: from SU-AI.ARPA by MIT-MC.ARPA; 10 APR 85 21:23:59 EST Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 10 Apr 85 11:58:59 PST Received: ID ; Wed 10 Apr 85 14:57:09-EST Date: Wed, 10 Apr 1985 14:56 EST Message-ID: From: Rob MacLachlan To: Jon White Cc: common-lisp@SU-AI.ARPA, greek@DEC-HUDSON.ARPA, moon@SCRC-STONY-BROOK.ARPA Subject: Meaning of PROBE-FILE for direction output In-reply-to: Msg of 9 Apr 1985 21:11-EST from Jon White I don't think that either of the problems of a non-opening probe for output files that you mention are important. The problem of the result only being valid for an arbitrarily short period of is not unique to this function. When opening for input, the file could be deleted or opened in a read-exclusive fashion between the probe-file and any open attempt. I'm not quite sure what sort of problem you are referring to in the second case. Are you talking about the business of the version number not being known, or what? The function I propose would probably return a null version, since that could not be known. Rob  Received: from SU-AI.ARPA by MIT-MC.ARPA; 10 APR 85 21:22:06 EST Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 10 Apr 85 11:56:46 PST Received: ID ; Wed 10 Apr 85 14:55:54-EST Date: Wed, 10 Apr 1985 14:55 EST Message-ID: Sender: FAHLMAN@CMU-CS-C.ARPA From: "Scott E. Fahlman" To: "Steven M. Haflich" Cc: Common-Lisp@SU-AI.ARPA Subject: defstruct slot names In-reply-to: Msg of 10 Apr 1985 14:04-EST from Steven M. Haflich I think that the motivation for allowing slot names to be non-keywords was that it might be useful to have these be local to some particular package. Of course, none of us was so perverse as to imagine that users would (a) mix together a lot of packages in the same defstruct definition and (b) then go on and introduce name conflicts among the symbols. I think that instead of somehow trying to make this illegal, we should just let the users hang themselves if they're that eager to do so. If there was some way in which this situation might happen by accident in halfway reasonable code, then it might be worthwhile to check for this case and keep the user out of trouble, but I don't see any potential for innocent lossage here. -- Scott "Nothing is foolproof because fools are so ingenious."  Received: from SU-AI.ARPA by MIT-MC.ARPA; 10 APR 85 20:30:27 EST Sent: to SU-AI.ARPA by IMSSS.? via ETHERNET with PUPFTP; 1985-Apr-10 15:01:27 PST (=GMT-8hr) Date: 1985 April 10 15:00:36 PST (=GMT-8hr) Message-id: SU-IMSSS.REM.A132125241707.G0365 From: Robert Elton Maas To:RAM@CMU-CS-C.ARPA CC:COMMON-LISP@SU-AI.ARPA Subject:interp .neq. compil, even in CL Sender: REM%IMSSS@SU-SCORE.ARPA (for undeliverable-mail notifications) Reply-to: REM%IMSSS@SU-SCORE.ARPA (temporary until nameservers up) |Date: Wed, 10 Apr 1985 15:16 EST |From: Rob MacLachlan | | Yep, that's true. In the hurry to say that compiling code has no |effects on its semantics, the CLM glossed over some uglies that are |unlikely to go away. Hear! Hear! You've brought up several items that ought to be explained in the manual. It should say something like "Common LISP tries to make the semantics of compiled programs and the semantics of their interpreted sources as nearly identical as they can be. But certain processes such as reading data in or writing it out lose information thereby causing some differences between interpreted and compiled code: - READing an s-expression containing unqualified identifiers (those with no explicit package qualifier) to be assigned to a package at the time they are read, thus causing compiled identifiers to be assigned to a package which was default at the time of compiling rather than the package that is default at the time the compiled code is later read and executed. To force these two packages to be the same, the IN-PACKAGE declaration is available (page ...). - When writing two different s-expressions (using PRIN1 or via compiling and FASL-writing), information about internal structure they share is lost. There is no way short of hashcons to maintain that sharing over a write-read cycle. ..." etc. etc. This list of differences between interpreted and compiled software should be summarized all in one place, as above, although details of IN-PACKAGE and the like can be elsewhere. CLM should realize it has not totally obtained the goal of interp/compil equivalence, and state to which degree it has and hasn't succeeded, lest hundreds of LUSERs discover for themselves (painfully) that we haven't told them the truth.  Received: from SU-AI.ARPA by MIT-MC.ARPA; 9 APR 85 23:07:01 EST Received: from SUMEX-AIM.ARPA by SU-AI.ARPA with TCP; 9 Apr 85 19:57:50 PST Date: Tue 9 Apr 85 19:57:32-PST From: Mark Richer Subject: Re: Arg cont checking, optionals, keywords, etc To: JLW@SU-AI.ARPA cc: Card.pa@XEROX.ARPA, bug-1100@SUMEX-AIM.ARPA, common-lisp@SU-AI.ARPA, RICHER@SUMEX-AIM.ARPA In-Reply-To: Message from "Jon White " of Tue 9 Apr 85 17:22:00-PST I wonder if Interlisp could have an option where arg checking was optional or only done on functions with a certain editdate (beyond the date the incompatibility is announced) without a penalty to users who set arg checking to be done always? mark -------  Received: from SU-AI.ARPA by MIT-MC.ARPA; 9 APR 85 22:24:33 EST Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 9 Apr 85 19:15:26 PST Received: ID ; Tue 9 Apr 85 22:14:16-EST Date: Tue, 9 Apr 1985 22:14 EST Message-ID: Sender: WHOLEY@CMU-CS-C.ARPA From: Skef Wholey To: "Daniel L. Weinreb" CC: Common-lisp@SU-AI.ARPA, perdue%hplabs.csnet@CSNET-RELAY.ARPA Subject: Compilation and package system There are a number of ways to let the compiler know about the package that a file will be loaded into. The portable, Common Lisp way to do this is with a call to In-Package at the beginning of a file, as suggested in CLTL, on page 189. The Lisp Machine -*- file comment hack (which is used by the editor, compiler, and loader) has a few drawbacks. First of all, it is not portable. People write Common Lisp programs with a -*- package specification, but these programs must be modified (by adding a real In-Package to the program text) when they are moved to non-Lisp Machine Common Lisps. Secondly, one cannot put all of the information about the packages Use'd or symbols Import'ed in the file comment. One cannot accurately fix up the package environment by looking at the file comment. I suppose one could hair it up to include imports and shadows and whatnot (maybe someone already has), but that just leaves one with more stuff to "translate into Common Lisp" when he moves his program off of the Lisp Machine. Finally, the Symbolics Common Lisp Compatibility Package will give an error when one attempts to load or compile a file with a header something like that presented below, because it interprets the file comment, and wants to find any package specified there before reading anything in the file. In fact, the first form read may be the one that creates the package, so it may not be there for the file comment gremlin to interpret. In-Package is a nice language feature that Does The Right Thing, but has been rendered useless on the Lisp Machine by zealous use of file comment magic. We have adopted the convention that any -*- package specification is for the editor only, and that the compiler and friends should get stuff out of Lisp forms. Thus, a typical Spice Lisp system file might begin with something like: ;;; -*- Package: Lisp; Log: Code.Log -*- ;;; ;;; ...blah blah blah... ;;; (in-package "LISP" :use '("SYSTEM")) (export '(things that this file defines)) The editor knows which package to associate with a buffer created when visiting this file, but the compiler and loader and everyone else just read Lisp forms, the way Father Lisp wanted them to. Since the -*- convention is not part of Common Lisp (and perhaps for good reason), I would encourage EVERYONE writing Common Lisp programs to begin each file in the way suggested in CLTL. Smart editors need to know things like the package (so that functions compiled in the text editor end up in the right package, for example), however, so it might be worth some effort to standardize the semantics of -*- file comments. Unfortunately, I imagine neither the Lisp Machine community nor the Spice Lisp community is willing to give in. --Skef  Received: from SU-AI.ARPA by MIT-MC.ARPA; 9 APR 85 21:45:34 EST Date: 09 Apr 85 1811 PST From: Jon White Subject: Meaning of PROBE-FILE for direction output To: moon@SCRC-STONY-BROOK.ARPA, ram@CMU-CS-C.ARPA, greek@DEC-HUDSON.ARPA CC: common-lisp@SU-AI.ARPA There are a couple of problems with using a non-OPENing probe for output files, which caused the Intelisp-D development group to want to flush the equivalent [outfilep]. One problem is the obvious one that when the result is non-null, it can be a guarantee only for a short interval of time [I'm assuming that even personal workstations will be having access to shared file servers] that such a file name may be opened for writing by the caller -- because someone else may sneak in and open up exactly the file you want. Another problem stems from a possible discrepancy between the pathname completion done by the file system when actually OPENing and when merely probing (without opening) On the other hand, it appears as though some persons may feel as Paul does, that using an "error" trap to do normal programming is bad practice. A reasonable way out of this dilemma is simply to stop calling such signals "errors", and admit signals as a first class mechanism. Xerox's Mesa language has an admirable signalling mechanism, although a little too baroque for my taste. The interface definition of any function then requires a description of the types of input argments, the types of output values (multple values) and an enumeration of any signals raised. In pdp10 MacLisp days, all "signals" were raised via calling ERRORs; the lossage with that approach is the too-limited bandwith of a single signal (the ERROR signal). So the "signal" approach would require the client program to actually do an OPEN and to check for signals as well as the return value; there are numerous ways to insure that an abort after the actual open will cause a close, but I wonder what purpose would be served by providing a probe-file for output operation if th client didn't actually open the file sooner or later anyhow. -- JonL --  Received: from SU-AI.ARPA by MIT-MC.ARPA; 9 APR 85 21:14:21 EST Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 9 Apr 85 17:37:24 PST Received: from SCRC-EUPHRATES by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 211990; Tue 9-Apr-85 20:37:10-EST Date: Tue, 9 Apr 85 20:37 EST From: David A. Moon Subject: Probe-File and proposed extension. To: Rob MacLachlan cc: common-lisp@SU-AI.ARPA, greek@DEC-HUDSON.ARPA In-Reply-To: Message-ID: <850409203759.4.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Mon, 8 Apr 1985 18:29 EST From: Rob MacLachlan The point about relative pathnames is the following: When you actually write a file, Open resolves any relative pathname down to an absolute pathname. Any implementation that allows writing relative pathnames must have some way to map the relative pathname to an absolute pathname. This mapping is not necessarily the same as merge pathnames, and in any case, there is no way in Common Lisp to determine what the defaults are. Well, the defaults for MERGE-PATHNAMES are whatever the program wants to pass to merge-pathnames as an argument. I would hope that if OPEN has to call MERGE-PATHNAMES, it would use *DEFAULT-PATHNAME-DEFAULTS*. But this is moot since by relative pathnames you meant something different than I: In Spice Lisp, when you open a file for write, Open first looks for any file with that name on the default search list, and if found, overwrites it, otherwise it creates a file in the current directory. I will argue that this is the right semantics in our implementation, and it is clearly implementation dependent. Regardeless of the error issue, it would be useful to be able to default a pathname for output in this fashion. I see. This is not covered by the generic file-system model, but that doesn't mean there is anything wrong with it. You need an interface to this implementation-dependent feature, and the question is, should the interface be defined in an implementation-independent way? Looked at that way, the proposal for a :direction keyword to PROBE-FILE seems pretty reasonable. Now that I understand it, this seems reasonable to me, and perhaps it's time for you to make an explicit proposal. On the other hand, you could always just add a function to Spice Lisp that is just an implementation-dependent interface to Accent. Trying to do file-system-related things in an implementation-independent way can often be very tricky. I know of at least one file system that would have some difficulty implementing this feature (specifically, getting the version number right), although it probably wouldn't be impossible. This should go on any lists that are being kept of proposed language enhancements and clarifications. As for the error issue, Spice Lisp currently does exactly what you suggest. A user complained that this was not what the manual said it should do. I tried both the Dec-20 Clisp and the Kyoto Common Lisp implementations, and they both refused to signal errors, no matter what garbage you gave them. I decided at this point that the issue was unclear, but that the Spice Lisp implementation was probably wrong. I think the Spice Lisp implementation is right. I don't think any implementation without an error-handling system can be used as a fair test of the circumstances in which PROBE-FILE should signal an error.  Received: from SU-AI.ARPA by MIT-MC.ARPA; 9 APR 85 20:42:49 EST Date: 09 Apr 85 1722 PST From: Jon White Subject: Arg cont checking, optionals, keywords, etc To: Card.pa@XEROX.ARPA CC: bug-1100@SUMEX-AIM.ARPA, common-lisp@SU-AI.ARPA Common Lisp has already developed a keyword argument syntax, so that "optionals" may be passed in random order. Until one actually gets down to implementing that proposal, he may be frightened away by the thought that it would unduly slow down the function calling protocol. I don't think it does (slow the vanilla case down), but am not inclined to elucidate over network mail. A major problem for Interlisp-D is, however, the backwards compatiblity question. Whereas it may be quite all right to take a function, say, (DEFINEQ (FOO (A B C) ...] and redefine it like (DEFINEQ (FOO (&OPTIONAL A B C) ...] and, I think, even suffer no slowdown. But what if you really wanted (DEFINEQ (FOO (A B &OPTIONAL C) ...] Then a lot of code may have to be re-written (or perhaps massaged mechanically) so that calls like (FOO 3) become (FOO 3 NIL). The benefits of arg count checking won't be realized without breaking some already running code. -- JonL --  Received: from SU-AI.ARPA by MIT-MC.ARPA; 9 APR 85 17:01:54 EST Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 9 Apr 85 13:30:49 PST Received: from SCRC-CHICOPEE by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 211844; Tue 9-Apr-85 16:26:09-EST Date: Tue, 9 Apr 85 16:27 EST From: Daniel L. Weinreb Subject: Compilation and package system To: perdue%hplabs.csnet@CSNET-RELAY.ARPA, Common-lisp@SU-AI.ARPA In-Reply-To: <8504090204.AA23590@HP-VENUS> Message-ID: <850409162744.7.DLW@CHICOPEE.SCRC.Symbolics.COM> When the compiler compiles a file, it has to know what package to do the READs in. If the compiler reads the symbols into the wrong package, there's no hope. Our system has a convention that lets you tell the compiler what package to use. The same convention tells the editor and the loader what package to use as well.  Received: from SU-AI.ARPA by MIT-MC.ARPA; 9 APR 85 16:50:46 EST Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 9 Apr 85 13:36:33 PST Received: from SCRC-CHICOPEE by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 211848; Tue 9-Apr-85 16:29:34-EST Date: Tue, 9 Apr 85 16:31 EST From: Daniel L. Weinreb Subject: Re: Arg count checking To: card.pa@XEROX.ARPA, masinter.pa@XEROX.ARPA cc: bug-1100@SUMEX-AIM.ARPA, common-lisp@SU-AI.ARPA In-Reply-To: The message of 8 Apr 85 20:06-EST from card.pa@XEROX.ARPA Message-ID: <850409163106.9.DLW@CHICOPEE.SCRC.Symbolics.COM> I don't think I understand the point of your message. What is the difference between what you are proposing and Common Lisp keyword arguments, other than syntax?  Received: from SU-AI.ARPA by MIT-MC.ARPA; 9 APR 85 14:57:15 EST Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 9 Apr 85 11:47:22 PST Received: from bostonu by csnet-relay.csnet id ab02727; 9 Apr 85 14:30 EST Received: by bu-cs.ARPA (4.12/4.7) id AA12160; Tue, 9 Apr 85 12:55:13 est Date: Tue, 9 Apr 85 12:55:13 est From: BostonU SysMgr To: card.pa@XEROX.ARPA, masinter.pa@XEROX.ARPA Subject: Re: Arg count checking Cc: bug-1100@SUMEX-AIM.ARPA, common-lisp@SU-AI.ARPA > Date: 8 Apr 85 17:06 PST > From: card.pa@XEROX.ARPA > Subject: Re: Arg count checking > .... > DEFINEQ > ((NSPRINT > (LAMBDA (PRINTER > (FILE.NAME OPTIONAL) > (DOCUMENT.NAME OPTIONAL) > (DOCUMENT.CREATION.DATE OPTIONAL) > (RECIPIENT.NAME OPTIONAL) > (#COPIES OPTIONAL) > (MEDIUM OPTIONAL) > (PRIORITY OPTIONAL) > (STAPLE? OPTIONAL) > (TWO.SIDED OPTIONAL))))) > > implements a function where the first argument PRINTER is mandatory and > the remaining are all optional. I agree but thought at this design stage I could throw my two cents in. It seems that rather than those redundant OPTIONALs a default value would be more useful, the fact that it is a list rather than an atom is sufficient to deduce that this is a keyword parameter (and it makes the whole thing consistent with PROG.) That's it...just two cents worth. -Barry Shein, Boston University  Received: from SU-AI.ARPA by MIT-MC.ARPA; 9 APR 85 10:16:38 EST Received: from [10.4.0.6] by SU-AI.ARPA with TCP; 9 Apr 85 07:08:58 PST Received: by Think.ARPA with CHAOS id AA22257; Tue, 9 Apr 85 10:06:22 est Date: Tue, 9 Apr 85 10:09 EST From: Guy Steele Subject: NIL and DEFCONSTANT [Gall: Bug Report] To: common-lisp@SU-AI.ARPA Cc: gls%AQUINAS.TMC@Think In-Reply-To: Response to Fahlman: Response to Steele: Maybe a right attitude to take is that it is an error to execute any compiled code that refers to a DEFCONSTANT'ed name that has been re-DEFCONSTANT'ed to a different (non-EQL?) value since the code was compiled. Yeah, that seems reasonable. We want to be able to change the value of a constant if, for example, we notice a typo, but once something has been compiled that uses that constant, it is unpredictable which value you get if you then change the constant. That would say that it is okay to (DEFCONSTANT T 43), but then you had better not execute any system code that refers to T. But the evaluator probably refers to T, so in practice you had simply better not do it. This looks like trouble to me. I don't think we'd better tell the users that this is legal but that they'd probably better not do it in practice. Unlike us high-powered language designers, mere users are likely to be confused by this. Maybe we'd just better tell them that it is erroneous, wrongheaded, evil, and uncool to do this, and that if they persist in this practice Father Lisp won't bring them any parentheses when they hang out their bit buckets on Flag Day. All I meant by this is that the evilness of redefining T follows logically from (1) the proposed rule that allows users to carefully redefine things, and (2) the fact that EVERYTHING depends on T. What we tell the user is another story. An additional attitude is that it is reasonable for the system to take a benevolent protective interest in those constants on which it depends. (Translation: refuse to change T because everything will break.) --Guy  Received: from SU-AI.ARPA by MIT-MC.ARPA; 9 APR 85 07:57:50 EST Sent: to SU-AI.ARPA by IMSSS.? via ETHERNET with PUPFTP; 1985-Apr-09 04:49:45 PST (=GMT-8hr) Date: 1985 April 09 04:49:12 PST (=GMT-8hr) Message-id: SU-IMSSS.REM.A132124132151.G0365 From: Robert Elton Maas To: "perdue%hplabs.csnet"@csnet-relay.arpa CC: Common-LISP@SU-AI.ARPA Subject: READ loses info as to whether package is specified or not, my fix Sender: REM%IMSSS@SU-SCORE.ARPA (for undeliverable-mail notifications) Reply-to: REM@MIT-MC.ARPA |Date: 8-Apr-85 18:03:48 |Subject: Compilation and package system |From: perdue%hplabs.csnet@csnet-relay.arpa |It is surprising to me that there has not been discussion of |the problems of compiling when there is a package system. |The specific problem I have in mind is in the handling of |symbols that are referred to in the input text without a package |qualifier. | |The user of a Common LISP implementation sees the problem as a |difference between the behavior of a module (file) loaded in its |interpretive form and loaded in its compiled form. Specifically, |references to symbols will in some cases be resolved differently |depending on whether or not the file was compiled before being loaded. I agree, this may indeed be a serious problem. I think the answer is to flush the idea that any piece of LISPish text must run exactly the same interpreted and compiled, and rather say that any correct LISP program must run the same interpreted and compiled. We define a file without an IN-PACKAGE at the beginning to NOT be a correct LISP program. Thus it may still work interpreted, and compiled, although differently, but the compiler should flag as an warning that it is not a valid LISP program and might not execute as expected (as it did interpreted).  Received: from SU-AI.ARPA by MIT-MC.ARPA; 9 APR 85 07:56:28 EST Sent: to SU-AI.ARPA by IMSSS.? via ETHERNET with PUPFTP; 1985-Apr-09 04:46:51 PST (=GMT-8hr) Date: 1985 April 09 02:54:05 PST (=GMT-8hr) Message-id: SU-IMSSS.REM.A132124131673.G0390 From: Robert Elton Maas To:Fahlman@CMU-CS-C.ARPA CC:common-lisp@SU-AI.ARPA Subject: I agree, but manual should tell LUSERs why Sender: REM%IMSSS@SU-SCORE.ARPA (for undeliverable-mail notifications) Reply-to: REM@MIT-MC.ARPA |Date: Mon, 8 Apr 1985 22:37 EST |From: "Scott E. Fahlman" |Subject: NIL and DEFCONSTANT [Gall: Bug Report] | | Maybe a right attitude to take is that it is an error | to execute any compiled code that refers to a DEFCONSTANT'ed | name that has been re-DEFCONSTANT'ed to a different (non-EQL?) | value since the code was compiled. | |Yeah, that seems reasonable. We want to be able to change the value of |a constant if, for example, we notice a typo, but once something has |been compiled that uses that constant, it is unpredictable which value |you get if you then change the constant. I agree. But more than just saying "it is an error to use code that has been compiled with one value of a constant in an environment where that constant now has a different value", we should explain what seems obvious to us so LUSERs who can't see the obvious can be shown the obvious and then see it themselves. (This is the sort of thing that isn't machine-dependent, the same problem would happen on virtually any system we imagine, thus we CAN say something more than the mysterious cop-out "it is an error to ...".) We could say something like "if code is compiled with the constant having one value, but then the constant is redefined and the previously-compiled code is run, it will probably use the old value instead of the new value. Accordingly, it is an error to continue to run the previously-compiled code after the constant has been redefined, and it is an error to redefine any commonly-used system constant unless one plans to recompile the whole LISP system immediately thereafter. It is an error to redefine T or NIL in any case of course." |Maybe we'd just better tell them that it is erroneous, wrongheaded, |evil, and uncool to do this, and that if they persist in this practice |Father Lisp won't bring them any parentheses when they hang out their |bit buckets on Flag Day. That's the right idea, but of course you are being flip here, the manual certainly shouldn't be so cutesy as that.  Received: from SU-AI.ARPA by MIT-MC.ARPA; 9 APR 85 04:10:46 EST Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 9 Apr 85 00:59:52 PST Received: from hplabs by csnet-relay.csnet id ad14103; 9 Apr 85 3:42 EST Received: by HP-VENUS id AA23590; Mon, 8 Apr 85 18:04:43 pst Message-Id: <8504090204.AA23590@HP-VENUS> Date: 8-Apr-85 18:03:48 To: Common-lisp@su-ai.ARPA Subject: Compilation and package system From: perdue%hplabs.csnet@csnet-relay.arpa Source-Info: From (or Sender) name not authenticated. It is surprising to me that there has not been discussion of the problems of compiling when there is a package system. The specific problem I have in mind is in the handling of symbols that are referred to in the input text without a package qualifier. The user of a Common LISP implementation sees the problem as a difference between the behavior of a module (file) loaded in its interpretive form and loaded in its compiled form. Specifically, references to symbols will in some cases be resolved differently depending on whether or not the file was compiled before being loaded. The source of the problem is that LISP compilers use READ to get forms to compile and READ loses all information about whether a symbol was specified with a package qualifier and whether a single or double colon. If the file has an IN-PACKAGE at the beginning it is only pathological cases that cause problems, but if the file does not, needed information has clearly been lost. The CLM specifies that loading a compiled file shall be equivalent to loading an interpretive file, but the packages of symbols in a compiled file have in effect been DETERMINED AT COMPILE TIME, and load-time binding can only be faked. Various heuristics are used by implementations to try to do more or less the right thing. For example, any symbol available without name qualification when read can be assumed to have been named without a package qualifier. At loadtime the reference can be resolved as though it had no qualifier. But the knowledge of whether it was actually written with qualification has been lost. If the module (file) is loaded with a current package different than the current package when it was compiled, loading of the compiled version will not necessarily result in references to the same symbols as loading the interpretive version of the module. -------  Received: from SU-AI.ARPA by MIT-MC.ARPA; 8 APR 85 22:54:12 EST Received: from UCB-VAX.ARPA by SU-AI.ARPA with TCP; 8 Apr 85 19:46:22 PST Received: from ucbdali.ARPA by UCB-VAX.ARPA (4.24/4.45) id AA05969; Mon, 8 Apr 85 19:45:24 pst Received: by ucbdali.ARPA (4.24/4.42) id AA05239; Mon, 8 Apr 85 19:46:33 pst Date: Mon, 8 Apr 85 19:46:33 pst From: fateman%ucbdali@Berkeley (Richard Fateman) Message-Id: <8504090346.AA05239@ucbdali.ARPA> To: card.pa@Xerox.ARPA, masinter.pa@Xerox.ARPA Subject: Re: Arg count checking Cc: bug-1100@SUMEX-AIM.ARPA, common-lisp@SU-AI.ARPA A heretical suggestion: (let ((staple? t)) (nsprint 'mprinter)). Using dynamic scope and global variables has been widely used in Interlisp and other systems to great advantage (and disadvantage). Setting up your default nsprint environment by setq's and then locally overriding is handy, though I suppose this is possible to do by initializing the optional arguments according to whether global variables of the same name are bound etc.  Received: from SU-AI.ARPA by MIT-MC.ARPA; 8 APR 85 22:46:31 EST Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 8 Apr 85 19:37:30 PST Received: ID ; Mon 8 Apr 85 22:37:30-EST Date: Mon, 8 Apr 1985 22:37 EST Message-ID: Sender: FAHLMAN@CMU-CS-C.ARPA From: "Scott E. Fahlman" To: common-lisp@SU-AI.ARPA Subject: NIL and DEFCONSTANT [Gall: Bug Report] Response to Steele: Maybe a right attitude to take is that it is an error to execute any compiled code that refers to a DEFCONSTANT'ed name that has been re-DEFCONSTANT'ed to a different (non-EQL?) value since the code was compiled. Yeah, that seems reasonable. We want to be able to change the value of a constant if, for example, we notice a typo, but once something has been compiled that uses that constant, it is unpredictable which value you get if you then change the constant. That would say that it is okay to (DEFCONSTANT T 43), but then you had better not execute any system code that refers to T. But the evaluator probably refers to T, so in practice you had simply better not do it. This looks like trouble to me. I don't think we'd better tell the users that this is legal but that they'd probably better not do it in practice. Unlike us high-powered language designers, mere users are likely to be confused by this. Maybe we'd just better tell them that it is erroneous, wrongheaded, evil, and uncool to do this, and that if they persist in this practice Father Lisp won't bring them any parentheses when they hang out their bit buckets on Flag Day. -- Scott  Received: from SU-AI.ARPA by MIT-MC.ARPA; 8 APR 85 21:03:55 EST Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 8 Apr 85 17:35:47 PST Received: from SCRC-RIO-DE-JANEIRO by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 211220; Mon 8-Apr-85 19:42:56-EST Date: Mon, 8 Apr 85 20:19 EST From: Kent M Pitman Subject: PROBE-FILE To: greek@DEC-HUDSON.ARPA cc: common-lisp@SU-AI.ARPA, Moon@SCRC-STONY-BROOK.ARPA In-Reply-To: The message of 8 Apr 85 15:02-EST from greek at DEC-HUDSON Message-ID: <850408201917.8.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> Date: Mon, 08 Apr 85 15:02:22 EST From: greek@DEC-HUDSON Rob's proposal makes sense. A few comments: ... 3. PROBE-FILE needs to tell me more. I want to know if I can't get at the file because: a) the file spec is bad. b) the device doesn't exist. c) the directory doesn't exist. d) I don't have sufficient access privilege. e) etc., etc. The basic need addressed by Rob is a real one: Is this file spec good, can I get to the file, and what can I do to it (read, write, etc). It is precisely because of this need to return a multitude of kinds of information that the Lisp Machine has gone away from having more functions to do this kind of investigation and toward using errors to convey this information. In the Lisp Machine's not-really-new-any-more "new error system", failure is flavorized so that a lot of kinds of information can be extracted depending on what the caller needs to know. This also has the important advantage that users who don't realize they need to detect odd situations will have their code stopped cold in its tracks rather than having it stumble on and notice a problem only later. For example, in Lisp Machine lisp, if you want to know if the failure was due to device doesn't exist, you can take the error object and do: (TYPEP error-object 'FS:DEVICE-NOT-FOUND) or if you want to know if a directory was not found, you do: (TYPEP error-object 'FS:DIRECTORY-NOT-FOUND) Or if you want more general information you can do: (TYPEP error-object 'FS:FILE-LOOKUP-ERROR) which will find both FS:DEVICE-NOT-FOUND errors and FS:DIRECTORY-NOT-FOUND errors. This allows error signallers to be quite exact about the error that occurred (by mixing in as many error types as are known to be relevant) and still have a fair chance that the handler will do something reasonable (by allowing it to look for more specific condition types than are actually signal. If you compare this to what you're asking for PROBE-FILE, you quickly realize that there is no obvious way to stop a huge explosion of functions named things like: (PROBE-FILE-RETURNING-NIL-FOR-BAD-PATHNAME ...) (PROBE-FILE-RETURNING-NIL-FOR-BAD-DEVICE-BUT-ERRING-ON-OTHER-PATHNAMES ...) ... or a huge explosion of keywords as in: (PROBE-FILE ... :ALLOW-ERROR-IF '(:BAD-DEVICE :BAD-DIRECTORY)) or a huge explosion of return values as in: (PROBE-FILE pathname) => pathname-or-NIL, device-not-found-p, device-not-valid-p, directory-not-found-p, ... or a huge explosion of keywords in return values such as (PROBE-FILE pathname) => pathname-or-NIL, reason-keyword (one of :DEVICE-NOT-FOUND, :DIRECTORY-NOT-AVAILABLE,...) etc. The problem with these situations is that you are then locked into a bottomless pit of having to make non-general extensions to the language every time a new situation comes up. In the Lisp Machine case, the definition of PROBEF is fairly simple. It returns a pathname if the probe code succeeds and the file was there, NIL if the probe code succeeds but no file was there, and errs if the probe code encounters a problem. How those problems may occur is something which users know is device dependent and subject to change as new devices are added or devices change their behavior. The really nice point is that flavors were designed to accomodate both the process of change and some sense of ambiguity in terms of what the error type is ("Is it a string error or a file error? hmm. Guess i'll make a new flavor file-string-error so that people watching for either situation can handle it.") So I really think this is something to be relegated to error handling. Although there's been little discussion on the error handling mailing list, I did get what I think is a fairly workable proposal out before discussion died down, so don't worry that we're just talking pipe dreams here. That's about all I have to say on the subject for now. Over the past several years using the LispM file system, I've been extremely pleased with how little I had to think about the target file system because of the nice abstractions upon which it's based. So my proxy basically goes to Moon for any further discussion on this subject. Just wanted to say something supportive since on sheer volume of mail it might have appeared he wasn't being believed.  Received: from SU-AI.ARPA by MIT-MC.ARPA; 8 APR 85 20:32:53 EST Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 8 Apr 85 17:16:40 PST Received: from Semillon.ms by ArpaGateway.ms ; 08 APR 85 17:07:23 PST Date: 8 Apr 85 17:06 PST From: card.pa@Xerox.ARPA Subject: Re: Arg count checking In-reply-to: masinter.pa's message of 1 Apr 85 01:00 PST To: masinter.pa@Xerox.ARPA cc: bug-1100@SUMEX-AIM.ARPA, common-lisp@SU-AI.ARPA Larry's message had an idea that coud be developed to handle both what I take to be the motivations of arg count checking and the motivations for optional arguments and more. 1. I remember that programming in Stanford Lisp 1.6, the mismatched number of argument was one of the most effective checks for getting out nuissance bugs quickly, especially the kind that comes where you change the arguments of the callee and miss some occurrences of calls to it. 2. The main offsetting advantage from giving this up in Interlisp-D seems to be that for functions with complicated arguments that are infrequently used. A simple calling sequnce is available for simple calls, more complicated calls for complicated situations. But there would seem to be be more graceful (from the point of view of the program reflecting the user's intentions) methods of achieving this. 3. It is certainly eaiser for the programmer to call (NSPRINT 'MYPRINTER) than to have to write (NSPRINT 'MYPRINTER NIL NIL NIL NIL NIL NIL NIL NIL NIL NIL). Thus optional arguments are handy. But they are not really handy enough because (NSPRINT 'MYPRINTER NIL NIL NIL NIL NIL NIL NIL NIL T) is still required to request stapling on the printed output. This call is not programmable without reference to the manual or a system aid such as ?=. It is a likely location for error (miscouting the arguments) and it is not readable by someone looking over the code. If (1) arguments could be addressed by argument name and (2) could be optional, then such problems would disappear. A notation that would stay within the Interlisp tradition, would be to pattern it after DLAMBDA declarations in DECL. Thus OPTIONAL would become a property of arguments in the same way as FIXP. DEFINEQ ((NSPRINT (LAMBDA (PRINTER (FILE.NAME OPTIONAL) (DOCUMENT.NAME OPTIONAL) (DOCUMENT.CREATION.DATE OPTIONAL) (RECIPIENT.NAME OPTIONAL) (#COPIES OPTIONAL) (MEDIUM OPTIONAL) (PRIORITY OPTIONAL) (STAPLE? OPTIONAL) (TWO.SIDED OPTIONAL))))) implements a function where the first argument PRINTER is mandatory and the remaining are all optional. The function could be called with the syntax (NSPRINT 'MYPRINTER STAPLE?=T) or perhaps a prefix syntax syntax such as (NSPRINT 'MYPRINTER (& STAPLE? T)) or (NSPRINT 'MYPRINTER / STAPLE? T) . ANY argument ought to be callable this way. (A more elegant proposal might even be able to encompass the current syntax of (FOR X IN L SUCHTHAT ...) as an instance, thus serving as a unifying abstraction for Interlisp syntax). Of course, the OPTIONAL property would be made to fit into DECL as just one more property: (DLAMBDA ((A LISTP SPECIAL ) (B FIXP LOCAL OPTIONAL)) . . . ). Arguments described by name and optional arguments would probably be a slight bit slower than fixed arguments, but (1) this would be well worth the convenience and readability is most cases (e.g. NSPRINT). (2) The fixed argument called by place would still be about as the same speed as they were, probably, and (3) Fast versions of complicated argument calls where small gains in speed were very important would be programmed in fast versions, as at present (FRPLACA). Thus both bug detection and optional argument calling flexibility can be had within a unified framework that generalizes both. It would seem that one can car one's cake and cons it too.  Received: from SU-AI.ARPA by MIT-MC.ARPA; 8 APR 85 18:41:36 EST Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 8 Apr 85 15:30:23 PST Received: ID ; Mon 8 Apr 85 18:29:59-EST Date: Mon, 8 Apr 1985 18:29 EST Message-ID: From: Rob MacLachlan To: "David A. Moon" Cc: common-lisp@SU-AI.ARPA, greek@DEC-HUDSON.ARPA Subject: Probe-File and proposed extension. In-reply-to: Msg of 8 Apr 1985 17:38-EST from David A. Moon The point about relative pathnames is the following: When you actually write a file, Open resolves any relative pathname down to an absolute pathname. Any implementation that allows writing relative pathnames must have some way to map the relative pathname to an absolute pathname. This mapping is not necessarily the same as merge pathnames, and in any case, there is no way in Common Lisp to determine what the defaults are. In Spice Lisp, when you open a file for write, Open first looks for any file with that name on the default search list, and if found, overwrites it, otherwise it creates a file in the current directory. I will argue that this is the right semantics in our implementation, and it is clearly implementation dependent. Regardeless of the error issue, it would be useful to be able to default a pathname for output in this fashion. As for the error issue, Spice Lisp currently does exactly what you suggest. A user complained that this was not what the manual said it should do. I tried both the Dec-20 Clisp and the Kyoto Common Lisp implementations, and they both refused to signal errors, no matter what garbage you gave them. I decided at this point that the issue was unclear, but that the Spice Lisp implementation was probably wrong. Rob  Received: from SU-AI.ARPA by MIT-MC.ARPA; 8 APR 85 18:04:14 EST Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 8 Apr 85 14:52:30 PST Received: from SCRC-EUPHRATES by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 211097; Mon 8-Apr-85 17:08:39-EST Date: Mon, 8 Apr 85 17:46 EST From: David A. Moon Subject: error-protected OPEN isn't a good way to fake a probe To: REM@MIT-MC.ARPA cc: COMMON-LISP@SU-AI.ARPA, RAM@CMU-CS-C.ARPA In-Reply-To: SU-IMSSS.REM.A132123230137.G0465 Message-ID: <850408174655.8.MOON@EUPHRATES.SCRC.Symbolics.COM> From: Robert Elton Maas |Date: Mon, 8 Apr 85 14:33 EST |From: David A. Moon |Subject: Probe-File and proposed extension. |To: Rob MacLachlan |cc: common-lisp@SU-AI.ARPA | There needs to be some way to determine whether a file name is | legal for output. |What's wrong with calling OPEN and handling the error when it fails? Since |I don't understand the desired application, I don't know whether my question |makes sense. That's unacceptable. Suppose you have an application program that wants to write two output files (for example, binary and listing output from assembler or compiler) under luser-control (one or both names might be wrong, and this is common enough to protect against in a clean way). The program wants to check both files for validity before opening either. If you handle error when OPEN fails, then if the first name is good and the second bad, by the time you find out the second is bad you have already made the mistake of starting to create the first file when the process can't finish and the file must then be garbage. It is therefore necessary to probe both files before opening either (or at least probe all but one and then error-protected-OPEN the remaining; but probing all of them is cleaner). This is what the :ABORT argument to CLOSE is for.  Received: from SU-AI.ARPA by MIT-MC.ARPA; 8 APR 85 18:00:43 EST Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 8 Apr 85 14:45:43 PST Received: from SCRC-EUPHRATES by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 211090; Mon 8-Apr-85 17:00:45-EST Date: Mon, 8 Apr 85 17:38 EST From: David A. Moon Subject: Probe-File and proposed extension. To: David A. Moon , Rob MacLachlan , greek@DEC-HUDSON.ARPA cc: common-lisp@SU-AI.ARPA In-Reply-To: <850408143305.9.MOON@EUPHRATES.SCRC.Symbolics.COM>, , The message of 8 Apr 85 15:02-EST from greek at DEC-HUDSON, The message of 8 Apr 85 15:05-EST from greek at DEC-HUDSON, , Message-ID: <850408173849.4.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Mon, 8 Apr 85 14:33 EST From: David A. Moon Date: Mon, 8 Apr 1985 10:23 EST From: Rob MacLachlan Query: Should Probe-File never signal an error, even if it is given a namestring which is malformed? No, it should signal lots of errors. Proposal: There needs to be some way to determine whether a file name is legal for output. I brought this issue up once before on this mailing list, but I think the discussion died. I am bringing it up again because we need something of the sort in Spice Lisp, so I am going to implement it. My proposed solution is the following: Probe-File should take a direction argument, which defaults to :input. The semantics of Probe-File would be to return the pathname which would be used if the file was opened in that direction, and to return NIL if the open would fail. What's wrong with calling OPEN and handling the error when it fails? Since I don't understand the desired application, I don't know whether my question makes sense. Answered below. "Common Lisp does not have a standard way to handle errors" is not an acceptable answer. It should get one. Date: Mon, 8 Apr 1985 14:55 EST From: Rob MacLachlan There are circumstances where being able to validate a filename as potentially writable without actually writing that file would be useful. The specific problem I want to solve involves the the "Visit File" command in Hemlock. If you visit a file that exists, you read the file, and the pathname associated with the buffer becomes the truename of the file; no problem there. The question is what do you do if Probe-File of the filename is false? Does this mean that the file simply doesn't exist, or does it mean that the filename is somehow broken? An example of a broken filename would be one with a nonexistant directory or device. If the filename is broken it would be useful to be able to tell the user this when he visits the file, rather than getting some error when he tries to save it. I see. In our implementation, the ambiguous phrase (actually lifted from the old Lisp Machine manual) "if there is no file named" in the documentation of PROBE-FILE is interpreted to mean that only a file-not-found error returns NIL; any other error, such as directory-not-found, host-not-up, name-too-long, etc. is signalled in the normal way. Thus PROBE-FILE serves as a test for whether you'll be able to write the file, assuming you have access to write, the host is still up when you try to write, the disk hasn't filled up by then, etc. Another way of saying this is that PROBE-FILE returns NIL without signalling an error if it would be possible for the file to exist at some future time (well, this is still ambiguous, after all someone could create a directory, rename a device, buy a new computer, or whatever). I think this means that our PROBE-FILE does everything your Visit File command needs. But I see that others could interpret the Common Lisp manual differently. I suppose the manual has to be ambiguous because anything more specific might be unimplementable on some file system! I think it would be better for you to fix your PROBE-FILE (to signal errors other than file-not-found) than to change its arguments to make it optional to do so. It is also useful to be able to get the name of the file that you expect to be created, since then you can set the buffer pathname to that, rather than leaving it a relative pathname until the file is actually created. Agreed. Our understanding is that MERGE-PATHNAMES is how relative pathnames get expanded. The manual doesn't say anything about relative pathnames, but I don't see how anything but MERGE-PATHNAMES could expand them, since they have to be relative to some default. But maybe you mean something different by "relative pathnames" than I; after all, the manual doesn't define the term. I mean pathnames with relative directory names, which start at some default directory in the tree of directories, rather than starting at the root. In Unix, all pathnames that don't start with a slash. Date: Mon, 08 Apr 85 15:02:22 EST From: greek@DEC-HUDSON .... 3. PROBE-FILE needs to tell me more. I want to know if I can't get at the file because: a) the file spec is bad. b) the device doesn't exist. c) the directory doesn't exist. d) I don't have sufficient access privilege. e) etc., etc. The basic need addressed by Rob is a real one: Is this file spec good, can I get to the file, and what can I do to it (read, write, etc). Agreed, but see below. Although I certainly agree that Common LISP needs an error handling facility, I don't want to have to use it to investigate whether or not a file exists. Why not? That's a basic file operation for which we've already attempted to account. Let's fix up the way we do it, not just punt it. Why is using the error-handling facility considered punting? Date: Mon, 8 Apr 1985 15:22 EST From: Rob MacLachlan A while back when bogosity in the file system chapter was being discussed on this list, Moon proposed that :direction :probe be flushed, and everyone seemed to agree. I still think so. It should exist only as an internal implementation detail of PROBE-FILE in some implementations. Date: Mon, 8 Apr 1985 15:33 EST From: Rob MacLachlan The issue of how to get back more information about what is wrong with a file was where we got bogged down before. I think that error systems are the called for when you start to consider that sort of issue. Any enumeration of all the things that can go wrong with writing a file will also probably be hopelessly implementation dependent. I agree. Look at Greek's list above, for example, especially item (e). Unless you can come up with a simple, highly esthetic proposal, I think we should stick with NIL for failure. I suppose we could return an error-message string as a second value, but anything along those lines seems like a sort of half-way measure to me. I don't think a string is what is going to be wanted in many cases, since it is not program-understandable.  Received: from SU-AI.ARPA by MIT-MC.ARPA; 8 APR 85 16:57:42 EST Sent: to SU-AI.ARPA by IMSSS.? via ETHERNET with PUPFTP; 1985-Apr-08 13:38:39 PST (=GMT-8hr) Date: 1985 April 08 13:37:02 PST (=GMT-8hr) Message-id: SU-IMSSS.REM.A132123230137.G0465 From: Robert Elton Maas To:Moon@SCRC-STONY-BROOK.ARPA CC:COMMON-LISP@SU-AI.ARPA,RAM@CMU-CS-C.ARPA Subject: error-protected OPEN isn't a good way to fake a probe Sender: REM%IMSSS@SU-SCORE.ARPA (for undeliverable-mail notifications) Reply-to: REM@MIT-MC.ARPA |Date: Mon, 8 Apr 85 14:33 EST |From: David A. Moon |Subject: Probe-File and proposed extension. |To: Rob MacLachlan |cc: common-lisp@SU-AI.ARPA | There needs to be some way to determine whether a file name is | legal for output. |What's wrong with calling OPEN and handling the error when it fails? Since |I don't understand the desired application, I don't know whether my question |makes sense. That's unacceptable. Suppose you have an application program that wants to write two output files (for example, binary and listing output from assembler or compiler) under luser-control (one or both names might be wrong, and this is common enough to protect against in a clean way). The program wants to check both files for validity before opening either. If you handle error when OPEN fails, then if the first name is good and the second bad, by the time you find out the second is bad you have already made the mistake of starting to create the first file when the process can't finish and the file must then be garbage. It is therefore necessary to probe both files before opening either (or at least probe all but one and then error-protected-OPEN the remaining; but probing all of them is cleaner).  Received: from SU-AI.ARPA by MIT-MC.ARPA; 8 APR 85 15:43:17 EST Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 8 Apr 85 12:33:59 PST Received: ID ; Mon 8 Apr 85 15:33:19-EST Date: Mon, 8 Apr 1985 15:33 EST Message-ID: From: Rob MacLachlan To: greek@DEC-HUDSON.ARPA Cc: common-lisp@SU-AI.ARPA Subject: PROBE-FILE In-reply-to: Msg of 8 Apr 1985 15:02-EST from greek at DEC-HUDSON The issue of how to get back more information about what is wrong with a file was where we got bogged down before. I think that error systems are the called for when you start to consider that sort of issue. Any enumeration of all the things that can go wrong with writing a file will also probably be hopelessly implementation dependent. Unless you can come up with a simple, highly esthetic proposal, I think we should stick with NIL for failure. I suppose we could return an error-message string as a second value, but anything along those lines seems like a sort of half-way measure to me. Rob  Received: from SU-AI.ARPA by MIT-MC.ARPA; 8 APR 85 15:32:27 EST Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 8 Apr 85 12:22:46 PST Received: ID ; Mon 8 Apr 85 15:22:27-EST Date: Mon, 8 Apr 1985 15:22 EST Message-ID: From: Rob MacLachlan To: greek@DEC-HUDSON.ARPA Cc: common-lisp@SU-AI.ARPA Subject: PROBE-FILE In-reply-to: Msg of 8 Apr 1985 15:02-EST from greek at DEC-HUDSON A while back when bogosity in the file system chapter was being discussed on this list, Moon proposed that :direction :probe be flushed, and everyone seemed to agree. Rob  Received: from SU-AI.ARPA by MIT-MC.ARPA; 8 APR 85 15:19:57 EST Received: from DEC-HUDSON.ARPA by SU-AI.ARPA with TCP; 8 Apr 85 12:08:25 PST Date: Mon, 08 Apr 85 15:02:22 EST From: greek@DEC-HUDSON Subject: PROBE-FILE To: common-lisp@su-ai Rob's proposal makes sense. A few comments: 1. Yup, use a keyword, namely :DIRECTION. 2. If we believe in :DIRECTION for PROBE-FILE, then we have to admit that :DIRECTION :PROBE makes no sense for OPEN, because probing is orthogonal to direction. I suggest we either add :PROBE T as another keyword to OPEN, or, better yet, remove the feature from OPEN. 3. PROBE-FILE needs to tell me more. I want to know if I can't get at the file because: a) the file spec is bad. b) the device doesn't exist. c) the directory doesn't exist. d) I don't have sufficient access privilege. e) etc., etc. The basic need addressed by Rob is a real one: Is this file spec good, can I get to the file, and what can I do to it (read, write, etc). - Paul  Received: from SU-AI.ARPA by MIT-MC.ARPA; 8 APR 85 15:17:19 EST Received: from DEC-HUDSON.ARPA by SU-AI.ARPA with TCP; 8 Apr 85 12:07:56 PST Date: Mon, 08 Apr 85 15:05:05 EST From: greek@DEC-HUDSON Subject: More on PROBE-FILE. To: common-lisp@su-ai Just got Dave Moon's message about Rob's proposal for PROBE-FILE. Although I certainly agree that Common LISP needs an error handling facility, I don't want to have to use it to investigate whether or not a file exists. That's a basic file operation for which we've already attempted to account. Let's fix up the way we do it, not just punt it. - Paul  Received: from SU-AI.ARPA by MIT-MC.ARPA; 8 APR 85 15:08:23 EST Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 8 Apr 85 11:56:07 PST Received: ID ; Mon 8 Apr 85 14:55:43-EST Date: Mon, 8 Apr 1985 14:55 EST Message-ID: From: Rob MacLachlan To: "David A. Moon" Cc: common-lisp@SU-AI.ARPA Subject: Probe-File and proposed extension. In-reply-to: Msg of 8 Apr 1985 14:33-EST from David A. Moon There are circumstances where being able to validate a filename as potentially writable without actually writing that file would be useful. The specific problem I want to solve involves the the "Visit File" command in Hemlock. If you visit a file that exists, you read the file, and the pathname associated with the buffer becomes the truename of the file; no problem there. The question is what do you do if Probe-File of the filename is false? Does this mean that the file simply doesn't exist, or does it mean that the filename is somehow broken? An example of a broken filename would be one with a nonexistant directory or device. If the filename is broken it would be useful to be able to tell the user this when he visits the file, rather than getting some error when he tries to save it. It is also useful to be able to get the name of the file that you expect to be created, since then you can set the buffer pathname to that, rather than leaving it a relative pathname until the file is actually created. Rob  Received: from SU-AI.ARPA by MIT-MC.ARPA; 8 APR 85 14:45:24 EST Received: from [18.26.0.206] by SU-AI.ARPA with TCP; 8 Apr 85 11:34:38 PST Received: from WAIKATO by ZERMATT via CHAOS with CHAOS-MAIL id 2202; Mon 8-Apr-85 14:32:39-EST Received: from SCRC-EUPHRATES by WAIKATO via CHAOS with CHAOS-MAIL id 91565; Mon 8-Apr-85 14:32:07-EST Date: Mon, 8 Apr 85 14:33 EST From: David A. Moon Subject: Probe-File and proposed extension. To: Rob MacLachlan cc: common-lisp@SU-AI.ARPA In-Reply-To: Message-ID: <850408143305.9.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Mon, 8 Apr 1985 10:23 EST From: Rob MacLachlan Query: Should Probe-File never signal an error, even if it is given a namestring which is malformed? Proposal: There needs to be some way to determine whether a file name is legal for output. I brought this issue up once before on this mailing list, but I think the discussion died. I am bringing it up again because we need something of the sort in Spice Lisp, so I am going to implement it. My proposed solution is the following: Probe-File should take a direction argument, which defaults to :input. The semantics of Probe-File would be to return the pathname which would be used if the file was opened in that direction, and to return NIL if the open would fail. What's wrong with calling OPEN and handling the error when it fails? Since I don't understand the desired application, I don't know whether my question makes sense. "Common Lisp does not have a standard way to handle errors" is not an acceptable answer. It should get one. Secondary query: Should the direction argument be a keyword or an optional? I favor an optional, since I can't think of any other arguments that want to be added to Probe-File. I can think of two other arguments right off the bat; make it a keyword.  Received: from SU-AI.ARPA by MIT-MC.ARPA; 8 APR 85 11:31:30 EST Received: from [10.4.0.6] by SU-AI.ARPA with TCP; 8 Apr 85 08:16:26 PST Received: by Think.ARPA with CHAOS id AA14362; Mon, 8 Apr 85 11:13:45 est Date: Mon, 8 Apr 85 11:16 EST From: Guy Steele Subject: NIL and DEFCONSTANT [Gall: Bug Report] To: Gall%MULTICS.MIT@Think Cc: common-lisp@SU-AI.ARPA, gls%AQUINAS.TMC@Think In-Reply-To: Maybe a right attitude to take is that it is an error to execute any compiled code that refers to a DEFCONSTANT'ed name that has been re-DEFCONSTANT'ed to a different (non-EQL?) value since the code was compiled. That would say that it is okay to (DEFCONSTANT T 43), but then you had better not execute any system code that refers to T. But the evaluator probably refers to T, so in practice you had simply better not do it. --Guy  Received: from SU-AI.ARPA by MIT-MC.ARPA; 8 APR 85 10:32:27 EST Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 8 Apr 85 07:23:33 PST Received: ID ; Mon 8 Apr 85 10:23:37-EST Date: Mon, 8 Apr 1985 10:23 EST Message-ID: From: Rob MacLachlan To: common-lisp@SU-AI.ARPA Subject: Probe-File and proposed extension. Query: Should Probe-File never signal an error, even if it is given a namestring which is malformed? Proposal: There needs to be some way to determine whether a file name is legal for output. I brought this issue up once before on this mailing list, but I think the discussion died. I am bringing it up again because we need something of the sort in Spice Lisp, so I am going to implement it. My proposed solution is the following: Probe-File should take a direction argument, which defaults to :input. The semantics of Probe-File would be to return the pathname which would be used if the file was opened in that direction, and to return NIL if the open would fail. Secondary query: Should the direction argument be a keyword or an optional? I favor an optional, since I can't think of any other arguments that want to be added to Probe-File. Rob  Received: from SU-AI.ARPA by MIT-MC.ARPA; 7 APR 85 23:33:43 EST Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 7 Apr 85 20:26:39 PST Received: ID ; Sun 7 Apr 85 23:26:32-EST Date: Sun, 7 Apr 1985 23:26 EST Message-ID: Sender: FAHLMAN@CMU-CS-C.ARPA From: "Scott E. Fahlman" To: Rem @ MIT-MC.ARPA Cc: COMMON-LISP@SU-AI.ARPA Subject: Any complete CL implementations?? In-reply-to: Msg of 5 Apr 1985 15:24-EST from Rem at IMSSS Our CMU version of Common Lisp on the Perq is essentially complete except for complex numbers. These have now been coded, and will probably be added to our system this week. By "essentially complete", I mean that nothing big is missing, though from time to time we discover that something has slipped through the cracks. CCASE and CTYPECASE are still among the missing, I think. I cannot claim that our system is believed to be a 100% complete and correct implementation. A number of bugs have been discovered and not yet fixed, and the whole system is in need of a systematic testing. A number of companies have started with our code and have had a lot more manpower for testing and fixing, so I wouldn't be surprised if a number of implementations are as complete as ours and a good deal more polished. There is not much reason for anyone following this route to end up with a less-than-complete Common Lisp -- once the basics are up, we can hand them the code for the rest. It is usually the implementations that try to bend some existing Lisp into a Common Lisp that end up stuck at 90% compatibility. -- Scott  Received: from SU-AI.ARPA by MIT-MC.ARPA; 5 APR 85 20:50:08 EST Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 5 Apr 85 17:40:48 PST Received: from RUTGERS.ARPA by SU-SCORE.ARPA with TCP; Fri 5 Apr 85 17:40:02-PST Date: 5 Apr 85 20:39:53 EST From: Charles Hedrick Subject: Re: Any complete CL implementations?? To: rem%imsss@SU-SCORE.ARPA cc: COMMON-LISP%SU-AI@SU-SCORE.ARPA In-Reply-To: Message from "Rem@IMSSS" of 5 Apr 85 15:24:00 EST It is very hard to evaluation how much is finished, as there is no evaluation suite. We have an implementation for TOPS-20, based on the CMU Spice Lisp implementation. Here are the known bugs and omissions, but it is certainly possible that there are things we don't know about. This prefixed by * will be fixed fairly soon. *Supposedly the same args can be used for &rest and &key. This fails (in interpreted code only; the compiler can handle this). Complex numbers are not implemented. When doing file-position, and maybe clrbfo and clrbfi, maybe we should clear lookahead and other status. Fix GRINDEF of macros to reproduce the DEFMACRO format, instead of using the undocumented MACRO format. Fix ` to produce a macro instead of expanding at read time. That way GRINDEF can print them properly. It should be possible to continue after a break initiated by ^B. Printing of circular objects is not implemented. INSPECT is not really implemented. RANDOM don't seem very hot: There seems to be too many repeated values. Maybe this is word-size dependent or something. Use | | instead of slashification in printing atom names. Missing :copier option for defstruct Missing &environment option for defmacro In Arith, function that could benefit from handcoding: dramatic benefit: floor, ceiling, round, mod, logcount some benefit: rem, ffloor, fceiling, ftruncate, fround RATIONALIZE is currently the same as RATIONAL. Compiler can't handle closures. Programs will work, but functions requiring closures will be interpreted. Missing DEFTYPE *READ barfs when CL:CLISP is typed in. *TRUNCATE doesn't return correct remainders for some values. Eg, -0.7 and -0.3. -------  Received: from SU-AI.ARPA by MIT-MC.ARPA; 5 APR 85 15:35:25 EST Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 5 Apr 85 12:27:01 PST Received: from IMSSS by Score with Pup; Fri 5 Apr 85 12:26:35-PST Date: 5 Apr 1985 1224-PST From: Rem@IMSSS Subject: Any complete CL implementations?? To: COMMON-LISP%SU-AI@SCORE At this time, has anybody completely 100% implemented Common LISP on any machine at all? I mean every single function in the manual without exception, every single feature in the manual (either as documented in manual or as amended more recently for next edition) for each such function, and every general capability such as all datatypes and closures of lexical variabls etc. etc.? If not, what is the best anybody has done to date? Would anybody with at least 50% of Common LISP (by some reasonable way of measuring) please send me a brief description of their implementation (CPU and operating system, % of CL implemented, list of major capabilities not implemented yet) for my curiosity? SCORE's mailbridge doesn't put correct return address, so reply via any of: Local on IMSSS: REM Anywhere on SU-NET with PUPMAIL: REM@IMSSS Anywhere on Arpanet: REM%IMSSS@SCORE Anywhere else on TCP/IP Arpa-Internet: REM@MIT-MC.ARPA (forwards to IMSSS) -------  Received: from SU-AI.ARPA by MIT-MC.ARPA; 5 APR 85 14:17:19 EST Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 5 Apr 85 11:06:46 PST Received: from SCRC-EUPHRATES by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 209748; Fri 5-Apr-85 14:04:36-EST Date: Fri, 5 Apr 85 14:06 EST From: David A. Moon Subject: Intern To: Scott E. Fahlman cc: common-lisp@SU-AI.ARPA In-Reply-To: Message-ID: <850405140606.9.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Thu, 4 Apr 1985 23:42 EST From: "Scott E. Fahlman" OK, I'd like to end this Intern nonsense before my mailbox overflows. Could everyone live with the following: 1. Intern never messes with the Symbol-Package cell. 2. Import fills in the symbol's Symbol-Package cell with the importing package if that cell is NIL. 3. In the next edition of the manual we fix up the description of symbols being "interned in a package" either by flushing this whole concept or by finding a more precise term for it. If we do all of that, I don't think it is redundant to add a Setf for Symbol-Package (with a check that the symbol is accessible in its home package), but I wouldn't fight to the death if people wanted to include this mechanism as well. I would fight an attempt to add a non-checking Setf of Symbol-Package. This is fine with me. Hey, I don't even have to make any changes in my implementation to conform to this clarified specification!  Received: from SU-AI.ARPA by MIT-MC.ARPA; 5 APR 85 00:22:13 EST Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 4 Apr 85 20:56:47 PST Received: ID ; Thu 4 Apr 85 23:56:22-EST Date: Thu, 4 Apr 1985 23:56 EST Message-ID: Sender: FAHLMAN@CMU-CS-C.ARPA From: "Scott E. Fahlman" To: Nick Gall Cc: common-lisp@SU-AI.ARPA Subject: NIL and DEFCONSTANT [Gall: Bug Report] In-reply-to: Msg of 3 Apr 1985 23:52-EST from Nick Gall I agree with Moon also. And I agree that pg. 56 is ok too. It is pg. 69 that is a little shaky, and pg. 324 DEFINITELY states that NIL and T are defined with DEFCONSTANT. OK, we all agree that it is an error to redefine built-in constants, whether or not we think of them as having been created by defconstant. The manual should be made consistent on this point. -- Scott  Received: from SU-AI.ARPA by MIT-MC.ARPA; 4 APR 85 23:55:34 EST Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 4 Apr 85 20:46:35 PST Received: ID ; Thu 4 Apr 85 23:46:36-EST Date: Thu, 4 Apr 1985 23:46 EST Message-ID: Sender: FAHLMAN@CMU-CS-C.ARPA From: "Scott E. Fahlman" To: common-lisp@SU-AI.ARPA Subject: Minor correction Where I spoke of allowing SETF of Symbol-Package with a check for accessibility of the symbol in that package, I should have said "presence" of the symbol. -- Scott  Received: from SU-AI.ARPA by MIT-MC.ARPA; 4 APR 85 23:51:16 EST Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 4 Apr 85 20:42:07 PST Received: ID ; Thu 4 Apr 85 23:42:03-EST Date: Thu, 4 Apr 1985 23:42 EST Message-ID: Sender: FAHLMAN@CMU-CS-C.ARPA From: "Scott E. Fahlman" To: common-lisp@SU-AI.ARPA Subject: Intern OK, I'd like to end this Intern nonsense before my mailbox overflows. Could everyone live with the following: 1. Intern never messes with the Symbol-Package cell. 2. Import fills in the symbol's Symbol-Package cell with the importing package if that cell is NIL. 3. In the next edition of the manual we fix up the description of symbols being "interned in a package" either by flushing this whole concept or by finding a more precise term for it. If we do all of that, I don't think it is redundant to add a Setf for Symbol-Package (with a check that the symbol is accessible in its home package), but I wouldn't fight to the death if people wanted to include this mechanism as well. I would fight an attempt to add a non-checking Setf of Symbol-Package. -- Scott  Received: from SU-AI.ARPA by MIT-MC.ARPA; 4 APR 85 21:24:51 EST Received: from MIT-MULTICS.ARPA by SU-AI.ARPA with TCP; 4 Apr 85 18:12:27 PST Date: Thu, 4 Apr 85 21:06 EST From: Nick Gall Subject: Re: INTERN and "intern" -- the unwise choice of terminology To: common-lisp@SU-AI.ARPA In-Reply-To: Message of 4 Apr 85 10:42 EST from "Rob MacLachlan" Message-ID: <850405020617.786913@MIT-MULTICS.ARPA> Date: 4 April 1985 10:42 est From: Rob MacLachlan Subject: INTERN and "intern" -- the unwise choice of terminology I don't think that a home-package-setting operation is well defined, at least without some constraints. The system would certainly get confused if you set the home package to a package that the symbol was not accessible in, and it would be dubious to set the home package to a package where the symbol is not present (as opposed to inherited). If you impose these requirements, setting the home package starts to sound a great deal like IMPORT. I think that the proposal to have IMPORT set the home package if there is none makes a great deal of sense. The effect of IMPORT is really about the same as old-style intern on a symbol. I don't really like the idea of INTERN having obscure side-effects such as setting the home package, since it is something that the system often does without an explicit request. Rob I prefer this proposal to White's `setf with constraints' proposal.  Received: from SU-AI.ARPA by MIT-MC.ARPA; 4 APR 85 17:30:41 EST Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 4 Apr 85 14:21:59 PST Received: ID ; Thu 4 Apr 85 17:21:24-EST Date: Thu, 4 Apr 1985 17:21 EST Message-ID: From: Rob MacLachlan To: Jon White Cc: common-lisp@SU-AI.ARPA, gall@MIT-MULTICS.ARPA, moon@SCRC-STONY-BROOK.ARPA Subject: "home-ifying" symbols In-reply-to: Msg of 4 Apr 1985 16:45-EST from Jon White I would consider the system very confused if a symbol which appears to be interned does not print readably when no package system changes have been made between the printing and the reading. This could happen if a symbol is not accessible in its home package. It would be reasonable to allow setf on symbol-package with the constraint that the new value may only be a package that the symbol is present in. I have survived until now without this capability, but won't object to its addition to the language, since opposing any feature would not be in the spirit of Common Lisp. Rob  Received: from SU-AI.ARPA by MIT-MC.ARPA; 4 APR 85 17:04:28 EST Date: 04 Apr 85 1345 PST From: Jon White Subject: "home-ifying" symbols To: ram@CMU-CS-C.ARPA CC: gall@MIT-MULTICS.ARPA, moon@SCRC-STONY-BROOK.ARPA, common-lisp@SU-AI.ARPA Several people, yourself included, have suggested that if a luser sets a symbol's package cell to something random then "the system will get very confused". How? The package cell seems to affect *nothing* in the system except print, and there is nothing particularly confusing about the fact that print will want to 1) certify either a nil or a package in that cell, and 2) output a #: prefix if it was nil. Given the current capabilities of unintern, there seems to be no way to avoid the so-called pathalogical situation wherein a symbol is "homed" nowhere, yet accessible from one or more packages [shall we call such a non-homed symbol a "bastard" since no one "owns" it?] The problem with trying to insure the existence of a home through side-effects in INTERN and/or IMPORT is that that doesn't address the issue that's been galling us all along. Namely, a symbol is present in several packages, and owned by one of them; but the luser decides that it is homed * in the wrong package * and he wishes to change it. How about having a set-symbol-package capablity which certifies that the symbol is at least present in the package that it is being "homed" in? Would that satisfy your feeling for constraints? -- JonL -- P.S. Two uses of "certify" above mean "run a cerror if condition not met".  Received: from SU-AI.ARPA by MIT-MC.ARPA; 4 APR 85 14:16:24 EST Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 4 Apr 85 11:03:50 PST Received: from SCRC-EUPHRATES by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 209032; Thu 4-Apr-85 13:56:10-EST Date: Thu, 4 Apr 85 13:57 EST From: David A. Moon Subject: INTERN and "intern" -- the unwise choice of terminology To: Rob MacLachlan cc: Jon White , Common-Lisp@SU-AI.ARPA, Gall@MIT-MULTICS.ARPA In-Reply-To: Message-ID: <850404135733.2.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Thu, 4 Apr 1985 10:42 EST From: Rob MacLachlan I don't think that a home-package-setting operation is well defined, at least without some constraints. The system would certainly get confused if you set the home package to a package that the symbol was not accessible in, and it would be dubious to set the home package to a package where the symbol is not present (as opposed to inherited). If you impose these requirements, setting the home package starts to sound a great deal like IMPORT. I think that the proposal to have IMPORT set the home package if there is none makes a great deal of sense. The effect of IMPORT is really about the same as old-style intern on a symbol. I don't really like the idea of INTERN having obscure side-effects such as setting the home package, since it is something that the system often does without an explicit request. This message makes sense to me.  Received: from SU-AI.ARPA by MIT-MC.ARPA; 4 APR 85 11:01:21 EST Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 4 Apr 85 07:50:02 PST Received: ID ; Thu 4 Apr 85 10:43:06-EST Date: Thu, 4 Apr 1985 10:42 EST Message-ID: From: Rob MacLachlan To: Jon White Cc: Common-Lisp@SU-AI.ARPA, Gall@MIT-MULTICS.ARPA, Moon@SCRC-STONY-BROOK.ARPA Subject: INTERN and "intern" -- the unwise choice of terminology In-reply-to: Msg of 3 Apr 1985 15:26-EST from Jon White I don't think that a home-package-setting operation is well defined, at least without some constraints. The system would certainly get confused if you set the home package to a package that the symbol was not accessible in, and it would be dubious to set the home package to a package where the symbol is not present (as opposed to inherited). If you impose these requirements, setting the home package starts to sound a great deal like IMPORT. I think that the proposal to have IMPORT set the home package if there is none makes a great deal of sense. The effect of IMPORT is really about the same as old-style intern on a symbol. I don't really like the idea of INTERN having obscure side-effects such as setting the home package, since it is something that the system often does without an explicit request. Rob  Received: from SU-AI.ARPA by MIT-MC.ARPA; 4 APR 85 00:23:28 EST Received: from MIT-MULTICS.ARPA by SU-AI.ARPA with TCP; 3 Apr 85 21:08:48 PST Posted-Date: 4 Apr 85 00:07 EST Date: Thu, 4 Apr 85 00:05 EST From: Nick Gall Subject: Re: What should CLOSE return? To: REM@MIT-MC.ARPA cc: common-lisp@SU-AI.ARPA In-Reply-To: Message of 3 Apr 85 03:29 EST from "Network_Server.Daemon (REM@IMSSS@SU-AI.ARPA)" Message-ID: <850404050502.925392@MIT-MULTICS.ARPA> Date: 3 April 1985 03:29 est From: Network_Server.Daemon (REM@IMSSS@SU-AI.ARPA) Return-Path: <@MIT-MULTICS.ARPA,@SU-AI.ARPA:REM@IMSSS> Received: from SU-AI.ARPA by MIT-MULTICS.ARPA TCP; 03-Apr-1985 03:28:38-est Sent: to SU-AI.ARPA by IMSSS.? via ETHERNET with PUPFTP; 1985-Apr-03 00:23:00 PST (=GMT-8hr) Date: 1985 April 02 18:50:35 PST (=GMT-8hr) Message-id: SU-IMSSS.REM.A132116072744.G0366 From: Robert Elton Maas To:Gall@MIT-MULTICS.ARPA Subject:attempt to bind constant, what should CLOSE return Sender: REM%IMSSS@SU-SCORE.ARPA (for undeliverable-mail notifications) Reply-to: REM@MIT-MC.ARPA > Date: Thu, 21 Mar 85 00:49 EST > From: Nick Gall > > From: Robert Elton Maas > Subject: What should CLOSE return? Closed-channel-object, or truefilename. > > > !topic What does CLOSE Return? > > > > I think it should return the STREAM it was given to close. This > > would make it symmetric with OPEN: OPEN returns an open stream, > > CLOSE returns a closed stream. > That's not symmetric, that's coercive. OPEN and CLOSE are like > matching parenthesis, one does it and the other undos it except for > a residual side-effect. ... > > You're right `symmetric' is the wrong adj. But I still think CLOSE should > return the (closed) stream. It can't (always) return the truename > of the file associated with the stream, since not all streams are > associated with files. It's a matter of opinion as to what "should" be returned, and if there's any use for the closed stream that couldn't be obtained by retaining a pointer to the original open stream and using that pointer after the CLOSE has been done, then I'll agree with you. But usually a closed stream is just an open stream that has been modified in place to be closed, in which case anyone wanting the closed stream can just as well retain the old pointer instead of expecting that CLOSE will return it back to you. On the other hand, if a system doesn't assign a version number until the moment a file is closed, and if there's no particular reason to need CLOSE to return the closed stream, then it should return the true filename to save the user the hassle of getting that info itself. You still haven't said what close should return when the stream being closed is NOT a file stream (e.g., closing a string stream). Note that the CLOSE function is in the chapter on streams NOT the file system interface chapter. > To obtain the truename of a just closed file, one could write > (truename (close x)) ; where x is bound to a file stream > since truename will take a stream as an argument. (Unfortunately, > the CLRM (23.1.2(5)) is only explicit about what truename does > with an `open' stream.) Clearly something needs to be change, either force truename to work on closed streams, telling the true name that couldn't have been known for sure while the file was still open, or having CLOSE return the true filename as I suggested. Agreed.  Received: from SU-AI.ARPA by MIT-MC.ARPA; 4 APR 85 00:14:31 EST Received: from MIT-MULTICS.ARPA by SU-AI.ARPA with TCP; 3 Apr 85 21:05:18 PST Date: Wed, 3 Apr 85 23:52 EST From: Nick Gall Subject: Re: NIL and DEFCONSTANT [Gall: Bug Report] To: "Scott E. Fahlman" cc: "David A. Moon" , common-lisp@SU-AI.ARPA In-Reply-To: Message of 2 Apr 85 23:14 EST from "Scott E. Fahlman" Message-ID: <850404045222.726223@MIT-MULTICS.ARPA> Date: 2 April 1985 23:14 est From: Scott E. Fahlman Subject: NIL and DEFCONSTANT [Gall: Bug Report] I agree with Moon that it "is an error" to redefine built-in constants. It probably is not required that an implementation stop you from doing this, but it would be a good idea. I think that the description on page 56 is OK as it is. First it says that there are built-in named constants that you don't get to change. Here it talks about such things as T and NIL. Then it says that "constant symbols defined by Defconstant" are also treated this way, but that they may be redefined if necessary by using Defconstant again. I don't see anything that would imply that T and NIL are implicitly defined by Defconstant and that they are therefore redefinable. -- Scott I agree with Moon also. And I agree that pg. 56 is ok too. It is pg. 69 that is a little shaky, and pg. 324 DEFINITELY states that NIL and T are defined with DEFCONSTANT.  Received: from SU-AI.ARPA by MIT-MC.ARPA; 3 APR 85 23:53:50 EST Received: from MIT-MULTICS.ARPA by SU-AI.ARPA with TCP; 3 Apr 85 20:43:01 PST Posted-Date: 3 Apr 85 23:42 EST Date: Wed, 3 Apr 85 23:38 EST From: Nick Gall Subject: Re: INTERN [Gall: Bug Report] To: "Scott E. Fahlman" cc: "David A. Moon" , common-lisp@SU-AI.ARPA In-Reply-To: Message of 2 Apr 85 23:01 EST from "Scott E. Fahlman" Message-ID: <850404043851.615892@MIT-MULTICS.ARPA> Date: 2 April 1985 23:01 est From: Scott E. Fahlman Subject: INTERN [Gall: Bug Report] This concerns the recent exchange between Moon and Gall on how INTERN should handle home packages. I will refrain from including all previous context. Unfortunately, I read most of this mail on an 80-column screen and if things get nested too deeply, each line starts on the next line. First, let me say that this is probably not of world-shaking importance. Home packages are just a convenience for the printer, so that if a symbol isn't accessible in the current package, it can (usually) either tell you some package where the symbol is accessible or flag the cases in which a symbol is not accessible in any package. It is true that by clever use of Unintern you can manage to create an accessible sysmbol with no recorded home package. Unintern also allows you to screw yourself in lots of other ways if you work hard at it. Yawn! Having said that, it seems to me that Gall's original reading of the manual is as reasonable as any other. This says that if Intern finds an acessible symbol that has no home (as opposed to creating a new symbol), it should bash the Symbol-Package cell to the value of the package in which it is doing the interning. It is too much work to make sure that every symbol that is accessible in any package always has a home package, but when we trip over an anomalous case like this, we may as well fix it. It seems intuitive that Intern should return a symbol that is "interned", in the sense of being accessible and having a home. Moon grants that this might be a reasonable implementation, but then comments that implementing this might be expensive. I don't see where the expense would be. If Intern creates a symbol, it sets the home package; if Intern finds a symbol whose package cell is NIL, it again sets the home package. Checking the home package for nillity is a tiny expense compared to the hash-table lookups, etc. The sentence on page 172 should more properly say "when a STRING is interned in a package...", since as Moon points out you cannot intern a symbol directly. However, I think that this passage makes sense despite this, if you make the reasonable assumption that the "symbol" referred to here is either the one that is created or the already accessible symbol that is found, as the case may be. We decided not to allow users to use SETF on Symbol-Package, since there seemed to be no good use for this and since by diddling around with this you can create some very confusing situations. -- Scott I agree with you completely. I disagree with the recommendations given by Jon L. White: 1) pick some other word to use in place of "interned" to describe the state so laboriously depicted on page 172, so that the reader is not tempted to jump to the conclusion that it is coextensive with INTERN'd 2) Introduce the user-level operation for modifying a symbol's package "cell" [its home package]. As Nick has already pointed out, the current design doesn't prevent one from damageing that cell, by injudicious use of UNINTERN and/or IMPORT; and worse yet, it doesn't provide any way to say precisely what you mean when you want to change its home [which is different from merely IMPORTing it somewhere]. Since the CLRM already implies that INTERN may clobber the package cell of an accessible symbol (an inexpensive operation) isn't it simpler (and cleaner) to merely state it explicitly in the def. of INTERN (pg.184), instead of changing pg. 172 AND inventing a WHOLE NEW user-level operation (and a dangerous one at that)?  Received: from SU-AI.ARPA by MIT-MC.ARPA; 3 APR 85 21:54:19 EST Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 3 Apr 85 18:45:46 PST Date: 3 April 1985 21:45-EST From: Kjeld Hvatum To: Fahlman @ CMU-CS-C cc: common-lisp @ SU-AI Date: 04/03/85 From: Steve Bacher To: "Scott E. Fahlman" Subject: INTERN (Gall: Bug Report) (Note: Please forgive absence of square brackets - I'm an IBM user.) We decided not to allow users to use SETF on Symbol-Package, since there seemed to be no good use for this and since by diddling around with this you can create some very confusing situations. It seems to me that this might be construed as a violation of the LISP (hacker?) ethic, which provides the user with the ability to manipulate his/her environment any which way {s}he wishes. Not that CL is required to provide every tool in the book, especially since it's straightforward enough to do your own DEFSETF for a (SETF SYMBOL-PACKAGE ...) construct, but the above reasoning seems a mite feeble, especially considering the degree of bashing that *is* permitted by CL. You should keep in mind that users have a way of discovering the most amazing uses for features that originated as afterthoughts or oversights. To say that users should be protected from nonfunctionality and/or self-confusion runs counter to all that I have been led to believe.  Received: from SU-AI.ARPA by MIT-MC.ARPA; 3 APR 85 21:53:22 EST Received: from SCRC-QUABBIN.ARPA by SU-AI.ARPA with TCP; 3 Apr 85 18:43:20 PST Received: from SCRC-EUPHRATES by SCRC-QUABBIN via CHAOS with CHAOS-MAIL id 150291; Wed 3-Apr-85 21:39:57-EST Date: Wed, 3 Apr 85 21:43 EST From: David A. Moon Subject: INTERN and "intern" -- the unwise choice of terminology To: Jon White cc: Gall@MIT-MULTICS.ARPA, Common-Lisp@SU-AI.ARPA In-Reply-To: The message of 3 Apr 85 15:26-EST from Jon White Message-ID: <850403214317.6.MOON@EUPHRATES.SCRC.Symbolics.COM> I agree completely with the enclosed message from Jon L. Date: 03 Apr 85 1226 PST From: Jon White I believe the confusion over the interning-an-unowned-symbol stems from the misleading use of the verb "intern" on page 172, and I think I'd rather see that part of the documentation fixed than have any change in th semantics of INTERN, UNINTERN, and/or IMPORT. The state of being "interned" clearly requires the symbol to be owned; and the penultimate paragraph of the introductory to chapter 11 says "this process [interning] is performed by the function INTERN." For these reasons, one might be tempted to agree with Nick that every call to INTERN results in an interned symbol; yet the definition of INTERN rather implies that when a symbol is already accessible [note well: "accessible", not "interned"] it is merely returned, without the modification to the home package outlined for the case of when "no such symbol is found". My recommendations are quite straightforward: 1) pick some other word to use in place of "interned" to describe the state so laboriously depicted on page 172, so that the reader is not tempted to jump to the conclusion that it is coextensive with INTERN'd 2) Introduce the user-level operation for modifying a symbol's package "cell" [its home package]. As Nick has already pointed out, the current design doesn't prevent one from damageing that cell, by injudicious use of UNINTERN and/or IMPORT; and worse yet, it doesn't provide any way to say precisely what you mean when you want to change its home [which is different from merely IMPORTing it somewhere].  Received: from SU-AI.ARPA by MIT-MC.ARPA; 3 APR 85 20:57:31 EST Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 3 Apr 85 17:49:35 PST Received: from Salvador.ms by ArpaGateway.ms ; 03 APR 85 17:49:37 PST Date: 3 Apr 85 17:49 PST From: Masinter.pa@XEROX.ARPA Subject: Re: SPECIAL FUNCTION NAME [Gall: Bug Report] In-reply-to: Jonathan A Rees 's message of 2 Apr 85 16:26 EST To: common-lisp@SU-AI.ARPA "For this particular application, though, isn't the right thing just to set up a separate package?..." Not if you ever had some other function which called (exit). The intent is to wall off the functionality, not the names.  Received: from SU-AI.ARPA by MIT-MC.ARPA; 3 APR 85 19:09:40 EST Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 3 Apr 85 15:47:58 PST Received: from SCRC-CONCORD by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 208449; Wed 3-Apr-85 18:47:06-EST Date: Wed, 3 Apr 85 18:48 EST From: Bernard S. Greenberg Subject: Re: Arg count checking To: masinter.pa@XEROX.ARPA, bug-1100@SUMEX-AIM.ARPA cc: common-lisp@SU-AI.ARPA In-Reply-To: The message of 1 Apr 85 04:00-EST from masinter.pa@XEROX.ARPA Message-ID: <850403184831.0.BSG@CONCORD.SCRC.Symbolics.COM> Fonts: CPTFONT, CPTFONTI Date: 1 Apr 85 01:00 PST From: masinter.pa@XEROX.ARPA All of these are instances where the CALLER knows the args are optional. I can imagine (not very seriously) a separate syntax for that, e.g., put the &OPTIONAL on the caller rather than the callee: (FOO 1 2 &OPTIONAL T) which says to call FOO with 2 arguments, and throw away the third if FOO only takes two arguments, but otherwise pass it all three. I have needed this some number of times; it has been discussed locally around here some, but to no end. Specifically, I had a function "A" with a functional argument. A's contract includes not only its own argument list, but the set of arguments with which it calls its functional argument. Some callees are not interested in all of the things that A passes them. The callees can &REST IGNORE the uninteresting arguments, or declare the arguments and ignore them. I (and not many others) see a true lack of symmetry with ordinary optional arguments. The whole reason &OPTIONAL exists is so that a caller need not have or show knowledge of arguments in which he is not interested: not have dummy variables, or have to give their name or number. Every such argument[English,not Lisp] can be applied equally well to the functional callees of functions accepting functional arguments.  Received: from SU-AI.ARPA by MIT-MC.ARPA; 3 APR 85 18:29:20 EST Date: 03 Apr 85 1502 PST From: Jon White Subject: Assymetry between argument-passing and value-returning To: common-lisp@SU-AI.ARPA In view of the recent semi-suggestions that the logical similarity between argument passing and value receiving be institutionalized in Common Lisp, perhaps we ought to review some of the reasons as to why we *didn't* do it in the first place. For one thing, I believe the need to mediate the argument spectrum could be done on either side -- the defining side or the calling side -- but that doing it on the defining side is simpler. For example, it is possible to correct a definition *** in one place *** that fixes up a whole slew of differing calls (e.g., some calls passing 3 args, some passing 5 args, etc). Similarly, we would keep the calling side "simple" even when multiple return values are expected (i.e., no &optional or &rest, and no destructuring). For the cases where some dynamic variation *is* desirable, well, APPLY permits full freedom on the caller side for argument passing, and MULTIPLE-VALUE-LIST permits full freedom on the caller side for receiving values; of course, these "full freedom" capabilities are consy, but they aren't expected to be very important. The case offered as a potential example needing (or rather,"wanting") some caller control over the argument spectrum -- simple WHEREIS and extended WHEREIS -- seems to be a clear case of buggy design. For example, suppose a caller passes 6 arguments at a time when the 4-argument-only version is resident. What could possibly be expected? Should one assume that the extra two argments didn't convey any information, and can safely be discarded? If so, then what is the point of the 6-argument version. If one takes the obvious tactic of having the 4-argument version admit two optional aguments and run a fatal error if either argument is passed in [or even perhaps autoload the 6-argument version when the optionals are passed in] then there is no "4-argument" version; both are in fact 6-argument functions, although one of them is biased against the 5th and 6th args. In short, if one wants downward compatibility, he has to design the low-end function to do something reasonable with callers who request high-end features. -- JonL --  Received: from SU-AI.ARPA by MIT-MC.ARPA; 3 APR 85 17:49:17 EST Received: from MIT-MULTICS.ARPA by SU-AI.ARPA with TCP; 3 Apr 85 14:37:41 PST Date: Wed, 3 Apr 85 17:36 EST From: Nick Gall To: common-lisp@SU-AI.ARPA In-Reply-To: Message of 3 Apr 85 03:28 EST from "Network_Server.Daemon (REM@IMSSS@SU-AI.ARPA)" Message-ID: <850403223620.774008@MIT-MULTICS.ARPA> Date: 3 April 1985 03:28 est From: Network_Server.Daemon (REM@IMSSS@SU-AI.ARPA) Return-Path: <@MIT-MULTICS.ARPA,@SU-AI.ARPA:REM@IMSSS> Received: from SU-AI.ARPA by MIT-MULTICS.ARPA TCP; 03-Apr-1985 03:28:38-est Sent: to SU-AI.ARPA by IMSSS.? via ETHERNET with PUPFTP; 1985-Apr-03 00:23:16 PST (=GMT-8hr) Date: 1985 April 02 23:36:01 PST (=GMT-8hr) Message-id: SU-IMSSS.REM.A132116072764.G0391 From: Robert Elton Maas To:Gall@MIT-MULTICS.ARPA Subject:CL, INTERN, etc. Sender: REM%IMSSS@SU-SCORE.ARPA (for undeliverable-mail notifications) Reply-to: REM@MIT-MC.ARPA > Date: Thu, 21 Mar 85 00:36 EST > From: Nick Gall > > Thanks for the encouragement. Having previously worked on an Ada > implementation effort, I was hoping that the Common Lisp spec. would > have been as carefully and completely defined. But it's never to > late, as long as there is a concerned community. Well, it's more difficult to make substantive changes now, because those who worked on the current version of the manual and have done some implentation are unwilling to start all over now, which I understand (PCNET pulled the rug out from under my software and documentation too many times), but indeed perhaps it's never too late to fix the document to say something consistent and reasonable. > I am sending my replies to some of your replies to the > Common-Lisp mailing list. Ok. (I think I already saw some of them, I'm falling behind in answering my netmail.) > !section 11.7 Nick Gall 85-03-20 > !version Digital Press 1984 > !topic UNINTERNing a shadowing-symbol > When uninterning a shadowing symbol (call it foo), UNINTERN > collects all inherited symbols with the same print-name > as foo, including foo (assuming foo was inherited). If the name > conflict is only between foo and one other symbol, what sense > does it make to signal a name conflict error and give the user a > choice between shadow-importing foo and the other symbol. If the > user chooses foo, it is no different from aborting from the > error. This plus later messages bring up a curious question. Originally INTERN could take a symbol and put it in a hash table so it'd be accessible by name in addition to by internal pointer. Any values or properties it had would presumably be kept. But CL allows INTERN only for strings (creating an symbol or finding an old one), so it never modifies an existing non-interned identifier to make it itself interned, it always makes a new symbol, thus it's impossible to keep the old properties and value from the old symbol in the new one. I this correct? IMPORT can be used to "put [a symbol] in a hash table so it'd be accessible by name...".  Received: from SU-AI.ARPA by MIT-MC.ARPA; 3 APR 85 15:58:29 EST Date: 03 Apr 85 1226 PST From: Jon White Subject: INTERN and "intern" -- the unwise choice of terminology To: Gall@MIT-MULTICS.ARPA, Moon@SCRC-STONY-BROOK.ARPA CC: Common-Lisp@SU-AI.ARPA I believe the confusion over the interning-an-unowned-symbol stems from the misleading use of the verb "intern" on page 172, and I think I'd rather see that part of the documentation fixed than have any change in th semantics of INTERN, UNINTERN, and/or IMPORT. The state of being "interned" clearly requires the symbol to be owned; and the penultimate paragraph of the introductory to chapter 11 says "this process [interning] is performed by the function INTERN." For these reasons, one might be tempted to agree with Nick that every call to INTERN results in an interned symbol; yet the definition of INTERN rather implies that when a symbol is already accessible [note well: "accessible", not "interned"] it is merely returned, without the modification to the home package outlined for the case of when "no such symbol is found". My recommendations are quite straightforward: 1) pick some other word to use in place of "interned" to describe the state so laboriously depicted on page 172, so that the reader is not tempted to jump to the conclusion that it is coextensive with INTERN'd 2) Introduce the user-level operation for modifying a symbol's package "cell" [its home package]. As Nick has already pointed out, the current design doesn't prevent one from damageing that cell, by injudicious use of UNINTERN and/or IMPORT; and worse yet, it doesn't provide any way to say precisely what you mean when you want to change its home [which is different from merely IMPORTing it somewhere]. -- JonL --  Received: from SU-AI.ARPA by MIT-MC.ARPA; 2 APR 85 23:29:50 EST Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 2 Apr 85 20:15:02 PST Received: ID ; Tue 2 Apr 85 23:14:24-EST Date: Tue, 2 Apr 1985 23:14 EST Message-ID: Sender: FAHLMAN@CMU-CS-C.ARPA From: "Scott E. Fahlman" To: "David A. Moon" Cc: common-lisp@SU-AI.ARPA, Nick Gall Subject: NIL and DEFCONSTANT [Gall: Bug Report] In-reply-to: Msg of 2 Apr 1985 19:28-EST from David A. Moon I agree with Moon that it "is an error" to redefine built-in constants. It probably is not required that an implementation stop you from doing this, but it would be a good idea. I think that the description on page 56 is OK as it is. First it says that there are built-in named constants that you don't get to change. Here it talks about such things as T and NIL. Then it says that "constant symbols defined by Defconstant" are also treated this way, but that they may be redefined if necessary by using Defconstant again. I don't see anything that would imply that T and NIL are implicitly defined by Defconstant and that they are therefore redefinable. -- Scott  Received: from SU-AI.ARPA by MIT-MC.ARPA; 2 APR 85 23:13:22 EST Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 2 Apr 85 20:02:42 PST Received: ID ; Tue 2 Apr 85 23:02:04-EST Date: Tue, 2 Apr 1985 23:01 EST Message-ID: Sender: FAHLMAN@CMU-CS-C.ARPA From: "Scott E. Fahlman" To: "David A. Moon" Cc: common-lisp@SU-AI.ARPA, Nick Gall Subject: INTERN [Gall: Bug Report] In-reply-to: Msg of 2 Apr 1985 19:41-EST from David A. Moon This concerns the recent exchange between Moon and Gall on how INTERN should handle home packages. I will refrain from including all previous context. Unfortunately, I read most of this mail on an 80-column screen and if things get nested too deeply, each line starts on the next line. First, let me say that this is probably not of world-shaking importance. Home packages are just a convenience for the printer, so that if a symbol isn't accessible in the current package, it can (usually) either tell you some package where the symbol is accessible or flag the cases in which a symbol is not accessible in any package. It is true that by clever use of Unintern you can manage to create an accessible sysmbol with no recorded home package. Unintern also allows you to screw yourself in lots of other ways if you work hard at it. Yawn! Having said that, it seems to me that Gall's original reading of the manual is as reasonable as any other. This says that if Intern finds an acessible symbol that has no home (as opposed to creating a new symbol), it should bash the Symbol-Package cell to the value of the package in which it is doing the interning. It is too much work to make sure that every symbol that is accessible in any package always has a home package, but when we trip over an anomalous case like this, we may as well fix it. It seems intuitive that Intern should return a symbol that is "interned", in the sense of being accessible and having a home. Moon grants that this might be a reasonable implementation, but then comments that implementing this might be expensive. I don't see where the expense would be. If Intern creates a symbol, it sets the home package; if Intern finds a symbol whose package cell is NIL, it again sets the home package. Checking the home package for nillity is a tiny expense compared to the hash-table lookups, etc. The sentence on page 172 should more properly say "when a STRING is interned in a package...", since as Moon points out you cannot intern a symbol directly. However, I think that this passage makes sense despite this, if you make the reasonable assumption that the "symbol" referred to here is either the one that is created or the already accessible symbol that is found, as the case may be. We decided not to allow users to use SETF on Symbol-Package, since there seemed to be no good use for this and since by diddling around with this you can create some very confusing situations. -- Scott  Received: from SU-AI.ARPA by MIT-MC.ARPA; 2 APR 85 20:40:11 EST Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 2 Apr 85 17:18:21 PST Received: from SCRC-EUPHRATES by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 207711; Tue 2-Apr-85 19:40:43-EST Date: Tue, 2 Apr 85 19:41 EST From: David A. Moon Subject: Re: INTERN [Gall: Bug Report] To: Nick Gall cc: common-lisp@SU-AI.ARPA In-Reply-To: <850402195716.255225@MIT-MULTICS.ARPA> Message-ID: <850402194129.7.MOON@EUPHRATES.SCRC.Symbolics.COM> Sorry about the long message but I can't justify deleting any of the context yet. Summary of conclusions at the end. Date: Tue, 2 Apr 85 14:57 EST From: Nick Gall !section 11.7 Nick Gall 85-03-20 !version Digital Press 1984 !topic INTERN's effect on an accessible symbol's owner. As a verb, to `intern' a symbol in a package means to cause the symbol to be interned (sic) in the package if it was not already; this function is performed by the function INTERN. If the symbol was previously unowned, then the package it is being interned in becomes its owner (home package)... CLRM Section 11.0 (pg. 172) I interpret this passage in the following way: ;; Current package is USER * (setf p1 (make-package 'p1 :use '())) {printed rep. of p1} * (import 'p1::xyzzy) T * (symbol-package 'xyzzy) {printed rep. of p1} * (unintern 'xyzzy p1) T * (symbol-package 'xyzzy) NIL ;; At this point, xyzzy is an accessible uninterned symbol. * (intern "XYZZY") XYZZY :INTERNAL * (symbol-package 'xyzzy) {printed rep. of user} In other words, INTERN ensures that the symbol that it returns as its first value has a home package. Is this interpretation correct? I think the mention of accessible but unowned symbols on page 172 (in the discussion of home packages) shoots down your example. The result of the last call to SYMBOL-PACKAGE is probably undefined. I don't understand your response. The mention of accessible but unowned symbols on page 172 merely confirms the possibility of accessible uninterned symbols. I fully agree that such beasts may exist. In fact, I have annotated the above code to show that BEFORE the intern is done, xyzzy is an accessible uninterned symbol. To amplify my response, I don't feel that when INTERN finds an already accessible symbol (rather than creating a new one), that it "interns the symbol". I think the symbol is already interned and INTERN shouldn't mess with its home package. Of course this is a matter of interpretation and perhaps you are right. The implementation might be expensive in some systems, though. My contention is that the above call to INTERN should (according to my interpretation of the CLRM and for practical reasons which I will point out below) change xyzzy from an accessible uninterned symbol into an interned symbol (simply by updating its package cell). If the symbol was previously unowned, then the package it is being interned in becomes its owner (home package); but if the symbol was previously owned by another package, that other package continues to own the symbol. This sentence strongly suggests to me that intern does affect accessible uninterned symbols. Oh my. The sentence you quote (on p. 172) appears to be left over from the days when INTERN would allow a symbol as its argument. The language was later changed to permit only strings as arguments to INTERN. But if this isn't really a left-over, then it is evidence for your position. If intern does not update an accessible symbol whose package cell contains NIL, there is NO WAY to change the home package of the symbol. I can't give it a new home! I think IMPORT was intended to be the way to do that. Again, the manual does not appear to have been updated to reflect this after the arguments allowed for INTERN were changed. SYMBOL-PACKAGE is also SETF'able in our implementation, but apparently not in the standard language. Suppose I defun foo in the user package. Then I decide that it `belongs' in my tool package. The best I can do now is * (import 'foo 'tool) T * (unintern 'foo) T But whenever foo is printed, it will print as #:foo. This is unacceptable. Do the operations in the other order. (Of course you have to read the IMPORT form before evaluating the UNINTERN form). That works in our implementation, although I admit it isn't crystal clear that that is what the manual intends. I think this issue may need to be referred to the (not yet existent) technical committee on clarifications to the language. If you want my own opinion, in summary: - INTERN never changes the SYMBOL-PACKAGE of a symbol that it did not just create. - IMPORT sets the SYMBOL-PACKAGE to the package imported into when given an uninterned symbol (more precisely, a symbol whose SYMBOL-PACKAGE is NIL).  Received: from SU-AI.ARPA by MIT-MC.ARPA; 2 APR 85 20:33:31 EST Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 2 Apr 85 17:17:01 PST Received: from SCRC-EUPHRATES by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 207707; Tue 2-Apr-85 19:27:57-EST Date: Tue, 2 Apr 85 19:28 EST From: David A. Moon Subject: Re: NIL and DEFCONSTANT [Gall: Bug Report] To: Nick Gall cc: common-lisp@SU-AI.ARPA In-Reply-To: <850402200658.769017@MIT-MULTICS.ARPA> Message-ID: <850402192844.6.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Tue, 2 Apr 85 15:06 EST From: Nick Gall !section 20.1(last-1) Nick Gall 85-03-19 !version Digital Press 1984 !topic Is nil declared by defconstant? ...all constant symbols declared by DEFCONSTANT, such as NIL, T, and PI. If NIL is declared by DEFCONSTANT then it can legally be redefined according to section 5.1.2(last): Constant symbols defined by DEFCONSTANT ... may be redefined, if necessary, by using DEFCONSTANT again[]. Is such an interpretation correct? From: Moon I do not believe that system-supplied constants can legally be redefined. Is it that my interpretation is incorrect (and if so why?) or is it that the CLRM is incorrect (and if so how?). The CLRM is not self-consistent. As I said, I do not believe that system-supplied constants can legally be redefined, so where the CLRM says or implies that they can be it is wrong, in my opinion, and where it says or implies that they cannot be it is not wrong.  Received: from SU-AI.ARPA by MIT-MC.ARPA; 2 APR 85 17:11:43 EST Received: from MIT-MULTICS.ARPA by SU-AI.ARPA with TCP; 2 Apr 85 12:18:08 PST Posted-Date: 2 Apr 85 15:15 EST Date: Tue, 2 Apr 85 15:12 EST From: Nick Gall Subject: Re: [Gall: Bug Report] To: "Daniel L. Weinreb" cc: Moon@SCRC-STONY-BROOK.ARPA, common-lisp@SU-AI.ARPA In-Reply-To: Message of 28 Mar 85 16:56 EST from "Daniel L. Weinreb" Message-ID: <850402201250.950711@MIT-MULTICS.ARPA> Date: 28 March 1985 16:56 est From: Daniel L. Weinreb Subject: [Gall: Bug Report] Date: Wed, 27 Mar 85 20:09 EST From: David A. Moon were EVAL-WHEN permitted inside a function body (it is not; see p.66). ... On p.66 it says that DEFVAR is not allowed elsewhere than top-level. Are we reading the same page 66? Mine says "It is not illegal to use these forms at other than top level, but whether it is meaningful to do so depends on context." To my ears, this is sort of like saying that integers can be of any precision, but after they get larger than the fixnum limit, their behavior depends on context. Also, note the wording in the description of DEFUN on page 67: "Because DEFUN forms normally appear at top level, this is normally the null lexical environment." This wording strongly suggests that DEFUN might sometimes not be at top level, and the environment is not necessarily always null. After all, if DEFUN were only allowed at top-level, why bother with the "normally" qualifiers? But you never find out anything further. I'm not advocating either side right at the moment; my point is that the manual is ambiguous (one might even say "coy") on this subject. Hmm! I thought ALL integers were infinitely precise. As to defuns at other that top level, on pg. 67 it says Evaluating a defun form causes the symbol NAME to be a global name for the function specified by the lambda-expression...DEFINED IN THE LEXICAL ENVIRONMENT IN WHICH THE defun WAS EXECUTED. I take this to mean that the CLRM specifically allows and defines the correct semantics for non-top-level use of DEFUN. I think pg. 66 is what needs cleaning up (i.e., it should enumerate the correct uses of `Top-Level' forms). "Depends on context" is equivalent to "is undefined" in my book.   Received: from SU-AI.ARPA by MIT-MC.ARPA; 2 APR 85 16:45:44 EST Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 2 Apr 85 13:27:03 PST Date: 2 April 1985 16:26-EST From: Jonathan A Rees Subject: SPECIAL FUNCTION NAME [Gall: Bug Report] To: Gall @ MIT-MULTICS cc: common-lisp @ SU-AI Date: Tue, 2 Apr 85 15:01 EST From: Nick Gall ...As for its usefulness, I am writing a command processor, and I wish to prevent the user from typing in forms that might abort the processor (e.g., (exit), (reset-stack-group), etc.). FLET would allow me to establish temporary global function definitions for these dangerous functions. The code would be much clearer than saving the old function definitions, doing defuns (or setfs of symbol-functions) and then restoring the old definitions. I think that special function binding was explicitly and intentionally omitted from CL. Symmetry with variables would suggest that they are desirable, but there were reasons for their omission (descriptive and implementation simplicity come to mind). You could do what you need to do by implementing yourself a sort of generalized special binding which is symmetric with SETF instead of with SETQ, using UNWIND-PROTECT: (SETF-TEMPORARILY place value-form ... body-forms ...) could expand into something like (LET ((SAVED-VALUE place)) (UNWIND-PROTECT (PROGN (SETF SAVED-VALUE place) ... body-forms ...) (SETF place SAVED-VALUE))) (with appropriate DEFSETF-like hair). Now you have a much more symmetrical facility, which will work not only with function bindings (take place = (SYMBOL-FUNCTION ...)) but any other kind of location - including CAR's of lists, lexical variables (!), etc. (Think about it.) We've been using exactly this facility in T (Yale Scheme) for quite a while (in fact, it replaces specbinding altogether) and it's pretty nice. Perhaps even a little too powerful. You run into problems if you're running in a multitasking or multiprocessing environment. Presumably special variable bindings are local to a process in any such system (whether deep- or shallow-bound). If you're multitasking you could imagine an UNWIND-PROTECT primitive for changing dynamic state going from one process to another, so that you could specbind arbitrary places; but this totally breaks down in a multiprocessor system, where deep binding would be necessary. How do you deep-bind the car of a pair, or the 13th bit of a bit-vector? That would argue in favor of permitting function specbinding by special dispensation, although how you'd implement it efficiently I can't imagine. For this particular application, though, isn't the right thing just to set up a separate package?... Jonathan  Received: from SU-AI.ARPA by MIT-MC.ARPA; 2 APR 85 16:43:50 EST Received: from UCB-VAX.ARPA by SU-AI.ARPA with TCP; 2 Apr 85 13:24:51 PST Received: from ucbdali.ARPA by UCB-VAX.ARPA (4.24/4.42) id AA22191; Tue, 2 Apr 85 12:50:14 pst Received: by ucbdali.ARPA (4.24/4.42) id AA02474; Tue, 2 Apr 85 12:50:16 pst Date: Tue, 2 Apr 85 12:50:16 pst From: fateman%ucbdali@Berkeley (Richard Fateman) Message-Id: <8504022050.AA02474@ucbdali.ARPA> To: common-lisp@SU-AI.ARPA Subject: CLRM? I think this is what I call CLTL (Common Lisp the Language). I am perhaps guilty of wishful thinking to hope that a CLRM (Common Lisp Reference Manual) will be a different, perhaps public domain, document. Is there any hope of this happening? In the meantime, I will wait for CLTM, (Common Lisp the Movie) and TWK (The numeric supplement... The Wrath of Kahan ).  Received: from SU-AI.ARPA by MIT-MC.ARPA; 2 APR 85 16:19:32 EST Received: from MIT-MULTICS.ARPA by SU-AI.ARPA with TCP; 2 Apr 85 12:16:02 PST Posted-Date: 2 Apr 85 15:04 EST Date: Tue, 2 Apr 85 15:01 EST From: Nick Gall Subject: Re: SPECIAL FUNCTION NAME [Gall: Bug Report] To: common-lisp@SU-AI.ARPA In-Reply-To: Message of 28 Mar 85 09:28 EST from "Network_Server.Daemon (Moon@SCRC-STONY-BROOK.ARPA@SU-AI)" Message-ID: <850402200150.524049@MIT-MULTICS.ARPA> !section 7.5(14) Nick Gall 85-03-19 !version Digital Press 1984 !topic Scope and Extent of local function names See above comment about the implications of FLET and LABELS not having been fully thought out and reflected in the manual. I suggest that Common Lisp go all the way, and allow a SPECIAL-FUNCTION-NAME declaration that would be analogous to the SPECIAL declaration for "ordinary" variables. Such a concept would make the idea of ordinary-variable/function-name binding and assignment much more consistent. As I recall this was considered and rejected on the basis that it would be confusing and wouldn't give any real increase in expressive power (since FUNCALL of a special variable could be used). I agree with that decision, even though our implementation has always had the feature. The only place where we use it is in a crock that could just as well be done some other way. I think that a thought out explanation of FLET and LABELS would allow a SPECIAL-FUNCTION-NAME declaration to be described in perspicuous manner. As for its usefulness, I am writing a command processor, and I wish to prevent the user from typing in forms that might abort the processor (e.g., (exit), (reset-stack-group), etc.). FLET would allow me to establish temporary global function definitions for these dangerous functions. The code would be much clearer than saving the old function definitions, doing defuns (or setfs of symbol-functions) and then restoring the old definitions.   Received: from SU-AI.ARPA by MIT-MC.ARPA; 2 APR 85 15:28:46 EST Received: from MIT-MULTICS.ARPA by SU-AI.ARPA with TCP; 2 Apr 85 12:16:52 PST Date: Tue, 2 Apr 85 15:06 EST From: Nick Gall Subject: Re: NIL and DEFCONSTANT [Gall: Bug Report] To: common-lisp@SU-AI.ARPA In-Reply-To: Message of 28 Mar 85 09:28 EST from "Network_Server.Daemon (Moon@SCRC-STONY-BROOK.ARPA@SU-AI)" Message-ID: <850402200658.769017@MIT-MULTICS.ARPA> !section 20.1(last-1) Nick Gall 85-03-19 !version Digital Press 1984 !topic Is nil declared by defconstant? ...all constant symbols declared by DEFCONSTANT, such as NIL, T, and PI. If NIL is declared by DEFCONSTANT then it can legally be redefined according to section 5.1.2(last): Constant symbols defined by DEFCONSTANT ... may be redefined, if necessary, by using DEFCONSTANT again[]. Is such an interpretation correct? I do not believe that system-supplied constants can legally be redefined. Is it that my interpretation is incorrect (and if so why?) or is it that the CLRM is incorrect (and if so how?).   Received: from SU-AI.ARPA by MIT-MC.ARPA; 2 APR 85 15:27:33 EST Received: from MIT-MULTICS.ARPA by SU-AI.ARPA with TCP; 2 Apr 85 12:16:27 PST Date: Tue, 2 Apr 85 15:05 EST From: Nick Gall Subject: Re: COPY-SYMBOL [Gall: Bug Report] To: common-lisp@SU-AI.ARPA In-Reply-To: Message of 28 Mar 85 09:28 EST from "Network_Server.Daemon (Moon@SCRC-STONY-BROOK.ARPA@SU-AI)" Message-ID: <850402200539.663972@MIT-MULTICS.ARPA> !section 10.3(9) Nick Gall 85-03-19 !version Digital Press 1984 !topic Which bindings are copied by COPY-SYMBOL? "the initial value and function-definition of the new symbol will be the same as those of SYM..." Does this mean that the (dynamic) value of the variable referred to by SYM, at the point where COPY-SYMBOL symbol is invoked, is copied? Or, does it mean that the `initial', i.e. global value of the special variable named by SYM is copied? Although the wording seems to suggest the latter, it should be made clearer. The word "initial" was meant to refer to the new symbol, not the old symbol, I believe. Probably no one realized the English could be regarded as ambiguous. The same questions and suggestion applies to the function-definition copied by COPY-SYMBOL. What confused me in the defintion of COPY-SYMBOL was the phrase, "the initial value and function definition of the NEW SYMBOL" [emphasis mine N.G.]. Symbols do not have values and/or function defintions in CL (or at least they are not required to), a point made very well on pg. 163. The language should be more like "the initial value of the dynamic variable NAMED BY THE new symbol..."   Received: from SU-AI.ARPA by MIT-MC.ARPA; 2 APR 85 15:20:20 EST Received: from MIT-MULTICS.ARPA by SU-AI.ARPA with TCP; 2 Apr 85 12:00:57 PST Date: Tue, 2 Apr 85 14:57 EST From: Nick Gall Subject: Re: INTERN [Gall: Bug Report] To: common-lisp@SU-AI.ARPA In-Reply-To: Message of 28 Mar 85 09:28 EST from "Network_Server.Daemon (Moon@SCRC-STONY-BROOK.ARPA@SU-AI)" Message-ID: <850402195716.255225@MIT-MULTICS.ARPA> !section 11.7 Nick Gall 85-03-20 !version Digital Press 1984 !topic INTERN's effect on an accessible symbol's owner. As a verb, to `intern' a symbol in a package means to cause the symbol to be interned (sic) in the package if it was not already; this function is performed by the function INTERN. If the symbol was previously unowned, then the package it is being interned in becomes its owner (home package)... CLRM Section 11.0 (pg. 172) I interpret this passage in the following way: ;; Current package is USER * (setf p1 (make-package 'p1 :use '())) {printed rep. of p1} * (import 'p1::xyzzy) T * (symbol-package 'xyzzy) {printed rep. of p1} * (unintern 'xyzzy p1) T * (symbol-package 'xyzzy) NIL ;; At this point, xyzzy is an accessible uninterned symbol. * (intern "XYZZY") XYZZY :INTERNAL * (symbol-package 'xyzzy) {printed rep. of user} In other words, INTERN ensures that the symbol that it returns as its first value has a home package. Is this interpretation correct? I think the mention of accessible but unowned symbols on page 172 (in the discussion of home packages) shoots down your example. The result of the last call to SYMBOL-PACKAGE is probably undefined. I don't understand your response. The mention of accessible but unowned symbols on page 172 merely confirms the possibility of accessible uninterned symbols. I fully agree that such beasts may exist. In fact, I have annotated the above code to show that BEFORE the intern is done, xyzzy is an accessible uninterned symbol. My contention is that the above call to INTERN should (according to my interpretation of the CLRM and for practical reasons which I will point out below) change xyzzy from an accessible uninterned symbol into an interned symbol (simply by updating its package cell). If the symbol was previously unowned, then the package it is being interned in becomes its owner (home package); but if the symbol was previously owned by another package, that other package continues to own the symbol. This sentence strongly suggests to me that intern does affect accessible uninterned symbols. If intern does not update an accessible symbol whose package cell contains NIL, there is NO WAY to change the home package of the symbol. I can't give it a new home! Suppose I defun foo in the user package. Then I decide that it `belongs' in my tool package. The best I can do now is * (import 'foo 'tool) T * (unintern 'foo) T But whenever foo is printed, it will print as #:foo. This is unacceptable.  Received: from SU-AI.ARPA by MIT-MC.ARPA; 2 APR 85 15:18:47 EST Received: from MIT-MULTICS.ARPA by SU-AI.ARPA with TCP; 2 Apr 85 12:01:32 PST Date: Tue, 2 Apr 85 14:58 EST From: Nick Gall Subject: Re: PROCLAIM [Gall: Bug Report] To: common-lisp@SU-AI.ARPA In-Reply-To: Message of 28 Mar 85 09:28 EST from "Network_Server.Daemon (Moon@SCRC-STONY-BROOK.ARPA@SU-AI)" Message-ID: <850402195849.627063@MIT-MULTICS.ARPA> !section 9.1(12) Nick Gall 85-03-19 !version Digital Press 1984 !topic Non-Top-Level use of PROCLAIM Some mention of the effects of the non-top-level use of PROCLAIM and the other proclaiming forms should be made. On p.66 it says that DEFVAR is not allowed elsewhere than top-level. PROCLAIM is the only function (rather than special form) that makes declarations, and presumably the declarations it makes when it is called take effect "immediately", but the exact definition of "immediately" might be implementation-dependent. For example, it is implementation- dependent whether PROCLAIM affects interpreted functions that have already been defined. I guess what really bothers me about the definition of proclaim is the following sentence: This allows a program to compute a declaration and then put it into effect by calling proclaim. (pg. 156) This encourages a style that is bound to bring out an inconsistency in between the semantics assigned to a correct program by the compiler and the interpreter. Is there a STRONG reason for allowing run-time declares? If not, I think the above sentence should be struck, and proclaim's usage restricted to DEFVAR, etc., and top-level.   Received: from SU-AI.ARPA by MIT-MC.ARPA; 2 APR 85 10:56:22 EST Received: from SCRC-QUABBIN.ARPA by SU-AI.ARPA with TCP; 2 Apr 85 07:44:51 PST Received: from SCRC-CHICOPEE by SCRC-QUABBIN via CHAOS with CHAOS-MAIL id 149181; Tue 2-Apr-85 10:39:25-EST Date: Tue, 2 Apr 85 10:46 EST From: Daniel L. Weinreb Subject: Re: Arg count checking To: KMP@SCRC-STONY-BROOK.ARPA, masinter.pa@XEROX.ARPA cc: common-lisp@SU-AI.ARPA In-Reply-To: <850401214307.2.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> Message-ID: <850402104635.2.DLW@CHICOPEE.SCRC.Symbolics.COM> Date: Mon, 1 Apr 85 21:43 EST From: Kent M Pitman This is interesting. I hadn't ever thought about (MAPCAR #'(LAMBDA (X &OPTIONAL (Y 0)) (LIST X Y)) '(A B C D) '(1 2)) I suppose one could argue that returning ((A 1) (B 2) (C 0) (D 0)) would have been the "right" thing. You'd have to change the definition of MAPCAR. Currently it's defined to stop after any of the lists run out. You'd have to change it; perhaps to say that it should keep going until ALL of the lists run out, but the old rule was there for a reason. Or that it should stop as soon as any of the lists that are being used as "required" argument run out, although that's on the hirsute side. Of course, (MAPCAR #'(LAMBDA (&OPTIONAL (X 0) (Y 0)) (LIST X Y)) '(A B C D) '(1 2)) might have been a little harder to deal with ... since presumably that just wouldn't return... No. Under any of the possibilities above, it must terminate after four steps. of course, the fact that (MAPCAR #'(LAMBDA (&OPTIONAL (X 0)) (PRINT X))) loops indefinitely rather than returning argues in favor of such a position. ... I think. The first list argument to MAPCAR is required, so this simply bombs out with too few arguments to MAPCAR. I definitely agree these two issues are not different. I think this just shows that what multiple value return does is wrong. I've held the position for quite some time that multiple values should have to be &OPTIONAL'd and &REST'd. I believe there are others on this committee who side with me, but we were in the minority in the discussions leading up to the current spec. Perhaps that will change with time. That's right. This was argued to death, and the present behavior was arrived at after lots of discussion about both (and other) schemes.  Received: from SU-AI.ARPA by MIT-MC.ARPA; 1 APR 85 21:56:40 EST Received: from SCRC-YUKON.ARPA by SU-AI.ARPA with TCP; 1 Apr 85 18:44:26 PST Received: from SCRC-RIO-DE-JANEIRO by SCRC-YUKON via CHAOS with CHAOS-MAIL id 98514; Mon 1-Apr-85 21:43:55-EST Date: Mon, 1 Apr 85 21:43 EST From: Kent M Pitman Subject: Re: Arg count checking To: masinter.pa@XEROX.ARPA cc: common-lisp@SU-AI.ARPA In-Reply-To: The message of 1 Apr 85 04:00-EST from masinter.pa@XEROX.ARPA Message-ID: <850401214307.2.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> [Removed Bug-1100@SUMEX-AIM] Date: 1 Apr 85 01:00 PST From: masinter.pa@XEROX.ARPA Subject: Re: Arg count checking In-reply-to: various messages To: bug-1100@SUMEX-AIM.ARPA cc: common-lisp@SU-AI.ARPA The only places I've seen extra args used in situations where it isn't (clearly) a bug is in code that is dealing with two different implementations. Implementation A has a function FOO with args A B and an optional C. Implementation B has a function FOO with args A B. No optional. You can then write a client that will work with both implementations, as long as it knows that some implementations may ignore the last argument. (Most of the cases I've seen have been ones where its been a "flag", e.g. implementation A has a "slow" and a "fast" case, and you can say (FOO 1 2 T) and it means do (FOO 1 2) and, if you care, do it fast rather than slow..., although there have been other uses.) I can think of about a half-dozen cases of this, off hand; e.g., the "standard system" has a vanilla WHEREIS, but there's a super-WHEREIS that takes lots of args, and it redefines WHEREIS to have lots of optionals. The odd thing is that I can't think of a really clean way of doing this-- having variant argument lists in different implementations -- I suppose you'd have to write a &REST in every implementation that didn't have the args. The proper solution would have been for the person who wrote the super-WHEREIS to call it something else (or in a language like CL, use the same name but put it in a different package). Then old code still calls the old utility and new code can call the new super-WHEREIS. Even if the super-WHEREIS fixes some misfeature the old WHEREIS wants, the writer should have done (DEFUN WHEREIS (...compatible-args...) (SUPER-WHEREIS ...whatever...)) (DEFUN SUPER-WHEREIS (...hairy-args...) ...) so that people wouldn't be tempted to call the existing WHEREIS with the hairy args and get into the situation you're talking about. It's the fault of the person who created the new FOO abstraction without giving it a new name that you are in this mess. If (FOO x y) and (FOO x y z) does already exist in two implementations, you should just write your own GENERALIZED-FOO abstraction that does (DEFUN GFOO (X Y &REST Z) (COND ((MEMQ 'HAIRY-FOO *FEATURES*) (APPLY #'FOO X Y Z)) (T (FOO X Y)))) or some macroesque equivalent (if you're an efficiency fiend). Another place this arises are in mapping functions which take functional arguments; they apply the functional arg; sometimes they pass extra arguments which of course the functional is free to ignore. This is interesting. I hadn't ever thought about (MAPCAR #'(LAMBDA (X &OPTIONAL (Y 0)) (LIST X Y)) '(A B C D) '(1 2)) I suppose one could argue that returning ((A 1) (B 2) (C 0) (D 0)) would have been the "right" thing. Of course, (MAPCAR #'(LAMBDA (&OPTIONAL (X 0) (Y 0)) (LIST X Y)) '(A B C D) '(1 2)) might have been a little harder to deal with ... since presumably that just wouldn't return... of course, the fact that (MAPCAR #'(LAMBDA (&OPTIONAL (X 0)) (PRINT X))) loops indefinitely rather than returning argues in favor of such a position. ... I think. All of these are instances where the CALLER knows the args are optional. I can imagine (not very seriously) a separate syntax for that, e.g., put the &OPTIONAL on the caller rather than the callee: (FOO 1 2 &OPTIONAL T) which says to call FOO with 2 arguments, and throw away the third if FOO only takes two arguments, but otherwise pass it all three. This is certainly consistent with the symmetry provided in the allow-other-keys portion of the keyword arg specs. Somehow this bothers me; I'm at a loss to say exactly why, though. But I think it also bothers me that :ALLOW-OTHER-KEYS is there (for reasons beyond the obvious fact that it's an ugly special case in the middle of the keyword namespace), so don't take it too personally. I think it has something to do with the fact that it means you're really trying to shoehorn an additional abstraction in where room wasn't provided. ie, the real problem is that all the old code is still calling FOO instead of GENERIC-FOO. I guess I think that's just a bug in that code. Can this be different than multiple-value-return where the caller is expecting fewer values than the callee returns? I definitely agree these two issues are not different. I think this just shows that what multiple value return does is wrong. I've held the position for quite some time that multiple values should have to be &OPTIONAL'd and &REST'd. I believe there are others on this committee who side with me, but we were in the minority in the discussions leading up to the current spec. Perhaps that will change with time.  Received: from SU-AI.ARPA by MIT-MC.ARPA; 1 APR 85 14:40:56 EST Received: from CCA-UNIX.ARPA by SU-AI.ARPA with TCP; 1 Apr 85 11:27:19 PST Received: by cca-unix.ARPA (4.12/4.7) id AA25468; Mon, 1 Apr 85 14:16:46 est Message-Id: <8504011916.AA25468@cca-unix.ARPA> Received: by godot with CHAOS id AA04234; Mon, 1 Apr 85 13:38:48 est Date: Monday, 1 April 1985, 13:39-EST From: Guy Steele Subject: Implementation of MAP, SOME, EVERY, etc... To: Moon%SCRC-STONY-BROOK.ARPA@GODOT, cork%umass-cs.csnet%CSNET-RELAY.ARPA@GODOT Cc: common-lisp%SU-AI.ARPA@GODOT, gls@AQUINAS In-Reply-To: <850327161712.2.MOON@EUPHRATES.SCRC.Symbolics.COM> Received: by godot id AA28148; Wed, 27 Mar 85 22:11:41 est Received: from SU-AI.ARPA (su-ai.arpa.ARPA) by cca-unix.ARPA (4.12/4.7) id AA24285; Wed, 27 Mar 85 21:34:41 est Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 27 Mar 85 13:39:50 PST Received: from SCRC-EUPHRATES by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 204367; Wed 27-Mar-85 16:16:13-EST Date: Wed, 27 Mar 85 16:17 EST From: David A. Moon Subject: Implementation of MAP, SOME, EVERY, etc... To: Dan Corkill Cc: common-lisp%SU-AI.ARPA@godot In-Reply-To: The message of 19 Mar 85 11:58-EST from Dan Corkill Message-Id: <850327161712.2.MOON@EUPHRATES.SCRC.Symbolics.COM> Comment: Message remailed after delay caused by distribution list error. Date: Tue, 19 Mar 85 11:58 EST From: Dan Corkill There is an easily made implementation error in MAP, SOME, EVERY, etc. The published semantics indicate that these functions use the length of the shortest argument sequence to determine how many iterations to perform (and in this way parallel the semantics of mapc, mapcar, etc.). Thus it would appear that: (map 'list '+ '(1 2 3) (star 2)) where star builds a circular list of its argument should be legal and return => (3 4 5). Implementations that use length to check the length of argument sequences will break on such a call. The Common Lisp LENGTH function returns NIL when given a circular list. From the Common Lisp manual, page 265: "LIST-LENGTH differs from LENGTH when the list is circular; LENGTH may fail to return, whereas LIST-LENGTH will return NIL."  Received: from SU-AI.ARPA by MIT-MC.ARPA; 1 APR 85 14:36:47 EST Received: from CCA-UNIX.ARPA by SU-AI.ARPA with TCP; 1 Apr 85 11:23:08 PST Received: by cca-unix.ARPA (4.12/4.7) id AA25503; Mon, 1 Apr 85 14:18:04 est Message-Id: <8504011918.AA25503@cca-unix.ARPA> Received: by godot with CHAOS id AA04348; Mon, 1 Apr 85 13:46:19 est Date: Monday, 1 April 1985, 13:46-EST From: Guy Steele Subject: [Gall: Bug Report] To: Moon%SCRC-STONY-BROOK.ARPA@GODOT, common-lisp%SU-AI.ARPA@GODOT Cc: gls@AQUINAS In-Reply-To: <850327200955.6.MOON@EUPHRATES.SCRC.Symbolics.COM> I have been tracking comments on ambiguities and lack of clarity in the manual, and have been making a list of "small" (not substantive) changes which might be incorporated in the next printing. While I expect no objections to the changes, I will circulate the list well before sending it to Digital Press. --Guy  Received: from SU-AI.ARPA by MIT-MC.ARPA; 1 APR 85 04:26:04 EST Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 1 Apr 85 01:18:21 PST Received: from Semillon.ms by ArpaGateway.ms ; 01 APR 85 01:18:18 PST Date: 1 Apr 85 01:00 PST From: masinter.pa@XEROX.ARPA Subject: Re: Arg count checking In-reply-to: various messages To: bug-1100@SUMEX-AIM.ARPA cc: common-lisp@SU-AI.ARPA The only places I've seen extra args used in situations where it isn't (clearly) a bug is in code that is dealing with two different implementations. Implementation A has a function FOO with args A B and an optional C. Implementation B has a function FOO with args A B. No optional. You can then write a client that will work with both implementations, as long as it knows that some implementations may ignore the last argument. (Most of the cases I've seen have been ones where its been a "flag", e.g. implementation A has a "slow" and a "fast" case, and you can say (FOO 1 2 T) and it means do (FOO 1 2) and, if you care, do it fast rather than slow..., although there have been other uses.) I can think of about a half-dozen cases of this, off hand; e.g., the "standard system" has a vanilla WHEREIS, but there's a super-WHEREIS that takes lots of args, and it redefines WHEREIS to have lots of optionals. The odd thing is that I can't think of a really clean way of doing this-- having variant argument lists in different implementations -- I suppose you'd have to write a &REST in every implementation that didn't have the args. Another place this arises are in mapping functions which take functional arguments; they apply the functional arg; sometimes they pass extra arguments which of course the functional is free to ignore. All of these are instances where the CALLER knows the args are optional. I can imagine (not very seriously) a separate syntax for that, e.g., put the &OPTIONAL on the caller rather than the callee: (FOO 1 2 &OPTIONAL T) which says to call FOO with 2 arguments, and throw away the third if FOO only takes two arguments, but otherwise pass it all three. Can this be different than multiple-value-return where the caller is expecting fewer values than the callee returns?  Received: from SU-AI.ARPA by MIT-MC.ARPA; 29 MAR 85 23:48:33 EST Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 29 Mar 85 20:41:27 PST Date: 29 March 1985 23:41-EST From: Tim McNerney Subject: multiple-value-setf To: Fahlman @ CMU-CS-C cc: common-lisp @ SU-AI, eak @ S1-B In-reply-to: Msg of Wed 27 Mar 1985 19:39 EST from Scott E. Fahlman Granted that it is relatively easy to write a multiple-value-setf, it probably should have been included in the language to begin with. I had several uses for it and was forced to write my own.  Received: from SU-AI.ARPA by MIT-MC.ARPA; 29 MAR 85 01:27:24 EST Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 28 Mar 85 22:16:49 PST Received: from umass-cs by csnet-relay.csnet id ab02829; 29 Mar 85 1:02 EST Date: Thu, 28 Mar 85 09:26 EST From: Dan Corkill To: common-lisp@su-ai.ARPA Subject: More on MAP, SOME, EVERY, etc..... I'm not certain this made it through the network..... ------------------------------------------------------------------------------ As I expected, my flame about MAP, SOME, EVERY, etc. has raised some important issues..... First, RAM suggests that viewing a circular list as a dotted list avoids the problem: > The definition of a normal list in the Lists chapter is one > terminated by NIL. By this definition, a circular list is a dotted > list. I believe that there was a decision at one point that functions > which use lists as sequences (a superset of the sequence functions) > are allowed to complain about dotted lists. This is implied by the > statement that Endp is the canonical list-end predicate. However, the next sentence from that chapter argues that a circular list CANNOT be a dotted list: ``A list whose cdr chain is terminated by some non-nil atom is called a dotted list.'' Clearly, a circular list is not terminated by some non-NIL atom (is it terminated at all?), and ENDP cannot be used to detect a circular list. ~~ An aside --- As the CLM is unclear on whether or not a circular is ~~ is an ORDINARY or DOTTED list, I would argue that it is better ~~ viewed as an ORDINARY list. In a sense a circular list is a list ~~ that shares structure with itself. Unless destructive functions ~~ are applied to a circular list, it behaves identically to an ~~ infinite list. Further supporting this position is the observation ~~ that mapc, mapcar, etc. work with circular list arguments and ~~ generate errors with dotted (non-circular) list arguments. *** Back to the original complaint about MAP, SOME, EVERY, etc. *** Under the premise that a circular list is NOT a dotted list, the implementation of MAP, SOME, EVERY, etc. should not care whether or not an argument sequence is circular or not. (It should be up to the user to worry about the effects of any destructive changes to an arglist. I suggest that all the following should be legal: (map 'list '+ '(1 2 3) (star 5)) => (6 7 8) ;; (defun star (&REST arglist) ;; (nconc arglist arglist)) (some 'char< "string" (star #\x)) => t (map 'array '#(2 3 4) (star 5)) => #(7 8 9) (replace '(1 2 3 4 5) (star -1) :START1 2 :END1 4)) => (1 2 -1 -1 5) ;; Note that (replace (star -1) '(1 2 3 4 5) :start1 2 :end1 4) ;; should not be expected to produce (-1 -1 1 2 -1 ... ). But ;; should be undefined as to what it does. I agree with Dave Dyer that the programmer shouldn't have to know anything about the lists passed to MAPxxx except that the shortest sequence (if a list) is a proper list. I would hope that even the following would be legal: (map 'list '+ '(1 2 3) '(1 2 3 4 5 . 6)) => (2 4 6) I also agree that the use of LENGTH for lists is a poor implementation technique, and Dave's admonition against the use of LENGTH in system functions unless all elements are guaranteed to be inspected is reasonable. In summary, I believe that implementations of MAP, SOME, EVERY, etc. using LENGTH do not follow the semantics of the CLM and are inconsistent with the usual behavior of the traditional list mapping functions. I strongly suggest that it is the implementations that are incorrect rather than ambiguity in the semantics and argue that merely changing the descriptions to explicitly exclude circular lists greatly curtails the utility of the sequence functions. Dan Corkill Cork@UMass ------------------------------------------------------------------------------  Received: from SU-AI.ARPA by MIT-MC.ARPA; 28 MAR 85 19:30:37 EST Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 28 Mar 85 16:21:40 PST Received: from SCRC-EUPHRATES by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 205314; Thu 28-Mar-85 19:04:52-EST Date: Thu, 28 Mar 85 19:06 EST From: David A. Moon Subject: [Gall: Bug Report] To: Daniel L. Weinreb cc: common-lisp@SU-AI.ARPA In-Reply-To: <850328165608.0.DLW@CHICOPEE.SCRC.Symbolics.COM> Message-ID: <850328190615.8.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Thu, 28 Mar 85 16:56 EST From: Daniel L. Weinreb Date: Wed, 27 Mar 85 20:09 EST From: David A. Moon were EVAL-WHEN permitted inside a function body (it is not; see p.66). ... On p.66 it says that DEFVAR is not allowed elsewhere than top-level. Are we reading the same page 66? Mine says "It is not illegal to use these forms at other than top level, but whether it is meaningful to do so depends on context." To my ears, this is sort of like saying that integers can be of any precision, but after they get larger than the fixnum limit, their behavior depends on context. In my opinion, saying that is not meaningful is tantamount to saying that it is not allowed. The phrase I should have used was not "not allowed", but "not defined by standard Common Lisp". Also, note the wording in the description of DEFUN on page 67: "Because DEFUN forms normally appear at top level, this is normally the null lexical environment." This wording strongly suggests that DEFUN might sometimes not be at top level, and the environment is not necessarily always null. After all, if DEFUN were only allowed at top-level, why bother with the "normally" qualifiers? But you never find out anything further. I'm not advocating either side right at the moment; my point is that the manual is ambiguous (one might even say "coy") on this subject. Indeed.  Received: from SU-AI.ARPA by MIT-MC.ARPA; 28 MAR 85 17:44:45 EST Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 28 Mar 85 14:34:38 PST Received: from SCRC-EUPHRATES by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 205160; Thu 28-Mar-85 16:13:54-EST Date: Thu, 28 Mar 85 16:15 EST From: David A. Moon Subject: values-list To: Earl A. Killian cc: common-lisp@SU-AI.ARPA In-Reply-To: The message of 28 Mar 85 14:52-EST from Earl A. Killian Message-ID: <850328161516.4.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: 28 March 1985 14:52-EST From: Earl A. Killian Date: Thu, 28 Mar 85 13:36 EST From: David A. Moon What's wrong with (APPLY #'VALUES-LIST A B C L)? You mean (APPLY #'VALUES A B C L). This is actually where the idea comes from. You're right. I don't really care about this; I was just observing that an obvious extension exists. If I wanted to be argumentative my reply would be "The same thing that's wrong with (APPLY #'VALUES L) that caused (VALUES-LIST L) to be added to the language." Indeed, I wouldn't care to defend the presence of VALUES-LIST in the language.  Received: from SU-AI.ARPA by MIT-MC.ARPA; 28 MAR 85 17:44:15 EST Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 28 Mar 85 14:33:20 PST Received: from SCRC-CHICOPEE by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 205213; Thu 28-Mar-85 16:54:47-EST Date: Thu, 28 Mar 85 16:56 EST From: Daniel L. Weinreb Subject: [Gall: Bug Report] To: Moon@SCRC-STONY-BROOK.ARPA, common-lisp@SU-AI.ARPA In-Reply-To: <850327200955.6.MOON@EUPHRATES.SCRC.Symbolics.COM> Message-ID: <850328165608.0.DLW@CHICOPEE.SCRC.Symbolics.COM> Date: Wed, 27 Mar 85 20:09 EST From: David A. Moon were EVAL-WHEN permitted inside a function body (it is not; see p.66). ... On p.66 it says that DEFVAR is not allowed elsewhere than top-level. Are we reading the same page 66? Mine says "It is not illegal to use these forms at other than top level, but whether it is meaningful to do so depends on context." To my ears, this is sort of like saying that integers can be of any precision, but after they get larger than the fixnum limit, their behavior depends on context. Also, note the wording in the description of DEFUN on page 67: "Because DEFUN forms normally appear at top level, this is normally the null lexical environment." This wording strongly suggests that DEFUN might sometimes not be at top level, and the environment is not necessarily always null. After all, if DEFUN were only allowed at top-level, why bother with the "normally" qualifiers? But you never find out anything further. I'm not advocating either side right at the moment; my point is that the manual is ambiguous (one might even say "coy") on this subject.  Received: from SU-AI.ARPA by MIT-MC.ARPA; 28 MAR 85 15:11:20 EST Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 28 Mar 85 11:58:17 PST Received: from SCRC-CROW by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 205049; Thu 28-Mar-85 14:32:07-EST Date: Thu, 28 Mar 85 14:32 EST From: Robert W. Kerns Subject: Clearly non-controversial To: brown@DEC-HUDSON.ARPA cc: common-lisp@SU-AI.ARPA In-Reply-To: The message of 6 Feb 85 12:52-EST from brown at DEC-HUDSON Message-ID: <850328143248.2.RWK@CROW.SCRC.Symbolics.COM> Date: Wed, 06 Feb 85 12:52:15 EST From: brown@DEC-HUDSON DELETE-SETF-METHOD access-fn [function] Removes the update form associated with the symbol access-fn. The access function can no longer be used as generalized variable. Either FMAKUNBOUND should call this, or maybe it should just be a part of FMAKUNBOUND. HASH-TABLE-REHASH-SIZE hash-table [function] HASH-TABLE-REHASH-TRESHOLD hash-table [function] Should these two be SETFable? HASH-TABLE-SIZE hash-table [function] HASH-TABLE-TEST hash-table [function] These functions return the values that were specified when the hash-table was created. (This list used to contain TERMINALP which returned T if its argument (string, pathname, etc.) was an "interactive terminal". I think this function would be useful, but decided I was unable to define what a terminal is, so removed it.) How about "a terminal is something that has a keyboard attached, with a good chance of having a user attached to the keyboard, and able to send characters back on any stream"? I'd suggest just defining it to work on streams. -Gary Brown  Received: from SU-AI.ARPA by MIT-MC.ARPA; 28 MAR 85 15:10:23 EST Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 28 Mar 85 11:51:48 PST Date: 28 March 1985 14:52-EST From: Earl A. Killian Subject: values-list To: Moon @ SCRC-STONY-BROOK cc: common-lisp @ SU-AI Date: Thu, 28 Mar 85 13:36 EST From: David A. Moon What's wrong with (APPLY #'VALUES-LIST A B C L)? You mean (APPLY #'VALUES A B C L). This is actually where the idea comes from. I don't really care about this; I was just observing that an obvious extension exists. If I wanted to be argumentative my reply would be "The same thing that's wrong with (APPLY #'VALUES L) that caused (VALUES-LIST L) to be added to the language."  Received: from SU-AI.ARPA by MIT-MC.ARPA; 28 MAR 85 14:42:12 EST Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 28 Mar 85 11:26:13 PST Received: from SCRC-EUPHRATES by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 204994; Thu 28-Mar-85 13:35:14-EST Date: Thu, 28 Mar 85 13:36 EST From: David A. Moon Subject: values-list To: Scott E. Fahlman cc: Earl Killian , common-lisp@SU-AI.ARPA In-Reply-To: Message-ID: <850328133629.1.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Wed, 27 Mar 1985 19:50 EST From: "Scott E. Fahlman" From: EAK A useful extension to values-list would be to make it take multiple arguments the way apply does, i.e. all but the last are values to return and the last is a list of further values to return. What's wrong with (APPLY #'VALUES-LIST A B C L)? You can easily get the effect you want with a macro, as long as you're willing to cons all the returned values into a list at some point. I guess your point is that sometimes you don't know how many values to expect, but would like to handle the first few without consing via values-list. Multiple-Value-Call with a &rest arg gives you this effect, but forces you to do a function call that might be superfluous. So there is a niche for your proposed mechanism, but I don't think it's a common enough situation to worry about. The only cases I've seen where you don't know how many args are coming back would not be bothered by the overhead of the function call or the values-list; in the tense cases, you generally how many args to expect. This discussion appears to be about MULTIPLE-VALUE-LIST.  Received: from SU-AI.ARPA by MIT-MC.ARPA; 28 MAR 85 14:30:59 EST Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 28 Mar 85 11:16:17 PST Received: ID ; Thu 28 Mar 85 14:15:35-EST Date: Thu, 28 Mar 1985 14:15 EST Message-ID: Sender: FAHLMAN@CMU-CS-C.ARPA From: "Scott E. Fahlman" To: "David A. Moon" Cc: common-lisp@SU-AI.ARPA, Earl Killian Subject: values-list In-reply-to: Msg of 28 Mar 1985 13:36-EST from David A. Moon Ooops, my reply was indeed about Multiple-Value-List. If EAK did indeed mean that he wanted Values-List to take args like apply, I agree with Moon that just using apply here solves the problem without adding any extra hair to the language. This week's confusion score stands at Moon 1, Fahlman 1. Look's like we're headed for overtime to break the tie. -- Scott  Received: from SU-AI.ARPA by MIT-MC.ARPA; 28 MAR 85 13:53:53 EST Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 28 Mar 85 10:35:58 PST Received: from SCRC-EUPHRATES by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 204967; Thu 28-Mar-85 13:18:36-EST Date: Thu, 28 Mar 85 13:19 EST From: David A. Moon Subject: Implementation of MAP, SOME, EVERY, etc... To: Scott E. Fahlman cc: common-lisp@SU-AI.ARPA In-Reply-To: Message-ID: <850328131955.5.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Wed, 27 Mar 1985 23:19 EST From: "Scott E. Fahlman" Moon claims: The Common Lisp LENGTH function returns NIL when given a circular list. I disagree. On page 265 of the aluminum edition, we find the following quote: "LIST-LENGTH differs from LENGTH when the list is circular; LENGTH may fail to return, whereas LIST-LENGTH will return NIL." The feeling was that LENGTH was used often, and we didn't want to require that it run more slowly on all lists just to accommodate the rare case of a circular list. My mistake. LENGTH used to check for circular lists, and when that feature was removed from the language we saw no reason to remove it from our implementation. I foolishly relied on memory and trying an example, rather than checking the manual.  Received: from SU-AI.ARPA by MIT-MC.ARPA; 28 MAR 85 09:12:51 EST Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 28 Mar 85 05:52:50 PST Received: from SCRC-EUPHRATES by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 204544; Wed 27-Mar-85 20:08:58-EST Date: Wed, 27 Mar 85 20:09 EST From: David A. Moon Subject: [Gall: Bug Report] To: common-lisp@SU-AI.ARPA In-Reply-To: , The message of 19 Mar 85 21:53-EST from Fahlman at CMU-CS-C, , The message of 21 Mar 85 00:49-EST from Gall@MIT-MULTICS.ARPA, <850321054958.626398@MIT-MULTICS.ARPA> Message-ID: <850327200955.6.MOON@EUPHRATES.SCRC.Symbolics.COM> Here are some comments on -portions- of the two long messages from Nick Gall. !section 9.1(6) Nick Gall 85-03-19 !version Digital Press 1984 !topic Pervasiveness of declarations over FLET and LABELS Example: (defun the-many-function-names-foo (x) (declare (inline foo)) (foo x) ; First call of FOO (flet ((foo (y z) (zap z y))) (foo x x)) ; Second call of FOO (foo x)) ; Third call of FOO .... Declarations concerning function names should be treated as special variable declarartions are: references are pervasively affected, but not bindings. Agreed. There are a number of areas in the language where the implications of adding FLET and LABELS (thus adding local function definitions) were not immediately obvious and therefore were not reflected in other parts of the manual. !section 9.1(12) Nick Gall 85-03-19 !version Digital Press 1984 !topic Non-Top-Level use of PROCLAIM Can PROCLAIM be used, other than at top-level? Since DEFVAR, etc., are proclamations and can be used at other than top-level, the answer to this question seems to be `yes'. Agreed. Is PROCLAIM a `declaration', i.e., must it appear only where a declaration is allowed? Since it is allowed at top-level (unlike DECLARE), and it is a function, and since the other proclaiming forms (e.g. DEFVAR, etc.) could not be considered declarations (since they perform evaluation and assignment), the answer must be no. Agreed. Then what is the effect of using PROCLAIM (or one one the other proclaiming forms) in the middle of a function? For example: (defun foo (a) (zap a) (proclaim '(special a)) (zark a)) Does the first reference to A refer to the local binding? Does the second reference refer to the global? PROCLAIM is merely a function, and has effect when it is called, not when a call to it is compiled. Your example might be rewritten as (defun foo (a) (zap a) (eval-when (compile) (proclaim '(special a))) (zark a)) were EVAL-WHEN permitted inside a function body (it is not; see p.66). Of course you could write a macro that evaluates the PROCLAIM at macro expansion time. If you did so, you could properly be castigated for using incomprehensible programming style, and I presume your program would execute differently in different Common Lisp compilers and interpreters. Some mention of the effects of the non-top-level use of PROCLAIM and the other proclaiming forms should be made. On p.66 it says that DEFVAR is not allowed elsewhere than top-level. PROCLAIM is the only function (rather than special form) that makes declarations, and presumably the declarations it makes when it is called take effect "immediately", but the exact definition of "immediately" might be implementation-dependent. For example, it is implementation- dependent whether PROCLAIM affects interpreted functions that have already been defined. ----------------------------------------------------------------- !section 7.5(14) Nick Gall 85-03-19 !version Digital Press 1984 !topic Scope and Extent of local function names NOTE: See 9.2 (ftype, function, inline). Example: (DEFUN CREATE-MAKEP (MAKE) (FLET ((CAR (SYMBOL) (GET SYMBOL 'AUTOMOBILE))) #'(LAMBDA (OWNER) (EQ MAKE (CAR OWNER))))) (SETQ FOO (CREATE-MAKEP 'HONDA)) (FUNCALL FOO 'BILL) => ????? Question: What does CAR refer to when it is used in the closure returned by CREATE-MAKEP? I.E., What is the scope and extent of the binding of a local function name to a functional object? Section 7.1(1) states that "There are two spaces of variables in Common Lisp, in effect: ordinary variables and function names." And the function name binding control structures appear in the section entitled "Establishing New Variable Bindings". Lexical function name bindings and lexical variable name bindings are treated identically. This should, of course, be discussed in chapter 3. See above comment about the implications of FLET and LABELS not having been fully thought out and reflected in the manual. I suggest that Common Lisp go all the way, and allow a SPECIAL-FUNCTION-NAME declaration that would be analogous to the SPECIAL declaration for "ordinary" variables. Such a concept would make the idea of ordinary-variable/function-name binding and assignment much more consistent. As I recall this was considered and rejected on the basis that it would be confusing and wouldn't give any real increase in expressive power (since FUNCALL of a special variable could be used). I agree with that decision, even though our implementation has always had the feature. The only place where we use it is in a crock that could just as well be done some other way. ----------------------------------------------------------------- !section 10.3(9) Nick Gall 85-03-19 !version Digital Press 1984 !topic Which bindings are copied by COPY-SYMBOL? "the initial value and function-definition of the new symbol will be the same as those of SYM..." Does this mean that the (dynamic) value of the variable referred to by SYM, at the point where COPY-SYMBOL symbol is invoked, is copied? Or, does it mean that the `initial', i.e. global value of the special variable named by SYM is copied? Although the wording seems to suggest the latter, it should be made clearer. The word "initial" was meant to refer to the new symbol, not the old symbol, I believe. Probably no one realized the English could be regarded as ambiguous. The same questions and suggestion applies to the function-definition copied by COPY-SYMBOL. ----------------------------------------------------------------- !section 15.5(8) Nick Gall 85-03-19 !version Digital Press 1984 !topic Is (TAILP NIL list) true or false for every list? False. By the way, the index entry for TAILP contains a typographical error and furthermore the function is documented in the wrong section (it's hard to see a justification for regarding it as an operation on sets). "...TAILP is true if (NTHCDR n list) is sublist, for some value of N." According to this definition NIL is a sublist of every list, since the (NTHCDR (LENGTH list) list) is NIL for every LIST. Yes, this side comment in the text would better have been omitted. ----------------------------------------------------------------- !section 20.1(7) Nick Gall 85-03-19 !version Digital Press 1984 !topic Is *APPLYHOOK* funcalled for special forms? "The variable *APPLYHOOK* ... is used when a function is about to be applied to arguments." Does `function' refer to a functional object which is in fact a function (i.e., its args. are evaled before it is called), or does it refer to any functional object (e.g., `special' functional objects)? Special forms are excluded. Later in the paragraph, it is stated that, The apply hook function is used only for application of ordinary functions within eval. It is not used for applications via apply, or funcall, for applications by such functions as map or reduce, or for invocation of macro-expansion functions... This paragraph does not really address the "application of ordinary functions within eval" but rather the "ordinary application of functions by eval." I disagree (but this may be an ambiguity of English). Also it does not clarify the action taken for special forms. Indeed, it ought to say something like "linkage from EVAL to special forms." Part of the problem is that there is no way, in Common Lisp, to describe the intercommunication between EVAL and special forms, since it is implementation-dependent and the language provides no way for the user to add new special forms. This is not a deficiency in the language (in my opinion), just something that makes it hard to fit special forms into that paragraph of documentation. ----------------------------------------------------------------- !section 20.1(last-1) Nick Gall 85-03-19 !version Digital Press 1984 !topic Is nil declared by defconstant? ...all constant symbols declared by DEFCONSTANT, such as NIL, T, and PI. If NIL is declared by DEFCONSTANT then it can legally be redefined according to section 5.1.2(last): Constant symbols defined by DEFCONSTANT ... may be redefined, if necessary, by using DEFCONSTANT again[]. Is such an interpretation correct? I do not believe that system-supplied constants can legally be redefined. ----------------------------------------------------------------- !section 4.8(1) Nick Gall 85-03-19 !version Digital Press 1984 !topic The meaning of the word `convert' Does coerce `convert' (i.e., change the type bits) and return the original object (or the pointer if typed pointers are supported) when possible (e.g., coercing a string to an array of (unsigned-byte 8) in some implementations); or does coerce ALWAYS create and return a new `equivalent' object; or does the Common Lisp spec. not define this? Common Lisp does not specify sharing or non-sharing of storage between the argument and result of COERCE. I don't see how it could, since this is necessarily very implementation-dependent. But the documentation could be clearer. !section 11.7 Nick Gall 85-03-20 !version Digital Press 1984 !topic INTERN's effect on an accessible symbol's owner. As a verb, to `intern' a symbol in a package means to cause the symbol to be interned (sic) in the package if it was not already; this function is performed by the function INTERN. If the symbol was previously unowned, then the package it is being interned in becomes its owner (home package)... CLRM Section 11.0 (pg. 172) I interpret this passage in the following way: ;; Current package is USER * (setf p1 (make-package 'p1 :use '())) {printed rep. of p1} * (import 'p1::xyzzy) T * (symbol-package 'xyzzy) {printed rep. of p1} * (unintern 'xyzzy p1) T * (symbol-package 'xyzzy) NIL * (intern "XYZZY") XYZZY :INTERNAL * (symbol-package 'xyzzy) {printed rep. of user} In other words, INTERN ensures that the symbol that it returns as its first value has a home package. Is this interpretation correct? I think the mention of accessible but unowned symbols on page 172 (in the discussion of home packages) shoots down your example. The result of the last call to SYMBOL-PACKAGE is probably undefined. ------------------------------------------------------------ !section 11.7 Nick Gall 85-03-20 !version Digital Press 1984 !topic UNINTERNing a shadowing-symbol UNINTERN: When uninterning a shadowing symbol (call it foo), UNINTERN collects all inherited symbols with the same print-name as foo, including foo (assuming foo was inherited). If the name conflict is only between foo and one other symbol, what sense does it make to signal a name conflict error and give the user a choice between shadow-importing foo and the other symbol. If the user chooses foo, it is no different from aborting from the error. In the above case, shouldn't UNINTERN just automatically shadow-import the other symbol? Surely it is a bad idea to guess the user's intent in this pathological case, rather than asking. I suppose it would be legal for a debugger not to offer the redundant option of shadowing-importing foo again, although that doesn't seem like a feature of great importance. I hope someone is listening to comments on unclarities in the manual, such as Gall's, and that someday a revised and improved manual will be issued. The Common Lisp community is hardly in possession of the same resources as the Ada community, so I don't think we can realistically expect as precise a specification as Ada enjoys.  Received: from SU-AI.ARPA by MIT-MC.ARPA; 27 MAR 85 23:28:25 EST Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 27 Mar 85 20:20:08 PST Received: ID ; Wed 27 Mar 85 23:19:20-EST Date: Wed, 27 Mar 1985 23:19 EST Message-ID: Sender: FAHLMAN@CMU-CS-C.ARPA From: "Scott E. Fahlman" To: "David A. Moon" Cc: common-lisp@SU-AI.ARPA Subject: Implementation of MAP, SOME, EVERY, etc... In-reply-to: Msg of 27 Mar 1985 16:17-EST from David A. Moon Moon claims: The Common Lisp LENGTH function returns NIL when given a circular list. I disagree. On page 265 of the aluminum edition, we find the following quote: "LIST-LENGTH differs from LENGTH when the list is circular; LENGTH may fail to return, whereas LIST-LENGTH will return NIL." The feeling was that LENGTH was used often, and we didn't want to require that it run more slowly on all lists just to accommodate the rare case of a circular list. -- Scott  Received: from SU-AI.ARPA by MIT-MC.ARPA; 27 MAR 85 22:55:01 EST Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 27 Mar 85 16:40:16 PST Received: ID ; Wed 27 Mar 85 19:39:45-EST Date: Wed, 27 Mar 1985 19:39 EST Message-ID: Sender: FAHLMAN@CMU-CS-C.ARPA From: "Scott E. Fahlman" To: Earl Killian Cc: common-lisp@SU-AI.ARPA Subject: multiple-value-setq In-reply-to: Msg of 27 Mar 1985 14:14-EST from Earl Killian Comment: Remailed after delay caused by distribution list error at SU-AI. Is this really multiple-value-setf? I.e. can the list be a list of places or just a list of variables? Multiple-Value-Setq definitely does not take SETF-style place names. I think that the manual is quite clear on this. Whether there should be an M-V-SETF is another issue, but I don't think there's much demand for this. I've seen very few uses of M-V-SETQ, as compared with M-V-BIND. -- Scott  Received: from SU-AI.ARPA by MIT-MC.ARPA; 27 MAR 85 22:37:49 EST Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 27 Mar 85 14:13:39 PST Received: ID ; Wed 27 Mar 85 17:12:29-EST Date: Wed, 27 Mar 1985 17:12 EST Message-ID: Sender: FAHLMAN@CMU-CS-C.ARPA From: "Scott E. Fahlman" To: "David A. Moon" Cc: common-lisp@SU-AI.ARPA Subject: do-xxx-symbols In-reply-to: Msg of 27 Mar 1985 16:06-EST from David A. Moon Comment: Remailed after delay caused by distribution list error at SU-AI. I thought that you had been unusually quiet of late. Of course, certain implementations of packages (ones that hash symbols redundantly in every package that inherits them, so that INTERN need do only a single hash lookup regardless of the length of the use-list) would never encounter such bugs. Perhaps the language should be based on such a simple implementation as a standard, and other implementations that try to save space are responsible for not deviating from that standard. Opinions? I think that requiring adherence to a model that is conceptually simple but that imposes a very heavy (and in my opinion, unacceptable) cost in space is the wrong move here, unless you can demonstrate some reasonable way of adhering to that model without incurring these costs. To just asy "it's the implementor's problem" is a good way to either make the language unusable because of the adherence to impractical models or to get the implementors to decide to deviate from the standard rather than pay these costs. Yes, I know we've done it before in this language, but in a couple of cases we've come to regret it. -- Scott  Received: from SU-AI.ARPA by MIT-MC.ARPA; 27 MAR 85 22:36:36 EST Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 27 Mar 85 16:51:22 PST Received: ID ; Wed 27 Mar 85 19:50:43-EST Date: Wed, 27 Mar 1985 19:50 EST Message-ID: Sender: FAHLMAN@CMU-CS-C.ARPA From: "Scott E. Fahlman" To: Earl Killian Cc: common-lisp@SU-AI.ARPA Subject: values-list In-reply-to: Msg of 27 Mar 1985 14:10-EST from Earl Killian Comment: Remailed after delay caused by distribution list error at SU-AI. A useful extension to values-list would be to make it take multiple arguments the way apply does, i.e. all but the last are values to return and the last is a list of further values to return. You can easily get the effect you want with a macro, as long as you're willing to cons all the returned values into a list at some point. I guess your point is that sometimes you don't know how many values to expect, but would like to handle the first few without consing via values-list. Multiple-Value-Call with a &rest arg gives you this effect, but forces you to do a function call that might be superfluous. So there is a niche for your proposed mechanism, but I don't think it's a common enough situation to worry about. The only cases I've seen where you don't know how many args are coming back would not be bothered by the overhead of the function call or the values-list; in the tense cases, you generally how many args to expect. -- Scott  Received: from SU-AI.ARPA by MIT-MC.ARPA; 27 MAR 85 21:58:38 EST Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 27 Mar 85 13:39:50 PST Received: from SCRC-EUPHRATES by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 204367; Wed 27-Mar-85 16:16:13-EST Date: Wed, 27 Mar 85 16:17 EST From: David A. Moon Subject: Implementation of MAP, SOME, EVERY, etc... To: Dan Corkill cc: common-lisp@SU-AI.ARPA In-Reply-To: The message of 19 Mar 85 11:58-EST from Dan Corkill Message-ID: <850327161712.2.MOON@EUPHRATES.SCRC.Symbolics.COM> Comment: Message remailed after delay caused by distribution list error. Date: Tue, 19 Mar 85 11:58 EST From: Dan Corkill There is an easily made implementation error in MAP, SOME, EVERY, etc. The published semantics indicate that these functions use the length of the shortest argument sequence to determine how many iterations to perform (and in this way parallel the semantics of mapc, mapcar, etc.). Thus it would appear that: (map 'list '+ '(1 2 3) (star 2)) where star builds a circular list of its argument should be legal and return => (3 4 5). Implementations that use length to check the length of argument sequences will break on such a call. The Common Lisp LENGTH function returns NIL when given a circular list.  Received: from SU-AI.ARPA by MIT-MC.ARPA; 27 MAR 85 21:39:50 EST Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 27 Mar 85 13:35:07 PST Received: from SCRC-EUPHRATES by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 204359; Wed 27-Mar-85 16:05:30-EST Date: Wed, 27 Mar 85 16:06 EST From: David A. Moon Subject: do-xxx-symbols To: Rob MacLachlan , Scott E. Fahlman , Charles Hedrick cc: common-lisp@SU-AI.ARPA, Moon@SCRC-STONY-BROOK.ARPA In-Reply-To: , , The message of 4 Mar 85 19:05-EST from Charles Hedrick , The message of 4 Mar 85 21:50-EST from Charles Hedrick , , The message of 4 Mar 85 23:34-EST from Charles Hedrick Message-ID: <850327160624.1.MOON@EUPHRATES.SCRC.Symbolics.COM> Comment: Message remailed after delay caused by distribution list error. Due to some kind of mail problem I didn't see this conversation until today. We take DO-SYMBOLS to mean to iterate over all symbols accessible to this package, including ones that are inherited from other packages. That seems like the most reasonable interpretation of what the manual says. I agree with Scott that the authors of the manual never imagined that other interpretations were possible. We provide DO-LOCAL-SYMBOLS as an extension. It iterates over only symbols present in the specified package. Our DO-SYMBOLS has the usual bug with shadowed symbols: its iteration includes symbols that would have been inherited had they not been shadowed. I think it's clear that this is a bug and not an allowable interpretation of the manual. Our DO-SYMBOLS has the usual bug with unnecessarily imported or exported symbols: its iteration sees a symbol more than once if that symbol is imported even though it would have been inherited, or is exported from two used packages. Perhaps this case is rare enough in practice, and difficult enough to test for, that the manual should be changed to say that a symbol can be seen more than once, as Scott suggested. Of course, certain implementations of packages (ones that hash symbols redundantly in every package that inherits them, so that INTERN need do only a single hash lookup regardless of the length of the use-list) would never encounter such bugs. Perhaps the language should be based on such a simple implementation as a standard, and other implementations that try to save space are responsible for not deviating from that standard. Opinions?  Received: from SU-AI.ARPA by MIT-MC.ARPA; 27 MAR 85 15:50:28 EST Received: from S1-B.ARPA by SU-AI.ARPA with TCP; 27 Mar 85 12:41:03 PST Received: by angband.ARPA id AA00664; Wed, 27 Mar 85 11:10:55 pst id AA00664; Wed, 27 Mar 85 11:10:55 pst Date: Wed, 27 Mar 85 11:10:55 pst From: Earl Killian Message-Id: <8503271910.AA00664@angband.ARPA> To: common-lisp@su-ai.ARPA Subject: values-list A useful extension to values-list would be to make it take multiple arguments the way apply does, i.e. all but the last are values to return and the last is a list of further values to return.  Received: from SU-AI.ARPA by MIT-MC.ARPA; 27 MAR 85 15:50:00 EST Received: from S1-B.ARPA by SU-AI.ARPA with TCP; 27 Mar 85 12:40:51 PST Received: by angband.ARPA id AA00677; Wed, 27 Mar 85 11:14:11 pst id AA00677; Wed, 27 Mar 85 11:14:11 pst Date: Wed, 27 Mar 85 11:14:11 pst From: Earl Killian Message-Id: <8503271914.AA00677@angband.ARPA> To: common-lisp@su-ai.ARPA Subject: multiple-value-setq Is this really multiple-value-setf? I.e. can the list be a list of places or just a list of variables?  Received: from SU-AI.ARPA by MIT-MC.ARPA; 26 MAR 85 06:24:01 EST Date: 26 Mar 85 0312 PST From: Jon White Subject: Previous note about DELFILE/DWIM To: common-lisp@SU-AI.ARPA My apologies for this note getting onto the mailing list -- it was not intended for Common Lisp, but rather for Bug-1100. The spazz was partly my fault, and partly a "gift" from the wonderful featurfulness of the su-ai editor/mailer. -- JonL --  Received: from SU-AI.ARPA by MIT-MC.ARPA; 25 MAR 85 22:26:16 EST Date: 25 Mar 85 1914 PST From: Jon White Subject: Excluding some symbols from DO-ALL-SYMBOLS To: Hedrick@RUTGERS.ARPA CC: Common-Lisp@SU-AI.ARPA Re your message of 4-Mar-85 19:05 EST I'm a little bit apprehensive about having two "functions" to iterater over "all the symbols of interest" -- How about instead of introducing the second one [do-most-symbols] we simply introduce a new global variable called, say, *do-all-symbols-exclusions* This list would merely exclude some of the packages which would otherwise be the output of list-all-packages. This way, not only could the compiler internal symbols be omitted, but any other package which a user develops could also be, temporarily or permanently, excluded. I'm currently thinking that this facility would not exclude the external symbols of those packages. -- JonL --  Received: from SU-AI.ARPA by MIT-MC.ARPA; 25 MAR 85 21:44:10 EST Date: 25 Mar 85 1831 PST From: Jon White Subject: DELFILE, thanks to DWIM To: DHare@SRI-CSL.ARPA CC: Common-Lisp@SU-AI.ARPA Apart from the failure to ask if you wanted the "correction" GETFILE into DELFILE, there is also the question of why DELFILE was happy with the extra argument (in your example, 'SIZE). Common Lisp programs have the notion of argument-number checking, and many spurious forms like (DELFILE 'FOO.BAR 'SIZE) would be rejected at that level. Argument-number checking isn't completely incompatible with Interlisp -- or at least the use of Interlisp without unwarranted DWIM interference. All that would be required is the breaking of the rather dubious contract that *all* functions must have *all* arguments in the category of "optional and defaulting to NIL". Totaly leaving aside the question of backwards compatibility with all those never-changing Interlisp programs dating back to the 1960's, it would be instructive to know what percentage of current users feel that the current situation of *no* argment-number checking is completely satisfactory. The alternative need not require explicity NIL's in calling code, since many functions may want some kind of &optional behaviour anyway. -- JonL --  Received: from SU-AI.ARPA by MIT-MC.ARPA; 22 MAR 85 01:30:42 EST Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 21 Mar 85 22:18:39 PST Received: from umass-cs by csnet-relay.csnet id ag24346; 22 Mar 85 1:07 EST Date: Thu, 21 Mar 85 13:21 EST From: Dan Corkill To: common-lisp@su-ai.ARPA Subject: More on MAP, SOME, EVERY, etc..... As I expected, my flame about MAP, SOME, EVERY, etc. has raised some important issues..... First, RAM suggests that viewing a circular list as a dotted list avoids the problem: > The definition of a normal list in the Lists chapter is one > terminated by NIL. By this definition, a circular list is a dotted > list. I believe that there was a decision at one point that functions > which use lists as sequences (a superset of the sequence functions) > are allowed to complain about dotted lists. This is implied by the > statement that Endp is the canonical list-end predicate. However, the next sentence from that chapter argues that a circular list CANNOT be a dotted list: ``A list whose cdr chain is terminated by some non-nil atom is called a dotted list.'' Clearly, a circular list is not terminated by some non-NIL atom (is it terminated at all?), and ENDP cannot be used to detect a circular list. ~~ An aside --- As the CLM is unclear on whether or not a circular is ~~ is an ORDINARY or DOTTED list, I would argue that it is better ~~ viewed as an ORDINARY list. In a sense a circular list is a list ~~ that shares structure with itself. Unless destructive functions ~~ are applied to a circular list, it behaves identically to an ~~ infinite list. Further supporting this position is the observation ~~ that mapc, mapcar, etc. work with circular list arguments and ~~ generate errors with dotted (non-circular) list arguments. *** Back to the original complaint about MAP, SOME, EVERY, etc. *** Under the premise that a circular list is NOT a dotted list, the implementation of MAP, SOME, EVERY, etc. should not care whether or not an argument sequence is circular or not. (It should be up to the user to worry about the effects of any destructive changes to an arglist. I suggest that all the following should be legal: (map 'list '+ '(1 2 3) (star 5)) => (6 7 8) ;; (defun star (&REST arglist) ;; (nconc arglist arglist)) (some 'char< "string" (star #\x)) => t (map 'array '#(2 3 4) (star 5)) => #(7 8 9) (replace '(1 2 3 4 5) (star -1) :START1 2 :END1 4)) => (1 2 -1 -1 5) ;; Note that (replace (star -1) '(1 2 3 4 5) :start1 2 :end1 4) ;; should not be expected to produce (-1 -1 1 2 -1 ... ). But ;; should be undefined as to what it does. I agree with Dave Dyer that the programmer shouldn't have to know anything about the lists passed to MAPxxx except that the shortest sequence (if a list) is a proper list. I would hope that even the following would be legal: (map 'list '+ '(1 2 3) '(1 2 3 4 5 . 6)) => (2 4 6) I also agree that the use of LENGTH for lists is a poor implementation technique, and Dave's admonition against the use of LENGTH in system functions unless all elements are guaranteed to be inspected is reasonable. In summary, I believe that implementations of MAP, SOME, EVERY, etc. using LENGTH do not follow the semantics of the CLM and are inconsistent with the usual behavior of the traditional list mapping functions. I strongly suggest that it is the implementations that are incorrect rather than ambiguity in the semantics and argue that merely changing the descriptions to explicitly exclude circular lists greatly curtails the utility of the sequence functions. Dan Corkill Cork@UMass  Received: from SU-AI.ARPA by MIT-MC.ARPA; 21 MAR 85 17:01:44 EST Received: from MIT-MULTICS.ARPA by SU-AI.ARPA with TCP; 21 Mar 85 13:52:41 PST Date: Thu, 21 Mar 85 16:49 EST From: Nick Gall Subject: Lost bet To: common-lisp@SU-AI.ARPA Message-ID: <850321214921.734669@MIT-MULTICS.ARPA> (defun foo () (let ((const 1)) const)) (defconstant const 2) ;; Compiler should issue a warning about ;; the use of lexical variable const in ;; foo. (defun bar () (let ((const 2)) const) ;; Compiler should signal an ;; error about the binding of a ;; constant. I guess I lose my bet. -- Nick  Received: from SU-AI.ARPA by MIT-MC.ARPA; 21 MAR 85 16:26:36 EST Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 21 Mar 85 13:16:47 PST Received: ID ; Thu 21 Mar 85 16:15:50-EST Date: Thu, 21 Mar 1985 16:15 EST Message-ID: Sender: FAHLMAN@CMU-CS-C.ARPA From: "Scott E. Fahlman" To: Nick Gall Cc: common-lisp@SU-AI.ARPA, Rob MacLachlan Subject: Follow-up and New Questions In-reply-to: Msg of 21 Mar 1985 15:57-EST from Nick Gall Let's just issue the warning "Attempting to bind a constant, FOO, as a variable" and let it go at that. No point in arguing about what kind of variable it would be if this illegal operation weren't illegal. -- Scott  Received: from SU-AI.ARPA by MIT-MC.ARPA; 21 MAR 85 16:14:10 EST Received: from MIT-MULTICS.ARPA by SU-AI.ARPA with TCP; 21 Mar 85 13:02:16 PST Date: Thu, 21 Mar 85 15:57 EST From: Nick Gall Subject: Re: Follow-up and New Questions To: Rob MacLachlan cc: common-lisp@SU-AI.ARPA In-Reply-To: Message of 21 Mar 85 04:04 EST from "Rob MacLachlan" Message-ID: <850321205739.178211@MIT-MULTICS.ARPA> Given a piece of code like (defconstant const ...) (defun foo () (let ((const 1)) ...)) I am not saying that the compiler would not object. I am saying that WHEN it objected, the message MUST NOT be Warning: Binding a LEXICAL variable with the same name as a constant. it SHOULD be Error: Attempting to bind a SPECIAL variable defined by DEFCONSTANT. It can't be the first message, because DEFCONSTANT, by doing an implicit (proclaim '(special const)) (which pervasively affect BINDINGS and references) FORCES the compiler to assume that the LET form is binding a SPECIAL variable, not a LEXICAL variable. To put it briefly, I was merely arguing that the variable name `const' in the LET form could not possibly considered a LEXICAL variable (so how could the compiler warn me about a `lexical' variable?). -- Nick  Received: from SU-AI.ARPA by MIT-MC.ARPA; 21 MAR 85 06:56:49 EST Received: from USC-ISIB.ARPA by SU-AI.ARPA with TCP; 20 Mar 85 20:32:02 PST Date: 20 Mar 1985 20:07:05 PST Subject: Re: Implementation of MAP, SOME, EVERY, etc... From: Dave Dyer To: Rob MacLachlan , common-lisp@SU-AI.ARPA In-Reply-To: I disagree with RAM; Imposing the requirement that all lists passed to MAPxxx be "proper" imposes an unnecesary burden on the use of mapping functions; The programmer shouldn't have to know anything about the lists passed to MAPxxx except that the sortest list is a proper list. Besides, it would be an extremely poor implementation technique to take LENGTH of all the lists before starting work -- I would say that system functions should NEVER use LENGTH unless it is otherwise known that the functin in question will inspect every element of the list anyway, both because lists might legitimately be "improper", and because lists can legitimately be very long, which makes LENGTH wasteful. -------  Received: from SU-AI.ARPA by MIT-MC.ARPA; 21 MAR 85 06:34:44 EST Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 21 Mar 85 01:11:02 PST Received: ID ; Thu 21 Mar 85 04:04:35-EST Date: Thu, 21 Mar 1985 04:04 EST Message-ID: From: Rob MacLachlan To: Nick Gall Cc: common-lisp@SU-AI.ARPA, REM@MIT-MC.ARPA Subject: Follow-up and New Questions In-reply-to: Msg of 21 Mar 1985 00:49-EST from Nick Gall From: Nick Gall To: common-lisp at SU-AI.ARPA Re: Follow-up and New Questions Posted-Date: 21 Mar 85 00:52 EST So... there is no way the compiler could ever warn the user that they are using a lexical variable with the same name as a constant. To put it briefly, I bet you can't show me a piece of Common Lisp code that would cause such a warning. The Spice Lisp compiler would object. Similarity between special variables and constants is an implementation detail. The name names a constant, the compiler knows this, the compiler complains. Rob  Received: from SU-AI.ARPA by MIT-MC.ARPA; 21 MAR 85 06:28:44 EST Date: 20 Mar 85 2122 PST From: Jon White Subject: Implementation of MAP, SOME, etc To: common-lisp@SU-AI.ARPA Surely the CLM doesn't suggest that the implementation of these functions must call the LENGTH function -- whereas it may not hurt to do so for what I'd call "index access" datatypes, there are many reasons for not doing so on lists. The phrase I see in the manual is "... if the end of a sequence is reached ...", and this doesn't say how one determines that the end is reached. But the docmentation of ENDP suggests that it is the preferred way to answer the question for lists. -- JonL --  Received: from SU-AI.ARPA by MIT-MC.ARPA; 21 MAR 85 06:25:25 EST Received: from MIT-MULTICS.ARPA by SU-AI.ARPA with TCP; 20 Mar 85 21:52:19 PST Posted-Date: 21 Mar 85 00:52 EST Acknowledge-To: Nick Gall Date: Thu, 21 Mar 85 00:49 EST From: Nick Gall Subject: Follow-up and New Questions To: common-lisp@SU-AI.ARPA cc: RAM@CMU-CS-C.ARPA, REM@MIT-MC.ARPA Message-ID: <850321054958.626398@MIT-MULTICS.ARPA> ********** From: Robert Elton Maas To:Gall@MIT-MULTICS.ARPA Subject:Compiler warning msgs > !section 5.3.2(7) Nick Gall 85-03-19 > !version Digital Press 1984 > !topic Lexical variable with the same name as a named constant > ... (illegal, can't do it) > If this is the case, when would the compiler ever have the > opportunity to > ...issue warnings about bindings of the lexical variable of > the same name [as a name declared by DEFCONSTANT to be > constant]. My guess is what is meant by "warning" is "nonfatal diagnostic message", i.e. the construction is illegal and the compiler can't possibly compile it into correct code, but the error doesn't crash the compiler, the compiler merely issues a diagnostic (warning) and proceeds to try to recover and compile the rest of the file. I think you misunderstood my question. Take this code for example: (defconstant const ...) (defun foo () (let ((const 1)) ...)) One might think that the LET is binding a lexical variable named CONST; it is not. LET is binding a special var. named CONST. This is due to the fact that defconstant does an implicit proclaim. This proclaim pervasively affects all bindings of the proclaimed var. This means that once a variable name appears in a defconstant, there is no context in which the interpreter or compiler would consider that name to be the name of a lexical variable. So... there is no way the compiler could ever warn the user that they are using a lexical variable with the same name as a constant. To put it briefly, I bet you can't show me a piece of Common Lisp code that would cause such a warning. ********** From: Robert Elton Maas To:common-lisp@SU-AI.ARPA CC:Gall@MIT-MULTICS.ARPA Subject: What should CLOSE return? Closed-channel-object, or truefilename. > !section 21.3(7) Nick Gall 85-03-19 > !version Digital Press 1984 > !topic What does CLOSE Return? > > I think it should return the STREAM it was given to close. This > would make it symmetric with OPEN: OPEN returns an open stream, > CLOSE returns a closed stream. That's not symmetric, that's coercive. OPEN and CLOSE are like matching parenthesis, one does it and the other undos it except for a residual side-effect. OPEN takes a name and returns an I/O channel (at the LISP level, an object that can be name an active stream of data). CLOSE takes an I/O channel and should return a name to be symmetric with OPEN. This would be an opportune time to solve race conditions where several users are making different versions of the same file at the same time by the trick of writing a temporary file and then renaming it during the CLOSE. At CLOSE the version number is determined, and at that moment before somebody can create a later version the lisp CLOSE function obtains the true filename of the particular version we created. You're right `symmetric' is the wrong adj. But I still think CLOSE should return the (closed) stream. It can't (always) return the truename of the file associated with the stream, since not all streams are associated with files. How can one rename a file `during' a CLOSE? CLOSE should not return until the stream is really closed (and the file associated with the stream is quiesent). To obtain the truename of a just closed file, one could write (truename (close x)) ; where x is bound to a file stream since truename will take a stream as an argument. (Unfortunately, the CLRM (23.1.2(5)) is only explicit about what truename does with an `open' stream.) ********** From: Rob MacLachlan Subject: Default attributes of copy due to SUBSEQ To: REM at MIT-MC cc: common-lisp at SU-AI, Gall at MIT-MULTICS The semantics that I favor (and those implemented by Spice Lisp) are that every Common Lisp function which returns an array returns a simple array unless the function is make-array or one of the arguments is eq to the result. This has the advantage of being a simple specification, and also allows the compiler to do more interesting type-inference. Your semantics are correct: Whenever a sequence function must construct and return a new vector, it always returns a SIMPLE vector (see section 2.5). Similarly, any strings will be simple strings. CLRM 14.0(last paragraph) Sorry I didn't see this sooner... ********** !section 11.7 Nick Gall 85-03-20 !version Digital Press 1984 !topic INTERN's effect on an accessible symbol's owner. As a verb, to `intern' a symbol in a package means to cause the symbol to be interned (sic) in the package if it was not already; this function is performed by the function INTERN. If the symbol was previously unowned, then the package it is being interned in becomes its owner (home package)... CLRM Section 11.0 (pg. 172) I interpret this passage in the following way: ;; Current package is USER * (setf p1 (make-package 'p1 :use '())) {printed rep. of p1} * (import 'p1::xyzzy) T * (symbol-package 'xyzzy) {printed rep. of p1} * (unintern 'xyzzy p1) T * (symbol-package 'xyzzy) NIL * (intern "XYZZY") XYZZY :INTERNAL * (symbol-package 'xyzzy) {printed rep. of user} In other words, INTERN ensures that the symbol that it returns as its first value has a home package. Is this interpretation correct? ------------------------------------------------------------ !section 11.7 Nick Gall 85-03-20 !version Digital Press 1984 !topic UNINTERNing a shadowing-symbol UNINTERN: When uninterning a shadowing symbol (call it foo), UNINTERN collects all inherited symbols with the same print-name as foo, including foo (assuming foo was inherited). If the name conflict is only between foo and one other symbol, what sense does it make to signal a name conflict error and give the user a choice between shadow-importing foo and the other symbol. If the user chooses foo, it is no different from aborting from the error. In the above case, shouldn't UNINTERN just automatically shadow-import the other symbol? ------------------------------------------------------------  Received: from SU-AI.ARPA by MIT-MC.ARPA; 21 MAR 85 06:21:35 EST Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 21 Mar 85 00:56:48 PST Received: ID ; Thu 21 Mar 85 03:56:22-EST Date: Thu, 21 Mar 1985 03:56 EST Message-ID: From: Rob MacLachlan To: Dave Dyer Cc: common-lisp@SU-AI.ARPA Subject: Implementation of MAP, SOME, EVERY, etc... In-reply-to: Msg of 20 Mar 1985 23:07-EST from Dave Dyer Our implementation of Map takes the length of every sequence; it is a page of code. When every sequence is a list, things are simple. Life is interesting when mapping over a list, a bit-vector and a string. Rob  Received: from SU-AI.ARPA by MIT-MC.ARPA; 21 MAR 85 06:19:15 EST Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 20 Mar 85 20:52:01 PST Received: ID ; Wed 20 Mar 85 23:21:34-EST Date: Wed, 20 Mar 1985 21:25 EST Message-ID: From: Rob MacLachlan To: common-lisp@SU-AI.ARPA Subject: [REM: destructive operations on circular emulation of infinite list] Date: 1985 March 20 03:01:16 PST (=GMT-8hr) From: Robert Elton Maas Sender: REM%IMSSS at SU-SCORE.ARPA (for undeliverable-mail notifications) Reply-To: REM at MIT-MC.ARPA To: RAM cc: "cork%umass-cs.csnet" at CSNET-RELAY.ARPA Re: destructive operations on circular emulation of infinite list Sent: to SU-AI.ARPA by IMSSS.? via ETHERNET with PUPFTP; 1985-Mar-20 14:51:18 PST (=GMT-8hr) > Date: Wed, 20 Mar 1985 05:07 EST > From: Rob MacLachlan > Subject: Implementation of MAP, SOME, EVERY, etc... > > I think that a sufficiently fascist interpretation of the CLM > would say that this is erroneous. Nowhere in the CLM is it stated > that a circular list is the same as an infinite list, and it is > unlikely that any implementation would consistently have those > semantics. Setting element 537 of an infinite list should only > change element 537. Setting element 537 in a one-element circular > list would probably change all the elements if it terminates. I agree. Mathematically if LISP emulates an infinite list by a circular list instead of by a continuation, and you ask LISP to make an infinite list, then if you ask LISP to change a single element, the circular list must be converted to a linear list up to the point of change so that only the single element you specify will get changed. A problem arises however if you fake out LISP by doing a RPLACD or NCONC et al yourself without telling LISP whether you really meant to end upwith a circular list (side-effects shared) or an emulation of an infinite lisp (unfold-on-modify). In that case CLM should say the result is implementation-dependent and such trick should be avoided in portable code. Rebuttal? > The definition of a normal list in the Lists chapter is one > terminated by NIL. By this definition, a circular list is a dotted > list. Does it say anything except a normal list is a dotted list? There are no other datatypes in the world? Or does it allow a third choice (infinite list, circular list, list-by-continuation, etc.) which it then fails to properly document? > I believe that there was a decision at one point that functions > which use lists as sequences (a superset of the sequence functions) > are allowed to complain about dotted lists. I think they should complain about (finite) dotted lists, but permit both normal lists and circular/infinite lists if the latter is/are permitted otherwise in CL. The semantics of MAPping down a set of lists none of which is normal nor dotted, should be that the process runs forever until a THROW-type event happens or the environment runs out of memory or another kind of error happens. For example, a reasonable hack would be to MAP down a circular list of ten elements and when a realtime interupt happens process the current cell and THROW out of the otherwise-infinite loop, thereby processing a random element from a finite set. Or MAP down a circular list of devices trying to find one that is available, looping forever if none of them ever become free, otherwise using the first random one that becomes free. The code for looping in a circular list seems to me cleaner than using a 2-level loop with the outer loop DOing FOREVER the inner finite loop. If the manual is unclear, I favor the above. If the manual clearly forbids my interpretation, then I guess it's too late to change it.  Received: from SU-AI.ARPA by MIT-MC.ARPA; 21 MAR 85 06:17:47 EST Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 20 Mar 85 20:52:25 PST Received: ID ; Wed 20 Mar 85 23:21:37-EST Date: Wed, 20 Mar 1985 21:25 EST Message-ID: From: Rob MacLachlan To: common-lisp@SU-AI.ARPA Subject: [REM: Query (FILE-LENGTH in particular) of file by name when open] Date: 1985 March 20 02:44:29 PST (=GMT-8hr) From: Robert Elton Maas Sender: REM%IMSSS at SU-SCORE.ARPA (for undeliverable-mail notifications) Reply-To: REM at MIT-MC.ARPA To: RAM Re: Query (FILE-LENGTH in particular) of file by name when open Sent: to SU-AI.ARPA by IMSSS.? via ETHERNET with PUPFTP; 1985-Mar-20 14:51:03 PST (=GMT-8hr) > Date: Wed, 20 Mar 1985 04:31 EST > From: Rob MacLachlan > Subject: Length of currently-open-for-write file is ambiguous or meaningless > > The meaning of File-Length on the name of a file which is open for > write seems operating system dependant, and should be undefined. Since > it is in fact this case which I understand to be the basis for not > allowing file-length on file names, taking this stand would dispose of > any problems. May I take it that you mostly agree with me on this point, that the ambiguity I pointed out (size of file before during or after current update), and you're saying the default (or only possible implementation) should be to signal an error if the file you happen to ask about by name is currently open for write? (Therefore the general idea of asking about a file by name is well-defined and should be provided by CL: if the file is open-for-write the query signals an error, else the query works as expected?) If so, I think we've reached 2-party concensus (I yield on the other point you made about query on lisp I/O-channel-object being meaningful).  Received: from SU-AI.ARPA by MIT-MC.ARPA; 21 MAR 85 06:16:35 EST Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 20 Mar 85 20:52:45 PST Received: ID ; Wed 20 Mar 85 23:21:39-EST Date: Wed, 20 Mar 1985 21:30 EST Message-ID: From: Rob MacLachlan To: REM@MIT-MC.ARPA cc: common-lisp@SU-AI.ARPA Subject: Query (FILE-LENGTH in particular) of file by name when open In-reply-to: Msg of 1985 Mar 20 02:44:29 PST (=GMT-8hr) from Robert Elton Maas I don't think we can require it to signal an error, since some operating systems don't provide any way to tell if a file is open. In Spice, for example, there is no open call, so the question isn't even meaningful. I think that all we can say is that it is an error, and implementations are encouraged to detect it, or at least not delete all you files and crash the machine. Rob  Received: from SU-AI.ARPA by MIT-MC.ARPA; 20 MAR 85 05:13:46 EST Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 20 Mar 85 02:08:14 PST Received: ID ; Wed 20 Mar 85 05:07:23-EST Date: Wed, 20 Mar 1985 05:07 EST Message-ID: From: Rob MacLachlan To: Dan Corkill Cc: common-lisp@SU-AI.ARPA Subject: Implementation of MAP, SOME, EVERY, etc... In-reply-to: Msg of 19 Mar 1985 11:58-EST from Dan Corkill I think that a sufficiently fascist interpretation of the CLM would say that this is erroneous. Nowhere in the CLM is it stated that a circular list is the same as an infinite list, and it is unlikely that any implementation would consistently have those semantics. Setting element 537 of an infinite list should only change element 537. Setting element 537 in a one-element circular list would probably change all the elements if it terminates. The definition of a normal list in the Lists chapter is one terminated by NIL. By this definition, a circular list is a dotted list. I believe that there was a decision at one point that functions which use lists as sequences (a superset of the sequence functions) are allowed to complain about dotted lists. This is implied by the statement that Endp is the canonical list-end predicate. Rob  Received: from SU-AI.ARPA by MIT-MC.ARPA; 20 MAR 85 04:50:53 EST Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 20 Mar 85 01:44:21 PST Received: ID ; Wed 20 Mar 85 04:43:45-EST Date: Wed, 20 Mar 1985 04:43 EST Message-ID: From: Rob MacLachlan To: REM@MIT-MC.ARPA Cc: common-lisp@SU-AI.ARPA, Gall@MIT-MULTICS.ARPA Subject: Default attributes of copy due to SUBSEQ In-reply-to: Msg of 1985 Mar 19 21:23:38 PST (=GMT-8hr) from Robert Elton Maas Well, I guess that's a bit excessively simple if read literally. It could be "every function that creates an array creates a simple array unless that function is make-array". Rob  Received: from SU-AI.ARPA by MIT-MC.ARPA; 20 MAR 85 04:48:51 EST Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 20 Mar 85 01:41:32 PST Received: ID ; Wed 20 Mar 85 04:40:52-EST Date: Wed, 20 Mar 1985 04:40 EST Message-ID: From: Rob MacLachlan To: REM@MIT-MC.ARPA Cc: common-lisp@SU-AI.ARPA, Gall@MIT-MULTICS.ARPA Subject: Default attributes of copy due to SUBSEQ In-reply-to: Msg of 1985 Mar 19 21:23:38 PST (=GMT-8hr) from Robert Elton Maas The semantics that I favor (and those implemented by Spice Lisp) are that every Common Lisp function which returns an array returns a simple array unless the function is make-array or one of the arguments is eq to the result. This has the advantage of being a simple specification, and also allows the compiler to do more interesting type-inference. Rob  Received: from SU-AI.ARPA by MIT-MC.ARPA; 20 MAR 85 04:39:15 EST Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 20 Mar 85 01:32:15 PST Received: ID ; Wed 20 Mar 85 04:31:46-EST Date: Wed, 20 Mar 1985 04:31 EST Message-ID: From: Rob MacLachlan To: REM@MIT-MC.ARPA Cc: common-lisp@SU-AI.ARPA Subject: Length of currently-open-for-write file is ambiguous or meaningless In-reply-to: Msg of 1985 Mar 19 20:54:07 PST (=GMT-8hr) from Robert Elton Maas I think that file-length of a stream that is open for write is perfectly meaningful. file-length is the file-position of EOF. In the presence of multiple concurrent writers, the result may be ill-defined, but if that is the case, you are in bad trouble anyway. The meaning of File-Length on the name of a file which is open for write seems operating system dependant, and should be undefined. Since it is in fact this case which I understand to be the basis for not allowing file-length on file names, taking this stand would dispose of any problems. Rob  Received: from SU-AI.ARPA by MIT-MC.ARPA; 20 MAR 85 01:40:29 EST Sent: to SU-AI.ARPA by IMSSS.? via ETHERNET with PUPFTP; 1985-Mar-19 22:23:35 PST (=GMT-8hr) Date: 1985 March 19 20:54:07 PST (=GMT-8hr) Message-id: SU-IMSSS.REM.A132100054747.G0371 From: Robert Elton Maas To: common-lisp@SU-AI.ARPA CC: RAM@CMU-CS-C.ARPA Subject: Length of currently-open-for-write file is ambiguous or meaningless Sender: REM%IMSSS@SU-SCORE.ARPA (for undeliverable-mail notifications) Reply-to: REM@MIT-MC.ARPA > Date: Tue, 19 Mar 1985 16:42 EST > From: Rob MacLachlan > Subject: File-length on pathnames >... > - This "operating system open" call may have some requirement for > exclusive access. If some other process has the file open, then > the call to FILE-LENGTH may wait or fail. > - It is somehow more intuitive to have OPEN wait or fail than to > have FILE-LENGTH wait or fail. > > I think that if there is any implicit guarantee in the CLM > filesystem chapter that certain calls may not wait or fail whenever > they feel like it, then it is bogus. ... I agree completely with RAM, in fact I'd like to present a case that FILE-LENGTH is meaningless when a file is open for write access by self or by other task/user, and thus that it's quite reasonable for FILE-LENGTH to fail (signal an error). FILE-LENGTH is supposed to tell the length of the disk file, right? Well, if you're in the middle of modifying it, either by replacing it with a new version you're in the midst of creating, or by destructively modifying it and by changing the directory attributes (length, disk record map, etc.), what exactly do you mean by the length? (1) Length that it was before you started to modify it (that info probably already clobbered in case of destructive modification, although available if making new version which is not yet installed). (2) Length it will be when you close it (not known yet). (3) Some sort of momentary length as it currently exists (does that include I/O buffers which have been partially filled in RAM but not yet written to disk? buffers that have been written to disk but not yet included in directory? buffers that have been unwritten by decreasing the end-of-file pointer but haven't yet been expunged and thus still are part of the file in some sense that if the system crashed a wizard could recover them?) Perhaps the function should include an extra argument that tells whether you want the old info or a failure (error signal) or a wait-for-close then new info or the instantaneous-guess info in such an ambiguous case? Probably the default should be failure if you don't supply the &OPTIONAL or &KEYWORD argument. If a file is open only for read, I think there's no problem, the file can always be sized? (Or in a network environment, perhaps there is only one copy of the file at any time, and to size it you have to first move it to your site, which means nobody else can have it open for read elsewhere? In such a network it might fail even in case of open for read by somebody else on another site, and the extra argument might be needed to say what to do to resolve the problem.) Since even in the case of a file you have open yourself the above ambiguity can occur, with FILE-LENGTH of an I/O channel signalling an error, I see no problem with implementing FILE-LENGTH applied to filenames, where it's completely reasonable for the programmer to have to be aware it might signal an error at random times when somebody (yourself included) happens to have the file open for write.  Received: from SU-AI.ARPA by MIT-MC.ARPA; 20 MAR 85 01:38:55 EST Sent: to SU-AI.ARPA by IMSSS.? via ETHERNET with PUPFTP; 1985-Mar-19 22:24:42 PST (=GMT-8hr) Date: 1985 March 19 22:10:06 PST (=GMT-8hr) Message-id: SU-IMSSS.REM.A132100055052.G0446 From: Robert Elton Maas To:common-lisp@SU-AI.ARPA CC:Gall@MIT-MULTICS.ARPA Subject: What should CLOSE return? Closed-channel-object, or truefilename. Sender: REM%IMSSS@SU-SCORE.ARPA (for undeliverable-mail notifications) Reply-to: REM@MIT-MC.ARPA > !section 21.3(7) Nick Gall 85-03-19 > !version Digital Press 1984 > !topic What does CLOSE Return? > > I think it should return the STREAM it was given to close. This > would make it symmetric with OPEN: OPEN returns an open stream, > CLOSE returns a closed stream. That's not symmetric, that's coercive. OPEN and CLOSE are like matching parenthesis, one does it and the other undos it except for a residual side-effect. OPEN takes a name and returns an I/O channel (at the LISP level, an object that can be name an active stream of data). CLOSE takes an I/O channel and should return a name to be symmetric with OPEN. This would be an opportune time to solve race conditions where several users are making different versions of the same file at the same time by the trick of writing a temporary file and then renaming it during the CLOSE. At CLOSE the version number is determined, and at that moment before somebody can create a later version the lisp CLOSE function obtains the true filename of the particular version we created.  Received: from SU-AI.ARPA by MIT-MC.ARPA; 20 MAR 85 01:38:16 EST Sent: to SU-AI.ARPA by IMSSS.? via ETHERNET with PUPFTP; 1985-Mar-19 22:24:02 PST (=GMT-8hr) Date: 1985 March 19 21:23:38 PST (=GMT-8hr) Message-id: SU-IMSSS.REM.A132100055002.G0396 From: Robert Elton Maas To:common-lisp@SU-AI.ARPA CC:Gall@MIT-MULTICS.ARPA Subject: Default attributes of copy due to SUBSEQ Sender: REM%IMSSS@SU-SCORE.ARPA (for undeliverable-mail notifications) Reply-to: REM@MIT-MC.ARPA > Date: Tuesday, 19 March 1985 13:39-EST > From: Nick Gall (via Fahlman) > Posted-Date: 19 Mar 85 13:41 EST > > !section 14.1(2) Nick Gall 85-03-19 > !version Digital Press 1984 > !topic Copying arrays > > Although functions such as SUBSEQ state that the copy made of an > array is of the same type, they say nothing of the two other array > attributes, fill pointer and adjustable. > > The question is, "Should copied arrays share these attributes > with their originals, or should they be simple?" > > The answer should be stated in the standard. I agree completely so far. I would think it would copy those other attributes, rather than clobber them to SIMPLE when making the copy, but on the other hand, I'm not really sure. But clearly the manual should say, and probably an extra argument should be available to override the default.  Received: from SU-AI.ARPA by MIT-MC.ARPA; 20 MAR 85 01:20:13 EST Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 19 Mar 85 22:12:08 PST Received: from umass-cs by csnet-relay.csnet id af11355; 20 Mar 85 1:07 EST Date: Tue, 19 Mar 85 11:58 EST From: Dan Corkill To: common-lisp@su-ai.ARPA Subject: Implementation of MAP, SOME, EVERY, etc... There is an easily made implementation error in MAP, SOME, EVERY, etc. The published semantics indicate that these functions use the length of the shortest argument sequence to determine how many iterations to perform (and in this way parallel the semantics of mapc, mapcar, etc.). Thus it would appear that: (map 'list '+ '(1 2 3) (star 2)) where star builds a circular list of its argument should be legal and return => (3 4 5). Implementations that use length to check the length of argument sequences will break on such a call. Dan Corkill (Cork@UMass)  Received: from SU-AI.ARPA by MIT-MC.ARPA; 19 MAR 85 22:21:11 EST Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 19 Mar 85 18:55:00 PST Received: ID ; Tue 19 Mar 85 21:54:17-EST Date: Tue, 19 Mar 1985 21:53 EST Message-ID: Sender: FAHLMAN@CMU-CS-C.ARPA From: "Scott E. Fahlman" To: common-lisp@SU-AI.ARPA Subject: [Gall: Bug Report] Here are some Common Lisp questions sent to me by Nick Gall of Gold Hill. I'll take a crack at answering some of them when I get the time, if nobody else beats me to this. -- Scott *************************************************************************** Date: Tuesday, 19 March 1985 13:39-EST From: Nick Gall To: Fahlman Re: Bug Report Posted-Date: 19 Mar 85 13:41 EST Acknowledge-To: Nick Gall These comments are presented in the style suggested by Postscript to the Ada (TM) Language Reference Manual. The format of the header is as follows: !section SECTION#(PARAGRAPH#) NAME ISO-DATE !version REFERENCE-MANUAL-VERSION-NAME !topic SUMMARY-OF-COMMENT The Ada RM states that, The topic line should contain a one line summary of the comment. This line is essential, and you are kindly asked to avoid topics such as "Typo" or "Editorial comment" which will not convey any information when printed in a table of contents. As an example consider: !topic Subcomponents of constants are constants Note also that nothing prevents the topic line from including all the information of a comment, as in the following topic line: !topic Insert: "... are {implicitly} defined by a subtype declarartion" ----------------------------------------------------------------- !section None Nick Gall 85-03-19 !version Digital Press 1984 !topic Paragraphs should be numbered Paragraphs should be numbered as in the Ada (TM) Language Reference Manual. This would make identification of particular paragraphs in discussions much simpler. ----------------------------------------------------------------- !section 14.1(2) Nick Gall 85-03-19 !version Digital Press 1984 !topic Copying arrays Although functions such as SUBSEQ state that the copy made of an array is of the same type, they say nothing of the two other array attributes, fill pointer and adjustable. The question is, "Should copied arrays share these attributes with their originals, or should they be simple?" The answer should be stated in the standard. I think the best solution is to make simple copies by default, and allow an optional or keyword arg. to specify that all attributes should be copied. ----------------------------------------------------------------- !section 18.3(2) Nick Gall 85-03-19 !version Digital Press 1984 !topic Implied copying in the trim functions Although it is implied that the result of the string `trim' functions is a copy of the original strings, it is not explicitly stated. Since all the other functions which can potentially make copies of strings/arrays state this explicitly (e.g. SUBSEQ, CONCATENATE, SUBSTITUTE), the trim functions should also. ----------------------------------------------------------------- !section 18.3(2) Nick Gall 85-03-19 !version Digital Press 1984 !topic Implied copying in the STRING-{UP | DOWN}CASE functions Although it is implied that the result of the {up | down} functions is a copy of the original strings, it is not explicitly stated. Since all the other functions which can potentially make copies of strings/arrays state this explicitly (e.g. SUBSEQ, CONCATENATE, SUBSTITUTE), the {up | down} functions should also. ----------------------------------------------------------------- !section 9.1(6) Nick Gall 85-03-19 !version Digital Press 1984 !topic Pervasiveness of declarations over FLET and LABELS Example: (defun the-many-function-names-foo (x) (declare (inline foo)) (foo x) ; First call of FOO (flet ((foo (y z) (zap z y))) (foo x x)) ; Second call of FOO (foo x)) ; Third call of FOO According to the paragraph in question: "Declarations that do not concern themselves with variable bindings are pervasive, affecting ALL CODE IN THE BODY OF THE SPECIAL FORM." Thus, the second call to FOO will be open-coded; in spite of the fact that the second call of FOO refers to a function which is totally unrelated (except by name) to the FOO referred to in the other two calls. To prevent this, one has to provide a declaration within the FLET form: ... (flet ((foo (y z) (zap z y))) (declare (notinline foo)) ...) ... But what if this FLET were the expansion of a macro? How is the macro expansion function supposed to know which pervasive declarations will affect the functional objects specified in the FLET? In an analogous case concerning special variables instead of function names, no such redeclaration is necessary: (defun the-many-variables-foo (foo) (declare (special foo)) (fram foo) ; dynamic binding (let ((foo (boop))) (frab foo)) ; local lexical binding (zoop foo)) ; dynamic binding Declarations concerning function names should be treated as special variable declarartions are: references are pervasively affected, but not bindings. The last paragraph in each of the function name declarations (e.g. FUNCTION, INLINE, etc.) which begins, "Note that the rules of lexical scoping...", suggests that function names and special variables ARE treated analogously. If this is so, it should be made explicitly clear in section 9.1. ----------------------------------------------------------------- !section 9.1(12) Nick Gall 85-03-19 !version Digital Press 1984 !topic Non-Top-Level use of PROCLAIM Can PROCLAIM be used, other than at top-level? Since DEFVAR, etc., are proclamations and can be used at other than top-level, the answer to this question seems to be `yes'. Is PROCLAIM a `declaration', i.e., must it appear only where a declaration is allowed? Since it is allowed at top-level (unlike DECLARE), and it is a function, and since the other proclaiming forms (e.g. DEFVAR, etc.) could not be considered declarations (since they perform evaluation and assignment), the answer must be no. Then what is the effect of using PROCLAIM (or one one the other proclaiming forms) in the middle of a function? For example: (defun foo (a) (zap a) (proclaim '(special a)) (zark a)) Does the first reference to A refer to the local binding? Does the second reference refer to the global? Some mention of the effects of the non-top-level use of PROCLAIM and the other proclaiming forms should be made. ----------------------------------------------------------------- !section 7.5(14) Nick Gall 85-03-19 !version Digital Press 1984 !topic Scope and Extent of local function names NOTE: See 9.2 (ftype, function, inline). Example: (DEFUN CREATE-MAKEP (MAKE) (FLET ((CAR (SYMBOL) (GET SYMBOL 'AUTOMOBILE))) #'(LAMBDA (OWNER) (EQ MAKE (CAR OWNER))))) (SETQ FOO (CREATE-MAKEP 'HONDA)) (FUNCALL FOO 'BILL) => ????? Question: What does CAR refer to when it is used in the closure returned by CREATE-MAKEP? I.E., What is the scope and extent of the binding of a local function name to a functional object? Section 7.1(1) states that "There are two spaces of variables in Common Lisp, in effect: ordinary variables and function names." And the function name binding control structures appear in the section entitled "Establishing New Variable Bindings". I suggest that Common Lisp go all the way, and allow a SPECIAL-FUNCTION-NAME declaration that would be analogous to the SPECIAL declaration for "ordinary" variables. Such a concept would make the idea of ordinary-variable/function-name binding and assignment much more consistent. ----------------------------------------------------------------- !section 5.2.2(4) Nick Gall 85-03-19 !version Digital Press 1984 !topic Lambda variables with the same `name' Ex. 1: (lambda (a a) (values a)) Ex. 2: ;; Assume (not (eq p1::a p2::a)) (lambda (p1::a p2::a) (values p1::a p2::a)) Ex. 3: ;; Assume (eq p1::a p2::a) (lambda (p1::a p2::a) (values p1::a p2::a)) 1. Is Ex. 1 legal? If so, which args., value is returned? My answer: No, and the CLRM should state this. 2. Is Ex. 2 legal? My answer: Yes. 3. Is Ex. 3 legal? My answer: No. it is just like Ex. 1. The point that Exs. 2 + 3 point out is that it is the symbols THEMSELVES that name variables, not their (qualified) print-names. This distinction should be pointed out. This same comment applies to all the other environment establishing functions (section 7.5). ----------------------------------------------------------------- !section 5.3.2(7) Nick Gall 85-03-19 !version Digital Press 1984 !topic Redeclaring Constants with DEFCONSTANT It should be mentioned in this paragraph, as it is in 5.1.2(6), that, Constant symbols defined by DEFCONSTANT also become reserved and may not be further assigned to or bound (although they may be redefined, if necessary, by using DEFCONSTANT again). ----------------------------------------------------------------- !section 7.8.5(3) Nick Gall 85-03-19 !version Digital Press 1984 !topic Are identical TAGs legal? If so, which one is gone to? If not, it should be stated. ----------------------------------------------------------------- !section 7.8.5(3) Nick Gall 85-03-19 !version Digital Press 1984 !topic Items which are not symbols, integers, or lists in a TAGBODY The sentence, An item in the body may be a symbol or an integer, in which case it is called a TAG, or ... a list, in which case it is called a STATEMENT. Does this mean that any other atom is illegal? If so, it should be stated. ----------------------------------------------------------------- !section 9.1(10) Nick Gall 85-03-19 !version Digital Press 1984 !topic Replace: "... the parameter {of} NONSENSE named Z." ----------------------------------------------------------------- !section 23.1.2(11) Nick Gall 85-03-19 !version Digital Press 1984 !topic Replace: "... if no syntactically correct {namestring} was seen." ----------------------------------------------------------------- ! ----------------------------------------------------------------- !section 10.3(9) Nick Gall 85-03-19 !version Digital Press 1984 !topic Which bindings are copied by COPY-SYMBOL? "the initial value and function-definition of the new symbol will be the same as those of SYM..." Does this mean that the (dynamic) value of the variable referred to by SYM, at the point where COPY-SYMBOL symbol is invoked, is copied? Or, does it mean that the `initial', i.e. global value of the special variable named by SYM is copied? Although the wording seems to suggest the latter, it should be made clearer. The same questions and suggestion applies to the function-definition copied by COPY-SYMBOL. ----------------------------------------------------------------- !section 15.2(39) Nick Gall 85-03-19 !version Digital Press 1984 !topic The effect of NCONC on '() arguments "The arguments are changed, rather than copied." Surely, this does not apply to the arguments which are empty lists. Also, the last argument is NOT changed, right? Are dotted-lists allowed? If so, the result of a call such as, (NCONC '(1 2 . 3) NIL) should be made explicit. ----------------------------------------------------------------- !section 15.2(55) Nick Gall 85-03-19 !version Digital Press 1984 !topic What may N be in BUTLAST? MUST N be a non-negative integer? Or can it be negative (with a neg. N having the same effect as a zero N)? The constraints on the type and range of N should be made explicit. ----------------------------------------------------------------- !section 15.2(57) Nick Gall 85-03-19 !version Digital Press 1984 !topic When is LIST modified in NBUTLAST? Shouldn't the condition, "If the LIST has fewer than N elements..." read, "If the LIST has N or fewer elements...". ----------------------------------------------------------------- !section 15.5(8) Nick Gall 85-03-19 !version Digital Press 1984 !topic Is (TAILP NIL list) true or false for every list? "This preicate is true if SUBLIST is a sublist of LIST (i.e. one of the conses that makes up LIST)." According to this criterion, NIL is not a sublist to any list since it is not a cons. "...TAILP is true if (NTHCDR n list) is sublist, for some value of N." According to this definition NIL is a sublist of every list, since the (NTHCDR (LENGTH list) list) is NIL for every LIST. Although a phrase in the definition of LDIFF, "If SUBLIST is not a tail of LIST (and in particular if SUBLIST is NIL)," seems to indicate that NIL is NOT a sublist (or tail) of any list, this should be stated explicitly in the definition of TAILP. ----------------------------------------------------------------- !section 20.1(7) Nick Gall 85-03-19 !version Digital Press 1984 !topic Is *APPLYHOOK* funcalled for special forms? "The variable *APPLYHOOK* ... is used when a function is about to be applied to arguments." Does `function' refer to a functional object which is in fact a function (i.e., its args. are evaled before it is called), or does it refer to any functional object (e.g., `special' functional objects)? Later in the paragraph, it is stated that, The apply hook function is used only for application of ordinary functions within eval. It is not used for applications via apply, or funcall, for applications by such functions as map or reduce, or for invocation of macro-expansion functions... This paragraph does not really address the "application of ordinary functions within eval" but rather the "ordinary application of functions by eval." Also it does not clarify the action taken for special forms. This paragraph should be made clearer. ----------------------------------------------------------------- !section 21.3(7) Nick Gall 85-03-19 !version Digital Press 1984 !topic What does CLOSE Return? I think it should return the STREAM it was given to close. This would make it symmetric with OPEN: OPEN returns an open stream, CLOSE returns a closed stream. ----------------------------------------------------------------- !section 20.1(last-1) Nick Gall 85-03-19 !version Digital Press 1984 !topic Is nil declared by defconstant? ...all constant symbols declared by DEFCONSTANT, such as NIL, T, and PI. If NIL is declared by DEFCONSTANT then it can legally be redefined according to section 5.1.2(last): Constant symbols defined by DEFCONSTANT ... may be redefined, if necessary, by using DEFCONSTANT again[]. Is such an interpretation correct? ----------------------------------------------------------------- !section 4.8(1) Nick Gall 85-03-19 !version Digital Press 1984 !topic The meaning of the word `convert' Does coerce `convert' (i.e., change the type bits) and return the original object (or the pointer if typed pointers are supported) when possible (e.g., coercing a string to an array of (unsigned-byte 8) in some implementations); or does coerce ALWAYS create and return a new `equivalent' object; or does the Common Lisp spec. not define this? ----------------------------------------------------------------- !section 5.3.2(7) Nick Gall 85-03-19 !version Digital Press 1984 !topic Lexical variable with the same name as a named constant A named constant is declared using DEFCONSTANT. DEFCONSTANT PROCLAIMs that a symbol always names a special variable (which happens to have a fixed value). This proclamation applies to ALL bindings and references. Therefore, after such a proclamation, no lexical variable with such a name can be used. If this is the case, when would the compiler ever have the opportunity to ...issue warnings about bindings of the lexical variable of the same name [as a name declared by DEFCONSTANT to be constant].  Received: from SU-AI.ARPA by MIT-MC.ARPA; 19 MAR 85 16:53:00 EST Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 19 Mar 85 13:43:52 PST Received: ID ; Tue 19 Mar 85 16:42:55-EST Date: Tue, 19 Mar 1985 16:42 EST Message-ID: From: Rob MacLachlan To: Jon White Cc: common-lisp@SU-AI.ARPA, dzg@CMU-CS-SPICE.ARPA, Fahlman@CMU-CS-C.ARPA Subject: File-length on pathnames In-reply-to: Msg of 19 Mar 1985 04:14-EST from Jon White The official party line is that Spice has no concept of a host. In order to access a file on another machine, you embed that filesystem into your filesystem. There is no reasonable way to talk about access at the byte level or page level, since the only file I/O primitives are reading and writing an entire file. This works fairly well, since the file is only mapped when you read it, and the reading not actually done until you touch the page. There is currently work in progress to permit mapping of files and memory over the network. When this capability exists, the problem will go away. I find the restriction on FILE-LENGTH extremely silly. As near as I can tell, the argument for requiring the restriction is the following: - Some operating systems require an operation (which they may nor may not call open, and is in any case not probably not identical in semantics to the Common Lisp open) to be done before the length of a file can be determined. - This "operating system open" call may have some requirement for exclusive access. If some other process has the file open, then the call to FILE-LENGTH may wait or fail. - It is somehow more intuitive to have OPEN wait or fail than to have FILE-LENGTH wait or fail. I think that if there is any implicit guarantee in the CLM filesystem chapter that certain calls may not wait or fail whenever they feel like it, then it is bogus. There is no way the CLM can hope to describe the semantics of arbitrary filesystems, let alone the real-time properties. Rob  Received: from SU-AI.ARPA by MIT-MC.ARPA; 19 MAR 85 10:24:23 EST Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 19 Mar 85 07:17:43 PST Received: ID ; Tue 19 Mar 85 10:05:40-EST Date: Tue, 19 Mar 1985 10:05 EST Message-ID: Sender: FAHLMAN@CMU-CS-C.ARPA From: "Scott E. Fahlman" To: Jon White Cc: common-lisp@SU-AI.ARPA Subject: DO-SYMBOLS: duplicates and shadowings The Spice Lisp system has now been changed by Rob Maclachlan so that DO-SYMBOLS does the right thing (according to my latest proposal): inherited symbols are presented, there is no special effort to eliminate duplicates, and shadowed symbols are eliminated. As I understand it, the latter is accomplished by keeping track of which packages contain *any* shadowed symbols, and for symbols exported by these packages doing what amounts to a call to FIND-SYMBOL on each candidate. Rob tells me that even when this extra checking is being done, it doesn't hurt us too much in speed. -- Scott  Received: from SU-AI.ARPA by MIT-MC.ARPA; 19 MAR 85 04:33:27 EST Date: 19 Mar 85 0114 PST From: Jon White Subject: File-length on pathnames To: dzg@CMU-CS-SPICE.ARPA CC: Fahlman@CMU-CS-C.ARPA, common-lisp@SU-AI.ARPA I believe that Interlisp, at one time, limited the use of the file-length equivalent to open file; this turned out to be very inconvenient, and was changed [maybe about the time I began working for Xerox, three years ago]. A lesson to be learned: no matter what the implementation cost, it will ultimately be more costly *not* to provide that capability to the user; somebody's example of how Spice would react to the opening of a huge remote file shows that this is the sort of thing that ought to be done by the system implementor. As for potential inconsistencies due to multi-user access to a shared file system -- consider the two alternatives: (A) Smooth results, with only an epsilonic probability that they will be ragged [non "Smooth"] due to the multi-user, shared access, or (B) nothing. While opting for (A), I don't consider myself a gambler. By the way, what kind of distributed file system does Spice have? Isn't it rather primitive to provide no byte-level or page-level access to remote files? It sounds from the previous discussions that only an FTP like facility is provided. -- JonL --  Received: from SU-AI.ARPA by MIT-MC.ARPA; 19 MAR 85 04:10:31 EST Date: 19 Mar 85 0056 PST From: Jon White Subject: DO-SYMBOLS: duplicates and shadowings To: Fahlman@CMU-CS-C.ARPA CC: common-lisp@SU-AI.ARPA My reading of the do-symbols documentation was that "the symbols of a package" was a colloquialism for "symbols accessible in a package", and hence it should include the inherited symbols -- the Spice code I saw appeared to be buggy on that score. Perhaps we should identify the needs and the costs of the two components in your "revised" suggestion. 1) I have no need [currently!] for removal of duplicates, but would be willing to listen to someone who claims such a need. As for cost of implementing this, it sounds like Hedricks 3+ hashtable lookups [on average] per symbol "done" is th best contender. That could easily make some simple cases an order of magnitude slower. 2) In at least one case I know of, it would be rather disastrous for a shadowed symbol to be "done", in addition to the shadowing counterpart. As for cost of removing shadowed potential inheritees, I would like to hear some estimates on the average number of shadowing symbols in a package that has an earnest need for some shadowing. The one example I can think of off-hand is a language emulator which is a variant on Common Lisp -- the non-standard, conflicting definitions have to be shadowed; in the example I'm thinking of, it is still less than 100 shadowings. The answer to this question may affect the strategy for shadowed-symbol omission, and hence the cost. Just for the record, one may have duplicates arise because the same symbol is inherited from several different used packages; IMPORT is not the only villain here. -- JonL --  Received: from SU-AI.ARPA by MIT-MC.ARPA; 12 MAR 85 10:55:57 EST Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 12 Mar 85 07:47:51 PST Received: ID ; Tue 12 Mar 85 10:47:11-EST Date: Tue, 12 Mar 1985 10:47 EST Message-ID: Sender: FAHLMAN@CMU-CS-C.ARPA From: "Scott E. Fahlman" To: hpfclp!paul%hplabs.csnet@CSNET-RELAY.ARPA Cc: common-lisp@SU-AI.ARPA Subject: float-digits In-reply-to: Msg of 12 Mar 1985 05:53-EST from hpfclp!paul%hplabs.csnet at csnet-relay.arpa Paul, Floating point hackery is not my specialty, but maybe I can give you a quick answer that will stand unless one of the real experts pops up to contradict me. What is the result of (float-digits 0.0)? Float-digits tells you how many radix-b digits there are in the representation of the fractional part (the "significand") of the type of number you feed it. It doesn't care at all about the value of the argument, just about which type of float it is. So in this case, it tells you the number of digits (usually bits) in the significand of a number of the default floating type, as controlled by *read-default-float-format*. Why isn't "float-radix" a constant? Float-radix may in principle be different for different types of floats in the same implementation, though I don't know of any existing implemenation that does this. By making it a function, we allow the user to ask for the float-radix of some particular type of number: the type of the argument. -- Scott  Received: from SU-AI.ARPA by MIT-MC.ARPA; 12 MAR 85 10:17:26 EST Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 12 Mar 85 07:10:19 PST Received: from hplabs by csnet-relay.csnet id ad07182; 12 Mar 85 9:59 EST Date: Tue, 12 Mar 85 02:53:42 pst From: hpfclp!paul%hplabs.csnet@csnet-relay.arpa MMDF-Warning: Parse error in preceding line at CSNET-RELAY.ARPA Received: by HP-VENUS id AA29106; Tue, 12 Mar 85 02:53:42 pst Message-Id: <8503121053.AA29106@HP-VENUS> To: hplabs!common-lisp@su-ai.ARPA Subject: float-digits Source-Info: From (or Sender) name not authenticated. What is the result of (float-digits 0.0)? Why isn't "float-radix" a constant? Paul Beiser Hewlett-Packard Ft. Collins, Colorado uucp: ...{ihnp4,hplabs}!hpfcla!paul arpa: "hpfclp!paul%hplabs.csnet"@csnet-relay