Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 14 Jul 87 22:59:43 EDT Received: from VENERA.ISI.EDU by SAIL.STANFORD.EDU with TCP; 14 Jul 87 19:46:29 PDT Posted-Date: Tue, 14 Jul 87 19:45:12 PDT Received: from hpai00.isi.edu by venera.isi.edu (5.54/5.51) id AA22941; Tue, 14 Jul 87 19:46:42 PDT Received: by hpai00 ; Tue, 14 Jul 87 19:45:27 pdt From: vrotney@venera.isi.edu Message-Id: <8707150245.AA03095@hpai00> Date: Tue, 14 Jul 87 19:45:12 PDT Subject: Re: Apropos case sensitive? To: Common-Lisp@sail.stanford.edu In-Reply-To: Your message of 14-Jul-87 12:03:00 X-Mailer: NMail [$Revision: 2.6 $] re: -------------------------------------------------------------------------------- From: Steve.Handerson@spice.cs.cmu.edu Sorry if this has already been decided, but I've been using lucid, which has a case-sensitive apropos, and think it's *the wrong thing*. -------------------------------------------------------------------------------- I think lucid is doing the right thing according to CLTL. CLTL says "(apropos [italics]string) tries to find all available symbols whose print name contains [italics]string as a substring." Since we are dealing with strings, I take "substring" here to mean case sensitive. For example (string= "FOO" "foo") => NIL. If this is what CLTL says however (clarification please) then two points need to made. (1.) There are other CL implementations that do a case INSENSATIVE apropos. (2.) The traditional apropos did a case INSENSATIVE comparison and I find this to be a generally more useful one. It would have been better (I think) if CLTL had specified EXACTLY that if apropos was given a string as an argument it would do case sensitive, and if given a symbol it would do case insensative. Because, on an implementation that does a strictly speaking "case sensitive apropos" then (apropos 'foo) should not print out the function who's print name is "foo" since the print name of the symbol 'foo is "FOO". -------  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 14 Jul 87 12:40:57 EDT Received: from MCC.COM by SAIL.STANFORD.EDU with TCP; 14 Jul 87 09:29:52 PDT Received: from bell by MCC.COM with TCP; Tue 14 Jul 87 11:29:10-CDT Date: Tue, 14 Jul 87 11:28:07 CDT From: Self-Deluded Demigod Posted-Date: Tue, 14 Jul 87 11:28:07 CDT Message-Id: <8707141628.AA05857@bell> Received: by bell (5.51/CAD) id AA05857; Tue, 14 Jul 87 11:28:07 CDT To: common-lisp@sail.stanford.edu Subject: Test - Please ignore Cc: arisco%bell.cad.mcc.com@mcc.com This is only a test. Please excuse the intrusion.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 14 Jul 87 12:34:01 EDT Received: from SPICE.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 14 Jul 87 09:22:04 PDT Date: 14 Jul 1987 12:03-EDT From: Steve.Handerson@spice.cs.cmu.edu To: Common-Lisp@SAIL.STANFORD.EDU Subject: Apropos case sensitive? Message-Id: <553277038/skh@spice.cs.cmu.edu> Sorry if this has already been decided, but I've been using lucid, which has a case-sensitive apropos, and think it's *the wrong thing*. It's easy to write a case-sensitive apropos using a case-sensitive one, but to do the reverse you're effectively rewriting apropos. What if some mad C hacker was writing code for you? "Oh yeah, apropos foo." Did he mean FOO, Foo, or foo? Or maybe (gasp) fOO? -- STeVe  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 14 Jul 87 11:33:12 EDT Received: from HPLABS.HP.COM by SAIL.STANFORD.EDU with TCP; 14 Jul 87 08:16:37 PDT Received: from hplms1 by hplabs.HP.COM with TCP ; Tue, 14 Jul 87 08:14:33 pdt Received: from hplabsz.hpl.hp.com by hplms1; Tue, 14 Jul 87 08:14:10 pdt Return-Path: Received: by hplabsz; Tue, 14 Jul 87 08:14:52 pdt Date: Tue, 14 Jul 87 08:14:52 pdt From: Jim Kempf Message-Id: <8707141514.AA25943@hplabsz.hpl.hp.com> To: @SAIL.STANFORD.EDU:KMP@STONY-BROOK.SCRC.Symbolics.COM, Common-Lisp@SAIL.STANFORD.EDU Subject: Re: Appropriate use of the Common-Lisp mailing list While I understand the motivation behind this note, I belive a more fruitful approach would be to provide a forum for novices to post questions, rather than chiding them for posting their questions to the only forum they perhaps know about. I personally believe that Common Lisp is generally useful enough as a language that information about how to use it should not become the property of an "elitist" club, but rather should be available to all. Electronic bboards are one of the most effective and timely means of dissemintating such information. I agree, in addition, that there should be a forum for experts, where serious design questions can be posted, particularly with regard to enhancements and fixes needed as a result of the standardization process. For those users who have access to UN*X notes, a more appropriate forum for novice questions might be the notes group comp.lang.lisp. Traffic in this group is generally light, and mostly of the nature of "Where can I find implementation" or "Does anyone have experience with implementation" rather than questions about how to the use the language. This is in contrast to the groups on C and other languages, where such questions form the bulk of the notes. Therefore, perhaps a better suggestion would be to use comp.lang.lisp for specific questions about how to use the language, and save this group for design questions on the language itself. Those users who don't have a UN*X notes feed will, unfortunately, have a problem, but notes feeds are easy to get. Additionally, as Ken pointed out in the base note, local experts (providing they are available) are generally even more effective than bboards, and books are approprate for getting the bigger picture. Jim Kempf kempf@hplabs.hp.com  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 10 Jul 87 14:48:26 EDT Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 10 Jul 87 11:16:09 PDT Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 190963; Thu 9-Jul-87 21:53:46 EDT Date: Thu, 9 Jul 87 21:53 EDT From: Kent M Pitman Subject: Appropriate use of the Common-Lisp mailing list To: Common-Lisp@SAIL.STANFORD.EDU Message-ID: <870709215332.4.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> The mailing list Common-Lisp@SAIL.STANFORD.EDU was created as a communication path between the Common-Lisp designers. Since its creation, a number of `outsiders' have asked to be added and the list has grown to enormous proportions. While we have allowed such `auditing' of this discussion, and while such `auditors' have occassionally contributed usefully to the discussion, please keep in mind that every message sent to this list takes a large amount of CPU time on dozens of machines to deliver, a large amount of disk space to deliver and archive, and ultimately reaches hundreds of people, most of whom are probably very busy. I don't wish to sound elitist, but this list is of little value to me or the other Common-Lisp designers if the quality of conversation which crosses it is not very high. It is not intended as a free consulting service for us to bring novices up to speed; we just don't have the time. If you think you have something to "contribute" but you've never implemented a lisp or you don't have many years of experience in serious Lisp programming, please think twice or talk it over with an expert before asking a question of this large community which could as easily have been answered by an individual. You can save the community much time, disk space, work, and ultimately money -- and you can save yourself some embarrassment. Thanks very much for your time and cooperation. -kmp  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 10 Jul 87 14:44:55 EDT Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 10 Jul 87 11:26:59 PDT Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 191277; Fri 10-Jul-87 14:26:06 EDT Date: Fri, 10 Jul 87 14:25 EDT From: Kent M Pitman Subject: Plists and NIL. To: dml@NADC.ARPA cc: common-lisp@SAIL.STANFORD.EDU In-Reply-To: <8707091316.AA06374@NADC.ARPA> Message-ID: <870710142547.8.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> Date: Thu, 9 Jul 87 09:16:07 EDT From: dml@nadc.arpa (D. Loewenstern) 1) NIL is a symbol. Like all symbols, it has a plist (see CLtL p.4 for an example). Correct. 2) NIL is a list. Correct. Therefore, does (SETQ z NIL) (SETF (GETF z :a) :b) z return NIL or (:a :b)? If you're having to ask this question, you must be confusing GET and GETF. GETF operates on the plist-format list which is returned by the place named in its first argument position. In the case you've described where Z contains the empty list, (SETF (GETF z :a) :b) is equivalent to (SETQ z (LIST* :a :b z)) CLtL is unambiguous on that Z should contain (:A :B) after the series of operations you're asking about. (That is, does the property go on NIL's plist or directly into the list referenced by z?) Quoting from p166 in the first line of the description of GETF: ``... searches the property list store in ..." The description of generalized variables on pp93-94 is adequate to allow you to interpret this, but just to be clear: A place is a form which if evaluated would access a location. Something is in a place if it would be yield by evaluating that place. the result of evaluating Z is NIL. Z is the place, NIL is the something that is in the place Z. The thing which is searched is the NIL. Updating a place means causing future accesses to that place, Z, to yield an updated value. SETF does such updating. The thing which is updated in the case of (SETF (GETF z ...) ...) is Z since Z is the thing whose contents are searched by GETF. Golden Common LISP (ver. 2.2LM) resolves this by having no plist on NIL. I consider this a bug, however. David Loewenstern It may be that GCLISP doesn't have a plist of NIL. My guess without doing the requisite research is that this is a bug, but you should take it up with them, not with the whole Common-Lisp community. In any case, the question of whether or not NIL has a plist has no bearing on the question of what GETF does, except in the special case which you did not mention where (GETF (SYMBOL-PLIST sym) ...) is done. (The description of GET is quite clear on this at the top of p165 where it actually makes this equivalence.) Even here, there is no ambiguity because here it is clear that you search the SYMBOL-PLIST cell: (GETF Z 'indicator) looks in the value Z. (SETF (GETF Z 'indicator) 'value) sets the value of Z an appropriate value so that subsequent calls to (GETF Z 'indicator) will yield the VALUE. (GET 'Z 'indicator) or (GETF (SYMBOL-PLIST 'Z) 'indicator) looks in the symbol-plist of the symbol Z. (SETF (GET 'Z 'indicator) 'value) or (SETF (GETF (SYMBOL-PLIST 'Z) 'indicator) 'value) sets the symbol-plist of the symbol Z to an appropriate value so that subsequent calls to (GET 'Z 'indicator) or (GETF (SYMBOL-PLIST 'Z) 'indicator) will yield VALUE. By the way, the telltale quotes all through the second paragraph should be the give-away that Z is being manipulated as a symbol, not a variable. As a symbol, accesses to it as a slot are typically the standard mode of interaction. As a variable, references to its value are typically the standard mode of interaction. In my opinion, it is appropriate to bring to the attention of this community situations in which two different vendors make the claim that there is a unique interpretation to a passage of CLtL and where those interpretations are not in agreement. I do not believe this is such a case. I think that all implementors are in agreement and I think you need to do your homework better. I'm sure your Gold Hill service representative would have been happy to provide you with this information if you'd gone to him/her before coming to us.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 10 Jul 87 14:37:04 EDT Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 10 Jul 87 11:16:41 PDT Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 190967; Thu 9-Jul-87 22:16:49 EDT Date: Thu, 9 Jul 87 22:16 EDT From: Kent M Pitman Subject: macrolet To: vax135!lcuxle!elia@ucbvax.Berkeley.EDU cc: common-lisp@SAIL.STANFORD.EDU In-Reply-To: <8707091704.AA03351@lcuxle.UUCP> Message-ID: <870709221637.5.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> [Aside: I don't think the purpose of the Common-Lisp list is to discuss the choice of examples in an already published book, except perhaps, in some cases where such examples are erroneous, misleading or contradictory. I don't think this is such a case. Personally, I think this would have been a good issue on which to get some private help rather than sending mail to this list.] Date: Thu, 9 Jul 87 13:04:27 EDT From: vax135!lcuxle!elia@ucbvax.Berkeley.EDU (Weixelbaum Elia) When I read the explanation for macrolet on page 114, Cltl, I had a few problems with the 'clear' example: (defun foo (x flag) (macrolet ((fudge (z) ... `(if flag (* ,z ,z) ,z))) ...)) ... (setq flag t) ==> t (foo 10 nil) ==> 31 (since flag is taken as nil). A more illustrative example might be to change the body of fudge to: `(if ,flag (* ,z ,z) ,z) ; Evaluate flag within macro expansion ... Your "fixed" code above fails to proclaim FLAG special. (Also, being special CLtL suggests the variable be called *FLAG* unless you have a compelling reason not to name it so.) Using DEFPARAMETER (or DEFVAR) rather than SETQ to set FLAG would have accomplished this. But more importantly, you have confused compilation time with load time. The SETQ (or even the DEFPARAMETER initialization) will not take place until the code is loaded, which is generally -after- the macro has expanded (except in the special case of interactive use, such as you probably did to test your example). You would have to have written the SETQ, DEFVAR, or DEFPARAMETER inside (EVAL-WHEN (EVAL COMPILE) ...) to assure that the assignment happened at the right time (ie, before the macroexpansion). I won't bother to address the issue that your suggested rewrite didn't include the removal of the FLAG variable (which is now unused) and the resulting visual confusion which might ensue from having a function bind a variable and then not refer to it while at the same time referring to a variable by the same name evaluated in some other context. All this aside, however, the code you suggest is not in a style that I think I would encourage people to use. The need to use global state is lamentable but often necessary. The use of compile time global state is even trickier and more to be avoided whenever possible just because of the confusion that can result about whether the compile time and runtime environment are the same or not. This varies a lot from dialect to dialect and is an easy place for code portability to be impacted. Encouraging a style which is likely to lead to trouble in portable programming is probably not wise. The example on p114 does not illustrate the full power of macrolet, but it does illustrate a fairly typical example of the way in which it is intended to be used, and that's what's important.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 10 Jul 87 12:59:41 EDT Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 10 Jul 87 09:42:03 PDT Received: ID ; Fri 10 Jul 87 12:40:45-EDT Date: Fri, 10 Jul 1987 12:40 EDT Message-ID: Sender: RAM@ From: Ram@C.CS.CMU.EDU To: sandra%orion@cs.utah.edu (Sandra J Loosemore) Cc: common-lisp@SAIL.STANFORD.EDU Subject: special forms In-reply-to: Msg of 10 Jul 1987 11:11-EDT from sandra%orion at cs.utah.edu (Sandra J Loosemore) Well, the implementation note on 58 implies that standard macros are allowed to expand into implementation-dependent special forms. In combination with the premission on 57 to implement special forms as macros, this suggests that it is legal for special forms to be implemented as macros that expand into implementation-dependent special forms. I am pretty certain that special forms, both standard and implementation dependent, should be special-form-p. It is true that it doesn't help a code walker much to know it has tripped over a special form it doesn't know about, but at least it can fail gracefully instead of treating random syntax as being evaluated forms. Having said this, I encourage you to avoid using implementation dependent special forms. In all the cases I have come across, expanding into a function call works just as well. You just stick in "'" and "#'" as necessary to prevent stuff from being evaluated. The compiler can still special-case these "funny functions" in arbitrary ways, but they obey function syntax, and thus make life easy for people who don't care. Rob  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 10 Jul 87 11:33:40 EDT Received: from CS.UTAH.EDU by SAIL.STANFORD.EDU with TCP; 10 Jul 87 08:09:27 PDT Received: by cs.utah.edu (5.54/utah-1.0) id AA26840; Fri, 10 Jul 87 09:11:41 MDT Received: by orion.utah.edu (5.54/utah-1.0-slave) id AA05214; Fri, 10 Jul 87 09:11:37 MDT Date: Fri, 10 Jul 87 09:11:37 MDT From: sandra%orion@cs.utah.edu (Sandra J Loosemore) Message-Id: <8707101511.AA05214@orion.utah.edu> Subject: special forms To: common-lisp@sail.stanford.edu Is it legit to implement a CL special form as a macro that expands into an implementation-specific special form? (For example, making FUNCTION expand into a CLOSURE form in some circumstances.) I do not think this would cause problems for code-walkers that use the procedure described on p. 57, since the code-walker is expected to have its own handling for all of the CL special forms and should never try to macroexpand them. Assuming this is allowed, should SPECIAL-FORM-P be true of the implementation-specific special forms or only those listed in CLtL? -Sandra -------  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 9 Jul 87 22:18:59 EDT Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 9 Jul 87 18:56:42 PDT Date: Thu, 9 Jul 1987 21:59 EDT Message-ID: From: STEVER%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU To: dml@NADC.ARPA (D. Loewenstern) Cc: common-lisp@SAIL.STANFORD.EDU Subject: Plists and NIL. In-reply-to: Msg of 9 Jul 1987 09:16-EDT from dml at nadc.arpa (D. Loewenstern) Date: Thursday, 9 July 1987 09:16-EDT From: dml at nadc.arpa (D. Loewenstern) 1) NIL is a symbol. Like all symbols, it has a plist (see CLtL p.4 for an example). 2) NIL is a list. Therefore, does (SETQ z NIL) (SETF (GETF z :a) :b) z return NIL or (:a :b)? (That is, does the property go on NIL's plist or directly into the list referenced by z?) It goes into the list referenced by Z. Your question seems to imply an extra level of evaluation, which doesn't occur with GETF. LISP is wonderful. It lets you say the same thing many ways. Here are some incantations and what they do (according to Steele and DEC-20 Common Lisp I'm using): These change NIL's property list: (SETQ Z NIL) (SETF (GET Z :A) :B) or (SETF (GETF (SYMBOL-PLIST 'NIL) :A) :B) or (SETF (GET 'NIL :A) :B) Note: (SETF (GETF Z :A) :B) gives Z the value (:A :B) This attempts to change NIL's value: (SETF (GETF NIL :A) :B) These retrieve properties from NIL's property list: (SETQ Z NIL) (GET Z :A) or (GETF (SYMBOL-PLIST 'NIL) :A) or (GET 'NIL :A) Note: (GETF Z :A) returns NIL (since Z contains an empty propert list) - Stephen  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 9 Jul 87 17:21:47 EDT Received: from VAXA.ISI.EDU by SAIL.STANFORD.EDU with TCP; 9 Jul 87 14:04:28 PDT Posted-Date: Thu, 09 Jul 87 14:04:38 PDT Message-Id: <8707092104.AA04144@vaxa.isi.edu> Received: from LOCALHOST by vaxa.isi.edu (5.54/5.51) id AA04144; Thu, 9 Jul 87 14:04:40 PDT To: common-lisp@sail.stanford.edu Subject: Validation suite Date: Thu, 09 Jul 87 14:04:38 PDT From: Richard Berman From the recent X3 committee meeting, it was gathered that, despite having posted several messages recently to CL-VALIDATION, it is apparent that even some people who subscribe to that mailing list haven't received my messages regarding the available common lisp test suite. Perhaps that mailing list is broken?? The only people that I know for sure have recieved copies of the test suite (which is available anonomous FTP from VENERA.ISI.EDU) are those who asked me directly for copies, and I gave them the information on where to find it. If you need this information, get on the CL-VALIDATION mailing list. If you ARE on it and you haven't received my messages, let Dick Gabriel know. If you have received my messages, please send me note to that effect. Rather than burden everyone with the full messages, send me a note if you want the info on the validation suite. And get on CL-VALIDATION. RB  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 9 Jul 87 16:53:11 EDT Received: from UCBVAX.Berkeley.EDU by SAIL.STANFORD.EDU with TCP; 9 Jul 87 12:08:24 PDT Received: by ucbvax.Berkeley.EDU (5.58/1.27) id AA24651; Thu, 9 Jul 87 10:21:07 PDT Received: by lcuxle.UUCP (4.6/4.2) id AA03351; Thu, 9 Jul 87 13:04:27 EDT Date: Thu, 9 Jul 87 13:04:27 EDT From: vax135!lcuxle!elia@ucbvax.Berkeley.EDU (Weixelbaum Elia) Message-Id: <8707091704.AA03351@lcuxle.UUCP> To: common-lisp@sail.stanford.edu Subject: macrolet When I read the explanation for macrolet on page 114, Cltl, I had a few problems with the 'clear' example: (defun foo (x flag) (macrolet ((fudge (z) ;The parameters x and flag are not accessible ;at this point; a reference to flag would be to ;the global variable of that name. `(if flag (* ,z ,z) ,z))) ;The parameters x and flag are accessible here. (+ x (fudge x) (fudge (+ x 1))))) It seems that while this is a valid example, it does not emphasize the point that is trying to be made. While 'fudge' is being defined foo's flag is not accessible, but since flag is quoted inside of fudge, by the time that the body of the macrolet is run, i.e., in (+ x ...), flag is accessible. Therefore if I run (setq flag t) ==> t (foo 10 nil) ==> 31 (since flag is taken as nil). A more illustrative example might be to change the body of fudge to: `(if ,flag (* ,z ,z) ,z) ; Evaluate flag within macro expansion Now, by running (setq flag t) ==> t (foo 10 nil) ==> 231 (since flag is taken as t). Elia Weixelbaum  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 9 Jul 87 16:52:49 EDT Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 9 Jul 87 12:07:14 PDT Received: from Cabernet.ms by ArpaGateway.ms ; 09 JUL 87 11:35:19 PDT Date: 9 Jul 87 11:34 PDT From: Daniels.pa@Xerox.COM Subject: Re: Plists and NIL. In-reply-to: dml@nadc.arpa (D. Loewenstern)'s message of Thu, 9 Jul 87 09:16:07 EDT To: dml@nadc.arpa cc: common-lisp@sail.stanford.edu Message-ID: <870709-113519-4138@Xerox> You seem to be confused. GETF always operates on an immediate plist, unlike GET, which operates on the plist of a given symbol. Thus (GETF Z :A) always refers to the plist that is the value of the variable Z. Whether or not NIL is a symbol or has a plist does not enter into the picture. The correct result of (setq z ()) (setf (getf z :a) :b) z is the list (:a :b). -- Andy. --  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 9 Jul 87 16:52:32 EDT Received: from MCC.COM by SAIL.STANFORD.EDU with TCP; 9 Jul 87 12:07:01 PDT Date: Thu 9 Jul 87 14:03:42-CDT From: Bob Boyer Subject: Re: kcl To: johnw%cvaxa.sussex.ac.uk@NSS.CS.UCL.AC.UK cc: common-lisp@SAIL.STANFORD.EDU In-Reply-To: <27802.8707091658@cvaxa.sussex.ac.uk> Message-ID: <12317044043.39.AI.BOYER@MCC.COM> ajcole%ai.leeds.ac.uk@Cs.Ucl.AC.UK has a copy and may help you out. -------  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 9 Jul 87 16:51:41 EDT Received: from CS.UCL.AC.UK by SAIL.STANFORD.EDU with TCP; 9 Jul 87 11:17:21 PDT Received: from aiva.edinburgh.ac.uk by nss.Cs.Ucl.AC.UK via Janet with NIFTP id aa13164; 9 Jul 87 18:53 BST From: Jeff Dalton Date: Thu, 9 Jul 87 18:52:11 -0100 Message-Id: <29800.8707091752@aiva.ed.ac.uk> To: johnw%cvaxa.sussex.ac.uk@Cs.Ucl.AC.UK Subject: UK KCL Cc: common-lisp@sail.stanford.edu We have a copy at Edinburgh that we are able to redistribute under the same conditions as U-Texas (that is, one must send in the license forms first), but it has not yet put it in place for ftp from outside the local ethernet. That will happen any day now, once certain admin. details have been dealt with. Instructions for obtaining a copy will be posted in the UK at that time. -- Jeff  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 9 Jul 87 12:49:56 EDT Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 9 Jul 87 09:30:28 PDT Received: from relay2.cs.net by RELAY.CS.NET id ac09037; 9 Jul 87 12:18 EDT Received: from utokyo-relay by RELAY.CS.NET id am10711; 9 Jul 87 12:12 EDT Received: by ccut.cc.u-tokyo.junet (5.51/6.2.9Junet) id AA26575; Fri, 10 Jul 87 00:38:41 JST Received: by titcca.cc.titech.junet (4.12/6.2Junet) id AA26856; Fri, 10 Jul 87 00:11:36 jst Received: by nttlab.NTT (4.12/6.2NTT.f) with TCP; Thu, 9 Jul 87 19:43:30 jst Received: by kuis.kuis.kyoto-u.junet (2.0/6.2Junet) id AA14586; Thu, 9 Jul 87 12:33:01 jst Received: by kurims.kurims.kyoto-u.junet (3.2/6.2Junet) id AA00314; Thu, 9 Jul 87 10:15:33 JST Date: Thu, 9 Jul 87 10:15:33 JST From: Masami Hagiya Return-Path: Message-Id: <8707090115.AA00314@kurims.kurims.kyoto-u.junet> To: common-lisp@SAIL.STANFORD.EDU Subject: Re: Flavors for KCL Mr. Hagiya, one of the implementors of KCL ported the Flavors system to KCL. This Flavors was originally written in Franz Lisp by Franz Inc. Please contact him if you are interested. His E-mail address is hagiya%kurims.kurims.kyoto-u.junet%japan.csnet@relay.cs.net - Gitchang - What I obtained from Franz (directly from the president) is the so called Old Flavors, which is in the public domain, and which is different from Franz's Flavors or Symbolics' New Flavors. Gitchang's comment is not correct in that I did not port Old Flavors to KCL, but my collegue Yuasa did. Moreover, since Old Flavors is written in dynamically scoped Lisp, he could not completely port it to KCL. As he is not satisfied with the result, he does not want to give the code away. If you are interested in obtaining the code, try to persuade him. -- Masami Hagiya  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 9 Jul 87 12:33:31 EDT Received: from CS.UCL.AC.UK by SAIL.STANFORD.EDU with TCP; 9 Jul 87 09:18:45 PDT Received: from cvaxa.sussex.ac.uk by nss.Cs.Ucl.AC.UK via Janet with NIFTP id aa11401; 9 Jul 87 17:13 BST From: John Williams Date: Thu, 9 Jul 87 16:58:14 gmt Message-Id: <27802.8707091658@cvaxa.sussex.ac.uk> To: common-lisp@sail.stanford.edu Subject: kcl Does anyone know of a UK distrubtion point for Kyoto Common Lisp ? I have a licence that has been approved by Kyoto U; but can't FTP the sources from the US as described in an earlier posting. Many thanks, john  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 9 Jul 87 09:35:33 EDT Received: from NADC.ARPA by SAIL.STANFORD.EDU with TCP; 9 Jul 87 06:18:35 PDT Received: by NADC.ARPA (5.51/1.0 ) id AA06374; Thu, 9 Jul 87 09:16:07 EDT Date: Thu, 9 Jul 87 09:16:07 EDT From: dml@nadc.arpa (D. Loewenstern) Message-Id: <8707091316.AA06374@NADC.ARPA> To: common-lisp@sail.stanford.edu Subject: Plists and NIL. Cc: dml@NADC.ARPA 1) NIL is a symbol. Like all symbols, it has a plist (see CLtL p.4 for an example). 2) NIL is a list. Therefore, does (SETQ z NIL) (SETF (GETF z :a) :b) z return NIL or (:a :b)? (That is, does the property go on NIL's plist or directly into the list referenced by z?) Golden Common LISP (ver. 2.2LM) resolves this by having no plist on NIL. I consider this a bug, however. David Loewenstern  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 9 Jul 87 08:59:05 EDT Received: from NADC.ARPA by SAIL.STANFORD.EDU with TCP; 9 Jul 87 05:45:49 PDT Received: by NADC.ARPA (5.51/1.0 ) id AA05017; Thu, 9 Jul 87 08:45:29 EDT Date: Thu, 9 Jul 87 08:45:29 EDT From: dml@nadc.arpa (D. Loewenstern) Message-Id: <8707091245.AA05017@NADC.ARPA> To: dml@NADC.ARPA, sidney%acorn@LIVE-OAK.LCS.MIT.EDU Subject: Re: Atoms in association lists Cc: common-lisp@sail.stanford.edu 1) Version 2.2, LM performs as I stated. I don't have 2.4. Personally, I prefer this performance. 2) CLtL, p.281, "if NIL appears in the a-list in place of a pair ... ASSOC will ignore the NIL in the a-list and continue to search for an actual pair (cons) whose car is NIL." If 2.4 returns NIL, then it is a bug.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 9 Jul 87 08:30:49 EDT Received: from CAEN.ENGIN.UMICH.EDU by SAIL.STANFORD.EDU with TCP; 9 Jul 87 05:21:01 PDT Received: by caen.engin.umich.edu (5.31/umix-2.0) id AA00351; Thu, 9 Jul 87 08:04:05 EDT Date: Thu, 9 Jul 87 08:04:05 EDT From: thoms@caen.engin.umich.edu (Dale E Thoms) Message-Id: <8707091204.AA00351@caen.engin.umich.edu> To: common-lisp@sail.stanford.edu Subject: OPS5 Does anyone know of an OPS5 interpreter written in CommonLisp? Any information you could give me would be much appreciated. My net address is: thoms@caen.engin.umich.edu Thanks, Dale Thoms EECS Department University of Michigan  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 9 Jul 87 08:05:58 EDT Received: from [128.81.51.3] by SAIL.STANFORD.EDU with TCP; 9 Jul 87 04:52:04 PDT Received: from RAVEN.S4CC.Symbolics.COM by DIAMOND.S4CC.Symbolics.COM via CHAOS with CHAOS-MAIL id 103750; Thu 9-Jul-87 07:50:39 EDT Date: Thu, 9 Jul 87 07:49 EDT From: Scott Cyphers Subject: Re: Atoms in association lists To: sidney%acorn@oak.lcs.mit.edu, dml@NADC.ARPA cc: common-lisp@sail.stanford.edu In-Reply-To: <870709062325.2.SIDNEY@ACORN.Gold-Hill.DialNet.Symbolics.COM> Message-ID: <870709074958.7.CYPHERS@RAVEN.S4CC.Symbolics.COM> Date: Thu, 9 Jul 87 06:23 EDT From: sidney%acorn@oak.lcs.mit.edu Actually, GCLisp handles atoms in alists by ignoring them, whether they are strings, NIL, or other symbols. E.g., (SETQ abc '(c (c . 3) NIL (NIL . 4))) (ASSOC 'c abc) --> (c . 3) (ASSOC nil abc) --> (NIL . 4) This is in accordance with CLtL, I believe. David Loewenstern -------- Since NIL is a list But NIL is not a cons. See page 281 of CLtL. as well as an atom and (car NIL) => NIL the correct result is (assoc NIL '((c . 3) NIL (NIL . 4))) => NIL (NIL . 4) should be returned, as someone stated earlier. The version of GCLisp I work with (2.4) evaluates it correctly. If an earlier version does return (NIL . 4) then it is a bug. (I didn't try it on any earlier versions.) -- sidney markowitz Gold Hill Computers  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 9 Jul 87 07:13:21 EDT Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 9 Jul 87 03:59:32 PDT Received: from LIVE-OAK.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 9 Jul 87 06:59-EDT Received: from GOLD-HILL-ACORN.DialNet.Symbolics.COM by LIVE-OAK.LCS.MIT.EDU.ARPA via DIAL with SMTP id 50792; 9 Jul 87 06:58:34-EDT Date: Thu, 9 Jul 87 06:23 EDT From: sidney%acorn@oak.lcs.mit.edu Subject: Re: Atoms in association lists To: dml@NADC.ARPA cc: common-lisp@sail.stanford.edu In-Reply-To: <8707081900.AA11071@NADC.ARPA> Message-ID: <870709062325.2.SIDNEY@ACORN.Gold-Hill.DialNet.Symbolics.COM> Actually, GCLisp handles atoms in alists by ignoring them, whether they are strings, NIL, or other symbols. E.g., (SETQ abc '(c (c . 3) NIL (NIL . 4))) (ASSOC 'c abc) --> (c . 3) (ASSOC nil abc) --> (NIL . 4) This is in accordance with CLtL, I believe. David Loewenstern -------- Since NIL is a list as well as an atom and (car NIL) => NIL the correct result is (assoc NIL '((c . 3) NIL (NIL . 4))) => NIL The version of GCLisp I work with (2.4) evaluates it correctly. If an earlier version does return (NIL . 4) then it is a bug. (I didn't try it on any earlier versions.) -- sidney markowitz Gold Hill Computers  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 9 Jul 87 07:13:08 EDT Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 9 Jul 87 03:58:21 PDT Received: from LIVE-OAK.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 9 Jul 87 06:58-EDT Received: from GOLD-HILL-ACORN.DialNet.Symbolics.COM by LIVE-OAK.LCS.MIT.EDU.ARPA via DIAL with SMTP id 50791; 9 Jul 87 06:58:16-EDT Date: Thu, 9 Jul 87 06:05 EDT From: sidney%acorn@oak.lcs.mit.edu Subject: Atoms in association lists To: krall%pp@mcc.com cc: common-lisp@sail.stanford.edu In-Reply-To: <8707061637.AA02959@pp.mcc.com> Message-ID: <870709060531.1.SIDNEY@ACORN.Gold-Hill.DialNet.Symbolics.COM> The behavior of assoc in current versions of Gold Hill's GCLISP is to not signal an error when it encounters an atom in an alist. It is not a matter of evaluating the car of an atom as nil, thus (assoc nil '((a 1) b (nil 5)) => (nil 5) This behavior is a deficiency in the error checking, even if technically not a bug. It is not an intentional interpretation of the standard. GCLISP v3.0, our first version which fully conforms to CLtL, corrects this. -- sidney markowitz Gold Hill Computers  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 9 Jul 87 01:14:19 EDT Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 8 Jul 87 22:02:47 PDT Received: by navajo.stanford.edu; Wed, 8 Jul 87 21:59:43 PDT Received: from bhopal.edsel.uucp by edsel.uucp (3.2/SMI-2.0) id AA04307; Wed, 8 Jul 87 21:33:03 PDT Received: by bhopal.edsel.uucp (3.2/SMI-3.2) id AA04024; Wed, 8 Jul 87 21:36:35 PDT Date: Wed, 8 Jul 87 21:36:35 PDT From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White) Message-Id: <8707090436.AA04024@bhopal.edsel.uucp> To: navajo!mab%mind.Princeton.EDU@navajo.stanford.edu Cc: navajo!common-lisp%sail.stanford.edu@navajo.stanford.edu In-Reply-To: Marie Bienkowski's message of Thu, 2 Jul 87 08:36:08 edt Subject: Loop Macro (after Zetalisp, franz, etc.) A MacLisp/Zetalisp LOOP facility is ready for "beta testing" in the Lucid 2.1 image; it is not a standard part of the 2.1 release, but can be obtained as a set of loadable files. It may be possible to retro-fit the "beta" LOOP for the 2.0 image also. -- JonL --  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 8 Jul 87 23:50:25 EDT Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 8 Jul 87 20:37:53 PDT Received: by navajo.stanford.edu; Wed, 8 Jul 87 20:35:09 PDT Received: from bhopal.edsel.uucp by edsel.uucp (3.2/SMI-2.0) id AA04214; Wed, 8 Jul 87 20:23:28 PDT Received: by bhopal.edsel.uucp (3.2/SMI-3.2) id AA03874; Wed, 8 Jul 87 20:27:01 PDT Date: Wed, 8 Jul 87 20:27:01 PDT From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White) Message-Id: <8707090327.AA03874@bhopal.edsel.uucp> To: navajo!DFM%JASPER%LIVE-OAK.LCS.MIT.EDU@navajo.stanford.edu Cc: navajo!sandra%orion%cs.utah.edu@navajo.stanford.edu, navajo!common-lisp%sail@navajo.stanford.edu In-Reply-To: Don Morrison's message of Mon, 29 Jun 87 12:56 EDT Subject: print question [This may have been answered already] MacLisp "streams" had an operation which basically amounted to saying "I want to output an n-character, unbroken sequence". By using this rather internal operation, the PRINT function would insure that streams with line-breaking capability didn't put the breaks at inappropriate places. I guess this means that the PRINT function is still somewhat involved. -- JonL --  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 8 Jul 87 18:04:21 EDT Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 8 Jul 87 14:48:09 PDT Received: from Cabernet.ms by ArpaGateway.ms ; 08 JUL 87 14:34:02 PDT Date: 8 Jul 87 14:33 PDT From: Daniels.pa@Xerox.COM Subject: Re: Atoms in association lists In-reply-to: dml@NADC.ARPA (D. Loewenstern)'s message of Wed, 8 Jul 87 15:00:19 EDT To: dml@NADC.ARPA cc: coffee@aerospace.aero.org, krall%pp.mcc.com%pp.mcc.com@mcc.com, common-lisp@sail.stanford.edu Message-ID: <870708-143402-2869@Xerox> Ignoring NIL in an alist is in accordance with CLtL. Any other non-cons in an alist is an error and may be dealt with as you see fit. -- Andy. --  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 8 Jul 87 15:40:57 EDT Received: from NADC.ARPA by SAIL.STANFORD.EDU with TCP; 8 Jul 87 12:23:49 PDT Received: by NADC.ARPA (5.51/1.0 ) id AA11071; Wed, 8 Jul 87 15:00:19 EDT Date: Wed, 8 Jul 87 15:00:19 EDT From: dml@NADC.ARPA (D. Loewenstern) Message-Id: <8707081900.AA11071@NADC.ARPA> To: coffee@aerospace.aero.org, krall%pp.mcc.com%pp.mcc.com@mcc.com Subject: Re: Atoms in association lists Cc: common-lisp@sail.stanford.edu Actually, GCLisp handles atoms in alists by ignoring them, whether they are strings, NIL, or other symbols. E.g., (SETQ abc '(c (c . 3) NIL (NIL . 4))) (ASSOC 'c abc) --> (c . 3) (ASSOC nil abc) --> (NIL . 4) This is in accordance with CLtL, I believe. David Loewenstern Naval Air Development Center code 7013 Warminster, PA 18974-5000  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 8 Jul 87 12:54:24 EDT Received: from [26.2.0.65] by SAIL.STANFORD.EDU with TCP; 8 Jul 87 09:38:09 PDT Received: by aerospace.aero.org (5.54/6.0.GT) id AA05259; Tue, 7 Jul 87 23:41:51 PDT Posted-Date: Tue, 07 Jul 87 23:41:31 -0800 Message-Id: <8707080641.AA05259@aerospace.aero.org> To: krall%pp.mcc.com%pp.mcc.com@mcc.com Cc: common-lisp@sail.stanford.edu Subject: Re: Atoms in association lists In-Reply-To: Your message of Monday, 6 July 1987, 11:34-CDT. <8707061637.AA02959@pp.mcc.com> Date: Tue, 07 Jul 87 23:41:31 -0800 From: coffee@aerospace.aero.org I wonder how Gold Hill would handle the example on p. 281 of CLtL, i.e., a NIL appearing in place of a pair in the a-list and an invocation of (assoc nil a-list). Steele notes that (assoc item list :test fn) is equivalent to (find item list :test fn :key #'car) *except* in this case, because the FIND will take the CAR of NIL and succeed with NIL while the ASSOC "will ignore the NIL in the a-list and continue to search for an actual pair (cons) whose CAR is NIL." I rather suspect that the Gold Hill implementation will fail to make this distinction, and if so I would consider this a bug (no matter how special the case may be).  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 7 Jul 87 22:22:35 EDT Received: from SUMEX-AIM.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 7 Jul 87 19:02:09 PDT Date: Tue, 7 Jul 87 19:00:23 PDT From: Hiroshi "Gitchang" Okuno Subject: Re: Flavors for KCL To: krall%pp.mcc.com%MCC.COM@SUMEX-AIM.STANFORD.EDU, common-lisp@SAIL.STANFORD.EDU In-Reply-To: <12316328931.47.OKUNO@SUMEX-AIM.STANFORD.EDU> Organization: Knowledge Systems Laboratory Group: Heuristic Programming Project Project: Advanced Architectures Project Address: 701 Welch Road, Building C, Palo Alto, CA 94304-1703 Phone: +1 (415)725-4854 Message-ID: <12316595611.63.OKUNO@SUMEX-AIM.STANFORD.EDU> I'm sorry that I posted a wrong information on FLavors. It should read "Mr. Hagiya, one of the implementors of KCL, ported a public domain Flavors system to KCL. This system was originally developed at MIT". Sorry for your inconvenience, - Gitchang - -------  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 7 Jul 87 12:38:09 EDT Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 7 Jul 87 09:18:25 PDT Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 188793; Mon 6-Jul-87 22:34:14 EDT Date: Mon, 6 Jul 87 22:34 EDT From: Kent M Pitman Subject: Atoms in association lists To: krall%pp.mcc.com@mcc.com cc: common-lisp@sail.stanford.edu In-Reply-To: <8707061637.AA02959@pp.mcc.com> Message-ID: <870706223404.4.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> Date: Monday, 6 July 1987, 11:34-CDT From: ... I write (setq alist '((a . 1) b (c . 3))) then try (assoc 'c alist) In Kyoto Common Lisp and in ZetaLisp, I get an error since the second element of alist is not a CONS. In Golden Common Lisp, I get no error. ... This is an "is an error" situation. Implementations are permitted to do whatever they want in such a situation since you are not supposed to ever cause this situation to occur. I like the Gold Hill implementation, however. It makes the processing of things like ((:gettable-instance-variables a b) :settable-instance-variables (inittable-instance-variables c d)) easier. Nothing to do with your question, but I wouldn't use ASSOC for this anyway, since using it implies to me that you're looping over possible keywords doing ASSOC rather than looping over the supplied options checking validity. This is bad for at least three reasons that come immediately to mind: * You won't detect mis-spelled or totally bogus keywords. For example, (ASSOC ':INITABLE-INSTANCE-VARIABLES your-list) will return NIL both because you didn't write it in the keyword package and because you didn't spell it right. * It will seem as if :SETTABLE-INSTANCE-VARIABLES is missing because (ASSOC ':SETTABLE-INSTANCE-VARIABLES your-list) will return NIL. I guess you can MEMBER for it later, but that seems really odd to me. * You won't correctly detect duplications. eg, ((:gettable-instance-variables a) (:gettable-instance-variables b)) which you may want to treat like: ((:gettable-instance-variables a b)) or at least you way want to warn about. Getting back to your original question, though... Is the GCLisp interpretation wrong? I can't really speak for GCLisp. Even if it does this, you'd better check their documentation carefully to see if it is documented behavior. If it's not, they'd be within their rights to change the behavior incompatibly between releases, leaving your code broken. I know that Maclisp used to have a similar behavior, but it worked by never doing an atom test before taking CAR of the alist entry. That generally worked out fine because the (CAR symbol) returned something which you couldn't make any other way and hence were not likely to be searching for. (It wouldn't surprise me to find that (ASSOC (CAR 'A) '(A)) => A in compiled Maclisp.) Anyway, CL could surely not tolerate an interpretation that allowed blind CAR'ing into symbols. CL implementations represent symbols in lots of different ways, and some of them might have interesting user-accessible objects in the slot that CAR would look in, so asking ASSOC to ignore atoms would mean putting an explicit atom check in the ASSOC inner loop, which might be very slow in some implementations. Also, efficiency aside, there's an error-checking argument. Even if we made atoms in an alist be legal, that wouldn't mean that every time an atom occurred in an alist it was there intentionally. Ill-formed alists are easy to construct. If we made it legal to have atoms at toplevel in an alist, an interesting class of program bugs that could have been detected would not be detectable because we could not tell whether the atom was there by design or by accident. In fact, entry to the debugger is not always bad. The KCL and Zetalisp versions are doing you a favor by flagging a buggy situation in your code; GCLisp is apparently not doing you that favor. If so, aside from RPLACD problems, wouldn't the GCLisp be slightly more useful? I doubt any claimed usefulness would be worth the price in lost efficiency and error checking. By the way, there are no RPLACD problems. (ASSOC 'B '((A 3) B (C 4))) returns NIL, but so does (ASSOC 'B '((A 3) (C 4))) You must always either do an ATOM check on the result of an ASSOC or know absolutely for sure that the thing you're looking for is going to be in the list before you do the RPLACD. Any RPLACD problem you're alluding to was either already present before you brought up this issue or was just imagined.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 6 Jul 87 21:56:29 EDT Received: from SUMEX-AIM.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 6 Jul 87 18:38:11 PDT Date: Mon, 6 Jul 87 18:35:28 PDT From: Hiroshi "Gitchang" Okuno Subject: Re: Flavors for KCL To: krall%pp.mcc.com%MCC.COM@SUMEX-AIM.STANFORD.EDU cc: common-lisp@SAIL.STANFORD.EDU In-Reply-To: <8707011334.AA29297@pp.mcc.com> Organization: Knowledge Systems Laboratory Group: Heuristic Programming Project Project: Advanced Architectures Project Address: 701 Welch Road, Building C, Palo Alto, CA 94304-1703 Phone: +1 (415)725-4854 Message-ID: <12316328931.47.OKUNO@SUMEX-AIM.STANFORD.EDU> Mr. Hagiya, one of the implementors of KCL ported the Flavors system to KCL. This Flavors was originally written in Franz Lisp by Franz Inc. Please contact him if you are interested. His E-mail address is hagiya%kurims.kurims.kyoto-u.junet%japan.csnet@relay.cs.net - Gitchang - -------  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 6 Jul 87 12:58:12 EDT Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 6 Jul 87 09:37:34 PDT Received: from MCC.COM by SU-SCORE.ARPA with TCP; Mon 6 Jul 87 09:32:56-PDT Received: from pp.mcc.com by MCC.COM with TCP; Mon 6 Jul 87 11:36:45-CDT Posted-Date: Monday, 6 July 1987, 11:34-CDT Message-Id: <8707061637.AA02959@pp.mcc.com> Received: from amber.pp.mcc.com by pp.mcc.com (4.12/KA70505) id AA02959; Mon, 6 Jul 87 11:37:16 cdt Date: Monday, 6 July 1987, 11:34-CDT From: Sender: krall%pp.mcc.com@mcc.com Subject: Atoms in association lists To: common-lisp@sail.stanford.edu I am not sure if this is just another interpretation or (more likely) a bug: I write (setq alist '((a . 1) b (c . 3))) then try (assoc 'c alist) In Kyoto Common Lisp and in ZetaLisp, I get an error since the second element of alist is not a CONS. In Golden Common Lisp, I get no error. In fact (assoc 'b alist) ==> nil I like the Gold Hill implementation, however. It makes the processing of things like ((:gettable-instance-variables a b) :settable-instance-variables (inittable-instance-variables c d)) easier. Is the GCLisp interpretation wrong? If so, aside from RPLACD problems, wouldn't the GCLisp be slightly more useful? -Ed Krall Parallel Processing Program Microelectronics and Computer Technology Corporation 3500 West Balcones Center Drive Austin, Texas 78759 (512) 338-3406 ARPA: krall@mcc.com UUCP: {ihnp4,seismo,ctvax}!ut-sally!im4u!milano!mcc-pp!krall  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 2 Jul 87 20:12:48 EDT Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 2 Jul 87 16:51:47 PDT Received: from LIVE-OAK.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 2 Jul 87 19:42-EDT Received: from PALLADIAN-JASPER.DialNet.Symbolics.COM by LIVE-OAK.LCS.MIT.EDU.ARPA via DIAL with SMTP id 50147; 2 Jul 87 19:35:44-EDT Received: from CHUGACH.Palladian.COM by JASPER.Palladian.COM via INTERNET with SMTP id 4262; 2 Jul 87 18:37:44-EDT Date: Thu, 2 Jul 87 18:33 EDT From: Subject: Loop Macro (after Zetalisp, Franz, etc.) To: Marie Bienkowski , common-lisp@sail.stanford.edu In-Reply-To: <8707021225.AA12487@flash.bellcore.com> Message-ID: <"870702183327.7.jeff@JASPER"@CHUGACH.Palladian.COM> Reply-To: jeff%JASPER@LIVE-OAK.LCS.MIT.EDU Date: Thu, 2 Jul 87 08:25:11 edt From: mab@flash.bellcore.com (Marie Bienkowski) Has anyone ported the wonderful loop macro provided e.g., with Symbolics Zetalisp, into regular Common Lisp (most particularly, Lucid Common Lisp). Even a port into another Common Lisp would be helpful. Thanks in advance Marie Read below. This is an exerpt from our local copy of the file which the exerpt describes. We use this with Lucid Common Lisp. BTW, the file is about 58K bytes. jeff ;;;; LOOP Iteration Macro ;;; This is the "officially sanctioned" version of LOOP for running in ;;; Common Lisp. It is a conversion of LOOP 829, which is fairly close to ;;; that released with Symbolics Release 6.1 (803). This conversion was ;;; made by Glenn Burke (one of the original author/maintainers); the ;;; work was performed at Palladian Software, in Cambridge MA, April 1986. ;;; ;;; The current version of this file will be maintained at MIT, available ;;; for anonymous FTP on MC.LCS.MIT.EDU from the file "LSB1;CLLOOP >". This ;;; location will no doubt change sometime in the future. [NB. It appears to have been moved to AI.AI.MIT.EDU in "GSB;CLLOOP >" -jeff] ;;; ;;; This file, like the LOOP it is derived from, has unrestricted ;;; distribution -- anyone may take it and use it. But for the sake of ;;; consistency, bug reporting, compatibility, and users' sanity, PLEASE ;;; PLEASE PLEASE don't go overboard with fixes or changes. Remember that ;;; this version is supposed to be compatible with the Maclisp/Zetalisp/NIL ;;; LOOP; it is NOT intended to be "different" or "better" or "redesigned". ;;; Report bugs and propose fixes to BUG-LOOP@MC.LCS.MIT.EDU; ;;; announcements about LOOP will be made to the mailing list ;;; INFO-LOOP@MC.LCS.MIT.EDU. Mail concerning those lists (such as requests ;;; to be added) should be sent to the BUG-LOOP-REQUEST and ;;; INFO-LOOP-REQUEST lists respectively. Note the Change History page ;;; below... ;;; ;;; LOOP documentation is still probably available from the MIT Laboratory ;;; for Computer Science publications office: ;;; LCS Publications ;;; 545 Technology Square ;;; Cambridge, MA 02139 ;;; It is Technical Memo 169, "LOOP Iteration Macro", and is very old. The ;;; most up-to-date documentation on this version of LOOP is that in the NIL ;;; Reference Manual (TR-311 from LCS Publications); while you wouldn't ;;; want to get that (it costs nearly $15) just for LOOP documentation, ;;; those with access to a NIL manual might photocopy the chapter on LOOP. ;;; That revised documentation can be reissued as a revised technical memo ;;; if there is sufficient demand.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 2 Jul 87 20:05:22 EDT Received: from EDDIE.MIT.EDU by SAIL.STANFORD.EDU with TCP; 2 Jul 87 16:43:26 PDT Received: by EDDIE.MIT.EDU with UUCP with smail2.3 with sendmail-5.31/4.7 id ; Thu, 2 Jul 87 19:41:57 EDT Received: by primerd.prime.com (3.2/SMI-3.0DEV3/smail) id AA12485; Thu, 2 Jul 87 13:54:14 EDT Message-Id: <8707021754.AA12485@primerd.prime.com> Received: (from user DOUG) by ENX.Prime.PDN; 02 Jul 87 13:06:38 EST To: COMMON-LISP@SAIL.STANFORD.EDU From: primerd!DOUG@ENX.Prime.PDN Date: 02 Jul 87 13:06:38 EST To: Commonlisp (common-lisp@sail.stanford.edu) From: Doug Rand (DOUG@ENX.PRIME.COM) Date: 02 Jul 87 1:04 PM Subject: Re: Location of defsys.l? They are on defsys.lsp[com,lsp] and defsys.doc[com,lsp] on SAIL. To add to the meager documentation (I'll eventually fix this in defsys.doc): :needed-systems lets a system require other systems. So to use system A you would like systems B and C to be loaded you can specify this with :needed-systems (B C). This means that B and C will be loaded before A. It also means that when you compile-system A then B and C with be recompiled (as if you typed (compile-system B) (compile-system C) before (compile-system A)). This behavior is controlled by the :include-components keyword arg to load-system and compile-system. The obscure sentence about :recompile-on means that the module with be recompiled if the date-time-modified (DTM) of any of the named, updated modules is newer then the module's DTM. This is a common concept in utilities like UNIX MAKE and I'm suprised that this is a new concept for LISPer's. Cheers, Doug  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 2 Jul 87 18:34:54 EDT Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 2 Jul 87 15:10:39 PDT Received: from ubaldo by Think.COM via CHAOS; Thu, 2 Jul 87 18:11:50 EDT Date: Thu, 2 Jul 87 18:09 EDT From: Barry Margolin Subject: Questions about (function eq) To: Michael Greenberg Cc: common-lisp@sail.stanford.edu In-Reply-To: <8707022101.AA29766@Think.COM> Message-Id: <870702180943.1.BARMAR@UBALDO.THINK.COM> Date: Wed, 1 Jul 87 14:25 EDT From: Michael Greenberg What are the semantic differences? Is there a difference between (defun xyz () (flet ((eq (a b) (bar a b))) (pushnew 'foo bar :test #'eq))) and (defun xyz () (flet ((eq (a b) (bar a b))) (pushnew 'foo bar :test 'eq))) Yes there is. In the first case, PUSHNEW will call your local function EQ, while in the second case it will call the global one. The second one is equivalent to (defun xyz () (flet ((eq (a b) (bar a b))) (pushnew 'foo bar :test (symbol-function 'eq)))) FLET creates a lexical binding, it doesn't do anything to the symbol's function cell; therefore, if PUSHNEW is given the symbol, all it can do is call SYMBOL-FUNCTION to extract its global function binding. What are the stylistic differences? Since there are semantic differences, I don't think the stylistic differences matter. Style choices don't come into play unless you're choosing between equivalent operations. Which of the following macro definitions is preferred? Why? (defmacro foo (fn) (if (eq fn 'eq) '(expansion-1 ...) '(expansion-2 ...))) (defmacro foo (fn) (if (eq fn #'eq) '(expansion-1 ...) '(expansion-2 ...))) (defmacro foo (fn) (if (or (eq fn #'eq) (eq fn 'eq)) '(expansion-1 ...) '(expansion-2 ...))) I don't think any of them are even right. You presumably meant the conditional to be one of (equal fn ''eq) (equal fn '#'eq) or (or (equal fn '#'eq) (equal fn ''eq)) because macros are passed the data structure from the form, not the evaluation (you have to use EQUAL because they are lists). I'm assuming that FOO is intended to be called as (FOO 'EQ) or (FOO #'EQ) If you want to allow both forms, then my third conditional would be the one to use. If you want it to be callable as (FOO EQ), then your (not my) first form would be correct. I don't think this will do the right thing in the face of locally-shadowed functions, though. The conditional is only looking at the list structure, i.e. it is checking whether its argument is the list whose first element is either the symbol FUNCTION or the symbol QUOTE and whose second element is the symbol EQ. In the #'EQ case, the macro has no way of evaluating this in the appropriate lexical environment in order to check whether it refers to the "real" EQ function. If the expansion contains ,FN or #'EQ, though, it will refer to a local EQ function if there is one, because macro expansions get processed in the caller's lexical scope. For this reason, I recommend that you not try to do this as a macro. If you do it as a function you can compare the argument against (SYMBOL-FUNCTION 'EQ), and conditionalize it at that time. If you really need the performance gain that the macro provides, you should clearly document the fact that it assumes that #'EQ is the standard EQ. In general, macros and FLET can have some weird interactions. Every macro makes assumptions about the functional values of symbols. For example, (defmacro bar (a b) `(list (cons ,a 1) (cons ,b 2))) makes an assumption about LIST. If one then did (defun quux (c) (flet ((list (thing) (car thing))) (bar c (1+ c)))) an error would be reported because the local function LIST was being called with the wrong number of arguments, because this is equivalent to (defun quux (c) (flet ((list (thing) (car thing))) (list (cons c '1) (cons (1+ c) '2)))) Macros, as they are currently defined, don't obey lexical scoping, because they are very simple rewrite rules. There has been some research on new ways to define macro expansion that don't have these problems, and there is some investigation taking place in X3J13, the ANSI Common Lisp standardization committee. For now, though, that's the way it is. barmar  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 2 Jul 87 17:17:42 EDT Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 2 Jul 87 13:55:02 PDT Received: from relay2.cs.net by RELAY.CS.NET id au00953; 2 Jul 87 11:47 EDT Received: from cs.umass.edu by RELAY.CS.NET id ay00482; 2 Jul 87 1:08 EDT Date: Wed, 1 Jul 87 14:25 EDT From: Michael Greenberg Subject: Questions about (function eq) To: common-lisp@SAIL.STANFORD.EDU X-VMS-To: IN%"common-lisp@sail.stanford.edu" I have several questions concerning the difference between (pushnew 'foo bar :test #'eq) and (pushnew 'foo bar :test 'eq) What are the semantic differences? Is there a difference between (defun xyz () (flet ((eq (a b) (bar a b))) (pushnew 'foo bar :test #'eq))) and (defun xyz () (flet ((eq (a b) (bar a b))) (pushnew 'foo bar :test 'eq))) What are the stylistic differences? Which of the following macro definitions is preferred? Why? (defmacro foo (fn) (if (eq fn 'eq) '(expansion-1 ...) '(expansion-2 ...))) (defmacro foo (fn) (if (eq fn #'eq) '(expansion-1 ...) '(expansion-2 ...))) (defmacro foo (fn) (if (or (eq fn #'eq) (eq fn 'eq)) '(expansion-1 ...) '(expansion-2 ...))) Michael Greenberg greenberg@cs.umass.edu  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 2 Jul 87 12:31:26 EDT Received: from HPLABS.HP.COM by SAIL.STANFORD.EDU with TCP; 2 Jul 87 09:11:01 PDT Received: from hplabsc by hplabs.HP.COM with TCP ; Thu, 2 Jul 87 09:10:13 pdt Received: by hplabsc ; Thu, 2 Jul 87 08:11:34 pdt Date: Thu, 2 Jul 87 08:11:34 pdt From: Jim Kempf Message-Id: <8707021511.AA22363@hplabsc> To: common-lisp@sail.stanford.edu Subject: Location of defsys.l? Some time ago, someone posted the location of a public domain defsys.l on SAIL, which I neglected to save. Could someone who has it either mail it or send me the location? I would be eternally grateful. Jim Kempf kempf@hplabs.hp.com  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 2 Jul 87 11:31:49 EDT Received: from FLASH.BELLCORE.COM by SAIL.STANFORD.EDU with TCP; 2 Jul 87 08:11:57 PDT Received: by flash.bellcore.com (4.12/4.7) id AA12487; Thu, 2 Jul 87 08:25:11 edt Date: Thu, 2 Jul 87 08:25:11 edt From: mab@flash.bellcore.com (Marie Bienkowski) Message-Id: <8707021225.AA12487@flash.bellcore.com> To: common-lisp@sail.stanford.edu Subject: Loop Macro (after Zetalisp, Franz, etc.) Has anyone ported the wonderful loop macro provided e.g., with Symbolics Zetalisp, into regular Common Lisp (most particularly, Lucid Common Lisp). Even a port into another Common Lisp would be helpful. Thanks in advance Marie  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 2 Jul 87 09:06:17 EDT Received: from PRINCETON.EDU by SAIL.STANFORD.EDU with TCP; 2 Jul 87 05:34:18 PDT Received: by Princeton.EDU (5.51/1.29) id AA08478; Thu, 2 Jul 87 08:32:54 EDT Received: by mind.Princeton.EDU (4.12/1.52) id AA06027; Thu, 2 Jul 87 08:36:08 edt Date: Thu, 2 Jul 87 08:36:08 edt From: Marie Bienkowski Message-Id: <8707021236.AA06027@mind.Princeton.EDU> To: common-lisp@sail.stanford.edu Subject: Loop Macro (after Zetalisp, franz, etc.) Has anyone ported the powerful loop macro provided with, e.g., the Symbolics Zetalisp, into regular common lisp. I am particularly interested in a version for Lucid Common Lisp. Thanks, Marie (mab@mind.princeton.edu)  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 1 Jul 87 11:14:44 EDT Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 1 Jul 87 07:42:33 PDT Received: from MCC.COM by SU-SCORE.ARPA with TCP; Wed 1 Jul 87 07:37:25-PDT Received: from pp.mcc.com by MCC.COM with TCP; Wed 1 Jul 87 09:28:21-CDT Posted-Date: Wednesday, 1 July 1987, 08:32-CDT Message-Id: <8707011334.AA29297@pp.mcc.com> Received: from amber.pp.mcc.com by pp.mcc.com (4.12/KA70505) id AA29297; Wed, 1 Jul 87 08:34:16 cdt Date: Wednesday, 1 July 1987, 08:32-CDT From: Sender: krall%pp.mcc.com@mcc.com Subject: Flavors for KCL To: common-lisp@SAIL.STANFORD.EDU Does anyone have access to a machine independent Flavors or a Flavors for Kyoto Common Lisp. We have some software here written for Symbolics in Common Lisp with Flavors and would like to port it to KCL will minimal change. -Ed Krall Parallel Processing Program Microelectronics and Computer Technology Corporation 3500 West Balcones Center Drive Austin, Texas 78759 (512) 338-3406 ARPA: krall@mcc.com UUCP: {ihnp4,seismo,ctvax}!ut-sally!im4u!milano!mcc-pp!krall  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 30 Jun 87 13:51:17 EDT Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 30 Jun 87 10:21:03 PDT Received: from relay2.cs.net by RELAY.CS.NET id af06830; 30 Jun 87 12:11 EDT Received: from sp.unisys.com by RELAY.CS.NET id ac20556; 30 Jun 87 12:05 EDT Date: Tue, 30 Jun 87 11:05 CDT From: Jim Hassett To: common-lisp@SAIL.STANFORD.EDU Subject: 2 namespaces & a complement to #' notation X-VMS-To: IN%"common-lisp@SAIL.STANFORD.EDU" The recent article by Kers (Christopher Dollin) concerning the two-namespace issue and Pop gives me an excuse for bringing up a related item. I'll be surprised if this idea has not been discussed before, but I've only been on this list for a year, so I haven't seen it. Like Kers, I recently read "Issues of Separation in Function Cells and Value Cells" by Gabriel & Pitman. I have been unable to resolve my personal preferences on this issue. I like the elegance and notational simplicity of a single namespace, but I also find it convenient that I needn't worry much about selecting names for lexical variables in Common Lisp. I might find a single namespace easier to accept were it not for a mere handful of very useful functions whose names happen to be very useful variable names (e.g., COUNT, LIST, STRING, and GET-SETF-METHOD-MULTIPLE-VALUE :-). But perhaps it is too late to change Common Lisp to a single-namespace Lisp dialect. If so, we should look for ways to mitigate the problems of having two namespaces. One problem is the awkwardness of having to use FUNCALL to invoke a function which is the (ordinary) value of a variable or other form. This is illustrated by Gabriel & Pitman with definitions of the Y operator (or paradoxical combinator) of lambda calculus. For a language with a single namespace, the definition given is (defun y (f) ((lambda (g) (lambda (h) ((f (g g)) h))) (lambda (g) (lambda (h) ((f (g g)) h))))) For a language with separate function and value namespaces, the definition is more complex: (defun y (f) ((lambda (g) #'(lambda (h) (funcall (funcall f (funcall g g)) h))) #'(lambda (g) #'(lambda (h) (funcall (funcall f (funcall g g)) h))))) (Note: My copy of the Gabriel & Pitman paper omits the second #', but it is needed to prevent attempted evaluation of the lambda expression.) To simplify the notation of this definition, we could alter the evaluation of forms to allow the definition a macro character, perhaps #@, to complement the #' syntax. A form preceded by #@ in the function position would have its ordinary value used as the function to be applied. The definition of Y would then be shorter, if not prettier: (defun y (f) ((lambda (g) #'(lambda (h) (#@(#@f (#@g g)) h))) #'(lambda (g) #'(lambda (h) (#@(#@f (#@g g)) h))))) The effect of this change can be obtained in Common Lisp by the following inelegant technique. Define ORDINARY-FUNCTION-VALUE-READER to convert a #@ form into a lambda-expression which applies the value of the form to its arguments, and install this function to handle the #@ macro character: (defun ordinary-function-value-reader (stream subchar arg) (declare (ignore subchar arg)) `(lambda (&rest args) (apply ,(read stream t nil t) args))) (set-dispatch-macro-character #\# #\@ #'ordinary-function-value-reader) This works, but a better implementation would allow some new expression such as (ordinary-value
) to be used in the function position, analogous to the current use of lambda expressions. Has this approach been considered? Is it just too ugly to get much support? Or am I missing a serious problem? Jim Hassett  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 30 Jun 87 01:36:29 EDT Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 29 Jun 87 22:09:48 PDT Received: from relay2.cs.net by RELAY.CS.NET id aa02113; 30 Jun 87 0:04 EDT Received: from utokyo-relay by RELAY.CS.NET id aj16893; 29 Jun 87 23:53 EDT Received: by ccut.cc.u-tokyo.junet (5.51/6.2.9Junet) id AA14909; Mon, 29 Jun 87 13:26:26 JST Received: by tansei.cc.u-tokyo.junet (4.12/6.2Junet) id AA04557; Mon, 29 Jun 87 13:25:54+0900 Date: Mon, 29 Jun 87 13:25:54+0900 From: Masayuki Ida Return-Path: Message-Id: <8706290425.AA04557@tansei.cc.u-tokyo.junet> To: baggins@ibm.com, ida%tansei.cc.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET Subject: Re: A multi-byte character extension proposal Cc: common-lisp@SAIL.STANFORD.EDU I got a mail from nippon UNIVAC person as for the matter. He is one of the contributors of Kanji WG. Here is his comment. (I am just acting as a junction between japanese net and US.) If someone is interested in his reply, I will forward mails to him (since direct mailing is not premitted.) Masayuki Ida ============================ his comment ================================= Date: Fri, 26 Jun 87 16:46:31 JST From: tshimizu@xxx.yyy.junet (Toshihiko Shimizu) To: ida@u-tokyo.junet Subject: Our comments to Thom Linden's q We have reviewed the JEIDA proposal and Mr. Thom Linden's questions. We have been making efforts for an implementation of the extention of Common Lisp for Japanese character processing on Explorer lisp machine. Our efforts have been made in pararell to the JEIDA Kanji WG activity, and our specifications had been nearly fixed before the final proposal was issued. But our implementation almost conforms to the proposal except the point left being implementation dependent. We think it is important to answer Linden's question according to our implementation for your information. First we have to give an overview of our implementation. Our primary goal is completely the same as the JEIDA proposal that we want to use Japanese characters "as almost the same as" characters already available. In Explorer, an extended ASCII character set called Lisp Machine character set has been used. We have added a new character set for Japanese characters called JIS character set which is defined to be the standard in Japan. This set has double-byte character code. Explorer has the capability to handle strings whose elements are 2 byte long. This string type can be considered to be a subtype of type string. Then we use this type of strings to hold double-byte characters. Apparently these strings are able to hold single-byte characters as mixture. This implementation is considered almost the same as the scheme using "internal-thin-string" type described in the proposal. We are now preparing a paper on this implementation for WGSYM IPSJ, September 1987. Please refer it for further detailes. The followings are our answers to Linden's questions; 1) All Common Lisp standard characters are included in the standared JIS character set, but they have different character code from the ones in ASCII character set. This situation is almost likely in case of usual file systems which allow JIS character set. Then we think these difference has to be preserved when files are read into Lisp as a sequance of characters. After that we can think of parsing, discussed later. 2) Above interpretation seems to lead to a contradiction against the description in CLtL (p.233). We think that two distinct character objects may have the same print glyphs, but in this case they shold have the same syntactic properties. Indeed they are different characters but somtimes we doubt. Because they may be printed using various fonts and sometimes these printed figures are very similar. 3), 4) Actually we have both single-byte and double-byte representations for some characters. But we never try to map them into the one except when the Lisp reader parses them. This is because these difference have to be preserved as described above. And we think that once these two representation is mapped into the one, there are no reasonable way to make inverse mapping. This is the crucial point for applications on Lisp to interact with other conventional applications. Suppose we have a text processing application on Lisp and we want use it against a text file in which single-byte and double-byte characters are containted in mixture. It is not desirable if all single-byte characters in the source text file are mapped into double-byte ones. 5) Now our stand point is that a double-byte character can be a standard character within the parsing context only if its printed glyph is regarded as a standard character. As a result, there must be some test for this correspondence. Acturally we have this "equivalence test". Both the single-byte character set and the double-byte character set include standard characters. If a character from the single-byte character set which is a standard character, there is a corresponding character in the double-byte character set. And these two characters pass the "equivalence test", but they never be EQ. However this point may lead to a contradiction to the description in CLtL (p.20). 5a) Then, our implementation recognizes some double-byte characters as standard characters. For example, STANDARD-CHAR-P returns T against #\a in the double-byte character set. 5b) Our implementation takes option 3 in the proposal. That is, we don't distinguish single-byte and double-byte versions of symbols, but we preserve these difference within strings. For example, two version of a symbol 'LAMBDA are considered to be EQ, but two versions of a string "LAMBDA" are distinguished, or not EQUAL, but they pass the test described above. Further, there may be mixed versions of a string "LAMBDA". 5c) We might agree Linden's point if we didn't think about strings. Actually our primary understanding was that there was no need to distinguish such a difference for the sole purpose of Common Lisp. But there is a certain requirement for interaction with conventional applications in which distinction between single-byte and double-byte version is significant. Then we decided that the distinction is not neccessary for symbols which plays an important role in programs, whereas it is neccessary for strings which are primarily used for interaction with outer world, such as files, displays, and networks. 5d) As we defined that a double-byte character may be a standard character, it is consistent to define such a character to satisfy ALPHA-CHAR-P. Then both version of a character 'a' satisfy ALPHA-CHAR-P, ALPHANUMERICP and LOWER-CASE-P. 5e) We think that these description sholud be eraborated, but the JEIDA committee has decided that these should be left implementation dependent. 6) In our implementation, such syntactic attributes relevant to parsing and format controlling are only defined for standard characters. That is, if a character is a double-byte character and also a standared character at the same time, it may have non-constituent syntax. Indeed it has the same syntax attribute as the single-byte version of it. For example, a string "123" in double-byte version is also parsed into a number 123. Otherwise its syntax cannot be other than constituent. 7) We think it is not neccessary to have such a large readtable which covers all characters of type string-char. We only have a readtable for single-byte characters and uses the "equivalent" mapping for the double-byte version of these characters. And the rest of double-byte characters are defined to have constituent syntax. 8) In our implementation, MAKE-DISPATCH-MACRO-CHARACTER against a non-standard, double-byte character is an error. ------------- end of the message -----------  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 29 Jun 87 13:50:29 EDT Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 29 Jun 87 10:31:08 PDT Received: from XX.LCS.MIT.EDU by navajo.stanford.edu with TCP; Mon, 29 Jun 87 10:27:47 PDT Received: from LIVE-OAK.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 29 Jun 87 13:28-EDT Received: from PALLADIAN-JASPER.DialNet.Symbolics.COM by LIVE-OAK.LCS.MIT.EDU.ARPA via DIAL with SMTP id 49628; 29 Jun 87 13:30:24-EDT Received: from WHITBY.Palladian.COM by JASPER.Palladian.COM via INTERNET with SMTP id 3998; 29 Jun 87 13:00:20-EDT Date: Mon, 29 Jun 87 12:56 EDT From: Don Morrison Subject: print question To: edsel!bhopal!jonl@navajo.stanford.edu Cc: navajo!sandra%orion%cs.utah.edu@navajo.stanford.edu, navajo!common-lisp%sail.stanford.edu@navajo.stanford.edu In-Reply-To: <8706281227.AA00660@bhopal.edsel.uucp> Message-Id: <870629125637.0.DFM@WHITBY.PALLADIAN.COM> Reply-To: Don Morrison Date: Sun, 28 Jun 87 05:27:40 PDT From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White) Although the MacLisp printer took care to insert "newline"'s ocasionally, I finally came to believe that PRINT was the wrong place to handle this. I would think that it does need to be handled higher up than character I/O. I would expect newlines to replace spaces between tokens, but not spaces embedded within tokens, such as strings; otherwise you can't parse what you print. Or am I missing something?  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 29 Jun 87 10:24:40 EDT Received: from NADC.ARPA by SAIL.STANFORD.EDU with TCP; 29 Jun 87 07:06:51 PDT Received: by NADC.ARPA (5.51/1.0 ) id AA27336; Mon, 29 Jun 87 10:06:30 EDT Date: Mon, 29 Jun 87 10:06:30 EDT From: dml@nadc.arpa (D. Loewenstern) Message-Id: <8706291406.AA27336@NADC.ARPA> To: VERACSD@a.isi.edu, common-lisp@sail.stanford.edu Subject: Re: MODIFYF Cc: veracsd@a.isi.edu In reference to Bob Sasseen's idea of a Modifyf macro: (Modifyf (CAR x) + 3) <-> (SETF (CAR x) (+ (CAR x) 3)) We have implemented a different, but similar macro: (DEFMACRO Self (place function-or-form) ...) Self can take a place and a single function to modify the place with: (Self object CDDDR) <-> (SETF object (CDDDR object)) If function-or-form is a form, not the name of a function, then Self replaces the symbol :self with the place: (Self (Structure-Thing struc) (DELETE NIL :self)) <-> (SETF (Structure-Thing struc) (DELETE NIL (Structure-Thing struc))) If place is of type (Function1 (Function2 ...)), Self takes care that (Function2 ...) is only evaled once: (Self (CAR (SECOND x)) 1+) <-> (LET ((#:|(second x)| (SECOND x))) (SETF (CAR #:|(second x)|) (1+ (CAR #:|(second x)|)))) I think this is more generally useful than MODIFYF because the modified field need not be the first argument of the modifier. I don't feel that Self, Modifyf, or any similar modify macro should be made part of CL until questions such as robustness vs. readability can be resolved. David Loewenstern Naval Air Development Center code 7013 Warminster, PA 18974-5000  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 28 Jun 87 21:19:39 EDT Received: from SCRC-YUKON.ARPA by SAIL.STANFORD.EDU with TCP; 28 Jun 87 18:00:58 PDT Received: from WHITE-BIRD.SCRC.Symbolics.COM by YUKON.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 231472; Sun 28-Jun-87 20:59:54 EDT Date: Sun, 28 Jun 87 20:59 EDT From: Robert W. Kerns Subject: Tracing locally defined functions To: "Dan Corkill A356 LGRC (413)545-0156" cc: Common-Lisp@SAIL.STANFORD.EDU In-Reply-To: The message of 26 Jun 87 16:18 EDT from "Dan Corkill A356 LGRC (413)545-0156" Message-ID: <870628205952.4.RWK@WHITE-BIRD.SCRC.Symbolics.COM> Date: Fri, 26 Jun 87 16:18 EDT From: "Dan Corkill A356 LGRC (413)545-0156" A better solution would have implementers augment TRACE with the ability to trace locally defined functions that are defined within a function: (TRACE factorial :LOCALLY-DEFINED-FUNCTIONS t) where TRACE would be smart enough to also trace any functions defined by FLET and LABELS. Specific functions might also be an option: (TRACE factorial :LOCALLY-DEFINED-FUNCTIONS '(factorial-helper)). Does anyone's implementation of TRACE handle LABELS or FLET? -- Dan Corkill (trace 'foo) would have to refer to the global value. One simple technique for tracing from inside a program would be to a (TRACEF place). The real problem is that Common Lisp thinks that all functions can be named with symbols. This just isn't the case. Function names are inherently structured objects. Our function specs allow us to trace not just internal functions, but functions living on property lists, in flavor method tables, in type descriptor objects, etc. etc. In general, they are either a symbol (i.e. the trivial CL usage), or ( . ) For example, (flavor:method open-the-door door) refers to the function which implements the OPEN-THE-DOOR operation for a DOOR flavor. Another benefit is that the user doesn't have to know where it's stored or how to get at it. Unfortunately, our :INTERNAL function-spec type is a little awkward; you have to know an internal index. For anonymous lambdas, this makes sense, and the index is zero-origin, so it's not that hard to deal with, but you'd like to be able to skip the index when it's unambiguous. For example, your FACTORIAL-HELPER internal function would be known as (:INTERNAL FACTORIAL 0 FACTORIAL-HELPER) in our system. A better scheme would be: (:INTERNAL FACTORIAL FACTORIAL-HELPER 0), where the 0 is optional, so long as there's just one FACTORIAL-HELPER local function. I think we proposed this years ago, but nobody saw the need back then. Perhaps now there's enough experience with the language to let us adopt something like this?  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 28 Jun 87 15:06:21 EDT Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 28 Jun 87 11:46:38 PDT Received: by navajo.stanford.edu; Sun, 28 Jun 87 11:43:55 PDT Received: from bhopal.edsel.uucp by edsel.uucp (3.2/SMI-2.0) id AA01509; Sun, 28 Jun 87 05:24:48 PDT Received: by bhopal.edsel.uucp (3.2/SMI-3.2) id AA00660; Sun, 28 Jun 87 05:27:40 PDT Date: Sun, 28 Jun 87 05:27:40 PDT From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White) Message-Id: <8706281227.AA00660@bhopal.edsel.uucp> To: navajo!sandra%orion%cs.utah.edu@navajo.stanford.edu Cc: navajo!common-lisp%sail.stanford.edu@navajo.stanford.edu In-Reply-To: Sandra J Loosemore's message of Sat, 27 Jun 87 14:38:47 MDT <8706272038.AA23897@orion.utah.edu> Subject: print question Although the MacLisp printer took care to insert "newline"'s ocasionally, I finally came to believe that PRINT was the wrong place to handle this. We ultimately made it a per-stream property -- whether or not to break long lines -- but one thing I proposed for VAX/NIL and for Interlisp-D (which I don't think ever got implemented) was to put the line-breaking code into the stream. That is, some low-level byte-output method in a stream would be paying attention so such matters of whether or not to substitute a "newline" for an ocasional "space", in order to limit the line length of the output [of course, you would still lose for long sequences of characters that had no spaces at all in them]. The main advantage of doing it "in the stream" is user-coded "printers" based over WRITE-CHAR or WRITE-STRING would also get the benefit. -- JonL --  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 27 Jun 87 16:56:16 EDT Received: from CS.UTAH.EDU by SAIL.STANFORD.EDU with TCP; 27 Jun 87 13:37:00 PDT Received: by cs.utah.edu (5.54/utah-1.0) id AA24317; Sat, 27 Jun 87 14:38:55 MDT Received: by orion.utah.edu (5.54/utah-1.0-slave) id AA23897; Sat, 27 Jun 87 14:38:47 MDT Date: Sat, 27 Jun 87 14:38:47 MDT From: sandra%orion@cs.utah.edu (Sandra J Loosemore) Message-Id: <8706272038.AA23897@orion.utah.edu> Subject: print question To: common-lisp@sail.stanford.edu In the description of how to print conses on p. 368 of CLtL, the algorithm says to "print a space" between successive list elements. Is this supposed to be taken literally? I have been having some problems with large data structures printing out on a single line that's too long for other utilities (like text editors!) to handle. It is very annoying to have your application write files you can't look at. Turning *print-pretty* on does give me a file that the editor can read, but some of the data structures I'm trying to print are so deeply nested that I would really prefer not to have all that extra whitespace -- *I* can't read what it's printing. I know that some people will say it's the editor that's wedged, but I think that in some cases it would be much more user-friendly to write out a newline instead of a space when the line length exceeds 80 characters or so. In other cases (like writing to a string output stream) I probably do not want to get a newline unless I explicitly ask for one. Maybe the real solution is to add another parameter to write? Or should this be an attribute of the particular output stream? I don't have a specific proposal in mind (and I really cringe at the thought of making CL bigger!), but I thought the problem was worth mentioning.... -Sandra -------  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 27 Jun 87 02:09:43 EDT Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 26 Jun 87 22:50:12 PDT Received: from relay2.cs.net by RELAY.CS.NET id ag10427; 27 Jun 87 1:39 EDT Received: from cs.umass.edu by RELAY.CS.NET id bf00359; 27 Jun 87 1:33 EDT Date: Fri, 26 Jun 87 16:18 EDT From: "Dan Corkill A356 LGRC (413)545-0156" Subject: Tracing locally defined functions To: Common-Lisp@SAIL.STANFORD.EDU X-VMS-To: IN%"Common-Lisp@SAIL.STANFORD.EDU",CORK This is a plea for Common Lisp implementers to augment their TRACE utility to handle functions defined using FLET and (especially!) LABELS. For example, here is a recursive definition of FACTORIAL with argument checking that uses LABELS to define a recursively invoked helper function: (defun FACTORIAL (n) (check-type n (integer 0 *)) (labels ((factorial-helper (n) (cond ((zerop n) 1) (t (* n (factorial-helper (- n 1))))))) (factorial-helper n))) If I wanted to trace factorial and factorial-helper, I would at least hope that I could add the following expression to the function definition: (defun FACTORIAL (n) (check-type n (integer 0 *)) (labels ((factorial-helper (n) (cond ((zerop n) 1) (t (* n (factorial-helper (- n 1))))))) (when (member 'factorial (trace) :TEST #'eq) ; <--- (trace 'factorial-helper)) ; <--- (factorial-helper n))) The trace of factorial-helper is initialized within the scope of the LABELS special form, conditionally based on the trace status of the enclosing factorial function. Once I've completed debugging, the clause would be removed. I believe this ``patch'' is slightly better than avoiding LABELS until all debugging is complete, but the technique is quite ugly. A better solution would have implementers augment TRACE with the ability to trace locally defined functions that are defined within a function: (TRACE factorial :LOCALLY-DEFINED-FUNCTIONS t) where TRACE would be smart enough to also trace any functions defined by FLET and LABELS. Specific functions might also be an option: (TRACE factorial :LOCALLY-DEFINED-FUNCTIONS '(factorial-helper)). One means of implementing such an extension to TRACE would have the LABELS and FLET special forms check at initialization time whether the functions they are defining are to be traced. (I would be satisifed if this check was only performed for interpreted code.) When factorial is encapsulated, the information that factorial-helper should also be traced when it is defined would be stored for later use by LABELS. LABELS would create the local function and also encapsulate it for TRACE. Then the body of the LABELS would be evaluated. Without the ability to trace functions defined by FLET and LABELS, these forms loose much of their attractiveness--especially to novice programmers. I consider the definition of factorial using LABELS to be a good example of Common Lisp programming style, but without the ability to trace its behavior it is difficult to recommend such programming style to beginners. Does anyone's implementation of TRACE handle LABELS or FLET? -- Dan Corkill  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 26 Jun 87 22:33:48 EDT Received: from A.ISI.EDU by SAIL.STANFORD.EDU with TCP; 26 Jun 87 19:11:13 PDT Date: 26 Jun 1987 22:10-EDT Sender: VERACSD@A.ISI.EDU Subject: MODIFYF From: VERACSD@A.ISI.EDU To: common-lisp@SAIL.STANFORD.EDU Cc: veracsd@A.ISI.EDU Message-ID: <[A.ISI.EDU]26-Jun-87 22:10:38.VERACSD> Was the following ever considered for Common Lisp? After SETF, the most logical and general generalized-variable function (macro) to have next would clearly seem to be something I call MODIFYF. (MODIFYF function place . args) would be approximately equivalent to (SETF place (function place . args)) except of course for subforms of place being evaluated only once. (There are a couple of issues, such as 1) unless you prefer swapping the order of args in MODIFYF, function being evaluated before place) 2) evaluating function and going to (funcall function place . args) instead, thus allowing lambdas and suchlike.) This is reminiscent of, among other things, the op= statements of the C language, where op includes +, -, etc. Many (if not all) "modify macros" would be easily defined in terms of it. E.g., (defmacro INCF (place &optional (increment 1)) (MODIFYF + place increment)) When called directly in user code, MODIFYF stands in approximately the same relation to DEFINE-MODIFY-MACRO as LAMBDA-expressions stand to DEFUN. Bob Sasseen veracsd@a.isi.edu  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 25 Jun 87 19:51:10 EDT Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 25 Jun 87 16:25:48 PDT Received: from KRYPTON.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 182534; Thu 25-Jun-87 19:10:35 EDT Date: Thu, 25 Jun 87 19:10 EDT From: Robert A. Cassels Subject: Format ~E nit -- language lawyer sought To: Common-Lisp@SAIL.Stanford.EDU Message-ID: <870625191023.3.CASSELS@KRYPTON.SCRC.Symbolics.COM> What should be the result of (format nil "~E" 1.0)? A. "1.0e+0" B. "1.0e0" C. All of the above D. None of the above The top of page 393 says, "Next, either a plus or a minus sign is printed, followed by e digits ... [decimal exponent]" Later on page 393 we see, "If all of w, d, and e are omitted, then the effect is ... [like prin1]. Page 366 [presumably where prin1 is defined] doesn't explicitly say that the plus sign is omitted from the exponent, but all the examples (and usual practice) indicate that. The first reference implies that A is correct, the third reference implies that B is correct. The second reference implies that A and B are the same.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 25 Jun 87 18:34:50 EDT Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 25 Jun 87 09:22:18 PDT Received: from relay2.cs.net by RELAY.CS.NET id ac04243; 25 Jun 87 11:10 EDT Received: from utokyo-relay by RELAY.CS.NET id aa19616; 25 Jun 87 11:04 EDT Received: by ccut.cc.u-tokyo.junet (5.51/6.2.9Junet) id AA24561; Thu, 25 Jun 87 23:49:44 JST Received: by tansei.cc.u-tokyo.junet (4.12/6.2Junet) id AA15608; Thu, 25 Jun 87 23:48:59+0900 Date: Thu, 25 Jun 87 23:48:59+0900 From: Masayuki Ida Return-Path: Message-Id: <8706251448.AA15608@tansei.cc.u-tokyo.junet> To: baggins@ibm.com, ida%tansei.cc.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET Subject: Re: A multi-byte character extension proposal Cc: common-lisp@SAIL.STANFORD.EDU Date: Tue, 23 Jun 87 12:54:31 PDT From: "Thomas Linden (Thom)" 1) Are characters with different codes always syntactically distinct? Yes. Can the standard character #\( have two different codes, corresponding, for example, to two different external file system representations of that character? No. (because you said 'the standard character'...) We cannot talk about the different representations on files. Some implementations may read 'similar' characters into one internal code, but others may not. 2) Does the JEIDA proposal permit two different string-chars to have the same print glyph, '(' for example, but different syntactical properties? We did not discuss about the issue related to your question, because we have no scope on the characters which has the same print glyph but different syntactical properties. There are several japanese characters which have similar glyphs. But their glyphs are not 'the same' (except for blank characters). 3) Is it allowable to map both of these sets of codes into the one, internal Lisp character code set when inputting data to Lisp, and adopt our own conventions for translating output back to single and double byte? yes. 4) An elaboration of the the previous question: Is it possible for an implementation to represent all of the standard characters internally with 2-byte codes, and to map some 2-byte character codes and some 1-byte character codes in system files onto the same set of 2-byte internal codes for the standard characters when read into Lisp? yes. 5) The English copy we saw of the proposal did not contain section 4.4. Based on our own translation from the original in Japanese, this section seems to discuss implementation issues. Since we could not make a good conclusion on the issue, the section 4.4 of the early draft injapanese was deleted. The proposal have many freedom for implementors. there seem to be two possible treatments of double byte characters. The first is the case where a double-byte character can be a standard character. The second is where a double-byte character cannot be a standard character. I think so too. 5a) Implementation dependent. 5b) Is the difference between option 1 and option 2 whether the Lisp system would recognize a single-byte version and a double-byte version of this symbol-name in the same file as referring to the same (EQ) symbol? Yes. 1. (list abc /fg " xy " ) -------------------------------- 2. (list abc /fg " xy " ) -- ---- ----- --- ---- 3. (list abc /fg " xy " ) ------------------------ ----- We tried to select one and only one selection among the above 3 'options'. But we found we cannot make decision until ISO related standardization of japanese character representation. 5c) I cannot understand what you said. I don't imagine the status like "there is a character which has a same print glyph but different code." 5d) Implementation dependent. Standard-character may be single-byte or may be multi-byte, according to the definition of the implementation. 5e) Is section 4.4 a part of the proposal to ANSI? No. If you could elaborate (in English) on the content of section 4.4, we would greatly appreciate it. Please ask IBM japan (your subsidiary) for the complex issue behind the section 4.4 of the early draft in japanese. We need more observations on other languages, file systems, operating systems and JIS character set definition refinement itself before we might make a firm guideline for the matter. 6) Correct? Your interpretation can cope with our proposal. 7) If a Lisp system supports a large character code set, need it allow every character of type string-char to have a non-constituent syntax type defined in the readtable, or is the proposal's default that only standard characters need be represented in the readtable? CLtL says (22.1.5 page 360): "every character of type string-char must be represented in the readtable." The members felt as we extended the definition of string-char to include japanese characters, as the results of a natual interpretation of CLtL, the readtable must have more than 64k 'logical' entries. Regards, Thom Linden Masayuki Ida PS: our proposal is the result of several japanese and USA CL implementations. Though we will welcome any opinions to our proposal, I feel the final decision will be by ANSI, JIS, and ISO. One of the members of our WG will attend the X3J13 meeting, since I cannot leave my university on the next week. He is a very active members and he knows the process. He is scheduled to have a presentation on this issue at the X3J13 meeting.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 25 Jun 87 17:01:55 EDT Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 25 Jun 87 09:22:18 PDT Received: from relay2.cs.net by RELAY.CS.NET id ac04243; 25 Jun 87 11:10 EDT Received: from utokyo-relay by RELAY.CS.NET id aa19616; 25 Jun 87 11:04 EDT Received: by ccut.cc.u-tokyo.junet (5.51/6.2.9Junet) id AA24561; Thu, 25 Jun 87 23:49:44 JST Received: by tansei.cc.u-tokyo.junet (4.12/6.2Junet) id AA15608; Thu, 25 Jun 87 23:48:59+0900 Date: Thu, 25 Jun 87 23:48:59+0900 From: Masayuki Ida Return-Path: Message-Id: <8706251448.AA15608@tansei.cc.u-tokyo.junet> To: baggins@ibm.com, ida%tansei.cc.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET Subject: Re: A multi-byte character extension proposal Cc: common-lisp@SAIL.STANFORD.EDU Date: Tue, 23 Jun 87 12:54:31 PDT From: "Thomas Linden (Thom)" 1) Are characters with different codes always syntactically distinct? Yes. Can the standard character #\( have two different codes, corresponding, for example, to two different external file system representations of that character? No. (because you said 'the standard character'...) We cannot talk about the different representations on files. Some implementations may read 'similar' characters into one internal code, but others may not. 2) Does the JEIDA proposal permit two different string-chars to have the same print glyph, '(' for example, but different syntactical properties? We did not discuss about the issue related to your question, because we have no scope on the characters which has the same print glyph but different syntactical properties. There are several japanese characters which have similar glyphs. But their glyphs are not 'the same' (except for blank characters). 3) Is it allowable to map both of these sets of codes into the one, internal Lisp character code set when inputting data to Lisp, and adopt our own conventions for translating output back to single and double byte? yes. 4) An elaboration of the the previous question: Is it possible for an implementation to represent all of the standard characters internally with 2-byte codes, and to map some 2-byte character codes and some 1-byte character codes in system files onto the same set of 2-byte internal codes for the standard characters when read into Lisp? yes. 5) The English copy we saw of the proposal did not contain section 4.4. Based on our own translation from the original in Japanese, this section seems to discuss implementation issues. Since we could not make a good conclusion on the issue, the section 4.4 of the early draft injapanese was deleted. The proposal have many freedom for implementors. there seem to be two possible treatments of double byte characters. The first is the case where a double-byte character can be a standard character. The second is where a double-byte character cannot be a standard character. I think so too. 5a) Implementation dependent. 5b) Is the difference between option 1 and option 2 whether the Lisp system would recognize a single-byte version and a double-byte version of this symbol-name in the same file as referring to the same (EQ) symbol? Yes. 1. (list abc /fg " xy " ) -------------------------------- 2. (list abc /fg " xy " ) -- ---- ----- --- ---- 3. (list abc /fg " xy " ) ------------------------ ----- We tried to select one and only one selection among the above 3 'options'. But we found we cannot make decision until ISO related standardization of japanese character representation. 5c) I cannot understand what you said. I don't imagine the status like "there is a character which has a same print glyph but different code." 5d) Implementation dependent. Standard-character may be single-byte or may be multi-byte, according to the definition of the implementation. 5e) Is section 4.4 a part of the proposal to ANSI? No. If you could elaborate (in English) on the content of section 4.4, we would greatly appreciate it. Please ask IBM japan (your subsidiary) for the complex issue behind the section 4.4 of the early draft in japanese. We need more observations on other languages, file systems, operating systems and JIS character set definition refinement itself before we might make a firm guideline for the matter. 6) Correct? Your interpretation can cope with our proposal. 7) If a Lisp system supports a large character code set, need it allow every character of type string-char to have a non-constituent syntax type defined in the readtable, or is the proposal's default that only standard characters need be represented in the readtable? CLtL says (22.1.5 page 360): "every character of type string-char must be represented in the readtable." The members felt as we extended the definition of string-char to include japanese characters, as the results of a natual interpretation of CLtL, the readtable must have more than 64k 'logical' entries. Regards, Thom Linden Masayuki Ida PS: our proposal is the result of several japanese and USA CL implementations. Though we will welcome any opinions to our proposal, I feel the final decision will be by ANSI, JIS, and ISO. One of the members of our WG will attend the X3J13 meeting, since I cannot leave my university on the next week. He is a very active members and he knows the process. He is scheduled to have a presentation on this issue at the X3J13 meeting.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 25 Jun 87 16:23:58 EDT Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 25 Jun 87 09:22:18 PDT Received: from relay2.cs.net by RELAY.CS.NET id ac04243; 25 Jun 87 11:10 EDT Received: from utokyo-relay by RELAY.CS.NET id aa19616; 25 Jun 87 11:04 EDT Received: by ccut.cc.u-tokyo.junet (5.51/6.2.9Junet) id AA24561; Thu, 25 Jun 87 23:49:44 JST Received: by tansei.cc.u-tokyo.junet (4.12/6.2Junet) id AA15608; Thu, 25 Jun 87 23:48:59+0900 Date: Thu, 25 Jun 87 23:48:59+0900 From: Masayuki Ida Return-Path: Message-Id: <8706251448.AA15608@tansei.cc.u-tokyo.junet> To: baggins@ibm.com, ida%tansei.cc.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET Subject: Re: A multi-byte character extension proposal Cc: common-lisp@SAIL.STANFORD.EDU Date: Tue, 23 Jun 87 12:54:31 PDT From: "Thomas Linden (Thom)" 1) Are characters with different codes always syntactically distinct? Yes. Can the standard character #\( have two different codes, corresponding, for example, to two different external file system representations of that character? No. (because you said 'the standard character'...) We cannot talk about the different representations on files. Some implementations may read 'similar' characters into one internal code, but others may not. 2) Does the JEIDA proposal permit two different string-chars to have the same print glyph, '(' for example, but different syntactical properties? We did not discuss about the issue related to your question, because we have no scope on the characters which has the same print glyph but different syntactical properties. There are several japanese characters which have similar glyphs. But their glyphs are not 'the same' (except for blank characters). 3) Is it allowable to map both of these sets of codes into the one, internal Lisp character code set when inputting data to Lisp, and adopt our own conventions for translating output back to single and double byte? yes. 4) An elaboration of the the previous question: Is it possible for an implementation to represent all of the standard characters internally with 2-byte codes, and to map some 2-byte character codes and some 1-byte character codes in system files onto the same set of 2-byte internal codes for the standard characters when read into Lisp? yes. 5) The English copy we saw of the proposal did not contain section 4.4. Based on our own translation from the original in Japanese, this section seems to discuss implementation issues. Since we could not make a good conclusion on the issue, the section 4.4 of the early draft injapanese was deleted. The proposal have many freedom for implementors. there seem to be two possible treatments of double byte characters. The first is the case where a double-byte character can be a standard character. The second is where a double-byte character cannot be a standard character. I think so too. 5a) Implementation dependent. 5b) Is the difference between option 1 and option 2 whether the Lisp system would recognize a single-byte version and a double-byte version of this symbol-name in the same file as referring to the same (EQ) symbol? Yes. 1. (list abc /fg " xy " ) -------------------------------- 2. (list abc /fg " xy " ) -- ---- ----- --- ---- 3. (list abc /fg " xy " ) ------------------------ ----- We tried to select one and only one selection among the above 3 'options'. But we found we cannot make decision until ISO related standardization of japanese character representation. 5c) I cannot understand what you said. I don't imagine the status like "there is a character which has a same print glyph but different code." 5d) Implementation dependent. Standard-character may be single-byte or may be multi-byte, according to the definition of the implementation. 5e) Is section 4.4 a part of the proposal to ANSI? No. If you could elaborate (in English) on the content of section 4.4, we would greatly appreciate it. Please ask IBM japan (your subsidiary) for the complex issue behind the section 4.4 of the early draft in japanese. We need more observations on other languages, file systems, operating systems and JIS character set definition refinement itself before we might make a firm guideline for the matter. 6) Correct? Your interpretation can cope with our proposal. 7) If a Lisp system supports a large character code set, need it allow every character of type string-char to have a non-constituent syntax type defined in the readtable, or is the proposal's default that only standard characters need be represented in the readtable? CLtL says (22.1.5 page 360): "every character of type string-char must be represented in the readtable." The members felt as we extended the definition of string-char to include japanese characters, as the results of a natual interpretation of CLtL, the readtable must have more than 64k 'logical' entries. Regards, Thom Linden Masayuki Ida PS: our proposal is the result of several japanese and USA CL implementations. Though we will welcome any opinions to our proposal, I feel the final decision will be by ANSI, JIS, and ISO. One of the members of our WG will attend the X3J13 meeting, since I cannot leave my university on the next week. He is a very active members and he knows the process. He is scheduled to have a presentation on this issue at the X3J13 meeting.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 25 Jun 87 12:52:03 EDT Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 25 Jun 87 09:22:18 PDT Received: from relay2.cs.net by RELAY.CS.NET id ac04243; 25 Jun 87 11:10 EDT Received: from utokyo-relay by RELAY.CS.NET id aa19616; 25 Jun 87 11:04 EDT Received: by ccut.cc.u-tokyo.junet (5.51/6.2.9Junet) id AA24561; Thu, 25 Jun 87 23:49:44 JST Received: by tansei.cc.u-tokyo.junet (4.12/6.2Junet) id AA15608; Thu, 25 Jun 87 23:48:59+0900 Date: Thu, 25 Jun 87 23:48:59+0900 From: Masayuki Ida Return-Path: Message-Id: <8706251448.AA15608@tansei.cc.u-tokyo.junet> To: baggins@ibm.com, ida%tansei.cc.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET Subject: Re: A multi-byte character extension proposal Cc: common-lisp@SAIL.STANFORD.EDU Date: Tue, 23 Jun 87 12:54:31 PDT From: "Thomas Linden (Thom)" 1) Are characters with different codes always syntactically distinct? Yes. Can the standard character #\( have two different codes, corresponding, for example, to two different external file system representations of that character? No. (because you said 'the standard character'...) We cannot talk about the different representations on files. Some implementations may read 'similar' characters into one internal code, but others may not. 2) Does the JEIDA proposal permit two different string-chars to have the same print glyph, '(' for example, but different syntactical properties? We did not discuss about the issue related to your question, because we have no scope on the characters which has the same print glyph but different syntactical properties. There are several japanese characters which have similar glyphs. But their glyphs are not 'the same' (except for blank characters). 3) Is it allowable to map both of these sets of codes into the one, internal Lisp character code set when inputting data to Lisp, and adopt our own conventions for translating output back to single and double byte? yes. 4) An elaboration of the the previous question: Is it possible for an implementation to represent all of the standard characters internally with 2-byte codes, and to map some 2-byte character codes and some 1-byte character codes in system files onto the same set of 2-byte internal codes for the standard characters when read into Lisp? yes. 5) The English copy we saw of the proposal did not contain section 4.4. Based on our own translation from the original in Japanese, this section seems to discuss implementation issues. Since we could not make a good conclusion on the issue, the section 4.4 of the early draft injapanese was deleted. The proposal have many freedom for implementors. there seem to be two possible treatments of double byte characters. The first is the case where a double-byte character can be a standard character. The second is where a double-byte character cannot be a standard character. I think so too. 5a) Implementation dependent. 5b) Is the difference between option 1 and option 2 whether the Lisp system would recognize a single-byte version and a double-byte version of this symbol-name in the same file as referring to the same (EQ) symbol? Yes. 1. (list abc /fg " xy " ) -------------------------------- 2. (list abc /fg " xy " ) -- ---- ----- --- ---- 3. (list abc /fg " xy " ) ------------------------ ----- We tried to select one and only one selection among the above 3 'options'. But we found we cannot make decision until ISO related standardization of japanese character representation. 5c) I cannot understand what you said. I don't imagine the status like "there is a character which has a same print glyph but different code." 5d) Implementation dependent. Standard-character may be single-byte or may be multi-byte, according to the definition of the implementation. 5e) Is section 4.4 a part of the proposal to ANSI? No. If you could elaborate (in English) on the content of section 4.4, we would greatly appreciate it. Please ask IBM japan (your subsidiary) for the complex issue behind the section 4.4 of the early draft in japanese. We need more observations on other languages, file systems, operating systems and JIS character set definition refinement itself before we might make a firm guideline for the matter. 6) Correct? Your interpretation can cope with our proposal. 7) If a Lisp system supports a large character code set, need it allow every character of type string-char to have a non-constituent syntax type defined in the readtable, or is the proposal's default that only standard characters need be represented in the readtable? CLtL says (22.1.5 page 360): "every character of type string-char must be represented in the readtable." The members felt as we extended the definition of string-char to include japanese characters, as the results of a natual interpretation of CLtL, the readtable must have more than 64k 'logical' entries. Regards, Thom Linden Masayuki Ida PS: our proposal is the result of several japanese and USA CL implementations. Though we will welcome any opinions to our proposal, I feel the final decision will be by ANSI, JIS, and ISO. One of the members of our WG will attend the X3J13 meeting, since I cannot leave my university on the next week. He is a very active members and he knows the process. He is scheduled to have a presentation on this issue at the X3J13 meeting.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 23 Jun 87 19:01:18 EDT Received: from IBM.COM by SAIL.STANFORD.EDU with TCP; 23 Jun 87 15:34:22 PDT Date: Tue, 23 Jun 87 12:54:31 PDT From: "Thomas Linden (Thom)" To: "Dr. Masayuki Ida" , Common Lisp mailing Message-ID: <870623.125431.baggins@IBM.com> Subject: A multi-byte character extension proposal Professor Ida: We have had the opportunity to review the English translation of part of the JEIDA proposal regarding the extension of Common Lisp to large (multi-byte) character sets. We were impressed with the scope of the issues addressed. However, the translation was vague on a few points, and we would like clarification. Your anwsers to the following questions would be appreciated: 1) The paper proposes that Lisp characters be assigned unique codes over a potentially large domain (possibly all the integers between 0 and 65535). Are characters with different codes always syntactically distinct? Can the standard character #\( have two different codes, corresponding, for example, to two different external file system representations of that character? If so, would the Lisp reader always parse these two representations identically? 2) CLtL says, (p. 233) "The code attribute is intended to distinguish among the printed glyphs and formatting functions for characters." Does the JEIDA proposal permit two different string-chars to have the same print glyph, '(' for example, but different syntactical properties? 3) Under the proposal, it is up to each implementation how it chooses to translate the contents of files or terminal input when passed as input to the Lisp system. We have both single-byte and double-byte character conventions for file contents; thus is it allowable to map both of these sets of codes into the one, internal Lisp character code set when inputting data to Lisp, and adopt our own conventions for translating output back to single and double byte? 4) An elaboration of the the previous question: Is it possible for an implementation to represent all of the standard characters internally with 2-byte codes, and to map some 2-byte character codes and some 1-byte character codes in system files onto the same set of 2-byte internal codes for the standard characters when read into Lisp? 5) The English copy we saw of the proposal did not contain section 4.4. Based on our own translation from the original in Japanese, this section seems to discuss implementation issues. Given a system such as our's, which has both single-byte and double-byte conventions for some characters, including the Common Lisp standard characters, there seem to be two possible treatments of double byte characters. The first is the case where a double-byte character can be a standard character. The second is where a double-byte character cannot be a standard character. 5a) Is the proposal's default, in section 4.4, that a Lisp implementation reading a file on a system with both single-byte and double-byte conventions, not recognize any double-byte character in that file as a standard character? 5b) There are three example Lisp forms with underlining which seem to indicate three options of single-byte/double-byte equivalency. Consider the symbol 'abc' in these forms. Is the difference between option 1 and option 2 whether the Lisp system would recognize a single-byte version and a double-byte version of this symbol-name in the same file as referring to the same (EQ) symbol? 1. (list abc /fg " xy " ) -------------------------------- 2. (list abc /fg " xy " ) -- ---- ----- --- ---- 3. (list abc /fg " xy " ) ------------------------ ----- 5c) If a Lisp system does not recognize these two symbol names as equivalent, doesn't that require the Lisp system to have two characters with different codes but the same print glyph? 5d) Under the default proposal, if the character object print syntax "#\a" or "#\A" is read from a file, is alpha-char-p true 1. if the 'a' had been encoded as a single byte? 2. if the 'a' had been encoded as a double byte? 3. if the 'A' had been encoded as a single byte? 4. if the 'A' had been encoded as a double byte? 5e) Is section 4.4 a part of the proposal to ANSI, or has it been included for merely illustrative purposes? If you could elaborate (in English) on the content of section 4.4, we would greatly appreciate it. 6) Even if the Lisp system supports a large character set, only standard characters have, as a default, non-constituent syntax type, constituent character attributes relevant to parsing of numbers and symbols, or defined syntax within a format control string. Correct? 7) If a Lisp system supports a large character code set, need it allow every character of type string-char to have a non-constituent syntax type defined in the readtable, or is the proposal's default that only standard characters need be represented in the readtable? 8) A specific case related to the previous question: suppose #\% were a non-standard character, but still a string-char in some implementation of Lisp. Is (make-dispatch-macro-character #\%) necessarily permitted in every implementation that supports #\% as a string-char? Regards, Thom Linden  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 23 Jun 87 10:27:11 EDT Received: from R20.UTEXAS.EDU by SAIL.STANFORD.EDU with TCP; 23 Jun 87 06:54:29 PDT Date: Mon 22 Jun 87 20:24:22-CDT From: CL.BOYER@R20.UTEXAS.EDU Subject: Kyoto Common Lisp To: ailist@STRIPE.SRI.COM, common-lisp@SAIL.STANFORD.EDU, arpanet-bboards@MC.LCS.MIT.EDU Message-ID: <12312656894.9.CL.BOYER@R20.UTEXAS.EDU> Kyoto Common Lisp (KCL) is a complete implementation of Common Lisp written by T. Yuasa and M. Hagiya working under Professor R. Nakajima at the Research Institute for Mathematical Sciences, Kyoto University. It runs on many different machines and is highly portable. It executes very efficiently and it is superbly documented. KCL is being made available at no fee through the implementors' generosity. The complete sources are included. One channel of distribution is via ftp on the Arpanet/Internet. LICENSE REQUIRED! IMPORTANT: Although there is no fee, KCL is not in the public domain. You are authorized to obtain it only after signing and mailing in a license agreement. Before you ftp KCL files you MUST fill out and send in the license agreement included in this message. Otherwise, you are not permitted to make copies of KCL. COPYING KCL VIA INTERNET KCL may be obtained from Internet source rascal.ics.utexas.edu [128.83.144.1], a Sun-3 at the University of Texas at Austin. To obtain KCL, login as "ftp" with password "guest". There are three tar files: /pub/kcl.tar, 4.0 megabytes /pub/kcl.tar.C, produced by compact from kcl.tar, 2.8 megabytes /pub/kcl.tar.Z, produced by compress from kcl.tar, 1.2 megabytes Any of the three files is sufficient to generate KCL. Please ftp the compressed file if possible. Please use ftp at an odd hour if possible to reduce traffic on a sometimes heavily loaded network. Be sure to use binary mode with ftp. A current version of this message may be found as the file /pub/kcl.broadcast. MACHINES ON WHICH KCL RUNS KCL runs on many machines. With the sources provided in the ftp file, KCL may be executed on the following machines (and operating systems). VAX/UNIX (4.2BSD) SUN2 (OS2, 3) SUN3 (OS3) SONY'S NEWS (4.2BSD) ATT3B2 (System V) Fujitu S3000 (System V) Sumitomo's E15 (Uniplus System V) Data General MV (DGUX) Instructions for making the system are in the file doc/porting in the ftp tar file. KCL LICENSE FORM To obtain the right to copy KCL, sign this license form and send it and a copy to the Kyoto address at the end of the form. ONCE YOU HAVE MAILED THE SIGNED LICENSE FORM, YOU MAY COPY KCL. YOU DO NOT HAVE TO WAIT FOR RECEIPT OF THE SIGNED FORM. --------------------------- cut here ---------------------------- ! LICENSE AGREEMENT FOR KYOTO COMMON LISP The Special Interest Group in LISP (Taiichi Yuasa and Masami Hagiya) at the Research Institute for Mathematical Sciences, Kyoto University (hereinafter referred to as SIGLISP) grants to USER NAME: _________________________________________ USER ADDRESS: ______________________________________ ______________________________________ (hereinafter referred to as USER), a non-transferable and non-exclusive license to copy and use Kyoto Common LISP (hereinafter referred to as KCL) under the following terms and conditions and for the period of time identified in Paragraph 6. 1. This license agreement grants to the USER the right to use KCL within their own home or organization. The USER may make copies of KCL for use within their own home or organization, but may not further distribute KCL except as provided in paragraph 2. 2. SIGLISP intends that KCL be widely distributed and used, but in a manner which preserves the quality and integrity of KCL. The USER may send a copy of KCL to another home or organization only after either receiving permission from SIGLISP or after seeing written evidence that the other home or organization has signed this agreement and sent a hard copy of it to SIGLISP. If the USER has made modifications to KCL and wants to distribute that modified copy, the USER will first obtain permission from SIGLISP by written or electronic communication. Any USER which has received such a modified copy can pass it on as received, but must receive further permission for further modifications. All modifications to copies of KCL passed on to other homes or organizations shall be clearly and conspicuously indicated in all such copies. Under no other circumstances than provided in this paragraph shall a modified copy of KCL be represented as KCL. 3. The USER will ensure that all their copies of KCL, whether modified or not, carry as the first information item the following copyright notice: (c) Copyright Taiichi Yuasa and Masami Hagiya, 1984. All rights reserved. Copying of this file is authorized to users who have executed the true and proper "License Agreement for Kyoto Common LISP" with SIGLISP. 4. Title to and ownership of KCL and its copies shall at all times remain with SIGLISP and those admitted by SIGLISP as contributors to the development of KCL. The USER will return to SIGLISP for further distribution modifications to KCL, modifications being understood to mean changes which increase the speed, reliability and existing functionality of the software delivered to the USER. The USER may make for their own ownership and use enhancements to KCL which add new functionality and applications which employ KCL. Such modules may be returned to SIGLISP at the option of the USER. 5. KCL IS LICENSED WITH NO WARRANTY OF ANY KIND. SIGLISP WILL NOT BE RESPONSIBLE FOR THE CORRECTION OF ANY BUGS OR OTHER DEFICIENCIES. IN NO EVENT SHALL SIGLISP BE LIABLE FOR ANY DAMAGES OF ANY KIND, INCLUDING SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF KCL. 6. This license for KCL shall be effective from the date hereof and shall remain in force until the USER discontinues use of KCL. In the event the USER neglects or fails to perform or observe any obligations under this Agreement, this Agreement and the License granted hereunder shall be immediately terminated and the USER shall certify to SIGLISP in writing that all copies of KCL in whatever form in its possession or under its control have been destroyed. 7. Requests. KCL is provided by SIGLISP in a spirit of friendship and cooperation. SIGLISP asks that people enjoying the use of KCL cooperate in return to help further develop and distribute KCL. Specifically, SIGLISP would like to know which machines KCL gets used on. A brief notice form is appended to this agreement which the user is requested to send by email or otherwise. Please send in further notifications at reasonable intervals if you increase the number and type of machines on which KCL is loaded. You may send these notices to another USER which is cooperating with SIGLISP for this purpose. USER DATE: _________________________________________ BY: ___________________________________________ TITLE: ________________________________________ ADDRESS: ______________________________________ ______________________________________ SIGLISP DATE: _________________________________________ BY: ___________________________________________ Taiichi Yuasa Masami Hagiya Special Interest Group in LISP Research Institute for Mathematical Sciences Kyoto University Kyoto, 606, JAPAN Telex: 05422020 RIMS J JUNET: siglisp@kurims.kurims.kyoto-u.junet CSNET: siglisp%kurims.kurims.kyoto-u.junet@utokyo-relay.csnet USER has loaded KCL on the following machines since (date): Model Number Production Name Number of Machines ! END OF LICENSE FORM --------------------------- cut here ------------------------ DOCUMENTATION The principal documentation for KCL is, of course, the book "Common Lisp The Language" by Guy L. Steele, Jr. with contributions by Scott E. Fahlman, Richard P. Gabriel, David A. Moon, and Daniel L. Weinreb, Digital Press, 1984. Implementation-specific details of KCL (debugging, garbage collection, data structure format, declarations, operating system interface, installation) may be found in the 131 page "Kyoto Common Lisp Report" by Taiichi Yuasa and Masami Hagiya, the authors of KCL. This report is available from: Teikoku Insatsu Inc. Shochiku-cho, Ryogae-cho-dori Takeya-machi Sagaru, Naka-gyo-ku, Kyoto, 604, Japan tel: 075-231-4757 for 5,000 yen plus postage. The KCL Report is produced by the text-formatter KROFF (Kyoto ROFF), which is used locally within Kyoto University. Currently KROFF works only on printers available in Japan. It is possible that an American distributorship of this report will be arranged. The source of the report, with KROFF commands, is found in the file doc/report on the ftp tar file. It is possible to read this source, though it is as hard on the eyes as TeX or Scribe source. A translation of this source into TeX is underway and will be available as part of the distribution tape. Future information about the availability of the KCL Report will be available in updated versions of this message, in the file /pub/kcl.broadcast. A document describing how to port KCL to other systems is available at no charge from the authors of KCL. Each of the KCL primitives is thoroughly described by the "describe" function, which is based on 340K bytes of documentation. SUPPORT KCL is one of the most bug-free large software systems that we have ever used. However, when bugs are found, they may be reported to the implementors: hagiya%kurims.kurims.kyoto-u.junet%utokyo-relay.csnet@RELAY.CS.NET yuasa%kurims.kurims.kyoto-u.junet%utokyo-relay.csnet@RELAY.CS.NET We have found them extremely responsive to bug reports and suggestions. SAMPLE TRANSCRIPT Below is a complete transcript for obtaining and installing KCL on a Sun-3. Make a directory for locating KCL tutorial% mkdir /usr/joe/kcl Get the compressed tar file tutorial% cd /usr/joe/kcl tutorial% ftp 128.83.144.1 220 rascal FTP server (Version 4.7 Sun Sep 14 12:44:57 PDT 1986) ready. Name: ftp Password: guest ftp>binary ftp>get /pub/kcl.tar.Z kcl.tar.Z ftp>quit Build the KCL directory structure tutorial% uncompress kcl.tar.Z tutorial% tar -xvf kcl.tar . tutorial% rm kcl.tar Make KCL tutorial% cd /usr/joe/kcl/ tutorial% su password: super-user-password tutorial# cp h/cmpinclude.h /usr/include tutorial# exit tutorial% make Edit and Install Two Files We wish to replace "~" by "/usr/joe" in lc and kcl, and put them in a directory on the search path e.g. "/usr/joe/bin" tutorial% cd /usr/joe/kcl/unixport tutorial% mkdir /usr/joe/bin tutorial% sed -e "s.~./usr/joe/kcl.g" lc > /usr/joe/bin/lc tutorial% sed -e "s.~./usr/joe/kcl.g" kcl > /usr/joe/bin/kcl tutorial% chmod a+x /usr/joe/bin/lc /usr/joe/bin/kcl It is now possible to run kcl: tutorial% /usr/joe/bin/kcl KCL (Kyoto Common Lisp) >(+ 2 3) 5 >(bye) It is best to become super user and execute the following commands, so that all users may execute kcl. tutorial% su Password: superuser-password tutorial# cp /usr/joe/bin/kcl /usr/local/bin tutorial# cp /usr/joe/bin/lc /usr/local/bin tutorial# exit This transcript puts the entire kcl system, including sources and documentation, in the directory /usr/joe/kcl. Any other directory name would do as well, e.g., /usr/local instead of /usr/joe. Although this transcript has worked perfectly for us on a Sun-3, it might not work for you if you are running under NFS but not logged into the right machine: you may need to login as root on the system where /usr/include and /usr/local/bin are really located to do the super-user things. Immediately after the make is finished about 8.4 megatyes of disk space are in use. SINCERELY YOURS Robert S. Boyer William F. Schelter cl.boyer@r20.utexas.edu atp.schelter@r20.utexas.edu This message was written by Robert S. Boyer and William F. Schelter. The opinions expressed are theirs and are not necessarily those of the authors of KCL, the University of Texas, or MCC. The authors of KCL have, however, indicated that they have no objection to our distributing this message. P.S. Thanks to Dave Capshaw, George Fann, Warren Hunt, Ken Rimey, and Carl Quillen for helping debug this message. Ken Rimey, rimey@ernie.Berkeley.EDU, makes the following remarks about bringing up this release of KCL under BSD 4.3 on a Vax. 1. Bringing up KCL under BSD4.3. The machine on which I installed kcl was a Vax 88xx running Ultrix V2.0. Kcl crashed when executing the final save-system command in init_kcl.lsp. It also did so on a Vax running BSD4.3. (I don't know of any Vaxen still running 4.2.) The problem is caused by some highly non-portable code introduced into Lsave() in c/unixsave.c since the version of March 28, 1986. I deleted the new code and reintroduced the old which had been commented out. Here is the resulting working Lsave(): Lsave() { char filename[256]; check_arg(1); check_type_or_pathname_string_symbol_stream(&vs_base[0]); coerce_to_filename(vs_base[0], filename); _cleanup(); memory_save(kcl_self, filename); exit(0); /* no return */ } KCL ran successfully after only fixing the Lsave problem. 2. The files o/makefile and unixport/makefile define variables that need to be changed when compiling for any machine other than a Sun-3. These definitions are found at the heads of these files. Here is the head of my copy of o/makefile: MACHINE = VAX # Select 'VAX', 'SUN', 'SUN2R3', 'SUN3', 'ISI', 'SEQ', 'IBMRT', # or 'NEWS'. CHTAB = char_table.s # Select 'char_table.s' or 'sun_chtab.s'. # 1) char_table.s : for VAX, SEQ and NEWS # 2) sun_chtab.s : for SUN, SUN2R3 and SUN3 # 3) isi_chtab.s : for ISI # 4) ibmrt_chtab.s: for IBMRT For machines other than Sun-3, one might change the MAKE KCL section of this message to: tutorial% cd /usr/joe/kcl/ tutorial% vi o/makefile (If not Sun-3, change definitions MACHINE and CHTAB.) tutorial% vi o/unixport (If not Sun-3, change definition of MACHINE.) tutorial% su password: super-user-password tutorial# cp h/cmpinclude.h /usr/include tutorial# exit tutorial% make -------  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 23 Jun 87 06:07:02 EDT Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 23 Jun 87 02:52:14 PDT Received: from relay2.cs.net by RELAY.CS.NET id aa22002; 23 Jun 87 4:19 EDT Received: from hplb by RELAY.CS.NET id ab04330; 23 Jun 87 4:11 EDT From: Christopher Dollin Date: Tue, 23 Jun 87 08:22:01 GMT Message-Id: <1977.8706230822@hplb.lb.hp.co.uk> To: common-lisp@SAIL.STANFORD.EDU Oops! Yes, I guess I slipped. Using LET* will cover the case of multiple bindings, too. Must have been a bad day ... can't even blame jet-lag ... Regards, Kers (Using KMail 10-Apr-87 (Kers))  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 22 Jun 87 18:19:32 EDT Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 22 Jun 87 13:59:47 PDT Received: from Cabernet.ms by ArpaGateway.ms ; 22 JUN 87 12:10:23 PDT Date: 22 Jun 87 12:09 PDT From: Daniels.pa@Xerox.COM Subject: Re: APPLY with 3+ arguments In-reply-to: Richard Fritzson 's message of 22 Jun 87 07:19 EDT (Monday) To: fritzson@bigburd.PRC.Unisys.COM cc: common-lisp@sail.stanford.edu Message-ID: <870622-121023-1188@Xerox> Perhaps you're a little confused about how APPLY with more than 2 args works. Only the last argument passed to APPLY is an arglist. The rest are individual arguments to the applied function. As CLtL says, "it is as if all the arguments to apply execpt the function were given to LIST* to create the argumentlist." Thus (APPLY #'LIST '(1 2) '(3 4)) => ((1 2) 3 4), not (1 2 3 4). Page 108 of CLtL and the other replies to your message give reasonable examples of what you can use this for. -- Andy. --  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 22 Jun 87 17:24:01 EDT Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 22 Jun 87 13:59:47 PDT Received: from Cabernet.ms by ArpaGateway.ms ; 22 JUN 87 12:10:23 PDT Date: 22 Jun 87 12:09 PDT From: Daniels.pa@Xerox.COM Subject: Re: APPLY with 3+ arguments In-reply-to: Richard Fritzson 's message of 22 Jun 87 07:19 EDT (Monday) To: fritzson@bigburd.PRC.Unisys.COM cc: common-lisp@sail.stanford.edu Message-ID: <870622-121023-1188@Xerox> Perhaps you're a little confused about how APPLY with more than 2 args works. Only the last argument passed to APPLY is an arglist. The rest are individual arguments to the applied function. As CLtL says, "it is as if all the arguments to apply execpt the function were given to LIST* to create the argumentlist." Thus (APPLY #'LIST '(1 2) '(3 4)) => ((1 2) 3 4), not (1 2 3 4). Page 108 of CLtL and the other replies to your message give reasonable examples of what you can use this for. -- Andy. --  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 22 Jun 87 13:18:55 EDT Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 22 Jun 87 09:59:25 PDT Received: from occam by Think.COM via CHAOS; Mon, 22 Jun 87 13:01:49 EDT Date: Mon, 22 Jun 87 12:59 EDT From: Barry Margolin Subject: I Like a Single Namespace To: Christopher Dollin Cc: common-lisp@sail.stanford.edu In-Reply-To: <25156.8706221353@hplb.lb.hp.co.uk> Message-Id: <870622125923.6.BARMAR@OCCAM.THINK.COM> Date: Mon, 22 Jun 87 13:53:15 GMT From: Christopher Dollin Issues in Function and Value Cells ------ -- -------- --- ----- ----- [...] Without this one has to restore to unwind-protects or double declarations as in (let ((old-special-variable special-variable)) (let ((special-variable expression-involving-old-special-variable)) bit-that-does-the-work ) ) where the unholy conspiracy between the structure of let-bindings and the behaviour of dynamic binding leaves a lot to be desired, especially if more than one special variable is being so modified. The above is not necessary in any Maclisp-descended Lisp I'm familiar with. (let ((*special-var* *special-var*)) bit-that-does-the-work) works fine (and is used quite often) in Maclisp, Zetalisp, and Common Lisp. The expressions in a LET value form are evaluated in the dynamic environment OUTSIDE the LET. You may be confusing this with the fact that declarations at the beginning of a LET body refer to variables in the value forms; this means that you can't do (let ((*special-var* *special-var*)) (declare (unspecial *special-var*)) bit-that-does-the-work) and have the lexical *SPECIAL-VAR* get initialized from the dynamic *SPECIAL-VAR*. barmar  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 22 Jun 87 10:59:20 EDT Received: from [128.81.51.3] by SAIL.STANFORD.EDU with TCP; 22 Jun 87 07:40:58 PDT Received: from KOYAANISQATSI.S4CC.Symbolics.COM by DIAMOND.S4CC.Symbolics.COM via CHAOS with CHAOS-MAIL id 98345; Mon 22-Jun-87 10:15:32 EDT Date: Mon, 22 Jun 87 10:14 EDT From: David C. Plummer Subject: APPLY with 3+ arguments To: Richard Fritzson , common-lisp@sail.stanford.edu In-Reply-To: <8706221121.AA16283@bigburd.PRC.Unisys.COM> Message-ID: <870622101406.6.DCP@KOYAANISQATSI.S4CC.Symbolics.COM> Date: 22 Jun 87 07:19 EDT (Monday) From: Richard Fritzson Can anyone provide a motivation for the CLtL definition of APPLY when more than one arglist is provided? I understand what it does perfectly well, but I don't understand when I am going to have a use for this. There are two common uses I have seen. One is to have a function take an &REST arg which is the arguments for some other function, yet the middle-man wants to supply additional keywords or override them, such as (defun make-raster-bit-array (width height &rest other-make-array-args) (apply #'make-array (list height width) :element-type 'bit other-make-array-args)) The other common case is similar, but is used to supply required and optional arguments to a function which also takes an &REST arg, for example, (defun trace-format (format-string &rest format-args) (apply #'format *trace-output* format-string format-args))  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 22 Jun 87 10:18:02 EDT Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 22 Jun 87 06:53:56 PDT Received: from relay2.cs.net by RELAY.CS.NET id aa13493; 22 Jun 87 9:19 EDT Received: from hplb by RELAY.CS.NET id aa10406; 22 Jun 87 9:10 EDT From: Christopher Dollin Date: Mon, 22 Jun 87 13:53:15 GMT Message-Id: <25156.8706221353@hplb.lb.hp.co.uk> To: common-lisp@SAIL.STANFORD.EDU Subject: I Like a Single Namespace Issues in Function and Value Cells ------ -- -------- --- ----- ----- I have been reading "Issues of Separation in Function Cells and Value Cells" and would like to add some comments. It is interesting to compare the choices discussed in the paper, and taken in Common Lisp, with similar choices in the language Pop11 (as instantiated in Poplog Version 11 onwards). Pop is a good language for comparison purposes, as it falls into the same general class as Lisp: imperative, interactive (and incremental), dynamically typed, extensible. (In contrast to Lisp, it is compile-only, has orthodox syntax, uses an open stack, and does not unite the notions of list and program. But these are separate issues.) Pop has (shallow) dynamic binding and (full) lexical binding, with variables having only one value cell. In practice there does not seem to be any particular problem with local names shadowing global ones (since Pop11 is intended as, amongst other things, a teaching language, this is a significant point). Why is this? Partly because of the names of the built-in procedures. Some of them, such as the underlying primitive "sysconslist", have names a user (especially a beginner!) would be unlikely to choose. Some of them have such common and well-entrenched meanings that it doesn't occur to anyone that they might use them as variables (eg, "hd", the approximate equivalent of "car"). Many of them are spelt with sign characters, eg the list brackets "[" and "]", the append operator "<>"; it is less natural to use names like this for ordinary variables, especially for programmers originally trained in Pascal or C, where the set of infix operators is not extensible. The other reason is that those names are "protected"; they cannot be redeclared or assigned to. Hence one learns rapidly which names are acceptable and which are not; there are only a few names one misses being able to use ("in" and "to" are the ones that come to mind, and I once made the mistake of reserving "a"). Experienced users can unprotect - and protect - names if they so desire. What about efficiency? Since there is only one value namespace, mustn't every call be checked to ensure it is a procedure object being applied? In general, yes. The first observation is that Pop programs run "fast enough", so clearly the inefficency induced by checking calls of every user procedure is not that high. The second is that the only sort of type declaration supported (at present) by the underlying implementation is that of declaring a variable to be of type procedure, in which case only procedure values can be stored into it and calls can be compiled as direct jumps rather than going through "apply". Variables can also be declared as "constant", permitting the compiler to avoid generating additional indirections in the code (this is true for values other than procedures as well, of course). Many system procedures are "protected constant procedure"s. (As it happens, they are also not garbage-collected, and have absolute addresses, but that's a separate issue). What have we demonstrated? That, by example, the single namespace is workable, and the possible disadvantages of efficiency and name clashes are countered by declarations (a device Common Lisp already supports) and name protection (a natural device that Common Lisp omits). Another point worthy of note is the way Pop treats variable declarations. When a variable is declared, it is annotated as being dynamic ("vars") or lexical ("lvars"). The declaration masks any that would be inherited from an outer scope. Unlike Common Lisp, variables can be declared lexical at the "top level" of a compilation (interaction) too: in this case they are local to the current compilation and are inaccessible from outside it. This turns out to be very convenient, permitting modules to be defined which expose only a few names to the outside world, while having many names internally, without having to use the Pop "section" mechanism (roughly equivalent to Lisp packages, but with a different set of design mistakes). Pop distinguishes "dynamic" constants (which are dynamic variables with fixed values) from "lexical" constants; just as with variables, lexical constants are visible only within a single compilation unit. Although it is possible to change a dynamic constant (by re-declaring it; of course all existing references will still get the old constant, so this facility is primarily useful when re-loading code when a change has been made) a lexical constant cannot be redefined. Naturally procedure names may be defined as being in any of the four classes "vars", "lvars", "constant", or "lconstant"; this is done with the simple expedient of allowing one of these words to follow the introductory "define" of the declaration. A very interesting difference between Lisp's and Pop's treatment of local declarations of dynamic variables is the way the dyamic variable is rebound when the binding procedure is entered - it isnt. The variable continues to have its existing value until an assignment to it is made; the only effect of the local redefinition is to ensure that its OLD value will be restored on procedure exit. This turns out to be useful behaviour, eg for locally incrementing a counter, or locally augmenting a procedure. For example, in a simple popup menu procedure which paints its picture inside an editor buffer, I have a declaration rather like vars interrupt = restore_the_screen <> interrupt; "interrupt" is called when an error occurs, and "<>" will compose procedures as well as append lists (and vectors). This declaration will temporarily change interrupt so that it will restore the screen before doing whatever it used to do; note that for this to work it is ESSENTIAL that the old value of interrupt be available. Another useful definition is vars popliblist = my_library :: popliblist; within a library-searching procedure to augment the library list "popliblist" with ones own library; again, it is essential that the old value of the dynamic variable be available. Without this one has to restore to unwind-protects or double declarations as in (let ((old-special-variable special-variable)) (let ((special-variable expression-involving-old-special-variable)) bit-that-does-the-work ) ) where the unholy conspiracy between the structure of let-bindings and the behaviour of dynamic binding leaves a lot to be desired, especially if more than one special variable is being so modified. What is the conclusion here? That a sensible and useful meaning can be found for top-level lexical bindings ("global" bindings in the terms of the paper), and that a useful alternative definition for local dynamic variable declarations can be found and is used in an existing language. A local guru tells me that I can be contacted at kers%hplb.csnet@csnet-relay.arpa which is my address at HPLabs Bristol. Kers  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 22 Jun 87 10:12:03 EDT Received: from ATHENA.MIT.EDU by SAIL.STANFORD.EDU with TCP; 22 Jun 87 06:55:17 PDT Received: by ATHENA.MIT.EDU (5.45/4.7) id AA04179; Mon, 22 Jun 87 09:57:07 EDT From: Received: by HADES.MIT.EDU (5.45/4.7) id AA02757; Mon, 22 Jun 87 09:51:48 EDT Message-Id: <8706221351.AA02757@HADES.MIT.EDU> To: common-lisp@sail.stanford.edu Subject: Re: APPLY with 3+ arguments Date: Mon, 22 Jun 87 09:51:46 EDT Can anyone provide a motivation for the CLtL definition of APPLY when more than one arglist is provided? I understand what it does perfectly well, but I don't understand when I am going to have a use for this. Another use is to write functions like the following: (defun simplify (new old sequence &rest keyword-args) (apply #'remove-duplicates (apply #'substitute new old sequence :count 1 keyword-args) keyword-args)) If APPLY took only two arguments it would be necessary for this function to either take explicit keywords itself or splice the :count keyword/value pair into the argument list for SUBSTITUTE manually. (BTW: Adding keyword arguments in this way is well-defined -- see pg. 62 of CLtL.) --Stuart A. Malone  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 22 Jun 87 09:14:29 EDT Received: from NADC.ARPA by SAIL.STANFORD.EDU with TCP; 22 Jun 87 06:01:23 PDT Received: by NADC.ARPA (5.51/1.0 ) id AA03305; Mon, 22 Jun 87 09:01:16 EDT Date: Mon, 22 Jun 87 09:01:16 EDT From: dml@nadc.arpa (D. Loewenstern) Message-Id: <8706221301.AA03305@NADC.ARPA> To: common-lisp@sail.stanford.edu, fritzson@bigburd.prc.unisys.com Subject: Re: APPLY with 3+ arguments I use 3+ arguments for APPLY often. Usually, I use this when the first few arguments to a function are known, but the remainder are to be passed in as a list: (APPLY #'MAX 0 list) == find the MAX of a list, but return 0 if all elements of the list are negative. Naturally, this isn't strictly necessary -- you could write the above as: (MAX 0 (APPLY #'MAX list)) but I find the first preferable. David Loewenstern Naval Air Development Center code 7013 Warminster, PA 18974-5000  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 22 Jun 87 07:32:53 EDT Received: from BIGBURD.PRC.UNISYS.COM by SAIL.STANFORD.EDU with TCP; 22 Jun 87 04:21:55 PDT Received: from bigburd.PRC.Unisys.COM by burdvax.PRC.Unisys.COM (burdvax) [5.54/1.0] id AA01279; Mon, 22 Jun 87 07:21:34 EDT Received: by bigburd.PRC.Unisys.COM (bigburd) [5.54/1.0] id AA16283; Mon, 22 Jun 87 07:21:31 EDT From: Richard Fritzson Message-Id: <8706221121.AA16283@bigburd.PRC.Unisys.COM> Received: from Plebian by bigburd with PUP; Mon, 22 Jun 87 07:21 EDT Date: 22 Jun 87 07:19 EDT (Monday) To: common-lisp@sail.stanford.edu Subject: APPLY with 3+ arguments Can anyone provide a motivation for the CLtL definition of APPLY when more than one arglist is provided? I understand what it does perfectly well, but I don't understand when I am going to have a use for this. -Rich Fritzson ARPA: fritzson@prc.unisys.com UUCP: {seismo,sdcrdcf,psuvax1}!burdvax!fritzson  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 12 Jun 87 13:38:28 EDT Received: from NADC.ARPA by SAIL.STANFORD.EDU with TCP; 12 Jun 87 10:22:02 PDT Received: by NADC.ARPA (5.51/1.0 ) id AA22156; Fri, 12 Jun 87 13:20:34 EDT Date: Fri, 12 Jun 87 13:20:34 EDT From: dml@nadc.arpa (D. Loewenstern) Message-Id: <8706121720.AA22156@NADC.ARPA> To: daly@ibm.com Subject: Hash-on-eq Cc: common-lisp@sail.stanford.edu We have implemented a portable, efficient method for performing hash-on- eq upon structures: 1. Set up a global counter. 2. For each key structure that will be hashed, add an extra slot. 3. Each time a key structure is instantiated, the current value of the global counter is incremented and stored in the extra slot. 4. Instead of using SXHASH upon the key structure, use the accessor function to get the value in the extra slot. As an added feature, this method will produce nearly uniform hash table distributions. At the expense of introducing an extra slot per structure, you gain a very fast hashing function. David Loewenstern & Mark Silbert  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 11 Jun 87 16:30:10 EDT Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 11 Jun 87 13:13:27 PDT Received: from boethius by Think.COM via CHAOS; Thu, 11 Jun 87 16:15:05 EDT Date: Thu, 11 Jun 87 16:12 EDT From: Guy Steele Subject: Re: historical question about CASE To: FREEMAN@sumex-aim.stanford.edu Cc: common-lisp@sail.stanford.edu In-Reply-To: <12309682881.14.FREEMAN@SUMEX-AIM.STANFORD.EDU> Message-Id: <870611161254.3.GLS@BOETHIUS.THINK.COM> Date: Thu, 11 Jun 87 10:07:37 PDT From: Andy Freeman You wrote: I use the idiom ",@(when foo `(...baz...))" a LOT. I thought that it was considered poor style to use "when" for its value. I may be confusing my dialects, but is there actually a guarantee that "when"'s definition is much like following? (defmacro when (pred &body x) `(if , pred (progn '() ,@ x) '())) Yes, there is such a guarantee: the second sentence of the description of WHEN in CLTL, page 115. (Did you look there?) I agree that in this case I am not consistent; strictly speaking perhaps AND is more appropriate, but I find WHEN mnemonically more appealing in this context, and there is no question that the value is being used, because of the presence of ",@" right before the form. --Guy  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 10 Jun 87 17:37:10 EDT Received: from SCRC-VALLECITO.ARPA by SAIL.STANFORD.EDU with TCP; 10 Jun 87 14:15:12 PDT Received: from EUPHRATES.SCRC.Symbolics.COM by VALLECITO.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 131870; Wed 10-Jun-87 17:09:32 EDT Date: Wed, 10 Jun 87 17:07 EDT From: David A. Moon Subject: Common LISP omissions: Locatives To: David Loewenstern , Mark Silbert , Scott E. Fahlman , Timothy Daly cc: common-lisp@sail.stanford.edu In-Reply-To: <8706101453.AA08852@NADC.ARPA>, , <061087.151319.daly@ibm.com> Message-ID: <870610170743.5.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Wed, 10 Jun 87 10:53:14 EDT From: dml@nadc.arpa (D. Loewenstern) We have been using Common LISP and have noticed two important omissions in the language. 1) Locatives ("LOCF" as found in ZetaLISP). 2) A COLLECT macro. [I won't address COLLECT in this particular message] A primary reason for locatives would be to create your own "hash-on-eq" functions. Common LISP provides SXHASH which hashes on equal. A serious problem occurs if the keys are circular objects. Locatives have no relevance to hashing on EQ. The Zetalisp feature you are thinking of is %POINTER, not LOCF. %POINTER is a function that returns a number which is the address of its argument. LOCF is a macro that returns a locative that designates the cell that is designated by the generalized variable (in the SETF sense) that is LOCF's first subform. The possible operations on locatives are getting the contents of the cell, changing the contents of the cell, making the cell "unbound", checking whether the cell is "unbound", comparing two locatives for equality, and recovering the object that contains the cell. It's pretty easy to make your own variant of SXHASH that detects circularities, although it's bound to be a little slower. I believe the IBM VM/LISP people published a paper on this a while back. Date: 10 June 1987, 15:13:19 EDT From: Timothy Daly We also have felt the need to do hashing-on-eq type of operations. That is, we would like to be able to hash a pair consisting of (address of left subtree . address of right subtree). Unfortunately, SXHASH will walk both subtrees which is much too expensive. We could think of no portable way to implement this in common lisp. Since the language gives us no way to implement this it does not seem that locatives are a frill. There -is- no portable way to implement hashing-on-eq efficiently, because it is inherently dependent on the implementation details of the system's garbage collector. For example, in many systems a garbage collection changes the numerical value of the addresses of objects. In these systems, anything that depends on the numerical values of addresses of objects has to be recomputed after a garbage collection. It's difficult to come up with a portable and efficient way of doing that, particularly in systems with multiple levels of garbage collection, which several systems do in somewhat different ways. It's even harder to do it in a way that doesn't impose an efficiency burden on systems where garbage collection does not change the numerical values of object addresses. This is why Common Lisp did not attempt to provide a hash-on-eq primitive, that is, a function that returns a number given an object, without looking at the contents of the object, and always returns the same number for the same object. There is a portable -inefficient- way to implement hashing-on-eq, which is to use a hash table :test #'eq to remember what hash code you have assigned to each object. I have actually used this. However, this is usually too inefficient to be seriously considered. Date: Wed, 10 Jun 1987 11:35 EDT From: "Scott E. Fahlman" We considered adding locatives early in the original design process, but decided that they didn't make much sense except on machines with hardware support for forwarding pointers. Locatives have no relevance to forwarding pointers, nor do they have any relevance to hardware support. However, I agree that locatives should not be in Common Lisp. My reason is that only some of the possible Lisp implementation techniques for object representation permit the efficient implementation of locatives. It is always possible to implement locatives, as T has demonstrated, but it isn't always possible to implement them efficiently. It seems inappropriate to design the language in a way that would rule out some otherwise reasonable implementation techniques (BIBOP, for example).  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 10 Jun 87 15:59:05 EDT Received: from IBM.COM by SAIL.STANFORD.EDU with TCP; 10 Jun 87 12:37:53 PDT Date: 10 June 1987, 15:13:19 EDT From: Timothy Daly To: common-lisp@sail.stanford.edu Message-Id: <061087.151319.daly@ibm.com> Subject: locatives... Re: locatives We also have felt the need to do hashing-on-eq type of operations. That is, we would like to be able to hash a pair consisting of (address of left subtree . address of right subtree). Unfortunately, SXHASH will walk both subtrees which is much too expensive. We could think of no portable way to implement this in common lisp. Since the language gives us no way to implement this it does not seem that locatives are a frill. tim DALY@IBM.COM T.J.Watson Research, Yorktown.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 10 Jun 87 14:36:50 EDT Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 10 Jun 87 11:21:14 PDT Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 169440; Wed 10-Jun-87 14:18:48 EDT Date: Wed, 10 Jun 87 14:18 EDT From: Kent M Pitman Subject: LISP:STRUCTURE To: hoey@nrl-aic.ARPA cc: Common-Lisp@SAIL.STANFORD.EDU In-Reply-To: <550341798/hoey@nrl-aic> Message-ID: <870610141846.8.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> See p440. STRUCTURE is a valid second argument to DOCUMENTATION and by implication must be on the LISP package. As with VARIABLE, it is not a type.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 10 Jun 87 14:36:36 EDT Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 10 Jun 87 11:20:40 PDT Received: ID ; Wed 10 Jun 87 14:17:47-EDT Date: Wed, 10 Jun 1987 14:17 EDT Message-ID: Sender: RAM@ From: Ram@C.CS.CMU.EDU To: Dan Hoey Cc: common-lisp@SAIL.STANFORD.EDU Subject: LISP:STRUCTURE ? In-reply-to: Msg of 10 Jun 1987 12:43-EDT from Dan Hoey STRUCTURE is a documentation type: see the DOCUMENTATION function. I believe you are right that STRUCTURE is not a Common Lisp type specifier. Rob  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 10 Jun 87 14:17:46 EDT Received: from NRL-AIC.ARPA by SAIL.STANFORD.EDU with TCP; 10 Jun 87 11:01:39 PDT Return-Path: Received: Wed, 10 Jun 87 13:59:26 edt by nrl-aic.ARPA id AA29108 Date: 10 Jun 1987 12:43:18 EDT (Wed) From: Dan Hoey Subject: LISP:STRUCTURE ? To: common-lisp@sail.stanford.edu Message-Id: <550341798/hoey@nrl-aic> 1. Is there a symbol named "STRUCTURE" in the LISP package? In all the ``official'' lists I have seen, the symbol appears. Yet I find no mention of it in CLtL nor in the lists of errata. 2. In the Common Lisps I have been able to test, LISP:STRUCTURE names a type of which types defined by DEFSTRUCT are subtypes. Is STRUCTURE a standard type that should be added to table 4-1? 3. If the answer to 1 is yes, and the answer to 2 is no, then what is LISP:STRUCTURE for? Dan  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 10 Jun 87 11:52:11 EDT Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 10 Jun 87 08:37:04 PDT Received: ID ; Wed 10 Jun 87 11:35:55-EDT Date: Wed, 10 Jun 1987 11:35 EDT Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: dml@nadc.arpa (D. Loewenstern) Cc: common-lisp@SAIL.STANFORD.EDU, silbert@NADC.ARPA Subject: Common LISP omissions: Collect, Locatives In-reply-to: Msg of 10 Jun 1987 10:53-EDT from dml at nadc.arpa (D. Loewenstern) We considered adding locatives early in the original design process, but decided that they didn't make much sense except on machines with hardware support for forwarding pointers. Lisp machines can use locatives to implement other Common Lisp constructs, but we felt that it would be confusing to users and something of a performance trap to make them part of the portable language, that also has to run well on stock hardware. As for collect, when something can be written without any special problems in the existing language, our strategy has been to add it to the standard only if (1) a LOT of people would otherwise end up coding this hack for themselves and (2) a single built-in version would satisfy all of those users. If that kind of need can be demonstrated for COLLECT, it should go in; if not, it should be added to the public-domain library for those people who do want it. Most of the critics of Common Lisp feel that we have put in too many of these optional things already. -- Scott  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 10 Jun 87 11:09:25 EDT Received: from NADC.ARPA by SAIL.STANFORD.EDU with TCP; 10 Jun 87 07:55:21 PDT Received: by NADC.ARPA (5.51/1.0 ) id AA08852; Wed, 10 Jun 87 10:53:14 EDT Date: Wed, 10 Jun 87 10:53:14 EDT From: dml@nadc.arpa (D. Loewenstern) Message-Id: <8706101453.AA08852@NADC.ARPA> To: common-lisp@sail.stanford.edu Subject: Common LISP omissions: Collect, Locatives Cc: dml@NADC.ARPA, silbert@NADC.ARPA We have been using Common LISP and have noticed two important omissions in the language. 1) Locatives ("LOCF" as found in ZetaLISP). 2) A COLLECT macro. A primary reason for locatives would be to create your own "hash-on-eq" functions. Common LISP provides SXHASH which hashes on equal. A serious problem occurs if the keys are circular objects. A collect macro would allow the construction of lists maintaining the order of creation. Currently, the only way to produce the same effect, would be to use PUSH and the NREVERSE. If the programmer intends to use the partially constructed list, it would need to be REVERSEd each time. An example of the collection macro could look like: (DEFMACRO With-Collection (vars &body body) (LET (collects gensym) (DOLIST (var vars) (SETQ gensym (GENSYM var)) (PUSH gensym (GET var :collect)) (PUSH gensym collects)) (PROG1 `(LET (,@vars ,@collects) ,@(Macroexpand-All body)) (DOLIST (var vars) (POP (GET var :collect))))) ) (DEFMACRO Collect (obj place) (LET ((endptr (CAR (GET place :collect)))) `(COND (,place (SETF (CDR ,endptr) (NCONS ,obj)) (SETQ ,endptr (CDR ,endptr))) (T (SETQ ,place (NCONS ,obj)) (SETQ ,endptr ,place)))) ) (DEFUN Macroexpand-All (form &AUX (mac (MACROEXPAND form))) (IF (CONSP form) (CONS (Macroexpand-All (CAR mac)) (Macroexpand-All (CDR mac))) mac)) It would be easier to implement the collect macro if a function like LOCF existed. Furthermore, we would not need to check the partially constructed list each time to determine whether it was still empty (see the COND in #'Collect). ZetaLISP's LOOP macro includes the collect facility, but collection should be possible outside of a loop (for example, when searching through a graph). David Loewenstern Mark Silbert Naval Air Development Center, code 7013 Warminster, PA 18974  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 5 Jun 87 17:44:23 EDT Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 5 Jun 87 13:59:51 PDT Received: from boethius by Think.COM via CHAOS; Fri, 5 Jun 87 17:01:16 EDT Date: Fri, 5 Jun 87 16:59 EDT From: Guy Steele Subject: historical question about CASE To: SOLEY@xx.lcs.mit.edu, barmar@think.com Cc: common-lisp@sail.stanford.edu, sandra%orion@cs.utah.edu, gls@think.com In-Reply-To: Message-Id: <870605165904.4.GLS@BOETHIUS.THINK.COM> Date: Fri, 5 Jun 1987 16:11 EDT From: SOLEY@xx.lcs.mit.edu Date: Friday, 5 June 1987 14:41-EDT From: Barry Margolin To: Sandra J Loosemore Date: Fri, 5 Jun 87 11:19:20 MDT From: sandra%orion@cs.utah.edu (Sandra J Loosemore) While porting some code between CL implementations, I got bit . . . Does anyone remember why it was decided to treat NIL as a list instead of a symbol in this context? I don't remember specifically, but I would guess that it is for the benefit of macros that take a lists of things and turn them into case clauses. For example: (defmacro do-something (thing &key allow-list ignore-list complain-list) `(case ,thing (,allow-list (frob-thing ,thing)) (,ignore-list nil) (,complain-list (error "I won't frob ~S!" ,thing)))) Silly Programmer, hacks are for kids. That's no reason. (defmacro do-something (thing &key allow-list ignore-list complain-list) (append `(case ,thing) (if allow-list `((,allow-list (frob-thing ,thing)))) .. etc .. )) -- Richard Why APPEND? What's wrong with this: (defmacro do-something (thing &key allow-list ignore-list complain-list) `(case ,thing ,@(when allow-list `((,allow-list (frob-thing ,thing)))) ,@(when ignore-list `((,ignore-list nil))) ,@(when complain-list `((,complain-list (error "I won't frob ~S!" ,thing)))))) I use the idiom ",@(when foo `(...baz...))" a LOT. But indeed, perhaps () as a case item should not have been made to mean an empty list. But it's probably too late now. --Guy  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 5 Jun 87 17:39:08 EDT Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 5 Jun 87 13:59:51 PDT Received: from occam by Think.COM via CHAOS; Fri, 5 Jun 87 17:01:33 EDT Date: Fri, 5 Jun 87 16:59 EDT From: Barry Margolin Subject: historical question about CASE To: SOLEY@xx.lcs.mit.edu Cc: common-lisp@sail.stanford.edu, Sandra J Loosemore In-Reply-To: Message-Id: <870605165918.7.BARMAR@OCCAM.THINK.COM> Date: Fri, 5 Jun 1987 16:11 EDT From: SOLEY@xx.lcs.mit.edu (defmacro do-something (thing &key allow-list ignore-list complain-list) `(case ,thing (,allow-list (frob-thing ,thing)) (,ignore-list nil) (,complain-list (error "I won't frob ~S!" ,thing)))) Silly Programmer, hacks are for kids. That's no reason. (defmacro do-something (thing &key allow-list ignore-list complain-list) (append `(case ,thing) (if allow-list `((,allow-list (frob-thing ,thing)))) .. etc .. )) I don't know about you, but I find mine much easier to read. barmar  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 5 Jun 87 16:56:21 EDT Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 5 Jun 87 13:12:44 PDT Date: Fri, 5 Jun 1987 16:11 EDT Message-ID: From: SOLEY@XX.LCS.MIT.EDU To: Barry Margolin Cc: common-lisp@SAIL.STANFORD.EDU, Sandra J Loosemore Subject: historical question about CASE In-reply-to: Msg of 5 Jun 1987 14:41-EDT from Barry Margolin Date: Friday, 5 June 1987 14:41-EDT From: Barry Margolin To: Sandra J Loosemore Date: Fri, 5 Jun 87 11:19:20 MDT From: sandra%orion@cs.utah.edu (Sandra J Loosemore) While porting some code between CL implementations, I got bit . . . Does anyone remember why it was decided to treat NIL as a list instead of a symbol in this context? I don't remember specifically, but I would guess that it is for the benefit of macros that take a lists of things and turn them into case clauses. For example: (defmacro do-something (thing &key allow-list ignore-list complain-list) `(case ,thing (,allow-list (frob-thing ,thing)) (,ignore-list nil) (,complain-list (error "I won't frob ~S!" ,thing)))) Silly Programmer, hacks are for kids. That's no reason. (defmacro do-something (thing &key allow-list ignore-list complain-list) (append `(case ,thing) (if allow-list `((,allow-list (frob-thing ,thing)))) .. etc .. )) -- Richard  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 5 Jun 87 15:13:22 EDT Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 5 Jun 87 11:42:34 PDT Received: from occam by Think.COM via CHAOS; Fri, 5 Jun 87 14:44:06 EDT Date: Fri, 5 Jun 87 14:41 EDT From: Barry Margolin Subject: historical question about CASE To: Sandra J Loosemore Cc: common-lisp@sail.stanford.edu In-Reply-To: <8706051719.AA26939@orion.utah.edu> Message-Id: <870605144148.3.BARMAR@OCCAM.THINK.COM> Date: Fri, 5 Jun 87 11:19:20 MDT From: sandra%orion@cs.utah.edu (Sandra J Loosemore) While porting some code between CL implementations, I got bit by the fine print in the manual about how NIL was not allowed as a singleton key in CASE, as it could be confused with an empty key list. It's easy enough to wrap a pair of parentheses around the NIL, but I got to thinking that an empty key list is not very interesting anyway. Does anyone remember why it was decided to treat NIL as a list instead of a symbol in this context? Just curious, -Sandra ------- I don't remember specifically, but I would guess that it is for the benefit of macros that take a lists of things and turn them into case clauses. For example: (defmacro do-something (thing &key allow-list ignore-list complain-list) `(case ,thing (,allow-list (frob-thing ,thing)) (,ignore-list nil) (,complain-list (error "I won't frob ~S!" ,thing)))) By the way, this is probably a good time to remind people that if they write macros that make a case clause out of each element of a list, they should always make them be lists of one element, not singleton keys. Here's a trivial example: (defmacro my-case (object &rest clauses) "Like CASE, but only takes singleton keys." `(case .,(loop for (key . consequent) in clauses ;I know it isn't CL LOOP collect `((,key) .,consequent)))) barmar  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 5 Jun 87 13:37:25 EDT Received: from CS.UTAH.EDU by SAIL.STANFORD.EDU with TCP; 5 Jun 87 10:17:49 PDT Received: by cs.utah.edu (5.54/utah-1.0) id AA22787; Fri, 5 Jun 87 11:19:24 MDT Received: by orion.utah.edu (5.54/utah-1.0-slave) id AA26939; Fri, 5 Jun 87 11:19:20 MDT Date: Fri, 5 Jun 87 11:19:20 MDT From: sandra%orion@cs.utah.edu (Sandra J Loosemore) Message-Id: <8706051719.AA26939@orion.utah.edu> Subject: historical question about CASE To: common-lisp@sail.stanford.edu While porting some code between CL implementations, I got bit by the fine print in the manual about how NIL was not allowed as a singleton key in CASE, as it could be confused with an empty key list. It's easy enough to wrap a pair of parentheses around the NIL, but I got to thinking that an empty key list is not very interesting anyway. Does anyone remember why it was decided to treat NIL as a list instead of a symbol in this context? Just curious, -Sandra -------  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 5 Jun 87 10:56:03 EDT Received: from ATHENA.MIT.EDU by SAIL.STANFORD.EDU with TCP; 5 Jun 87 07:34:35 PDT Received: by ATHENA (5.45/4.7) id AA03976; Fri, 5 Jun 87 10:35:33 EDT From: Received: by HADES.MIT.EDU (5.45/4.7) id AA16032; Fri, 5 Jun 87 10:31:50 EDT Message-Id: <8706051431.AA16032@HADES.MIT.EDU> To: common-lisp@sail.stanford.edu Subject: Re: Interpretation Needed for #+feature Date: Fri, 05 Jun 87 10:31:49 EDT One of the many unimplemented features of Golden Common Lisp is *READ-SUPPRESS*, which is why GCLisp does the wrong thing with #+ and #-. (See page 345 of CLtL.) I have successfully gotten around the problem by redefining the #+ and #- reader macros to do the following instead of binding *READ-SUPPRESS*: Copy the current readtable and save it. Modify the entry for #\: to make it behave the same as #\A. Read the suppressed form. Restore the old readtable. Even this is not easy because, although GCLisp has readtables, it is missing the standard readtable functions. Send me mail if you need help. --Stuart A. Malone  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 5 Jun 87 03:07:39 EDT Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 4 Jun 87 23:50:29 PDT Received: from MCC.COM by SU-SCORE.ARPA with TCP; Thu 4 Jun 87 09:26:19-PDT Received: from pp.mcc.com by MCC.COM with TCP; Thu 4 Jun 87 11:23:55-CDT Posted-Date: Thursday, 4 June 1987, 11:23-CDT Message-Id: <8706041624.AA15436@pp.mcc.com> Received: from amber.pp.mcc.com by pp.mcc.com (4.12/KA70505) id AA15436; Thu, 4 Jun 87 11:24:14 cdt Date: Thursday, 4 June 1987, 11:23-CDT From: Sender: krall%pp.mcc.com@mcc.com Subject: Interpretation Needed for #+feature To: common-lisp@SAIL.STANFORD.EDU On some systems (LMI Lambda, KCL) the form below is NOT read (or, at least, I get no complaint): #+symbolics (local-symbolics-package:name a b c) On Golden Common Lisp, however, the reader balks because it cannot resolve local-symbolics-package:name since the package does not exist. Naturally, I prefer the first behavior for writing code to be moved to many different machines. What is the correct interpretation? -Ed Krall Parallel Processing Program Microelectronics and Computer Technology Corporation 3500 West Balcones Center Drive Austin, Texas 78759 (512) 338-3406 ARPA: krall@mcc.com UUCP: {ihnp4,seismo,ctvax}!ut-sally!im4u!milano!mcc-pp!krall  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 4 Jun 87 17:49:25 EDT Received: from ELEPHANT-BUTTE.SCRC.SYMBOLICS.COM by SAIL.STANFORD.EDU with TCP; 4 Jun 87 14:25:10 PDT Received: from WHITE-BIRD.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 181251; Thu 4-Jun-87 17:11:57 EDT Date: Thu, 4 Jun 87 17:12 EDT From: Robert W. Kerns Subject: SIMPLE-VECTOR To: Ram@C.CS.CMU.EDU cc: common-lisp@SAIL.STANFORD.EDU, DALY@IBM.COM, Glenn S. Burke In-Reply-To: Message-ID: <870604171246.5.RWK@WHITE-BIRD.SCRC.Symbolics.COM> Date: Thu, 4 Jun 1987 10:59 EDT From: Ram@C.CS.CMU.EDU Note that the old SIMPLE-VECTOR can easily be defined using SIMPLE-ARRAY: (deftype rwk-array (&optional type size) `(simple-array ,type (,size))) Certainly. My only concern is that I don't think RWK-ARRAY is quite the right name. There's no issue here larger than what name to attach to which concept. It doesn't seem worth the energy it will take to do anything about it.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 4 Jun 87 11:25:13 EDT Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 4 Jun 87 08:02:08 PDT Received: ID ; Thu 4 Jun 87 10:59:34-EDT Date: Thu, 4 Jun 1987 10:59 EDT Message-ID: Sender: RAM@ From: Ram@C.CS.CMU.EDU To: "Robert W. Kerns" Cc: common-lisp@SAIL.STANFORD.EDU, DALY@IBM.COM, "Glenn S. Burke" Subject: SIMPLE-VECTOR In-reply-to: Msg of 3 Jun 1987 18:03-EDT from Robert W. Kerns SIMPLE-VECTOR started out meaning "one dimensional simple array" with exactly the syntax you suggest, and it was changed to the current semantics. I believe this was because Moon argued that that interpretation of simple-vector is fairly useless, at least without an element type being specified. Since under that interpretation, SVREF is useless, it made sense to flush the bletcherous SGVREF and make SVREF do that useful thing. I believe that the SIMPLE-ARRAY type was introduced at the same time. Note that the old SIMPLE-VECTOR can easily be defined using SIMPLE-ARRAY: (deftype rwk-array (&optional type size) `(simple-array ,type (,size))) Rob  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 3 Jun 87 22:14:32 EDT Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 3 Jun 87 18:56:06 PDT Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 163443; Wed 3-Jun-87 21:55:02 EDT Date: Wed, 3 Jun 87 21:54 EDT From: David A. Moon Subject: SIMPLE-VECTOR To: Robert W. Kerns cc: Glenn S. Burke , DALY@ibm.com, common-lisp@sail.stanford.edu In-Reply-To: <870603180301.9.RWK@WHITE-BIRD.SCRC.Symbolics.COM> Message-ID: <870603215451.9.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Wed, 3 Jun 87 18:03 EDT From: Robert W. Kerns Date: Tue, 2 Jun 87 21:54 EDT From: Glenn S. Burke Historically, SIMPLE-VECTOR is a contraction of SIMPLE-GENERAL-VECTOR ....this highly-specific and less useful thing is taking up the obvious name for a less-specific and more flexible and useful thing. What would one call this more useful thing? SIMPLE-VECTOR-MAYBE-NOT-GENERAL? SIMPLE-VECTOR-SPECIALIZED? SIMPLE-VECTOR-TWO-ARGUMENTS? (SIMPLE-ARRAY * 1). I don't think we need to add even more names for subtypes of ARRAY to Common Lisp; there are already too many. I of course would prefer to remove the whole concept of "simple arrays" from Common Lisp. But it's certainly not my decision.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 3 Jun 87 18:40:27 EDT Received: from SCRC-YUKON.ARPA by SAIL.STANFORD.EDU with TCP; 3 Jun 87 15:05:25 PDT Received: from WHITE-BIRD.SCRC.Symbolics.COM by YUKON.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 218481; Wed 3-Jun-87 18:03:12 EDT Date: Wed, 3 Jun 87 18:03 EDT From: Robert W. Kerns Subject: SIMPLE-VECTOR To: Glenn S. Burke cc: DALY@ibm.com, common-lisp@sail.stanford.edu In-Reply-To: <870602215436.6.GSB@DWORKIN.PALLADIAN.COM> Message-ID: <870603180301.9.RWK@WHITE-BIRD.SCRC.Symbolics.COM> Date: Tue, 2 Jun 87 21:54 EDT From: Glenn S. Burke Historically, SIMPLE-VECTOR is a contraction of SIMPLE-GENERAL-VECTOR, i.e. (SIMPLE-ARRAY T (*)) -- it IS intentionally like SIMPLE-STRING. The name got contracted because many got bent out of shape by the length of SIMPLE-GENERAL-VECTOR, and I guess no one argued (strongly enough?) against the inconsistent nomenclature. I was just guessing, since I didn't pay attention when this was discussed. I think this has caused enough confusion to require attention and an eventual change, but I am against any reinterpretation of the meaning in the current CL incarnation. Without looking, i would bet that the only inconsistency is in the name itself, and the manual is fairly clear on what it means. Right, I believe the manual is consistant. Perhaps the cleanup to be done here is to note (in the next printing of the manual?) that the terminology is is inconsistant. Unfortunately, leaving it inconsistant means this highly-specific and less useful thing is taking up the obvious name for a less-specific and more flexible and useful thing. What would one call this more useful thing? SIMPLE-VECTOR-MAYBE-NOT-GENERAL? SIMPLE-VECTOR-SPECIALIZED? SIMPLE-VECTOR-TWO-ARGUMENTS?  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 3 Jun 87 13:19:00 EDT Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 3 Jun 87 10:04:20 PDT Received: from boethius by Think.COM via CHAOS; Wed, 3 Jun 87 13:06:50 EDT Date: Wed, 3 Jun 87 13:04 EDT From: Guy Steele Subject: Latin To: common-lisp@sail.stanford.edu Cc: gls@think.com Message-Id: <870603130434.8.GLS@BOETHIUS.THINK.COM> Date: Fri, 22 May 1987 11:14 EDT From: "Scott E. Fahlman" Implementors are informally encouraged to print either the decimal equivalent, or else the phrase GUIDO CANTABRIGIENSIS PERDITOR PERDELIRUS OK, somebody has to ask: What, O mighty and imponederable Quux, does this phrase mean in English, if indeed it is translatable and not too obscene for transmission via netmail? How does "Guy of Cambridge, that brain-damaged loser" grab you?  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 3 Jun 87 11:05:54 EDT Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 3 Jun 87 07:39:40 PDT Received: from LIVE-OAK.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 3 Jun 87 10:38-EDT Received: from PALLADIAN-JASPER.DialNet.Symbolics.COM by LIVE-OAK.LCS.MIT.EDU.ARPA via DIAL with SMTP id 45438; 3 Jun 87 10:23:47-EDT Received: from DWORKIN.Palladian.COM by JASPER.Palladian.COM via INTERNET with SMTP id 1187; 2 Jun 87 21:55:44-EDT Date: Tue, 2 Jun 87 21:54 EDT From: Glenn S. Burke Subject: SIMPLE-VECTOR To: RWK@YUKON.SCRC.Symbolics.COM, DALY@ibm.com cc: common-lisp@sail.stanford.edu In-Reply-To: <870601221248.6.RWK@WHITE-BIRD.SCRC.Symbolics.COM> Message-ID: <870602215436.6.GSB@DWORKIN.PALLADIAN.COM> Reply-To: Glenn S. Burke Date: Mon, 1 Jun 87 22:12 EDT From: Robert W. Kerns Date: 1 June 1987, 11:24:47 EDT From: Timothy Daly . . . Is (SIMPLE-VECTOR T) valid? (semantics: (SIMPLE-VECTOR T *)) No. I don't know why you thought it might, so I'm not sure this is the most helpful answer, but I think p47 is pretty clear that SIMPLE-VECTOR takes only a single argument, a size. I.e. (SIMPLE-VECTOR 47) = (SIMPLE-ARRAY T 47). However, I think this is really also a bug in the manual, and that it is SUPPOSED to take two arguments, like you apparently thought, and it was accidentally edited to take arguments like SIMPLE-STRING instead of SIMPLE-ARRAY. Unfortunately, we've been using the manual to specify the language, and at this point I think this would have to be regarded as an incompatible change. (I still think we should fix it; SIMPLE-VECTOR is of much less use as currently defined, and quite confusing). If we fix it as described, then the answer to your question is YES. Historically, SIMPLE-VECTOR is a contraction of SIMPLE-GENERAL-VECTOR, i.e. (SIMPLE-ARRAY T (*)) -- it IS intentionally like SIMPLE-STRING. The name got contracted because many got bent out of shape by the length of SIMPLE-GENERAL-VECTOR, and I guess no one argued (strongly enough?) against the inconsistent nomenclature. I think this has caused enough confusion to require attention and an eventual change, but I am against any reinterpretation of the meaning in the current CL incarnation. Without looking, i would bet that the only inconsistency is in the name itself, and the manual is fairly clear on what it means.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 1 Jun 87 22:49:06 EDT Received: from SCRC-YUKON.ARPA by SAIL.STANFORD.EDU with TCP; 1 Jun 87 19:28:51 PDT Received: from WHITE-BIRD.SCRC.Symbolics.COM by YUKON.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 217124; Mon 1-Jun-87 22:12:56 EDT Date: Mon, 1 Jun 87 22:12 EDT From: Robert W. Kerns Subject: type specifiers To: Timothy Daly cc: common-lisp@sail.stanford.edu In-Reply-To: <060187.112448.daly@ibm.com> Message-ID: <870601221248.6.RWK@WHITE-BIRD.SCRC.Symbolics.COM> Date: 1 June 1987, 11:24:47 EDT From: Timothy Daly CLtL states that (SIMPLE-VECTOR *) is an abbreviation for (VECTOR T *) except that the elements are of type simple vector (p47) [This doesn't relate to your question, but...] A serious bit of miswording, that. It should have said "except that it additionally specifies that OBJECTS OF THE TYPE are @I(simple) arrays." I don't have a current list of corrections to the manual; is this on it already? CLtL states that If a type specifier is a list, the car of the list is a symbol and the rest of the list is subsidiary type information. ... (p42) [I'm not sure how this part relates to your question.] CLtL state that As a convenience, if a list has one or more unspecified items at the end, such items may simply be dropped rather than writing an explicit * for each one. (p43) Is (SIMPLE-VECTOR T) valid? (semantics: (SIMPLE-VECTOR T *)) No. I don't know why you thought it might, so I'm not sure this is the most helpful answer, but I think p47 is pretty clear that SIMPLE-VECTOR takes only a single argument, a size. I.e. (SIMPLE-VECTOR 47) = (SIMPLE-ARRAY T 47). However, I think this is really also a bug in the manual, and that it is SUPPOSED to take two arguments, like you apparently thought, and it was accidentally edited to take arguments like SIMPLE-STRING instead of SIMPLE-ARRAY. Unfortunately, we've been using the manual to specify the language, and at this point I think this would have to be regarded as an incompatible change. (I still think we should fix it; SIMPLE-VECTOR is of much less use as currently defined, and quite confusing). If we fix it as described, then the answer to your question is YES. tim DALY@IBM.COM  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 1 Jun 87 12:05:34 EDT Received: from IBM.COM by SAIL.STANFORD.EDU with TCP; 1 Jun 87 08:37:05 PDT Date: 1 June 1987, 11:24:47 EDT From: Timothy Daly To: common-lisp@sail.stanford.edu Message-Id: <060187.112448.daly@ibm.com> Subject: type specifiers CLtL states that (SIMPLE-VECTOR *) is an abbreviation for (VECTOR T *) except that the elements are of type simple vector (p47) CLtL states that If a type specifier is a list, the car of the list is a symbol and the rest of the list is subsidiary type information. ... (p42) CLtL state that As a convenience, if a list has one or more unspecified items at the end, such items may simply be dropped rather than writing an explicit * for each one. (p43) Is (SIMPLE-VECTOR T) valid? (semantics: (SIMPLE-VECTOR T *)) tim DALY@IBM.COM  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 25 May 87 13:45:12 EDT Received: from EDDIE.MIT.EDU by SAIL.STANFORD.EDU with TCP; 25 May 87 10:32:31 PDT Received: by EDDIE.MIT.EDU with UUCP with smail2.3 with sendmail-5.31/4.7 id ; Mon, 25 May 87 13:30:19 EDT Received: by primerd.prime.com (1.1/SMI-3.0DEV3/smail) id AA01965; Mon, 25 May 87 11:28:04 EDT Message-Id: <8705251528.AA01965@primerd.prime.com> Received: (from user DOUG) by ENX.Prime.PDN; 25 May 87 11:06:33 EST Subject: Revision 2.1 of public defsystem available To: common-lisp@sail.stanford.edu From: primerd!DOUG@ENX.Prime.PDN Date: 25 May 87 11:06:33 EST There is a new version of defsys available for public ftp from SAIL. This version has make-pathname instead of concatenate for constructing source and binary paths and so will work on systems that don't have regularly formed pathnames. This version should also compile without any errors or warnings. Cheers, Doug (doug@enx.prime.com)  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 25 May 87 08:08:50 EDT Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 25 May 87 04:59:23 PDT Date: Mon 25 May 87 07:58:15-EDT From: "Gail Zacharias" Subject: All arrays can be adjustable? To: common-lisp@SAIL.STANFORD.EDU Message-ID: <12305170113.39.GZ@OZ.AI.MIT.EDU> The description of ADJUST-ARRAY (bottom of p. 297) says "It is not permitted to call adjust-array on an array that was not created with the :adjustable option." Of course, assuming "not permitted" means "is an error" rather than "signals an error", an implementation is free to make an extension to CL and have ADJUST-ARRAY work on some arrays which weren't created with the :ADJUSTABLE option, and non-portable code is free to take advantage of such an extension. It seems rather pointless to me, however. Unless the user has detailed knowledge of exactly which combinations of other arguments to MAKE-ARRAY will allow ADJUST-ARRAY to work, he has no business trying to adjust an array which he didn't ask to be adjustable. A friendly implementation would signal an error, at least when running in a safe mode. -------  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 22 May 87 19:25:22 EDT Received: from [192.10.41.109] by SAIL.STANFORD.EDU with TCP; 22 May 87 16:09:40 PDT Received: from CHICOPEE.SCRC.Symbolics.COM by ALDERAAN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 84991; Fri 22-May-87 19:09:02 EDT Date: Fri, 22 May 87 19:08 EDT From: Daniel L. Weinreb Subject: defsystem To: primerd!DOUG@ENX.Prime.PDN, COMMON-LISP@SAIL.STANFORD.EDU In-Reply-To: <8705222127.AA16674@primerd.prime.com> Message-ID: <870522190809.5.DLW@CHICOPEE.SCRC.Symbolics.COM> I thought this would be a nice test case to see how good Common Lisp is for making portable code, so I tried it out. It looks as if the function COMPILE-IF-NEEDED needs to have a declaration, saying (DECLARE (SPECIAL SYSTEM COMPILED-MODULES)) in it, in order to work properly. Does your CL implementation work without such a declaration? If so, you might want to check into that, since it oughtn't, if I'm not mistaken. It would also be nice to put in (DECLARE (IGNORE LEVEL)) in the functions PRINT-SYSTEM and PRINT-MODULE, just to suppress the compiler warnings. There are a few places that manipulate pathnames by using concatenate to append a file name to a directory name. That'll work OK with the PRIME file system (and Symbolics's file system), but it won't with several others, because syntaxes vary. It should use the pathname manipulation functions in CL. I tried running it on a simple case. It signalled an error, trying to find the file-write-date of a bin file that didn't exist yet, because the source file (which I had just created) had never been compiled. This appears to be our bug; file-write-date is supposed to return NIL "if it cannot be determined". After I fixed this, compile-system, load-system, and show-system appeared to work properly.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 22 May 87 18:12:24 EDT Received: from EDDIE.MIT.EDU by SAIL.STANFORD.EDU with TCP; 22 May 87 14:49:32 PDT Received: by EDDIE.MIT.EDU with UUCP with smail2.3 with sendmail-5.31/4.7 id ; Fri, 22 May 87 17:47:10 EDT Received: by primerd.prime.com (1.1/SMI-3.0DEV3/smail) id AA16674; Fri, 22 May 87 17:27:10 EDT Message-Id: <8705222127.AA16674@primerd.prime.com> Received: (from user DOUG) by ENX.Prime.PDN; 22 May 87 16:34:47 EST To: COMMON-LISP@SAIL.STANFORD.EDU From: primerd!DOUG@ENX.Prime.PDN Date: 22 May 87 16:34:48 EST To: (common-lisp@sail.stanford.edu) From: Doug Rand (DOUG@ENX.PRIME.COM) Date: 22 May 87 4:25 PM Subject: Portable public domain DEFSYSTEM available for use I have a defsystem and associated utilities that others may find useful. I have made the code available for use on SAIL via anonymous ftp from defsys.lsp[com,lsp] and the documentation from defsys.doc[com,lsp]. (Many thanks to Dick Gabriel for putting them up for me) The usual caveats apply about no warrantty expressed or implied. You can pass the source and documentation on to others but I ask that enhancements get funnelled back through me. Modification for your own use is, of course, no problem. Some effort has been made in options to use existing names for items where appropriate but this really isn't a direct copy of the functionality of the ZETALISP defsystem facility on the LISPM. Cheers, Doug --------------------------- An abbreviated description: --------------------------- (defsystem system-name (system-options*) module-descriptions* ) Compile-system (function) (compile-system system-name {keys}) Compiles all modules requiring recompilation. The recompile keyword will cause all recompilations to occur regardless of 'need'. Need is determined by the date-time of the respective binary and source files. (load-system system-name {keys}) Loads modules of a system. Load-system is called recursively for all required systems. Keyword options are: (show-system system-name) Pretty output of system description.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 22 May 87 16:16:26 EDT Received: from VAXA.ISI.EDU by SAIL.STANFORD.EDU with TCP; 22 May 87 12:56:57 PDT Posted-Date: Fri, 22 May 87 12:56:46 PDT Message-Id: <8705221956.AA04810@vaxa.isi.edu> Received: from LOCALHOST by vaxa.isi.edu (5.54/5.51) id AA04810; Fri, 22 May 87 12:56:48 PDT To: common-lisp@sail.stanford.edu Subject: :KEY, hairsplit Date: Fri, 22 May 87 12:56:46 PDT From: Richard Berman I have an implementation here which interprets the :KEY keyword of SUBLIS as applying to the ALIST. Consistency seems to demand that it applies to the TREE. For example, the code for SUBST on page 274, and the description of :KEY on 246. Nevertheless, with the description on 246 I couldn't say that they are wrong in applying it to ALIST: "If an operation tests elements of a sequence in any manner, the keyword argument :key, if not nil, should be a function of one argument that will extract from an element the part to be tested in place of the whole element." But in SUBLIS, both ALIST and TREE are being "tested". But since it is TREE that would be affected, and since things like SUBST, SUBSTITUTE and relatives, all use :key on the effected sequence, it would be inconsistent for :key to work on ALIST as above. Strictly speaking, I could see how an implementor could interpret pg 246 to mean applying :key to both ALIST and TREE. Especially because the only description of :key is in the Sequence chapter, and despite the fact that :key is used in a number of places in the LISTS chapter, it is not defined, leaving one with the sequence definition Page 273 says "The naming conventions for these functions and for their keyword arguments generally follow the conventions for the generic sequence functions." Fine. I am sure most will agree to my interpretation -- That ALIST does not get :key applied to it, and TREE does. I am trying to convert some of one manufacturer's tests to the standard format, and ran into this goody. Any official word? RB  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 22 May 87 11:26:09 EDT Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 22 May 87 08:14:57 PDT Received: ID ; Fri 22 May 87 11:14:30-EDT Date: Fri, 22 May 1987 11:14 EDT Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: Guy Steele Cc: common-lisp@SAIL.STANFORD.EDU Subject: numerals, Roman, large, overly, printing of, how to do it In-reply-to: Msg of 22 May 1987 10:55-EDT from Guy Steele Implementors are informally encouraged to print either the decimal equivalent, or else the phrase GUIDO CANTABRIGIENSIS PERDITOR PERDELIRUS OK, somebody has to ask: What, O mighty and imponederable Quux, does this phrase mean in English, if indeed it is translatable and not too obscene for transmission via netmail? My Latin stopped with "Sic Friat Crustulum": So crumbles the cookie. (Actually, I think it's "biscuit" -- the Romans seem not have had cookies in the modern sense, since Cortes had not yet conquered the land where chocolate chips grow.) -- Scott  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 22 May 87 11:14:07 EDT Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 22 May 87 08:00:50 PDT Received: from boethius by Think.COM via CHAOS; Fri, 22 May 87 10:58:47 EDT Date: Fri, 22 May 87 10:55 EDT From: Guy Steele Subject: numerals, Roman, large, overly, printing of, how to do it To: berman@vaxa.isi.edu, las@bfly-vax.bbn.com Cc: common-lisp@sail.stanford.edu, gls@think.com In-Reply-To: <8705201905.AA02808@vaxa.isi.edu> Message-Id: <870522105532.3.GLS@BOETHIUS.THINK.COM> Date: Wed, 20 May 87 12:05:53 PDT From: Richard Berman My only question re: roman numerals is: what does *common lisp* do for values above the specified range (or unspecified, so far as the spec is concerned). Do we just not print romans above certain values? What is printed instead? Etc.? RB Implementors are informally encouraged to print either the decimal equivalent, or else the phrase GUIDO CANTABRIGIENSIS PERDITOR PERDELIRUS --Quux  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 22 May 87 11:03:08 EDT Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 22 May 87 07:48:04 PDT Received: from boethius by Think.COM via CHAOS; Fri, 22 May 87 10:49:17 EDT Date: Fri, 22 May 87 10:46 EDT From: Guy Steele Subject: Re: More FORMAT To: berman@vaxa.isi.edu, DFM%JASPER@live-oak.lcs.mit.edu Cc: common-lisp@sail.stanford.edu, gls@think.com In-Reply-To: <8705201855.AA02717@vaxa.isi.edu> Message-Id: <870522104659.2.GLS@BOETHIUS.THINK.COM> Date: Wed, 20 May 87 11:55:34 PDT From: Richard Berman As someone else mentioned, it can be more than useful to know that something is causing an array to grow. It seems reduntant to me to have an :adjustable keyword if there are no clear semantics to :adjustable nil, only to :adjustable T. Especially when :adjustable (non-nil) == :adjustable nil. Or perhaps we need a :non-adjustable keyword, just to keep our semantics consistent, where :non-adjustable T means "definitely" non-adjustable, and :non-adjustable nil means "maybe non-adjustable"? RB It is not redundant. It is, however, in some sense merely an efficiency hint. :ADJUSTABLE NIL is a promise on the part of the programmer never to try to adjust the array. The value of this promise is that the implementation may then be able to create an array that uses less time or space. --Guy  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 22 May 87 10:43:04 EDT Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 22 May 87 07:29:17 PDT Received: from boethius by Think.COM via CHAOS; Fri, 22 May 87 10:28:41 EDT Date: Fri, 22 May 87 10:26 EDT From: Guy Steele Subject: All arrays can be adjustable? To: DFM%JASPER@live-oak.lcs.mit.edu, edsel!bhopal!jonl@navajo.stanford.edu Cc: navajo!DLA%DIAMOND.S4CC.Symbolics.COM@navajo.stanford.edu, navajo!sandra%orion%cs.utah.edu@navajo.stanford.edu, common-lisp@sail.stanford.edu In-Reply-To: <870521152017.2.DFM@WHITBY.PALLADIAN.COM> Message-Id: <870522102614.1.GLS@BOETHIUS.THINK.COM> Date: Thu, 21 May 87 15:20 EDT From: Don Morrison Date: Wed, 20 May 87 22:45:04 PDT From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White) See CLtL page 34 where simple-array is defined as a subtype of array. Note also that everywhere "subtype" is used, it means "proper subtype". CLtL, page 33: "If x is a supertype of y, then any object of type y is also of type x, and y is said to be a subtype of x." Doesn't sound like "proper subtype" to me. Also, in both Symbolics and Lucid, (subtypep x x) => t for every type I tried. CLTL page 72: "This predicate [subtypep] is true if type1 is a (not necessarily proper) subtype of type2." --Guy  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 22 May 87 10:31:58 EDT Received: from [192.10.41.109] by SAIL.STANFORD.EDU with TCP; 22 May 87 07:18:14 PDT Received: from CHICOPEE.SCRC.Symbolics.COM by ALDERAAN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 84675; Fri 22-May-87 10:17:45 EDT Date: Fri, 22 May 87 10:17 EDT From: Daniel L. Weinreb Subject: Re: Order of evaluation in general To: Randy%acorn@oak.lcs.mit.edu, common-lisp@sail.stanford.edu In-Reply-To: The message of 22 May 87 02:55 EDT from Randy%acorn@oak.lcs.mit.edu Message-ID: <870522101716.4.DLW@CHICOPEE.SCRC.Symbolics.COM> Date: Fri, 22 May 87 02:55 EDT From: Randy%acorn@oak.lcs.mit.edu I realize that it was explicitly stated (somewhere) that Common Lisp is ignoring issues of parallelism. Given that parellel is going to be the next fad, it's probably time to start thinking about parallel issues. It's certainly time for many people and many groups to be thinking about parallel issues, and many are. But I don't think X3J13 is the right forum for that. Standardization is a very different activity from language exploration and design. Imposing the constraints of the former on the latter would be a mistake. It's not time yet to standardize on parallelism in Lisp; it's time to try things out and gain experience. That can be done best the way Lisp has always grown: experimentation in environments that encourage creativity and freedom, rather than the practical constraints of ANSI standardization.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 22 May 87 05:02:25 EDT Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 22 May 87 01:52:18 PDT Received: from LIVE-OAK.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 22 May 87 04:50-EDT Received: from GOLD-HILL-ACORN.DialNet.Symbolics.COM by MIT-LIVE-OAK.ARPA via DIAL with SMTP id 43818; 22 May 87 04:52:54-EDT Received: from PINK-FLOYD.Gold-Hill.DialNet.Symbolics.COM by ACORN.Gold-Hill.DialNet.Symbolics.COM via CHAOS with CHAOS-MAIL id 70302; Fri 22-May-87 02:56:02-EDT Date: Fri, 22 May 87 02:55 EDT From: Randy%acorn@oak.lcs.mit.edu To: common-lisp@sail.stanford.edu Subject: Re: Order of evaluation in general From: larus%paris.Berkeley.EDU@berkeley.edu (James Larus) Date: Thu, 21 May 87 09:43:16 PDT Leaving the order of evaluation of actual parameters unspecified (a la Scheme) would help some serial, as well as parallel, implementations. ... I realize that it was explicitly stated (somewhere) that Common Lisp is ignoring issues of parallelism. Given that parellel is going to be the next fad, it's probably time to start thinking about parallel issues. In addition to special forms like PROGN-IN-ANY-ORDER (or some more aesthetic name), there should be versions of DO-family and MAP-family functions that could frotz with order however they wanted. Random  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 21 May 87 17:34:08 EDT Received: from [128.32.150.46] by SAIL.STANFORD.EDU with TCP; 21 May 87 14:11:15 PDT Received: by paris.Berkeley.EDU (5.57/1.25) id AA25054; Thu, 21 May 87 14:08:44 PDT From: larus%paris.Berkeley.EDU@berkeley.edu (James Larus) Message-Id: <8705212108.AA25054@paris.Berkeley.EDU> To: David A. Moon Cc: P. T. Withington , Scott E. Fahlman , quiroz@cs.rochester.edu, common-lisp@sail.stanford.edu Subject: Re: Order of evaluation in PUSH (& PUSHNEW) In-Reply-To: Your message of Thu, 21 May 87 16:42:00 EDT. <870521164208.9.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Thu, 21 May 87 14:08:36 PDT Date: Thu, 21 May 87 14:19 EDT From: P. T. Withington I see no reason to require evaluation order of arguments when there is already a mechanism to enforce it: use LET* where evaluation order is important. A good compiler should be able to optimize away the implied temporaries when the expressed evaluation order matches the implementation evaluation order. Remember that Common Lisp is a language with side-effects, and in such languages there are more constraints on evaluation order than just the data dependencies. With LET* you are talking data dependencies. In discussing side-effects between the evaluation of formal arguments, we are also talking about data-dependencies. Taking a page from the vector processor and multiprocessor compiler literature: a data-dependence between two statements occurs when one statement writes a value into a location and another statement either reads or writes this location. This gives us three types of data-dependencies: W(rite) followed by R(read), R followed by W, and W followed by W. Moon is expressing the common belief that all data-dependencies are of the first type, as for example: (LET* ((A (FOO)) (B (BAR A))) ...) in which the first clause of the LET* statement writes a value into the location called `a' and the second reads the same location (W-R for short). However, there is no fundamental difference between this example and the following one (R-W): (REORDER-AND-DIE ARG (SETQ ARG 1)) The major difference between the two is that a larger group of people would probably object to the latter example on grounds of taste. In any case, Scott Fahlman explained quite clearly in an earlier message why Common Lisp takes the stand it does. I think that reasoning is just as true today as it was three years ago. As I tried to suggest in my earlier note, there are strong reasons apart from multiprocessor Lisps why Common Lisp's stand is an unnecessary constraint on the language. The status quo be better defended on two grounds: I like side-effects and want predictability without having to introduce additional sequence constraints like LET* and PROGN or this is a major change that will break a lot of code. Multiprocessors are just a red-herring. /Jim  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 21 May 87 17:02:48 EDT Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 21 May 87 13:46:57 PDT Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 146808; Thu 21-May-87 16:42:06 EDT Date: Thu, 21 May 87 16:42 EDT From: David A. Moon Subject: Re: Order of evaluation in PUSH (& PUSHNEW) To: P. T. Withington cc: James Larus , Scott E. Fahlman , quiroz@cs.rochester.edu, common-lisp@sail.stanford.edu In-Reply-To: <870521141924.9.PTW@TIGGER.S4CC.Symbolics.COM> Message-ID: <870521164208.9.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Thu, 21 May 87 14:19 EDT From: P. T. Withington I see no reason to require evaluation order of arguments when there is already a mechanism to enforce it: use LET* where evaluation order is important. A good compiler should be able to optimize away the implied temporaries when the expressed evaluation order matches the implementation evaluation order. Remember that Common Lisp is a language with side-effects, and in such languages there are more constraints on evaluation order than just the data dependencies. With LET* you are talking data dependencies. In any case, Scott Fahlman explained quite clearly in an earlier message why Common Lisp takes the stand it does. I think that reasoning is just as true today as it was three years ago.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 21 May 87 16:42:09 EDT Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 21 May 87 13:23:42 PDT Received: from XX.LCS.MIT.EDU by navajo.stanford.edu with TCP; Thu, 21 May 87 13:18:58 PDT Received: from LIVE-OAK.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 21 May 87 16:19-EDT Received: from PALLADIAN-JASPER.DialNet.Symbolics.COM by MIT-LIVE-OAK.ARPA via DIAL with SMTP id 43733; 21 May 87 16:20:33-EDT Received: from WHITBY.Palladian.COM by JASPER.Palladian.COM via INTERNET with SMTP id 149; 21 May 87 15:20:33-EDT Date: Thu, 21 May 87 15:20 EDT From: Don Morrison Subject: All arrays can be adjustable? To: edsel!bhopal!jonl@navajo.stanford.edu Cc: navajo!DLA%DIAMOND.S4CC.Symbolics.COM@navajo.stanford.edu, navajo!sandra%orion%cs.utah.edu@navajo.stanford.edu, navajo!common-lisp%sail@navajo.stanford.edu In-Reply-To: <8705210545.AA03359@bhopal.edsel.uucp> Message-Id: <870521152017.2.DFM@WHITBY.PALLADIAN.COM> Reply-To: Don Morrison Date: Wed, 20 May 87 22:45:04 PDT From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White) See CLtL page 34 where simple-array is defined as a subtype of array. Note also that everywhere "subtype" is used, it means "proper subtype". CLtL, page 33: "If x is a supertype of y, then any object of type y is also of type x, and y is said to be a subtype of x." Doesn't sound like "proper subtype" to me. Also, in both Symbolics and Lucid, (subtypep x x) => t for every type I tried.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 21 May 87 15:37:31 EDT Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 21 May 87 12:20:30 PDT Received: ID ; Thu 21 May 87 15:20:04-EDT Date: Thu, 21 May 1987 15:20 EDT Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: Richard Berman Cc: common-lisp@SAIL.STANFORD.EDU Subject: :fill-pointer maybe In-reply-to: Msg of 21 May 1987 14:48-EDT from Richard Berman Sounds fine, though I wouldn't waste a lot of effort looking for extensions to flag. The most important task is to flag those places where an implementation falls short, rather than those places where it does more than it has to. -- Scott  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 21 May 87 15:13:08 EDT Received: from VAXA.ISI.EDU by SAIL.STANFORD.EDU with TCP; 21 May 87 11:56:23 PDT Posted-Date: Thu, 21 May 87 11:55:10 PDT Message-Id: <8705211855.AA10809@vaxa.isi.edu> Received: from LOCALHOST by vaxa.isi.edu (5.54/5.51) id AA10809; Thu, 21 May 87 11:55:28 PDT To: Timothy Daly Cc: common-lisp@sail.stanford.edu, berman@vaxa.isi.edu Subject: Re: validation suite In-Reply-To: Your message of 21 May 87 00:00:00 +0000. <052187.094511.daly@ibm.com> Date: Thu, 21 May 87 11:55:10 PDT From: Richard Berman Dear Tim, Subscribe to CL-VALIDATION@sail.stanford.edu. Get its archive, which is not too long. Look it over. RB  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 21 May 87 15:04:18 EDT Received: from VAXA.ISI.EDU by SAIL.STANFORD.EDU with TCP; 21 May 87 11:48:42 PDT Posted-Date: Thu, 21 May 87 11:48:24 PDT Message-Id: <8705211848.AA10759@vaxa.isi.edu> Received: from LOCALHOST by vaxa.isi.edu (5.54/5.51) id AA10759; Thu, 21 May 87 11:48:27 PDT To: "Scott E. Fahlman" Cc: common-lisp@sail.stanford.edu Subject: Re: :fill-pointer maybe In-Reply-To: Your message of Wed, 20 May 87 19:47:00 -0400. Date: Thu, 21 May 87 11:48:24 PDT From: Richard Berman Scott, I get the picture. What I may be able to do is still put in checks to cause these "is an error" conditions, with messages that if anything other than "strict" results are obtained, the report mentions that it is optional or implementation dependent, or whatever. Like if no error "is signalled" (which would be the strictest interpretation of "is an error"), then I would report that, with the above modifier. How's that sound? RB  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 21 May 87 14:39:38 EDT Received: from [128.81.51.3] by SAIL.STANFORD.EDU with TCP; 21 May 87 11:24:06 PDT Received: from TIGGER.S4CC.Symbolics.COM by DIAMOND.S4CC.Symbolics.COM via CHAOS with CHAOS-MAIL id 88979; Thu 21-May-87 14:19:26 EDT Date: Thu, 21 May 87 14:19 EDT From: P. T. Withington Subject: Re: Order of evaluation in PUSH (& PUSHNEW) To: James Larus , Scott E. Fahlman cc: quiroz@cs.rochester.edu, common-lisp@sail.stanford.edu In-Reply-To: <8705211643.AA24598@paris.Berkeley.EDU> Message-ID: <870521141924.9.PTW@TIGGER.S4CC.Symbolics.COM> I see no reason to require evaluation order of arguments when there is already a mechanism to enforce it: use LET* where evaluation order is important. A good compiler should be able to optimize away the implied temporaries when the expressed evaluation order matches the implementation evaluation order.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 21 May 87 13:34:49 EDT Received: from [192.10.41.109] by SAIL.STANFORD.EDU with TCP; 21 May 87 10:19:46 PDT Received: from CHICOPEE.SCRC.Symbolics.COM by ALDERAAN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 84258; Thu 21-May-87 13:18:16 EDT Date: Thu, 21 May 87 13:17 EDT From: Daniel L. Weinreb Subject: [adjustable arrays?] More FORMAT To: edsel!bhopal!jonl@navajo.stanford.edu cc: common-lisp@sail.stanford.edu In-Reply-To: <8705210227.AA03071@bhopal.edsel.uucp> Message-ID: <870521131752.5.DLW@CHICOPEE.SCRC.Symbolics.COM> Date: Wed, 20 May 87 19:27:34 PDT From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White) Isn't this a bug? It certainly provides a loophole for non-portable code that isn't reasonably detectable as non-portable. No. As Fahlman explained clearly in an earlier message, providing extensions that make it harder to determine portability is in no way a "bug" or "violation of Common Lisp".  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 21 May 87 12:56:51 EDT Received: from [128.32.150.46] by SAIL.STANFORD.EDU with TCP; 21 May 87 09:44:58 PDT Received: by paris.Berkeley.EDU (5.57/1.25) id AA24598; Thu, 21 May 87 09:43:20 PDT From: larus%paris.Berkeley.EDU@berkeley.edu (James Larus) Message-Id: <8705211643.AA24598@paris.Berkeley.EDU> To: "Scott E. Fahlman" Cc: quiroz@cs.rochester.edu, common-lisp@sail.stanford.edu Subject: Re: Order of evaluation in PUSH (& PUSHNEW) In-Reply-To: Your message of Thu, 21 May 87 00:33:00 EDT. Date: Thu, 21 May 87 09:43:16 PDT Leaving the order of evaluation of actual parameters unspecified (a la Scheme) would help some serial, as well as parallel, implementations. Consider a machine that uses registers for passing parameters and evaluating expressions. If a compiler is free to reorder the evaluation of expressions, it can evaluate the more complex ones using the (empty) registers, then evaluate the other ones directly into their target registers. From personal experience on SPUR, this freedom would produce noticeably better code and reduce the number of temporaries that have to be allocated by the register allocator. Of course, some existing programs would break. But a good argument can be made that these programs were dependent an implementation artifact. /Jim PS Did the CL committee ever decide which sentence actually *requires* left-to-right evaluation of formals?  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 21 May 87 12:50:30 EDT Received: from HARVARD.HARVARD.EDU by SAIL.STANFORD.EDU with TCP; 21 May 87 09:38:07 PDT Received: by harvard.harvard.edu; Thu, 21 May 87 12:26:46 EDT Received: by RUTGERS.EDU (5.54/1.14) with UUCP id AA13987; Thu, 21 May 87 12:34:38 EDT Received: by moss.ATT.COM (smail2.5) id AA16386; 21 May 87 11:21:06 EDT (Thu) To: common-lisp@sail.stanford.edu In-Reply-To: "Scott E. Fahlman"'s message of Thu, 30 Apr 1987 16:56 EDT Subject: Re: Notice on Kyoto Common Lisp distribution (query) Date: 21 May 87 11:21:06 EDT (Thu) From: tk@moss.att.com (Tom Kirk) Message-Id: <8705211121.AA16386@moss.ATT.COM> Does anyone have new information about the availability of KCL, or what the distribution mechanism will be? I'd appreciate any current knowledge anyone could pass along. Thanks, tom kirk ------- tk@nosc, tk@moss.att.com  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 21 May 87 10:39:35 EDT Received: from IBM.COM by SAIL.STANFORD.EDU with TCP; 21 May 87 07:25:38 PDT Date: 21 May 1987, 09:45:11 EDT From: Timothy Daly To: common-lisp@sail.stanford.edu Message-Id: <052187.094511.daly@ibm.com> Subject: validation suite Is there a publically available validation suite of programs for common lisp?  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 21 May 87 09:06:56 EDT Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 21 May 87 05:56:39 PDT Received: from DIAMOND.S4CC.Symbolics.COM ([128.81.51.3]) by navajo.stanford.edu with TCP; Thu, 21 May 87 05:52:42 PDT Received: from KOYAANISQATSI.S4CC.Symbolics.COM (KOYAANISQATSI.S4CC.Symbolics.COM) by DIAMOND.S4CC.Symbolics.COM via INTERNET with SMTP id 88819; 21 May 87 08:53:17 EDT Date: Thu, 21 May 87 08:57 EDT From: David C. Plummer Subject: [adjustable arrays?] More FORMAT To: Jon L White , navajo!Moon%STONY-BROOK.SCRC.Symbolics.COM@navajo.stanford.edu Cc: navajo!berman%vaxa.isi.edu@navajo.stanford.edu, navajo!common-lisp%sail@navajo.stanford.edu In-Reply-To: <8705210227.AA03071@bhopal.edsel.uucp> Message-Id: <870521085729.6.DCP@KOYAANISQATSI.S4CC.Symbolics.COM> Date: Wed, 20 May 87 19:27:34 PDT From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White) ... You can imagine how someone using a system that doesn't detect this error will fare when trying to run on another system that really can't adjust simple arrays. "You can imagine how someone using a system that doesn't do number-of-argument checking will fare ..." As I recall, the number-of-argument discussion did happen several months ago, and by the strict reading of CLtL it "is an error" to supply the wrong number of arguments but implementations are not required to "signal an error." To me, this array discussion should fall in the same class: - What "is an error?" - What "signals an error?" - What implementation freedom should there be? - How important are some of these to various parts of the language? For example, I would rank number of argument checking considerably more important than worrying about allowing some systems to adjust even simple arrays.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 21 May 87 02:05:44 EDT Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 20 May 87 22:54:16 PDT Received: by navajo.stanford.edu; Wed, 20 May 87 22:51:50 PDT Received: from bhopal.edsel.uucp by edsel.uucp (2.2/SMI-2.0) id AA01603; Wed, 20 May 87 22:43:20 pdt Received: by bhopal.edsel.uucp (3.2/SMI-3.2) id AA03359; Wed, 20 May 87 22:45:04 PDT Date: Wed, 20 May 87 22:45:04 PDT From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White) Message-Id: <8705210545.AA03359@bhopal.edsel.uucp> To: navajo!DLA%DIAMOND.S4CC.Symbolics.COM@navajo.stanford.edu Cc: navajo!sandra%orion%cs.utah.edu@navajo.stanford.edu, navajo!common-lisp%sail@navajo.stanford.edu In-Reply-To: David L. Andre's message of Tue, 19 May 87 22:21 EDT <870519222134.7.DLA@LIMPKIN.S4CC.Symbolics.COM> Subject: All arrays can be adjustable? Re: I don't think the issue is whether or not users can tell whether arrays are simple or adjustable. . . . Whether or not that is the issue with Loosemore's complaint, it is indeed a requirement of Common Lisp -- a user need only do (typep x 'simple-array). See CLtL page 34 where simple-array is defined as a subtype of array. Note also that everywhere "subtype" is used, it means "proper subtype". -- JonL --  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 21 May 87 01:25:22 EDT Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 20 May 87 22:09:27 PDT Received: from LIVE-OAK.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 21 May 87 01:07-EDT Received: from PALLADIAN-JASPER.DialNet.Symbolics.COM by MIT-LIVE-OAK.ARPA via DIAL with SMTP id 43633; 21 May 87 01:08:30-EDT Received: from CHUGACH.Palladian.COM by JASPER.Palladian.COM via INTERNET with SMTP id 110; 21 May 87 00:44:33-EDT Date: Thu, 21 May 87 00:44 EDT From: Jeff Gibbons Subject: [dg%acorn@oak.lcs.mit.edu: Re: &REST] To: Patrick H Dussud , dg%acorn@LIVE-OAK.LCS.MIT.EDU, Daniel L. Cerys cc: common-lisp@SAIL.STANFORD.EDU, Acuff@SUMEX-AIM.STANFORD.EDU In-Reply-To: <2757506096-3811281@Jenner> Message-ID: <870521004419.0.JEFF@CHUGACH.PALLADIAN.COM> Reply-To: Jeff Gibbons Date: Wed, 20 May 87 08:54:56 CDT From: Patrick H Dussud ... in Release 3, TI ... There are 0 restrictions on using &REST lists outside of the dynamic scope of the parameter. ... Patrick. This claim may be true but don't be fooled into thinking they are fully blessed lists. Try: (defun trouble (&rest x) (rplacd x '(a b c))) (trouble 1 2 3) => Hello, debugger! Jeff Gibbons  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 21 May 87 00:44:16 EDT Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 20 May 87 21:34:39 PDT Received: ID ; Thu 21 May 87 00:34:04-EDT Date: Thu, 21 May 1987 00:33 EDT Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: quiroz@CS.ROCHESTER.EDU Cc: common-lisp@SAIL.STANFORD.EDU Subject: Order of evaluation in PUSH (& PUSHNEW) In-reply-to: Msg of Wed 20 May 87 23:38:50 -0400 from quiroz at cs.rochester.edu In the original design discussions, we briefly considered leaving the order of argument evaluation undefined in order to make life easier for some future parallel version of Common Lisp. However, we felt that the question of what should go into a parallel Lisp was an open research issue (it still is). We decided that designing a good serial Lisp was plenty hard enough, and that worrying about various half-baked ideas for a parallel Lisp would be a distraction we didn't need. So the design went forward with parallel processing explicitly excluded from the design criteria; given that stance, tying down the order of evaluation seemed to be a good idea for portability. Even if we had left order of argument evaluation open, this change by itself would only buy you a factor of two or so on the average, and that's with no overhead for splitting and merging processes. -- Scott  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 20 May 87 23:54:54 EDT Received: from CS.ROCHESTER.EDU by SAIL.STANFORD.EDU with TCP; 20 May 87 20:37:38 PDT Received: by cayuga.cs.rochester.edu (5.52/b) id AA02470; Wed, 20 May 87 23:36:11 EDT Received: from loopback by yed.cs.rochester.edu (3.2/b) id AA00246; Wed, 20 May 87 23:38:54 EDT Message-Id: <8705210338.AA00246@yed.cs.rochester.edu> To: David A. Moon Cc: peck@Sun.COM, common-lisp@sail.stanford.edu Summary: Left to right seems correct. Unspecified might be better. Subject: Re: Order of evaluation in PUSH (& PUSHNEW) In-Reply-To: Your message of Wed, 20 May 87 20:56:00 -0400. <870520205618.1.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Wed, 20 May 87 23:38:50 -0400 From: quiroz@cs.rochester.edu I agree that the letter and spirit of CLtL strongly suggest that the order of evaluation should be left to right. This is so mainly because that is the way things normally go in Common Lisp, and so the programmer must expect that behavior unless explicitly told not to. However, specifying strict left to right order of evaluation kills a substantial amount of parallelism in argument evaluation. At least, it makes it harder to recognize when the arguments of a function call can be parallelized. I am almost sure this has been raised before and probably the original committee even considered this, but as I am new to the list, I haven't seen this discussed: Was it ever considered to leave the order of evaluation in function calls unspecified (or less restricted) than in the current version? I am thinking of something along the lines of saying that, except for special forms, other evaluable forms are evaluated by: 1- determining the function to call or macro to expand. 2- computing the arguments, if a function. 3- calling the function (or (eval (macroexpand....))). 1- and 2- could go in parallel, or 1- could be guaranteed to occur before 2-. It is obvious that certain forms have no meaning but for an order of evaluation (progn,...) and others need special rules for whether an argument even gets eval'd (and, or, ...). But that's why all of these forms are 'special', and pure applicative thinking [:-)] makes it unnecessary to depend on the order of evaluation for the normal function calls. I suspect that the original committee had a really good reason to tie up this part of the language, but I cannot think of one... =Cesar (Of course, if this has been hashed time and again, please just point me to the relevant archives.) -------- Cesar Augusto Quiroz Gonzalez Department of Computer Science {allegra|seismo}!rochester!quiroz University of Rochester or Rochester, NY 14627 quiroz@cs.rochester.edu  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 20 May 87 23:12:25 EDT Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 20 May 87 19:55:39 PDT Received: by navajo.stanford.edu; Wed, 20 May 87 19:53:13 PDT Received: from bhopal.edsel.uucp by edsel.uucp (2.2/SMI-2.0) id AA00421; Wed, 20 May 87 19:25:54 pdt Received: by bhopal.edsel.uucp (3.2/SMI-3.2) id AA03071; Wed, 20 May 87 19:27:34 PDT Date: Wed, 20 May 87 19:27:34 PDT From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White) Message-Id: <8705210227.AA03071@bhopal.edsel.uucp> To: navajo!Moon%STONY-BROOK.SCRC.Symbolics.COM@navajo.stanford.edu Cc: navajo!berman%vaxa.isi.edu@navajo.stanford.edu, navajo!common-lisp%sail@navajo.stanford.edu In-Reply-To: David A. Moon's message of Tue, 19 May 87 17:46 EDT <870519174622.9.MOON@EUPHRATES.SCRC.Symbolics.COM> Subject: [adjustable arrays?] More FORMAT Re: In some implementations all arrays are adjustable even if you didn't explicitly ask for an adjustable array in make-array. Isn't this a bug? It certainly provides a loophole for non-portable code that isn't reasonably detectable as non-portable. For CLtL says (1) on p289 that certain arguments to make-array "guarantee" that the result will be a simple array; (2) and on p28 that a simple array "is not to have its size adjusted dynamically after creation". You can imagine how someone using a system that doesn't detect this error will fare when trying to run on another system that really can't adjust simple arrays. -- JonL --  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 20 May 87 22:26:24 EDT Received: from LABREA.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 20 May 87 19:10:13 PDT Received: by labrea.stanford.edu; Wed, 20 May 87 18:08:28 PDT Received: by ibuki.UUCP (1.4/4.7) id AA3211335; Wed, 20 May 87 17:19:21 pdt Date: Wed, 20 May 87 17:19:21 pdt From: ibuki!weaver@labrea.stanford.edu (Eric Weaver) Message-Id: <8705210019.AA3211335@ibuki.UUCP> To: labrea!common-lisp@sail.arpa Subject: Order of evaluation in PUSH Date: Wed, 20 May 87 13:57:56 -0700 From: labrea!peck@Sun.COM In the form: (push (ref1) (car (ref2))) It is unclear whether (ref1) should be evaluated before (ref2). .... Lucid and Franz evaluate (ref2) then (ref1) Symbolics evaluate (ref1) then (ref2) KCL falls in the former group: (macroexpand '(push (ref1) (car (ref2)))) => (LET* ((#:G7 (REF2)) (#:G8 (CONS (REF1) (CAR #:G7)))) (PROGN (RPLACA #:G7 #:G8) #:G8))  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 20 May 87 22:18:49 EDT Received: from CLS.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 20 May 87 19:02:33 PDT Received: by CLS.LCS.MIT.EDU (4.12/4.7); Wed, 20 May 87 22:07:31 edt Date: Wed, 20 May 87 22:07:31 edt From: rauen@CLS.LCS.MIT.EDU (James R. Rauen) Message-Id: <8705210207.AA16268@CLS.LCS.MIT.EDU> To: common-lisp@sail.stanford.edu Subject: Roman numeral hacking. How about just throwing more M's in front? (6666 = MMMMMMDCLXVI). The case I'd worry about is zero. The Romans didn't have a zero; maybe (format nil "~@R" 0) should return "". --Jim  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 20 May 87 22:16:44 EDT Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 20 May 87 18:44:29 PDT Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 145741; Wed 20-May-87 20:56:15 EDT Date: Wed, 20 May 87 20:56 EDT From: David A. Moon Subject: Order of evaluation in PUSH (& PUSHNEW) To: peck@Sun.COM cc: common-lisp@sail.stanford.edu In-Reply-To: <8705202058.AA29640@denali.sun.com> Message-ID: <870520205618.1.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Wed, 20 May 87 13:57:56 -0700 From: peck@Sun.COM In the form: (push (ref1) (car (ref2))) It is unclear whether (ref1) should be evaluated before (ref2). The intention of the two paragraphs on page 99 Other macros that manipulate generalized variables include ... push .... Macros that manipulate generalized variables must guarantee... subforms of generalized-variable references are evaluated ... in exactly the same order as they appear in the *source* program. was to require (ref1) to be evaluated before (ref2). If some implementations fail to follow this, that's evidence that this part of the specification is not considered universally important, but I don't think it changes the language. I hadn't realized until I read your message that the book is actually ambiguous (here as in so many other places). The quoted paragraphs could be taken to restrict order of evaluation only of the subforms of (car (ref2)), not all of the subforms of the push form. I'm sure this weaker interpretation was not what was intended, and the discussion of (setf reference value) later on the same page supports that, since value is not a subform of a generalized-variable reference. I personally think it's pretty dangerous for order of evaluation to be unspecified and implementation-dependent, so I would prefer to leave the language the way I claim it was intended to be, and as part of the standardization process write a less ambiguous specification.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 20 May 87 22:16:21 EDT Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 20 May 87 18:44:03 PDT Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 145711; Wed 20-May-87 20:20:50 EDT Date: Wed, 20 May 87 20:20 EDT From: David A. Moon Subject: arrays To: Richard Berman cc: common-lisp@sail.stanford.edu In-Reply-To: <8705202322.AA05367@vaxa.isi.edu> Message-ID: <870520202050.5.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Wed, 20 May 87 16:22:48 PDT From: Richard Berman On bit vectors: on page 12: "One dimensional arrays of bits (that is, of integers whose values are 0 or 1) are called bit vectors" implies that any array of all 0 and 1 integers is a bit vector. Page 29: "All implementations are also required to provide specialized arrays of bits, that is, arrays of type (array bit); the one-dimensional instances of this specialization are called bit-vectors." Page 286: "Vectors whose elements are restricted to type bit are called bit-vectors" This implies strongly that a bit vector won't let one store any other value than 0 or 1. I think the imprecise language on page 12 should not be assumed to overrule the more precise language on pages 29 and 286. So bit-vector and bit-array refer to the specialized types. Another way of saying this is that you cannot change whether an object is a bit-vector (or a bit-array) by using setf of aref, or indeed by using any other Common Lisp feature (read the description of the :element-type argument to adjust-array carefully). It is my *opinion* that #(1 0 0 1) is not a bit vector because there is a precise input style for such (like *1001) and bit vectors are specialized. I'm sure you're right.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 20 May 87 22:01:28 EDT Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 20 May 87 16:47:42 PDT Received: ID ; Wed 20 May 87 19:47:14-EDT Date: Wed, 20 May 1987 19:47 EDT Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: Richard Berman Cc: common-lisp@SAIL.STANFORD.EDU Subject: :fill-pointer maybe In-reply-to: Msg of 20 May 1987 18:51-EDT from Richard Berman Richard, It looks to me like you and some others are missing a key concept. There are an awful lot of places in CLtL where it is specified that certain things have to work, but where the manual is silent on what happens if those conditions don't hold. A classic example is a built-in function whose arguments "must" be of a certain type. As a rule, these unspecified situations should be considered to "be an error". That phrase means that a legal Common Lisp implementation is free to extend the language to handle this situation in some allegedly useful way; it is not required to signal an error or to self-destruct. Portable Common Lisp code may not depend on any such extensions, but an implementation is free to extend all it wants. In some cases where CLtL is silent, it is an oversight and a case can be made for changing to a "signals an error" case or for specifying exactly what must happen in that situation. In most cases, however, the language is left open-ended deliberately. The feeling of the designers was that Common Lisp is a living, growing language, and we didn't want to bind it all up too tightly by trying to specify EVERYTHING. "Signals an error" was only specified in those cases where we felt that an error signal was essential and where detecting the error would not impose too great a performance penalty on some calsses of machine. Now, if an implementation takes advantage of its freedom to extend the language, and if it does not provide a compiler mode or some other tool that flags the use of such non-portable extensions, then that implementation is unsuitable for developing portable applications. (I could name some names, but I won't.) Nevertheless, such implementations are perfectly legal and are operating within the spirit of the Common Lisp spec. The language was meant to be extensible; that was an important part of the original charter that we set for ourselves. So, for the purposes of validation, you should treat these unspecified cases as "is an error" cases and leave them alone (unless it is unclear whether the case is or is not specified). It couldn't hurt to make a list of the ones you encounter for later discussion, but in almost all cases the default answer is "this situation is an error; implementations may do what they like". It is the job of the validation suite to make sure that the cases that ARE specified are handled correctly. -- Scott  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 20 May 87 21:59:58 EDT Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 20 May 87 16:58:03 PDT Received: ID ; Wed 20 May 87 19:57:39-EDT Date: Wed, 20 May 1987 19:57 EDT Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: Richard Berman Cc: common-lisp@SAIL.STANFORD.EDU Subject: arrays In-reply-to: Msg of 20 May 1987 19:22-EDT from Richard Berman "Vectors whose elements are restricted to type bit are called bit-vectors" This implies strongly that a bit vector won't let one store any other value than 0 or 1. This one is right in my opinion. Sloppy wording in some of the other descriptions you quote. So, is this a bit vector? #(1 0 0 1) No. should things like BIT-NOT which specifically want a bit vector work on it. Does it return a general vector like this in this case rather than something like *0110??? They have to work on bit vectors. It is an error to give it anything else. If an implementation wants to handle general vectors that happen to be full of 1's and 0's, that's a legal extension; in such cases, it is no business of Common Lisp what it returns. -- Scott  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 20 May 87 21:59:45 EDT Received: from VAXA.ISI.EDU by SAIL.STANFORD.EDU with TCP; 20 May 87 16:22:57 PDT Posted-Date: Wed, 20 May 87 16:22:48 PDT Message-Id: <8705202322.AA05367@vaxa.isi.edu> Received: from LOCALHOST by vaxa.isi.edu (5.54/5.51) id AA05367; Wed, 20 May 87 16:22:51 PDT To: common-lisp@sail.stanford.edu Subject: arrays Date: Wed, 20 May 87 16:22:48 PDT From: Richard Berman On bit vectors: on page 12: "One dimensional arrays of bits (that is, of integers whose values are 0 or 1) are called bit vectors" implies that any array of all 0 and 1 integers is a bit vector. Page 29: "All implementations are also required to provide specialized arrays of bits, that is, arrays of type (array bit); the one-dimensional instances of this specialization are called bit-vectors." Page 286: "Vectors whose elements are restricted to type bit are called bit-vectors" This implies strongly that a bit vector won't let one store any other value than 0 or 1. So, is this a bit vector? #(1 0 0 1) and should things like BIT-NOT which specifically want a bit vector work on it. Does it return a general vector like this in this case rather than something like *0110??? It is my *opinion* that #(1 0 0 1) is not a bit vector because there is a precise input style for such (like *1001) and bit vectors are specialized. What do you think? Is this a real maybe? RB  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 20 May 87 19:36:05 EDT Received: from VAXA.ISI.EDU by SAIL.STANFORD.EDU with TCP; 20 May 87 16:22:57 PDT Posted-Date: Wed, 20 May 87 16:22:48 PDT Message-Id: <8705202322.AA05367@vaxa.isi.edu> Received: from LOCALHOST by vaxa.isi.edu (5.54/5.51) id AA05367; Wed, 20 May 87 16:22:51 PDT To: common-lisp@sail.stanford.edu Subject: arrays Date: Wed, 20 May 87 16:22:48 PDT From: Richard Berman On bit vectors: on page 12: "One dimensional arrays of bits (that is, of integers whose values are 0 or 1) are called bit vectors" implies that any array of all 0 and 1 integers is a bit vector. Page 29: "All implementations are also required to provide specialized arrays of bits, that is, arrays of type (array bit); the one-dimensional instances of this specialization are called bit-vectors." Page 286: "Vectors whose elements are restricted to type bit are called bit-vectors" This implies strongly that a bit vector won't let one store any other value than 0 or 1. So, is this a bit vector? #(1 0 0 1) and should things like BIT-NOT which specifically want a bit vector work on it. Does it return a general vector like this in this case rather than something like *0110??? It is my *opinion* that #(1 0 0 1) is not a bit vector because there is a precise input style for such (like *1001) and bit vectors are specialized. What do you think? Is this a real maybe? RB  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 20 May 87 19:05:23 EDT Received: from VAXA.ISI.EDU by SAIL.STANFORD.EDU with TCP; 20 May 87 15:51:51 PDT Posted-Date: Wed, 20 May 87 15:51:43 PDT Message-Id: <8705202251.AA05057@vaxa.isi.edu> Received: from LOCALHOST by vaxa.isi.edu (5.54/5.51) id AA05057; Wed, 20 May 87 15:51:46 PDT To: common-lisp@sail.stanford.edu Subject: :fill-pointer maybe Date: Wed, 20 May 87 15:51:43 PDT From: Richard Berman Another maybe! On pg 288, about the :fill-pointer keyword to MAKE-ARRAY: "This argument specifies that the array should have a fill pointer. If this option is specified and not NIL, the array must be one-dimensional. The value is used to initialize the fill pointer for the array. If the value T is specified, the length of the array is used...etc." It doesn't say that an array with :fill-pointer nil *doesn't* have a fill pointer, although it implies that multi-dimensional arrays can't or don't have one. I have one implmentation where all vectors have fill pointers, and another that strictly reports an error when vector-push-extend is called on an array with no fill pointer. Any idea if this is intentional relaxation, or oversight? RB  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 20 May 87 17:15:39 EDT Received: from SUN.COM by SAIL.STANFORD.EDU with TCP; 20 May 87 13:59:28 PDT Received: from snail.sun.com by Sun.COM (4.0/SMI-3.2) id AA03347; Wed, 20 May 87 13:55:56 PDT Received: from denali.sun.com by snail.sun.com (3.2/SMI-3.2) id AA05880; Wed, 20 May 87 13:55:28 PDT Received: from localhost by denali.sun.com (3.2/SMI-3.2) id AA29640; Wed, 20 May 87 13:58:00 PDT Message-Id: <8705202058.AA29640@denali.sun.com> To: common-lisp@sail.stanford.edu Subject: Order of evaluation in PUSH (& PUSHNEW) Date: Wed, 20 May 87 13:57:56 -0700 From: peck@Sun.COM In the form: (push (ref1) (car (ref2))) It is unclear whether (ref1) should be evaluated before (ref2). CLtL, page 270 states: " The *effect* of (PUSH Item Place) is *roughly* equivalent to (SETF Place (CONS Item Place)) except that the latter would evaluate any subforms of Place twice while PUSH takes care to evaluate them only once." CLtL, in discussion of generalized variable accessors/modifiers, page 99 states: "Macros that manipulate generalized variables must guarentee the "obvious" semantics: subforms of generalized-variable references are evaluated ... in exactly the same order as they appear in the *source* program." [Is this the *definition* of "obvious" semantics...?] PUSH is in the class of "Macros that manipulate generalized variables". However, even though the *generalized-variable references* are evaluated with the "obvious" semantics, should standard macros necessarily evaluate *all* their arguments in the "obvious" order? The problem is that PUSH is [almost] specified as a macro which expands to something in which its args are not in the "obvious" source order. Shall we just agree that PUSH does not follow the "obvious" semantics? Lucic and Franz evaluate (ref2) then (ref1) Symbolics evaluate (ref1) then (ref2) Lucid: > (macroexpand '(push (ref1) (car (ref2)))) ((LAMBDA (#:G2) ((LAMBDA (#:G1) (SET-CAR #:G2 #:G1)) (CONS (REF1) (CAR #:G2)))) (REF2)) T ExCL: (macroexpand '(push (ref1) (car (ref2)))) (LET* ((#:G8 (REF2)) (#:G7 (CONS (REF1) (CAR #:G8)))) (EXCL::.INV-CAR #:G8 #:G7)) T Symbolics: Command: (macroexpand '(push (ref1) (car (ref2)))) (LET* ((#:G5 (REF1)) (#:G4 (REF2))) NIL (SYS:RPLACA2 #:G4 (VALUES (CONS #:G5 (CAR #:G4))))) T Definitely one for the CL comittee.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 20 May 87 16:06:42 EDT Received: from [128.81.51.3] by SAIL.STANFORD.EDU with TCP; 20 May 87 12:50:54 PDT Received: from KOYAANISQATSI.S4CC.Symbolics.COM by DIAMOND.S4CC.Symbolics.COM via CHAOS with CHAOS-MAIL id 88582; Wed 20-May-87 15:48:49 EDT Date: Wed, 20 May 87 15:53 EDT From: David C. Plummer Subject: All arrays can be adjustable? To: Scott E. Fahlman , David C. Plummer cc: common-lisp@SAIL.STANFORD.EDU In-Reply-To: Message-ID: <870520155306.3.DCP@KOYAANISQATSI.S4CC.Symbolics.COM> Well, I guess I blew it. (I had it right when I first wrote it and then made the mistake of thinking too much and conversed everything.) The idea still stands: figure out formal relationships and draw conclusions from them. What I meant, in IF-THEN language, was Statement: IF not adjustable, and no fill-pointer, and not displaced THEN simple Contrapositive (for those that believe in it): IF not simple THEN adjustable, or fill-pointer, or displaced I agree with whoever (Moon?) said that simple is largely a semantic concept that allows implementations to get leverage if they can.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 20 May 87 16:03:27 EDT Received: from BFLY-VAX.BBN.COM by SAIL.STANFORD.EDU with TCP; 20 May 87 12:47:39 PDT To: berman@vaxa.isi.edu CC: common-lisp@sail.stanford.edu Date: 20 May 87 15:44:22 EDT (Wed) From: las@bfly-vax.bbn.com More on Roman numerals: I haven't given the question a large amount of thought, but it seems to me that the printed representation of a number is as much tied to the font characteristics of a given output device as it is to the "style" or "language" of the number. This problem seems to apply to other areas as well, such as non-English printing. Rumbling about Roman numerals only scratches the surface. I see the following solutions to the Roman problem: 1. Print in decimal, when Roman won't work. 2. Extend the Roman system, e.g., V-CCIV = 5204. 3. Deem it an error. 4. Extend the character set and sense properties of the output device when printing. This, of course, does not solve the problem in general. I think I like (1) best, since it guarantees a number recognizable by English-speaking humans (which the rest of Common Lisp seems geared to), and does not lead us into the quagmire of querying devices, extending character sets, etc. The need to address those problems, however, is not far off. -Larry Stabile  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 20 May 87 15:54:52 EDT Received: from VAXA.ISI.EDU by SAIL.STANFORD.EDU with TCP; 20 May 87 12:38:50 PDT Posted-Date: Wed, 20 May 87 12:38:44 PDT Message-Id: <8705201938.AA03160@vaxa.isi.edu> Received: from LOCALHOST by vaxa.isi.edu (5.54/5.51) id AA03160; Wed, 20 May 87 12:38:46 PDT To: common-lisp@sail.stanford.edu Subject: las@bfly-vax.bbn.com Date: Wed, 20 May 87 12:38:44 PDT From: Richard Berman To everyone else: sorry. I can't send you mail. You will have to call me. 213-822-1511 RB  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 20 May 87 15:16:57 EDT Received: from VAXA.ISI.EDU by SAIL.STANFORD.EDU with TCP; 20 May 87 11:56:57 PDT Posted-Date: Wed, 20 May 87 11:55:34 PDT Message-Id: <8705201855.AA02717@vaxa.isi.edu> Received: from LOCALHOST by vaxa.isi.edu (5.54/5.51) id AA02717; Wed, 20 May 87 11:55:56 PDT To: Don Morrison Cc: common-lisp@sail.stanford.edu Subject: Re: More FORMAT In-Reply-To: Your message of Wed, 20 May 87 01:01:00 -0400. <870520010156.3.DFM@WHITBY.PALLADIAN.COM> Date: Wed, 20 May 87 11:55:34 PDT From: Richard Berman As someone else mentioned, it can be more than useful to know that something is causing an array to grow. It seems reduntant to me to have an :adjustable keyword if there are no clear semantics to :adjustable nil, only to :adjustable T. Especially when :adjustable (non-nil) == :adjustable nil. Or perhaps we need a :non-adjustable keyword, just to keep our semantics consistent, where :non-adjustable T means "definitely" non-adjustable, and :non-adjustable nil means "maybe non-adjustable"? RB  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 20 May 87 15:29:40 EDT Received: from VAXA.ISI.EDU by SAIL.STANFORD.EDU with TCP; 20 May 87 12:10:14 PDT Posted-Date: Wed, 20 May 87 12:05:53 PDT Message-Id: <8705201905.AA02808@vaxa.isi.edu> Received: from LOCALHOST by vaxa.isi.edu (5.54/5.51) id AA02808; Wed, 20 May 87 12:05:56 PDT To: las@bfly-vax.bbn.com Cc: common-lisp@sail.stanford.edu, berman@vaxa.isi.edu In-Reply-To: Your message of Wed, 20 May 87 13:41:08 -0400. <8705201807.AA02149@vaxa.isi.edu> Date: Wed, 20 May 87 12:05:53 PDT From: Richard Berman My only question re: roman numerals is: what does *common lisp* do for values above the specified range (or unspecified, so far as the spec is concerned). Do we just not print romans above certain values? What is printed instead? Etc.? RB