Received: from SU-AI.ARPA by MIT-MC.ARPA 27 Jul 85 16:41:40 EDT Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 27 Jul 85 13:34:23 PDT Date: Sat, 27 Jul 85 16:35:16 EDT From: Tim McNerney Subject: Clearing the screen and other such things. To: fateman@UCBDALI.ARPA cc: COMMON-LISP@SU-AI.ARPA, KMP@SCRC-STONY-BROOK.ARPA In-reply-to: Msg of Sat 27 Jul 85 11:38:16 PDT from fateman%ucbdali at Berkeley (Richard Fateman) Message-ID: <[MIT-MC.ARPA].590458.850727.TIM> Date: Sat, 27 Jul 85 11:38:16 PDT From: fateman%ucbdali at Berkeley (Richard Fateman) Doesn't UNIX (4.0, 4.1, 4.2 BSD) and those derived from it (e.g. Xenix) have a cursor-control package, and aren't there editors (e.g. vi, gnumacs, Gosling emacs) that use the termcap (or similar) information files? Termcap does not address some of the subtleties of many terminals. For instance: Does the terminal scroll after printing a character in the last column of the last like? Also, many terminals support operations like "Delete N lines," which are almost indispensable for writing screen editors and the like, are not supported by termcap (nor KMP's proposal). Then there is the issue of padding which is not modeled well at all by termcap. But, unix aside, because Common Lisp is supposed to be operating system and machine independent, designing generic I/O in general is problematic. Witness the problems that have been raised w.r.t. interfacing with various files systems (eg. OPEN's :direction :probe).  Received: from SU-AI.ARPA by MIT-MC.ARPA 27 Jul 85 14:44:25 EDT Received: from UCB-VAX.ARPA by SU-AI.ARPA with TCP; 27 Jul 85 11:37:32 PDT Received: from ucbdali.ARPA by UCB-VAX.ARPA (4.24/5.3) id AA20272; Sat, 27 Jul 85 11:32:52 pdt Received: by ucbdali.ARPA (5.5/4.48) id AA20272; Sat, 27 Jul 85 11:38:16 PDT Date: Sat, 27 Jul 85 11:38:16 PDT From: fateman%ucbdali@Berkeley (Richard Fateman) Message-Id: <8507271838.AA20272@ucbdali.ARPA> To: KMP@SCRC-STONY-BROOK.ARPA, TIM@MIT-MC.ARPA Subject: Re: Clearing the screen and other such things. Cc: COMMON-LISP@SU-AI.ARPA Doesn't UNIX (4.0, 4.1, 4.2 BSD) and those derived from it (e.g. Xenix) have a cursor-control package, and aren't there editors (e.g. vi, gnumacs, Gosling emacs) that use the termcap (or similar) information files? I believe that Franz Lisp provides a set of primitives to do all this character-screen oriented stuff (to the extent it is supported by Unix).  Received: from SU-AI.ARPA by MIT-MC.ARPA 27 Jul 85 05:20:42 EDT Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 27 Jul 85 02:10:27 PDT Date: Sat, 27 Jul 85 05:11:22 EDT From: Tim McNerney Subject: Clearing the screen and other such things. To: KMP@SCRC-STONY-BROOK.ARPA cc: COMMON-LISP@SU-AI.ARPA In-reply-to: Msg of Fri 26 Jul 85 14:49 EDT from Kent M Pitman Message-ID: <[MIT-MC.ARPA].590150.850727.TIM> Date: Fri, 26 Jul 85 14:49 EDT From: Kent M Pitman As nearly as I can tell, Common Lisp offers no way to even clear the screen. In the absence of a graphics standard, can we commit to even something so simple as a CLEAR-SCREEN function? I agree that Common Lisp should have better terminal support, but beyond CLEAR-SCREEN, things are not so simple. Some issues (and mere details) need to be settled on before we extend the language in this direction: ERASE-REST-OF-SCREEN, ERASE-REST-OF-LINE, INSERT-CHAR, DELETE-CHAR, INSERT-LINE, DELETE-LINE Should these functions return T or NIL depending on whether there was any effect on the screen? ERASE-CHAR-BACKWARD, ERASE-CHAR-FORWARD Many terminals don't support these operations. If we are trying to limit ourselves to a set of essential primitives, I would suggest that these be flushed, since they are merely abstractions for printing the sequences, backspace-space-backspace and space-backspace, respectively. CURSOR-BACKWARD, CURSOR-FORWARD, CURSOR-DOWN, CURSOR-UP, CURSOR-HOME-UP, CURSOR-HOME-DOWN Should these return the cursor position, or either T or NIL depending on whether there was any effect (like the ERASE-xxx functions)? CHARACTER-POSITION Should all Common Lisp implementations be required to accurately model the the terminal's cursor position? In the discussion of TERPRI, FRESH-LINE, and FORMAT, in CLtL, it is stated explicitly that the implementation not be required to do so. This is a wise decision, because this is not always possible, expecially if the operating system is allowed to randomly print out notices without telling the Lisp. Also, some terminals move the cursor to the next line after printing in the last column, and some terminals scroll the screen up one line after printing in the last column of the last screen line! This can be a source of problems. (...and some terminals are just plain spastic; remember how TTY's occasionally skipped spaces, etc?) (SETF (CHARACTER-POSITION) (VALUES x y)) There should probably be a function SET-CHARACTER-POSITION which the above SETF form expands into. I would prefer the names CURSOR-POSITION and SET-CURSOR-POSITION so as to be consistent with the names of the cursor motion functions. SCREEN-SIZE-IN-CHARACTERS Presumably this will return the page size for printing terminals too. How about a more generic name like TERMINAL-SIZE-IN-CHARACTERS? SCREEN-TYPE I would prefer the name TERMINAL-TYPE. SCREEN-OPERATION-HANDLED-P Similarly, I would prefer TERMINAL-OPERATION-HANDLED-P [terminal-type] :OTHER The screen is of some type not adequately described by one of these categories. SCREEN-OPERATION-HANDLED-P should be used to determine specifically what type of terminal is involved. This seems like an overly painful way of finding out the charateristics of a terminal. Perhaps TERMINAL-TYPE should return as a second value the list of functions names the terminal it supports (something akin to the list returned by a :WHICH-OPERATIONS method in Flavors). Tim McNerney P.S. If these function were put into the language (white pages), Common Lisp may be the first language standard to acknowledge the existence of display terminals!  Received: from SU-AI.ARPA by MIT-MC.ARPA 27 Jul 85 03:04:58 EDT Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 26 Jul 85 23:57:01 PDT Date: Sat, 27 Jul 85 02:57:55 EDT From: Tim McNerney Subject: labels To: HAUG%CSL60%ti-csl.csnet@CSNET-RELAY.ARPA cc: common-lisp@SU-AI.ARPA In-reply-to: Msg of 26 Jul 1985 1550-CDT from HAUG%CSL60%ti-csl.csnet at csnet-relay.arpa Message-ID: <[MIT-MC.ARPA].590070.850727.TIM> Date: 26 Jul 1985 1550-CDT Re: labels ... a surrounding BLOCK is not implicitly generated in the case of LABELS. I believe this to be an oversight in the specification for LABELS. -- David Haug I agree. Functions defined with LABELS and FLET should have the same implicit BLOCK as functions defined with DEFUN. Tim McNerney P.S. This is "broken" (but by the book) in Symbolics Common Lisp as well.  Received: from SU-AI.ARPA by MIT-MC.ARPA 26 Jul 85 19:48:06 EDT Received: from SU-GLACIER.ARPA by SU-AI.ARPA with TCP; 26 Jul 85 16:38:35 PDT Received: by mips.UUCP (4.12/4.7) id AA25005; Fri, 26 Jul 85 16:35:42 pdt Date: Fri, 26 Jul 85 16:35:42 pdt From: mips!earl@Glacier (Earl Killian) Message-Id: <8507262335.AA25005@mips.UUCP> To: Glacier!KMP@SCRC-STONY-BROOK.ARPA Cc: Glacier!COMMON-LISP@SU-AI.ARPA In-Reply-To: Kent M Pitman's message of Fri, 26 Jul 85 14:49 EDT Subject: Clearing the screen and other such things. I'm not sure whether it is a good idea to add such things or not, but the specific proposal is severely flawed and should be fixed before being considered. ERASE-REST-OF-SCREEN is rarely useful, while a function to erase multiple lines can be quite useful (e.g. N lines from current line). In general your proposed functions all need to take arguments to do multiple operations instead of one. It is MUCH easier to expand DELETE-CHAR N than it is to recognize N consecutive DELETE-CHARs, and merge them into one terminal operation. However, instead of INSERT-CHARS N, what you really want is INSERT-STRING, and instead of INSERT/DELETE-LINES N, what you want is a INSERT/DELETE-LINES N M which is insert/delete N lines in the M-line region after the current line (again, this is easy to simulate on terminals with simple insert-delete line commands, but pattern recognizing the other direction is difficult). You can apply the same technique if you want to INSERT/DELETE-CHARS, and indeed to ERASE-LINE, by giving a column to stop at, making it easy to support windowing. Erase-to-column is the only one that can't be efficiently supported on your average terminal (requiring the typeout of lots of spaces if the column in question isn't the last column of the screen).  Received: from SU-AI.ARPA by MIT-MC.ARPA 26 Jul 85 19:25:16 EDT Received: from SU-GLACIER.ARPA by SU-AI.ARPA with TCP; 26 Jul 85 16:18:16 PDT Received: by mips.UUCP (4.12/4.7) id AA24168; Fri, 26 Jul 85 16:13:10 pdt Date: Fri, 26 Jul 85 16:13:10 pdt From: mips!earl@Glacier (Earl Killian) Message-Id: <8507262313.AA24168@mips.UUCP> To: Glacier!KMP@SCRC-STONY-BROOK.ARPA Cc: Glacier!Common-Lisp@SU-AI.ARPA, Glacier!CWH@SCRC-STONY-BROOK.ARPA In-Reply-To: Kent M Pitman's message of Fri, 26 Jul 85 15:02 EDT Subject: Does READ-CHAR echo? Does READ-CHAR echo, or does the terminal handler, which supplied the character in the first place, echo? Echoing is terminal-specific (you don't want READ-CHAR from a file to echo) so it makes more sense to talk about what the terminal handler does. This starts to get into the controversy over whether you want to echo the character when it is typed ("interrupt level") or when it is read, or try to rise above these simple alternatives to do the right thing. Does Common Lisp specify whether echoing is done at type-in time or read-time? Probably it should leave such things undefined so that you can use system echoing for efficiency, or try to do something better than either of the simple alternatives. Leaving it undefined makes it difficult to write portable rubout handlers (because you can't know the state the screen), but my guess is that these will be provided by the underlying implementation. The underlying implementation should of course promise to echo things exactly once; your problem with UNREAD-CHAR in ZetaLisp sounds like a simple bug.  Received: from SU-AI.ARPA by MIT-MC.ARPA 26 Jul 85 19:14:19 EDT Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 26 Jul 85 16:05:00 PDT Received: from ti-csl by csnet-relay.csnet id aa09231; 26 Jul 85 19:00 EDT Date: 26 Jul 1985 1550-CDT From: HAUG%CSL60%ti-csl.csnet@csnet-relay.arpa Subject: labels To: common-lisp@su-ai.ARPA Received: from csl60 by ti-csl; Fri, 26 Jul 85 16:41 CST I use the LABELS construct frequently and recently observed that if a function FOO is defined via LABELS, use of a (RETURN-FROM FOO ...) within the body of FOO generates an "undefined block FOO" error in both our interpreter and compiler. I also looked at the source code for SPICE (FAHLMAN et al.) and believe that it would generate an error in this implementation as well. The reason is that a surrounding BLOCK is not implicitly generated in the case of LABELS. I believe this to be an oversight in the specification for LABELS. -- David Haug -------  Received: from SU-AI.ARPA by MIT-MC.ARPA 26 Jul 85 17:31:21 EDT Received: from SCRC-YUKON.ARPA by SU-AI.ARPA with TCP; 26 Jul 85 14:21:43 PDT Received: from CROW.SCRC.Symbolics.COM by SCRC-YUKON.ARPA via CHAOS with CHAOS-MAIL id 141347; Fri 26-Jul-85 17:21:16-EDT Date: Fri, 26 Jul 85 17:21 EDT From: Robert W. Kerns Subject: Does READ-CHAR echo? To: KMP@SCRC-STONY-BROOK.ARPA, Common-Lisp@SU-AI.ARPA cc: CWH@SCRC-STONY-BROOK.ARPA In-Reply-To: <850726150233.6.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> Message-ID: <850726172130.7.RWK@CROW.SCRC.Symbolics.COM> Date: Fri, 26 Jul 85 15:02 EDT From: Kent M Pitman I could not find any place in CLtL where it says whether READ-CHAR echos the character that it has read. Likewise for PEEK-CHAR. Also, there is no discussion of whether UNREAD-CHAR should unecho the character. I note that Symbolics Common Lisp has (somewhat arbitrarily, I guess) decided that READ-CHAR echos, PEEK-CHAR does not echo, and UNREAD-CHAR does not un-echo the character. This has the odd effect that: (PROGN (PEEK-CHAR) (UNREAD-CHAR (READ-CHAR)) (READ-CHAR)) echos the character twice. I imagine it will be a real hassle when programs start porting if this behavior does not become standardized. I would suggest that it is incorrect for READ-CHAR to echo a character which was UNREAD-CHAR'd. Such a character has already been echoed once. I think this is just a bug. Does anyone have any thoughts about whether we should think about adding functions called PEEK-CHAR-NO-ECHO, READ-CHAR-NO-ECHO, and UNREAD-CHAR-NO-ECHO? Or maybe there should be WITH-INPUT-ECHO and WITHOUT-INPUT-ECHO special forms which affect calls to the character readers within the dynamic scope of their body. I think the only one needed would be READ-CHAR-NO-ECHO.  Received: from SU-AI.ARPA by MIT-MC.ARPA 26 Jul 85 15:25:07 EDT Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 26 Jul 85 12:15:00 PDT Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 283120; Fri 26-Jul-85 15:02:18-EDT Date: Fri, 26 Jul 85 15:02 EDT From: Kent M Pitman Subject: Does READ-CHAR echo? To: Common-Lisp@SU-AI.ARPA cc: CWH@SCRC-STONY-BROOK.ARPA Message-ID: <850726150233.6.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> I could not find any place in CLtL where it says whether READ-CHAR echos the character that it has read. Likewise for PEEK-CHAR. Also, there is no discussion of whether UNREAD-CHAR should unecho the character. I note that Symbolics Common Lisp has (somewhat arbitrarily, I guess) decided that READ-CHAR echos, PEEK-CHAR does not echo, and UNREAD-CHAR does not un-echo the character. This has the odd effect that: (PROGN (PEEK-CHAR) (UNREAD-CHAR (READ-CHAR)) (READ-CHAR)) echos the character twice. I imagine it will be a real hassle when programs start porting if this behavior does not become standardized. Does anyone have any thoughts about whether we should think about adding functions called PEEK-CHAR-NO-ECHO, READ-CHAR-NO-ECHO, and UNREAD-CHAR-NO-ECHO? Or maybe there should be WITH-INPUT-ECHO and WITHOUT-INPUT-ECHO special forms which affect calls to the character readers within the dynamic scope of their body. I kind of assume that we all agree that READ and READ-LINE should echo the characters as they come in from an interactive terminal. Perhaps, we should state that explicitly in the next edition of the manual. I believe Carl Hoffman (who wrote the Lisp Machine rubout handler) has some thoughts on this, which I hope this letter will spur him to share with us.  Received: from SU-AI.ARPA by MIT-MC.ARPA 26 Jul 85 15:14:52 EDT Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 26 Jul 85 11:58:44 PDT Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 283113; Fri 26-Jul-85 14:48:52-EDT Date: Fri, 26 Jul 85 14:49 EDT From: Kent M Pitman Subject: Clearing the screen and other such things. To: COMMON-LISP@SU-AI.ARPA Message-ID: <850726144908.5.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> As nearly as I can tell, Common Lisp offers no way to even clear the screen. In the absence of a graphics standard, can we commit to even something so simple as a CLEAR-SCREEN function? In fact, I'd like to see as many of the functions below as we could agree on; please note that this suggestion is not meant to preclude a more sophisticated graphics proposal. It is only meant to acknowledge the fact that many interesting portable applications can be written using a single fixed width fonts and character coordinates. Note also that some of these functions might later want more arguments added, but I've deliberately kept them as simple as possible for now so as not to preempt decisions that might be made by the graphics group. -kmp ERASE-SCREEN &optional (screen *TERMINAL-IO*) Erases the text on the entire screen. On screens which do not support this operation, a fresh-line is done instead. ERASE-REST-OF-SCREEN &optional (screen *TERMINAL-IO*) Erases the text on the rest of the screen beginning at the point of the cursor. On screens which do not support this operation, a fresh-line is done instead. ERASE-REST-OF-LINE &optional (screen *TERMINAL-IO*) Clears the rest of the line (from the point of the cursor). On screens which do not support this operation, a linefeed is done is done instead. ERASE-CHAR-BACKWARD &optional (screen *TERMINAL-IO*) Erases the character before the cursor. Undefined if called at head of line. ERASE-CHAR-FORWARD &optional (screen *TERMINAL-IO*) Erases the character after the cursor. Undefined if called at end of line. CURSOR-BACKWARD &optional (screen *TERMINAL-IO*) Moves the cursor back one character. Undefined if called at head of line. CURSOR-FORWARD &optional (screen *TERMINAL-IO*) Moves the cursor forward one character. Undefined if called at end of line. CURSOR-DOWN &optional (screen *TERMINAL-IO*) Moves the cursor down one character. Undefined if called at bottom of screen. CURSOR-UP &optional (screen *TERMINAL-IO*) Moves the cursor up one character. Undefined if called at top of screen. CURSOR-HOME-UP &optional (screen *TERMINAL-IO*) Moves the cursor to the top left corner of the screen. CURSOR-HOME-DOWN &optional (screen *TERMINAL-IO*) Moves the cursor to the bottom left corner of the screen. INSERT-CHAR &optional (screen *TERMINAL-IO*) Opens a position in front of the cursor for display of a character using the Insert-Char operation supported by most modern terminals. The effect of INSERT-CHAR when there is a character in the last position on the line is undefined. DELETE-CHAR &optional (screen *TERMINAL-IO*) Deletes the character in front of the cursor using the standard Delete-Char operation supported by most modern terminals. The effect of DELETE-CHAR at the end of a line is undefined. INSERT-LINE &optional (screen *TERMINAL-IO*) Opens the line at the cursor by sliding the remaining lines on the screen down using the Insert-Line operation supported by most modern terminals. The effect of calling this when not in column 0 is undefined. DELETE-LINE &optional (screen *TERMINAL-IO*) Deletes the line at the cursor, sliding the remaining lines on the screen up using the standard Delete-Line operation supported by most modern terminals. The effect of calling this when not in column 0 is undefined. CHARACTER-POSITION &optional (screen *TERMINAL-IO*) Returns two values representing the character position (X,Y) of the cursor on the given screen in character units (assuming a fixed width font). It should be possible to say (SETF (CHARACTER-POSITION) (VALUES x y)) to later restore the cursor to the given coordinates. SCREEN-SIZE-IN-CHARACTERS &optional (screen *TERMINAL-IO*) Returns two values representing the size of the screen in characters (X,Y). SCREEN-OPERATION-HANDLED-P operation &optional (screen *TERMINAL-IO*) Takes an argument of the name of a screen operation and returns true if that operation is correctly handled on the current screen. eg, (SCREEN-OPERATION-HANDLED-P 'DELETE-LINE) would be handled only on screens with Delete-Line capability. Some operations, such as CLEAR-SCREEN, will be simulated even if this returns false. For example, (SCREEN-OPERATION-HANDLED-P 'CLEAR-SCREEN) may sometimes return false but the CLEAR-SCREEN operation will never signal an error. SCREEN-TYPE screen Returns a keyword which is one of: :DISPLAY The screen handles all of the above display operations. :CURSOR-MOTION The screen handles all display operations except the INSERT-xxx and DELETE-xxx operations. :GLASS The screen handles ERASE-CHARACTER-BACKWARD. :PRINTING The screen is a paper terminal and handles none of the display operations. :OTHER The screen is of some type not adequately described by one of these categories. SCREEN-OPERATION-HANDLED-P should be used to determine specifically what type of terminal is involved.  Received: from SU-AI.ARPA by MIT-MC.ARPA 26 Jul 85 14:19:32 EDT Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 26 Jul 85 11:03:20 PDT Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 283054; Fri 26-Jul-85 14:02:14-EDT Date: Fri, 26 Jul 85 14:02 EDT From: Kent M Pitman Subject: CHAR-BIT To: COMMON-LISP@SU-AI.ARPA Message-ID: <850726140224.4.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> At the top of page 244, it says that it is an error to give this the name of a bit that doesn't exist in a given implementation. This is a loss because it means that users then have to * know which bits are supported where * write code to know it. Consider: (DEFUN HAS-HYPER-BIT-P (CHAR) #+Symbolics (CHAR-BIT CHAR :HYPER) #-Symbolics NIL) This sort of definition bothers me. Even the non #'d variant: (DEFUN HAS-HYPER-BIT-P (CHAR) (IF THIS-IMPLEMENTATION-HAS-A-HYPER-BIT-P (CHAR-BIT CHAR :HYPER))) bothers me since the compiler is no doubt going to warn me about using CHAR-BIT with an invalid argument. I suppose I have to write: (DEFMACRO IF-THIS-IMPLEMENTATION-HAS-A-HYPER-BIT (&BODY FORMS) (IF THIS-IMPLEMENTATION-HAS-A-HYPER-BIT-P `(PROGN ,@FORMS) `NIL)) (DEFUN HAS-HYPER-BIT-P (CHAR) (IF-THIS-IMPLEMENTATION-HAS-A-HYPER-BIT (CHAR-BIT CHAR :HYPER))) to avoid that. And what if I was wrong? What if some other implementations allow a Hyper bit that I don't know about. eg, what if there were another LispM company besides Symbolics or what if the DEC VT1000 has a Hyper key? Does that mean his code should be wrong? Isn't it reasonable for him to predicate Hyper-ness of a character even though it will never be Hyper? Also, there will certainly be keyboards that can't generate a Hyper key even in machine implementations that could accept it; in those cases, it certainly makes sense to ask about bits that couldn't exist. The point is that conceptually it makes sense to allow this and implementationally it's possible to make these efficient. eg, (CHAR-BIT char :HYPER) can optimize to NIL at compile time in some implementations, and it's probably ok for (CHAR-BIT char X) to be a bit slower. So I believe I should be able to simply do (CHAR-BIT CHAR :HYPER) and reliably get NIL in implementations that do not support the Hyper key. As to SET-CHAR-BIT, I am content to have an error generated when I try to set a non-existent bit. This happens, I suspect, less frequently. [In fact, the only case I can think of where it would ever happen at all is where someone is writing code (eg, for an editor) that offers a Hyper- escape for keyboards that can't generate such characters primitively.] I am willing to specially conditionalize such cases. In principle, there may be implementations that don't support even the :CONTROL bit. For the sake of such implementations, are you willing to conditionalize your uses of (CHAR-BIT CHAR :CONTROL) in order to be able to truthfully claim portability? -kmp  Received: from SU-AI.ARPA by MIT-MC.ARPA.ARPA; 12 Jul 85 14:22:13 EDT Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 12 Jul 85 11:05:50 PDT Received: ID ; Fri 12 Jul 85 14:05:57-EDT Date: Fri, 12 Jul 1985 14:05 EDT Message-ID: Sender: FAHLMAN@CMU-CS-C.ARPA From: "Scott E. Fahlman" To: marick@GSWD-VMS.ARPA Cc: common-lisp@SU-AI.ARPA Subject: Proposal for a UNIX subgroup. In-reply-to: Msg of 12 Jul 1985 12:37-EDT from marick at GSWD-VMS I think that it is a good idea for the Common Lisp/Unix people to be talking about ways of being maximally compatible. The participants will have to decide for themselves how much standardization makes sense here. For example, I'm sure that it is more important to DEC that their own VMS and Unix versions agree than that their Unix version matches someone else's. Same for Lucid, which is working on Unix-based and non-Unix-based versions and needs to keep them all in sync. But even given these constraints, a little communication would keep down the amount of truly needless incompatibility. Let me suggest that the people who want to communicate about this stuff do it on the Common Lisp mailing list for now. I don't think it would hurt the rest of us to hear what's going on in this area -- maybe some of the decisions have consequences outside unix-land. If the traffic gets too heavy, or too irrelevant to the rest of the community, then we can split it off. -- Scott  Received: from SU-AI.ARPA by MIT-MC.ARPA.ARPA; 12 Jul 85 14:06:37 EDT Received: from UCB-VAX.ARPA by SU-AI.ARPA with TCP; 12 Jul 85 10:36:04 PDT Received: from ucbdali.ARPA by UCB-VAX.ARPA (4.24/5.2) id AA00517; Fri, 12 Jul 85 10:31:30 pdt Received: by ucbdali.ARPA (4.24/4.48) id AA26130; Fri, 12 Jul 85 10:19:49 pdt Date: Fri, 12 Jul 85 10:19:49 pdt From: fateman%ucbdali@Berkeley (Richard Fateman) Message-Id: <8507121719.AA26130@ucbdali.ARPA> To: common-lisp@su-ai Subject: Re: Proposal for a UNIX subgroup. Cc: marick@gswd-vms there are presumably a few universities involved in similar things (e.g. UC Berkeley will have a UNIX-like system on a reduced instruction set multi-processor (SPUR)), so I would extend your invitation to universities; also, while we are targeting subgroups, maybe there should be a common-lisp multi-processing subgroup standardization (e.g. qlambda, multilisp, spur-lisp, others?).. or more likely, a minimum agreement not to tread on each others' name space.  Received: from SU-AI.ARPA by MIT-MC.ARPA.ARPA; 12 Jul 85 12:47:01 EDT Received: from GSWD-VMS.ARPA by SU-AI.ARPA with TCP; 12 Jul 85 09:37:16 PDT Date: Fri, 12 Jul 85 11:37:34 CDT From: marick@GSWD-VMS Subject: Proposal for a UNIX subgroup. To: common-lisp@su-ai Cc: marick@gswd-vms There are at least four companies working on implementations of Common Lisp for some flavor of UNIX. It would, I think, be to everyone's benefit if the implementations were as compatible as possible (so that, for example, OPEN :IF-EXISTS keywords meant the same things in all implementations). I wouldn't mind seeing a UNIX superset standard, but just giving implementors a way to talk together would be useful. To that end, I propose yet another mailing list, Common-Unix. I volunteer to prime the pump by generating proposals from our own design. Anyone interested? Brian Marick Gould CSD - Urbana  Received: from SU-AI.ARPA by MIT-MC.ARPA.ARPA; 11 Jul 85 15:45:27 EDT Date: 11 Jul 85 1225 PDT From: Dick Gabriel Subject: Archives To: common-lisp@SU-AI.ARPA The archives are, in order of earliest through most recent: COMMON.1[COM,LSP] COMMON.2[COM,LSP] COMMON.3[COM,LSP] COMMON.4[COM,LSP] COMMON.MSG[COM,LSP] on SAIL (Su-AI). No login or password required to FTP or TYPE them. -rpg-  Received: from SU-AI.ARPA by MIT-MC.ARPA.ARPA; 11 Jul 85 13:45:18 EDT Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 11 Jul 85 10:30:53 PDT Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 273051; Thu 11-Jul-85 13:29:47-EDT Date: Thu, 11 Jul 85 13:30 EDT From: David A. Moon Subject: flet and labels To: Nick Gall cc: common-lisp@SU-AI.ARPA In-Reply-To: <850711161211.939102@MIT-MULTICS.ARPA> Message-ID: <850711133003.6.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Thu, 11 Jul 85 12:12 EDT From: Nick Gall Two Questions: 1. Sorry to repeat myself, but are the function-name bindings done by flet and labels (a) of lexical scope and indefinite extent, or (b) of lexical scope and dynamic extent. I believe that the answer was (a), but I lost my copy of the orig. q/a. (a). GLS: This information is on pp.40-41 of the manual, but should be repeated in briefer form on pages 39 and 113. 2. Where is the common-lisp mail-list archive? (so I won't have to repeat questions in the future) SU-AI:COMMON.MSG[COM,LSP]  Received: from SU-AI.ARPA by MIT-MC.ARPA.ARPA; 11 Jul 85 12:30:47 EDT Received: from MIT-MULTICS.ARPA by SU-AI.ARPA with TCP; 11 Jul 85 09:17:48 PDT Date: Thu, 11 Jul 85 12:12 EDT From: Nick Gall Subject: flet and labels To: common-lisp@SU-AI.ARPA Message-ID: <850711161211.939102@MIT-MULTICS.ARPA> Two Questions: 1. Sorry to repeat myself, but are the function-name bindings done by flet and labels (a) of lexical scope and indefinite extent, or (b) of lexical scope and dynamic extent. I believe that the answer was (a), but I lost my copy of the orig. q/a. 2. Where is the common-lisp mail-list archive? (so I won't have to repeat questions in the future) -- Nick  Received: from SU-AI.ARPA by MIT-MC.ARPA.ARPA; 5 Jul 85 19:07:01 EDT Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 5 Jul 85 15:59:09 PDT Received: from Semillon.ms by ArpaGateway.ms ; 05 JUL 85 15:56:59 PDT Date: 5 Jul 85 15:57 PDT From: Masinter.pa@Xerox.ARPA Subject: Re: multiple slot descriptions of the same slot in a DEFSTRUCT In-reply-to: David A. Moon 's message of Fri, 5 Jul 85 16:16 EDT To: Moon@SCRC-STONY-BROOK.ARPA cc: Common-Lisp@SU-AI.ARPA Message-ID: <850705-155659-1763@Xerox> As you may know (since I talked to DLW about this last week), "getting into object-oriented inheritance issues in something as supposedly simple and straightfoward as defstruct" is just what we're up to. We hope to have a proposal out to common-lisp-objects in the next couple of days -- unless there's an overwhelming interest in sending it out to the global list.  Received: from SU-AI.ARPA by MIT-MC.ARPA.ARPA; 5 Jul 85 16:26:41 EDT Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 5 Jul 85 13:17:29 PDT Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 269509; Fri 5-Jul-85 16:17:16-EDT Date: Fri, 5 Jul 85 16:16 EDT From: David A. Moon Subject: multiple slot descriptions of the same slot in a DEFSTRUCT To: Kahn.pa@XEROX.ARPA cc: Common-Lisp@SU-AI.ARPA In-Reply-To: <850704-124942-1313@Xerox> Message-ID: <850705161654.2.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: 4 Jul 85 12:49 PDT From: Kahn.pa@Xerox.ARPA What does the following mean? (defstruct foo (a 0) (a 1)) ....Along the same lines, is it an error when using the :include option to "over-ride" a default as follows (defstruct (bar (:include foo)) (a 2)) .... In my opinion both of these errors. Each defstruct slot must have a distinct name and it is beyond defstruct's scope to attempt to merge together information from multiple sources about a single slot. Let's not get into object-oriented inheritance issues in something as supposedly simple and straightforward as defstruct!  Received: from SU-AI.ARPA by MIT-MC.ARPA.ARPA; 4 Jul 85 15:58:06 EDT Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 4 Jul 85 12:49:23 PDT Received: from Semillon.ms by ArpaGateway.ms ; 04 JUL 85 12:49:42 PDT Date: 4 Jul 85 12:49 PDT From: Kahn.pa@Xerox.ARPA Subject: multiple slot descriptions of the same slot in a DEFSTRUCT To: Common-Lisp@SU-AI.ARPA cc: Kahn.pa@Xerox.ARPA Message-ID: <850704-124942-1313@Xerox> What does the following mean? (defstruct foo (a 0) (a 1)) is it equivalent to (defstruct foo (a 1)) Along the same lines, is it an error when using the :include option to "over-ride" a default as follows (defstruct (bar (:include foo)) (a 2)) or does this work as well as the advertised: (defstruct (bar (:include foo (a 2)))  Received: from SU-AI.ARPA by MIT-MC.ARPA.ARPA; 1 Jul 85 16:36:36 EDT Received: from DEC-HUDSON.ARPA by SU-AI.ARPA with TCP; 1 Jul 85 13:21:08 PDT Date: Mon, 01 Jul 85 16:20:41 EDT From: greek@DEC-HUDSON Subject: Common LISP Registry To: common-lisp@su-ai I've gotten so few responses about my proposal for a Common LISP Registry. I'm suspicious. All the responses have been positive, which makes me even more suspicious. Are folks out there really interested, and do you intend to use the registry. Are the TIs, HPs, Symbolicses, and LMIs on the list going to use the Registry. If not, of course, it won't work, and I don't feel like wasting my time setting it up. - Paul  Received: from SU-AI.ARPA by MIT-MC.ARPA.ARPA; 1 Jul 85 15:42:52 EDT Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 1 Jul 85 11:17:59 PDT Received: ID ; Mon 1 Jul 85 14:17:48-EDT Date: Mon, 1 Jul 1985 14:17 EDT Message-ID: Sender: FAHLMAN@CMU-CS-C.ARPA From: "Scott E. Fahlman" To: DLW@SCRC-QUABBIN.ARPA Cc: Common-lisp@SU-AI.ARPA Subject: Unable to deliver letter In-reply-to: Msg of 25 Jun 1985 13:46-EDT from Postmaster at SCRC-QUABBIN.ARPA It seems reasonably clear to me from the description in the manual that (append 'a) is legal and evaluates to 'a. I guess the manual is just ambiguous enough to confuse people coming from other Lisps where things don't work this way, so a little tightening of the language is called for, but I don't think that there is any question about what the right thing is here. -- Scott  Received: from SU-AI.ARPA by MIT-MC.ARPA.ARPA; 1 Jul 85 12:04:52 EDT Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 1 Jul 85 08:54:32 PDT Received: from CHICOPEE.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 265943; Sun 30-Jun-85 14:19:28-EDT Date: Tuesday, 25 June 1985, 13:46-EDT From: Postmaster at SCRC-QUABBIN.ARPA Subject: Unable to deliver letter To: DLW@SCRC-QUABBIN Resent-To: common-lisp@SU-AI.ARPA Resent-From: DLW@SCRC-QUABBIN.ARPA Resent-Date: Sun, 30 Jun 85 14:24 EDT Resent-Message-ID: <850630142456.3.DLW@CHICOPEE.SCRC.Symbolics.COM> Unable to deliver letter to the following recipient: gls%Aquinas@THINK: Host not responding. ----- Text of letter follows ----- Received: from CHICOPEE.SCRC.Symbolics.COM by SCRC-QUABBIN.ARPA via CHAOS with CHAOS-MAIL id 172966; Tue 18-Jun-85 11:56:52-EDT Date: Tue, 18 Jun 85 11:57 EDT From: Daniel L. Weinreb Subject: [TYSON@SRI-AI.ARPA: APPEND in Common-LISP] To: gls%Aquinas@THINK.ARPA Message-ID: <850618115747.0.DLW@CHICOPEE.SCRC.Symbolics.COM> Fonts: CPTFONT, CPTFONTB, CPTFONTI Reply-To: dlw@SCRC-STONY-BROOK.ARPA This message shows a slight confusion from the wording of APPEND's documentation. My understanding is that what Symbolics CL does is correct, and the manual faked Mabry out by making him think that "APPEND always returns a list" is always true for all valid arguments. Maybe the wording can be made a bit more explicit in the next revision. Date: Mon, 17 Jun 85 20:58 PDT From: Mabry Tyson Subject: APPEND in Common-LISP To: dlw@SCRC-STONY-BROOK.ARPA Fcc: B:>tyson>mail>MYMAIL.mail Message-ID: <850617205802.3.TYSON@BISHOP.ARPA> I was going to write a longish message about how APPEND had problems with a single atomic argument and dotted lists as arguments but I finally realized CL gets out of it via the statement that its arguments are lists and thus are presumed to be true lists... If you don't pass it the expected arguments, anything may happen with perhaps no error message. So, while the argument list specifies "lists" which must be presumed to be true lists (since it can be interpreted differently if passed dotted lists) but it gleefully returns "lists" which specifically may be dotted lists. (At least two interpretations are available: cause an error or ignore the non-list cdr -- ie, ignore the fact the user passed illegal arguments.) I still object to the fact, in SCL, that (APPEND 'A) = A though! At least that one ought to get an error message. Hmmmm... This one may be a legal call to APPEND (since "The last argument actually need not be a list..") but it does not return a list ("The result is a list ..."). At least one version of PSL returns NIL for (APPEND 'A) {It ignores the non-list first argument as though it had just CDRed down to it. Then it takes the second arg (NIL) as the value.} So, is (APPEND 'A) a legal call to append and the "The result is a list..." is invalid? At least UCILisp, or at least the version from Texas, was careful with such things! I feel that programmers tend to err here and need some protection. Maybe someday we will have a super-safe version of CL that will do such error checking.  Received: from SU-AI.ARPA by MIT-MC.ARPA.ARPA; 1 Jul 85 11:11:55 EDT Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 1 Jul 85 08:03:16 PDT Received: ID ; Mon 1 Jul 85 11:03:17-EDT Date: Mon, 1 Jul 1985 11:03 EDT Message-ID: Sender: FAHLMAN@CMU-CS-C.ARPA From: "Scott E. Fahlman" To: Fischer.pa@XEROX.ARPA Cc: common-lisp@SU-AI.ARPA Subject: Comments on Array Summary. In-reply-to: Msg of 28 Jun 1985 17:12-EDT from Fischer.pa at Xerox.ARPA I see no compelling reason to do array-copying when a previously displaced array is undisplaced. If you change displacement to a different array you get new contents; by analogy, if you change displacement to no existing array, it seems perfectly reasonable that you would get a fresh array, observing :initial-contents or :initial-element if they are specified, and with the default emptiness otherwise. What we want to do is handle this odd case without leaving an ugly scar in the language, and it seems to me that this behavior is no more surprising or illogical any other. If people want to copy the target array and displace to that, that is easy enough to do. -- Scott  Received: from SU-AI.ARPA by MIT-MC.ARPA.ARPA; 28 Jun 85 17:24:25 EDT Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 28 Jun 85 14:15:36 PDT Received: from Semillon.ms by ArpaGateway.ms ; 28 JUN 85 14:13:58 PDT Date: 28 Jun 85 14:12 PDT From: Fischer.pa@Xerox.ARPA Subject: Re: Comments on Array Summary. In-reply-to: greek@DEC-HUDSON.ARPA's message of Thu, 27 Jun 85 09:52:56 EDT To: greek@DEC-HUDSON.ARPA cc: common-lisp@su-ai.ARPA Message-ID: <850628-141358-1529@Xerox> It seems that we need a judgement call on whether to copy arrays when they are undisplaced. In all cases but #1 you could specify :initial-contents or :initial-element. Case #1 supposes that :displaced-to was specified. Case #4. You're right, one could choose to not copy the block when the array was shrinking. I believe this is what the Spice CommonLisp code does. :element-type seemed pretty clear. It is treated as an error test, signalling if the array cannot hold elements of that type. Regarding fill pointers: the case that seems ambiguous is vector-pop. It signals an error if the fill pointer is zero, and only then. If a vector is shrunk to a size smaller than where the fill pointer points, what do we do? vector-push and vector-push-extend seem clear about what to do, return nil or enlarge the vector. (ron)  Received: from SU-AI.ARPA by MIT-MC.ARPA.ARPA; 28 Jun 85 13:55:49 EDT Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 28 Jun 85 08:42:03 PDT Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 265138; Fri 28-Jun-85 11:36:59-EDT Date: Fri, 28 Jun 85 11:41 EDT From: Kent M Pitman Subject: feature names To: Snyder%hplabs.csnet@CSNET-RELAY.ARPA cc: Common-Lisp@SU-AI.ARPA In-Reply-To: <8506251758.AA25905@HP-VENUS> Message-ID: <850628114121.1.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> Comment: Remailed at SU-AI after delay caused by dist list error. Date: 25-Jun-85 09:57:28 From: Snyder%hplabs.csnet@csnet-relay.arpa If we agree that feature names are to be read in the keyword package, then I claim there is no advantage to allowing package prefixes to appear in feature names. In particular, if you have to write MIT:FOOBAR to name your feature, why not write MIT-FOOBAR instead? What makes the package system "better" than long names is the ability to be "in" a particular package, so you don't have to write the package name on each symbol. If feature names are always read "in" the keyword package, then this advantage disappears. The disadvantage of allowing package prefixes in feature names is this business of supressing package system errors. Recall that #+ and #- are not the only things which hack features. Admittedly in light of that limited context it seems silly, but there is a bigger issue of what happens to other programs that which to probe the existence of features. eg, my FEATURE-CASE primitive. Besides, you already have to be able to suppress package system errors somehow inside other contexts for the sake of *READ-SUPPRESS*. I'd be willing to go so far as to say NIL should never be a valid feature so that package errors could be handled similarly in this context, returning NIL which would be the equivalent of a non-existent feature...  Received: from SU-AI.ARPA by MIT-MC.ARPA 27 Jun 85 14:18:55 EST Received: from DEC-HUDSON.ARPA by SU-AI.ARPA with TCP; 27 Jun 85 06:53:26 PDT Date: Thu, 27 Jun 85 09:52:56 EDT From: greek@DEC-HUDSON Subject: Comments on Array Summary. To: common-lisp@su-ai After reading Ron's summary, here are my comments: Case 1. OK. Case 2. I'm not sure I agree that copying the elements when undisplacing an array is correct. Hey, if the user doesn't want to have one array look at the same elements as another, then it shouldn't, either by sharing or copying. You want to copy an array, then copy it explicitly. Of course, we don't have COPY-ARRAY, but I'd sure hate to see people copy arrays by displacing to them and then undisplacing! Blech. I'd be perfectly happy if it was an error to undisplace an array; if not, then it shouldn't copy and we should require an :INITIAL-ELEMENT or :INITIAL-CONTENTS option. Case 3. I presume :INITIAL-ELEMENT or :INITIAL-CONTENTS is allowed in this case to reinitialize the array? Case 4. I presume here that you mean "copy if necessary"? In particular, if the new linear size is smaller than the old, many implementations can just change the array dimensions and not touch the data itself. Of course, doing so may prevent lots of data from ever being GCed. Again, I presume :INITIAL-ELEMENT or :INITIAL-CONTENTS are OK. General. Just exactly what does :ELEMENT-TYPE do in each situation? Just exactly what happens to a fill pointer in each situation?  Received: from SU-AI.ARPA by MIT-MC.ARPA 26 Jun 85 23:16:37 EST Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 26 Jun 85 20:08:53 PDT Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 264033; Wed 26-Jun-85 23:03:35-EDT Date: Wed, 26 Jun 85 23:07 EDT From: David A. Moon Subject: Adjustable and displaced arrays (summary) To: Common-Lisp@SU-AI.ARPA References: <850626-152602-1271@Xerox> Message-ID: <850626230737.5.MOON@EUPHRATES.SCRC.Symbolics.COM> Fischer's message agrees with my understanding of the situation.  Received: from SU-AI.ARPA by MIT-MC.ARPA 26 Jun 85 23:07:38 EST Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 26 Jun 85 19:59:03 PDT Received: ID ; Wed 26 Jun 85 22:59:00-EDT Date: Wed, 26 Jun 1985 22:58 EDT Message-ID: Sender: FAHLMAN@CMU-CS-C.ARPA From: "Scott E. Fahlman" To: "David A. Moon" Cc: Common-Lisp@SU-AI.ARPA Subject: char-equal of control characters In-reply-to: Msg of 26 Jun 1985 22:41-EDT from David A. Moon The next time we design a new Lisp, we should separate the concept of characters (which might or might not want to have fonts attached) and input-keystrokes, which would be some implementation-dependent representation of anything that might come in from keyboard land, including combinations of shift bits. It was a mistake to muddle these two ideas together, but it is too late to change that now. I'm not sure I agree with that, since that is what we did in the Lisp machine world originally (before character objects) and it has been a continuing source of grief. Well, the grief might be due directly to the separation of keystrokes and characters, or it might be due to interaction with some other problems in the way the Lisp Machine deals with characters. We would have to isolate the various issues involved before deciding. In any event, "the next time we design a new Lisp" will (for me) not be in my current incarnation, and probably not the next one since I am scheduled to come back as some sort of mollusc next time around, and few of them design programming languages. (Please, no puns about shell scripts...) -- Scott  Received: from SU-AI.ARPA by MIT-MC.ARPA 26 Jun 85 22:50:38 EST Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 26 Jun 85 19:42:08 PDT Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 264017; Wed 26-Jun-85 22:37:20-EDT Date: Wed, 26 Jun 85 22:41 EDT From: David A. Moon Subject: char-equal of control characters To: Scott E. Fahlman cc: Common-Lisp@SU-AI.ARPA In-Reply-To: Message-ID: <850626224129.3.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Wed, 26 Jun 1985 20:59 EDT From: "Scott E. Fahlman" The next time we design a new Lisp, we should separate the concept of characters (which might or might not want to have fonts attached) and input-keystrokes, which would be some implementation-dependent representation of anything that might come in from keyboard land, including combinations of shift bits. It was a mistake to muddle these two ideas together, but it is too late to change that now. I'm not sure I agree with that, since that is what we did in the Lisp machine world originally (before character objects) and it has been a continuing source of grief.  Received: from SU-AI.ARPA by MIT-MC.ARPA 26 Jun 85 18:37:01 EST Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 26 Jun 85 15:26:44 PDT Received: from Semillon.ms by ArpaGateway.ms ; 26 JUN 85 15:26:02 PDT Date: 26 Jun 85 15:25 PDT From: Fischer.pa@Xerox.ARPA Subject: Adjustable and displaced arrays (summary) To: Common-Lisp@SU-AI.arpa Message-ID: <850626-152602-1271@Xerox> Here is "my understanding" of adjustable and displaced arrays. This is an "unproofed by the other participants" summary of a discussion between: Moon@STONY-BROOK.SCRC.Symbolics.COM, fischer.pa, Fahlman@CMU-CS-C, Greek@DEC-HUDSON, RAM@CMU-CS-C, GSB@MIT-MC A simple implementation example of displaced arrays: a displaced array keeps a pointer to the actual array that it is displaced to. Accesses to such a displaced array must look down the chain of displacements to make a reference. It is important that the behavior of this technique be preserved. It becomes critical when, for instance, an array somewhere in the chain of displacements is handed to adjust-array and given a new displacement. Accesses must then follow the new chain. Your mileage may vary, eg you can optimize this any way you please, most commonly by encaching information in the array "header" about the ultimate address and offset of the block of data being referenced. A scheme to update the encached information is then called for (possibly for the whole chain of displaced arrays). adjust-array can alter the dimensionality and contents (or displacement) of an array. It doesn't move elements around to preserve order. It only copies elements if the array they are part of enlarges or shrinks*. Here is an outline of the cases adjust-array handles: If a displacement is given as an argument then set dimensions set displacement else if the old array was displaced then copy the elements (shrink, enlarge or same size**) set new dimensions else if new dimensions have same linear size as old then simply set dimensions else ; new dimensions with different linear size copy elements to new size block. Bear in mind that initial-element, initial-contents, and displaced-to, are mutually exclusive. Completely new contents may be specified by initial-contents. Gaps in a newly enlarged array may be initialized with initial-element. [*Note: CLtL specifically does not specify when an error should be signalled if adjusting an array causes another array displaced to it to have invalid linear size. This could be done at adjust-array time or aref time. Seems to be your choice.] [**Note: this interpretation of the case where a displaced array loses its displacement is made arbitrarily. It is unclear from the text of CLtL whether the elements should be copied into a new block to remove the old displacement, or whether a blank storage block should be created. The former seems somewhat more reasonable.] (ron)  Received: from SU-AI.ARPA by MIT-MC.ARPA 26 Jun 85 14:04:08 EST Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 26 Jun 85 09:40:35 PDT Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 263544; Wed 26-Jun-85 12:35:49-EDT Date: Wed, 26 Jun 85 12:39 EDT From: David A. Moon Subject: char-equal of control characters To: Common-Lisp@SU-AI.ARPA Message-ID: <850626123932.8.MOON@EUPHRATES.SCRC.Symbolics.COM> We're encountering continuing difficulties caused by the fact that CHAR-EQUAL (and the related character and string functions) ignores differences in the bits attribute, so that (CHAR-EQUAL #\A #\Control-A) is true. Does anyone remember the motivation for specifying CHAR-EQUAL this way? It's not set forth in the Common Lisp manual. I went through all my old draft manuals, back to to Colander edition of 29 July 1982, but found no illumination. Since graphic-char-p, alpha-char-p, upper-case-p, and digit-char-p are influenced by the bits attribute of a character, it appears that two characters with different bits attributes are considered to be essentially different, in the same way that pea and pi are essentially different (see the example under CHAR-EQUAL in the manual). I'm not proposing to change anything at this time, but I'd like to understand the motivation. Can the other designers of Common Lisp comment on this? Do any of the other implementors of Common Lisp have relevant experience to offer?  Received: from SU-AI.ARPA by MIT-MC.ARPA 26 Jun 85 21:27:46 EST Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 26 Jun 85 18:00:14 PDT Received: ID ; Wed 26 Jun 85 20:59:57-EDT Date: Wed, 26 Jun 1985 20:59 EDT Message-ID: Sender: FAHLMAN@CMU-CS-C.ARPA From: "Scott E. Fahlman" To: "David A. Moon" Cc: Common-Lisp@SU-AI.ARPA Subject: char-equal of control characters In-reply-to: Msg of 26 Jun 1985 12:39-EDT from David A. Moon Now that you mention it, this business about CHAR-EQUAL ignoring differences in the bits attributes looks like a pure mistake to me. I don't remember any discussion of this -- it probably just sounded halfway plausible and slipped by us all at the time. (Then again, I might be misremembering. I've got no easy way to search the archives.) If we think of the bits attribute as encoding things like control and meta -- funny shift modifiers that really only make sense in keystrokes coming in -- I can't think of very many situations in which we would want to consider #\control-A as being in an equivalence class with #\A. It certainly is not a situation that parallels the close relationship between #\A and #\a. Unless someone thinks of a good reason why CHAR-EQUAL ought to be the way the manual says it is, maybe we should consider changing CHAR-EQUAL to take differing bits into account. The next time we design a new Lisp, we should separate the concept of characters (which might or might not want to have fonts attached) and input-keystrokes, which would be some implementation-dependent representation of anything that might come in from keyboard land, including combinations of shift bits. It was a mistake to muddle these two ideas together, but it is too late to change that now. -- Scott  Received: from SU-AI.ARPA by MIT-MC.ARPA 25 Jun 85 16:37:22 EST Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 25 Jun 85 13:25:08 PDT Received: from hplabs by csnet-relay.csnet id cx00847; 25 Jun 85 16:04 EDT Received: by HP-VENUS id AA25905; Tue, 25 Jun 85 10:58:48 pdt Message-Id: <8506251758.AA25905@HP-VENUS> Date: 25-Jun-85 09:57:28 To: Common-Lisp@su-ai.ARPA Subject: feature names From: Snyder%hplabs.csnet@csnet-relay.arpa Source-Info: From (or Sender) name not authenticated. If we agree that feature names are to be read in the keyword package, then I claim there is no advantage to allowing package prefixes to appear in feature names. In particular, if you have to write MIT:FOOBAR to name your feature, why not write MIT-FOOBAR instead? What makes the package system "better" than long names is the ability to be "in" a particular package, so you don't have to write the package name on each symbol. If feature names are always read "in" the keyword package, then this advantage disappears. The disadvantage of allowing package prefixes in feature names is this business of supressing package system errors. Alan -------  Received: from SU-AI.ARPA by MIT-MC.ARPA 25 Jun 85 09:31:42 EST Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 25 Jun 85 05:10:53 PDT Received: ID ; Tue 25 Jun 85 08:10:45-EDT Date: Tue, 25 Jun 1985 08:10 EDT Message-ID: From: Rob MacLachlan To: Steiner@RUTGERS.ARPA Cc: common-lisp@SU-AI.ARPA Subject: Dribble and *error-output* In-reply-to: Msg of 24 Jun 1985 22:28-EDT from Dave Not any more, it doesn't. It redirects *terminal-io*. Perhaps you have some old version. We lost our original version which was rewritten way back in the beginning, so I rewrote it as the following function: (defun dribble (&optional pathname &key (if-exists :append) (if pathname (with-open-file (f pathname :if-exists if-exists :if-does-not-exist :create) (catch 'dribble-punt (let ((*terminal-io* (make-two-way-stream (make-echo-stream *terminal-io* f) (make-broadcast-stream *terminal-io* f)))) (%top-level)))) (throw 'dribble-punt nil))) This is in misc.slisp Rob  Received: from SU-AI.ARPA by MIT-MC.ARPA 24 Jun 85 23:34:58 EST Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 24 Jun 85 20:27:49 PDT Received: ID ; Mon 24 Jun 85 23:26:44-EDT Date: Mon, 24 Jun 1985 23:26 EDT Message-ID: Sender: FAHLMAN@CMU-CS-C.ARPA From: "Scott E. Fahlman" To: Steiner@RUTGERS.ARPA Cc: common-lisp@SU-AI.ARPA Subject: Dribble and *error-output* The SLISP version of dribble should not be taken as definitive. Dribble exists here only because the manual says we have to have one. Everyone at CMU uses an editor top-level, so if we want a console transcript we just write out the editor buffer. -- Scott  Received: from SU-AI.ARPA by MIT-MC.ARPA 24 Jun 85 22:36:34 EST Received: from RU-BLUE.ARPA by SU-AI.ARPA with TCP; 24 Jun 85 19:28:59 PDT Date: 24 Jun 85 22:28:36 EDT From: Dave Subject: Dribble and *error-output* To: common-lisp@SU-AI.ARPA Reply-To: Steiner@Rutgers Currently the Slisp implementation of Dribble makes a broadcast stream of *standard-output* and the dribble file. If you get an error while doing this, it doesn't show up in the dribble file. Wouldn't it make sense to also have *error-output* be one of the broadcast streams? ds uucp: ...{harvard, seismo, ut-sally, sri-iu, ihnp4!packard}!topaz!steiner arpa: Steiner@RUTGERS -------  Received: from SU-AI.ARPA by MIT-MC.ARPA 24 Jun 85 11:06:06 EST Received: from DEC-HUDSON.ARPA by SU-AI.ARPA with TCP; 24 Jun 85 06:42:41 PDT Date: Mon, 24 Jun 85 09:42:09 EDT From: greek@DEC-HUDSON Subject: Common LISP Registry To: common-lisp@su-ai Well, I seem to be receiving a positive response to my proposal for the Common LISP Registry. I hope for some more responses, particularly if anyone sees problems with my proposal. I'll think about what Scott said concerning registering Common LISP extensions and add something to a second round proposal. I had intended to include a contact address in every registration anyway. Once I've incorporated all comments, I'll send out a second round proposal, including a new section on the registration procedure itself. After that, if there are no objections, I'll declare the registry open? Please, let me know what you think. - Paul  Received: from SU-AI.ARPA by MIT-MC.ARPA 23 Jun 85 18:35:11 EST Date: 23 Jun 85 1519 PDT From: Jon White Subject: Need for #+ and #- To: common-lisp@SU-AI.ARPA Apologies if I'm addressing a non-problem here, but a quick scan of the CL main for the past two weeks there seemed to show an undercurrent of question about the need for #+ and #-, the counter proposal being to do everything by means of eval time macros. A common case wherein I used reader conditionalization while at MIT was in the building and maintenance of several data files. These files had #+ and #- in them, and I wouldn't seriously contemplate writing a post processor for all data read in, simply in order to avoid using #+. One may argue that certain pieces of lisp programs that have reader conditionalizations in them would have been in better style had they used some eval time macro [no need to bring in the compiler here -- I assume that (cond (t ...)) would be optimized, but that doesn't really matter]. On the other hand, in some cases, the #+ construct makes for much more succinct and readable code; compare a #+ in a bound variable list with the eval-time macro that must construct up such a defun in the absence of reader conditionals. -- JonL --  Received: from SU-AI.ARPA by MIT-MC.ARPA 23 Jun 85 18:10:55 EST Date: 23 Jun 85 1502 PDT From: Jon White Subject: What package are feature names resident in? To: moon@SCRC-STONY-BROOK.ARPA, common-lisp@SU-AI.ARPA In-reply-to: your message of 20-Jun-85 16:58 EDT Your most current proposal is exactly what I had been hoping for when first bringing this problem up; namely 1) features are symbols, and the basic "featurep" amounts to a memq on the *features* list; and 2) *package* is temporarily rebound to the keyword package while reading in the feature form, so that the default case is to look for symbols on the keyword package. This solution permits random, or non-keyword, features to exist, but puts the burden on the instigator and user of such random features to prefix them by their package name. Contrast this with the only secure way to use a feature name that is immune to incidental shadowings -- every user would be forced to package-qualify their feature names. Better to not burden the common case user. Two other items I hadn't anticipated seem to have come up 1) Non-existent package qualifiers should be interpeted, in this context, to be missing features [as opposed to being an error] 2) The user of #. will have to be aware of the context change, or else #. will have to be outlawed in the #+ context. I have no particlar feelings on (2) one way or the other, but I do feel rather strongly that *whenever* a programmer has to resort to the use of #., it is an indication of a shortcoming in the defined external syntax. If a reasonable programmer can't find an alternative for his usages of #., then the Common Lisp community should have an action/discussion item on its agenda. Stress "reasonable". -- JonL --  Received: from SU-AI.ARPA by MIT-MC.ARPA 21 Jun 85 20:04:05 EST Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 21 Jun 85 16:55:57 PDT Received: ID ; Fri 21 Jun 85 19:55:20-EDT Date: Fri, 21 Jun 1985 19:55 EDT Message-ID: Sender: FAHLMAN@CMU-CS-C.ARPA From: "Scott E. Fahlman" To: greek@DEC-HUDSON.ARPA Cc: common-lisp@SU-AI.ARPA Subject: Proposal for Common LISP Registrar In-reply-to: Msg of 21 Jun 1985 11:04-EDT from greek at DEC-HUDSON This looks very good to me. Paul has worked out nice solutions to several of the problems I raised in my earlier message. On the issue of registering implementation-specific extensions, a few comments: It is essential that any implementation group be free to extend their own Common Lisp in any compatible way, without asking anyone's permission. Given that, there is considerable benefit to having these groups publicize the extensions they have decided to make, so that other groups making similar extension can do this in a way that is not gratuitously incompatible. The goal of universal compatibility is even better served if the group making the extension is willing to make the code available to others. I'm sure that some companies and universities will be more forthcoming about this than others -- there's a tradeoff between compatibility with competitors and the possibility of gaining an advantage by keeping such information private. In any event, "registering" this information is a rather more complex business than simply registering package names and keywords. Perhaps the right mechanism is for companies to be encouraged to make their red pages available to other implementation groups through some sort of clearinghouse. A central registry could keep a list of groups willing to supply such info, the address to write to when you want such info, and perhaps an index of what extensions are included in each company's stuff. -- Scott  Received: from SU-AI.ARPA by MIT-MC.ARPA 21 Jun 85 15:33:58 EST Received: from DEC-HUDSON.ARPA by SU-AI.ARPA with TCP; 21 Jun 85 06:08:45 PDT Date: Fri, 21 Jun 85 09:08:17 EDT From: greek@DEC-HUDSON Subject: Features & Common LISP Registrar To: common-lisp@su-ai Moon's proposal sounds good to me (now that I've stopped yelling about features in the keyword package). Do we really need to say that errors while reading the feature are equivalent to it not being there? Without an error handling mechanism in Common LISP, that may be tough to implement for some people. Well, thank y'all for the response to my registrar proposal. It seems worth it for me to take some time and write up a short proposal. You'll get it by the end of the day. - Paul  Received: from SU-AI.ARPA by MIT-MC.ARPA 21 Jun 85 15:30:59 EST Received: from DEC-HUDSON.ARPA by SU-AI.ARPA with TCP; 21 Jun 85 08:04:37 PDT Date: Fri, 21 Jun 85 11:04:07 EDT From: greek@DEC-HUDSON Subject: Proposal for Common LISP Registrar To: common-lisp@su-ai PROPOSAL FOR COMMON LISP REGISTRY Purpose ------- The purpose of the Common LISP Registry is to prevent or resolve conflicts in software written for Common LISP implementations. These conflicts can arise in the following areas: o Feature names. We must agree on those features which will be in a flat name space (the keyword package, if we adopt the latest proposal). Such features include implementation subsystems, company names, operating system names, etc. Package-specific features will be in the packages themselves (again, if we agree). o Package names. The package name space is flat, so each and every package that a user might need should have a unique name. o Extensions. The Registry could also maintain a central collection of Common LISP extensions, thus increasing the probability that similar extensions are implemented in a consistent fashion. Such extensions might include additional sharp-sign reader macros, additional format directives, use of numeric extension characters, additional character bits, etc. This tends to be controversial, since it's akin to proposing additions to the language, so maybe it's not time for this yet. Comments? o Surely I forget something. Feature Names ------------- The Registry would be responsible for keeping track of those feature names which reside in a flat name space. The conventions would be as follows (exact names to be determined): o Feature names for LISP dialects are such things as COMMON-LISP, MACLISP, FRANZ-LISP, etc. We should agree on these so that people can write dialect-independent code if possible. We already have some Common LISP implementations using the feature COMMON-LISP and others using just COMMON. o Feature names for Common LISP subsystems are such things as COMPILER, EDITOR, TRACER, FLAVORS, etc. These would be generic names that indicate that some (hopefully standard) such subsystem exists in this implementation. o Feature names for companies are such things as DEC, SYMBOLICS, TI, etc. These names can correspond to trademarks. o Feature names for computers are such things as VAX, DECSYSTEM-20, SYMBOLICS-3600, EXPLORER, etc. These names can correspond to trademarks. o Feature names for operating systems are such things as VMS, UNIX, MSDOS, etc. Some of these names can correspond to trademarks. o Feature names for specific Common LISP implementations are such things as VAX-LISP, SPICE-LISP, etc. Note that the last four items are redundant with some of the functions in Section 25.4.2 of CLtL. This is unfortunate, but the functions are meant to be descriptive to people, while the features are meant to be tested by code. I believe that package-specific features should reside in the package, but this is currently under debate. An implementation would also be free to add any features in the flat name space, so long as they were prefixed with registered features belonging to that implementation (e.g., VAX-LISP-MUMBLE is registered by virtue of VAX-LISP being registered). Package Names ------------- The Registry would be responsible for keeping track of package names. The conventions would be as follows: o The following package names are currently standard: LISP, USER, KEYWORD, SYSTEM (SYS). o Any package names which are prefixed with SYSTEM- or SYS- are considered to be implementation-specific and are automatically registered. o Another set of generic package names will be preregistered for Common LISP subsystems. These are to be determined, but an example is EDITOR. This name is reserved for the editor in any given implementation. A goal is that these names coincide with the corresponding feature names. Note that this convention precludes anyone from creating a fancy new Common LISP editor and selling it under the name of EDITOR (or DEBUGGER or FLAVORS or GRAPHICS or ...). o All other package names must be registered, most importantly those which are assigned to a product to be sold. o It will be possible to register a package prefix. For example, the Acme Artificial Intelligence Corp. registers GAMBLING-EXPERT-* for a set of gambling expert systems. The star is a wildcard, meaning that all names beginning with GAMBLING-EXPERT- are registered. An implementation would also be free to create additional package names as long as they were prefixed with a registered feature belonging to that implementation (e.g., VAX-PACKAGE3 is registered by virtue of VAX being a registered feature). This would, in fact, be the recommended way for an organization to make up package names for separate products. Other Conventions ----------------- All registration would be on a first-come-first-served basis. The Registrar has the right, within reason, to refuse to register a name which is too generic (e.g., ENGINEERING), to short (e.g., A*), likely to conflict with future Common LISP extensions (e.g., GKS), or what have you. In such cases, the reason will always be given. All online correspondence with the registrar will be via the Arpanet to an account with a name such as COMMON-LISP-REGISTRAR. Registration can also be done in writing. The Registration List --------------------- A complete registration list would be published from time to time and distributed to the Common LISP mailing list. Hard copy would also be available upon request. Many new packages may be considered proprietary by the developing organization. I would certainly make a provision for this and not publish such packages. However, since I work for Digital it may be that the organization does not even want me to know about the package. That is why I have provided for automatic registration of names prefixed with a registered feature name.  Received: from SU-AI.ARPA by MIT-MC.ARPA 21 Jun 85 01:47:39 EST Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 20 Jun 85 15:21:05 PDT Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 259808; Thu 20-Jun-85 16:58:33-EDT Date: Thu, 20 Jun 85 16:58 EDT From: David A. Moon Subject: What package are feature names resident in? To: Common-Lisp@SU-AI.ARPA References: <850613224203.3.MOON@EUPHRATES.SCRC.Symbolics.COM> Message-ID: <850620165838.9.MOON@EUPHRATES.SCRC.Symbolics.COM> I'd like to revise my proposal to be that the "feature expression" after a #+ or #- is read in the keyword package if no explicit package prefix appears in it, but it is legal to use an explicit package prefix. I also propose that features defined in the Common Lisp manual be in the keyword package, and "public" features (such as those of a particular implementation) be in the keyword package, by convention. "Private" features can be qualified with a package name when that convention seems appropriate. I also endorse KMP's proposal that package failure while reading a feature name is equivalent to nonpresence of that feature, rather than being an error. Thus (list 1 #+(not nosuchpackage:quux) 2 3) evaluates to a list of 3 elements in most circumstances.  Received: from SU-AI.ARPA by MIT-MC.ARPA 20 Jun 85 22:35:58 EST Received: from USC-ISI.ARPA by SU-AI.ARPA with TCP; 20 Jun 85 12:02:28 PDT Date: 20 Jun 1985 15:01-EDT Sender: OLDMAN@USC-ISI.ARPA Subject: make-string-output-stream From: OLDMAN@USC-ISI.ARPA To: common-lisp@SU-AI.ARPA Message-ID: <[USC-ISI.ARPA]20-Jun-85 15:01:13.OLDMAN> Why doesn't make-string-output-stream accept an optional string (that has a fill pointer)? Format and with-output-to-string which presumably use that function accept such a destination string. --Dan Oldman  Received: from SU-AI.ARPA by MIT-MC.ARPA 20 Jun 85 22:30:53 EST Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 20 Jun 85 11:07:20 PDT Received: from CROW.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 259462; Thu 20-Jun-85 13:05:40-EDT Date: Thu, 20 Jun 85 13:06 EDT From: Robert W. Kerns Subject: Common LISP Registrar To: David C. Plummer in disguise cc: greek@DEC-HUDSON.ARPA, common-lisp@SU-AI.ARPA In-Reply-To: <850620095809.9.NFEP@NEPONSET.SCRC.Symbolics.COM> Message-ID: <850620130623.2.RWK@CROW.SCRC.Symbolics.COM> Date: Thu, 20 Jun 85 09:58 EDT From: David C. Plummer in disguise Date: Thu, 20 Jun 85 09:44:55 EDT From: greek@DEC-HUDSON Since I haven't gotten any response to my offer to be Common LISP registrar, I assume people are either vastly disinterested or not sure what I mean. Is there enough interest that I should write up a little proposal and send it around? The proposal would describe what registration meant and suggest a few policies therefor. If there is going to be the possibility of global name conflicts, at least one registrar is needed. Are you volunteering to be the N registrars for the N possible conflicts? Some subset of N? Or specifically the case that seems to have brought this up: The registry of *FEATURES*? Humurous (?) suggestion: Be the Registrar of Common Lisp Naming Registrars. More seriously, I think it's important that we consider registries as a (mostly compatible) change in the semantics of the language. Don't take that to mean I think it's a bad idea, however. If we're going to do it, we should do it right, and document it, consider its impact, and possibly make other changes in light of that. We may wish to provide ways that users can choose names guarenteed not to conflict with any registered name. For example #+FOO vs #+PRIVATE:FOO. (I don't know if this case example solves a real problem). I don't think this is hard or much work, so long as we recognize that it IS a change.  Received: from SU-AI.ARPA by MIT-MC.ARPA 20 Jun 85 21:41:43 EST Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 20 Jun 85 07:05:56 PDT Received: from NEPONSET.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 259196; Thu 20-Jun-85 09:57:55-EDT Date: Thu, 20 Jun 85 09:58 EDT From: David C. Plummer in disguise Subject: Common LISP Registrar To: greek@DEC-HUDSON.ARPA, common-lisp@SU-AI.ARPA In-Reply-To: The message of 20 Jun 85 09:44-EDT from greek@DEC-HUDSON Message-ID: <850620095809.9.NFEP@NEPONSET.SCRC.Symbolics.COM> Date: Thu, 20 Jun 85 09:44:55 EDT From: greek@DEC-HUDSON Since I haven't gotten any response to my offer to be Common LISP registrar, I assume people are either vastly disinterested or not sure what I mean. Is there enough interest that I should write up a little proposal and send it around? The proposal would describe what registration meant and suggest a few policies therefor. If there is going to be the possibility of global name conflicts, at least one registrar is needed. Are you volunteering to be the N registrars for the N possible conflicts? Some subset of N? Or specifically the case that seems to have brought this up: The registry of *FEATURES*?  Received: from SU-AI.ARPA by MIT-MC.ARPA 20 Jun 85 21:00:56 EST Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 20 Jun 85 17:52:40 PDT Received: ID ; Thu 20 Jun 85 20:51:59-EDT Date: Thu, 20 Jun 1985 20:51 EDT Message-ID: Sender: FAHLMAN@CMU-CS-C.ARPA From: "Scott E. Fahlman" To: "David A. Moon" Cc: Common-Lisp@SU-AI.ARPA Ssject: What package are feature names resident in? In-reply-to: Msg of 20 Jun 1985 16:58-EDT from David A. Moon Moon's revised proposal sounds good to me. -- Scott  Received: from SU-AI.ARPA by MIT-MC.ARPA 20 Jun 85 21:00:07 EST Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 20 Jun 85 08:32:17 PDT Received: ID ; Thu 20 Jun 85 11:31:23-EDT Date: Thu, 20 Jun 1985 11:31 EDT Message-ID: Sender: FAHLMAN@CMU-CS-C.ARPA From: "Scott E. Fahlman" To: greek@DEC-HUDSON.ARPA Cc: common-lisp@SU-AI.ARPA Subject: Common LISP Registrar In-reply-to: Msg of 20 Jun 1985 09:44-EDT from greek at DEC-HUDSON I think that the lack of response to your offer to be the Common Lisp name registrar is because the problem that that would solve doesn't exist yet. So far, we've had no trouble at CMU with conflicting package names in our system or in our code libarary, and we don't use the #+ stuff at all. If we wanted to import something into our library from outside and there was a name conflict, it seems to me that the quickest and easiest solution would be for the library maintainers to fix the problem in some locally appropriate way. Right now, I think that name-conflict resolution is just a natural part of library maintenance. I suppose that someday there will be a lot of commerce in Common Lisp software, and it will benefit the customers that the various big AI packages and various public and proprietary libraries all respect one another's conventions. In that future time, it will be necessary to have some official registrar. It will also be important that there be some agreed-upon mechanism for resolving disputes over these names. Do we give a nice package/feature name like GRAPHICS to the first outfit that asks for it (setting off a gold rush to grab all the good names for future use, much as some companies are now trying to trademark every English word and a lot of otherwise-useful numbers), or do we try to assign a name like GRAPHICS to whatever is the most widely used graphics package around at the time, or do we say that only names like DEC-GRAPHICS will be registered if the root name is too generic? -- Scott  Received: from SU-AI.ARPA by MIT-MC.ARPA 20 Jun 85 12:10:16 EST Received: from DEC-HUDSON.ARPA by SU-AI.ARPA with TCP; 20 Jun 85 06:45:24 PDT Date: Thu, 20 Jun 85 09:44:55 EDT From: greek@DEC-HUDSON Subject: Common LISP Registrar To: common-lisp@su-ai Since I haven't gotten any response to my offer to be Common LISP registrar, I assume people are either vastly disinterested or not sure what I mean. Is there enough interest that I should write up a little proposal and send it around? The proposal would describe what registration meant and suggest a few policies therefor. - Paul  Received: from SU-AI.ARPA by MIT-MC.ARPA 19 Jun 85 22:56:52 EST Received: from DEC-HUDSON.ARPA by SU-AI.ARPA with TCP; 19 Jun 85 07:12:52 PDT Date: Wed, 19 Jun 85 10:12:35 EDT From: greek@DEC-HUDSON Subject: Common LISP Registrar To: common-lisp@su-ai I hereby volunteer to be the Common LISP registrar. This would involve registering package names, features, and anything else we think is necessary. - Paul  Received: from SU-AI.ARPA by MIT-MC.ARPA 18 Jun 85 12:12:27 EST Received: from SCRC-QUABBIN.ARPA by SU-AI.ARPA with TCP; 18 Jun 85 08:59:50 PDT Received: from NEPONSET.SCRC.Symbolics.COM by SCRC-QUABBIN.ARPA via CHAOS with CHAOS-MAIL id 172970; Tue 18-Jun-85 11:57:56-EDT Date: Tue, 18 Jun 85 11:53 EDT From: David C. Plummer in disguise Subject: Features To: greek@DEC-HUDSON.ARPA, Guy Steele , Quux@THINK.ARPA, Steven M. Haflich , dlw@SCRC-STONY-BROOK.ARPA, common-lisp@SU-AI.ARPA, Masinter.pa@XEROX.ARPA, greek%DEC-HUDSON@SU-AI.ARPA, smh%mit-eddie@SU-AI.ARPA, Fahlman@CMU-CS-C.ARPA In-Reply-To: The message of 17 Jun 85 11:13-EDT from greek@DEC-HUDSON.ARPA, <850617115428.2.GLS@UBALDO.ARPA>, <850617120800.3.GLS@UBALDO.ARPA>, <8506171616.AA00429@mit-eddie.ARPA>, The message of 17 Jun 85 13:03-EDT from greek@DEC-HUDSON.ARPA, The message of 17 Jun 85 14:27-EDT from Rem@IMSSS, The message of 17 Jun 85 17:13-EDT from Rem@IMSSS, <850617183248.1.DLW@CHICOPEE.SCRC.Symbolics.COM>, The message of 18 Jun 85 09:35-EDT from greek@DEC-HUDSON.ARPA Message-ID: <850618115336.3.NFEP@NEPONSET.SCRC.Symbolics.COM> Three opinions on this subject: (1) If we are going to order things by kludginess, I think #, is kludgier than #., and that #. is kludgier than #+. (2) I don't think #+#.pred form should work, partially because this is combining two evils at the same time (as opposed to #+pred #.form2 which is two evils at different times!) (3) I'm not vehement about this one, but I think features should be in the keyword package. This allows a relatively simple impmentation of #+ in that it simply binds *package* to the keyword package, turns off #. (ours doesn't right now), does a READ and parses the result. This leads to a slight inconsistency in our implementation: #+3600 causes 3600 (in base 10, because #+ also binds *read-base* to 10) and this simply causes 3600 to be read in as an integer. Since our test on *features* is EQ (should be EQL), this still works. Independent of the above, I think the following needs to be made clear to implementors (which probably means it has to go into CLtL, even though that isn't an implementors guide). The conditional read construct (currently it is #+/#-) must turn of package errors and probably #. and #, while reading forms for effect. Example: (defun frob-net () #+Symbolics (neti:frob-net) #+Spice (spice-network:frob-net) #-(or Symbolics Spice) (error "I see no network here.")) I think it is important for portability to have a read time conditional. How about this proposal (this is very serious and not intended to be a flame): Features are in the keyword package. This means they need to be registered because the keyword package is flat. Registered trademarks can appear as-is, E.g., #+3600, #+Symbolics, #+LMI, etc. (Maybe this should extend to major organizations (maybe they're already registered?)? #+MIT, etc.) Another set of keywords is globally agreed upon by this group, or by the yellow pages group, e.g., #+Flavors. Non-registered keywords must be prefaced with the name of the group that supports the implementation, e.g., #+Symbolics-Rel-6, #+MIT-System-99, etc.  Received: from SU-AI.ARPA by MIT-MC.ARPA 18 Jun 85 10:41:46 EST Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 18 Jun 85 07:33:15 PDT Received: ID ; Tue 18 Jun 85 10:33:20-EDT Date: Tue, 18 Jun 1985 10:33 EDT Message-ID: Sender: FAHLMAN@CMU-CS-C.ARPA From: "Scott E. Fahlman" To: Rem%imss@SU-SCORE.ARPA Cc: COMMON-LISP@SU-AI.ARPA Subject: No change needed for name-domains in package-name space The point of a hierarchical package space, instead of simply using hierarchical conventions for the names themselves, is that if I already have a package named FOO (a shorthand, perhaps, for PACKAGE-NAME-ROOT:FOO) and I get a distinct package named FOO, I can with proper care make the latter into PACKAGE-ROOT:IMPORTS:FOO just by loading it right, and not by going in and editing anythign within the package. Again, the analogy to a tree-structured directory is useful in understanding this: in most decent operating systems I can make /usr/mystuff be the default, and then operate as though there were no other directories around; I never have to worry about stuff in /usr/yourstuff unless I explicitly ask for that. Please note that I am NOT advocating any changes to Common Lisp here. A tree structured package system would have both benefits and costs (in greater complexity), and I like the tradeoff we currently hae in the language. -- Scott  Received: from SU-AI.ARPA by MIT-MC.ARPA 18 Jun 85 10:22:14 EST Received: from IMSSS by SU-AI with PUP; 18-Jun-85 07:08 PDT Date: 18 Jun 1985 0707-PDT From: Rem@IMSSS Subject: No change needed for name-domains in package-name space To: COMMON-LISP@SU-AI If we decide that we want a heirarchy of naming authorities for package names, analagous to ARPA-Internet host-name domains and to Xanadu/Hypertext trademark names, it can be implemented as a convention without changing anything in the CL kernel. You simply hyphenate any package names that aren't at the top level. Thus you'd have LISP and SI and USER etc. but you'd have MIT-BIGFLOAT and CMU-SCRIBE and UTAH-PSLCOMPAT and SU-IMSSS-REM-TEMP856A also. So what's all the fuss about whether or not to have a tree-structured system of naming authorities when we can do it both ways at the same time without changing any CL implementation? Probably we'd let any name be used during debugging, but when exporting a package to another site we'd want the name of the package to be fully qualified to avoid any chance of naming conflict later. Thus TEMP856A might be my first temporary package this month, until I share it with somebody at H/P at which point I have to change the name to the fully qualified name given in the previous paragraph. -------  Received: from SU-AI.ARPA by MIT-MC.ARPA 18 Jun 85 09:45:09 EST Received: from DEC-HUDSON.ARPA by SU-AI.ARPA with TCP; 18 Jun 85 06:35:39 PDT Date: Tue, 18 Jun 85 09:35:23 EDT From: greek@DEC-HUDSON Subject: Features. To: common-lisp@su-ai I guess most people think that features should be keywords. I think this goes against the intended use of keywords, but anyway. I think the argument that they save space as keywords over regular symbols is bogus. Are you intending to have thousands of features? I'm really quite amazed that we've invented packages to hide things, but people don't want package-specific feature information in the package. We HAVE solved the package name conflict to some degree with RENAME-PACKAGE. Not so for keyword features. I did a stint as name registrar for VAX/VMS. There are lots and lots of products and packages for that operating system, and even with a data base of names and associated information, I had conflicts. I don't know who is going to be registrar for Common LISP, but I don't see any reason to make the job harder. - Paul  Received: from SU-AI.ARPA by MIT-MC.ARPA 17 Jun 85 23:49:00 EST Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 17 Jun 85 20:39:19 PDT Received: ID ; Mon 17 Jun 85 23:39:22-EDT Date: Mon, 17 Jun 1985 23:39 EDT Message-ID: Sender: FAHLMAN@CMU-CS-C.ARPA From: "Scott E. Fahlman" To: DALTON FHL (on ERCC DEC-10) Cc: common-lisp@SU-AI.ARPA Subject: flat name space for pkg names In-reply-to: Msg of 17 Jun 1985 19:25-EDT from DALTON FHL (on ERCC DEC-10) Jeff, At the risk of re-opening some issues that are better left alone, I will respond in public to your query. I have no idea what would be an appropriate name-space mechanism for Prolog, but I don't feel that the single-level namespace of Common Lisp is a problem. If two packages are to run together in the same system, they have to agree at *SOME* level of the package system that they are going to use distinct names. If there's no coordination at all, there's always the chance of a collision. You can't get rid of this; you can only bury it deeper. It would be possible to have a hierarchical package structure (or nested, if you prefer to look at it that way), analogous in some ways to hierarchical directories. This makes it possible to have sub-domains of coordination -- if all files coming from CMU have symbols named things like CMU:SOME-PACKAGE:SOME-SYMBOL, the CMU people can coordinate package names among themselves with no fear that MIT people will happen to choose conflicting names; all we have to agree on is that we use the CMU super package and MIT uses the MIT super-package. This sort of thing can be carried on to arbitrary depth. In Common Lisp we decided that it wasn't worth the added complexity, and that a single namespace for packages would suffice. I have not yet seen any reason to regret that decision. If we try to import some new module (or set of modules) whose choices for package names happen to conflict with some existing modules, we do minor surgery on one file or the other to eliminate the conflict. Inelegant, but good enough. -- Scott  Received: from SU-AI.ARPA by MIT-MC.ARPA 17 Jun 85 19:31:11 EST Received: from UCL-CS.ARPA by SU-AI.ARPA with TCP; 17 Jun 85 16:19:16 PDT Received: from edxa.ac.uk by 44d.Cs.Ucl.AC.UK via Janet with NIFTP id a002496; 17 Jun 85 23:58 BST From: DALTON FHL (on ERCC DEC-10) Date: Monday, 17-Jun-85 23:25:52-GMT Message-ID: <132231-763-675@EDXA> To: common-lisp , J.Dalton%edxa@ucl-cs.arpa Subject: flat name space for pkg names -------- [This is not a proposal for changing Common Lisp; it is just a request for information. You may want to reply just to me rather than to the mailing list.] We're curently looking into ways of adding "modules" to Prolog, where modules are just some way of having multiple name spaces. One possible model for at least some parts of this is Common Lisp packages (packages rather than Common Lisp modules). But, whenever they are mentioned, someone always raises the objection that there can be name conflicts between package names. (Suppose two programs are to be combined and both have some procedures packaged up in a "graph" package. The "graph" packages meant to be independent, but they clash.) My question, then, is this: why was a flat name space for package names chosen for Common Lisp instead of one that allowed subpackages? And how are package conflicts of the kind mentioned above meant to be resolved? Cheers, Jeff Dalton AIAI, University of Edinburgh --------  Received: from SU-AI.ARPA by MIT-MC.ARPA 17 Jun 85 18:43:47 EST Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 17 Jun 85 15:32:56 PDT Received: from CHICOPEE.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 256071; Mon 17-Jun-85 18:29:15-EDT Date: Mon, 17 Jun 85 18:32 EDT From: Daniel L. Weinreb Subject: features To: Fahlman@CMU-CS-C.ARPA, common-lisp@SU-AI.ARPA In-Reply-To: Message-ID: <850617183248.1.DLW@CHICOPEE.SCRC.Symbolics.COM> Fonts: CPTFONT, CPTFONTB, CPTFONTI Reply-To: dlw@SCRC-STONY-BROOK.ARPA I agree with you and Moon. Let them be keywords. The namespace for packages is already flat; if we are not dealing with conflicting package names then there is no need to deal with conflicting feature names. The language is hairy enough as it is.  Received: from SU-AI.ARPA by MIT-MC.ARPA 17 Jun 85 18:30:29 EST Received: from SU-AI.ARPA by MIT-MC.ARPA 17 Jun 85 11:50:07 EST Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 17 Jun 85 08:39:54 PDT Received: ID ; Mon 17 Jun 85 11:39:44-EDT Date: Mon, 17 Jun 1985 11:39 EDT Message-ID: From: Rob MacLachlan To: Common-Lisp@SU-AI.ARPA Subject: With-Open-File :if-does-not-exist nil Comment: Remailed after delay caused by network problem. What should be done in With-Open-File if open returns NIL as a consequence of a :if-does-not-exist or :if-exists or :probe keyword? Our current implementation simply binds the result, whatever it is, to the variable. It has been suggested that it would be better to not evaluate the body in this case. I have my doubts about this, but the current implementation also has problems, since it will attempt to close NIL when the body is exited. Rob  Received: from SU-AI.ARPA by MIT-MC.ARPA 17 Jun 85 18:15:56 EST Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 17 Jun 85 14:56:26 PDT Received: from hplabs by csnet-relay.csnet id ah26751; 17 Jun 85 17:48 EDT Received: by HP-VENUS id AA15341; Mon, 17 Jun 85 11:20:06 pdt Message-Id: <8506171820.AA15341@HP-VENUS> Date: 17-Jun-85 11:05:30 To: postmaster@csnet-relay.arpa Subject: Botched mail message From: perdue%hplabs.csnet@csnet-relay.arpa Source-Info: From (or Sender) name not authenticated. Mike, here is a copy of one of the messages I got back after attempting to send mail to Tim Tillson at FSD. Note that the address shown is "hpfclp!twt@csnet-relay.arpa", but what I actually typed in as the address was "hpfclp!twt". Thanks for looking into this. As I mentioned, I have received something around 15 replies of this general nature. UUCP X.1 >From uhplabs Mon Jun 17 07:40:58 1985 remote from hpatlS >From COMSAT@MIT-MC Mon Jun 17 04:11:57 1985 remote from hplabs Received: by HP-VENUS id AA02358; Mon, 17 Jun 85 04:11:57 pdt Date: Mon, 17 Jun 85 03:34:37 EDT From: Communications Satellite Received: by HP-VENUS via CSNET; 17 Jun 1985 04:11:54-PDT (Mon) Received: from su-ai.arpa by csnet-relay.arpa id a022463; 17 Jun 85 3:35 EDT Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 17 Jun 85 00:33:36 PDT To: "@SU-AI.ARPA:hplabs!perdue%hplabs.csnet@csnet-relay.arpa"@SU-AI Via: CSNet; 17 Jun 85 4:11-PDT Subject: Msg of Monday, 17 June 1985 03:34-EDT Message-Id: <[MIT-MC].545653.850617> ============ A copy of your message is being returned, because: ============ "PGS@MIT-MC.ARPA" at MIT-MC is an unknown recipient. ============ Failed message follows: ============ Received: from SU-AI.ARPA by MIT-MC.ARPA 17 Jun 85 03:32:52 EST Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 17 Jun 85 00:22:18 PDT Received: from hplabs by csnet-relay.csnet id ac22393; 17 Jun 85 3:19 EDT Received: by HP-VENUS id AA18871; Sun, 16 Jun 85 16:27:57 pdt Message-Id: <8506162327.AA18871@HP-VENUS> Date: 16-Jun-85 16:25:39 To: hpfclp!twt@csnet-relay.arpa Subject: Interesting Common LISP mail From: perdue%hplabs.csnet@csnet-relay.arpa Source-Info: From (or Sender) name not authenticated. Here is an especially interesting piece of mail that was sent out to the Common LISP distribution list. Note the suggestion of a more or less official group of implementors of Common LISP for conventional architectures. -Cris UUCP X.1 >From uhplabs Wed Jun 12 03:39:56 1985 remote from hpatlS >From Moon@stony-brook.scrc.symbolics.com Wed Jun 12 00:21:21 1985 remote from hplabs Received: by HP-VENUS id AA05084; Wed, 12 Jun 85 00:21:21 pdt Mail-From: HP-VENUS received 12-Jun-85 00:22:24 Received: by HP-VENUS id AA05040; Wed, 12 Jun 85 00:20:56 pdt Date: Tue, 11 Jun 85 23:51 EDT From: "David A. Moon" Received: by HP-VENUS via CSNET; 12 Jun 1985 00:20:53-PDT (Wed) Received: from su-ai.arpa by csnet-relay.arpa id a024133; 12 Jun 85 0:00 EDT Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 11 Jun 85 20:52:13 PDT Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 252533; Tue 11-Jun-85 23:49:29-EDT To: "Scott E. Fahlman" Via: CSNet; 12 Jun 85 0:20-PDT Subject: Adjustable and displaced arrays Cc: common-lisp@SU-AI In-Reply-To: Message-Id: <850611235159.4.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Tue, 11 Jun 1985 21:43 EDT From: "Scott E. Fahlman" OK, if we accept Moon's view of the proper semantics for all this, and if we decide not to outlaw displacing to adjustable arrays, then the Fortran machines probably have to forego cacheing and let each call to Aref potentially grovel the headers of both arrays (or a whole chain of arrays). Maybe that is not so bad, since none of this affects Simple-Vectors, and they are the only kind of array that really HAS to be fast. However, the vendors of non-microcodable machines may feel, with some justification, that they don't want to slow down ALL references to non-simple arrays just so that the obscure case of adjusting an array that is displaced to will work properly. Perhaps the right move is to unbundle the SIMPLE declaration and allow the user to declare that an array is NOT-DISPLACED, even if it is not simple in other respects. Sure. I would think that an appropriate way to proceed would be for the implementors on non-Lisp machines to get together and agree on a common set of language extensions to deal with this sort of issue. At a later time, those extensions can be moved into the standard language, once they are well-debugged and agreed to be the right thing for all machines that need them. Until that happens, programs that use the extensions won't be portable to all implementations (but they will probably be portable to almost all implementations if the extensions are designed right, e.g. as ignorable declarations). ------- -------  Received: from SU-AI.ARPA by MIT-MC.ARPA 17 Jun 85 17:29:34 EST Received: from IMSSS by SU-AI with PUP; 17-Jun-85 14:15 PDT Date: 17 Jun 1985 1413-PDT From: Rem@IMSSS Subject: Unrecant To: smh%mit-eddie@SU-AI cc: greek%DEC-HUDSON@SU-AI, COMMON-LISP@SU-AI Aha, I think greek misled us, and smh is right. The names of the features are interned identifiers (symbols), which are used only for their data-matching value, i.e. exactly like keywords. The list which contains all current features, *FEATURES*, is a normal identifier which shouldn't be in the keyword package, it should be in LISP or SI or somesuch system package. Now that makes it harder to handle ad hoc keywords that aren't yet registered and thus might have conflicting names with features in other user software that may or may not have been registered. Perhaps the registered features should be keywords and the unregistered ones should be in private experimental packages, but all of them should be consed onto the list LISP:*FEATURES* or whatever it is? Having the unregistered feature names in private packages is wasteful because they have things like value cells etc. whereas true keywords can actually be in a special package that doesn't even have hooks for values etc., but this inefficient use of fullblown identifiers (symbols) for just their keyword semantics is temporary until they become registered. -------  Received: from SU-AI.ARPA by MIT-MC.ARPA 17 Jun 85 14:53:44 EST Received: from IMSSS by SU-AI with PUP; 17-Jun-85 11:30 PDT Date: 17 Jun 1985 1127-PDT From: Rem@IMSSS Subject: Recant: features don't belong in keyword package To: greek%DEC-HUDSON@SU-AI cc: COMMON-LISP@SU-AI In my comparison of benign characteristics of keywords, I completely forgot the obvious, that you (greek) pointed out, that the boolean fact of whether the keyword exists or not isn't important, whereas features are essentially flags. I therefore amend my proposal. Features should be in their own package or in some system-standard package such as LISP, except for ad hoc (not yet registered) features which should temporarily reside in their own private packages to avoid inadvertant name conflict. After an ad hoc feature turns into an official (registered) feature, it moves into the standard package for features, and during the transition period when a user programmer doesn't know where it might be a boolean OR can be used to select the two possibilities. Thus first REMTEST3:BIGFLOAT might be a private feature, then when things are stable the name is submitted to the registry but there's already some registered feature called exactly BIGFLOAT so my new feature gets called REMBFLOAT or BFLOAT2 or somesuch, so we ask programmers to say (OR REMTEST3:BIGFLOAT BFLOAT2) for a while, then after a reasonable time we change the installed feature name to be BFLOAT2 which is transparent to any program doing the OR. New programs written after the transition can of course just use BFLOAT2 without the OR. -------  Received: from SU-AI.ARPA by MIT-MC.ARPA 15 Jun 85 22:07:12 EST Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 15 Jun 85 18:59:13 PDT Received: from Semillon.ms by ArpaGateway.ms ; 15 JUN 85 18:59:13 PDT Date: 15 Jun 85 18:59 PDT From: Masinter.pa@Xerox.ARPA Subject: Re: What #+rmhackery a good idea #-rmhackery utter nonsense In-reply-to: David C. Plummer in disguise 's message of Fri, 14 Jun 85 21:09 EDT To: DCP@SCRC-STONY-BROOK.ARPA cc: COMMON-LISP@SU-AI.ARPA Message-ID: <850615-185913-1015@Xerox> Sorry, my message was a bit too #+:-). Examples of code that don't use #+ and #-: (if (status 'lispm) (progn ... 20 pages of lispm code ...)) (if (not (status 'lispm)) (progn ... 20 pages of generic CL code ...)) I'd prefer (defun hairy-thing () (if (status 'lispm) (compute-hairy-thing-for-LispM) (compute-generic-hairy-thing)) but if you insist: (defmacro const (x) `',(eval x)) (defun hairy-thing () (cond ((status 'lispm) (const (compute-hairy-thing-for-LispM)) (t (const (compute-generic-hairy-thing))))  Received: from SU-AI.ARPA by MIT-MC.ARPA 14 Jun 85 23:54:15 EST Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 14 Jun 85 20:43:17 PDT Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 254772; Fri 14-Jun-85 23:40:09-EDT Date: Fri, 14 Jun 85 23:43 EDT From: Kent M Pitman Subject: features To: Fahlman@CMU-CS-C.ARPA cc: Common-Lisp@SU-AI.ARPA In-Reply-To: References: <850614141940.5.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> Message-ID: <850614234301.4.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> Date: Fri, 14 Jun 1985 21:46 EDT From: "Scott E. Fahlman" It was clear at the time we let #+ and #- into the language that these were total kludges and were being kept around almost entirely for reasons of compatibility with existing code. I disagree with this. #+ and #- are necessary because implementations invariably differ in all kinds of unexpected ways and sometimes it is necessary (both in program and data files) to completely blindfold READ to gross kludges. While I think it's reasonable to describe this as a total kludge, I think you're kidding yourself to think such kludges are a thing of the past and something that will not continue to occur. In spite of a desire I'm sure we all have to never resort to these tools, they serve a vital function and should be made as convenient and as well-defined as possible for those situations where they turn out to be needed. ... I think it would be a major mistake to try to extend them by letting them take an arbitrary extension to evaluate ... I certainly agree with this part. #. can handle the more complicated situations. I think that by far the simplest solution is to make #+foo treat the symbol FOO as a keyword, despite the lack of a leading colon in this context. This minimizes the possibilities for subtle package lossage of the type Moon describes. Yes, it would then be possible that packages developed in total ignorance of each other might choose confliciting feature keywords; on the other hand, such packages have an equally great chance of choosing conflicting package names, so there has to be some modest amount of coordination if they are to run together. I think that this is a change and not a clarification, however -- there's no way to read the current manual as specifying this conversion to keywords... Statements like "yes, it would then be possible ..." and such which suggest that you want to ignore the "hard cases" completely miss the point. #+ and #- have their major use in the strangest situations and flattening the namespace will not serve to make things better. I think that putting all these symbols in the Lisp package (as external symbols) is not workable. For ont thing, this will often result in some internal symbol in Lisp being unintentionally made external, and then when another package imports Lisp it is in for some unpleasant surprises.... As I said in an earlier message, I am content to have a fixed and advertised set of Common-Lisp approved features reside on the keyword package, but I very strongly oppose any use of the keyword package for any application which involves an user-extensible set of names (such as the features list). In my opinion, user-defined features should must be packaged (and expressly not on the keyword package); refer to my earlier message on this subject for details. The manual is quite clear that the features are to be symbols (or lists that are boolean combinations of symbols), and I don't see any reason to extend that. #+3600 can read the string "3600" as the name of a (keyword) symbol. This avoids all radix lossage. I guess I really don't like this because it destroys the simple user model that READ is involved and it makes one wonder if #+FOO:3600 will read as FOO:/3600 or just :/3600.  Received: from SU-AI.ARPA by MIT-MC.ARPA 14 Jun 85 21:55:19 EST Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 14 Jun 85 18:46:31 PDT Received: ID ; Fri 14 Jun 85 21:46:27-EDT Date: Fri, 14 Jun 1985 21:46 EDT Message-ID: Sender: FAHLMAN@CMU-CS-C.ARPA From: "Scott E. Fahlman" To: common-lisp@SU-AI.ARPA Subject: features It was clear at the time we let #+ and #- into the language that these were total kludges and were being kept around almost entirely for reasons of compatibility with existing code. For the cases that they can handle, they are convenient enough, but I think it would be a major mistake to try to extend them by letting them take an arbitrary extension to evaluate, as Paul the Greek proposes. There are many problems, among them being the problem of which Lisp interpreter is used to evaluate the expression in question if the #+ stuff is being used to allow the same file to work in, say, Common Lisp and Maclisp. I think that by far the simplest solution is to make #+foo treat the symbol FOO as a keyword, despite the lack of a leading colon in this context. This minimizes the possibilities for subtle package lossage of the type Moon describes. Yes, it would then be possible that packages developed in total ignorance of each other might choose confliciting feature keywords; on the other hand, such packages have an equally great chance of choosing conflicting package names, so there has to be some modest amount of coordination if they are to run together. I think that this is a change and not a clarification, however -- there's no way to read the current manual as specifying this conversion to keywords. I think that putting all these symbols in the Lisp package (as external symbols) is not workable. For ont thing, this will often result in some internal symbol in Lisp being unintentionally made external, and then when another package imports Lisp it is in for some unpleasant surprises. The manual is quite clear that the features are to be symbols (or lists that are boolean combinations of symbols), and I don't see any reason to extend that. #+3600 can read the string "3600" as the name of a (keyword) symbol. This avoids all radix lossage. -- Scott  Received: from SU-AI.ARPA by MIT-MC.ARPA 14 Jun 85 21:18:19 EST Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 14 Jun 85 18:10:15 PDT Received: from NEPONSET.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 254716; Fri 14-Jun-85 21:07:05-EDT Date: Fri, 14 Jun 85 21:09 EDT From: David C. Plummer in disguise Subject: What #+rmhackery a good idea #-rmhackery utter nonsense To: Masinter.pa@XEROX.ARPA, Greek@DEC-HUDSON.ARPA cc: COMMON-LISP@SU-AI.ARPA In-Reply-To: <850614-150318-1105@Xerox> Message-ID: <850614210948.4.NFEP@NEPONSET.SCRC.Symbolics.COM> Date: 14 Jun 85 15:03 PDT From: Masinter.pa@Xerox.ARPA The #+rmhackery feature #-rmhackery lossage of "#+" and "#-" is one of the more dubious in GSSB. Expanding it with #+(good-ideap ':rmhackery) the obvious extension #-(good-ideap ':rmhackery) the awful extension of allowing arbitrary expressions in the feature-forms removes any hope of being able to do anything with a file of code than #+(good-ideap ':rmhackery) allows the natural extension to more complex situations #-(good-ideap ':rmhackery) load it. I'm not sure what you mean. Anyway, in our implementation, #+ and #- does a READ with *package* bound to the keyword package as well as turning off #. (see below). It then uses STRING-EQUAL as the comparison function with the symbols (presumed, but not forced [I think] to be keywords) in *FEATURES* for the appropriate tokens (e.g., :LISPM and :NIL are the appropriate tokens of #+(or LispM NIL)). We've had this for years and it doesn't seem to have any problems. What happened to the natural constructs (IF (STRING= (SOFTWARE-TYPE) "VMS") ) It doesn't allow #+LispM (progn ... 20 pages of LispM specific code ... ) #-LispM (progn ... 20 pages of generic CL code ... ) One could even imagine (whoa) a compiler that would expand (SOFTWARE-TYPE) into a constant, and evaluate STRING= at compile time if the args were constant (!) Our compiler would do this today if somebody put STRING= in the list of functions to apply constant folding to. Of course, there's always #+#.(STRING= (SOFTWARE-TYPE) "VMS"). Says who? In our implementation, #. is turned off while reading #+ or #-. Suppose I shipped some code that said #-LispM #.(error nil "This code hasn't been made to run on non-LispMs yet.") Perhaps a better example would be building machine dependent data structures inside #+ or #-: (defun hairy-thing () #+LispM '#.(compute-hairy-thing-for-LispM) #-LispM '#.(compute-generic-hairy-thing))  Received: from SU-AI.ARPA by MIT-MC.ARPA 14 Jun 85 18:12:24 EST Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 14 Jun 85 15:03:23 PDT Received: from Semillon.ms by ArpaGateway.ms ; 14 JUN 85 15:03:18 PDT Date: 14 Jun 85 15:03 PDT From: Masinter.pa@Xerox.ARPA Subject: What #+rmhackery a good idea #-rmhackery utter nonsense to: Greek@DEC-HUDSON.ARPA cc: COMMON-LISP@SU-AI.ARPA Message-ID: <850614-150318-1105@Xerox> The #+rmhackery feature #-rmhackery lossage of "#+" and "#-" is one of the more dubious in GSSB. Expanding it with #+(good-ideap ':rmhackery) the obvious extension #-(good-ideap ':rmhackery) the awful extension of allowing arbitrary expressions in the feature-forms removes any hope of being able to do anything with a file of code than #+(good-ideap ':rmhackery) allows the natural extension to more complex situations #-(good-ideap ':rmhackery) load it. What happened to the natural constructs (IF (STRING= (SOFTWARE-TYPE) "VMS") ) One could even imagine (whoa) a compiler that would expand (SOFTWARE-TYPE) into a constant, and evaluate STRING= at compile time if the args were constant (!) Of course, there's always #+#.(STRING= (SOFTWARE-TYPE) "VMS").  Received: from SU-AI.ARPA by MIT-MC.ARPA 14 Jun 85 17:47:54 EST Received: from IMSSS by SU-AI with PUP; 14-Jun-85 14:38 PDT Date: 14 Jun 1985 1438-PDT From: Rem@IMSSS Subject: Features in keyword package? Yes. To: COMMON-LISP@SU-AI It seems to me the essential thing about keywords is that they are interned (hashed) thus can be uniquely recognized, but don't have any other objects (values functions or properties) associated with them. This places them somewhat between strings and normal identifiers (symbols). Anyway, features seem to have the same essential things, they need to be recognized but they needn't have values etc. assigned to them. So it makes sense to put them in the keyword package, and to default the current package to the keyword package in places where they are expected so that the user needn't type the : prefix, such as after #+. (This is analagous to not needing the : prefix after &KEY in a lambda expression; But actually I'm a little confused by the example on page 65 at the bottom, where : prefix isn't used inside the body either. I presume START and END are lexical variables in the current package, not in the KEYWORD package, thus somehow the lambda expression establishes a temporary linkage between similarily-named variables in two different packages, without actually importing them as a permanent side-effect. It's possible my confusion here invalidates my opinion. Can somebody explain this strangeness?) -------  Received: from SU-AI.ARPA by MIT-MC.ARPA 14 Jun 85 16:28:39 EST Received: from DEC-HUDSON.ARPA by SU-AI.ARPA with TCP; 14 Jun 85 13:16:36 PDT Date: Fri, 14 Jun 85 16:16:12 EDT From: greek@DEC-HUDSON Subject: Putting features in the keyword package. To: common-lisp@su-ai Dave Moon and others have suggested that features should be symbols in the keyword package. I see some problems with this: 1. People seem to think that packages and subsystems will want to add things to *FEATURES* because that make conditionalizing code using the packages easier. Fine, but that's a real good reason why the features ought to be in that package. Otherwise packages will have duplicate features names and things will get confused. Packages are to isolate names! 2. If features are in the keyword package, are they keywords? I suppose so. Thus we get things like #+:COMPILER. I really think package-specific stuff ought to stay in that package. Perhaps we should extend #+ so I can write #+(FOO:FEATURE-P :OPTION1) to find out if package FOO has OPTION1 now. That syntax won't work, but you know what I mean. If I could evaluate an arbitrary form with #+, then I could also write things like #+(STRING= (SOFTWARE-TYPE) "VMS"). Otherwise we need redundant information in *FEATURES* to specify the operating system, etc. If we need to make arbitrary decision with #+, then let's bite the bullet and allow that. - Paul  Received: from SU-AI.ARPA by MIT-MC.ARPA 14 Jun 85 14:30:54 EST Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 14 Jun 85 11:19:57 PDT Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 254453; Fri 14-Jun-85 14:16:48-EDT Date: Fri, 14 Jun 85 14:19 EDT From: Kent M Pitman Subject: What's in *FEATURES*? To: Moon@SCRC-STONY-BROOK.ARPA, greek@DEC-HUDSON.ARPA cc: common-lisp@SU-AI.ARPA In-Reply-To: <850614130943.0.MOON@EUPHRATES.SCRC.Symbolics.COM> Message-ID: <850614141940.5.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> Date: Fri, 14 Jun 85 13:09 EDT From: David A. Moon Date: Fri, 14 Jun 85 09:09:45 EDT From: greek@DEC-HUDSON It seems to me that, since *FEATURES* is a "global" variable, the items in the list should not be package-specific. The features should pertain to the LISP system as a whole, specifying things which parameterize the system. If a package wants to itemize features within it, that should be done with something inside the package (special variable or function). Furthermore, even the existence of a package isn't a feature, but rather is noted by the presence of its name in *MODULES*. It's not even clear to me that *FEATURES* isn't a constant, but that might be a little radical. In light of my opinion, features can only be simple symbols, all present in the LISP package. Right? The problem with that idea is that putting a symbol into the LISP package makes that symbol be shared among all packages except those that explicitly shadow it. Thus it is not a good idea to put a lot of extra symbols into the LISP package in addition to the ones listed in the manual. If *FEATURES* were a constant, controlled solely by the implementation, the problem would simply be that different implementations would have different symbols in the LISP package, which could be lived with (it happens anyway). But the #+ and #- syntaxes are quite convenient and many large programs want to push their own symbols onto *FEATURES*. I don't think it's at all a good idea for such symbols to also be exported from the LISP package. And it would be silly to have two versions of #+, one for "system features" and the other for "user features." The main reason the KEYWORD package exists is to serve as a flat namespace that, unlike the LISP package, has no effect on inter-package sharing. Thus I think the KEYWORD package is the right one for features. I dislike the idea of saying package doesn't matter on features. There was a big hassle in Maclisp years ago because two compatible implementations of strings both wanted to use the name STRING. If one could have done #+JOE:STRING and #+BILL:STRING, we'd have been OK. I'm willing to go so far as to say that common features which we wish to standardize meanings for might want to go on the keyword package and that user-defined features could be legislated not to be allowed there. From this, we could further define that #+ and #- would do the effect of (LET ((PACKAGE (FIND-PACKAGE "KEYWORD"))) (READ)) so that #+FOO was like #+:FOO. So, for example, if COMPLEX was something we expected some implementations to fail to provide for some reason, we might say legislate that implementations providing it must have a :COMPLEX feature and people could use #+COMPLEX. But people providing private features would be forced to do #+FOO:COMPLEX. We should stipulate that package-not-found errors after #+ and #- are to be treated as if the feature were missing. Would people buy this or some close variation thereof? It gets around the problem of having to make feature names go on LISP (since everything is on keyword) without losing package information and without causing people to type package names in common (pun?) situations.  Received: from SU-AI.ARPA by MIT-MC.ARPA 14 Jun 85 13:23:39 EST Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 14 Jun 85 10:10:13 PDT Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 254385; Fri 14-Jun-85 13:07:02-EDT Date: Fri, 14 Jun 85 13:09 EDT From: David A. Moon Subject: What's in *FEATURES*? To: greek@DEC-HUDSON.ARPA cc: common-lisp@SU-AI.ARPA In-Reply-To: The message of 14 Jun 85 09:09-EDT from greek@DEC-HUDSON Message-ID: <850614130943.0.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Fri, 14 Jun 85 09:09:45 EDT From: greek@DEC-HUDSON It seems to me that, since *FEATURES* is a "global" variable, the items in the list should not be package-specific. The features should pertain to the LISP system as a whole, specifying things which parameterize the system. If a package wants to itemize features within it, that should be done with something inside the package (special variable or function). Furthermore, even the existence of a package isn't a feature, but rather is noted by the presence of its name in *MODULES*. It's not even clear to me that *FEATURES* isn't a constant, but that might be a little radical. In light of my opinion, features can only be simple symbols, all present in the LISP package. Right? The problem with that idea is that putting a symbol into the LISP package makes that symbol be shared among all packages except those that explicitly shadow it. Thus it is not a good idea to put a lot of extra symbols into the LISP package in addition to the ones listed in the manual. If *FEATURES* were a constant, controlled solely by the implementation, the problem would simply be that different implementations would have different symbols in the LISP package, which could be lived with (it happens anyway). But the #+ and #- syntaxes are quite convenient and many large programs want to push their own symbols onto *FEATURES*. I don't think it's at all a good idea for such symbols to also be exported from the LISP package. And it would be silly to have two versions of #+, one for "system features" and the other for "user features." The main reason the KEYWORD package exists is to serve as a flat namespace that, unlike the LISP package, has no effect on inter-package sharing. Thus I think the KEYWORD package is the right one for features.  Received: from SU-AI.ARPA by MIT-MC.ARPA 14 Jun 85 12:09:51 EST Received: from THINK.ARPA by SU-AI.ARPA with TCP; 14 Jun 85 09:00:49 PDT Received: by THINK.ARPA with CHAOS id AA25189; Fri, 14 Jun 85 11:54:53 edt Date: Friday, 14 June 1985, 11:56-EDT From: Guy Steele Subject: [hpfclp!paul%hplabs.csnet: LCM] To: common-lisp@sail Cc: gls@THINK.ARPA In-Reply-To: Message-Id: <850614115605.1.GLS@DESIDERIUS.ARPA> Date: Thu, 13 Jun 1985 17:39 EDT From: "Scott E. Fahlman" This one's for you. I can't remember how or whether this discussion finally got resolved. --------------------------------------------------------------------------- Date: Thursday, 13 June 1985 09:48-EDT From: hpfclp!paul%hplabs.csnet at csnet-relay.arpa To: hplabs!Fahlman Re: LCM MMDF-Warning: Parse error in preceding line at CSNET-RELAY.ARPA Source-Info: From (or Sender) name not authenticated. Scott, Is the definition of LCM (12.4) being modified so that it will accept 0 arguments? If so, is the result 1? Paul Beiser Hewlett-Packard Ft. Collins, Colorado uucp: ...{ihnp4,hplabs}!hpfcla!paul arpa: "hpfclp!paul%hplabs.csnet"@csnet-relay I believe everyone agrees that *if* LCM is to accept zero arguments then it should return 1. I strongly recommend that all implementors support this case as an extension to Common Lisp, and intend to recommend the change when we update Common Lisp. --Guy  Received: from SU-AI.ARPA by MIT-MC.ARPA 14 Jun 85 11:35:22 EST Received: from DEC-HUDSON.ARPA by SU-AI.ARPA with TCP; 14 Jun 85 06:09:59 PDT Date: Fri, 14 Jun 85 09:09:45 EDT From: greek@DEC-HUDSON Subject: What's in *FEATURES*? To: common-lisp@su-ai It seems to me that, since *FEATURES* is a "global" variable, the items in the list should not be package-specific. The features should pertain to the LISP system as a whole, specifying things which parameterize the system. If a package wants to itemize features within it, that should be done with something inside the package (special variable or function). Furthermore, even the existence of a package isn't a feature, but rather is noted by the presence of its name in *MODULES*. It's not even clear to me that *FEATURES* isn't a constant, but that might be a little radical. In light of my opinion, features can only be simple symbols, all present in the LISP package. Right? - Paul  Received: from SU-AI.ARPA by MIT-MC.ARPA 13 Jun 85 22:56:08 EST Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 13 Jun 85 19:42:20 PDT Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 254089; Thu 13-Jun-85 22:39:13-EDT Date: Thu, 13 Jun 85 22:42 EDT From: David A. Moon Subject: What package are feature names resident in? To: Common-Lisp@SU-AI.ARPA In-Reply-To: The message of 25 Apr 85 07:19-EST from Jon White , Message-ID: <850613224203.3.MOON@EUPHRATES.SCRC.Symbolics.COM> Was the following issue ever resolved? I don't think I saw anything about it other than these two messages. Date: 25 Apr 85 0419 PST From: Jon White 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 . . . Date: Fri, 26 Apr 1985 15:11 EST From: Rob MacLachlan 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. The manual is not clear on this point. I think the most likely reading of what the manual says is that features are packaged symbols. However, I don't believe that that can be workable in practice. As JonL pointed out, it's difficult to deal with this unless you make every feature a keyword, but then you have a lot of extra colons flying around. In some cases the package in which a feature symbol would be defined will not even be defined if the feature is not present. An example: ;; Use fast matrix multiplication if present, else do it by hand (defmacro mm (m1 m2 m3) #+fastarithmetic:fastarithmetic `(fastarithmetic:matrix-multiply ,m1 ,m2 ,m3) #-fastarithmetic:fastarithmetic `(dotimes (i (array-dimension ,m1 0)) (dotimes (j (array-dimension ,m2 1)) (let ((sum 0)) (dotimes (k (array-dimension ,m1 1)) (incf sum (* (aref ,m1 i k) (aref ,m2 k j)))) (setf (aref ,m3 i j) sum))))) A flat namespace for feature names would avoid these problems, and surely would have no more name conflicts than the existing flat namespaces for packages and modules. I'd like to propose that the manual be "clarified" on pp.358-9 to say that #+ and #- are not sensitive to packages when reading @I[feature]; this applies both to feature names and to the AND, OR, and NOT operators. Incidentally, in our implementation feature names can be numbers; these are not sensitive to radix. (This is so we can say #+3600; I'd hate for this to be illegal syntax in another Common Lisp implementation.) The manual should also be "clarified" on p.448 to say that the symbols on *features* should be keywords and that any numbers present should be notated in decimal. Does anyone object to this?  Received: from SU-AI.ARPA by MIT-MC.ARPA 13 Jun 85 17:59:58 EST Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 13 Jun 85 14:47:01 PDT Received: ID ; Thu 13 Jun 85 17:45:58-EDT Date: Thu, 13 Jun 1985 17:45 EDT Message-ID: Sender: FAHLMAN@CMU-CS-C.ARPA From: "Scott E. Fahlman" To: Alan Snyder Cc: common-lisp@SU-AI.ARPA Subject: conflicting declarations In-reply-to: Msg of 12 Jun 1985 18:56-EDT from Alan Snyder I would say that the current status is that it "is an error". We might want to specify that redundant declarations are harmless, the conflicting case is (signals?) an error, and if the declared types are hierarchically related, the more restrictive governs. But right now, I don't think the user has the right to count on any particular behavior in these cases. -- Scott  Received: from SU-AI.ARPA by MIT-MC.ARPA 13 Jun 85 17:39:56 EST Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 13 Jun 85 14:27:41 PDT Received: from hplabs by csnet-relay.csnet id ah05457; 13 Jun 85 17:18 EDT Received: by HP-VENUS id AA28111; Wed, 12 Jun 85 15:55:22 pdt Message-Id: <8506122255.AA28111@HP-VENUS> Date: Wed 12 Jun 85 15:56:27-PDT From: Alan Snyder Subject: conflicting declarations To: common-lisp@su-ai.ARPA Source-Info: From (or Sender) name not authenticated. I could not find anything in Chapter 9 to cover the case of multiple declarations for the same variable binding, particularly the case of conflicting declarations. Examples: 1. (defun foo (x) (declare (type float x)) (declare (type float x)) ; redundant ... 2. (defun foo (x) (declare (type float x)) (declare (type integer x)) ; conflicting ... 3. (defun foo (x) (declare (type number x)) (declare (type integer x)) ; restricting ... 4. (defun foo (x) (declare (type integer x)) (declare (type number x)) ; enlarging ... Any opinions on what the definition does or should say in such cases? Should any set of individually legal declarations be legal, with the textually last declaration taking effect in cases of conflict? Should an error be signalled if multiple declarations of the same "kind" are found? If so, in all cases above? (I find example 3 remotely reasonable. Perhaps the first declaration is machine-generated and the second was added by the programmer who knew more?) -------  Received: from SU-AI.ARPA by MIT-MC.ARPA 13 Jun 85 16:03:42 EST Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 13 Jun 85 12:46:47 PDT Received: from MIT-OZ by MIT-MC.ARPA via Chaosnet; 13 JUN 85 15:47:39 EDT Date: Thu 13 Jun 85 15:44:59-EDT From: Rodney A. Brooks Subject: Re: declaration pervasiveness. To: gls@THINK.ARPA cc: common-lisp@SU-AI.ARPA, jk@SU-AI.ARPA In-Reply-To: Message from "Guy Steele " of Thu 13 Jun 85 14:39:33-EDT The notinline declaration does not apply to the call to the (bar m m) version. The description of notinline specifically notes that lexical scoping is observed regarding the references to function names occurring in the declaration. So the declaration (notinline f) refers to the function named f that is visible at that point, namely the (* m m) version. The declaration is pervasive in that it affects all *calls* to that specific f (not *bindings* of other functions also named f) in the body of the construct. The call to the (bar m m) version is not a call to the f referred to by the notinline declaration, but to some other f, and so is not affected by that declaration. --Guy Ok. Thats sounds reasonable. But what's the difference between a pervasive and a non-pervasive declaration then? Your description would fit a type declaration also, which the manual says is not pervasive. As I read it the only difference is that in addition to what you say above, the declaration of notinline, since it is pervasive (page 155), also applies to calls to that specific f within the local function definitions of an FLET or LABELS (which are outside the body). By your lexical scoping argument this only affects LABELS as that particular f is not visible in the FLET function definitions. Could you comment on whether these declarations are even legal in the body of an FLET, LABELS or MACROLET since pages 113 and 154 seem to be contradictory. On random typography: in the table at the top of page 154, do* preceeds do whereas let* and prog* come after let and prog respectively. -------  Received: from SU-AI.ARPA by MIT-MC.ARPA 13 Jun 85 14:52:27 EST Received: from THINK.ARPA by SU-AI.ARPA with TCP; 13 Jun 85 11:39:38 PDT Received: by THINK.ARPA with CHAOS id AA17400; Thu, 13 Jun 85 14:29:45 edt Date: Thu, 13 Jun 85 14:30 EDT From: Guy Steele Subject: declaration pervasiveness. To: common-lisp@SU-AI.ARPA Cc: jk@SU-AI.ARPA, gls@THINK.ARPA In-Reply-To: Your message of 12 Jun 85 19:44-EDT Message-Id: <850613143035.1.GLS@YON.ARPA> Received: from GODOT by AQUINAS via CHAOS with CHAOS-MAIL; Wed 12-Jun-85 20:08:52-EDT Received: from SU-AI.ARPA (su-ai.arpa.ARPA) by THINK.ARPA id AA09914; Wed, 12 Jun 85 20:03:40 edt Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 12 Jun 85 17:04:32 PDT Received: from MIT-OZ by MIT-MC.ARPA via Chaosnet; 12 JUN 85 19:46:52 EDT Date: Wed 12 Jun 85 19:44:14-EDT From: Rodney A. Brooks Subject: declaration pervasiveness. To: common-lisp@SU-AI.ARPA Cc: jk@SU-AI.ARPA I'm having trouble deciding exactly how pervasive certain declarations are. For instance: (defun f (n) (flet ((f (m) (* m m))) (declare (ftype (function (integer) integer) f)) (declare (notinline f)) (+ (f n) (flet ((f (m) (bar m m))) (f n))))) By analogy to type it would appear that the ftype declaration applies to the call to the (* m m) f, but not to the (bar m m) call. There is specific language in the first paragraph of page 159 that implies that. However notinline , which has precisely the same language applied to it at the top of page 160, is earlier singled out has having nothing to do with bindings and being pervasive on page 155. So does the notinline apply to the call to the (bar m m) version or not? If not, then page 155, and the notion of pervasiveness seem misleading. ------- The notinline declaration does not apply to the call to the (bar m m) version. The description of notinline specifically notes that lexical scoping is observed regarding the references to function names occurring in the declaration. So the declaration (notinline f) refers to the function named f that is visible at that point, namely the (* m m) version. The declaration is pervasive in that it affects all *calls* to that specific f (not *bindings* of other functions also named f) in the body of the construct. The call to the (bar m m) version is not a call to the f referred to by the notinline declaration, but to some other f, and so is not affected by that declaration. --Guy  Received: from SU-AI.ARPA by MIT-MC.ARPA 13 Jun 85 12:46:23 EST Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 13 Jun 85 09:35:35 PDT Received: from MIT-OZ by MIT-MC.ARPA via Chaosnet; 13 JUN 85 12:34:49 EDT Date: Thu 13 Jun 85 12:32:11-EDT From: Rodney A. Brooks Subject: Re: declaration pervasiveness. To: DCP@SCRC-QUABBIN.ARPA, common-lisp@SU-AI.ARPA cc: jk@SU-AI.ARPA In-Reply-To: Message from "David C. Plummer in disguise " of Thu 13 Jun 85 11:23:12-EDT From: David C. Plummer in disguise Subject: declaration pervasiveness. If you follow the language defined in the book, you will find that your function is illegal. Declarations are not permitted after FLET, LABELS, or MACROLET. A lot of the language in the book seems to assume that these forms don't exist. ?? In my copy of the book (the one from digital press) all of FLET, LABELS and MACROLET are included in a list at the top of page 154 which claim to be the forms in which declarations can appear at the beginning of a body. However page 113 does seem to disagree with this--there the only declarations are in the definition parts of the functional `variables'. Once you admit their existance, it is clear (to me at least) that several things follow. First, FTYPE and [NOT]INLINE declarations should be able to follow them and second, that these declarations should not be pervasive. That sounds reasonable to me too. But that's not what page 155 currently says. -------  Received: from SU-AI.ARPA by MIT-MC.ARPA 13 Jun 85 12:43:36 EST Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 13 Jun 85 09:32:53 PDT Received: ID ; Thu 13 Jun 85 12:32:33-EDT Date: Thu, 13 Jun 1985 12:32 EDT Message-ID: Sender: FAHLMAN@CMU-CS-C.ARPA From: "Scott E. Fahlman" To: "David C. Plummer in disguise" Cc: common-lisp@SU-AI.ARPA Subject: declaration pervasiveness. In-reply-to: Msg of 13 Jun 1985 11:20-EDT from David C. Plummer in disguise If you follow the language defined in the book, you will find that your function is illegal. Declarations are not permitted after FLET, LABELS, or MACROLET. A lot of the language in the book seems to assume that these forms don't exist. Once you admit their existance, it is clear (to me at least) that several things follow. First, FTYPE and [NOT]INLINE declarations should be able to follow them and second, that these declarations should not be pervasive. This seems to me like the only sensible interpretation, even if the language in the book is contradictory. What we have here is a very strong analogy with variable-binding forms, and we need similar machinery for declaring things about a particular lexical binding of a function name. Obviously the language about declarations in the book was written before we had really faced up to the existence of lexically scoped function definitions. I'm not so sure about MACROLET, however. It's not clear that FTYPE and INLINE make any sense here. -- Scott  Received: from SU-AI.ARPA by MIT-MC.ARPA 13 Jun 85 11:30:30 EST Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 13 Jun 85 08:21:41 PDT Received: from NEPONSET.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 253562; Thu 13-Jun-85 11:18:40-EDT Date: Thu, 13 Jun 85 11:20 EDT From: David C. Plummer in disguise Subject: declaration pervasiveness. To: Rodney A. Brooks , common-lisp@SU-AI.ARPA cc: jk@SU-AI.ARPA In-Reply-To: The message of 12 Jun 85 19:44-EDT from Rodney A. Brooks Message-ID: <850613112008.7.NFEP@NEPONSET.SCRC.Symbolics.COM> Date: Wed 12 Jun 85 19:44:14-EDT From: Rodney A. Brooks I'm having trouble deciding exactly how pervasive certain declarations are. For instance: (defun f (n) (flet ((f (m) (* m m))) (declare (ftype (function (integer) integer) f)) (declare (notinline f)) (+ (f n) (flet ((f (m) (bar m m))) (f n))))) By analogy to type it would appear that the ftype declaration applies to the call to the (* m m) f, but not to the (bar m m) call. There is specific language in the first paragraph of page 159 that implies that. However notinline , which has precisely the same language applied to it at the top of page 160, is earlier singled out has having nothing to do with bindings and being pervasive on page 155. So does the notinline apply to the call to the (bar m m) version or not? If not, then page 155, and the notion of pervasiveness seem misleading. ------- If you follow the language defined in the book, you will find that your function is illegal. Declarations are not permitted after FLET, LABELS, or MACROLET. A lot of the language in the book seems to assume that these forms don't exist. Once you admit their existance, it is clear (to me at least) that several things follow. First, FTYPE and [NOT]INLINE declarations should be able to follow them and second, that these declarations should not be pervasive.  Received: from SU-AI.ARPA by MIT-MC.ARPA 13 Jun 85 08:50:52 EST Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 13 Jun 85 05:42:11 PDT Received: from CONCORD.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 253452; Thu 13-Jun-85 08:39:18-EDT Date: Thu, 13 Jun 85 08:43 EDT From: Bernard S. Greenberg Subject: Re: Does Defmacro establish a block? To: AS%hplabs.csnet@CSNET-RELAY.ARPA, common-lisp@SU-AI.ARPA In-Reply-To: <8506121623.AA16535@HP-VENUS> Message-ID: <850613084351.1.BSG@CONCORD.SCRC.Symbolics.COM> Date: Wed 12 Jun 85 09:24:07-PDT From: Alan Snyder I believe that all defining forms that have a name and a body should put a named block around the body. I fail to see the advantage of all these named blocks being created implicitly. Too many implicit definitions can be confusing. Can you provide an example of how an implicit named block around, say, a DEFMACRO, will ever confuse anyone, in any case, forced as it may be? "Why, suppose somebody shouted 'ALAKAZAM00112233MXYZPTLK' by accident!"  Received: from SU-AI.ARPA by MIT-MC.ARPA 12 Jun 85 20:14:39 EST Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 12 Jun 85 17:04:32 PDT Received: from MIT-OZ by MIT-MC.ARPA via Chaosnet; 12 JUN 85 19:46:52 EDT Date: Wed 12 Jun 85 19:44:14-EDT From: Rodney A. Brooks Subject: declaration pervasiveness. To: common-lisp@SU-AI.ARPA cc: jk@SU-AI.ARPA I'm having trouble deciding exactly how pervasive certain declarations are. For instance: (defun f (n) (flet ((f (m) (* m m))) (declare (ftype (function (integer) integer) f)) (declare (notinline f)) (+ (f n) (flet ((f (m) (bar m m))) (f n))))) By analogy to type it would appear that the ftype declaration applies to the call to the (* m m) f, but not to the (bar m m) call. There is specific language in the first paragraph of page 159 that implies that. However notinline , which has precisely the same language applied to it at the top of page 160, is earlier singled out has having nothing to do with bindings and being pervasive on page 155. So does the notinline apply to the call to the (bar m m) version or not? If not, then page 155, and the notion of pervasiveness seem misleading. -------  Received: from SU-AI.ARPA by MIT-MC.ARPA 12 Jun 85 18:11:54 EST Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 12 Jun 85 14:59:13 PDT Received: ID ; Wed 12 Jun 85 17:58:32-EDT Date: Wed, 12 Jun 1985 17:58 EDT Message-ID: From: Rob MacLachlan To: Alan Snyder Cc: common-lisp@SU-AI.ARPA Subject: Does Defmacro establish a block? In-reply-to: Msg of 12 Jun 1985 12:24-EDT from Alan Snyder It is clearly stated in the manual that defun establishes a block named with the function name. This is a feature which I use extensively. The question is "Which of the other def-mumbles establish a block as well, and if not why not?" Moon's answer is "They all do." Admittedly returning out of the body of a deftype will probably not often be useful, but this definition has the advantage that it is consistent. This consistency doesn't cost anything, so we might as well do thing this way. Rob  Received: from SU-AI.ARPA by MIT-MC.ARPA 12 Jun 85 17:05:26 EST Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 12 Jun 85 13:53:00 PDT Received: from hplabs by csnet-relay.csnet id ak28624; 12 Jun 85 16:48 EDT Received: by HP-VENUS id AA16535; Wed, 12 Jun 85 09:23:17 pdt Message-Id: <8506121623.AA16535@HP-VENUS> Date: Wed 12 Jun 85 09:24:07-PDT From: Alan Snyder Subject: Re: Does Defmacro establish a block? To: common-lisp@su-ai.ARPA In-Reply-To: Message from ""David A. Moon" " of Tue 11 Jun 85 14:32:35-PDT Source-Info: From (or Sender) name not authenticated. I believe that all defining forms that have a name and a body should put a named block around the body. I fail to see the advantage of all these named blocks being created implicitly. Too many implicit definitions can be confusing. Is it really too much to ask the programmer to put in an explicit block on those occasions when he/she wants to do a return from one of these constructs? Does it happen that often? Are there some situations (I hope not!) where the system can put a block where the programmer cannot (and where it makes sense to return to)? -------  Received: from SU-AI.ARPA by MIT-MC.ARPA 12 Jun 85 16:49:36 EST Received: from IMSSS by SU-AI with PUP; 12-Jun-85 13:37 PDT Date: 12 Jun 1985 1334-PDT From: Rem@IMSSS Subject: Printing of displaced/shared arrays To: COMMON-LISP@SU-AI It seems to me the "problem" of loss of sharing when you print displaced arrays and try to read them back in is classical. Normal printing of any data structure that shares non-atomic parts with itself or anything else, followed by reading it back in, causes the sharing to be lost. We've accepted that fact since day one and seeing it crop up with displaced arrays shouldn't upset us. We should expect that when an array is printed out all information about its structure (dimensions) and contents (elements) should be included in the printing, except that information about shared structure will be lost if the normal printer is used. Some really smart printer might be able to recognize shared structure and arrange to preserve it on reading back in, but normally we shouldn't expect such a printer to be available for all possible cases of sharing that can occur. If a program has a crazy-quilt of displaced arrays sharing structure, the programmer shouldn't expect to be able to print out the structure and later read it back in. But the programmer should be able to expect to be able to print out the structure for purpose of eyeballing it during debugging, and not have critical information lost, such as which axis are of length zero. Thus the proposal to use #.(MAKE-ARRAY ...) or whatever seems reasonable in cases where normal print representation loses critical information. -------  Received: from SU-AI.ARPA by MIT-MC.ARPA 12 Jun 85 16:22:59 EST Received: from IMSSS by SU-AI with PUP; 12-Jun-85 13:12 PDT Date: 12 Jun 1985 1310-PDT From: Rem@IMSSS Subject: Test suite to say what manual is confusing about To: COMMON-LISP@SU-AI It seems to me urgent to create a test suite for aspects of CL that are so complicated that nobody has found a way to explain them so that a majority of readers would truly understand them. Thus the test suite would determine whether a given implementation is correct or not, and would serve as the standard definition until such time as somebody figures out how to explain it precisely in English. It also seems that displaced adjustable mumble arrays is a case where this need for test suite applies. Anybody who thinks he understands what the manual meant to say, care to volunteer to make a test suite for arrays? (Anybody agree with my opinion that test suite is needed for such?) -------  Received: from SU-AI.ARPA by MIT-MC.ARPA 12 Jun 85 15:35:57 EST Received: from DEC-HUDSON.ARPA by SU-AI.ARPA with TCP; 12 Jun 85 12:25:06 PDT Date: Wed, 12 Jun 85 15:24:48 EDT From: greek@DEC-HUDSON Subject: Printing Arrays with #. To: common-lisp@su-ai Just to clarify, I really was asking whether all funny arrays should be printed with #. (not #<>). I don't like the idea, either for arrays with zero dimensions or for nonsimple arrays, but I'm not sure why it bothers me. I'd rather see those guys printed with #<>. - Paul  Received: from SU-AI.ARPA by MIT-MC.ARPA 12 Jun 85 13:10:51 EST Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 12 Jun 85 09:59:23 PDT Received: from CONCORD.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 252868; Wed 12-Jun-85 12:56:10-EDT Date: Wed, 12 Jun 85 13:00 EDT From: Bernard S. Greenberg Subject: Using #.(MAKE-ARRAY ... To: greek@DEC-HUDSON.ARPA, common-lisp@SU-AI.ARPA In-Reply-To: The message of 12 Jun 85 08:56-EDT from greek@DEC-HUDSON Message-ID: <850612130012.9.BSG@CONCORD.SCRC.Symbolics.COM> Date: Wed, 12 Jun 85 08:56:25 EDT From: greek@DEC-HUDSON I have an uncomfortable feeling about the printer generating complex function calls with #. as a way to print something. I'm not really sure why it bothers me so much. Well, for one, if I had some complex network of displaced arrays with all sorts of hairy attributes, I think it would be as part of some complicated data structure: an attempt to print them out in such away that the reader, on reading-back-in, would create an array "similar to lisp", but in no way part of the data structure of my program at that time, is wholly bogus and misguided help. Should we also adopt the convention that arrays which can't be printed with #A for other reasons will be printed with #. Such things as fill pointers, adjustability, displacement, etc. can't be represented with #A. If we do this, then the printed representation is not suitable for the :INITIAL-CONTENTS options, since that option won't take an array. If we don't do this, the printer is really lying about the array. By my argument above, the more cases it uses #< (I think that's what you meant) the better it is, and the fewer times it will lie about arrays. - Paul  Received: from SU-AI.ARPA by MIT-MC.ARPA 12 Jun 85 12:38:31 EST Received: from THINK.ARPA by SU-AI.ARPA with TCP; 12 Jun 85 09:28:21 PDT Received: by THINK.ARPA with CHAOS id AA05340; Wed, 12 Jun 85 12:23:04 edt Date: Wednesday, 12 June 1985, 12:24-EDT From: Guy Steele Subject: Adjusting Displaced Arrays To: greek@DEC-HUDSON@THINK.ARPA, common-lisp@su-ai Cc: gls@THINK.ARPA In-Reply-To: The message of 12 Jun 85 09:29-EDT from greek at DEC-HUDSON at think Message-Id: <850612122418.1.GLS@UBALDO.ARPA> Date: Wed, 12 Jun 85 09:29:57 EDT From: greek@DEC-HUDSON@think .... 2. Moon stated that adjusting an array never affect the target array. Assuming my point #1 is correct, then the target array is affected if a) it is specified in the :DISPLACED-TO option, and b) the :INITIAL-ELEMENT option is also specified. If I'm incorrect here, then I think that implies that the new array has to share some element with the original target array and also have some of its own! The problem here is vague language in the manual under ADJUST-ARRAY. Under MAKE-ARRAY, it says in more than one place that :INITIAL-ELEMENT and :DISPLACED-TO may not be used together. This restriction should apply to ADJUST-ARRAY also. The language under ADJUST-ARRAY is misleading in a number of respects about how :INITIAL-ELEMENT and :DISPLACED-TO are handled. --Guy  Received: from SU-AI.ARPA by MIT-MC.ARPA 12 Jun 85 11:39:43 EST Received: from LL-XN.ARPA by SU-AI.ARPA with TCP; 12 Jun 85 04:16:54 PDT Received: by ll-xn.arpa.ARPA (4.24/4.7) id AA02250; Wed, 12 Jun 85 07:17:35 edt Date: Wed, 12 Jun 85 07:17:35 edt From: walton%ll-xn.arpa@ll-xn.ARPA (Robert Walton) Message-Id: <8506121117.AA02250@ll-xn.arpa.ARPA> To: common-lisp@su-ai Subject: Two suggestions on array adjustability. We (Machine Intelligence and Tactical Sensors Project of MIT Lincoln Laboratory) have an `image understanding operating system' called SKETCH written in FRANZ and C and running on a VAX which has a large array package that effectively replaces the FRANZ array package for our purposes. Based on our experience with this, I do not think we could (optimally) use COMMON LISP arrays for an image understanding system, and here are two suggestions, triggered by the recent discussion of displaced arrays, that might begin to fix this. (1) Non-adjustability should be a dynamic declarable attribute. If an array is declared non-adjustable in a block, it should be an error to adjust the array when the block is active. The compiler should make use of the declaration to optimize code. However, when an array is in no such block, it should be adjustable. Non-adjustability of a displaced array implies non-adjustability of the array it is displaced to. We often adjust displaced arrays and then pass them off to C code that treats them as non-adjustable (given a good enough COMMON LISP compiler we might, sometime in the future, replace the C code with COMMON LISP code). [I would guess that non-adjustability could never be the same as simplicity, since the later may imply a different array header structure, and untagged hardware should know about this difference at compile time if possible.] (2) Displaced arrays should be allowed to have non-standard subscript multipliers. Negative multipliers and 0 should be allowed. We use this most frequently to transpose arrays and reverse left and right or up and down. It is obviously applicable to decimating arrays, though we have little actual experience with this. I offer these suggestions from the user's point of view only, though they certainly seem implementable to me (after being refined to make them more precise).  Received: from SU-AI.ARPA by MIT-MC.ARPA 12 Jun 85 11:17:40 EST Received: from DEC-HUDSON.ARPA by SU-AI.ARPA with TCP; 12 Jun 85 05:56:41 PDT Date: Wed, 12 Jun 85 08:56:25 EDT From: greek@DEC-HUDSON Subject: Using #.(MAKE-ARRAY ... To: common-lisp@su-ai I have an uncomfortable feeling about the printer generating complex function calls with #. as a way to print something. I'm not really sure why it bothers me so much. Should we also adopt the convention that arrays which can't be printed with #A for other reasons will be printed with #. Such things as fill pointers, adjustability, displacement, etc. can't be represented with #A. If we do this, then the printed representation is not suitable for the :INITIAL-CONTENTS options, since that option won't take an array. If we don't do this, the printer is really lying about the array. - Paul  Received: from SU-AI.ARPA by MIT-MC.ARPA 12 Jun 85 10:52:19 EST Received: from DEC-HUDSON.ARPA by SU-AI.ARPA with TCP; 12 Jun 85 06:30:17 PDT Date: Wed, 12 Jun 85 09:29:57 EDT From: greek@DEC-HUDSON Subject: Adjusting Displaced Arrays To: common-lisp@su-ai I'll accept the hair of allowing arbitrary "nesting" of displaced arrays, but I don't have to like it. Unless I missed a message, I still don't understand some things. 1. CLtL says that if the :DISPLACED-TO option is specified on ADJUST-ARRAY then none of the original contents of the array appears in the new array. I presume, of course, that this is not the case when displacing back to the original target array, which I have to explicitly request according to the first paragraph on page 298. 2. Moon stated that adjusting an array never affect the target array. Assuming my point #1 is correct, then the target array is affected if a) it is specified in the :DISPLACED-TO option, and b) the :INITIAL-ELEMENT option is also specified. If I'm incorrect here, then I think that implies that the new array has to share some element with the original target array and also have some of its own! The reason we chose not to implement adjustable displaced arrays in VAX LISP was not because we have a religious objection, but because I didn't understand what to do. I guess I'd like to see a list of all the options to ADJUST-ARRAY and what they do to displaced arrays. We also need to specify any interactions between the options, such as with :DISPLACED-TO AND :INITIAL-ELEMENT above. - Paul  Received: from SU-AI.ARPA by MIT-MC.ARPA 12 Jun 85 00:01:02 EST Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 11 Jun 85 20:52:13 PDT Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 252533; Tue 11-Jun-85 23:49:29-EDT Date: Tue, 11 Jun 85 23:51 EDT From: David A. Moon Subject: Adjustable and displaced arrays To: Scott E. Fahlman cc: common-lisp@SU-AI.ARPA In-Reply-To: Message-ID: <850611235159.4.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Tue, 11 Jun 1985 21:43 EDT From: "Scott E. Fahlman" OK, if we accept Moon's view of the proper semantics for all this, and if we decide not to outlaw displacing to adjustable arrays, then the Fortran machines probably have to forego cacheing and let each call to Aref potentially grovel the headers of both arrays (or a whole chain of arrays). Maybe that is not so bad, since none of this affects Simple-Vectors, and they are the only kind of array that really HAS to be fast. However, the vendors of non-microcodable machines may feel, with some justification, that they don't want to slow down ALL references to non-simple arrays just so that the obscure case of adjusting an array that is displaced to will work properly. Perhaps the right move is to unbundle the SIMPLE declaration and allow the user to declare that an array is NOT-DISPLACED, even if it is not simple in other respects. Sure. I would think that an appropriate way to proceed would be for the implementors on non-Lisp machines to get together and agree on a common set of language extensions to deal with this sort of issue. At a later time, those extensions can be moved into the standard language, once they are well-debugged and agreed to be the right thing for all machines that need them. Until that happens, programs that use the extensions won't be portable to all implementations (but they will probably be portable to almost all implementations if the extensions are designed right, e.g. as ignorable declarations).  Received: from SU-AI.ARPA by MIT-MC.ARPA 11 Jun 85 23:56:03 EST Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 11 Jun 85 20:48:00 PDT Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 252531; Tue 11-Jun-85 23:45:14-EDT Date: Tue, 11 Jun 85 23:47 EDT From: David A. Moon Subject: Does Defmacro establish a block? To: Scott E. Fahlman cc: common-lisp@SU-AI.ARPA, Rob MacLachlan In-Reply-To: Message-ID: <850611234750.3.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Tue, 11 Jun 1985 21:17 EDT From: "Scott E. Fahlman" If defmacro does, do define-setf-method, defsetf, deftype...? I believe that all defining forms that have a name and a body should put a named block around the body. In our implementation, defun and defmacro do so, but currently the others you mentioned do not. I'm calling that a bug in our implementation and suggesting that a future clarification of Common Lisp should require this. I can accept this, but let's be sure we agree on what the block name would be in each case. For the SETF forms, is it the name of the accessing operator? For DEFTYPE, is it the name of the type? Yes. I propose this rule: In any DEFxxx form that has a body that is code to executed, then if CADR of the form is a symbol, then a BLOCK with that symbol as its name is automatically wrapped around the body in such a place that RETURN-FROM that block is the same as making the body evaluate to the returned value. The complicated language here is to deal with the case where the form expands into a large bunch of code with the user-supplied body buried somewhere inside it.  Received: from SU-AI.ARPA by MIT-MC.ARPA 11 Jun 85 21:51:50 EST Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 11 Jun 85 18:42:42 PDT Received: ID ; Tue 11 Jun 85 21:43:42-EDT Date: Tue, 11 Jun 1985 21:43 EDT Message-ID: Sender: FAHLMAN@CMU-CS-C.ARPA From: "Scott E. Fahlman" To: "David A. Moon" Cc: common-lisp@SU-AI.ARPA Subject: Adjustable and displaced arrays In-reply-to: Msg of 11 Jun 1985 15:44-EDT from David A. Moon OK, if we accept Moon's view of the proper semantics for all this, and if we decide not to outlaw displacing to adjustable arrays, then the Fortran machines probably have to forego cacheing and let each call to Aref potentially grovel the headers of both arrays (or a whole chain of arrays). Maybe that is not so bad, since none of this affects Simple-Vectors, and they are the only kind of array that really HAS to be fast. However, the vendors of non-microcodable machines may feel, with some justification, that they don't want to slow down ALL references to non-simple arrays just so that the obscure case of adjusting an array that is displaced to will work properly. Perhaps the right move is to unbundle the SIMPLE declaration and allow the user to declare that an array is NOT-DISPLACED, even if it is not simple in other respects. -- Scott  Received: from SU-AI.ARPA by MIT-MC.ARPA 11 Jun 85 21:34:32 EST Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 11 Jun 85 18:25:38 PDT Received: ID ; Tue 11 Jun 85 21:26:34-EDT Date: Tue, 11 Jun 1985 21:26 EDT Message-ID: Sender: FAHLMAN@CMU-CS-C.ARPA From: "Scott E. Fahlman" To: "David A. Moon" Cc: common-lisp@SU-AI.ARPA Subject: Degenerate array axes In-reply-to: Msg of 11 Jun 1985 15:57-EDT from David A. Moon OK, maybe the best way out is to follow Mlynarik's suggestion that (a) we allow multi-D arrays with one or more dimensions of 0 and (b) we go with #.make-array for those situations where the #A syntax can't make it. That way we avoid a significant incompatible change to the syntax and we avoid outlawing a heretofore legal object type. -- Scott  Received: from SU-AI.ARPA by MIT-MC.ARPA 11 Jun 85 21:27:57 EST Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 11 Jun 85 18:19:03 PDT Received: ID ; Tue 11 Jun 85 21:20:04-EDT Date: Tue, 11 Jun 1985 21:19 EDT Message-ID: Sender: FAHLMAN@CMU-CS-C.ARPA From: "Scott E. Fahlman" To: "David A. Moon" Cc: common-lisp@SU-AI.ARPA Subject: common lisp- &environment objects In-reply-to: Msg of 11 Jun 1985 16:11-EDT from David A. Moon To sum up: the data structure that Common Lisp offers to users is the lexical closure, not the environment. The only thing a user can do with an environment is receive it as an argument and pass it to another function as an argument. I believe that these environments should be defined to have only dynamic extent; in other words, a user isn't allowed to save them away in permanent structures. Fine, I agree with Moon. Any passionately dissenting opinions? -- Scott  Received: from SU-AI.ARPA by MIT-MC.ARPA 11 Jun 85 21:25:16 EST Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 11 Jun 85 18:16:51 PDT Received: ID ; Tue 11 Jun 85 21:17:43-EDT Date: Tue, 11 Jun 1985 21:17 EDT Message-ID: Sender: FAHLMAN@CMU-CS-C.ARPA From: "Scott E. Fahlman" To: "David A. Moon" Cc: common-lisp@SU-AI.ARPA, Rob MacLachlan Subject: Does Defmacro establish a block? In-reply-to: Msg of 11 Jun 1985 16:14-EDT from David A. Moon If defmacro does, do define-setf-method, defsetf, deftype...? I believe that all defining forms that have a name and a body should put a named block around the body. In our implementation, defun and defmacro do so, but currently the others you mentioned do not. I'm calling that a bug in our implementation and suggesting that a future clarification of Common Lisp should require this. I can accept this, but let's be sure we agree on what the block name would be in each case. For the SETF forms, is it the name of the accessing operator? For DEFTYPE, is it the name of the type? -- Scott  Received: from SU-AI.ARPA by MIT-MC.ARPA 11 Jun 85 16:30:14 EST Received: from THINK.ARPA by SU-AI.ARPA with TCP; 11 Jun 85 13:17:29 PDT Received: by THINK.ARPA with CHAOS id AA27754; Tue, 11 Jun 85 16:12:51 edt Date: Tuesday, 11 June 1985, 16:14-EDT From: Guy Steele Subject: Environment-objects don't exist in CL according to manual To: REM%IMSSS@SU-SCORE.ARPA, COMMON-LISP@SU-AI Cc: gls@THINK.ARPA In-Reply-To: SU-IMSSS.REM.A132222142466.G0353 Message-Id: <850611161408.2.GLS@ROCK.ARPA> Date: 1985 June 10 06:00:54 PST (=GMT-8hr) From: Robert Elton Maas ... The answer, if I can believe the index, is that CL has no such things as environment objects. ... You can't believe the index. The index is lousy. I am looking into automated technology to improve the index for the next edition. --Guy  Received: from SU-AI.ARPA by MIT-MC.ARPA 11 Jun 85 16:27:06 EST Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 11 Jun 85 13:16:01 PDT Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 252265; Tue 11-Jun-85 16:12:17-EDT Date: Tue, 11 Jun 85 16:14 EDT From: David A. Moon Subject: Does Defmacro establish a block? To: Rob MacLachlan cc: common-lisp@SU-AI.ARPA, bug-CLCP@STONY-BROOK.SCRC.Symbolics.COM In-Reply-To: Message-ID: <850611161450.6.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Mon, 27 May 1985 04:30 EDT From: Rob MacLachlan Does defmacro establish a named block around the definition the same way that defun does? CLTL doesn't mention this issue at all, leading one to suppose that it doesn't, but this seems to create a pointless inconsistency with defun. If defmacro does, do define-setf-method, defsetf, deftype...? I believe that all defining forms that have a name and a body should put a named block around the body. In our implementation, defun and defmacro do so, but currently the others you mentioned do not. I'm calling that a bug in our implementation and suggesting that a future clarification of Common Lisp should require this.  Received: from SU-AI.ARPA by MIT-MC.ARPA 11 Jun 85 16:22:22 EST Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 11 Jun 85 13:11:16 PDT Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 252256; Tue 11-Jun-85 16:08:31-EDT Date: Tue, 11 Jun 85 16:11 EDT From: David A. Moon Subject: common lisp- &environment objects To: David C. Plummer in disguise , Scott E. Fahlman cc: common-lisp@SU-AI.ARPA In-Reply-To: <850610145904.7.NFEP@NEPONSET.SCRC.Symbolics.COM> Message-ID: <850611161100.5.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Mon, 10 Jun 85 14:59 EDT From: David C. Plummer in disguise Date: Mon, 10 Jun 1985 09:47 EDT From: "Scott E. Fahlman" So again the question is whether we can accomplish everything we need to with environment objects even%if these objects have only dynamic extent. Whether some parts of the environment need to have indefinite extent in order to make closures work is a different question, I think. OK, I think I understand the question you are asking. My question is: Does it matter? I cannot think of any valid programs (read: macros) that would want to store an environment in permanent storage. For that matter, I cannot think of any valid programs (read: macros) that side effect the environment. They only USE them, which means you pass them as arguments to macroexpand(-1). Therefore, I don't think it matters how they are implemented, since all programs should be using them as lexical scope, dynamic extent, which is the most restrictive. The only "program" that needs to update the environment is the interpreter (read: special forms), and that "program" is supplied by the vendor and users don't need to know about it. I think Scott has hit the nail on the head and I also agree with Dave's comments. To sum up: the data structure that Common Lisp offers to users is the lexical closure, not the environment. The only thing a user can do with an environment is receive it as an argument and pass it to another function as an argument. I believe that these environments should be defined to have only dynamic extent; in other words, a user isn't allowed to save them away in permanent structures.  Received: from SU-AI.ARPA by MIT-MC.ARPA 11 Jun 85 16:10:45 EST Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 11 Jun 85 12:59:00 PDT Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 252237; Tue 11-Jun-85 15:54:53-EDT Date: Tue, 11 Jun 85 15:57 EDT From: David A. Moon Subject: Degenerate array axes To: Jon White , Guy Steele , Scott E. Fahlman , Richard Mlynarik , greek@DEC-HUDSON.ARPA, David C. Plummer in disguise cc: common-lisp@SU-AI.ARPA In-Reply-To: The message of 6 Jun 85 08:43-EDT from Jon White , <850606103442.4.GLS@DESIDERIUS.ARPA>, , <[MIT-MC.ARPA].532788.850606.MLY>, The message of 6 Jun 85 15:30-EDT from greek@DEC-HUDSON, The message of 7 Jun 85 12:33-EDT from greek@DEC-HUDSON, <850609145609.5.NFEP@NEPONSET.SCRC.Symbolics.COM> Message-ID: <850611155723.4.MOON@EUPHRATES.SCRC.Symbolics.COM> I read the seven messages in this discussion about multidimensional arrays where some of the dimensions (other than the last) are zero. My opinion is that the language semantics are correct and consistent, and the problem lies solely in the print syntax. The best suggestion so far, in my opinion, is the one from Mlynarik that when array cannot be meaningfully be printed with #A it should be printed with #.(MAKE-ARRAY ...).  Received: from SU-AI.ARPA by MIT-MC.ARPA 11 Jun 85 15:58:04 EST Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 11 Jun 85 12:45:10 PDT Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 252220; Tue 11-Jun-85 15:42:22-EDT Date: Tue, 11 Jun 85 15:44 EDT From: David A. Moon Subject: Adjustable and displaced arrays To: Rob MacLachlan , greek@DEC-HUDSON.ARPA, Glenn S. Burke cc: common-lisp@SU-AI.ARPA In-Reply-To: , The message of 23 May 85 09:57-EDT from greek@DEC-HUDSON, <850523163729.9.NFEP@NEPONSET.SCRC.Symbolics.COM>, <[MIT-MC].516737.850524.GSB0>, The message of 28 May 85 11:21-EDT from greek@DEC-HUDSON, <850528124820.3.NFEP@NEPONSET.SCRC.Symbolics.COM> Message-ID: <850611154451.3.MOON@EUPHRATES.SCRC.Symbolics.COM> Perhaps I can clarify one or two points in this discussion. Date: Wed, 22 May 1985 23:56 EDT From: Rob MacLachlan I am somewhat confused about the interaction between array adjustment and displacement. In CLTL p298: Note that if the array a is created displaced to array b and subsequently array b is given to adjust-array, array a will still be displaced to array b; the effects of this displacement and the rule of row-major storage order must be taken into account. What is this trying to say? Is this a warning to the user or a threat to the implementor? The obvious interpretation of this statement seems to require that all non-simple arrays contain a list of all the other array headers that share the same data so that they can be fixed up when the array is adjusted. The answer that you stick in a forwarding pointer is not acceptable. I can't tell what you mean by your last two sentences, but if you encache information about array b inside of array a, you must arrange one way or another to discover when that cache is invalid. An alternative to encaching is to examine array b on every access to array a. We use a combination of both techniques; normal array accesses to array a examine array b, but a tight array processing loop can use a declaration to get the array decoding moved outside of the loop. This encached information is automatically updated if any array is adjusted (our hardware can do with this without taking any extra time; the validity check for the encached information consists of comparing two numbers, one of which increments every time an array is adjusted, and is overlapped with memory access time). In a system that doesn't allow multiple processes, you could probably get away without any provision for cache updating if you require the user not to do any array adjustment inside his inner loop. The statement in the manual also doesn't answer the question of what happens to array b if array a is adjusted. Is it legal or meaningful to have arrays which are both displaced to another array and adjustable? What are the semantics of adjusting such an array? The answer is that it is extremely straightforward. Adjusting array a never affects array b in any way. Adjusting a displaced array never moves any data elements around in storage; it simply changes the dimensions, displaced-to, and/or index-offset of the displaced array. It sounds like the manual needs to be improved. Date: Thu, 23 May 85 09:57:23 EDT From: greek@DEC-HUDSON We were so confused about the problem of adjusting displaced arrays, we simply don't allow it in VAX LISP. I'd sure appreciate some thoughts on the matter myself. See above; adjusting displaced arrays is much easier than adjusting ordinary arrays. Date: Tue, 28 May 85 11:21:20 EDT From: greek@DEC-HUDSON Erf! I certainly should have objected to the incredible hair needed to implement adjustable arrays, particularly those which are displaced, back when we specified them. However, I'd like to object now. I'd like to see a list of the uses people make of displaced and adjustable arrays. Maybe there are only two or three real features that people use, and we could restrict ourselves to those. I looked around here at DEC, and found exactly two uses: 1. Make an array bigger. Obviously this could be done with MAKE-ARRAY and REPLACE. This is not obvious at all! Suppose there are multiple references to the original array; how do they get updated to refer to the new copy? That issue is the whole reason why adjustable arrays exist. 2. Linearize a multidimensional array so that row-major references can be done. This is useful, but an AREF-ROW-MAJOR function could probably do it more efficiently. It seems to me that any set of rules that require AREF to iterate to find the data ought to be simplified. So much for inline code. Common Lisp was explicitly not designed for efficient implementation on Fortran machines in the absence of declarations. Does the ability to declare an array to be SIMPLE take care of your problems with implementing inline code for AREF? If not, there is an issue we need to address. Date: Tue, 28 May 85 12:48 EDT From: David C. Plummer in disguise I don't think we don't use it for your case (1); instead we do make a new array, copy, and structure forwared the old to the new. They can also be used for your case (2), but I think the our function SYS:%1D-AREF subsumes the need. Slight clarifications: SYS:%1D-AREF and AREF-ROW-MAJOR are two names for exactly the same thing. "structure forward" is a Lisp machine concept that does not exist in Common Lisp.  Received: from SU-AI.ARPA by MIT-MC.ARPA 11 Jun 85 15:56:53 EST Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 11 Jun 85 12:47:48 PDT Received: ID ; Tue 11 Jun 85 15:46:08-EDT Date: Tue, 11 Jun 1985 15:46 EDT Message-ID: Sender: FAHLMAN@CMU-CS-C.ARPA From: "Scott E. Fahlman" To: Richard Weyhrauch Cc: common-lisp@SU-AI.ARPA Subject: using lower case In-reply-to: Msg of 11 Jun 1985 13:43-EDT from Richard Weyhrauch There is no way in standard Common Lisp to get full case-sensitivity as the reader default. Individual implementations may have a case-sensitive input mode as an extension, but the CMU code upon which many Common Lisp implementations are based does not have this feature. -- Scott  Received: from SU-AI.ARPA by MIT-MC.ARPA 11 Jun 85 13:56:55 EST Date: 11 Jun 85 1043 PDT From: Richard Weyhrauch Subject: using lower case To: common-lisp@SU-AI.ARPA Is there any way to make common lisp simply be totally case sensitive in the naive way? I would somply like symbols to have PNAMES like Hello or hEllo or heLLo ... and all be different symbols which I do not need to type any other characters to use this way? Richard  Received: from SU-AI.ARPA by MIT-MC.ARPA 11 Jun 85 02:06:24 EST Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 10 Jun 85 22:56:10 PDT Received: from MIT-OZ by MIT-MC via Chaosnet; 11 JUN 85 01:00:22 EDT Date: Tue 11 Jun 85 00:57:48-EDT From: Rodney A. Brooks Subject: function type specifiers To: common-lisp@SU-AI.ARPA cc: jk@SU-AI.ARPA In CTtL page 47 it defines a function type specifier to look like: (function (arg1-type arg2-type ...) value-type) and says "The value-type may be a values type specifier in order to indicate the types of multiple values.". On page 158 in talking about delarations it says that for (ftype type function-name-1 function-name-2 ...) type must be a functional type. Then on page 159 it says that (function name arglist result-type1 result-type-2 ...) is entirely equivalent to (ftype (function arglist result-type1 result-type2 ...) name) which establishes a contradiction. Page 159 should be changed. -------  Received: from SU-AI.ARPA by MIT-MC.ARPA 10 Jun 85 15:12:09 EST Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 10 Jun 85 11:59:44 PDT Received: from NEPONSET.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 251236; Mon 10-Jun-85 14:57:03-EDT Date: Mon, 10 Jun 85 14:59 EDT From: David C. Plummer in disguise Subject: common lisp- &environment objects To: Scott E. Fahlman , David C. Plummer in disguise cc: common-lisp@SU-AI.ARPA In-Reply-To: Message-ID: <850610145904.7.NFEP@NEPONSET.SCRC.Symbolics.COM> Date: Mon, 10 Jun 1985 09:47 EDT From: "Scott E. Fahlman" So again the question is whether we can accomplish everything we need to with environment objects even if these objects have only dynamic extent. Whether some parts of the environment need to have indefinite extent in order to make closures work is a different question, I think. OK, I think I understand the question you are asking. My question is: Does it matter? I cannot think of any valid programs (read: macros) that would want to store an environment in permanent storage. For that matter, I cannot think of any valid programs (read: macros) that side effect the environment. They only USE them, which means you pass them as arguments to macroexpand(-1). Therefore, I don't think it matters how they are implemented, since all programs should be using them as lexical scope, dynamic extent, which is the most restrictive. The only "program" that needs to update the environment is the interpreter (read: special forms), and that "program" is supplied by the vendor and users don't need to know about it. Aside: Symbolics' EVAL function takes an &OPTIONAL ENV argument so that the implementation of special forms can call EVAL instead of EVAL-WITH-ENV or somesuch.  Received: from SU-AI.ARPA by MIT-MC.ARPA 10 Jun 85 14:18:31 EST Received: from DEC-HUDSON.ARPA by SU-AI.ARPA with TCP; 10 Jun 85 11:07:54 PDT Date: Mon, 10 Jun 85 13:37:28 EDT From: greek@DEC-HUDSON Subject: Scott's observation on MACROLET To: common-lisp@su-ai MACROLET? What's MACROLET? Must be a mistake. Let's erase it from the book. - Paul  Received: from SU-AI.ARPA by MIT-MC.ARPA 10 Jun 85 13:50:02 EST Received: from RUTGERS.ARPA by SU-AI.ARPA with TCP; 10 Jun 85 10:40:06 PDT Date: 10 Jun 85 13:39:50 EDT From: Charles Hedrick Subject: extent of environments To: common-lisp@SU-AI.ARPA TOPS-20 Common Lisp in fact does precisely what Scott conjectured a hypothetical implementation might do: We put the environment information on the stack. We copy it into the heap whenever we have to give the information to the user. This seems to speed up the interpreter a lot. If somebody can guarantee us that the things we give to a macro with &environment can safely be left on the stack, that would speed up those macro expansions. This is not critical, however, since we only do macro expansions once. (We use the old UCI Lisp displacement technique.) What has actually stopped us from doing &environment is not this problem (which is trivial to fix - after all we already have the function to copy the environment into the heap) but the fact that we have to make the compiler do it also. Thus the compiler is going to have to construct an environment which will look to the macro 7s if it were the runtime enviornment in which the macro was called. The copy of Spice Lisp that we have (which may, as usual, be slightly out of date) simply doesn't deal with these issues. Indeed in SETF they have a separate macro expander that explicitly tests whether it is in the compiler or not. We are going to have to replace that with a new mechanism that does things right. The whole implementation of macros that expand to declarations and &environment seems to be one single knotted mess, which I will solve the first time I get a weekend that I can devote to it. -------  Received: from SU-AI.ARPA by MIT-MC.ARPA 10 Jun 85 10:59:09 EST Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 10 Jun 85 07:48:35 PDT Received: ID ; Mon 10 Jun 85 10:49:50-EDT Date: Mon, 10 Jun 1985 10:49 EDT Message-ID: Sender: FAHLMAN@CMU-CS-C.ARPA From: "Scott E. Fahlman" To: REM%IMSSS@SU-SCORE.ARPA (temporary until nameservers up) Cc: COMMON-LISP@SU-AI.ARPA Subject: Environment-objects don't exist in CL according to manual Assuming that something doesn't exist in Common Lisp just because it doesn't appear in the index of the manual is a pretty risky business. In fact, this business of environment objects would probably be indexed under &environment, but all the &-thingies got left out of the index. In this case, the problem is compounded by a serious typo in the text. The use of &evironment in the arglist of a defmacro is described on page 145 at the very bottom. In my copy of the manual, at least, the actual word "&environment" got left out, but it is supposed to be the label for the last paragraph on this page, after the paragraph describing &whole. Uses of these environment objects are described under macroexpand and macroexpand-1, and also under the hook functions in the Eval chapter. Subsequent discussion has revealed that you also need these environment objects as arguments to the proposed PARSE-BODY, to MACRO-FUNCTION, and also to GET-SETF-METHOD. Arguably also to EVAL, because of the damned macro-> declaration business, but I'm not sure about that. Basically, everyone who might have to expand a macro as part of the expansion of another macro has to receive the environment object so that lexically defined macros are handled properly. I have come around to the conclusion that we really blew it when we let MACROLET into the language, despite that operator's occasional usefulness. If not for that, none of this environment hackery would be necessary, and macro->declaration processing would be straightforward. -- Scott  Received: from SU-AI.ARPA by MIT-MC.ARPA 10 Jun 85 10:13:29 EST Sent: to SU-AI.ARPA by IMSSS.? via ETHERNET with PUPFTP; 1985-Jun-10 06:01:26 PST (=GMT-8hr) Date: 1985 June 10 06:00:54 PST (=GMT-8hr) Message-id: SU-IMSSS.REM.A132222142466.G0353 From: Robert Elton Maas To:COMMON-LISP@SU-AI SUBJECT:Environment-objects don't exist in CL according to manual Sender: REM%IMSSS@SU-SCORE.ARPA (for undeliverable-mail notifications) Reply-to: REM%IMSSS@SU-SCORE.ARPA (temporary until nameservers up) Prodded by all this recent discussion about whether environments have dynamic or indefinite extent, how one might obtain an environment-object so as to pass it as optional argument to EVAL, what kinds of info might be captured in such an object, I looked in the index to the CL manual to see what the manual said about environments. The answer, if I can believe the index, is that CL has no such things as environment objects. There are only two mentions of "environment" in the index: one referring to a general statement that special structures in CL allow the programmer to organize a program, some having to do with flow of control (control structures) and others controlling access to variables (environment structures); the other referring to LISP funcitons to query the system regarding such matters as time-of-day or CPU-ID. Neither has anything to do with the topic that seems to be under discussion recently. Is this recent discussion utter nonsense (referring to some local extension to CL rather than to CL itself), or is the index grossly deficient in this topic? If the latter, can somebody supply me/us with a list of pages where environment objects are discussed in the CL manual? If the former, there seems to be no need to introduce the topic; if environment-objects can't be passed to functions, there's no need to worry about how to create them or what aspects of the environment they might encapsulate if they could be created.  Received: from SU-AI.ARPA by MIT-MC.ARPA 10 Jun 85 09:55:41 EST Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 10 Jun 85 06:46:12 PDT Received: ID ; Mon 10 Jun 85 09:47:18-EDT Date: Mon, 10 Jun 1985 09:47 EDT Message-ID: Sender: FAHLMAN@CMU-CS-C.ARPA From: "Scott E. Fahlman" To: "David C. Plummer in disguise" Cc: common-lisp@SU-AI.ARPA Subject: common lisp- &environment objects In-reply-to: Msg of 10 Jun 1985 06:56-EDT from David C. Plummer in disguise I'm arguing that CLtL says much too little about environments. It does not say how to get your hands on one, but specifies them as optional arguments to functions, for example EVALHOOK, APPLYHOOK, MACROEXPAND(-1) (and in our implementation EVAL). Dynamic extent isn't good enough; how can you do upward funargs? This is far from cute: (defun adder (val) #'(lambda (x) (+ x val))) it is instead at the heart of lexical scoping. Ah, OK, we've got some misunderstanding here between the general concept of an environment and the specific concept of an environment object, as returned by &environment. I agree that lexical closures have to work, and that this requires that some parts of the environment in which a function is closed be saved with indefinite extent. However, this doesn't say that environment objects must have indefinite extent. It doesn't even say that the lexical variable part of the environment has to be saved or has to be an object with indefinite extent. In our current (inefficient) Spice Lisp interpreter, this environment is a consed A-list, but one could certainly imagine an implementation that stack allocated this structure (with provision for saving it if a closure is created) or some sort of shallow-bound variable environment that never has a specific object that represents the current variable environment, but that somehow arranges to save all the right value cells when a closure is created. So I agree that closures have to work, but not that this implies anything about the extent of environment objects. In speaking of the expense of diddling variable values, I am referring to those values that are not part of any lexical closure, but that might somehow still be accessible if we were to take seriously the notion that environment objects can be kept alive indefinitely and passed around. I don't think we want to allow this. We do, of course, have to make sure that properly created lexical closures work properly, but we should not specify the internal mechanism that makes that possible. Parts of the lexical function name environment must similarly be of indefinite extent if FLET and LABELS are to work properly, but again we do not need to keep the entire environment around in order to accomplish this. Clearly go-tags and block-names want to become inoperative outside of the dynamic extent of their blocks, whatever we decide about the extent of environment objects. So again the question is whether we can accomplish everything we need to with environment objects even if these objects have only dynamic extent. Whether some parts of the environment need to have indefinite extent in order to make closures work is a different question, I think. -- Scott  Received: from SU-AI.ARPA by MIT-MC.ARPA 10 Jun 85 07:09:56 EST Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 10 Jun 85 03:57:02 PDT Received: from NEPONSET.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 250864; Mon 10-Jun-85 06:54:31-EDT Date: Mon, 10 Jun 85 06:56 EDT From: David C. Plummer in disguise Subject: common lisp- &environment objects To: Scott E. Fahlman , David C. Plummer in disguise cc: common-lisp@SU-AI.ARPA In-Reply-To: Message-ID: <850610065628.8.NFEP@NEPONSET.SCRC.Symbolics.COM> Date: Sun, 9 Jun 1985 23:17 EDT From: "Scott E. Fahlman" One false move here and we have not Lisp but Conniver. How about requiring "dynamic" extent for environment objects, and no more? Will that take care of the needs for macro-expansion, steppers, and so on? True, you could imagine cute ways of using environments that outlive their invocations, but I REALLY don't want to pay for those cute uses with inefficiency or severe constraints on the implementor. If anyone wants to implement Conniver in Common Lisp, I can supply the old Maclisp code, but let's not drag down Common Lisp itself. Moon very carefully solved this problem in Symbolics' implementation of Common Lisp by having an &ENVIRONMENT keyword to defmacro and making sure all possible expanders of macros took an optional environment argument, to which they can pass to MACROEXPAND(-1). This isn't cute; it is functional. It isn't inefficient and it doesn't pose any constraints on the implementor, unless I misunderstand what "the implementor" is suposed to mean. I don't understand what you are saying here. What does this have to do with the extent of environment objects? What, exactly, are you arguing for? I'm arguing that CLtL says much too little about environments. It does not say how to get your hands on one, but specifies them as optional arguments to functions, for example EVALHOOK, APPLYHOOK, MACROEXPAND(-1) (and in our implementation EVAL). Dynamic extent isn't good enough; how can you do upward funargs? This is far from cute: (defun adder (val) #'(lambda (x) (+ x val))) it is instead at the heart of lexical scoping. As I said in an immediate follow-up to the above message, you only get a lot of additional expense if you actually let users do all of the "obvious" things with an immortal environment object, such as going to the tags Tags have dynamic extent. Going with tags outside their dynamic extent should generate errors. and diddling the lexical variables. What good is lexical scoping if you can't diddle lexical variables? I really don't care if environment objects have indefinite or dynamic extent, as long as these expensive kinds of uses are clearly forbidden once you exit the dynamic extent, but the politics of this group are such that we must be very careful about introducing features that, if taken to their logical conclusion, lead us to somewhere we don't want to go; there are always a lot of people who demand that everything be taken to its logical conclusion, and damn the expense, so it is sometimes better not to take the first step. CLtL'84, on page 39 pretty clearly gives the scope and extent of just about everything. Maybe you are concerned that I want the users to diddle with the environment itself? Not at all. The structure of the environment is peculiar to the implementation. I am, perhaps incorrectly, assuming that creating a lexical closure captures the current environment. I do note that the original query suggested that Symbolics was stack-allocating environment objects, and other implementations might want to do similarly tense things in order to make the interpreter reasonably cons-free. That suggests to me that it would be a good idea to allow environment objects to have dynamic extent only, unless someone can explain why this is unworkable or can demonstrate some important thing that cannot be done if we take this position. I am always nervous about disappearing objects, such as the disappearing &rest args in Zetalisp (not legal in Common Lisp), but in the case of environment arguments we might choose to go with a dangerous but efficient solution. I'll repeat the classic lexical scoping example: (defun adder (val) #'(lambda (x) (+ x val))) Environments must have indefinite extent (at least the environment of non-special variables and local functions (FLET, LABELS)). The way this works is that the environment has a slot which is called ENV-EVACUATION which is the heap version created as necessary. Therefore, internal interpreter functions (e.g., the definition of the FUNCTION special form) explicitly evacuate the environment since it is being stored in permanent storage.  Received: from SU-AI.ARPA by MIT-MC.ARPA 9 Jun 85 23:24:40 EST Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 9 Jun 85 20:16:07 PDT Received: ID ; Sun 9 Jun 85 23:17:03-EDT Date: Sun, 9 Jun 1985 23:17 EDT Message-ID: Sender: FAHLMAN@CMU-CS-C.ARPA From: "Scott E. Fahlman" To: "David C. Plummer in disguise" Cc: common-lisp@SU-AI.ARPA Subject: common lisp- &environment objects In-reply-to: Msg of 9 Jun 1985 15:01-EDT from David C. Plummer in disguise One false move here and we have not Lisp but Conniver. How about requiring "dynamic" extent for environment objects, and no more? Will that take care of the needs for macro-expansion, steppers, and so on? True, you could imagine cute ways of using environments that outlive their invocations, but I REALLY don't want to pay for those cute uses with inefficiency or severe constraints on the implementor. If anyone wants to implement Conniver in Common Lisp, I can supply the old Maclisp code, but let's not drag down Common Lisp itself. Moon very carefully solved this problem in Symbolics' implementation of Common Lisp by having an &ENVIRONMENT keyword to defmacro and making sure all possible expanders of macros took an optional environment argument, to which they can pass to MACROEXPAND(-1). This isn't cute; it is functional. It isn't inefficient and it doesn't pose any constraints on the implementor, unless I misunderstand what "the implementor" is suposed to mean. I don't understand what you are saying here. What does this have to do with the extent of environment objects? What, exactly, are you arguing for? As I said in an immediate follow-up to the above message, you only get a lot of additional expense if you actually let users do all of the "obvious" things with an immortal environment object, such as going to the tags and diddling the lexical variables. I really don't care if environment objects have indefinite or dynamic extent, as long as these expensive kinds of uses are clearly forbidden once you exit the dynamic extent, but the politics of this group are such that we must be very careful about introducing features that, if taken to their logical conclusion, lead us to somewhere we don't want to go; there are always a lot of people who demand that everything be taken to its logical conclusion, and damn the expense, so it is sometimes better not to take the first step. I do note that the original query suggested that Symbolics was stack-allocating environment objects, and other implementations might want to do similarly tense things in order to make the interpreter reasonably cons-free. That suggests to me that it would be a good idea to allow environment objects to have dynamic extent only, unless someone can explain why this is unworkable or can demonstrate some important thing that cannot be done if we take this position. I am always nervous about disappearing objects, such as the disappearing &rest args in Zetalisp (not legal in Common Lisp), but in the case of environment arguments we might choose to go with a dangerous but efficient solution. -- Scott  Received: from SU-AI.ARPA by MIT-MC.ARPA 9 Jun 85 21:04:07 EST Received: from CCA-UNIX.ARPA by SU-AI.ARPA with TCP; 9 Jun 85 17:56:22 PDT Received: by cca-unix.ARPA (4.12/4.7) id AA29292; Sun, 9 Jun 85 20:55:25 edt Date: Sun, 9 Jun 85 20:55:25 edt From: ima!inmet!norman@cca-unix Message-Id: <8506100055.AA29292@cca-unix.ARPA> Sender: inmet!norman@cca-unix To: Common-lisp@SU-AI.ARPA Would you add my name to the common lisp distributaion list. My mailing address is ima!imnet!norman@cca-unix.arpa Thanks Norman rubin Intermetrics  Received: from SU-AI.ARPA by MIT-MC.ARPA 9 Jun 85 20:17:21 EST Received: from SCRC-YUKON.ARPA by SU-AI.ARPA with TCP; 9 Jun 85 17:07:10 PDT Received: from NEPONSET.SCRC.Symbolics.COM by SCRC-YUKON.ARPA via CHAOS with CHAOS-MAIL id 130300; Sun 9-Jun-85 13:48:51-EDT Date: Sun, 9 Jun 85 15:01 EDT From: David C. Plummer in disguise Subject: common lisp- &environment objects To: Scott E. Fahlman , Guy Steele cc: common-lisp@SU-AI.ARPA In-Reply-To: Message-ID: <850609150107.6.NFEP@NEPONSET.SCRC.Symbolics.COM> Date: Wed, 5 Jun 1985 22:06 EDT From: "Scott E. Fahlman" The book is silent in the question of the extent of environments as delivered to &environment bindings in DEFMACRO, hook functions, etc. What shall we say? One false move here and we have not Lisp but Conniver. How about requiring "dynamic" extent for environment objects, and no more? Will that take care of the needs for macro-expansion, steppers, and so on? True, you could imagine cute ways of using environments that outlive their invocations, but I REALLY don't want to pay for those cute uses with inefficiency or severe constraints on the implementor. If anyone wants to implement Conniver in Common Lisp, I can supply the old Maclisp code, but let's not drag down Common Lisp itself. Moon very carefully solved this problem in Symbolics' implementation of Common Lisp by having an &ENVIRONMENT keyword to defmacro and making sure all possible expanders of macros took an optional environment argument, to which they can pass to MACROEXPAND(-1). This isn't cute; it is functional. It isn't inefficient and it doesn't pose any constraints on the implementor, unless I misunderstand what "the implementor" is suposed to mean.  Received: from SU-AI.ARPA by MIT-MC.ARPA 9 Jun 85 20:16:58 EST Received: from SCRC-YUKON.ARPA by SU-AI.ARPA with TCP; 9 Jun 85 17:06:51 PDT Received: from NEPONSET.SCRC.Symbolics.COM by SCRC-YUKON.ARPA via CHAOS with CHAOS-MAIL id 130299; Sun 9-Jun-85 13:43:55-EDT Date: Sun, 9 Jun 85 14:56 EDT From: David C. Plummer in disguise Subject: Arrays with zero dimensions. To: greek@DEC-HUDSON.ARPA, common-lisp@SU-AI.ARPA In-Reply-To: The message of 6 Jun 85 15:30-EDT from greek@DEC-HUDSON Message-ID: <850609145609.5.NFEP@NEPONSET.SCRC.Symbolics.COM> Date: Thu, 06 Jun 85 15:30:40 EDT From: greek@DEC-HUDSON Is it really of cosmic importance that we allow dimensions of zero? We sure could invent a lot of baggage to handle it correctly, but... We already have it: (array-dimensions "") => (0) The problems presented so far only come up when the number of dimensions is 2 or more. My answer to that is that such arrays have legitimate structure and are therefore meaningful. Zero-dimensional arrays likewise have legitimate structure, which is why I assume they were included in the language.  Received: from SU-AI.ARPA by MIT-MC.ARPA 7 Jun 85 12:44:46 EST Received: from DEC-HUDSON.ARPA by SU-AI.ARPA with TCP; 7 Jun 85 09:33:24 PDT Date: Fri, 07 Jun 85 12:33:33 EDT From: greek@DEC-HUDSON Subject: Arrays with Zero Dimensions To: common-lisp@su-ai Yes, I should have made myself clearer. Of course, zero-length vectors are great. But once you go to multiple dimensions, the problem of telling which is zero is messy. - Paul  Received: from SU-AI.ARPA by MIT-MC.ARPA 7 Jun 85 09:58:51 EST Received: from THINK.ARPA by SU-AI.ARPA with TCP; 7 Jun 85 06:50:52 PDT Received: by THINK.ARPA with CHAOS id AA05194; Fri, 7 Jun 85 09:47:08 edt Date: Friday, 7 June 1985, 09:48-EDT From: Guy Steele Subject: Arrays with zero dimensions. To: greek@DEC-HUDSON@THINK.ARPA, common-lisp@su-ai Cc: gls@THINK.ARPA In-Reply-To: The message of 6 Jun 85 15:30-EDT from greek at DEC-HUDSON at think Message-Id: <850607094803.1.GLS@DESIDERIUS.ARPA> Date: Thu, 06 Jun 85 15:30:40 EDT From: greek@DEC-HUDSON@think Is it really of cosmic importance that we allow dimensions of zero? We sure could invent a lot of baggage to handle it correctly, but... - Paul Well, empty strings have their uses. And in image processing I can easily imagine wanting to extract a sub-rectangle of a rectangular pixel array; in certain boundary cases one dimensions might be zero. --Guy  Received: from SU-AI.ARPA by MIT-MC.ARPA 7 Jun 85 01:26:41 EST Received: from UCB-VAX.ARPA by SU-AI.ARPA with TCP; 6 Jun 85 22:12:00 PDT Received: from ucbdali.ARPA by UCB-VAX.ARPA (4.24/4.46) id AA23236; Thu, 6 Jun 85 17:59:55 pdt Received: by ucbdali.ARPA (4.24/4.46) id AA19201; Thu, 6 Jun 85 18:02:59 pdt Date: Thu, 6 Jun 85 18:02:59 pdt From: wilensky%ucbdali@Berkeley (Robert Wilensky) Message-Id: <8506070102.AA19201@ucbdali.ARPA> To: common-lisp@su-ai.ARPA Subject: Common LISP terminology There appears to be considerable terminological confusion in Commmon LISP. Here are two examples: (1) The use of the terms ``binding'', ``bound'' and ``unbound''. On p. 55 we are told variable can be ``assigned to, as by `setq' or bound, as by `let'. '' However, a binding is defined as a particular parameter instance (p. 36). Moreover, a special variable (and only a special variable) can be ``unbound''. It is also rather hard to avoid saying that a special variable is ``bound'' when it has a value, as ``boundp'' will return true in this case. Unfortunately, these meanings are in conflict. For example, they allow for the case in which a variable is ``bound'' but has no ``binding'' (namely, when the reference is to the global value); the variable can be ``unbound'', but have a binding (as you point out, when it is ``bound'', but valueless.) If you simply refuse to say that a variable without any bindings is bound (even though ``boundp'' of it is true), you are then committed to saying that it is not `bound'', not ``unbound'', and has no ``binding'' (although, of course, it has a perfectly fine and accessible value). In addition, a ``bound variable'' appears to mean a variable that currently has a binding (as in, ``a variable bound by `let' ''), although, of course, such a bound variable may very well be ``unbound''. In addition, there appears to be confusion as to whether a variable or a binding is something that is referenced, etc. For example, p. 37 talks about the scope and extent of special bindings, whereas p. 38 talks about the scope and extent of special variables. it is unclear what a reference to a variable that happens to be a parameter might be, other than a reference to its current binding, since this is an fact the particular instance of that paramater that is in force. For example, p. 55 talks about ``the reference ... to the variable specified by the binding''. It is not clear how a particular instance of a parameter can specify a variable. Nor would this seem desirable. If two different invocations of the same function are considered to have the same variables but with different bindings, then one would not want to reference any variable, but rather, the current bindings of those variables. I could go on, but I think you get the point. Here are some suggestions: (1) Drop the notion of binding altogether. I think this is really an old implementation artifact. Instead, say that every APPLICATION of a lambda form creates new variables for its formal parameters. Also, every symbol has a global variable associated with it. A variable may have a value, or it may be valueless. A variable has an extent and a scope. Introduce the function ``assignedp'', which meets the current description of ``boundp''. ``setq'' changes the value of a variable through ``assignment''. Lambda application creates a new variable and assigns it a value. (2) Preserve the notion of a binding as the association of a variable and a value. We still say that every APPLICATION of a lambda form creates new variables for its formal parameters. But we can now consistently say that a variable is bound, meaning that it has a binding, meaning that it is currently associated with a value. Leave ``boundp'' as is. Parameter variables, special variables and global variables can all be ``bound'' to values. (3) Introduce some more terminology. First, state that all variables have ``bindings'', i. e., instances of variables. This includes a global binding for the global variable named by each symbol. Different applications of a lambda refer to different bindings of the same variable (if you must). All variables are always ``bound'', unless perhaps you introduce some new construct that really and abnormally removes bindings. In addition, bindings, and only bindings, which are the only repositories for values, can be ``assigned'' values. ``assignedp'' does what ``boundp'' now does. Note that if you define ``binding'' as a variable instance, i. e., an object, rather than as an association of a variable (or variable instance) with a symbol (or with a value!), then we are in need of terms to describe (1) the relation of a symbol to a variable, (2) the relation of a variable to its binding(s), and (3) relation of a binding to a value. The first seems to be the ``naming'' or ``named by'' relation; the second may be called ``instantiation'', or some such, and the third could be called ``assignment.'' Personally, I prefer (1). It is simplest and least confusing. The terminology of shadowing can still apply to give a lucid description of the rules of reference. Also, it seems to be most compatible with the notion of generalized variables. (2) Special Form Terminology A special form is defined as a form beginning with one of the symbols appearing in Table 5-1. However, p. 57 states that ``The set of special forms is fixed in Common LISP'' and that ``The set of special forms in Common LISP is purposely kept very small''. Of course, these claims are both false. There are an infinite number of special forms in Common LISP. What is finite and small is the set of symbols that designate special forms. These are referred to in Table 5-1 as the ``names'' of special forms. Ugh. I propose the following terminology: Leave the definition of special forms alone. Call the objects referred to by the symbols that designate special forms ``special functions''. Call the objects referred to by symbols that invoke macrq definitions ``macro functions''. Call everything else a ``normal'' function. These are the unmarked case, analogous to the lack of a compelling name for non-``special'' variables. This terminology appears to be consistent with ``symbol-function'', which may return something ``representing a special form (sic) or macro.''  Received: from SU-AI.ARPA by MIT-MC.ARPA 6 Jun 85 15:54:50 EST Received: from DEC-HUDSON.ARPA by SU-AI.ARPA with TCP; 6 Jun 85 12:30:31 PDT Date: Thu, 06 Jun 85 15:30:40 EDT From: greek@DEC-HUDSON Subject: Arrays with zero dimensions. To: common-lisp@su-ai Is it really of cosmic importance that we allow dimensions of zero? We sure could invent a lot of baggage to handle it correctly, but... - Paul  Received: from SU-AI.ARPA by MIT-MC.ARPA 6 Jun 85 13:32:24 EST Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 6 Jun 85 10:20:17 PDT Date: Thu, 6 Jun 85 11:46:27 EST From: Richard Mlynarik Subject: Degenerate array axes -- really array printing. To: common-lisp@SU-AI.ARPA Message-ID: <[MIT-MC.ARPA].532788.850606.MLY> Date: Thu, 6 Jun 85 10:34 EDT From: Guy Steele [...] Under option (3), how about #A ? This would provide a notation for empty arrays, as well as a concise notation for arrays with all elements the same (EQL). For empty arrays the initial element doesn't especially matter, so use (). So one would have (make-array '(0 5)) => #A(0 5)() (make-array '(0 10)) => #A(0 10)() Of course, this is a non-trivial extension to the language. It is also rather ugly, in that there seem to be no other predefined reader macros which read TWO sexps as this does, and as such this may be a little confusing. I suppose the other way to do this is to print `#.(make-array '(0 5) :initial-element 'foo)' Speaking of which, it has always struck me as sort of a shame that there is no convenient representation for arrays other than simple bit-vectors, simple strings, and multidimensional arrays of element-type `t'. It would have been nice if there had been some facility for providing `make-array' options by way of the `#a' macro construct (excluding `:displaced-to' and `:displaced-index-offset') but as it is one must print `#.(make-array ...)' in order to read in an `isomorphicp' array. Any takers for `#a((2 5) :element-type (mod 4) :fill-pointer 2 :initial-element 3)'?!!  Received: from SU-AI.ARPA by MIT-MC.ARPA 6 Jun 85 13:14:45 EST Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 6 Jun 85 08:09:39 PDT Received: ID ; Thu 6 Jun 85 11:11:28-EDT Date: Thu, 6 Jun 1985 11:11 EDT Message-ID: Sender: FAHLMAN@CMU-CS-C.ARPA From: "Scott E. Fahlman" To: Guy Steele Cc: common-lisp@SU-AI.ARPA Subject: Degenerate array axes In-reply-to: Msg of 6 Jun 1985 10:34-EDT from Guy Steele Guy's suggested syntax extension seems to be the best way to go, IF we really want to handle this problem properly. I'm not sure that this degenerate case is worth the hassle of a major syntax extension, however. The only reason we allowed a dimension to be 0 (in a vector) was for APL compatibility -- the argument was that we may as well make the boundary conditions such that someone could implement APL easily in Common Lisp. So I guess the question is whether keeping a (0 5) array distinct from a (0 10) array during reading and printing is really necessary for APL compatibility and, if so, whether we continue to care about APL compatibility. Maybe the right move is to require ALL dimensions to be > 0 and not >= 0. -- Scott  Received: from SU-AI.ARPA by MIT-MC.ARPA 6 Jun 85 10:52:13 EST Received: from THINK.ARPA by SU-AI.ARPA with TCP; 6 Jun 85 07:39:56 PDT Received: by THINK.ARPA with CHAOS id AA23798; Thu, 6 Jun 85 10:34:00 edt Date: Thu, 6 Jun 85 10:34 EDT From: Guy Steele Subject: Degenerate array axes To: common-lisp@SU-AI.ARPA Cc: gls@THINK.ARPA In-Reply-To: Your message of 6 Jun 85 08:43-EDT Message-Id: <850606103442.4.GLS@DESIDERIUS.ARPA> Date: 06 Jun 85 0543 PDT From: Jon White What does one mean by (make-array '(0 5)) ? How should it print? (assuming that *print-array* is non-null) The description of array printing on page 369 presumes that the array is either single-dimensional, or else it has some (i.e., not 0) elements. Notice how the looping part of the algorithm resets an index to 0 (not -1) in order to try to access the "element" at index . Eeee-yuk! This boner is completely my fault, and I feel very bad about it, inasmuch as I put a lot of study into how APL hackers solved this problem. (Essentially what they do is to exhibit a NON-empty array showing typical components, and then say "the array I'm talking about is just like this one except that thus-and-so axes are zero". I'm not crazy about this solution, since we don't have the same problem of prototypes [their technical term for what you get when you take the "CAR" of an empty array] that APL does.) I've looked a several CL implementations, and all fail to print such objects in a readable manner. Furthermore, they all print the above array exactly the same as they do (make-array '(0 10)), even though the two arrays are not equalp [with *print-array* set to non-null]. It seems clear to me that the algorithm of page 369 does not provide for a way to distinguish these two arrays, since the #nA syntax deduces the contents of th dimensions list from the :initial-contents -- but for arrays of array-total-size equal to zero, they all have the same "initial contents" even though their dimensions lists may assume infinitely may values. Three possible solutions come to mind: 1) simply rule out degenerate axes as being somehow wrong -- the only zero-element arrays must then be vectors 2) coerce all such beasts into one with all dimensions zero -- e.g., treat the '(0 5) and '(0 10) as if they were '(0 0); then a NIL for the :initial-contents would be acceptable. 3) extend the print syntax of #nA so that it can specify the dimension list exactly, and independently of the :initial-contents field. Anyone have any ideas on this one? -- JonL -- Under option (3), how about #A ? This would provide a notation for empty arrays, as well as a concise notation for arrays with all elements the same (EQL). For empty arrays the initial element doesn't especially matter, so use (). So one would have (make-array '(0 5)) => #A(0 5)() (make-array '(0 10)) => #A(0 10)() Of course, this is a non-trivial extension to the language. --Guy  Received: from SU-AI.ARPA by MIT-MC.ARPA 6 Jun 85 08:53:04 EST Date: 06 Jun 85 0543 PDT From: Jon White Subject: Degenerate array axes To: common-lisp@SU-AI.ARPA What does one mean by (make-array '(0 5)) ? How should it print? (assuming that *print-array* is non-null) The description of array printing on page 369 presumes that the array is either single-dimensional, or else it has some (i.e., not 0) elements. Notice how the looping part of the algorithm resets an index to 0 (not -1) in order to try to access the "element" at index . I've looked a several CL implementations, and all fail to print such objects in a readable manner. Furthermore, they all print the above array exactly the same as they do (make-array '(0 10)), even though the two arrays are not equalp [with *print-array* set to non-null]. It seems clear to me that the algorithm of page 369 does not provide for a way to distinguish these two arrays, since the #nA syntax deduces the contents of th dimensions list from the :initial-contents -- but for arrays of array-total-size equal to zero, they all have the same "initial contents" even though their dimensions lists may assume infinitely may values. Three possible solutions come to mind: 1) simply rule out degenerate axes as being somehow wrong -- the only zero-element arrays must then be vectors 2) coerce all such beasts into one with all dimensions zero -- e.g., treat the '(0 5) and '(0 10) as if they were '(0 0); then a NIL for the :initial-contents would be acceptable. 3) extend the print syntax of #nA so that it can specify the dimension list exactly, and independently of the :initial-contents field. Anyone have any ideas on this one? -- JonL --  Received: from SU-AI.ARPA by MIT-MC.ARPA 5 Jun 85 22:30:57 EST Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 5 Jun 85 19:21:38 PDT Received: ID ; Wed 5 Jun 85 22:23:29-EDT Date: Wed, 5 Jun 1985 22:23 EDT Message-ID: Sender: FAHLMAN@CMU-CS-C.ARPA From: "Scott E. Fahlman" To: Guy Steele Cc: common-lisp@SU-AI.ARPA Subject: common lisp- &environment objects Actually, that was a slight overstatement. You only get CONNIVER if you actually allow the user to make use of the environment in certain ways, such as GO-ing to the tags it contains. There's not much harm in making the environment object itself non-ephemeral, I suppose, as long as people don't get the idea that you can do very much with these objects once you exit the dynamic extent. Still, I would opt for dynamic extent unless someone comes up with a very clear need to go with something more difficult. -- Scott  Received: from SU-AI.ARPA by MIT-MC.ARPA 5 Jun 85 22:14:07 EST Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 5 Jun 85 19:04:33 PDT Received: ID ; Wed 5 Jun 85 22:06:18-EDT Date: Wed, 5 Jun 1985 22:06 EDT Message-ID: Sender: FAHLMAN@CMU-CS-C.ARPA From: "Scott E. Fahlman" To: Guy Steele Cc: common-lisp@SU-AI.ARPA Subject: common lisp- &environment objects In-reply-to: Msg of 5 Jun 1985 16:25-EDT from Guy Steele The book is silent in the question of the extent of environments as delivered to &environment bindings in DEFMACRO, hook functions, etc. What shall we say? One false move here and we have not Lisp but Conniver. How about requiring "dynamic" extent for environment objects, and no more? Will that take care of the needs for macro-expansion, steppers, and so on? True, you could imagine cute ways of using environments that outlive their invocations, but I REALLY don't want to pay for those cute uses with inefficiency or severe constraints on the implementor. If anyone wants to implement Conniver in Common Lisp, I can supply the old Maclisp code, but let's not drag down Common Lisp itself. -- Scott  Received: from SU-AI.ARPA by MIT-MC.ARPA 5 Jun 85 16:40:04 EST Received: from THINK.ARPA by SU-AI.ARPA with TCP; 5 Jun 85 13:28:18 PDT Received: by THINK.ARPA with CHAOS id AA08313; Wed, 5 Jun 85 16:24:54 edt Date: Wednesday, 5 June 1985, 16:25-EDT From: Guy Steele Subject: common lisp- &environment objects To: common-lisp%sail@THINK.ARPA In-Reply-To: <850605151454.3.BRADLEY@ROCK.ARPA> Message-Id: <850605162546.1.GLS@DESIDERIUS.ARPA> Received: from GODOT by AQUINAS via CHAOS with CHAOS-MAIL; Wed 5-Jun-85 15:18:54-EDT Received: by THINK.ARPA with CHAOS id AA07682; Wed, 5 Jun 85 15:13:58 edt Date: Wednesday, 5 June 1985, 15:14-EDT From: Bradley C. Kuszmaul Subject: common lisp- &environment objects To: gls@AQUINAS, bradley@AQUINAS Message-Id: <850605151454.3.BRADLEY@ROCK.ARPA> I would like to be able to save &environment objects away somewhere, but the book is silent about whether I can do that. Symbolics does not let me save them because they are on the stack. -Brad The book is silent in the question of the extent of environments as delivered to &environment bindings in DEFMACRO, hook functions, etc. What shall we say? --Guy  Received: from SU-AI.ARPA by MIT-MC.ARPA 3 Jun 85 22:35:25 EST Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 3 Jun 85 19:25:34 PDT Date: Mon, 3 Jun 85 22:21:23 EST From: Glenn S. Burke Subject: Get-Setf-Method To: common-lisp@SU-AI.ARPA Message-ID: <[MIT-MC.ARPA].529174.850603.GSB> Date: Sun, 2 Jun 1985 15:20 EDT From: "Scott E. Fahlman" Steve Handerson has pointed out that MACRO-FUNCTION also needs an optional evironment argument, since without this we have no way of getting hold of the expansion function for a lexically defined macro (though we can execute this function). This may or may not be important for normal code, but it is definitely important for writing environment tools such as a single-stepper. -- Scott Yes. I don't remember why, but apparently it was important to something in NIL. I don't think it was just the stepper. From the looks of the sources we put this in last october or earlier.  Received: from SU-AI.ARPA by MIT-MC.ARPA 3 Jun 85 12:56:11 EST Received: from DEC-HUDSON.ARPA by SU-AI.ARPA with TCP; 3 Jun 85 09:45:12 PDT Date: Mon, 03 Jun 85 12:45:17 EDT From: vanroggen@DEC-HUDSON Subject: read macros To: common-lisp@su-ai Cc: vanroggen I agree invertibility of backquote is desired. But users can define their own read macros. Why don't we supply a mechanism to allow users to define inverses of read macros, and have system supplied ones also use this mechanism, and have the pretty-printer print the inverse? Which reminds me--there hasn't been any discussion of Waters's modification of FORMAT and streams to do pretty printing on this mailing list. It seems there was some accord back in September that his proposal was reasonable. This would be a good example of a non-portable, compatible extension to Common Lisp; we should try to agree on this now so that its future inclusion will be easy. ---Walter  Received: from SU-AI.ARPA by MIT-MC.ARPA 3 Jun 85 10:18:20 EST Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 3 Jun 85 07:10:24 PDT Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 247754; Mon 3-Jun-85 10:09:12-EDT Date: Mon, 3 Jun 85 10:09 EDT From: Kent M Pitman Subject: Programs writing backquotes To: greek@DEC-HUDSON cc: Common-Lisp@SAIL Message-ID: <850603100932.0.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> Don't be silly. Programs that write programs to run maybe can generate `real' code, but programs that write programs to read better use a readable convention. It is not just writing convenience that leads one to write with backquote. Further, the issue of program-manipulation of backquote is not only one of generation, but of intelligibility of code written by users. It should be possible to have called vanilla READ and to get backquoted structure and to be able to identify it as such. The grinder is an obvious example of a program which needs uo be able to recognize such things, but it would be easy to conjure others.  Received: from SU-AI.ARPA by MIT-MC.ARPA 3 Jun 85 09:31:26 EST Received: from DEC-HUDSON.ARPA by SU-AI.ARPA with TCP; 3 Jun 85 06:24:15 PDT Date: Mon, 03 Jun 85 09:24:25 EDT From: greek@DEC-HUDSON Subject: Programs writing backquotes To: common-lisp@su-ai I agree with Scott. Backquote et al are shorthands for people. Programs can (really almost) just as easily generate the real code. - Paul  Received: from SU-AI.ARPA by MIT-MC.ARPA 3 Jun 85 08:27:55 EST Date: 03 Jun 85 0520 PDT From: Jon White Subject: Explicit definition of backquote To: Fahlman@CMU-CS-C.ARPA CC: Perdue%hplabs@CSNET-RELAY.ARPA, common-lisp@SU-AI.ARPA In-reply-to: your message of 2-Jun-85 11:02 EDT MacLisp may have been the first implementation to use macro wrappers for the target of the various "backquote" readmacros; it was motivated by the desire to use the programable "prettyprinter", which had a very simple readmacroinverse facility. The goal was to have read/print do for backquote what it was doing for singlequote. Later, the Lispm (which had backquote first) switched from a direct expansion into basic primitives (like, QUOTE, CONS, APPEND etc) to the use of internal, semi-unpronouncable names which were copies of these primitives, primarily to retain a modicum of the structure of the original text (I don't think it succeeds in all cases, as does the pdp10 MacLisp and NIL code. By the way, MacLisp's wrapper names are also quite unpronounceable -- but then, MacLisp has no package system.) In defense of using eval-time macros, rather than going directly to "efficient" primitive code, one may notice that CL requires a macro expansion hook (CLtL, page 152), with which one may smoothly implement the equivalent of the MacLisp MACROMEMO macro cacheing scheme [this is somewhat equivalent to Interlisp's cacheing of expansions in the hashtable CLISPARRAY]. With a very modest amount of time spent on tuning the evaluator, there should be no hesitation to use macros freely in CL; in fact, with a compile-time-only "optimizer", it's quite feasible to retain full input syntax, while compiling something quite different, something which has been "optimized" to the hilt. Even a vanilla implementation, wrappers or not, for the next manual would be of immense help, and could fullfill your suggestion: If we really want to do this, it should be sufficient to define S-expression forms that the various backquote character macros COULD expand into, and that programs can generate to get the same effect. We don't have to require implementors to actually use these in processing backquoted expressions. Frankly, I think such a suggestive coding, in Lisp, would be more easily understandable than the formal specification of CLtL pages 349-351. This may have more value than one would think at first. A few years back, someone in the Interlisp community decided to re-invent the backquote facility in a more "Interlispy" fashion, and spent three years getting it wrong. The test case was some doubly-nested (not triply-nested!!) code taken from Bob Kern's original implementation of DEFSETF for MacLisp/NIL. About every six months, this individual would proffer yet another version of the newly-invented substitute for backquote, and I would have to grovel over the output on the test case to see why it was wrong. Sometimes the code produced was grossly erroneous (unbound gensyms as free variables!) but most often it would CONS when it should have LIST'd, or CAR when it should have CDR'd; and the only way to check it was to compare it with the normalized form produced by pdp10 MacLisp. We need the CL equivalent of that MacLisp version -- a standard by which other, alleged backquote implementations may be measured. -- JonL --  Received: from SU-AI.ARPA by MIT-MC.ARPA 2 Jun 85 15:28:15 EST Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 2 Jun 85 12:20:36 PDT Received: ID ; Sun 2 Jun 85 15:20:44-EDT Date: Sun, 2 Jun 1985 15:20 EDT Message-ID: Sender: FAHLMAN@CMU-CS-C.ARPA From: "Scott E. Fahlman" To: Rob MacLachlan Cc: common-lisp@SU-AI.ARPA Subject: Get-Setf-Method In-reply-to: Msg of 23 May 1985 08:03-EDT from Rob MacLachlan Get-Setf-Method should take an (optional?) environment argument so that it can expand macros correctly. Steve Handerson has pointed out that MACRO-FUNCTION also needs an optional evironment argument, since without this we have no way of getting hold of the expansion function for a lexically defined macro (though we can execute this function). This may or may not be important for normal code, but it is definitely important for writing environment tools such as a single-stepper. -- Scott  Received: from SU-AI.ARPA by MIT-MC.ARPA 2 Jun 85 14:07:36 EST Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 2 Jun 85 10:58:18 PDT Received: ID ; Sun 2 Jun 85 13:58:26-EDT Date: Sun, 2 Jun 1985 13:58 EDT Message-ID: Sender: FAHLMAN@CMU-CS-C.ARPA From: "Scott E. Fahlman" To: Guy Steele Cc: common-lisp@SU-AI.ARPA Subject: Rules of the game and stability In-reply-to: Msg of 29 May 1985 17:24-EDT from Guy Steele The charter committee has indeed been too inactive of late, and even when we were active we were concentrating more on organizational issues than on the proper philosophy for stability versus fixing things. I'll try to fire this discussion up again, once I get finished with some immediate demands on my time. I sort of put things on hold until we all could get some idea of what services the DARPA/ISI contract was going to provide, and when. I agree with Guy's list of the kinds of changes that might be considered, in increasing order of disruptiveness. I would only add that there is a lot of variation in each of these categories: an incompatible change in the cut points of obscure trig functions is not going to disrupt things as much as, say, an incompatible change in the handling of special variables. Additions to the language are not a burden if accompanied by portable code that implements the addition. Other additions might not be implementable in a portable way, but would obviously require only very minor and local changes to implement. I also agree that Common Lisp 84 should be considered frozen in the way that Guy proposes: only compatible or absolutely essential changes should be made at this point. There should be no fundamental additions to Common Lisp 84 either, though there is no harm in putting together a body of quasi-standard code that can be trivially added to any complete and correct implementation, with the understanding that these features go into the base language the next time around. Library files could begin assuming the existence of these additions right now. But having said that, I should also say that the language as it stands is still very young, relatively untried, and full of known flaws. We should therefore allow for a reasonably fast evolution at the start. I think that for the next few years, it would be optimal to an updated specification appear every year, or at most every two years. I certainly don't want to wait until 1989 or whenever in order to fix the small but important problems that we've already identified. I'm not talking about a major upheaval every year -- I'm sure that we will carefully weigh the benefit of each change against the cost both to users and implementors -- but once we've decided that a change is worth making, we should not have to wait too long for the next release cycle to come around. At any time, there will be one well-defined version of Common Lisp that corresponds to the latest official release, and another that includes the changes that have been approved for the next future release. Nobody would be required to track the latter until the release date rolls around, but some of us (in universities, maybe) should install any such changes right away in order to verify that they do their job as intended. In any event, I think we should be aiming for another release as early as possible in 1986, and the incompatible changes we have been discussing should be considered to be proposals for that next release. -- Scott  Received: from SU-AI.ARPA by MIT-MC.ARPA 2 Jun 85 11:09:50 EST Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 2 Jun 85 08:02:33 PDT Received: ID ; Sun 2 Jun 85 11:02:19-EDT Date: Sun, 2 Jun 1985 11:02 EDT Message-ID: Sender: FAHLMAN@CMU-CS-C.ARPA From: "Scott E. Fahlman" To: perdue%hplabs.csnet@CSNET-RELAY.ARPA Cc: common-lisp@SU-AI.ARPA Subject: Programs writing backquote In-reply-to: Msg of 31 May 1985 12:58-EDT from perdue%hplabs.csnet at csnet-relay.arpa I'd like to second the proposal that Common LISP backquote "`" be explicitly defined as expanding into a macro, and that ",", ",@", and ",." expand similarly into s-expression forms. This makes backquote more accessible to programs. The point has been made that if "`" expands into a LISP macro invokation, a conventional interpreter will run the code relatively slowly. This kind of objection of course applies to use of macros in general, and I don't think we usually let it stop us from defining macros where they are useful. If we really want to do this, it should be sufficient to define S-expression forms that the various backquote character macros COULD expand into, and that programs can generate to get the same effect. We don't have to require implementors to actually use these in processing backquoted expressions. Since all of these generated forms have equivalents that use only pre-defined things like QUOTE, CONS, APPEND, and NCONC, I don't really see much point in adding a bunch of new things that correspond directly to the backquote forms. Programs can just say what they really mean, without having to try to think in terms of these cute surface-level forms that happen to be convenient for humans. -- Scott  Received: from SU-AI.ARPA by MIT-MC.ARPA 31 May 85 17:51:56 EST Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 31 May 85 14:40:04 PDT Received: from hplabs by csnet-relay.csnet id ag02308; 31 May 85 17:35 EDT Received: by HP-VENUS id AA09296; Fri, 31 May 85 13:00:59 pdt Message-Id: <8505312000.AA09296@HP-VENUS> Date: 31-May-85 12:58:47 To: common-lisp@su-ai.ARPA Subject: Re: Programs writing backquote From: perdue%hplabs.csnet@csnet-relay.arpa Source-Info: From (or Sender) name not authenticated. I'd like to second the proposal that Common LISP backquote "`" be explicitly defined as expanding into a macro, and that ",", ",@", and ",." expand similarly into s-expression forms. This makes backquote more accessible to programs. The point has been made that if "`" expands into a LISP macro invokation, a conventional interpreter will run the code relatively slowly. This kind of objection of course applies to use of macros in general, and I don't think we usually let it stop us from defining macros where they are useful. -------  Received: from SU-AI.ARPA by MIT-MC.ARPA 31 May 85 12:35:48 EST Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 31 May 85 09:26:01 PDT Received: from NEPONSET.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 246905; Fri 31-May-85 12:25:18-EDT Date: Fri, 31 May 85 12:28 EDT From: David C. Plummer in disguise Subject: CLtL Index To: common-lisp@SU-AI.ARPA Message-ID: <850531122824.9.NFEP@NEPONSET.SCRC.Symbolics.COM> CLtL's index doesn't have &anything either at the beginning or the end (with the other non-alphabetics). I therefore can't look up &KEY, etc, since they aren't listed under their non-& names.  Received: from SU-AI.ARPA by MIT-MC.ARPA 29 May 85 17:55:13 EST Received: from THINK.ARPA by SU-AI.ARPA with TCP; 29 May 85 14:45:49 PDT Received: by THINK.ARPA with CHAOS id AA17733; Wed, 29 May 85 17:23:35 edt Date: Wed, 29 May 85 17:24 EDT From: Guy Steele Subject: Re: Rules of the game and stability To: common-lisp@SU-AI.ARPA Cc: gls@AQUINAS.ARPA In-Reply-To: <850529104747.9.DLW@CHICOPEE.SCRC.Symbolics.COM> Message-Id: <850529172430.3.GLS@DESIDERIUS.ARPA> Fonts: CPTFONT, CPTFONTB, CPTFONTI Date: Wed, 29 May 85 10:47 EDT From: Daniel L. Weinreb Date: 28 May 85 14:46 PDT From: masinter.pa@Xerox.ARPA Isn't this what the "charter" committee is supposed to be deciding? Yes, that's what I thought too. That's what I thought, too. When I started this whole discussion I clearly labeled my list of "rules" as merely my opinion of what we ought to do. The charter committee may consider that list as input to their discussions. The charter committee must also bear in mind that to make no decision is also a decision. People clearly want a revised edition (or revised printing) of the manual, or at least an errata sheet. I will do the editing work on this, but the charter should provide guidance how to go about it. If this doesn't happen in the next four months or so, I, radical fanatic that I am, may just go ahead and conduct a poll as we have done before and go from there, simply to get something done. However, I would rather have an agreed-upon structure in place to work within before this time comes. --Guy  Received: from SU-AI.ARPA by MIT-MC.ARPA 29 May 85 16:08:54 EST Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 29 May 85 12:57:19 PDT Received: from NEPONSET.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 245299; Wed 29-May-85 10:56:43-EDT Date: Wed, 29 May 85 10:59 EDT From: David C. Plummer in disguise Subject: programs writing backquote To: masinter.pa@XEROX.ARPA, common-lisp@SU-AI.ARPA In-Reply-To: <[]<>MG>Q>Item-850528-143855-1480@Xerox> Message-ID: <850529105911.3.NFEP@NEPONSET.SCRC.Symbolics.COM> Date: 28 May 85 14:38 PDT From: masinter.pa@Xerox.ARPA In part of the discussion over nesting depth of backquote, more than one person alluded to the possibility that a *program* could write a 3-deep nested backquote and that this was generally a good thing. However, as far as I can tell, it would be easier for a Snobol program to write nested backquotes rather than Lisp, because there is no defined S-expression representation of backquotes... the only thing GSSB ( Guy Steele's Silver Book) defines is the surface syntax. Do I misunderstand? Can someone give a program which creates a Common Lisp 3-deep-nested backquote, without resorting to string manipulations? This doesn't resort to string manipulation, and it produces structure that is more than 3 deep. It is quite contrived, but it does satisfy your requirements. Just trying to produce this example gave me the opinion it is hard to write meaningful programs [that write meaningful programs...] that produce highly nested backquoted structure. (defun print-using-backquote (exp) (pprint (sublis '((list . si:xr-bq-list) (cons . si:xr-bq-cons) (list* . si:xr-bq-list*) (append . si:xr-bq-append)) exp))) (print-using-backquote ;; exp starts out being a constructor of an alist. The data of the ;; alist is another alist (do ((exp '(list (list 'a (cons 'ab ab) (cons 'ac ac)) (list 'b (cons 'bb bb) (cons 'bc bc)) (list 'c (cons 'cb cb) (cons 'cc cc))) (subst exp 'bc exp)) (count 2 (1- count))) ((zerop count) (print-using-backquote exp)))) `((A (AB .,AB) (AC .,AC)) (B (BB .,BB) (`((A (AB .,AB) (AC .,AC)) (B (BB .,BB) (`((A (AB .,AB) (AC .,AC)) (B (BB .,BB) (`((A (AB .,AB) (AC .,AC)) (B (BB .,BB) (BC .,BC)) (C (CB .,CB) (CC .,CC))) (A (AB .,AB) (AC .,AC)) (B (BB .,BB) (BC .,BC)) (C (CB .,CB) (CC .,CC)))) (C (CB .,CB) (CC .,CC))) (A (AB .,AB) (AC .,AC)) (B (BB .,BB) (`((A (AB .,AB) (AC .,AC)) (B (BB .,BB) (BC .,BC)) (C (CB .,CB) (CC .,CC))) (A (AB .,AB) (AC .,AC)) (B (BB .,BB) (BC .,BC)) (C (CB .,CB) (CC .,CC)))) (C (CB .,CB) (CC .,CC)))) (C (CB .,CB) (CC .,CC))) (A (AB .,AB) (AC .,AC)) (B (BB .,BB) (`((A (AB .,AB) (AC .,AC)) (B (BB .,BB) (`((A (AB .,AB) (AC .,AC)) (B (BB .,BB) (BC .,BC)) (C (CB .,CB) (CC .,CC))) (A (AB .,AB) (AC .,AC)) (B (BB .,BB) (BC .,BC)) (C (CB .,CB) (CC .,CC)))) (C (CB .,CB) (CC .,CC))) (A (AB .,AB) (AC .,AC)) (B (BB .,BB) (`((A (AB .,AB) (AC .,AC)) (B (BB .,BB) (BC .,BC)) (C (CB .,CB) (CC .,CC))) (A (AB .,AB) (AC .,AC)) (B (BB .,BB) (BC .,BC)) (C (CB .,CB) (CC .,CC)))) (C (CB .,CB) (CC .,CC)))) (C (CB .,CB) (CC .,CC)))) (C (CB .,CB) (CC .,CC)))  Received: from SU-AI.ARPA by MIT-MC.ARPA 29 May 85 16:06:49 EST Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 29 May 85 12:57:29 PDT Received: from CHICOPEE.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 245277; Wed 29-May-85 10:46:45-EDT Date: Wed, 29 May 85 10:47 EDT From: Daniel L. Weinreb Subject: Re: Rules of the game and stability To: masinter.pa@XEROX.ARPA, common-lisp@SU-AI.ARPA In-Reply-To: <[]<>MG>Q>Item-850528-144636-1487@Xerox> Message-ID: <850529104747.9.DLW@CHICOPEE.SCRC.Symbolics.COM> Fonts: CPTFONT, CPTFONTB, CPTFONTI Reply-To: dlw@SCRC-STONY-BROOK.ARPA Date: 28 May 85 14:46 PDT From: masinter.pa@Xerox.ARPA Isn't this what the "charter" committee is supposed to be deciding? Yes, that's what I thought too.  Received: from SU-AI.ARPA by MIT-MC.ARPA 29 May 85 15:56:23 EST Received: from DEC-HUDSON.ARPA by SU-AI.ARPA with TCP; 29 May 85 07:08:44 PDT Date: Wed, 29 May 85 10:08:47 EDT From: greek@DEC-HUDSON Subject: Internal representation of backquotes To: common-lisp@su-ai We would have to be very careful if we wanted to specify how backquotes et al are represented when read in. In PSL, you have an explicit form for backquote et al, but in VAX LISP the reader converts the backquotes into the actual LISP code needed to build the backquoted lists. So we lose all knowledge that a backquote was ever involved (unless, of course, you turn on the magic variable that causes us to remember). I think we need to allow maximum flexibility in generating efficient code for backquotes. - Paul  Received: from SU-AI.ARPA by MIT-MC.ARPA 29 May 85 15:49:52 EST Received: from DEC-HUDSON.ARPA by SU-AI.ARPA with TCP; 29 May 85 07:08:44 PDT Date: Wed, 29 May 85 10:08:47 EDT From: greek@DEC-HUDSON Subject: Internal representation of backquotes To: common-lisp@su-ai We would have to be very careful if we wanted to specify how backquotes et al are represented when read in. In PSL, you have an explicit form for backquote et al, but in VAX LISP the reader converts the backquotes into the actual LISP code needed to build the backquoted lists. So we lose all knowledge that a backquote was ever involved (unless, of course, you turn on the magic variable that causes us to remember). I think we need to allow maximum flexibility in generating efficient code for backquotes. - Paul  Received: from SU-AI.ARPA by MIT-MC.ARPA 29 May 85 03:15:40 EST Sent: to SU-AI.ARPA by IMSSS.? via ETHERNET with PUPFTP; 1985-May-29 23:02:12 PST (=GMT-8hr) Date: 1985 May 28 22:56:08 PST (=GMT-8hr) Message-id: SU-IMSSS.REM.A132206061364.G0353 From: Robert Elton Maas To:masinter.pa@Xerox.ARPA CC:COMMON-LISP@SU-AI.ARPA Sender: REM%IMSSS@SU-SCORE.ARPA (for undeliverable-mail notifications) Reply-to: REM%IMSSS@SU-SCORE.ARPA (temporary until nameservers up) > Date: 28 May 85 14:38 PDT > From: masinter.pa@Xerox.ARPA > Subject: programs writing backquote > > In part of the discussion over nesting depth of backquote, more than one > person alluded to the possibility that a *program* could write a 3-deep > nested backquote and that this was generally a good thing. > > However, as far as I can tell, ... because there is no defined > S-expression representation of backquotes... the only thing GSSB ( Guy > Steele's Silver Book) defines is the surface syntax. This is curious because in PSL the ` read-macro seems to generate a true LISP macro (i.e. an s-expression representation of the ` syntax) which then actually implements the semantics of the ` character when interpreted or compiled. Perhaps CL should specify something like this explicitly? Below are examples of original PSL source and the result of READing into memory following by PRIN1ing it back out (then manually prettyprinting in EMACS). It seems to me quite reasonable that a PRINter function that is smarter than PRIN1 might re-introduce the backquote optimizations (or in complex cases find better optimizations than given by original programmer). (defmacro cl-alias (sl-name cl-name) `(defmacro ,cl-name form `(,',sl-name . ,form))) (DEFMACRO CL-ALIAS (SL-NAME CL-NAME) (BACKQUOTE (DEFMACRO (UNQUOTE CL-NAME) FORM (BACKQUOTE ((UNQUOTE (QUOTE (UNQUOTE SL-NAME))) UNQUOTE FORM))))) (defmacro errset (form flag) `(errorset `,',form ,flag ,flag)) (DEFMACRO ERRSET (FORM FLAG) (BACKQUOTE (ERRORSET (BACKQUOTE (UNQUOTE (QUOTE (UNQUOTE FORM)))) (UNQUOTE FLAG) (UNQUOTE FLAG))))  Received: from SU-AI.ARPA by MIT-MC.ARPA 28 May 85 18:41:12 EST Received: from SUMEX-AIM.ARPA by SU-AI.ARPA with TCP; 28 May 85 15:32:24 PDT Date: Tue 28 May 85 15:32:25-PDT From: Larry Masinter Subject: (duplicate) programs writing backquote To: common-lisp@SU-AI.ARPA I've gotten back about twenty "Unable to deliver" messages because of a new "message-id" that our local mail-handler started adding. I'm repeating the message here -- sorry if it is a duplicate. Date: 28 May 85 14:38 PDT From: masinter.pa@Xerox.ARPA Subject: programs writing backquote To: common-lisp@su-ai.ARPA Message-ID: <[]<>MG>Q>Item-850528-143855-1480@Xerox> In part of the discussion over nesting depth of backquote, more than one person alluded to the possibility that a *program* could write a 3-deep nested backquote and that this was generally a good thing. However, as far as I can tell, it would be easier for a Snobol program to write nested backquotes rather than Lisp, because there is no defined S-expression representation of backquotes... the only thing GSSB ( Guy Steele's Silver Book) defines is the surface syntax. Do I misunderstand? Can someone give a program which creates a Common Lisp 3-deep-nested backquote, without resorting to string manipulations? -------  Received: from SU-AI.ARPA by MIT-MC.ARPA 28 May 85 18:28:10 EST Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 28 May 85 15:15:03 PDT Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 244953; Tue 28-May-85 18:14:34-EDT Date: Tue, 28 May 85 18:14 EDT From: Kent M Pitman Subject: programs writing backquote To: masinter.pa@XEROX.ARPA, common-lisp@SU-AI.ARPA In-Reply-To: <[]<>MG>Q>Item-850528-143855-1480@Xerox> Message-ID: <850528181434.0.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> Date: 28 May 85 14:38 PDT From: masinter.pa@Xerox.ARPA In part of the discussion over nesting depth of backquote, more than one person alluded to the possibility that a *program* could write a 3-deep nested backquote and that this was generally a good thing. However, as far as I can tell, it would be easier for a Snobol program to write nested backquotes rather than Lisp, because there is no defined S-expression representation of backquotes... the only thing GSSB ( Guy Steele's Silver Book) defines is the surface syntax. Do I misunderstand? Can someone give a program which creates a Common Lisp 3-deep-nested backquote, without resorting to string manipulations? The program that manipulates the common lisp does not itself have to be written in common lisp. (eg, we've already conceded you can't write a real time editor in common lisp, but that doesn't free us from the constraint that common lisp code must be editable...) In fact, the programs that I have which manipulate common backquote structure are written in Zetalisp and they make assumptions about the internal representation of backquoted structure. However, all that aside, it is completely trivial to write a common lisp program which has its own readtable and its own representation for backquoted structure and whose sole job in life is to read in expressions, frob their backquoted structure using its private representation, and write them back out. ... not to mention manipulating the expression at the text level -- such as using just c-m-K and c-Y in Emacs to move a doubly nested backquote expression inside a macro which already has a level of backquote ... something I do all the time without the aid of any tools fancier than Emacs...  Received: from SU-AI.ARPA by MIT-MC.ARPA 28 May 85 17:59:33 EST Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 28 May 85 14:50:31 PDT Received: from Semillon.ms by ArpaGateway.ms ; 28 MAY 85 14:46:36 PDT Date: 28 May 85 14:46 PDT From: masinter.pa@Xerox.ARPA Subject: Re: Rules of the game and stability To: common-lisp@SU-AI.ARPA cc: common-lisp-charter@su-ai.ARPA Message-ID: <[]<>MG>Q>Item-850528-144636-1487@Xerox> Isn't this what the "charter" committee is supposed to be deciding? I've not seen much action on CLCHRT.MSG -- is there more happening behind-the-scenes?  Received: from SU-AI.ARPA by MIT-MC.ARPA 28 May 85 17:47:16 EST Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 28 May 85 14:38:51 PDT Received: from Semillon.ms by ArpaGateway.ms ; 28 MAY 85 14:38:55 PDT Date: 28 May 85 14:38 PDT From: masinter.pa@Xerox.ARPA Subject: programs writing backquote To: common-lisp@su-ai.ARPA Message-ID: <[]<>MG>Q>Item-850528-143855-1480@Xerox> In part of the discussion over nesting depth of backquote, more than one person alluded to the possibility that a *program* could write a 3-deep nested backquote and that this was generally a good thing. However, as far as I can tell, it would be easier for a Snobol program to write nested backquotes rather than Lisp, because there is no defined S-expression representation of backquotes... the only thing GSSB ( Guy Steele's Silver Book) defines is the surface syntax. Do I misunderstand? Can someone give a program which creates a Common Lisp 3-deep-nested backquote, without resorting to string manipulations?  Received: from SU-AI.ARPA by MIT-MC.ARPA 28 May 85 12:56:56 EST Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 28 May 85 09:46:29 PDT Received: from NEPONSET.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 244606; Tue 28-May-85 12:46:07-EDT Date: Tue, 28 May 85 12:48 EDT From: David C. Plummer in disguise Subject: Adjusting displaced arrays. To: greek@DEC-HUDSON.ARPA, common-lisp@SU-AI.ARPA In-Reply-To: The message of 28 May 85 11:21-EDT from greek@DEC-HUDSON Message-ID: <850528124820.3.NFEP@NEPONSET.SCRC.Symbolics.COM> Date: Tue, 28 May 85 11:21:20 EDT From: greek@DEC-HUDSON Erf! I certainly should have objected to the incredible hair needed to implement adjustable arrays, pa'ticularly those which are displaced, back when we specified them. However, I'd like to object now. I'd like to see a list of the uses people make of displaced and adjustable arrays. Maybe there are only two or three real features that people use, and we could restrict ourselves to those. I looked around here at DEC, and found exactly two uses: 1. Make an array bigger. Obviously this could be done with MAKE-ARRAY and REPLACE. 2. Linearize a multidimensional array so that row-major references can be done. This is useful, but an AREF-ROW-MAJOR function could probably do it more efficiently. LispMs (which include Symbolics, and I believe LMI and TI for this discussion) use displaced arrays for at least the following: NSUBSTRING (which is SUBSTRING, but shares storage) bitmaps (both for creating subwindows of windows, and for redirecting an array (a) to a physical screen or (b) to a bit save array.) de/en-capsulating network packets (e.g., the data of a packet is a string that shares storage with the packet; the string starts after the protocol header.) I don't think we don't use it for your case (1); instead we do make a new array, copy, and structure forwared the old to the new. They can also be used for your case (2), but I think the our function SYS:%1D-AREF subsumes the need. It seems to me that any set of rules that require AREF to iterate to find the data ought to be simplified. So much for inline code.  Received: from SU-AI.ARPA by MIT-MC.ARPA 28 May 85 11:32:45 EST Received: from DEC-HUDSON.ARPA by SU-AI.ARPA with TCP; 28 May 85 08:21:49 PDT Date: Tue, 28 May 85 11:21:20 EDT From: greek@DEC-HUDSON Subject: Adjusting displaced arrays. To: common-lisp@su-ai Erf! I certainly should have objected to the incredible hair needed to implement adjustable arrays, particularly those which are displaced, back when we specified them. However, I'd like to object now. I'd like to see a list of the uses people make of displaced and adjustable arrays. Maybe there are only two or three real features that people use, and we could restrict ourselves to those. I looked around here at DEC, and found exactly two uses: 1. Make an array bigger. Obviously this could be done with MAKE-ARRAY and REPLACE. 2. Linearize a multidimensional array so that row-major references can be done. This is useful, but an AREF-ROW-MAJOR function could probably do it more efficiently. It seems to me that any set of rules that require AREF to iterate to find the data ought to be simplified. So much for inline code. - Paul  Received: from SU-AI.ARPA by MIT-MC.ARPA 28 May 85 10:50:46 EST Received: from DEC-HUDSON.ARPA by SU-AI.ARPA with TCP; 28 May 85 07:41:41 PDT Date: Tue, 28 May 85 10:41:47 EDT From: greek@DEC-HUDSON Subject: Rules of the Game To: common-lisp@su-ai I'm glad we are taking time to establish a "policy" about making changes to CL'84. Regarding Guy's categories 3 and 4, I think we should only introduce new features when they are necessary to repair a (more or less) flawed feature in the language. For example, PARSE-BODY is needed by every correct implementation, so indeed we might as well specify it. Incompatible changes should only be made when absolutely necessary to fix a broken feature. New features and incompatible changes which do not fall into the above category should be left for CL'8n. As Guy said, we ought to give everyone a half a chance to finish implementing CL'84 before we throw a pile of new good stuff at them. Remember, CLs that are real products can't be changed continuously, because real products change in cycles (often as long as a year or two). - Paul