Received: from SU-AI.ARPA by AI.AI.MIT.EDU 25 May 86 02:19:39 EDT Received: from HPLABS.ARPA by SU-AI.ARPA with TCP; 24 May 86 23:07:49 PDT Received: by hplabs.ARPA ; Sat, 24 May 86 23:06:08 pdt Date: Sat, 24 May 86 23:06:08 pdt From: hpfclp!diamant@hplabs.ARPA To: common-lisp@su-ai.ARPA Subject: Re: LISP:*LOCAL-PACKAGE* > From: Kent M Pitman > > OK. This is starting to sound pretty good. Based on your message and the > others that have gone by, what would make me happy would be... > > LISP - a pure CL package to make the hard-core portability folks happy. Great. > > LISP:*LOCAL-PACKAGE* - a variable holding the a package which is named > (hopefully uniquely) in a system-dependent way by each implementation. > This should use LISP. There's a minor issue about whether this should > be a system constant (no stars) or a settable variable. I'm not fussy. It should also export all of LISPs exported symbols, and all of the symbols exported from LISP should be homed in LISP. You have convinced me that the name of the local package should not be standard, but instead to use a standard mechanism to access it. If you allow *LOCAL-PACKAGE* to be a variable, you will shoot yourself in the foot. What happens if you change the value? Will all subsequent MAKE-PACKAGEs reflect the new value (good idea)? So far this is no problem, but if you want to really make it control the default environment (otherwise why not use a constant), it should also change the use list of the USER package. There is currently no mechanism for packages on the use list to be tied to the value of a variable (nor should there as it would make manipulating the use list more complicated). You would require a function as I had suggested in a previous message or an object with a setf method in order to be able to change the use list of the USER package. It is conceivable that the USER package would use the original value, and subsequent MAKE-PACKAGEs would use the current package, but it seems conceptually unclean. My attitude about this is due to my view of the USER package as a reasonable place for portable programs to live (which differs from Alan Snyder's view). Given that view, I would like the USER package to have the same characteristics as ones I make with subsequent calls to MAKE-PACKAGE. I had always assumed that the USER package should use LISP (as it says in CLtL) and nothing else. I don't mind having it use the default environment for convenience, but realize that this makes programs which are now portable (in that they assume that no less and no more than what is defined in CLtL is in the implementation on which they run), no longer portable until they change all their MAKE-PACKAGEs to explicitly use LISP, so that they don't get the default environment and/or change the value of *LOCAL-PACKAGE* to be LISP. I would be happier if a mechanism were set up where the default was the current status quo (i.e. the bare environment), but the variable (or whatever mechanism used) could be set to the implementation dependent package. > USER - a package which uses LISP and which uses the package which is the > value of LISP:*LOCAL-PACKAGE* . > > MAKE-PACKAGE,etc - as before, but if no package is explicitly given to > use, the default would be LISP:*LOCAL-PACKAGE* . Writers of most portable > code would use LISP explicitly. > > > Thoughts, anyone? I think it is time we start thinking about writing a guide for writing portable programs in Common Lisp. It is clear that this is not as simple a matter as had originally been suspected, and at present neither implementors nor users have such a guide. It should be part of the ANSI standard document. John Diamant  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 24 May 86 17:08:15 EDT Received: from HPLABS.ARPA by SU-AI.ARPA with TCP; 24 May 86 14:01:53 PDT Received: from hplabsc by hplabs.ARPA ; Sat, 24 May 86 13:59:58 pdt Received: by hplabsc ; Sat, 24 May 86 14:00:47 pdt Date: Sat, 24 May 86 14:00:47 pdt From: Jim Kempf Message-Id: <8605242100.AA20249@hplabsc> To: common-lisp@SU-AI.ARPA Subject: Re: Common Lisp Subset > Today it is hard to get a personal computer with less than 64k of >memory; ten years ago it was hard to get a personal computer with more >then 64k. The question is how long is the performance window of >subset Common Lisp v.s. full Common Lisp going to be open. In your I think there is an additional issue here besides simply reducing resource requirments, and that is one of language design principles. Should the language designer provide a rich language with lots of features (like PL/I and Common Lisp) or rather a minimal set of orthogonal features which programmers can build upon (like C and Smalltalk)? An argument for the former is that it allows programmers to start at a higher level, reducing the need for porting lower level packages. An argument for the latter is conceptual simplicity and enhancement of the programmer's ability to tune the application to resource requirements ("you only pay for what you use"). Jim Kempf kempf@hplabs  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 24 May 86 15:39:10 EDT Received: from MIT-EMS.ARPA by SU-AI.ARPA with TCP; 24 May 86 12:32:25 PDT Received: by mit-ems.ARPA (4.12/4.8) id AA04942; Sat, 24 May 86 15:29:26 edt Date: Sat, 24 May 86 15:29:26 edt From: Steven Haflich Message-Id: <8605241929.AA04942@mit-ems.ARPA> To: KMP@SCRC-STONY-BROOK.ARPA Subject: Re: LISP:*LOCAL-PACKAGE* Cc: common-lisp@SU-AI.ARPA >From: Kent M Pitman > >LISP - a pure CL package to make the hard-core portability folks happy. > >LISP:*LOCAL-PACKAGE* - a variable holding the a package which is named > (hopefully uniquely) in a system-dependent way by each implementation. > This should use LISP. There's a minor issue about whether this should > be a system constant (no stars) or a settable variable. I'm not fussy. > >USER - a package which uses LISP and which uses the package which is the > value of LISP:*LOCAL-PACKAGE* . > >MAKE-PACKAGE,etc - as before, but if no package is explicitly given to > use, the default would be LISP:*LOCAL-PACKAGE* . Writers of most portable > code would use LISP explicitly. I agree with the intention, but some of the details are unclear. There are two ways the local-extension package could work: (1) LISP:*LOCAL-PACKAGE* exports only the extension symbols. USER and other user-created packages must use both it and LISP. (2) LISP:*LOCAL-PACKAGE* also exports all the normal external symbols in the portable LISP package, except those that it might want to shadow with distinct versions. Your descriptions of USER and MAKE-PACKAGE above seem to imply different choices. Anyway, for several reasons (2) seems cleaner: It is less of a change from the current spec since packages created with the `default' still will only use a single package (even though it's name might not be LISP) rather than two packages. If an implementation for some reason shadows a standard function symbol under (1), the user cannot naively create a new package which uses both LISP:*LOCAL-PACKAGE* and LISP without also doing explicit shadowing. If we choose (2) it is insufficient (or irrelevant?) for LISP:*LOCAL-PACKAGE* to use LISP. Inherited symbols are not automatically exported. The following has to happen (for simplicity, assuming no shadowing is necessary): (LET ((LOCAL (FIND-PACKAGE :LOCAL))) (DO-EXTERNAL-SYMBOLS (SYM (FIND-PACKAGE :LISP)) (EXPORT SYM LOCAL)))  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 24 May 86 13:30:24 EDT Received: from MIT-LIVE-OAK.ARPA by SU-AI.ARPA with TCP; 24 May 86 10:23:55 PDT Received: from GOLD-HILL-ACORN.DialNet.Symbolics.COM (DIAL|DIAL|4925473) by MIT-LIVE-OAK.ARPA via DIAL with SMTP id 1736; 24 May 86 13:23:43-EDT Received: from VENEZUELA.Gold-Hill.DialNet.Symbolics.COM by ACORN.Gold-Hill.DialNet.Symbolics.COM via CHAOS with CHAOS-MAIL id 20922; Sat 24-May-86 10:42:31-EDT Date: Sat, 24 May 86 10:20 EST From: JerryB@a To: Moon@SCRC-STONY-BROOK.ARPA Subject: Where Pure Common Lisp lives Cc: COMMON-LISP@SU-AI.ARPA Date: Fri, 23 May 86 20:54 EDT From: David A. Moon Date: Fri, 23 May 1986 14:57 EDT From: "Scott E. Fahlman" Hmmmm...is USER allowed to start up with random local extensions in it, or is it supposed to inherit ONLY from the LISP package, which is now pure Common Lisp? How have people been reading this? Part of my objection to making LISP pure was because I assumed that this meant USER had to be pure as well, which means that we need another standard place to look for the default local environment. I always assumed USER was supposed to have everything in it. I guess this is not written down anyplace, though. Sigh. ... I have assumed that USER should contain everything as well. One reason being the desire to minmize complexity (knowledge of the package system) for new users. New users will frequently use local extensions.  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 24 May 86 12:56:54 EDT Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 24 May 86 09:48:20 PDT Received: ID ; Sat 24 May 86 12:47:17-EDT Date: Sat, 24 May 1986 12:47 EDT Message-ID: From: Rob MacLachlan To: Masayuki Ida Cc: common-lisp@SU-AI.ARPA, ida.UTOKYO-RELAY@CSNET-RELAY.ARPA, mathis@USC-ISIF.ARPA Subject: Common Lisp Subset In-reply-to: Msg of Sat 24 May 86 12:34:54+0900 from Masayuki Ida Out of curiousity, I went through the Spice Lisp sources and counted all the code that we could eliminate if we were implementing your subset instead of Common Lisp. I counted about 12,000 lines of code. This is out of the 40,000+ lines of code in Spice Lisp which implement the Common Lisp specification. These figures don't include the compiler, but then none of your restrictions help the compiler a great deal. The only significant one is elimination of keyword args. Largely what you propose is the elimination of many facilities which are easily defined in terms of other facilities. This may be a good criterion for eliminating them on esthetic grounds, but it isn't the best way to reduce resource requirements. An example is the restrictions on the irrational functions. Your changes only eliminate 25% of our irrational code. This is because the strange irrational functions and complexes are defined in terms of the basic functions which you do require. In other cases, things that you eliminate will have to exist anyway to support things that you require. For example, Decode-Float is used to implement the irrational functions. If you set out to build an entire implementation with minimal memory usage, then you could probably build one quite a bit smaller than Spice Lisp. It is unclear whether in such a minimal implementation, the effect of your restrictions would be larger or smaller than in Spice Lisp. Many of the features that you propose to eliminate are quite amenable to simplification at the cost of efficiency, possibly more so than the ones to propose to retain. Some of your restrictions are legal in Common Lisp implementations. Declarations may be ignored, THE is ignorable, and several implementations don't have DISASSEMBLE. You have avoided eliminating the big "iceberg" features such as full lexical scoping and full rational arithmetic. These are features which take little text to describe, but much code to implement. This does make the subsetting less traumatic, but it isn't the most effective way to eliminate resource requirements. It seems that you set out to eliminate 50% of the tokens from the language, and have done so. In the process of eliminating everything that was easy to eliminate, you have only reduced the real complexity of the language by about 25%. While it is true that there will always be a price/performance range in computers, a 25% reduction in required performance will probably bring a smaller reduction in price. It is also true that there are effective lower bounds on price and performance. Today it is hard to get a personal computer with less than 64k of memory; ten years ago it was hard to get a personal computer with more then 64k. The question is how long is the performance window of subset Common Lisp v.s. full Common Lisp going to be open. In your example of a too-small subset, you mentioned miminal basic. The real problem with minimal basic is that there is no machine today which cannot run a full basic. Remember the "standard" 4k basic and the "extended" 16k basic? It's no surprise you don't hear much about 2k tiny basics anymore. Rob  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 24 May 86 01:10:04 EDT Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 23 May 86 21:38:33 PDT Received: from utokyo-relay by csnet-relay.csnet id aa09319; 24 May 86 0:27 EDT Received: by u-tokyo.junet (4.12/4.9J-1[JUNET-CSNET]) id AA13068; Sat, 24 May 86 12:51:13+0900 Received: by ccut.u-tokyo.junet (4.12/6.1Junet) id AA28268; Sat, 24 May 86 12:34:54+0900 Date: Sat, 24 May 86 12:34:54+0900 From: Masayuki Ida Message-Id: <8605240334.AA28268@ccut.u-tokyo.junet> To: common-lisp@SU-AI.ARPA, ida@UTOKYO-RELAY.CSNET, mathis@USC-ISIF.ARPA Subject: Common Lisp Subset It was appeared as WGSYM 34-4 IPSJ Nov. 1985. WGSYM is Working Group on Symbol Manipulation IPSJ is Information Processing Society of Japan. and was the base for subsetting discussions in Japan. The paper is attached here. We have a continuous talk with this paper for polishing it up. We have a working group for it under CommonLisp committee at Jeida. The group meeting was held twice-a-month schedule from Dec.1985 till now. The polished version will be apperead at July 8th meeting. The primary members are Masayuki Ida, K. Yuura (Hitachi), H. Kato(Fujitsu), S. Kawai (DEC japan), Y. Hashimoto(NEC), K. Umemura(NTT), S. Harada (Sharp) Y. Yamamura (Nippon Univac), K. Kawagome(Sord) and some other members extended from this April. Mr. Yuura is the chair of the working group. I hope this subset efforts will assist you, if you are considering a two-level language spec like Fortran. I feel the current disccusions on Common-lisp@su-ai have a tendency to make Common Lisp fat, not slim. Of cause it is needed to include rich functionality into Common-lisp, but there are small sized machines which can not use the "full-set" CommonLisp. I am not so enthusiastic to make a subset, but I think it will be needed, and I have a continuous interest to make a subset or a core Common Lisp. Here is my paper on Nov. 1985 (M.Ida: A Common Lisp Subset Proposal", WGSYM 34-4, IPSJ Nov. 1985) ----------------------------------------------------------------------- A Common Lisp Subset Proposal Masayuki Ida Assoc.Prof, Aoyama Gakuin University Chair. Jeida Common Lisp Committee Make Common Lisp slim. Don't cut arms and legs One and only one official subset for Common Lisp.It prevents us from divergence of language specification among CommonLisp-LIKE lisps ********** extracted from WGSYM 34-4 *********** 1) Is this proposal for personal computer based implementa- tion? ---> Yes and No YES: As prof. Fahlman said in [Fah85], personal comput- er will grow to have much more memory space and secondary storages. Large size personal computer will be possible to run full set Common Lisp. But, there is a price range fac- tor. There will be still low-end computers with popularity. Price of the machine which may run this subset can range among a few thousand dollars. No: The decision upon defining subset should not in- clude the restrictions drived from the current technology. 2) How small or slim? A subset which is very small, cannot play the actual roles. For example, Minimal Basic seems to be dead now for almost every scene. Then this subset of CommonLisp should not go to extremes. The author have an image in mind the size is about half of full set. And may be more than 50%, but not greatly less than 50%. 3) What is the basic policy? Don't cut arms and legs of Common Lisp 4.2 Some technical issues 1) Do we assume compiler? ----> Yes Interpreter plays a role of command interpreter/debugger. As a matured language, a compiler should be equipped. 2) DO we keep the type hierarchy? ---> Yes Omit some types, but, preserve hierarchy (for example, character type is independent from number) 3) Do we omit sequence type? ---> No (for user friendlyness) 4) Do we need complex numbers? ---> No 5) Do we need the visibility of system constants and vari- ables? ---> No (some variables and constants are left) 6) Do we need complete function sets of numbers? ---> No preserve types except Complex numbers. delete almost all the irrational functions 7) Do we need hash-table? ---> No 8) Do we need dynamic properties of array? ---> No Only simple and static array. no fill-pointers, no ad- justable array, no bit array. three dimension, not seven, is enough. 9) How about the format feature? ---> there are two ways 1. limit the field specifier set,consulting fortran case. subset F77 has I, F, E, L, A, '...', H, X, /, P, N, Z, BZ ,BN. subset F77 does not have colon, S, SP ,SS, T, TL, TR, G, and list directed editing. 2. exclude all the spec of format from subset ---> include format with restricted syntax 10) How about lambda list keyword? ---> make it slim only &optional and &rest 11) Will include the object oriented facility? ---> No. CommonLOOPS[Bob85] will be the standard after some dis- cussions. But not include in this subset. 12) Do we include go/prog/tagbody? --->No "go" structure should be rewritten with other con- structs. In Common Lisp, go is not always equivalent to a simple jump instruction. prog is obsolete. If there is no "go", tagbody is meaningless. 13) Keyword arguments ? -> restrict to the special cases. So parser will be easier ( general parsing mechanism for keyword is not needed) 5.Summary of the subset spec Total: 330 functions, 2 constants, 7 variables (Table 1). Notation of the following summary: 1) listed elements are included in subset spec. 2) single braketted elements ([ ... ]) are OMITTED. 3) double braketted elements ([[ ... ]]) have RESTRICTED syntax/semantics 4) triple braket ([[[ ... ]]]) contains comments Chapter 2 Data Type number, integer, fixnum, bignum, ratio, float, short- float,single-float, double-float, long-float, [omit: com- plex] character, standard-char, string-char, [[[comment: bits-attribute and font-attribute may be zero]]] symbol,list,cons,null array, [[restricted: max rank=3, array means simple- array]], [omit: bit vector] [hash table] [[ readtable;restricted to only one readtable]] [package, pathname, stream, random-state] structure, function 2.15 type overlap,inclusion,disjointeness [[[ preserve data type hierarchy of full set. hierar- chy figure is defined as in [ida84] ]]] Chapter 3. Scope and Extent [[[same scoping as full set]]] Chatpter 4. type specifier standard type specifiers of Fig.4.1 are all active, coerce, typeof, readtable, simple-array, simple-bit-vector, simple-string, simple-vector [bit, bit-vector,complex,hash-table, stream, ] [And omit functions such as deftype, type specifier combination, predicating specifier(satisfies)] Chapter 5. Porgram structure (2 functions) defun,defvar [omitted functions from Fig 5.1; tagbody, macrolet, flet, compiler-let, eval-when,go] [&key,&allow-other-keys,&aux from lambda-list keyword, lambda-list-keyword, lambda-parameters-limit, defparameter, defconstant] Chapter 6. predicates (27 functions, 2 constants) nil, t, typep, subtypep, null, symbolp, atom, consp, listp, numberp, integerp, rationalp, floatp, characterp, stringp, vectorp, simple-vector-p, simple-string-p, arrayp, packagep, functionp, compiled-function-p, commonp, eq, eql, equal, not, and, or [complexp, bit-vector-p, simple-bit-vector-p, equalp] Chapter 7. Control Structure (51 functions) quote, function, symbol-value, symbol-function, boundp, fboundp, special-form-p, setq, psetq, set, makunbound, fmakunbound, setf, apply, funcall, progn, prog1, prog2, let, let*, progv, labels, if, when, unless, cond, case, block, return-from, return, loop, do, do*, dolist, dotimes, ma- plist, mapcar, mapc, mapl, mapcan, mapcon, values, values- list, multiple-value-list, multiple-value-prog1, multiple- value-bind, multiple-value-setq, multiple-value-call, catch, unwind-protect, throw [psetf, shiftf, rotatef, defsetf, define-setf- method, define-modify-macro, get-setf-method, get-setf- method-multiple-value, call-argument-limit, compiler-let, flet, macrolet, prog, go, typecase, tagbody] setf accessible forms; aref, car, cdr, c...r, fill-pointer, first, get, getf, nth, nthcdr, rest, second, symbol-function, symbol-plist, symbol-value, third, access function of defstruct, [omitted access form; elt,fourth-- tenth,svref,gethash,documentation, c....r, macro-function, (char, schar, bit, sbit, subseq) function calls, the- declaration, apply ] Chapter 8. Macro (5 functions) macro-function, defmacro, macro, macroexpand, macroexpand-1 [[ defmacro keywords only to &optional and &rest]] [omit *macro-expand-hook*, &key, &allow-other-keys, &aux, &body, &whole, &environment] Chapter 9. Declarations (2 functions) Only (declare (special ...)) acceptable [omit all the spec of declarations but above] [[["the" acceptable but not effective]]] Chapter 10. Symbols (10 functions) get, remprop, symbol-plist, getf, remf, symbol-name, make-symbol, copy-symbol, gensym, keywordp [get-properties, gentmp, symbol-package] Chapter 11. Package (1 function) [All the spec of Package features are omitted,but below] 11.1 consistency rules, intern Chapter 12. Number (51 functions) zerop, plusp, minusp, oddp, evenp, =, /=, <, >, <=, >=, max, min, +, -, *, /, 1+, 1-, incf, decf, gcd, lcm, exp, expt, log, sqrt, abs, signum, sin, cos, tan, rational, ra- tionalize, numerator, denominator, float, floor, ceiling, truncate, round, mod, rem, logior, logxor, logand, logeqv, lognot, logtest. logbitp, ash [[ complex related features of above fuctions are omit- ted]] [ complex and byte-manipulation functions, random- numbers, implementation parameters described in 12.10. conjugate, isqrt, phase, cis, asin, acos, atan, pi, sinh, cosh, tanh, sinh, acosh, atanh, ffloor, fceiling, ftruncate, fround, decode-float -- integer-decode-float, complex, realpart, imagpart, lognand, logandc1, logandc2, logorc1, logorc2, boole, bool- constants byte, byte-size, byte-position, ldb, ldb-test, mask-field, dpb, deposit- field, random, *random-state*, make-random-state ] Chapter 13. Characters (21 functions) standard-char-p, alpha-char-p, upper-case-p, both- case-p, digit-char-p, char=, char/=, char<, char<=, char- code, code-char, make-char, char-upcase, digit-char, char- int, int-char, char-downcase, char-name, name-char, char- bit, set-char-bit [ char-code-limit, char-font-limit, char-bits-limit, graphic-char-p, string-char-p, alphanumericp, char-equal, char-not-equal, char-lessp, char-greaterp, char-not- greaterp, char-not-lessp, char>, char>=, 13.5 char control bit functions ] Chapter 14. Sequences (17 functions) subseq, reverse, nreverse, some, every, notany, notevery, sort [[as to fill pointer:: elt,length]] [[as to :start - :end :: remove, remove-if, remove- if-not, remove-duplicates, find, position, count]] :count, :from-end, :strat, :end, make-sequence, con- catenate, map, reduce, fill, replace, delete, delete-if, delete-if-not, delete-duplicates, substitute, substitute-if, substitute-if-not, nsubstitute, nsubstitute-if, nsubstitute-if-not, find-if, find-if-not, position-if, position-if-not, count-if, count-if-not, mismatch, search, stable-sort, merge ] Chapter 15. list (62 functions) car, cdr, c..r, c...r, cons, tree-equal, endp, list- length, nth, first, second, third, rest, nthcdr, last, list, list*, append, copy-list, copy-alist, copy-tree, nconc, push, pushnew, pop, butlast, nbutlast, ldiff, rplaca, rplacd, pairlis [[keyword not allowed; subst, nsubst, sublis, member, member-if, member-if-not, adjoin, union, nunion, intersec- tion, nintersection, set-defference, nset-difference, set- exclusive-or, nset-exclusive-or, assoc,assoc-if, assoc-if- not, rassoc, rassoc-if, rassoc-if-not]] [c....r, fourth -- tenth, make-list, revappend, nreconc, subst-if, subst-if-not, nsubst-if, nsubst-if-not, subsetp, acons, tailp] Chapter 16. Hash-table (0 functions) [ ALL ] Chapter 17. Array (6 functions) vector, aref, array-rank, array-in-bounds-p, array- total-size [[ make-array( limit to three dimensions (not seven), all the keyword arguments but :initial-contents are delet- ed)]] [ array-rank-limit, array-dimension-limit, array-total- size-limit, svref, array-elemet-type, array-dimension, array-dimensions, array-row-major-index, adjustable-array-p, bit, sbit, bit-and, bit-or, ..., bitorc2, bit-not, array- has-fill-pointer-p, fill-pointer, vector-push, vector-push- extend, vector-pop, adjust-array, 17.4 all (bit-array),17.5 all (fill pointer),17.6 all (augumentation of dimension) ] Chapter 18. string (9 functions) char, string-trim, string-left-trim, string-right-trim, string-capitalize [[ subseq(:start and :end) related restriction :: string=, string/=, string<, string<=]] [schar, string>, string>=, string-equal, string-lessp, ...,make-string, string-upcase, string-downcase, nstring- upcase, nstring-down-case, nstring-capitalize] Chapter 19. structure (1 functions) [[ defstruct ]] [ :type,:read-only (in defstruct slot option), :conc-name, :constructor, :copier, :predicate, :include, :print-function, :type, :named, :initial-offset (in defs- truct option), by-position constructor ] Chapter 20. Evaluator (1 function) eval [ evalhook, applyhook, *evalhook*, *applyhook*, con- stantp, +, ++, +++, -, *, **, ***, /, //, /// ] Chapter 21. stream (1 function, 7 variables) *standard-input*, *standard-output*, *error-output*, *query-io*, *debug-io*, *terminal-io*, *trace-output* [[ close (No :abort arg) ]] [make-synonym-stream, make-...-stream, get-output- stream-string, with-input-from-string, with-output-to- string,streamp, input-stream-p, output-stream-p, stream- element-type ] Chapter 22. input/output (22 functions) 22.1.4 dispatching macro character #',#(,#+,#-,#B,#D,#S,#X,#nA,#| [#\,#*,#:,#.,#,,#O,#nR,#n=,#n#,#<,#)] 22.1.5 [*readtable*, copy, readtable, readtablep, set- syntax-from-char, set/get-macro-character, make-dispatch- macro-character, set/get-dispatch-macro-character ] 22.1.6 [*print-...* all omitted] 22.2 input read, read-line, read-char, unread-char, listen, read- char-no-hang, clean-input, read-byte [*read-default-float-format*, read-preserving- whitespace, read-delimited-list, peek-char, parse-integer] [[ read-from-string (no keyword arg) ]] 22.3 output write-byte, prin1, print, pprint, princ, prin1-to- string, princ-to-string, write-char, terpri, fresh-line, format, y-or-n-p, yes-or-no-p 22.3.3 format specifier: ~A, ~S, ~D, ~X, ~C, ~F, ~E, ~%, ~&, ~|, ~~, ~, [~B, ~O, ~nR, ~P, ~G, ~$, ~T, ~*, ~?, ~(str~), Chapter 23.file system interface (11 functions) 23.1 file name pathname file name should be string [all the pathname related definitions are omitted] 23.2 file open/close open [[file name should be string (:direction is Only input or output, :element-type is only string-char or unsigned- byte, :if-exists omitted, :if-does-not-exist omitted)]], with-open-file 23.3 rename-file, delete-file, probe-file, file-write-date, file-author, file-position, file-length 23.4 [[load(no keyword)]], [*load-verbose*] 23.5 directory Chapter 24. error (4 functions) error, cerror, warn, break [ *break-on-warning*, check-type, assert, etypecase, ctypecase, ecase, ccase] Chapter 25. miscellaneous (26 functions) compile, compile-file, documentation, trace, untrace, step,time, describe, inspect, room, ed, dribble, appropos, appropos-list, get-decoded-time, get-internal-run-time, get-internal-real-time, sleep, lisp-implementation-type, *features*, lisp-implementation-version, machine-type, machine-version, machine-instance, software-type, software- version [disassemble, get-universal-time, decode/encode- universal-time, internal-time-units-per-second, short-site- name, long-site-name, identity] ------------------------end of the document ---------- ----------  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 24 May 86 01:01:47 EDT Received: from MIT-EMS.ARPA by SU-AI.ARPA with TCP; 23 May 86 21:12:18 PDT Received: by mit-ems.ARPA (4.12/4.8) id AA02152; Sat, 24 May 86 00:10:06 edt Date: Sat, 24 May 86 00:10:06 edt From: Steven Haflich Message-Id: <8605240410.AA02152@mit-ems.ARPA> To: snyder%hplsny@hplabs.ARPA Subject: Re: Where Pure Common Lisp lives Cc: common-lisp@su-ai.ARPA > From @SU-AI.ARPA:snyder%hplsny@hplabs.ARPA Fri May 23 11:58:17 1986 > > Here's an alternative: How about leaving LISP:MAKE-PACKAGE alone, and > defining LOCAL:MAKE-PACKAGE to default to the LOCAL package? You'll have to do the same for LISP:IN-PACKAGE, and you'll have to fix the compiler to give LOCAL:IN-PACKAGE the same special attention it gives LISP:IN-PACKAGE... It's disturbing how rapidly any hacking of the package system gets ugly.  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 23 May 86 21:23:17 EDT Received: from SCRC-QUABBIN.ARPA by SU-AI.ARPA with TCP; 23 May 86 18:13:49 PDT Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-QUABBIN.ARPA via INTERNET with SMTP id 1816; 23 May 86 20:56:24 EDT Date: Fri, 23 May 86 20:54 EDT From: David A. Moon Subject: Where Pure Common Lisp lives To: COMMON-LISP@SU-AI.ARPA In-Reply-To: Message-ID: <860523205433.3.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Fri, 23 May 1986 14:57 EDT From: "Scott E. Fahlman" Hmmmm...is USER allowed to start up with random local extensions in it, or is it supposed to inherit ONLY from the LISP package, which is now pure Common Lisp? How have people been reading this? Part of my objection to making LISP pure was because I assumed that this meant USER had to be pure as well, which means that we need another standard place to look for the default local environment. I always assumed USER was supposed to have everything in it. I guess this is not written down anyplace, though. Sigh. To be a true standard to which many implementations adhere, rather than the original goal of making four Lisp implementations go in the same direction instead of four different directions, Common Lisp will have to be a lot more precise.  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 23 May 86 21:11:36 EDT Received: from [192.10.41.41] by SU-AI.ARPA with TCP; 23 May 86 18:01:45 PDT Received: from HOME.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 7384; Fri 23-May-86 17:35:30 EDT Date: Fri, 23 May 86 17:34 EDT From: Charles Hornig Subject: list of lisp package external symbols To: common-lisp@SU-AI.ARPA In-Reply-To: <8605231350.AA04561@fimass> Message-ID: <860523173447.2.HORNIG@HOME.SCRC.Symbolics.COM> Date: Fri, 23 May 86 05:50:43 PST From: franz!fimass!jkf@kim.Berkeley.EDU (John Foderaro) Is there an official 'online' list of the external lisp package symbols implied by the Common Lisp book? If not, I'd like to start the process of computing the list by supplying the following list which I believe to be very close to correct. Are there any additions or deletions? ...list removed... I would add COMPILATION-SPEED and remove SEQUENCEP.  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 23 May 86 16:09:18 EDT Received: from HPLABS.ARPA by SU-AI.ARPA with TCP; 23 May 86 12:52:00 PDT Received: from hplsny by hplabs.ARPA ; Fri, 23 May 86 12:49:26 pdt Received: by hplsny ; Fri, 23 May 86 12:49:16 pdt From: Alan Snyder Message-Id: <8605231949.AA01057@hplsny> Date: Friday, May 23, 1986 12:49:12 Subject: Re: Scott's comments on extensions To: greek%bach.decnet@hudson.dec.com Cc: common-lisp@su-ai.ARPA In-Reply-To: Your message of 23-May-86 14:45:00 X-Sent-By-Nmail-Version: 04-Nov-84 17:14:46 Let's say in VAX LISP we have a LISP package with pure Common LISP and a VAXLISP package with our extensions. Which packages should the USER package use? My model is that portable code will always define its own package, i.e., it will not live in the USER package. The USER package is where you type in commands and test expressions and perhaps build prototypes. Therefore, I don't think the language definition particularly needs to constrain what packages the USER package uses. In your case, I would guess that users would prefer that it use both LISP and VAXLISP (I'm reading your statement to mean that VAXLISP exports ONLY your extensions). The situation becomes interesting if there are conflicts between LISP and VAXLISP (which I would expect, if VAXLISP extends the definitions of LISP functions). In this case, I think users would want VAXLISP to use LISP and export all of its non-shadowed symbols; then the USER package would use only VAXLISP. Alan -------  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 23 May 86 15:42:44 EDT Received: from SRI-KL.ARPA by SU-AI.ARPA with TCP; 23 May 86 12:31:05 PDT Date: Fri 23 May 86 09:38:03-PDT From: David Singer Subject: Pure CL, package names etc. To: common-lisp%SU-AI@SRI-KL I don't think the vendor extended package on different vendors systems should have the same name, because the won't have the same meaning (i.e. contents). The pure CL package should be called LISP; portable programs are well advised to select it explicitly; any other extensions should be in packages which are functionally named as far as possible, and inherited (maybe) by packages like SYMBOLICS-COMMON-LISP et al. so that there is a single 'extended' package on each machine. Many of the extensions can be and will be at least semi-portable, or from other than the original lisp vendor. To the largest extent possible these extensions should be functionally separated into packages with functional names, rather than names which signify nothing (e.g. EXTENDED) or the vendor name. I would expect sites, under such a scheme, to develop their extended package(s) to suit them, knowing that if they import e.g. LISP and TENSOR-ALGEBRA they'll either get pure cl+tensors or an error. Dave Singer -------  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 23 May 86 15:41:36 EDT Received: from HUDSON.DEC.COM by SU-AI.ARPA with TCP; 23 May 86 12:27:02 PDT Date: 23 May 86 15:19:00 EST From: "BACH::GREEK" Subject: Momentary disengagement of brain. To: "common-lisp" Reply-To: "BACH::GREEK" Sorry, I was referring to Kent's comments, not Scott's. - Paul ------  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 23 May 86 15:18:50 EDT Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 23 May 86 11:59:27 PDT Received: ID ; Fri 23 May 86 14:57:58-EDT Date: Fri, 23 May 1986 14:57 EDT Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: "David A. Moon" Cc: COMMON-LISP@SU-AI.ARPA Subject: Where Pure Common Lisp lives In-reply-to: Msg of 23 May 1986 13:55-EDT from David A. Moon If you want to make a package that uses the same exported symbols as the user package, you do (MAKE-PACKAGE "MY-VERY-OWN-PACKAGE" :USE (PACKAGE-USE-LIST (PACKAGE "USER"))). I don't see any reason why we need to add a new language feature that duplicates this. I agree completely with the people who say that the default for :USE in MAKE-PACKAGE should be the portable default, not the full local extensions. Hmmmm...is USER allowed to start up with random local extensions in it, or is it supposed to inherit ONLY from the LISP package, which is now pure Common Lisp? How have people been reading this? Part of my objection to making LISP pure was because I assumed that this meant USER had to be pure as well, which means that we need another standard place to look for the default local environment. -- Scott  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 23 May 86 15:04:19 EDT Received: from HUDSON.DEC.COM by SU-AI.ARPA with TCP; 23 May 86 11:45:28 PDT Date: 23 May 86 14:45:00 EST From: "BACH::GREEK" Subject: Scott's comments on extensions To: "common-lisp" Reply-To: "BACH::GREEK" I hope we'll all read Scott's comments carefully and give them the attention they deserve. I have a related question. Let's say in VAX LISP we have a LISP package with pure Common LISP and a VAXLISP package with our extensions. Which packages should the USER package use? Unfortunately, certain answers to that question will be incompatible with our situation now, where everything is in the LISP package. - Paul ------  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 23 May 86 14:29:09 EDT Received: from SCRC-QUABBIN.ARPA by SU-AI.ARPA with TCP; 23 May 86 11:00:28 PDT Received: from EUPHRATES.SCRC.Symbolics.COM by SCRC-QUABBIN.ARPA via CHAOS with CHAOS-MAIL id 1566; Fri 23-May-86 13:59:52 EDT Date: Fri, 23 May 86 13:55 EDT From: David A. Moon Subject: Where Pure Common Lisp lives To: COMMON-LISP@SU-AI.ARPA In-Reply-To: Message-ID: <860523135545.4.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Fri, 23 May 1986 10:33 EDT From: "Scott E. Fahlman" I'm not wedded to the name "LOCAL", but if the place you go to get the default good environment on your machine is not "LISP", it has to be some standard package name. Maybe "EXTENDED", or whatever. This could be set up as a nickname for "SCL" or "DEC'S-PROPRIETARY-VAX-EXTENSIONS" or whatever, but it should be a uniform place on each machien so users don't have to hunt for it. If you want to make a package that uses the same exported symbols as the user package, you do (MAKE-PACKAGE "MY-VERY-OWN-PACKAGE" :USE (PACKAGE-USE-LIST (PACKAGE "USER"))). I don't see any reason why we need to add a new language feature that duplicates this. I agree completely with the people who say that the default for :USE in MAKE-PACKAGE should be the portable default, not the full local extensions.  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 23 May 86 12:06:15 EDT Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 23 May 86 08:58:09 PDT Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 6049; Fri 23-May-86 11:59:40 EDT Date: Fri, 23 May 86 11:56 EDT From: Kent M Pitman Subject: LISP:*LOCAL-PACKAGE* To: Fahlman@CMU-CS-C.ARPA cc: common-lisp@SU-AI.ARPA, KMP@SCRC-STONY-BROOK.ARPA In-Reply-To: Message-ID: <860523115607.3.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> Date: Thu, 22 May 1986 22:24 EDT From: "Scott E. Fahlman" ... I'm ready to agree that the path of maximum sanity is to require that the LISP package contain only the symbols of pure Common Lisp, and that we create a new standard package (I like the name "LOCAL") for containing the local lisp environment, with possible extensions. I think we should agree to disagree on naming anything that is implementation specific. If two implementations have a LOCAL:FOO function and they don't do the same thing, it will be hard to detect the problem until runtime. Again, the absence of VAXLISP:FOO in the Symbolics environment or the absence of SYMBOLICS:FOO in VAXLISP will be easy to detect. After all, to use the implementation stuff, people will have to have read the implementation-specific manual, which will tell them the package name. Also, and importantly, I can create a VAXLISP:FOO if I need it on a 3600 in order to not have to edit the source file containing the reference. If both implementations call their extension LOCAL:FOO, the fix is not so easy to make because some other code I'm using may already reference Symbolics' LOCAL:FOO and may not be happy if I bash that definition with something to make some ported VAXLISP code happy. I'd like to see some variable that holds the current default package for MAKE-PACKAGE, with the default default being LISP. As long as a portable program can specify LISP explicitly and not have to worry that this variable will override that, I'm agreeable to that. In fact, I don't see the use of it, though, unless you allow the default default to vary from implementation to implementation. In other words, I think it's fine for programs that don't say they want LISP to get whatever they get -- all my programs will say LISP so they'll not be bothered by this feature. You might as well let VAXLISP make this variable be # and Symbolics let this package be #, etc. I'll call this variable *LOCAL-PACKAGE* for purposes of discussion here; I'm not wedded to the name -- another possibility might be *NATIVE-PACKAGE*. We should encourage implementations (maybe require, but I'm not sure about this) not to extend the language by adding keywords and other non-standard options to the functions in LISP, but to put such extensions in LOCAL instead. I agree, but rather than "LOCAL" the value of *LOCAL-PACKAGE*. Once we start considering exactly what goes into the ANSI/ISO spec (I'll be sending a message about this soon, probably over the weekend), I'll propose this for formal consideration. OK. This is starting to sound pretty good. Based on your message and the others that have gone by, what would make me happy would be... LISP - a pure CL package to make the hard-core portability folks happy. LISP:*LOCAL-PACKAGE* - a variable holding the a package which is named (hopefully uniquely) in a system-dependent way by each implementation. This should use LISP. There's a minor issue about whether this should be a system constant (no stars) or a settable variable. I'm not fussy. USER - a package which uses LISP and which uses the package which is the value of LISP:*LOCAL-PACKAGE* . MAKE-PACKAGE,etc - as before, but if no package is explicitly given to use, the default would be LISP:*LOCAL-PACKAGE* . Writers of most portable code would use LISP explicitly. At this point, I'll back off a little and admit that some classes of portable code will usefully be able to take advantage of LISP:*LOCAL-PACKAGE* . Portable programs can't be coded in an environment where the local package is active because the author won't know what the program will mean in an arbitrarily mucked up environment. Macsyma is a good example of this kind of program. But some portable programs, though written in a portable subset, might want to be able to portably extend whatever environment was available on the local machine. An example of this might be GLISP. I would expect such a program to be written in some package (GLISP-INTERNALS, I guess) which used only LISP, but which sometimes manipulated LISP:*LOCAL-PACKAGE* -- particularly for the purpose of creating a GLISP package based on LISP:*LOCAL-PACKAGE*. Code written in such a GLISP package might not be portable even though it could built by a portable program. (I'm kinda handwaving the GLISP example here because I'm not familiar with its details; if my example doesn't hold up, perhaps you can go back and re-cast this paragraph using AMORD or FRL or some other layered language as an example with better results). Thoughts, anyone?  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 23 May 86 11:51:49 EDT Received: from HPLABS.ARPA by SU-AI.ARPA with TCP; 23 May 86 08:45:58 PDT Received: from hplsny by hplabs.ARPA ; Fri, 23 May 86 08:44:06 pdt Received: by hplsny ; Fri, 23 May 86 08:43:56 pdt From: Alan Snyder Message-Id: <8605231543.AA00822@hplsny> Date: Friday, May 23, 1986 08:43:52 Subject: Re: Where Pure Common Lisp lives To: Fahlman@C.CS.CMU.EDU Cc: common-lisp@su-ai.ARPA In-Reply-To: Your message of 22-May-86 22:24:00 X-Sent-By-Nmail-Version: 04-Nov-84 17:14:46 OK, having been beaten soundly by everyone who has ever tried to port a big program, I'm ready to agree that the path of maximum sanity is to require that the LISP package contain only the symbols of pure Common Lisp, and that we create a new standard package (I like the name "LOCAL") for containing the local lisp environment, with possible extensions. I'd like to see some variable that holds the current default package for MAKE-PACKAGE, with the default default being LISP. I feel very uneasy about introducing a global variable that controls the behavior of MAKE-PACKAGE. How can I expect portable code to load correctly if this variable has any value other than LISP? Here's an alternative: How about leaving LISP:MAKE-PACKAGE alone, and defining LOCAL:MAKE-PACKAGE to default to the LOCAL package? Alan -------  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 23 May 86 11:40:32 EDT Received: from XX.LCS.MIT.EDU by SU-AI.ARPA with TCP; 23 May 86 08:34:01 PDT Date: Fri, 23 May 1986 11:32 EDT Message-ID: From: SOLEY@XX.LCS.MIT.EDU To: "Scott E. Fahlman" Cc: COMMON-LISP@SU-AI.ARPA Subject: Where Pure Common Lisp lives In-reply-to: Msg of 23 May 1986 10:33-EDT from Scott E. Fahlman Date: Friday, 23 May 1986 10:33-EDT From: Scott E. Fahlman Sender: FAHLMAN at C.CS.CMU.EDU To: COMMON-LISP at SU-AI.ARPA Re: Where Pure Common Lisp lives I'm not wedded to the name "LOCAL", but if the place you go to get the default good environment on your machine is not "LISP", it has to be some standard package name. Actually, I agree more with Plummer - the EXTENDED package you mention will probably offer a totally different environment in each CL implementation. You DO want your user to hunt for it (i.e., look in the doc), since the coincidence of the name might make the user believe that the same interfaces are offered in each CL. This is just the naming problem on a grander scale, offerred up because of the global namespace of package names. If I write an FFT package and DCP does too, and we both call the package FFT, and the interfaces (functions) in the packages are different, that's a bug, not a feature. -- Richard  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 23 May 86 11:12:49 EDT Received: from [128.32.130.7] by SU-AI.ARPA with TCP; 23 May 86 07:54:52 PDT Received: by kim.Berkeley.EDU (5.51/1.12) id AA21757; Fri, 23 May 86 07:54:40 PDT Received: from fimass by franz (5.5/3.14) id AA09972; Fri, 23 May 86 06:52:14 PDT Received: by fimass (5.5/3.14) id AA04561; Fri, 23 May 86 05:50:48 PST From: franz!fimass!jkf@kim.Berkeley.EDU (John Foderaro) Return-Path: Message-Id: <8605231350.AA04561@fimass> To: common-lisp@su-ai.arpa Subject: list of lisp package external symbols Date: Fri, 23 May 86 05:50:43 PST Is there an official 'online' list of the external lisp package symbols implied by the Common Lisp book? If not, I'd like to start the process of computing the list by supplying the following list which I believe to be very close to correct. Are there any additions or deletions? --- start list &allow-other-keys &aux &body &environment &key &optional &rest &whole * ** *** *applyhook* *break-on-warnings* *debug-io* *default-pathname-defaults* *error-output* *evalhook* *features* *load-verbose* *macroexpand-hook* *modules* *package* *print-array* *print-base* *print-case* *print-circle* *print-escape* *print-gensym* *print-length* *print-level* *print-pretty* *print-radix* *query-io* *random-state* *read-base* *read-default-float-format* *read-suppress* *readtable* *standard-input* *standard-output* *terminal-io* *trace-output* + ++ +++ - / // /// /= 1+ 1- < <= = > >= abs acons acos acosh adjoin adjust-array adjustable-array-p alpha-char-p alphanumericp and append apply applyhook apropos apropos-list aref array array-dimension array-dimension-limit array-dimensions array-element-type array-has-fill-pointer-p array-in-bounds-p array-rank array-rank-limit array-row-major-index array-total-size array-total-size-limit arrayp ash asin asinh assert assoc assoc-if assoc-if-not atan atanh atom bignum bit bit-and bit-andc1 bit-andc2 bit-eqv bit-ior bit-nand bit-nor bit-not bit-orc1 bit-orc2 bit-vector bit-vector-p bit-xor block boole boole-1 boole-2 boole-and boole-andc1 boole-andc2 boole-c1 boole-c2 boole-clr boole-eqv boole-ior boole-nand boole-nor boole-orc1 boole-orc2 boole-set boole-xor both-case-p boundp break butlast byte byte-position byte-size caaaar caaadr caaar caadar caaddr caadr caar cadaar cadadr cadar caddar cadddr caddr cadr call-arguments-limit car case catch ccase cdaaar cdaadr cdaar cdadar cdaddr cdadr cdar cddaar cddadr cddar cdddar cddddr cdddr cddr cdr ceiling cerror char char-bit char-bits char-bits-limit char-code char-code-limit char-control-bit char-downcase char-equal char-font char-font-limit char-greaterp char-hyper-bit char-int char-lessp char-meta-bit char-name char-not-equal char-not-greaterp char-not-lessp char-super-bit char-upcase char/= char< char<= char= char> char>= character characterp check-type cis clear-input clear-output close clrhash code-char coerce common commonp compile compile-file compiled-function compiled-function-p compiler-let complex complexp concatenate cond conjugate cons consp constantp copy-alist copy-list copy-readtable copy-seq copy-symbol copy-tree cos cosh count count-if count-if-not ctypecase decf declaration declare decode-float decode-universal-time defconstant define-modify-macro define-setf-method defmacro defparameter defsetf defstruct deftype defun defvar delete delete-duplicates delete-file delete-if delete-if-not denominator deposit-field describe digit-char digit-char-p directory directory-namestring disassemble do do* do-all-symbols do-external-symbols do-symbols documentation dolist dotimes double-float double-float-epsilon double-float-negative-epsilon dpb dribble ecase ed eighth elt encode-universal-time endp enough-namestring eq eql equal equalp error etypecase eval eval-when evalhook evenp every exp export expt fboundp fceiling ffloor fifth file-author file-length file-namestring file-position file-write-date fill fill-pointer find find-all-symbols find-if find-if-not find-package find-symbol finish-output first fixnum flet float float-digits float-precision float-radix float-sign floatp floor fmakunbound force-output format fourth fresh-line fround ftruncate ftype funcall function functionp gcd gensym gentemp get get-decoded-time get-dispatch-macro-character get-internal-real-time get-internal-run-time get-macro-character get-output-stream-string get-properties get-setf-method get-setf-method-multiple-value get-universal-time getf gethash go graphic-char-p hash-table hash-table-count hash-table-p host-namestring identity if ignore imagpart import in-package incf inline input-stream-p inspect int-char integer integer-decode-float integer-length integerp intern internal-time-units-per-second intersection isqrt keyword keywordp labels lambda lambda-list-keywords lambda-parameters-limit last lcm ldb ldb-test ldiff least-negative-double-float least-negative-long-float least-negative-short-float least-negative-single-float least-positive-double-float least-positive-long-float least-positive-short-float least-positive-single-float length let let* lisp-implementation-type lisp-implementation-version list list* list-all-packages list-length listen listp load locally log logand logandc1 logandc2 logbitp logcount logeqv logior lognand lognor lognot logorc1 logorc2 logtest logxor long-float long-float-epsilon long-float-negative-epsilon long-site-name loop lower-case-p machine-instance machine-type machine-version macro-function macroexpand macroexpand-1 macrolet make-array make-broadcast-stream make-char make-concatenated-stream make-dispatch-macro-character make-echo-stream make-hash-table make-list make-package make-pathname make-random-state make-sequence make-string make-string-input-stream make-string-output-stream make-symbol make-synonym-stream make-two-way-stream makunbound map mapc mapcan mapcar mapcon maphash mapl maplist mask-field max member member-if member-if-not merge merge-pathnames min minusp mismatch mod most-negative-double-float most-negative-fixnum most-negative-long-float most-negative-short-float most-negative-single-float most-positive-double-float most-positive-fixnum most-positive-long-float most-positive-short-float most-positive-single-float multiple-value-bind multiple-value-call multiple-value-list multiple-value-prog1 multiple-value-setq multiple-values-limit name-char namestring nbutlast nconc nil nintersection ninth not notany notevery notinline nreconc nreverse nset-difference nset-exclusive-or nstring-capitalize nstring-downcase nstring-upcase nsublis nsubst nsubst-if nsubst-if-not nsubstitute nsubstitute-if nsubstitute-if-not nth nthcdr null number numberp numerator nunion oddp open optimize or otherwise output-stream-p package package-name package-nicknames package-shadowing-symbols package-use-list package-used-by-list packagep pairlis parse-integer parse-namestring pathname pathname-device pathname-directory pathname-host pathname-name pathname-type pathname-version pathnamep peek-char phase pi plusp pop position position-if position-if-not pprint prin1 prin1-to-string princ princ-to-string print probe-file proclaim prog prog* prog1 prog2 progn progv provide psetf psetq push pushnew quote random random-state random-state-p rassoc rassoc-if rassoc-if-not ratio rational rationalize rationalp read read-byte read-char read-char-no-hang read-delimited-list read-from-string read-line read-preserving-whitespace readtable readtablep realpart reduce rem remf remhash remove remove-duplicates remove-if remove-if-not remprop rename-file rename-package replace require rest return return-from revappend reverse room rotatef round rplaca rplacd safety satisfies sbit scale-float schar search second sequence sequencep set set-char-bit set-difference set-dispatch-macro-character set-exclusive-or set-macro-character set-syntax-from-char setf setq seventh shadow shadowing-import shiftf short-float short-float-epsilon short-float-negative-epsilon short-site-name signed-byte signum simple-array simple-bit-vector simple-bit-vector-p simple-string simple-string-p simple-vector simple-vector-p sin single-float single-float-epsilon single-float-negative-epsilon sinh sixth sleep software-type software-version some sort space special special-form-p speed sqrt stable-sort standard-char standard-char-p step stream stream-element-type streamp string string-capitalize string-char string-char-p string-downcase string-equal string-greaterp string-left-trim string-lessp string-not-equal string-not-greaterp string-not-lessp string-right-trim string-trim string-upcase string/= string< string<= string= string> string>= stringp structure sublis subseq subsetp subst subst-if subst-if-not substitute substitute-if substitute-if-not subtypep svref sxhash symbol symbol-function symbol-name symbol-package symbol-plist symbol-value symbolp t tagbody tailp tan tanh tenth terpri the third throw time trace tree-equal truename truncate type type-of typecase typep unexport unintern union unless unread-char unsigned-byte untrace unuse-package unwind-protect upper-case-p use-package user-homedir-pathname values values-list variable vector vector-pop vector-push vector-push-extend vectorp warn when with-input-from-string with-open-file with-open-stream with-output-to-string write write-byte write-char write-line write-string write-to-string y-or-n-p yes-or-no-p zerop ---- end-list John Foderaro Franz Inc.  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 23 May 86 10:41:49 EDT Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 23 May 86 07:34:39 PDT Received: ID ; Fri 23 May 86 10:33:49-EDT Date: Fri, 23 May 1986 10:33 EDT Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: COMMON-LISP@SU-AI.ARPA Subject: Where Pure Common Lisp lives In-reply-to: Msg of 23 May 1986 09:59-EDT from preece%ccvaxa at gswd-vms.ARPA (Scott E. Preece) I'm not wedded to the name "LOCAL", but if the place you go to get the default good environment on your machine is not "LISP", it has to be some standard package name. Maybe "EXTENDED", or whatever. This could be set up as a nickname for "SCL" or "DEC'S-PROPRIETARY-VAX-EXTENSIONS" or whatever, but it should be a uniform place on each machien so users don't have to hunt for it. -- Scott  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 23 May 86 10:11:25 EDT Received: from GSWD-VMS.ARPA by SU-AI.ARPA with TCP; 23 May 86 07:02:55 PDT Received: from ccvaxa.GSD (ccvaxa.ARPA) by gswd-vms.ARPA (5.9/) id AA00943; Fri, 23 May 86 09:01:50 CDT Message-Id: <8605231401.AA00943@gswd-vms.ARPA> Date: Fri, 23 May 86 08:59:07 cdt From: preece%ccvaxa@gswd-vms.ARPA (Scott E. Preece) To: COMMON-LISP@su-ai.arpa Subject: Re: Where Pure Common Lisp lives > From: David C. Plummer > > A nit pick on names: LOCAL is poor. ---------- I agree. LOCAL is a good name for site-local stuff, not for vendor-specific stuff. The name of the local extensions package probably ought to be the name of the implementation, possibly subdivided if the vendor supports multiple implmentations. Thus DEC ought to have a VAXLISP package and separate VAXLISP-ULTRIX and VAXLISP-VMS packages for OS-specific features [not picking on DEC -- they just came to mind as a vendor with multiple sub-implementations]. The default environment should be the most specific one; in the example case it should be LOCAL, which is on top of VAXLISP-ULTRIX, which is on top of VAXLISP, which is on top of LISP. Sites would normally, though, establish their own defaults at installation. -- scott preece gould/csd - urbana ihnp4!uiucdcs!ccvaxa!preece  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 23 May 86 08:12:57 EDT Received: from [192.10.41.223] by SU-AI.ARPA with TCP; 23 May 86 05:07:27 PDT Received: from FIREBIRD.SCRC.Symbolics.COM by SAPSUCKER.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 23010; Fri 23-May-86 08:02:40 EDT Date: Fri, 23 May 86 08:06 EDT From: David C. Plummer Subject: Where Pure Common Lisp lives To: Scott E. Fahlman , common-lisp@SU-AI.ARPA In-Reply-To: Message-ID: <860523080646.3.DCP@FIREBIRD.SCRC.Symbolics.COM> A nit pick on names: LOCAL is poor. What does LOCAL: mean to somebody in California (pick a site) running an implementation developed in the eastern US (pick a site)? VENDOR-EXTENSIONS: is more meaningful than LOCAL:. SYMBOLICS-COMMON-LISP: (SCL:) is >much< more meaningful than LOCAL:. I guess my question is: What is gained by agreeing on the standard package for extensions. I know this came up 6 weeks ago, but I don't think the issue was closed.  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 22 May 86 22:32:22 EDT Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 22 May 86 19:24:54 PDT Received: ID ; Thu 22 May 86 22:24:17-EDT Date: Thu, 22 May 1986 22:24 EDT Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: common-lisp@SU-AI.ARPA Subject: Where Pure Common Lisp lives OK, having been beaten soundly by everyone who has ever tried to port a big program, I'm ready to agree that the path of maximum sanity is to require that the LISP package contain only the symbols of pure Common Lisp, and that we create a new standard package (I like the name "LOCAL") for containing the local lisp environment, with possible extensions. I'd like to see some variable that holds the current default package for MAKE-PACKAGE, with the default default being LISP. We should encourage implementations (maybe require, but I'm not sure about this) not to extend the language by adding keywords and other non-standard options to the functions in LISP, but to put such extensions in LOCAL instead. Once we start considering exactly what goes into the ANSI/ISO spec (I'll be sending a message about this soon, probably over the weekend), I'll propose this for formal consideration. -- Scott  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 22 May 86 20:25:11 EDT Received: from HPLABS.ARPA by SU-AI.ARPA with TCP; 22 May 86 15:56:11 PDT Received: by hplabs.ARPA ; Thu, 22 May 86 15:54:14 pdt Date: Thu, 22 May 86 15:54:14 pdt From: hpfclp!diamant@hplabs.ARPA To: common-lisp@su-ai.ARPA Subject: Re: Keyword extensions to Compile From: hplabs!preece%ccvaxa@gswd-vms.ARPA (Scott E. Preece) > From: hpfclp!diamant@hplabs.ARPA > The problem with making the default environment the extended one is > that it is IMPOSSIBLE to write portable programs! If implementation X > makes an incompatible extension to COMPILE, and I want the CL-only > environment so I can use the CLtL version of COMPILE, I must say > something like: #+X (progn (unuse-package 'lisp) (use-package > 'cl-only)) ; or some other non-standard package name ---------- You're combining the important objection to "some other non-standard package name" with the objection to the default environment. They're separate issues. I think the name of the pure CL package should be standard (probably it should be lisp), but I think the default It is at least as important that the extended environment has a standard name, or you can't turn it off portably, if it is on by default. Sure, you can create your own package and explicitly use the pure package, but you can't unuse the extended package from the USER package unless its name is standardized. environment should be the local environment, including appropriate enhancements, and portable code should back off to the standard pure-CL package. I don't want users to have to specify their environment at startup, even in a canned initialization file. The default environment should be what corresponds to our implementation- specific users' guide. I was aware that I was discussing both issues, but I apologize if it was unclear from my comments above. Let me explain why I consider these related. I believe that we should make the ANSI standard upward compatible where possible with CLtL. This requires that the pure Common Lisp package be called LISP. Since CLtL also says that the default environment uses LISP (MAKE-PACKAGE states this explicitly), and that the USER package uses LISP, again the only way to make an upward compatible extension is to leave this alone, and use another mechanism to get full-blown environment (such as a global flag which is off by default). Otherwise, people who have written "portable" programs based on CLtL will have to change them (in a portable way) to work on ANSI standard Common Lisp. It is true, I am more concerned about there being a pure lisp package, and its being called LISP, than about the default environment. My earlier objection about the impossibility of writing portable programs hinges on the name of the extended package being non-standard, and I see general agreement here that we must standardize that name. My concern about the default environment is based on upward compatibility, and my concern about standardization of the name was to make sure that it was still possible to write portable programs. But the name of the pure-CL package should obviously be standardized. -- scott preece gould/csd - urbana ihnp4!uiucdcs!ccvaxa!preece My proposal is that we define a function with a standard name that tells MAKE-PACKAGE et. al. (and sets the values for the USER package) whether to go by CLtL or to include the extensions package, which by then will have a standard name. So you would say something like: (SET-DEFAULT-ENVIRONMENT 'LISP) ; for bare CLtL or (SET-DEFAULT-ENVIRONMENT 'EXTENSIONS) ; for the extended environment This would not only set the global flag, but change the use list of USER to contain the package specified instead of whichever one it had. This has to be a function instead of a variable, because it must actively change the use list of the USER package. I would still prefer that this would be set to LISP by default so that programs which are now portable don't need to change when the ANSI standard comes out, but this way each user can set up (say in an init file) his preference for getting a portable environment, or a "full" environment. Notice that this scheme has the added advantage of allowing the user to specify an arbitrary default environment (he can make a package with any mix of LISP, EXTENSIONS, or whatever -- even merge extensions from multiple Lisps, if the source is available to him. By the way, regarding the home package problem that KMP mentions, we need to require that the home package of the symbols exported from the LISP package (the pure one) are homed in the LISP package. John Diamant Systems Software Operation UUCP: {ihnp4!hpfcla,hplabs}!hpfclp!diamant Hewlett Packard Co. ARPA/CSNET: diamant%hpfclp@hplabs Fort Collins, CO  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 22 May 86 13:10:10 EDT Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 22 May 86 09:58:30 PDT Received: from HUMMINGBIRD.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 5065; Thu 22-May-86 13:00:03 EDT Date: Thu, 22 May 86 12:56 EDT From: Kent M Pitman Subject: Further remarks about portability To: Common-Lisp@SU-AI.ARPA In-Reply-To: <8605220344.AA00603@kurims.kyoto-u.junet>, The message of 21 May 86 14:03-PDT from hpfclp!diamant@hplabs.ARPA, <8605211723.AA03797@hplsny> Message-ID: <860522125620.8.KMP@HUMMINGBIRD.SCRC.Symbolics.COM> This message contains replies to and remarks about several of the messages which have crossed the list since my message a couple of days ago... Date: Thu, 22 May 86 12:44:25+0900 From: yuasa@kurims.kurims.kyoto-u.junet Having heard of the problems on the LISP package extensions, I got tempted to add the following constant into our system. THOSE-SYMBOLS-THAT-ARE-ADDED-IN-THE-LISP-PACKAGE [Constant] ... (The name does not matter.) With this constant, implementors of portable code could do the shadowing easily. (SHADOW THOSE-SYMBOLS-THAT-ARE-ADDED-IN-THE-LISP-PACKAGE) I know this would not solve all the problem, but it is better than nothing. At least, Gregor's PCL code might become clearer, if all CL implementations support this kind of constant. Any comments? If you implement such a thing without the rest of us standardizing on it, it's of little value since portable code won't know to look for it. I mention this only because you sounded like your message sounds like you're looking for an interim solution. Also, -all- portable programs would have to begin with: (SHADOW THOSE-SYMBOLS-THAT-ARE-ADDED-IN-THE-LISP-PACKAGE) because they wouldn't stand a real chance of running correctly without it. This seems a little silly since the point of CL was not to agree on a package that was incompatible and then to patch it with a way to get around that agreed-upon incompatibility. The point of CL was to give users who cared about portability something they could cling to so they don't get swept away by the whims of designers of specific implementations. If we don't give people at least that, we're not doing very much for them. I think it was Jonathan Rees who pointed out that the problem is more severe because the home package of a symbol severely affects the portability of code which has been read by READ and printed by PRINT in a given implementation. This problem fails to be addressed by your shadow technique. Consider the following program: (IN-PACKAGE 'PROCESSOR) (USE-PACKAGE 'LISP) (SHADOW THOSE-SYMBOLS-THAT-ARE-ADDED-IN-THE-LISP-PACKAGE) (DEFUN PROCESS-FILE (INPUT-FILE OUTPUT-FILE) (LET ((*PACKAGE* (FIND-PACKAGE "PROCESSOR"))) (WITH-OPEN-FILE (INPUT-STREAM INPUT-FILE :DIRECTION :INPUT) (WITH-OPEN-FILE (OUTPUT-STREAM OUTPUT-FILE :DIRECTION :OUTPUT) (PRINT (READ INPUT-STREAM) OUTPUT-STREAM))))) and a file A.LISP which contains the expression: (FOO LISP:FOO) If (PROCESS-FILE "A.LISP" "B.LISP") is done, then B.LISP is not portable if the LISP package can vary its contents because the output may contain either (FOO LISP:FOO) or (FOO FOO) depending upon whether FOO was on the LISP package and therefore got shadowed in this implementation. In another implementation, different results will be produced. If the results of such processing are shared back and forth between different implementations (as I could easily imagine wanting to happen in Macsyma's save files, for example), the results could be disastrous. Finally, I'd like to remark that I couldn't help getting a chuckle out of the following message from John Diamant. He's obviously in agreement with me on this, but unfortunately (as I've learned the hard way), the full magnitude of the problem is worse than he describes it... Date: Wed, 21 May 86 14:03:49 pdt From: hpfclp!diamant@hplabs.ARPA ... The problem with making the default environment the extended one is that it is IMPOSSIBLE to write portable programs! If implementation X makes an incompatible extension to COMPILE, and I want the CL-only environment so I can use the CLtL version of COMPILE, I must say something like: #+X (progn (unuse-package 'lisp) (use-package 'cl-only)) ; or some other non-standard package name I realize that someday we may agree on the name of the this other package, but that isn't an upward compatible change. It requires everyone trying to write portable code based on the first edition of CLtL to change their code. The piece of code above has made the inherently portable program no longer portable (since if I didn't know about implementation X, I couldn't have written it to run on implementation X). Not only is all this too true, but even worse, we don't even require implementations to put any distinguishing feature in their implementation. Eg, VAXLISP 1.2 comes up with a features list that includes things like VAX, VMS, etc. but nothing that says DIGITAL or DEC or anything. The result is that if I knew someone else (eg, LUCID) had implemented a lisp that ran under VAX VMS, I'd not be able to tell from the features list whose Lisp I was running under. To further aggravate things, we don't specify what package things in the features list should be in, so while on the LispM you do (PUSH ':FOO LISP:*FEATURES*) and later #+FOO in any package works, in VAXLISP you have to do (PUSH 'WHATEVER:FOO LISP:*FEATURES*) and #+FOO only works in the WHATEVER package. (I assume #+WHATEVER:FOO works elsewhere but have never actually constructed the test. Perhaps I shouldn't be so sure, though, since #+3600 and #-3600 don't do the obvious thing -- they both get read errors. No reason they shouldn't since CLtL doesn't say they'll work.) My point is that we failed to standardize just enough even on #+ and #- so that it's hard even when you've bitten the bullet and decided to just write implementation specific code in some places. This is a terrible shame. In retrospect, I think that if there's one thing we should have gotten right in the first release of CL, it was #+ and #- so that people would have a foothold when other things didn't work. Right along side that should have been to make the LISP package contain all and only the things mentioned in CLtL. There just isn't a substitute for this. Anything less just screws those people who care about portability. It's silly to say that there shouldn't be a standard package which contains only CL stuff because allowing that to happen lets open the situation where I could create a system which took all symbols having n letters or less which were not defined in CLtL and defined them to be system constants that couldn't be assigned, bound, etc. and which had completely silly values. Would we want to admit that such a language was a Common Lisp? Fahlman is arguing that we should. It's also silly to say that the point of CL was to define a lot of interesting meanings but finally not to put them in some known place, which is effectively what Fahlman is suggesting. I'm not trying to cast blame on anyone about past decisions. Most of us had the power to speak up early on and failed to notice the impending problem. As they say, hindsight is always 20/20. If we made mistakes, they were arguably not intentional. CL is obviously a highly ambitious experiment in portability. There were so many things to deal with the first time around that it wasn't possible to know what was going to matter in the end. But now we're at the crossroads to the future with time our side and better access to experience and knowledge than we had the last time around. If we make any new CL spec and it doesn't correct these problems, lack of proper experience and time isn't going to be so good a defense. Users are going to think that either we don't care about portability or that we don't understand it. I don't know which I think would be worse.  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 22 May 86 11:11:46 EDT Received: from GSWD-VMS.ARPA by SU-AI.ARPA with TCP; 22 May 86 08:06:35 PDT Received: from ccvaxa.GSD (ccvaxa.ARPA) by gswd-vms.ARPA (5.9/) id AA00104; Thu, 22 May 86 10:05:49 CDT Message-Id: <8605221505.AA00104@gswd-vms.ARPA> Date: Thu, 22 May 86 09:17:06 cdt From: preece%ccvaxa@gswd-vms.ARPA (Scott E. Preece) To: COMMON-LISP@su-ai.arpa Subject: Re: Keyword extensions to Compile > From: hpfclp!diamant@hplabs.ARPA > The problem with making the default environment the extended one is > that it is IMPOSSIBLE to write portable programs! If implementation X > makes an incompatible extension to COMPILE, and I want the CL-only > environment so I can use the CLtL version of COMPILE, I must say > something like: #+X (progn (unuse-package 'lisp) (use-package > 'cl-only)) ; or some other non-standard package name ---------- You're combining the important objection to "some other non-standard package name" with the objection to the default environment. They're separate issues. I think the name of the pure CL package should be standard (probably it should be lisp), but I think the default environment should be the local environment, including appropriate enhancements, and portable code should back off to the standard pure-CL package. I don't want users to have to specify their environment at startup, even in a canned initialization file. The default environment should be what corresponds to our implementation- specific users' guide. But the name of the pure-CL package should obviously be standardized. -- scott preece gould/csd - urbana ihnp4!uiucdcs!ccvaxa!preece  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 22 May 86 03:07:44 EDT Received: from SU-SHASTA.ARPA by SU-AI.ARPA with TCP; 22 May 86 00:01:16 PDT Received: by su-shasta.arpa; Wed, 21 May 86 23:59:58 PDT Received: by ntt.junet (4.12/4.7JC-7) CHAOS with CHAOS-MAIL id AA12294; Thu, 22 May 86 13:33:33 jst From: yuasa@kurims.kurims.kyoto-u.junet Received: by ntt.junet (4.12/4.7JC-7) CHAOS with CHAOS-MAIL id AA12254; Thu, 22 May 86 13:32:27 jst Received: by kurims.kyoto-u.junet (2.0/4.7) id AA00603; Thu, 22 May 86 12:44:25+0900 Date: Thu, 22 May 86 12:44:25+0900 Message-Id: <8605220344.AA00603@kurims.kyoto-u.junet> To: common-lisp@su-ai.arpa Having heard of the problems on the LISP package extensions, I got tempted to add the following constant into our system. THOSE-SYMBOLS-THAT-ARE-ADDED-IN-THE-LISP-PACKAGE [Constant] The value of this constant is a list of those symbols that are added in the LISP package by the implementation. An external symbol in the LISP package must be either the one specified in CLtL or an element of this list, may not be both. It is expected that the value of this constant be NIL. (The name does not matter.) With this constant, implementors of portable code could do the shadowing easily. (SHADOW THOSE-SYMBOLS-THAT-ARE-ADDED-IN-THE-LISP-PACKAGE) I know this would not solve all the problem, but it is better than nothing. At least, Gregor's PCL code might become clearer, if all CL implementations support this kind of constant. Any comments? -- Taiichi  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 21 May 86 23:44:29 EDT Received: from MIT-MULTICS.ARPA by SU-AI.ARPA with TCP; 21 May 86 20:39:19 PDT Date: Wed, 21 May 86 23:31 EDT From: Hvatum@MIT-MULTICS.ARPA Subject: (see below) To: common-lisp@SU-AI.ARPA Message-ID: <860522033136.597246@MIT-MULTICS.ARPA> To: Common-Lisp From: Stephen Bacher at Draper Lab Subject: Lexical references in DEFMACRO - reply to a previous message from Dave Moon > I think if you actually write out the seemingly obvious defmacro, you > will see that it's not so: > > (defmacro foo-p (x) `(and (listp ,x) (eq (car ,x) unique-id)))) > > which does not reference unique-id as a variable from the body of > the macro, only from the expansion of the macro. > I don't see what Dave Moon is trying to accomplish here. The point of the discussion is whether you can reference lexical variables in the expansion function, not in the expanded body - of course you can't reference the lexical variable in the expanded code! So, if DEFMACRO uses a null lexical environment, you can't reference UNIQUE-ID, and if it doesn't, you can, and the appropriate macro definition to test this should be: (defmacro foo-p (x) `(and (listp ,x) (eq (car ,x) ',unique-id))) ================================================================== MC.LCS.MIT.EDU is flakey. We may have missed mail that would make the above comment moot. Please remove KSH@MC.LCS.MIT.EDU from the Common-Lisp distribution and add Hvatum@MULTICS.MIT.EDU instead. Thanks. ==================================================================  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 21 May 86 21:01:34 EDT Received: from [192.10.41.223] by SU-AI.ARPA with TCP; 21 May 86 17:51:48 PDT Received: from FIREBIRD.SCRC.Symbolics.COM by SAPSUCKER.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 22684; Wed 21-May-86 20:46:37 EDT Date: Wed, 21 May 86 20:51 EDT From: David C. Plummer Subject: Re: case using other equality-testing predicates To: Gregor.pa@Xerox.COM, Moon@SCRC-STONY-BROOK.ARPA cc: common-lisp@SU-AI.ARPA In-Reply-To: <860521-160538-1375@Xerox> Message-ID: <860521205110.7.DCP@FIREBIRD.SCRC.Symbolics.COM> Date: 21 May 86 16:03 PDT From: Gregor.pa@Xerox.COM From: David A. Moon Subject: case using other equality-testing predicates So where would additional options, such as :KEY and an option that controls whether or not the keys at the heads of the clauses are evaluated, go in your syntax? Do we really need additional options? Its easy to get the behavior of a :key option in the obvious way, after all: (ncase (car item) #'eq (a (do-a)) (b (do-b)) (otherwise (lose))) is at least as clear as: (ncase item (:test #'eq :key #'car) (a (do-a)) (b (do-b)) (otherwise (lose))) or something, and since none of the other case macros make it possible to evaluate the "keys at the heads of the clauses" I am not sure why this one should. [I'm not wedded to the name selector.] Symbols (the normal thing case gets used for) aren't evaluated because that is the normal thing for case. Consider my original example again: (selector foo < (1 "small") (10 "moderate") (q "less than q") (1000 "big") (otherwise "huge")) This can't be done unless Q gets evaluated because the test isn't EQL but something arbitrary. I'll warn the community of some rather strange looking code this can sometimes produce: - If you want to use EQUAL on a list, you need to do something like (selector foo equal (('(1 2 3) ...whatever...))) because (selector foo equal ('(1 2 3) ...whatever...)) is realy (selector foo equal ((quote (1 2 3)) ...whatever...)) => (cond ((or (equal foo quote) (equal foo (1 2 3))) ...whatever...)) which is not what was intended. Maybe the implicit OR clause shouldn't be included?  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 21 May 86 19:10:21 EDT Received: from XEROX.COM by SU-AI.ARPA with TCP; 21 May 86 16:06:10 PDT Received: from Salvador.ms by ArpaGateway.ms ; 21 MAY 86 16:05:38 PDT Date: 21 May 86 16:03 PDT From: Gregor.pa@Xerox.COM Subject: Re: case using other equality-testing predicates In-reply-to: David A. Moon 's message of Wed, 21 May 86 14:14 EDT To: Moon@SCRC-STONY-BROOK.ARPA cc: common-lisp@SU-AI.arpa Message-ID: <860521-160538-1375@Xerox> From: David A. Moon Subject: case using other equality-testing predicates So where would additional options, such as :KEY and an option that controls whether or not the keys at the heads of the clauses are evaluated, go in your syntax? Do we really need additional options? Its easy to get the behavior of a :key option in the obvious way, after all: (ncase (car item) #'eq (a (do-a)) (b (do-b)) (otherwise (lose))) is at least as clear as: (ncase item (:test #'eq :key #'car) (a (do-a)) (b (do-b)) (otherwise (lose))) or something, and since none of the other case macros make it possible to evaluate the "keys at the heads of the clauses" I am not sure why this one should.  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 21 May 86 18:33:13 EDT Received: from AI.AI.MIT.EDU by SU-AI.ARPA with TCP; 21 May 86 15:25:25 PDT Date: Wed, 21 May 86 17:50:46 EDT From: Jonathan A Rees Subject: Keyword extensions to Compile To: Fahlman@C.CS.CMU.EDU cc: common-lisp@SU-AI.ARPA, Gregor.pa@XEROX.COM, KMP@SCRC-STONY-BROOK.ARPA In-reply-to: Msg of Wed 21 May 1986 16:43 EDT from Scott E. Fahlman Message-ID: <[AI.AI.MIT.EDU].44171.860521.JAR> Date: Wed, 21 May 1986 16:43 EDT From: Scott E. Fahlman I guess if we want to get serious about portable code, we're going to have to require that implementations provide a pure Common Lisp package, even though this will be pretty bloody for implementations that didn't start off this way. Then all we've got to argue about is whether the pure or extended version gets the name "LISP", and with it the default inclusion into other packages. This is not a life-or-death issue with me, but I think that getting the extended stuff by default is the right way to go. I also agree with what Kent and Gregor have said on this topic. I'm not sure I understand why anyone bothered inventing Common Lisp in the first place if we weren't serious about portability. I think this is a very important question. I get the impression that very few people out there have tried moving real programs from one Common Lisp implementation to another. One thing that makes this situation particularly bad is that people who are closest to the implementations themselves, and are in a position to make life easier for those of us trying to write portable code, are exactly those people LEAST likely to need to transport code, so I don't believe their motivation to make portability really work is very high. Chances are good that they don't even use other implementations besides their own. I don't perceive market demands here, either (yet), which would be another motivation to clean this up. So right now a small number of us just have to suffer. I don't think we need to go to the Ada extreme, but there is a lot to be said for it. The current state of affairs is quite unsatisfactory. Jonathan  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 21 May 86 17:38:24 EDT Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 21 May 86 14:06:28 PDT Received: from SORA.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 4186; Wed 21-May-86 17:08:11 EDT Date: Wed, 21 May 86 17:05 EDT From: Bernard S. Greenberg Subject: case using other equality-testing predicates To: Moon@SCRC-STONY-BROOK.ARPA, common-lisp@SU-AI.ARPA In-Reply-To: <860521141451.1.MOON@EUPHRATES.SCRC.Symbolics.COM> Message-ID: <860521170559.1.BSG@SORA.SCRC.Symbolics.COM> Date: Wed, 21 May 86 14:14 EDT From: David A. Moon Date: Tue, 20 May 1986 23:45 EDT From: "Scott E. Fahlman" I'm sure some people will jump all over me for suggesting this, but it might be better to allow CASE to accept a :TEST keyword. Which of these three syntaxes do you-all prefer? (selector item equalp ("foo" ...) ...) (case item :test #'equalp ("foo" ...) ...) (cond ((equalp item "foo") ...) ...) I think that mixing keywords into a construct like Case that already has a complex syntax is likely to cause confusion. I agree. But the other alternatives cause confusion, too. I would prefer adding a new construct CASE-TEST that would look like (case-test #'equalp item ("foo" ...) ...) This is similar to your Selector, but without the odd treatment of the test function, and the name emphasizes the close parallel to Case. I think it is best to put the test function before the item -- other things in the language put the testing function first. So where would additional options, such as :KEY and an option that controls whether or not the keys at the heads of the clauses are evaluated, go in your syntax? I guess it's obvious why Common Lisp doesn't currently have a way to do this -- no one has thought of a syntax for it that anyone else likes. (seleckter object (:key -- :test ---) ("foo" ...  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 21 May 86 17:13:14 EDT Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 21 May 86 14:06:28 PDT Received: from SORA.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 4186; Wed 21-May-86 17:08:11 EDT Date: Wed, 21 May 86 17:05 EDT From: Bernard S. Greenberg Subject: case using other equality-testing predicates To: Moon@SCRC-STONY-BROOK.ARPA, common-lisp@SU-AI.ARPA In-Reply-To: <860521141451.1.MOON@EUPHRATES.SCRC.Symbolics.COM> Message-ID: <860521170559.1.BSG@SORA.SCRC.Symbolics.COM> Date: Wed, 21 May 86 14:14 EDT From: David A. Moon Date: Tue, 20 May 1986 23:45 EDT From: "Scott E. Fahlman" I'm sure some people will jump all over me for suggesting this, but it might be better to allow CASE to accept a :TEST keyword. Which of these three syntaxes do you-all prefer? (selector item equalp ("foo" ...) ...) (case item :test #'equalp ("foo" ...) ...) (cond ((equalp item "foo") ...) ...) I think that mixing keywords into a construct like Case that already has a complex syntax is likely to cause confusion. I agree. But the other alternatives cause confusion, too. I would prefer adding a new construct CASE-TEST that would look like (case-test #'equalp item ("foo" ...) ...) This is similar to your Selector, but without the odd treatment of the test function, and the name emphasizes the close parallel to Case. I think it is best to put the test function before the item -- other things in the language put the testing function first. So where would additional options, such as :KEY and an option that controls whether or not the keys at the heads of the clauses are evaluated, go in your syntax? I guess it's obvious why Common Lisp doesn't currently have a way to do this -- no one has thought of a syntax for it that anyone else likes. (seleckter object (:key -- :test ---) ("foo" ...  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 21 May 86 17:11:44 EDT Received: from HPLABS.ARPA by SU-AI.ARPA with TCP; 21 May 86 14:05:33 PDT Received: by hplabs.ARPA ; Wed, 21 May 86 14:03:49 pdt Date: Wed, 21 May 86 14:03:49 pdt From: hpfclp!diamant@hplabs.ARPA To: common-lisp@su-ai.ARPA Subject: Re: Keyword extensions to Compile From: "Scott E. Fahlman" Put another way, I think that every implementation should pick some other package and put all their extensions on that package and leave the LISP package pure. We've hashed this one out at length. If someone doesn't think that there was overwhelming concensus that this was the right thing, I'd like to hear from them. I don't think that consensus was reached on this. There was mail on both sides, and in the absence of a decision procedure, the discussion eventually petered out. This will certainly be among the issues we want to get a final decision on as the ANSI spec is developed. Since you ask, my own view is (still) that each implementation will want to provide a default Lisp environment for their users, including all of Common Lisp plus some implementation-specific extensions, and that this is what should live in the LISP package and be inherited by default in other packages such as USER. It is certainly a good idea to have some other package that is pure Common Lisp, but this should not be the default environment for users. The mix of things in the default environment should be a local option. -- Scott The problem with making the default environment the extended one is that it is IMPOSSIBLE to write portable programs! If implementation X makes an incompatible extension to COMPILE, and I want the CL-only environment so I can use the CLtL version of COMPILE, I must say something like: #+X (progn (unuse-package 'lisp) (use-package 'cl-only)) ; or some other non-standard package name I realize that someday we may agree on the name of the this other package, but that isn't an upward compatible change. It requires everyone trying to write portable code based on the first edition of CLtL to change their code. The piece of code above has made the inherently portable program no longer portable (since if I didn't know about implementation X, I couldn't have written it to run on implementation X). If, on the other hand, the lisp package (and the default environment) contained no extensions, you wouldn't need to say anything for portable programs, and for programs specific to that environment, you would say: #+X (use-package 'extensions) ; or whatever it is called. It is much preferable to require the use of *features* in inherently non-portable code than in portable code that has been made non-portable because the Lisp system comes up in a non-portable mode. John Diamant  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 21 May 86 17:01:35 EDT Received: from CS.UCL.AC.UK by SU-AI.ARPA with TCP; 21 May 86 13:56:40 PDT Received: from aiva.edinburgh.ac.uk by 44d.Cs.Ucl.AC.UK via Janet with NIFTP id a000698; 21 May 86 18:11 BST From: Jeff Dalton Date: Wed, 21 May 86 17:04:43 -0100 Message-Id: <9828.8605211604@aiva.ed.ac.uk> To: Fahlman@c.cs.cmu.edu, KMP@scrc-stony-brook.arpa Subject: Porting Cl code Cc: common-lisp@su-ai.arpa, eulisp%inria.uucp@Cs.Ucl.AC.UK Date: Tue, 20 May 86 17:16 EDT From: Kent M Pitman Subject: Keyword extensions to Compile Let's stop talking "legal" for a while and talk "rational". ... I've spent some time in-house talking to our software support staff about problems they're going to come up against when dealing with CL customers and the worst one is going to be the fact that customers using CL are going to expect that porting CL code should be a breeze and are going to be quite surprised at the difficulties they can encounter. In my opinion, that's a fault of CL, not a fault of Symbolics or DEC or Lucid or whomever. ... I fully agree with everything Kent said in his message, and in particular that (1) implementations should package extensions so that they do not make visible changes in the basic language, (2) stricter implementations are better in that code written for them will be more portable, and (3) portability problems are often due to looseness in the specification. (Consider, for example, compiling. CLtL says very little about the compiler and refers to most uses of EVAL-WHEN as "esoteric". There is little to guide a user (or implementor) who is not already familiar with a similar system, and implementations of CL differ on default "eval-when times". IN KCL, for example, everything seems to be eval-compile-load, so it is very easy to write programs that run interpreted and compile in KCL but do not compile in, say, Lucid.) One of the most common criticisms of Common Lisp that I hear, and such criticism may be more common now in Europe than in the US, is that it is not really a language but a collection of languages, and that it takes work to port programs from one dialect to another. In a sense, the whole point to Common Lisp is to make porting easier; we should do everything we can to make it so. -- Jeff  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 21 May 86 16:52:11 EDT Received: from [192.10.41.223] by SU-AI.ARPA with TCP; 21 May 86 13:46:16 PDT Received: from FIREBIRD.SCRC.Symbolics.COM by SAPSUCKER.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 22528; Wed 21-May-86 16:41:19 EDT Date: Wed, 21 May 86 16:45 EDT From: David C. Plummer Subject: Coerce (Symbols) To: ELIOT%umass-cs.csnet@CSNET-RELAY.ARPA, common-lisp@SU-AI.ARPA In-Reply-To: The message of 20 May 86 16:31 EDT from ELIOT%umass-cs.csnet@CSNET-RELAY.ARPA Message-ID: <860521164558.1.DCP@FIREBIRD.SCRC.Symbolics.COM> Date: Tue, 20 May 86 15:31 EST From: ELIOT%umass-cs.csnet@CSNET-RELAY.ARPA Coercing symbols to strings is fine, as long as NIL is treated as the empty SEQUENCE, rather than as a symbol. I have also wanted to have an :initial-contents argument to make-string and make-sequence, analogous to make-array. (Make-list should also have an :initial-contents arg.) Does (coerce 'string) return (symbol-name ), or (format nil "~S" ), which would (possibly) include the package, or (format nil "~A::~A" (package-name (symbol-package )) (symbol-name )) or what? If this weren't enough, added in with my personal views of style and functionality, for me to want to help veto this coersion, the special casing of NIL certainly would. Programs should reflect their meaning. A string is a sequence, a symbol is not. Why shouldn't (coerce :ascii-EOT 'integer) work? The answer is that the requested behavior is not a coersion between compatible types, it is a functional translation between human understandable names for the ascii control characters and the integers that are their corresponding values.  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 21 May 86 16:50:51 EDT Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 21 May 86 13:44:30 PDT Received: ID ; Wed 21 May 86 16:43:25-EDT Date: Wed, 21 May 1986 16:43 EDT Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: Gregor.pa@XEROX.COM Cc: common-lisp@SU-AI.ARPA, KMP@SCRC-STONY-BROOK.ARPA Subject: Keyword extensions to Compile In-reply-to: Msg of 21 May 1986 14:40-EDT from Gregor.pa at Xerox.COM The point is a portable program needs to know what it is going to get when it says (make-package 'foo), an implementation-specific program can know that it will get extra nice stuff if it says (make-package 'foo :use 'extended-common-lisp), but a portable program needs to be able to protect itself from that extra stuff. Or alternatively, the portable package could say (make-package 'foo :use 'pure-common-lisp) while random users say (make-package 'foo). I guess if we want to get serious about portable code, we're going to have to require that implementations provide a pure Common Lisp package, even though this will be pretty bloody for implementations that didn't start off this way. Then all we've got to argue about is whether the pure or extended version gets the name "LISP", and with it the default inclusion into other packages. This is not a life-or-death issue with me, but I think that getting the extended stuff by default is the right way to go. -- Scott  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 21 May 86 16:23:25 EDT Received: from XEROX.COM by SU-AI.ARPA with TCP; 21 May 86 13:15:33 PDT Received: from Cabernet.ms by ArpaGateway.ms ; 21 MAY 86 12:57:56 PDT Date: 21 May 86 11:40 PDT From: Gregor.pa@Xerox.COM Subject: Re: Keyword extensions to Compile In-reply-to: "Scott E. Fahlman" 's message of Tue, 20 May 86 23:35 EDT To: Fahlman@C.CS.CMU.EDU cc: KMP@SCRC-STONY-BROOK.ARPA, common-lisp@SU-AI.arpa Message-ID: <860521-125756-1077@Xerox> From: "Scott E. Fahlman" To: Kent M Pitman Subject: Keyword extensions to Compile I don't think that consensus was reached on this. There was mail on both sides, and in the absence of a decision procedure, the discussion eventually petered out. This will certainly be among the issues we want to get a final decision on as the ANSI spec is developed. I don't recall any argument that other than "it might be nice for users of that implementation" that suggested that implementations should be allowed to put extra symbols in the lisp package. I believe that Kent and I made strong cases for not doing this based on the kinds of problems it has caused us both. The point is a portable program needs to know what it is going to get when it says (make-package 'foo), an implementation-specific program can know that it will get extra nice stuff if it says (make-package 'foo :use 'extended-common-lisp), but a portable program needs to be able to protect itself from that extra stuff.  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 21 May 86 16:23:13 EDT Received: from XEROX.COM by SU-AI.ARPA with TCP; 21 May 86 13:15:25 PDT Received: from Cabernet.ms by ArpaGateway.ms ; 21 MAY 86 11:40:43 PDT Date: 21 May 86 10:51 PDT Sender: Bobrow.pa@Xerox.COM Subject: Re: case using other equality-testing predicates In-reply-to: David A. Moon 's message of Tue, 20 May 86 15:35 EDT To: Moon@SCRC-STONY-BROOK.ARPA cc: fateman%dim@UCBVAX.Berkeley.EDU, common-lisp@SU-AI.ARPA From: Bobrow.pa@Xerox.COM (Danny Bobrow) Message-ID: <860521-114043-168@Xerox> >> ...to be able to specify the test function in CASE. >> (selector item equalp ("foo" ...) ...) >> >> (case item :test #'equalp ("foo" ...) ...) >> >> (cond ((equalp item "foo") ...) ...) Of the three, I prefer the (case item :test #'equalp ("foo" ...) ...) But I would rather a separate function (case-with-test item equalp ...) ----- dgb:  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 21 May 86 15:59:06 EDT Date: 1986 May 19 09:34:14 PST (=GMT-8hr) From: Robert Elton Maas To:gls@THINK-AQUINAS.ARPA CC:MATHIS@USC-ISIF.ARPA,COMMON-LISP@SU-AI.ARPA Subject:Mismatch between name of function and what it really does G> Date: Mon, 19 May 86 12:20 EDT G> From: Guy Steele G> Subject: coercion of symbols to strings (Re allowing (COERCE 'X 'STRING) to coerce X to the string "X") G> ..., and so the general decision was made that G> string-specific functions would accept symbols, but general sequence G> functions would not. COERCE was limited to performing, for the most part, G> sequence coercions and numerical coercions. This is one of the bad points (in my opinion) of many LISPs, including CL, functions that are mis-named or otherwise don't do what you'd except from their name. Examples: INTERN doesn't internalize things any more, it does something different which I don't understand (why not use a different name?) COERCE works only for sequences and numbers, not for arbitrary things that can obviously be coerced. For the latter you have to use various other functions whose names you have to individually remember. NTH may return a tail or the CAR of a tail, may take the list or the index as first argument, and may take the index starting at 0 or at 1, in various LISPs, and having used several I can never remember which it is currently this year (why not do what I do, name this and related functions more explicitly: NTHCDR-LN0 NTHC-LN0 NTHCDR-N0L NTHC-N0L NTHCDR-LN1 NTHC-LN1 NTHCDR-N1L NTHC-N1L for the 8 possible variants, each of which is optimal for certain applications?). I hope (my opinion, of course) the international standards committee will fix this kind of problem so programmers reading somebody else's code can have the meaning apparent in most cases from general programming tradition rather than having to constantly check the manual to see if the function does what it seems to say it would do.  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 21 May 86 15:37:45 EDT Received: from [192.10.41.41] by SU-AI.ARPA with TCP; 21 May 86 12:30:41 PDT Received: from EUPHRATES.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 5442; Wed 21-May-86 14:17:26 EDT Date: Wed, 21 May 86 14:14 EDT From: David A. Moon Subject: case using other equality-testing predicates To: common-lisp@SU-AI.ARPA In-Reply-To: Message-ID: <860521141451.1.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Tue, 20 May 1986 23:45 EDT From: "Scott E. Fahlman" I'm sure some people will jump all over me for suggesting this, but it might be better to allow CASE to accept a :TEST keyword. Which of these three syntaxes do you-all prefer? (selector item equalp ("foo" ...) ...) (case item :test #'equalp ("foo" ...) ...) (cond ((equalp item "foo") ...) ...) I think that mixing keywords into a construct like Case that already has a complex syntax is likely to cause confusion. I agree. But the other alternatives cause confusion, too. I would prefer adding a new construct CASE-TEST that would look like (case-test #'equalp item ("foo" ...) ...) This is similar to your Selector, but without the odd treatment of the test function, and the name emphasizes the close parallel to Case. I think it is best to put the test function before the item -- other things in the language put the testing function first. So where would additional options, such as :KEY and an option that controls whether or not the keys at the heads of the clauses are evaluated, go in your syntax? I guess it's obvious why Common Lisp doesn't currently have a way to do this -- no one has thought of a syntax for it that anyone else likes.  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 21 May 86 13:33:36 EDT Received: from HPLABS.ARPA by SU-AI.ARPA with TCP; 21 May 86 10:25:03 PDT Received: from hplsny by hplabs.ARPA ; Wed, 21 May 86 10:23:16 pdt Received: by hplsny ; Wed, 21 May 86 10:23:15 pdt From: Alan Snyder Message-Id: <8605211723.AA03797@hplsny> Date: Wednesday, May 21, 1986 10:23:11 Subject: Re: Keyword extensions to Compile To: Fahlman@C.CS.CMU.EDU Cc: common-lisp@su-ai.ARPA In-Reply-To: Your message of 20-May-86 23:35:00 X-Sent-By-Nmail-Version: 04-Nov-84 17:14:46 For implementation X to be a superset of Common Lisp means that Common Lisp programs written according to the manual will run in X ... you make a superset by taking various cases that are errors in vanilla Common Lisp and by giving them useful interpretations in your superset. This is usually done with undefined functions, ... Since you ask, my own view is (still) that each implementation will want to provide a default Lisp environment for their users, including all of Common Lisp plus some implementation-specific extensions, and that this is what should live in the LISP package and be inherited by default in other packages such as USER. Common Lisp programs written "according to the manual" may fail to run in a supserset implementation under your proposal if they define packages that inherit from the LISP package (the default case) and the LISP package contains extra, unexpected symbols (because of package conflicts, unintended function redefinition, etc.). Alan -------  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 21 May 86 02:07:52 EDT Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 20 May 86 22:57:03 PDT Received: from umass-cs by csnet-relay.csnet id av02545; 21 May 86 1:33 EDT Date: Tue, 20 May 86 15:31 EST From: ELIOT%umass-cs.csnet@CSNET-RELAY.ARPA To: common-lisp@SU-AI.ARPA Subject: Coerce (Symbols) Coercing symbols to strings is fine, as long as NIL is treated as the empty SEQUENCE, rather than as a symbol. I have also wanted to have an :initial-contents argument to make-string and make-sequence, analogous to make-array. (Make-list should also have an :initial-contents arg.)  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 21 May 86 00:26:34 EDT Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 20 May 86 21:21:41 PDT Received: ID ; Wed 21 May 86 00:20:52-EDT Date: Wed, 21 May 1986 00:20 EDT Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: Dave.Touretzky@A.CS.CMU.EDU Cc: common-lisp@SU-AI.ARPA Subject: case-test In-reply-to: Msg of 21 May 1986 00:09-EDT from Dave.Touretzky at A.CS.CMU.EDU Wouldn't CASE-IF be closer to the other things in the language that take predicate first arguments (such as REMOVE-IF, FIND-IF, etc.)? I can't think of any other Common Lisp function that ends in -TEST. I thought about that, but I believe that the "if" forms all take unary predicates at present. -- Scott  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 21 May 86 00:13:34 EDT Received: from A.CS.CMU.EDU by SU-AI.ARPA with TCP; 20 May 86 21:10:12 PDT Date: 21 May 86 00:09 EDT From: Dave.Touretzky@A.CS.CMU.EDU To: common-lisp@SU-AI.ARPA Subject: case-test CC: fahlman@C.CS.CMU.EDU I like the idea of CASE-TEST, but not the name. Wouldn't CASE-IF be closer to the other things in the language that take predicate first arguments (such as REMOVE-IF, FIND-IF, etc.)? I can't think of any other Common Lisp function that ends in -TEST. -- Dave  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 20 May 86 23:49:34 EDT Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 20 May 86 20:46:24 PDT Received: ID ; Tue 20 May 86 23:45:35-EDT Date: Tue, 20 May 1986 23:45 EDT Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: "David A. Moon" Cc: common-lisp@SU-AI.ARPA Subject: case using other equality-testing predicates In-reply-to: Msg of 20 May 1986 15:35-EDT from David A. Moon I'm sure some people will jump all over me for suggesting this, but it might be better to allow CASE to accept a :TEST keyword. Which of these three syntaxes do you-all prefer? (selector item equalp ("foo" ...) ...) (case item :test #'equalp ("foo" ...) ...) (cond ((equalp item "foo") ...) ...) I think that mixing keywords into a construct like Case that already has a complex syntax is likely to cause confusion. I would prefer adding a new construct CASE-TEST that would look like (case-test #'equalp item ("foo" ...) ...) This is similar to your Selector, but without the odd treatment of the test function, and the name emphasizes the close parallel to Case. I think it is best to put the test function before the item -- other things in the language put the testing function first. -- Scott  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 20 May 86 23:40:03 EDT Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 20 May 86 20:36:24 PDT Received: ID ; Tue 20 May 86 23:35:34-EDT Date: Tue, 20 May 1986 23:35 EDT Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: Kent M Pitman Cc: common-lisp@SU-AI.ARPA Subject: Keyword extensions to Compile In-reply-to: Msg of 20 May 1986 17:16-EDT from Kent M Pitman Since day one we have emphasized that, while Common Lisp should be a perfectly usable language in its own right, many implementations would be supersets of Common Lisp. That was an essential part of the original treaty. The participation of Symbolics, in particular, was absolutely conditional on this point of view, since many beloved Lisp Machine features (beloved by Symbolics people at the time, anyway) obviously made no sense in a language that also had to be implemented on stock hardware. For many years, Symbolics people made a fetish of always referring to "the Common Lisp subset" rather than just "Common Lisp", though that seems to have gone away. For implementation X to be a superset of Common Lisp means that Common Lisp programs written according to the manual will run in X, but that many legal programs in implementation X will not be portable Common Lisp and will not necessarily run in implementation Y. Or, put another way, you make a superset by taking various cases that are errors in vanilla Common Lisp and by giving them useful interpretations in your superset. This is usually done with undefined functions, but it can also be done by adding new keywords to old functions or by extending type-specific functions to take new types of arguments that would otherwise be in error. There is some controversy over whether it is allowable to extend an implementation by returning extra values from built-in functions; I favor allowing this, but it is possible (not natural, but possible) to write legal Common Lisp code that would be screwed by this. I think that we should require an implementation to document any such extensions, and encourage implementors to provide a "portable" compiler mode that flags any use of non-standard extensions. But to outlaw extensions at this late date is impossible. I agree that it would be a good idea in an implementation to have a package (not necessarily the LISP package) in which nothing but pure Common Lisp is visible. I think we can encourage this, but I'm not sure about requiring it. Put another way, I think that every implementation should pick some other package and put all their extensions on that package and leave the LISP package pure. We've hashed this one out at length. If someone doesn't think that there was overwhelming concensus that this was the right thing, I'd like to hear from them. I don't think that consensus was reached on this. There was mail on both sides, and in the absence of a decision procedure, the discussion eventually petered out. This will certainly be among the issues we want to get a final decision on as the ANSI spec is developed. Since you ask, my own view is (still) that each implementation will want to provide a default Lisp environment for their users, including all of Common Lisp plus some implementation-specific extensions, and that this is what should live in the LISP package and be inherited by default in other packages such as USER. It is certainly a good idea to have some other package that is pure Common Lisp, but this should not be the default environment for users. The mix of things in the default environment should be a local option. -- Scott  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 20 May 86 23:12:02 EDT Received: from XEROX.COM by SU-AI.ARPA with TCP; 20 May 86 17:42:40 PDT Received: from Cabernet.ms by ArpaGateway.ms ; 20 MAY 86 17:20:30 PDT Date: 20 May 86 17:20 PDT From: Gregor.pa@Xerox.COM Subject: Re: Keyword extensions to Compile In-reply-to: Kent M Pitman 's message of Tue, 20 May 86 17:16 EDT To: KMP@SCRC-STONY-BROOK.arpa cc: Fahlman@C.CS.CMU.EDU, common-lisp@su-ai.arpa Message-ID: <860520-172030-1065@Xerox> Kent is right. These kinds of extensions are definitely responsible for a large number of porting problems. In addition to having all their extensions in another package, a quality implementation may want to consider using warnings to identify things that aren't real common-lisp. This would help someone prepare their code for porting. Gregor  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 20 May 86 21:11:35 EDT Received: from XEROX.COM by SU-AI.ARPA with TCP; 20 May 86 17:42:40 PDT Received: from Cabernet.ms by ArpaGateway.ms ; 20 MAY 86 17:20:30 PDT Date: 20 May 86 17:20 PDT From: Gregor.pa@Xerox.COM Subject: Re: Keyword extensions to Compile In-reply-to: Kent M Pitman 's message of Tue, 20 May 86 17:16 EDT To: KMP@SCRC-STONY-BROOK.arpa cc: Fahlman@C.CS.CMU.EDU, common-lisp@su-ai.arpa Message-ID: <860520-172030-1065@Xerox> Kent is right. These kinds of extensions are definitely responsible for a large number of porting problems. In addition to having all their extensions in another package, a quality implementation may want to consider using warnings to identify things that aren't real common-lisp. This would help someone prepare their code for porting. Gregor  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 20 May 86 17:29:53 EDT Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 20 May 86 14:18:10 PDT Received: from HUMMINGBIRD.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 3157; Tue 20-May-86 17:15:51 EDT Date: Tue, 20 May 86 17:16 EDT From: Kent M Pitman Subject: Keyword extensions to Compile To: Fahlman@CMU-CS-C.ARPA cc: common-lisp@SU-AI.ARPA In-Reply-To: Message-ID: <860520171605.2.KMP@HUMMINGBIRD.SCRC.Symbolics.COM> Date: Sat, 17 May 1986 20:25 EDT From: "Scott E. Fahlman" ... I think it is legal for you to extend your implementation in this way as the language is currently defined ... Let's stop talking "legal" for a while and talk "rational". There are lots of gaping holes in the language and it's one thing to agree that a Common Lisp which is "suspect" is technically correct because the manual doesn't contradict them. It's another thing altogether to suggest that implementations not yet written should be encouraged to be as loose with the wording. We want to be tolerant of those who took the manual at face value as a spec they could implement faithfully and be proud of, but we also want to keep in mind that there's much which we've learned since creating that spec and it would be silly not to encourage people to use this new knowledge when designing new CL systems. It continues to amaze me that people have made "upward-compatible" extensions to the core language. This just makes it hard to debug portable programs. CLtL has primitives built in which allow extensions to be made in a non-intrusive way and I think everyone should use those in their implementation and leave the standard language alone. Put another way, I think that every implementation should pick some other package and put all their extensions on that package and leave the LISP package pure. We've hashed this one out at length. If someone doesn't think that there was overwhelming concensus that this was the right thing, I'd like to hear from them. VAXLISP, to pick an example at random, does not currently do this. They throw lots of symbols in with the standard LISP package. I hope they have plans to change that. Symbolics almost does it right by having an SCL package for its extensions, but still doesn't go all the way by shadowing the symbols in LISP which it intends to extend incompatibly. I'm trying to get that changed. My recommendation to anyone who wants to extend COMPILE (or any other function)'s argument specs would be to simply shadow COMPILE on another package, FOO, and do (DEFUN LISP:COMPILE (NAME &OPTIONAL DEFINITION) (FOO:COMPILE NAME DEFINITION)) This way, callers of LISP:COMPILE cannot possibly get non-standard features in code that's intended to be portable. People who know about the extensions can also know what package they need to use in order to make the extensions available. Life becomes much simpler that way. The problem with making upward compatible extensions is that someone might accidentally use them and not remember the fact. They'd typically get no diagnostics from their compiler -- in the case of functions (especially in light of APPLY or the ability to have a variable evaluate to a keyword), it's not possible to detect all such uses at compile time. The result is that the first time they find out they're losing is when they port to another dialect and it rejects the extended argument syntax. ... if they're lucky. If they're not lucky, it doesn't reject the syntax. Maybe it thinks it understands the extended syntax -- and if it thinks it does, maybe it's right -- then again, maybe it's not. Maybe you eventually get an error signalled -- or maybe you just get the wrong answer. I'm not just making this problem up. It has already really happened to me in real-live attempts to port things. It is a royal pain to debug. If we don't take steps to alleviate it, we're doing users a disservice. I've spent some time in-house talking to our software support staff about problems they're going to come up against when dealing with CL customers and the worst one is going to be the fact that customers using CL are going to expect that porting CL code should be a breeze and are going to be quite surprised at the difficulties they can encounter. In my opinion, that's a fault of CL, not a fault of Symbolics or DEC or Lucid or whomever. In the long run, every vendor is going to have some set of users who are upset at the vendor because their program "which ran fine in some other implementation" doesn't work in the new implementation. More often than not, it's going to really be due to the fact that the "other implementation" was too forgiving and let them run non-portable code. My experience says that the user will blame the vendor who gave them the new, more restrictive implementation for their headaches, not the one that let them run the bogus code in the first place. If it's any vendor's fault that lossage arises, it's probably the less restrictive implementation, not the more restrictive one. But I don't think it's any vendor's fault at all. It isn't fair for the individual vendors to take this heat because they've had no advice about how to avoid this problem, or even that it's a problem to be avoided. The fault belongs to the designers. It's time we started asking serious questions about what portability is really about, and giving good advice about how implementors should proceed in the future before. Again, I'm not talking about declaring existing implementations to be "wrong". I'm just talking about laying down guidelines for how people can and should build better implementations in the future. For now it's just friendly advice. Nothing legalistic involved... yet. That advice -should- be part of a later spec, I think, and implementations which claimed to adhere to that revised spec and still didn't heed that advice would at that time be declared to be in error.  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 20 May 86 16:14:10 EDT Received: from [192.10.41.41] by SU-AI.ARPA with TCP; 20 May 86 13:02:35 PDT Received: from EUPHRATES.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 4184; Tue 20-May-86 15:38:12 EDT Date: Tue, 20 May 86 15:35 EDT From: David A. Moon Subject: case using other equality-testing predicates To: fateman%dim@UCB-VAX.ARPA cc: common-lisp@SU-AI.ARPA In-Reply-To: <8605201525.AA00779@dim> Message-ID: <860520153533.5.MOON@EUPHRATES.SCRC.Symbolics.COM> Regardless of whether your particular application does or does not need it, I too have long wanted to be able to specify the test function in CASE. In Symbolics Common Lisp we have this as an alternate function name. I'm sure some people will jump all over me for suggesting this, but it might be better to allow CASE to accept a :TEST keyword. Which of these three syntaxes do you-all prefer? (selector item equalp ("foo" ...) ...) (case item :test #'equalp ("foo" ...) ...) (cond ((equalp item "foo") ...) ...)  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 20 May 86 14:43:37 EDT Received: from [192.10.41.45] by SU-AI.ARPA with TCP; 20 May 86 11:33:09 PDT Received: from FIREBIRD.SCRC.Symbolics.COM by ALLEGHENY.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 17726; Tue 20-May-86 14:30:15-EDT Date: Tue, 20 May 86 14:23 EDT From: David C. Plummer Subject: case using other equality-testing predicates To: Richard Fateman , common-lisp@SU-AI.ARPA In-Reply-To: <8605201525.AA00779@dim> Message-ID: <860520142338.9.DCP@FIREBIRD.SCRC.Symbolics.COM> Date: Tue, 20 May 86 08:25:15 pdt From: fateman%dim@BERKELEY.EDU (Richard Fateman) If case used equalp or had a keyword :test with the usual meaning, I could use case instead of redefining it.. I include the explanation below for those who might choose to try to satisfy my perceived need by another programming construct.. For those familiar with the Lisp Machine Lisp-derived dialects, SELECTQ is pretty much CASE SELECT is sort-of selectq without the quoting of the items, e.g., (select foo (bar 1) (baz 2)) ==> (COND ((EQL FOO BAR) 1) ((EQL FOO BAZ) 2)) ; BAR and BAZ aren't quoted SELECTOR is like SELECT (doesn't quote) and gives you the predicate: (selector foo < (1 "small") (q "less than q") (100 "moderate") (1000 "big") (otherwise "huge")) ==> (COND ((< FOO 1) "small") ((< FOO Q) "less than q") ((< FOO 100) "moderate") ((< FOO 1000) "big") (T "huge")) Since CLtL doesn't have this functionality, Symbolics has included it in their extensions. I also note CLtL doesn't have the functionality of SELECT (which is SELECTOR using EQL), so Symbolics provides that too. In an application I had hoped to put in a package, I used a construction analogous to (in-package 'commandpackage) ..... (case com ;; com is a command, an atom read in by Lisp reader (p ) ((1 first) ) (cos ) ... etc) Now when you read in the atom p, it is not the same as the item in the case table, which is commandpackage::p. Exporting and then shadowing-importing p, first, cos, .. is not a good idea, (in general), but specifically because the symbols first, cos, etc would cover up the functions of the same name. What it seems I need is another macro in the case-family that tests using equalp rather than eql, so I can use strings.. e.g. (string-case (string com) ("p" ) (("1" "first") ) ... etc..  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 20 May 86 13:16:12 EDT Received: from A.CS.CMU.EDU by SU-AI.ARPA with TCP; 20 May 86 10:12:47 PDT Date: Tue, 20 May 86 13:10 EDT From: David.Dill@A.CS.CMU.EDU (C410DD60) To: common-lisp@SU-AI.ARPA Subject: CASE using other equality predicates Message-Id: <20May86.131033.DD60@A.CS.CMU.EDU> While the proposed change might be useful for other reasons, there are a variety of other solutions to this particular problem. The most obvious is to call the reader to read the user commands with *package* bound to the commandpackage package (either explicitly or using IN-PACKAGE), so that the user commands are interned in the same place as the code. What I do when I want to be extra careful is put all the commands in a completely separate package with NO other symbols, export the commands from that package, explicitly qualify all the commands when I use them in code (in this example, in the case clauses), and read the symbols typed by the user into the special command name package.  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 20 May 86 11:29:47 EDT Received: from UCBVAX.Berkeley.EDU by SU-AI.ARPA with TCP; 20 May 86 08:25:12 PDT Received: by ucbvax.Berkeley.EDU (5.51/1.13) id AA03497; Tue, 20 May 86 08:25:15 PDT Received: by dim (2.0/5.17) id AA00779; Tue, 20 May 86 08:25:15 pdt Date: Tue, 20 May 86 08:25:15 pdt From: fateman%dim@BERKELEY.EDU (Richard Fateman) Message-Id: <8605201525.AA00779@dim> To: common-lisp@su-ai.arpa Subject: case using other equality-testing predicates If case used equalp or had a keyword :test with the usual meaning, I could use case instead of redefining it.. I include the explanation below for those who might choose to try to satisfy my perceived need by another programming construct.. In an application I had hoped to put in a package, I used a construction analogous to (in-package 'commandpackage) ..... (case com ;; com is a command, an atom read in by Lisp reader (p ) ((1 first) ) (cos ) ... etc) Now when you read in the atom p, it is not the same as the item in the case table, which is commandpackage::p. Exporting and then shadowing-importing p, first, cos, .. is not a good idea, (in general), but specifically because the symbols first, cos, etc would cover up the functions of the same name. What it seems I need is another macro in the case-family that tests using equalp rather than eql, so I can use strings.. e.g. (string-case (string com) ("p" ) (("1" "first") ) ... etc..  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 20 May 86 03:27:28 EDT Received: from MIT-REAGAN.ARPA by SU-AI.ARPA with TCP; 20 May 86 00:22:33 PDT Received: from MACH.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 32715; Tue 20-May-86 03:23:37-EDT Date: Tue, 20 May 86 03:21 EDT From: Christopher Fry Subject: coercion of symbols to strings To: fateman@dali.berkeley.edu, common-lisp@SU-AI.ARPA In-Reply-To: <8605162240.AA27077@dali.berkeley.edu> Message-ID: <860520032159.3.CFRY@MACH.AI.MIT.EDU> To convert a symbol to a string one apparently must use the string function. That is, (coerce 'x 'string) is illegal. But (string 'x) ==> "X" . Why not allow the former as a synonym for the latter? Coersion is a powerful, easy to remember concept. I think it should be extended as much as possible. The above is reasonable, as are: (coerce #\a 'string) => "a" (coerce 123 'string) => "123" (coerce #\a 'integer) => (char-code #\a) ;this is mentioned as explicitly not provided CLtL p. 52. It appears that the only reason is that no one could decide on using char-code or char-int for the conversion so they chose not to do it at all. This reasoning is odd. Pick the most frequently used way, document it, and permit it. Same argument for coercion of numeric types. Further out extensions might be: (coerce #'foo 'compiled-function) => returns a compiled function object we can decide whether or not it should update foo's definition. (coerce hash-table-1 'list) => makes an list of the values in the hash table. You can find out their keys via sxhash. We might also want to convert hash tables to simple-vectors, and visa-versa. [key on printed representation ?] (coerce pathname-1 'string) (coerce string-1 'pathname) (coerce bit-vector-1 'integer) consider the bit vector to be a straight binary representation of a non-negative integer. This is like converting between #*101 and #b101 . (coerce structure-instance-1 'list) Coersion between streams and strings sounds useful. This mechanism could be used to make a string from a file, for example, or do the reverse. Undoubtedly there are other coersions which would make sense. Being implementors, we can think of hairy cases where semantics will be ambiguous for most of the above suggestions. But typical cases are, by definition, the cases usually used. The awkward cases can be documented. Users would save a lot of manual searching if coerce was extended.  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 19 May 86 20:50:25 EDT Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 19 May 86 17:43:39 PDT Received: ID ; Mon 19 May 86 20:44:18-EDT Date: Mon, 19 May 1986 20:44 EDT Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: Guy Steele Cc: common-lisp@SU-AI.ARPA, fateman@DALI.BERKELEY.EDU Subject: coercion of symbols to strings In-reply-to: Msg of 19 May 1986 12:20-EDT from Guy Steele Now that the dust has settled a bit, I would not object to generalizing coerce to handle some of the additional cases that people imagine it ought to handle. -- Scott  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 19 May 86 12:26:29 EDT Received: from GODOT.THINK.COM by SU-AI.ARPA with TCP; 19 May 86 09:18:41 PDT Received: from katherine by Godot.Think.Com via CHAOS; Mon, 19 May 86 12:19:47 edt Date: Mon, 19 May 86 12:20 EDT From: Guy Steele Subject: coercion of symbols to strings To: fateman@dali.berkeley.edu, common-lisp@SU-AI.ARPA Cc: gls@THINK-AQUINAS.ARPA In-Reply-To: <8605162240.AA27077@dali.berkeley.edu> Message-Id: <860519122046.1.GLS@THINK-KATHERINE.ARPA> Date: Fri, 16 May 86 15:40:10 PDT From: fateman@dali.berkeley.edu (Richard Fateman) To convert a symbol to a string one apparently must use the string function. That is, (coerce 'x 'string) is illegal. But (string 'x) ==> "X" . Why not allow the former as a synonym for the latter? Research shows that the Common Lisp archives up to a couple of months ago contains 18 messages that mention COERCE. None explicitly addresses this iccue, but the general tone of the messages is one of conservatism. I now remember that this issue was tied up with the design of the sequence functions. There was real resistance to letting symbols be treated as general sequences, and so the general decision was made that string-specific functions would accept symbols, but general sequence functions would not. COERCE was limited to performing, for the most part, sequence coercions and numerical coercions. (As for the latter, there was an explicit decision not to let COERCE translate between numbers and characters.)  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 18 May 86 15:49:49 EDT Received: from CS.UCL.AC.UK by SU-AI.ARPA with TCP; 18 May 86 09:24:17 PDT Received: from aiva.edinburgh.ac.uk by 44d.Cs.Ucl.AC.UK via Janet with NIFTP id a012141; 18 May 86 17:18 BST From: Jeff Dalton Date: Sun, 18 May 86 17:17:59 -0100 Message-Id: <26803.8605181617@aiva.ed.ac.uk> To: common-lisp@su-ai.arpa Subject: coercion from X to string Date: Fri, 16 May 86 15:40:10 PDT From: Richard Fateman Subject: coercion of symbols to strings To convert a symbol to a string one apparently must use the string function. That is, (coerce 'x 'string) is illegal. But (string 'x) ==> "X" . Why not allow the former as a synonym for the latter? Not only that, (coerce #\a 'string) is an error; you have to use (string #\a). But for some reason, the powers of 'string' and 'coerce' are reversed for sequences: 'string' applied to a sequence of characters gives an error, typically saying the sequence can't be coerced to a string, but 'coerce' will in fact coerce it. All of this is mentioned in the book (p. 304), but I found it quite hard to keep it straight at first and had to constantly refer back to the book. -- Jeff  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 17 May 86 20:34:13 EDT Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 17 May 86 17:24:16 PDT Received: ID ; Sat 17 May 86 20:25:20-EDT Date: Sat, 17 May 1986 20:25 EDT Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: common-lisp@SU-AI.ARPA Subject: Keyword extensions to Compile In reply to Yuasa: I agree that it is desirable to allow implementations to add their own keyword arguments to Compile. It's too bad that we put the Definition argument in as an optional. Given that it is not used much, it would be better for it to be a keyword. But we probably should not change this in an incompatible way now, so your suggestion that we allow NIL to mean the same thing as not supplying a definition argument is the best solution, and we might want to make this explicit in the specification next time around. However, I think it is legal for you to extend your implementation in this way as the language is currently defined. It certainly is an error to supply NIL as the definition argument, since that could not be a legal definition, so you can define this error case to do something more useful. -- Scott  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 17 May 86 15:28:41 EDT Received: from [192.10.41.45] by SU-AI.ARPA with TCP; 17 May 86 12:18:33 PDT Received: from FIREBIRD.SCRC.Symbolics.COM by ALLEGHENY.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 17045; Fri 16-May-86 10:27:09-EDT Date: Fri, 16 May 86 10:22 EDT From: David C. Plummer Subject: adjusting displaced arrays To: NGALL@G.BBN.COM, common-lisp@SU-AI.ARPA In-Reply-To: <[G.BBN.COM]15-May-86 19:26:22.NGALL> Message-ID: <860516102218.8.DCP@FIREBIRD.SCRC.Symbolics.COM> Date: 15 May 1986 19:26-EDT From: NGALL@G.BBN.COM Nit picking. (DEFUN AREF (ORIGINAL-ARRAY &REST SUBSCRIPTS) (LABELS ((FOO (ARRAY INDEX) It would be a tad clearer if FOO were called 1D-AREF (MULTIPLE-VALUE-BIND (NEW-ARRAY OFFSET) (DISPLACED-ARRAY-P ARRAY) (IF (NULL NEW-ARRAY) (ROW-MAJOR-AREF ARRAY INDEX) ROW-MAJOR-AREF isn't a CL primitive. Our system calls is SYS:%1D-AREF. It's not clear you need to call it row-major-aref either, as the row-major part of the computation is dealt with below. (MULTIPLE-VALUE-CALL #'FOO You don't need multiple-value-call; FOO takes exactly two arguments. NEW-ARRAY (+ INDEX OFFSET))))) (FOO ORIGINAL-ARRAY (APPLY #'ARRAY-ROW-MAJOR-INDEX ORIGINAL-ARRAY SUBSCRIPTS)))) I think this is a reasonable extension, but I think it also must warn users that since arrays are adjustable, and indirect chain can be changed, and therefore, the target of repeated calls to DISPLACED-ARRAY-P should not be cached.  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 17 May 86 15:12:06 EDT Received: from SU-SHASTA.ARPA by SU-AI.ARPA with TCP; 17 May 86 12:00:25 PDT Received: by su-shasta.arpa; Sat, 17 May 86 12:00:30 PDT Received: by ntt.junet (4.12/4.7JC-7) CHAOS with CHAOS-MAIL id AA16933; Sat, 17 May 86 14:41:37 jst From: yuasa@kurims.kurims.kyoto-u.junet Received: by ntt.junet (4.12/4.7JC-7) CHAOS with CHAOS-MAIL id AA16885; Sat, 17 May 86 14:39:17 jst Received: by kurims.kyoto-u.junet (2.0/4.7) id AA00392; Sat, 17 May 86 13:33:34+0900 Date: Sat, 17 May 86 13:33:34+0900 Message-Id: <8605170433.AA00392@kurims.kyoto-u.junet> To: common-lisp@su-ai.arpa I would like to add some keyword parameters to COMPILE in our Common Lisp system, so that the user can control its behavior in an implementation-dependent way. However, the specification of COMPILE in CLtL prevents me from doing this. CLtL says: compile &optional [Function] If is supplied, it *should* be a lambda-expression, ... If it is not supplied, then should be a symbol ... The problem arises when the user does not want to specify , but does want to specify and implementation-dependent keyword parameters, since there clearly is no way to do this. There seem to be two solutions for this problem. A. Let be a keyword parameter as in the case of :OUTPUT-FILE parameter to COMPILE-FILE. B. Allow COMPILE to accept NIL (or anything other than a lambda-expression) as the value of , and let COMPILE work as though no was supplied. That is, change the description of COMPILE as: If is supplied and is non-NIL, it *should* be ... ... If it is not supplied or if it is NIL, then should be a symbol ... B seems more reasonable than A, but A is also acceptable, since, in my experience, the user seldom wants to supply actually. -- Taiichi  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 16 May 86 18:51:19 EDT Received: from DALI.Berkeley.EDU by SU-AI.ARPA with TCP; 16 May 86 15:39:05 PDT Received: by dali.berkeley.edu (5.51/1.11) id AA27077; Fri, 16 May 86 15:40:10 PDT Date: Fri, 16 May 86 15:40:10 PDT From: fateman@dali.berkeley.edu (Richard Fateman) Message-Id: <8605162240.AA27077@dali.berkeley.edu> To: common-lisp@su-ai.arpa Subject: coercion of symbols to strings To convert a symbol to a string one apparently must use the string function. That is, (coerce 'x 'string) is illegal. But (string 'x) ==> "X" . Why not allow the former as a synonym for the latter?  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 15 May 86 23:13:59 EDT Received: from BBNG.ARPA by SU-AI.ARPA with TCP; 15 May 86 19:59:29 PDT Date: 15 May 1986 23:01-EDT Sender: NGALL@G.BBN.COM Subject: Is justification random? From: NGALL@G.BBN.COM To: common-lisp@SU-AI.ARPA Message-ID: <[G.BBN.COM]15-May-86 23:01:44.NGALL> I wanted to use format to lay out some column headers like this: | xxx | xxx | xxx | ... | yyy | yyy | yyy | ... I assumed that the ~<...~> format directives would fit the bill. When I tried it on VaxLisp, I discovered that their FORMAT randomizes the dispersion of whitespace (their code actually calls a random number generator). Their rationale is that doing so will prevent whitespace from clumping on the left if ~<...~> were used to put out a paragraph of text. The Symbolics CL does not randomize, it inserts spaces from left to right. I guess their rationale (really mine) is that it makes column header layout work right (a much more common use of ~<...~>). CLtL is ambiguous. It merely says "the spacing is evenly divided between the text segments" (pg. 404) Here is a brief test case: (dotimes (i 10) (format t "~&~3:")) On the Vax, the x is not in the same column each time. On the SCL it is. I think the behavior of ~<...~> should be standardized and I vote against randomization. -- Nick  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 15 May 86 19:43:38 EDT Received: from BBNG.ARPA by SU-AI.ARPA with TCP; 15 May 86 16:24:10 PDT Date: 15 May 1986 19:26-EDT Sender: NGALL@G.BBN.COM Subject: adjusting displaced arrays From: NGALL@G.BBN.COM To: common-lisp@SU-AI.ARPA Message-ID: <[G.BBN.COM]15-May-86 19:26:22.NGALL> The following appears in Guy's list of `clarifications': (*) 293 ...Add a function DISPLACED-ARRAY-P, which takes an array and returns NIL and 0 if it is not displaced or the array displaced to and the displaced-index-offset if it is displaced. These allow certain code efficiencies, and also allow array displacement to be explained in terms of Lisp primitives: (DEFUN AREF (ORIGINAL-ARRAY &REST SUBSCRIPTS) (LABELS ((FOO (ARRAY INDEX) (MULTIPLE-VALUE-BIND (NEW-ARRAY OFFSET) (DISPLACED-ARRAY-P ARRAY) (IF (NULL NEW-ARRAY) (ROW-MAJOR-AREF ARRAY INDEX) (MULTIPLE-VALUE-CALL #'FOO NEW-ARRAY (+ INDEX OFFSET))))) (FOO ORIGINAL-ARRAY (APPLY #'ARRAY-ROW-MAJOR-INDEX ORIGINAL-ARRAY SUBSCRIPTS)))) As a bow to efficiency, note the fact that if array A is displaced to B with offset M, and B is displaced to C with offset N, and B is not adjustable, then DISPLACED-ARRAY-P of A might return either array B with offset M or array C with offset (+ M N). This generalizes to chains of non-adjustable arrays. ---------- I would like to add an additional (and I think stronger) argument for DISPLACED-ARRAY-P. Someone in our group had the following type of problem: Given a very long string (representing, say, a long report), he wanted to be able to displace a char. string of length N (call it N-char-string) (where 1 <= N <= 80) to the beginning of the very-long-string, do some parsing of the N-char-string, and then ADJUST the N-char-string to start where it had previously ended and to have a new length. In other words, he wanted to slide this variable length window over the very-long-string. Without DISPLACED-ARRAY-P, he is forced to wrap a structure around the displaced-array to record the original array the current offset, even though the displaced array structure already contains this info! I would suggest one minor change to DISPLACED-ARRAY-P, in the case that it returns NIL, I suggest that it should return only that (and not return the 0). The zero provides no information and does not seem to be of any use. ---------- (*) 297 Here are the interactions of ADJUST-ARRAY with displacement. Suppose we are adjusting array A, which is perhaps displaced to B before adjustment and perhaps to C after adjustment. (1) Not displaced before or after. The dimensions of A are altered, and the contents rearranged as appropriate. Additional elements of A are taken from the :initial-element. The use of :initial-contents causes all old contents to be discarded. (2) Not displaced before, but displaced afterwards to C. As already specified, none of the original contents of A appears in A afterwards, but rather the contents of C without any rearrangement of C. (3) Displaced beforehand to B, and afterward to C. As in case (2), no contents of B appear in A afterward. If :DISPLACED-INDEX-OFFSET is not specified in this case, it defaults to zero; the old offset (into B) is not retained. (4) Displaced beforehand to B, but not displaced afterward. A gets a new "data region", and contents of B are copied into it as appropriate to maintain the existing old contents; additional elements of A are taken from the :initial-element. However, the use of :initial-contents causes all old contents to be discarded. ---------- In case (3), what if (eq B C)? (this would be the case in the sliding window above). Saying that "no contents of B appear in A afterward" is not true. -- Nick  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 15 May 86 19:19:22 EDT Received: from UTAH-CS.ARPA by SU-AI.ARPA with TCP; 15 May 86 15:55:08 PDT Received: by utah-cs.ARPA (5.31/4.40.2) id AA23739; Thu, 15 May 86 16:56:56 MDT Date: Thu, 15 May 86 16:56:56 MDT From: shebs@utah-cs.arpa (Stanley Shebs) Message-Id: <8605152256.AA23739@utah-cs.ARPA> To: common-lisp@su-ai.arpa Subject: PCLS Available This is to announce the availability of the Portable Common Lisp Subset (PCLS), a Common Lisp subset developed at the University of Utah which runs in Portable Standard Lisp (PSL). PCLS is a large subset which implements about 550 of the 620+ Common Lisp functions. It lacks lexical closures, ratios, and complex numbers. Streams and characters are actually small integers, some of the special forms are missing, and a number of functions (such as FORMAT) lack many of the more esoteric options. PCLS does include a fully working package system, multiple values, lambda keywords, lexical scoping, and most data types (including hash tables, arrays, structures, pathnames, and random states). The PCLS compiler is the PSL compiler which produces very efficient code, augmented by a frontend that does a number of optimizations specific to Common Lisp. Gabriel benchmarks and others show that PCLS programs can be made to run as fast as their PSL counterparts - almost all uses of lambda keywords are optimized away, and a type declaration/inference optimizer replaces many function calls with efficient PSL equivalents. PCLS has been used at Utah and elsewhere for about 6 months, and a number of programs have been ported both to and from PCLS and other Common Lisps. PCLS is being distributed along with an updated version of PSL (3.2a). We require that you sign a site license agreement. The distribution fee is $250 US for nonprofit institutions, plus a $750 license fee for corporations. Full sources to both PSL and PCLS are included along with documentation on the internals and externals of the system. At present, we are distributing PCLS for 4.2/4.3 BSD Vax Un*x and for Vax VMS. Releases for Apollo and Sun are anticipated soon, and versions for other PSL implementations are likely. If interested, send your USnail address to: Loretta Cruse Computer Science Department, 3160 MEB University of Utah Salt Lake City UT 84112 cruse@utah-20.ARPA {seismo, ihnp4, decvax}!utah-cs!cruse.UUCP Technical questions about PCLS, flames about absence of closures, etc may be directed to shebs@utah-cs.ARPA, loosemore@utah-20.ARPA, or kessler@utah-cs.ARPA.  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 14 May 86 21:56:02 EDT Received: from HPLABS.ARPA by SU-AI.ARPA with TCP; 14 May 86 18:45:08 PDT Received: by hplabs.ARPA ; Wed, 14 May 86 18:45:12 pdt Date: Wed, 14 May 86 18:45:12 pdt From: hpfclp!diamant@hplabs.ARPA To: common-lisp@su-ai.ARPA Subject: re: rebinding of *evalhook* From: SANDRA Our toploop uses the ordinary eval function, just like everybody else. Once you setq *evalhook* from the toploop, therefore, the hook function gets called every time you type anything in. What's more, because of the rebinding, it's impossible to setq *evalhook* back to NIL so that the hook function doesn't get called anymore. This is quite correct. It is impossible to reset the value of *evalhook* from inside the hook function. Do other implementations do anything special to avoid this situation? We (at HP) have a command available always (called "Abort") which places the user back in the default toploop, which, among other things, turns off the eval hook function. For example, inside a break loop, it is possible either to quit (which essentially takes you one level out), or abort to top level. After abort has been executed, the value of *evalhook* will again be nil.  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 14 May 86 13:58:51 EDT Received: from UTAH-20.ARPA by SU-AI.ARPA with TCP; 14 May 86 10:09:33 PDT Date: Wed 14 May 86 11:10:23-MDT From: SANDRA Subject: rebinding of *evalhook* To: common-lisp@SU-AI.ARPA Message-ID: <12206660792.25.LOOSEMORE@UTAH-20.ARPA> Comment: Remailed at SU-AI after delay caused by mailing list error. A PCLS user has pointed out that it is basically impossible to setq *evalhook* from the toploop. The manual (p. 322) clearly states that "both *evalhook* and *applyhook* are rebound to the value nil around the invocation of the hook function", so this is how we've implemented eval. Our toploop uses the ordinary eval function, just like everybody else. Once you setq *evalhook* from the toploop, therefore, the hook function gets called every time you type anything in. What's more, because of the rebinding, it's impossible to setq *evalhook* back to NIL so that the hook function doesn't get called anymore. Do other implementations do anything special to avoid this situation? -Sandra -------  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 12 May 86 21:50:12 EDT Received: from [192.10.41.223] by SU-AI.ARPA with TCP; 12 May 86 17:23:04 PDT Received: from EUPHRATES.SCRC.Symbolics.COM by SAPSUCKER.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 18315; Mon 12-May-86 20:20:28 EDT Date: Mon, 12 May 86 20:20 EDT From: David A. Moon Subject: Re: First Class environments in CL ?? To: NGALL@G.BBN.COM cc: beckerle@MIT-XX.ARPA, common-lisp@SU-AI.ARPA In-Reply-To: <[G.BBN.COM]12-May-86 18:57:23.NGALL> Message-ID: <860512202002.2.MOON@EUPHRATES.SCRC.Symbolics.COM> Your ideas about what applyhook could be used for are interesting, but not what it was historically put in for. It was put in to make it possible for a program that steps through execution of an interpreted program to get control after all the arguments have been evaluated and before the function receives control. A hook for the "fvaluation" of the function in the car of the form would be useful, perhaps, but Common Lisp doesn't have one now. It would be better to add a third hook for this than to incompatibly change the meaning of applyhook. Note that the fvaluation of the function has to happen -before- the arguments are evaluated, because that's how EVAL finds out that it's dealing with a macro or a special form. I would be the first to admit that this stuff could benefit from clarification.  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 12 May 86 20:11:17 EDT Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 12 May 86 16:59:41 PDT Received: ID ; Mon 12 May 86 20:00:32-EDT Date: Mon, 12 May 1986 20:00 EDT Message-ID: From: Rob MacLachlan To: Common-Lisp@SU-AI.ARPA Subject: Void In-reply-to: Msg of 12 May 1986 06:28-EDT from Kent M Pitman Let be rephrase the VOID proposal in terms of continuations, hopefully making the semantics seem less arbitrary: 1] THE and the result type for a function type are statements about the type of continuations with which it is legal to call a function or evaluate an expression. 2] VALUES and the proposed VOID are only meaningful in this context because they can only apply to continuations, not the values of cells. 3] Stating that a continuation must be VOID is stating that the continuation cannot reference its arguments *in any way*. Excepting the funny cases of MULTIPLE-VALUE-PROG1 and UNWIND-PROTECT, these statements are comparable to the previous definition, but a bit stronger. The cases where I said that VOID should be erroneous are those cases where it is obvious that the continuation for the expression is not VOID. Rob  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 12 May 86 19:07:18 EDT Received: from BBNG.ARPA by SU-AI.ARPA with TCP; 12 May 86 15:56:50 PDT Date: 12 May 1986 18:57-EDT Sender: NGALL@G.BBN.COM Subject: Re: First Class environments in CL ?? From: NGALL@G.BBN.COM To: Moon@SCRC-STONY-BROOK.ARPA Cc: beckerle@XX.LCS.MIT.EDU, common-lisp@SU-AI.ARPA Message-ID: <[G.BBN.COM]12-May-86 18:57:23.NGALL> In-Reply-To: <860512151354.6.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Mon, 12 May 86 15:13 EDT From: David A. Moon To: beckerle@MIT-XX.ARPA Subject: First Class environments in CL ?? I believe the env argument to the function applyhook to be a typographical error, since there is no meaningful way that that argument could be used. Our implementation ignores it. I have not investigated, but I expect every other implementation ignores it too. Hmmm. Once again the meaning of FUNCTION and the semantics of function application is ambiguous in CLtL. In the definition of *applyhook* on pg. 322, it says "When a function is about to be applied to a list of arguments, no attempt is made to apply the function. Instead, the hook function is invoked and is passed the function and the list of arguments as its first and second arguments." The naive reader (me) would assume that given a function call such as (foo 1. 2. 3.) that the apply hook function's first arg would be FOO and second arg would be (1. 2. 3.). Such is not the case in VaxLisp (nor in SCL). Instead, the first arg is FOO's function definition! I admit that it is not clear from the above definition whether or not "function" refers to "function name" (i.e., a symbol or a lambda expression) or function definition (i.e., the thing associated with the function name). But I do think that it is strongly implied that the function name should be used, for the following reasons: An implementation that passed the function definition to the apply hook function would not be able to handle (xyttdf 1.2. 3.) where XYTTDF has no function definition. Instead of passing XYTTDF to the apply hook function so that it can figure out what to do, it will signal an error. I thought one of the uses of applyhook was to be able to experiment with different ways of defining functions, for example, funcalling an undefined function returns a continuation to be evaled later when it has a definition. Also, giving the apply hook function the function definition of a function makes it useless as a way of overriding the functional interpretation of a symbol, which I would assume is one of the primary purposes of the apply hook. All the apply hook function sees is some functional object (that may well be implementation dependent). It can't find out the name that was actually used in the function call. Finally, I believe the whole point of the ENV arg to APPLYHOOK is to handle (flet ((frab (a b) (+ a b))) (frab 1 2)) so that the apply hook function is given three args: FRAB, (1 2), and an env that contains a definition for FRAB. Without requiring that the first arg to the apply hook function be the function name, then the ENV arg to APPLYHOOK IS meaningless. Rather than being a typo., I think it is more likely that the first arg to APPLYHOOK may be the NAME of a function like FRAB above. I think the apply hook stuff is in need of clarification in one direction or the other, and I vote that it deal with function names as opposed to function definitions. -- Nick  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 12 May 86 15:29:55 EDT Received: from [192.10.41.223] by SU-AI.ARPA with TCP; 12 May 86 12:16:56 PDT Received: from EUPHRATES.SCRC.Symbolics.COM by SAPSUCKER.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 18106; Mon 12-May-86 15:13:59 EDT Date: Mon, 12 May 86 15:13 EDT From: David A. Moon Subject: First Class environments in CL ?? To: beckerle@MIT-XX.ARPA cc: common-lisp@SU-AI.ARPA In-Reply-To: The message of 12 May 86 14:01 EDT from mike@ALLEGHENY.SCRC.Symbolics.COM Message-ID: <860512151354.6.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Mon, 12 May 86 13:01 EST From: mike@a Can you obtain a first-class handle on a lexical environment in CL??? Common Lisp only supports lexical closures as first-class objects. Each implementation has (perhaps too much) freedom to implement the environments embedded inside those closures however it wants. The motivation for this freedom is to permit efficient compilation. We should do one of the following: (1) eliminate the 'env' optional to evalhook/applyhook. (2) provide a selector which extracts the current lexical environment and returns it so that it can be stored as any first class object. I prefer (1) since it makes compilation much easier and more effective. Compiled code does not set off *evalhook* and *applyhook*, so this 'env' facility does not affect compilation in any way. I believe the env argument to the function applyhook to be a typographical error, since there is no meaningful way that that argument could be used. Our implementation ignores it. I have not investigated, but I expect every other implementation ignores it too. It would be impossible for the evalhook function to operate correctly without an env argument, since a form is only meaningful for evaluation in some particular lexical environment. The book doesn't explain this very well, but it should be apparent after studying the example on page 323. The only valid value for the env argument to the evalhook function is, I believe, a value that was received as the second argument to a function that is the value of *evalhook*, or nil. Finally, to avoid confusion, In CLtL, there is a discussion of the &environment keyword for macros. It specifically says that this environment may not be complete, and should only be used with "macroexpand" and is constructed by "macrolet". This is clearly not the environment intended for use with evalhook. I agree with you. It is permitted, but not required, to be the same environment. In our implementation, it is the same environment in some contexts and is something else in other contexts.  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 12 May 86 14:39:26 EDT Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 12 May 86 11:27:41 PDT Received: ID ; Mon 12 May 86 14:28:06-EDT Date: Mon, 12 May 1986 14:27 EDT Message-ID: From: Rob MacLachlan To: Kent M Pitman Cc: Common-Lisp@SU-AI.ARPA Subject: Void In-reply-to: Msg of 12 May 1986 06:28-EDT from Kent M Pitman Date: Monday, 12 May 1986 06:28-EDT From: Kent M Pitman Re: Void Date: Sun, 11 May 1986 21:06 EDT From: Rob MacLachlan The only places where a void expression may be legal are: 1] Any place where the value is immediately discarded: PROGN, etc. 2] Any place in a function that can return multiple values. In addition to tail-recursive positions, this includes the protected form of UNWIND-PROTECT and the values form for MULTIPLE-VALUE-PROG1 when these forms are in such a multiple-value position. I'm sorry, but I find this completely ridiculous. Many valid programs can be written which use `void' values in ways other than this without being ill-formed. Note that in either case, a void value may be illegal because the result was declared to be of some other type: (proclaim '(function frob-foo (foo) void)) (defun frob-foo (foo) ...) (proclaim '(function make-foo ((member t nil)) foo)) (defun make-foo (frob-p) (let ((foo (cons-a-foo))) (if frob-p (frob-foo foo) foo))) Suppose that FROB-FOO puts the FOO on the heap somewhere. Then suppose that I have a function, CREATE-FOO, which is the only call of MAKE-FOO and is defined as: (DEFUN CREATE-FOO (STASH-P) (COND (PUT-IN-HEAP (MAKE-FOO T) (VALUES NIL NIL)) (T (VALUES (MAKE-FOO NIL) T)))) There's nothing ill-formed about the collection of programs which include my program and yours. Not true. I declared that MAKE-FOO *always* returns a FOO. VOID is not a FOO, ever. The programming problem you're worried about is a common one, but the technique you're proposing for fixing it is just not practical. This situation comes up in legitimate code (especially when macros are involved) all the time. I am aware of the macro problem that you describe, but I am not convinced that it is significant. Any macro in Common Lisp which has an implicit PROGN cannot get this effect by saving the value in a variable, since the body might want to return multiple values. A macro which knows nothing about its body must place it in a multiple-value context. This is why there is a relation between multiple-value contexts and legal VOID expressions. Consider the following common situation: I have a macro MYBLOCK which binds the variable * to the value of the previous computation at the same level. For example: (DEFMACRO MYBLOCK (&BODY FORMS) `(LET ((* *)) ,@(MAPCAR #'(LAMBDA (FORM) `(SETQ * ,FORM)) FORMS))) In my reality, this macro assumes that each body form is not VOID. I don't really see all these bad implications of adding a VOID type. If you think that declaring things VOID crimps your style, then don't do it. If the compiler barfs because you are using the value of something that some other bozo declared VOID, then you can always say (PROGN xxx NIL). Rob  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 12 May 86 14:16:58 EDT Received: from MIT-LIVE-OAK.ARPA by SU-AI.ARPA with TCP; 12 May 86 11:00:34 PDT Received: from GOLD-HILL-ACORN.DialNet.Symbolics.COM by MIT-LIVE-OAK.ARPA via DIAL with SMTP id 1286; 12 May 86 14:01:08-EDT Received: from BOSTON.Gold-Hill.DialNet.Symbolics.COM by ACORN.Gold-Hill.DialNet.Symbolics.COM via CHAOS with CHAOS-MAIL id 20741; Mon 12-May-86 14:10:50-EDT Date: Mon, 12 May 86 13:01 EST From: mike@a To: common-lisp@su-ai.arpa Subject: First Class environments in CL ?? Reply-to: beckerle@xx.lcs.mit.edu Can you obtain a first-class handle on a lexical environment in CL??? I do not see any operations which return an "environment" anywhere in CLtL; however, the following discussion is on page 323 with respect to the evalhook and applyhook feature. "Furthermore, the 'env' argument is used as the lexical environment for the operation; 'env' defaults to the null environment." I see no way to use this other than with the default environment. Furthermore, if there were "environments" available, then I'd expect to be able to pass them to EVAL, APPLY, etc. We should do one of the following: (1) eliminate the 'env' optional to evalhook/applyhook. (2) provide a selector which extracts the current lexical environment and returns it so that it can be stored as any first class object. I prefer (1) since it makes compilation much easier and more effective. Finally, to avoid confusion, In CLtL, there is a discussion of the &environment keyword for macros. It specifically says that this environment may not be complete, and should only be used with "macroexpand" and is constructed by "macrolet". This is clearly not the environment intended for use with evalhook. ...mike beckerle  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 12 May 86 09:31:20 EDT Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 12 May 86 06:21:44 PDT Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 485357; Mon 12-May-86 06:27:47-EDT Date: Mon, 12 May 86 06:28 EDT From: Kent M Pitman Subject: Void To: RAM@C.CS.CMU.EDU cc: Common-Lisp@SU-AI.ARPA References: Message-ID: <860512062855.6.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> Date: Sun, 11 May 1986 21:06 EDT From: Rob MacLachlan Well, I freely admit that the big hole in my proposal is defining what it means to "use" a VOID value. I think that the best approach is to be extremely facist. I've outlined reasonable design principles which suggest this is a bogus thing do do. I hardly find your idea of ignoring those principles and just arbitrarily pulling a semantics out of the air to be very convincing. The only places where a void expression may be legal are: 1] Any place where the value is immediately discarded: PROGN, etc. 2] Any place in a function that can return multiple values. In addition to tail-recursive positions, this includes the protected form of UNWIND-PROTECT and the values form for MULTIPLE-VALUE-PROG1 when these forms are in such a multiple-value position. I'm sorry, but I find this completely ridiculous. Many valid programs can be written which use `void' values in ways other than this without being ill-formed. Note that in either case, a void value may be illegal because the result was declared to be of some other type: (proclaim '(function frob-foo (foo) void)) (defun frob-foo (foo) ...) (proclaim '(function make-foo ((member t nil)) foo)) (defun make-foo (frob-p) (let ((foo (cons-a-foo))) (if frob-p (frob-foo foo) foo))) Suppose that FROB-FOO puts the FOO on the heap somewhere. Then suppose that I have a function, CREATE-FOO, which is the only call of MAKE-FOO and is defined as: (DEFUN CREATE-FOO (STASH-P) (COND (PUT-IN-HEAP (MAKE-FOO T) (VALUES NIL NIL)) (T (VALUES (MAKE-FOO NIL) T)))) There's nothing ill-formed about the collection of programs which include my program and yours. In this classic "oops, I forgot to return the value" example, the compiler is quite justified in giving a warning, since one branch of the IF can never be legally executed. The function MAKE-FOO itself is not erroneous, but the compiler could replace the call to FROB-FOO with code that just signals an error. When this happens, I would like my compiler to tell me that something may be wrong, since there almost certainly is. The programming problem you're worried about is a common one, but the technique you're proposing for fixing it is just not practical. This situation comes up in legitimate code (especially when macros are involved) all the time. Consider the following common situation: I have a macro MYBLOCK which binds the variable * to the value of the previous computation at the same level. For example: (DEFMACRO MYBLOCK (&BODY FORMS) `(LET ((* *)) ,@(MAPCAR #'(LAMBDA (FORM) `(SETQ * ,FORM)) FORMS))) This lets me do: (MYBLOCK 3 (+ * 5) (- * 2)) ==> 6 But what if the function FOO has a void return value? It's completely reasonable to do: (MYBLOCK (FOO) (BAR) (PRINT *)) because * gets assigned but never used. The way the program can represent the information necessary to decide whether a value is used correctly are endless. You really cannot mechanically detect them.  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 11 May 86 21:47:06 EDT Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 11 May 86 18:38:10 PDT Received: ID ; Sun 11 May 86 21:39:15-EDT Date: Sun, 11 May 1986 21:39 EDT Message-ID: From: Rob MacLachlan To: common-lisp@SU-AI.ARPA Subject: New type specifier? On second thought, it isn't true that the call to FROB-FOO would be replaced with a call to error, since it is possible that FROB-FOO may not return. This doesn't reduce the usefulness of getting a warning, though. Lisp's dynamic typing makes it very difficult to prove anything erroneous, but there are many code sequences which are unreasonable. Compiler warnings are for flagging code which is probably not what you want. If you write lots of declarations, you give the compiler a better idea of what you want, so it can give better warnings. VOID declarations give a useful increment in specifying what I want. Judging from various discussions of (VALUES), I think that there is demand for a way to declare "procedures" in Common Lisp. Rob  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 11 May 86 21:15:22 EDT Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 11 May 86 18:05:48 PDT Received: ID ; Sun 11 May 86 21:06:24-EDT Date: Sun, 11 May 1986 21:06 EDT Message-ID: From: Rob MacLachlan To: Kent M Pitman Cc: Common-Lisp@SU-AI.ARPA Subject: New type specifier? In-reply-to: Msg of 11 May 1986 19:06-EDT from Kent M Pitman Well, I freely admit that the big hole in my proposal is defining what it means to "use" a VOID value. I think that the best approach is to be extremely facist. The only places where a void expression may be legal are: 1] Any place where the value is immediately discarded: PROGN, etc. 2] Any place in a function that can return multiple values. In addition to tail-recursive positions, this includes the protected form of UNWIND-PROTECT and the values form for MULTIPLE-VALUE-PROG1 when these forms are in such a multiple-value position. Note that in either case, a void value may be illegal because the result was declared to be of some other type: (proclaim '(function frob-foo (foo) void)) (defun frob-foo (foo) ...) (proclaim '(function make-foo ((member t nil)) foo)) (defun make-foo (frob-p) (let ((foo (cons-a-foo))) (if frob-p (frob-foo foo) foo))) In this classic "oops, I forgot to return the value" example, the compiler is quite justified in giving a warning, since one branch of the IF can never be legally executed. The function MAKE-FOO itself is not erroneous, but the compiler could replace the call to FROB-FOO with code that just signals an error. When this happens, I would like my compiler to tell me that something may be wrong, since there almost certainly is. Rob  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 11 May 86 19:16:10 EDT Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 11 May 86 16:06:32 PDT Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 485265; Sun 11-May-86 19:04:41-EDT Date: Sun, 11 May 86 19:06 EDT From: Kent M Pitman Subject: New type specifier? To: RAM@C.CS.CMU.EDU cc: Common-Lisp@SU-AI.ARPA In-Reply-To: Message-ID: <860511190615.9.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> Unfortunately, even if you had a VOID type specifier, it would not be reasonable for the compiler to warn about uses of VOID items. It is only a semantic error if you rely on the particular value that returns, not if you use a value that happens to come back. For example, consider: (DEFUN FOO (X) (IF X (VALUES T 3) (VALUES NIL (THE VOID NIL)))) As I understand it, you're suggesting that this would declare that the data-flow from the alternative branch of the IF to have a void second value. The problem is that a program such as: (DEFUN BAR (X) (DECLARE (SPECIAL *FOO*)) (MULTIPLE-VALUE-BIND (A B) (FOO X) (SETQ *FOO* (CONS A B)) (IF (CAR *FOO*) (CDR *FOO*) NIL))) is using B legitimately because it is never accessing the second value unless the first value is true. The problem is that whether a value is "used" is relative, not absolute. Consider even the program: (DEFUN BAR (X) (MULTIPLE-VALUE-BIND (A B) (FOO X) (PRINT B) A)) Surely, you might say, if anything "uses" B, this does. But what if I tell you now that BAR is not exported and is called internally only from BAZ, which is defined by: (DEFUN BAZ (X &AUX BAR-OUTPUT-IS-VALID) (LET ((BAR-OUTPUT-AS-A-STRING (WITH-OUTPUT-TO-STRING (*STANDARD-OUTPUT*) (SETQ BAR-OUTPUT-IS-VALID (BAR X))))) (IF BAR-OUTPUT-IS-VALID BAR-OUTPUT-AS-A-STRING NIL))) The effect of having used the void value has been contained and is in the global context cannot be said to have been used. I claim the output of the function BAZ is meaningful in all situations. In the final analysis, I think the kind of error you seek to detect is inherently undetectable for fairly deep-seated philosophical reasons. I would be amazingly irrated if compilers became pretentious enough to claim that understood my intent in a situation like this, since I think it's probably possible to construct a proof that they cannot. Your VOID specifier does have the slight advantage that it provides useful self-documentation from me to myself about my intent in the program. It might even prove useful to programs -writing- programs. It's just that in the general case of reading programs, it's of little or no use in proving that a program is incorrect because of issues related to this idea of the global vs local relevance of a computation.  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 11 May 86 17:09:10 EDT Received: from [192.10.41.223] by SU-AI.ARPA with TCP; 11 May 86 13:56:26 PDT Received: from WHITE-BIRD.SCRC.Symbolics.COM by SAPSUCKER.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 17749; Sun 11-May-86 16:53:31 EDT Date: Sun, 11 May 86 16:51 EDT From: Robert W. Kerns Subject: The first note on kanji, sent to junet site in Jan 1986 and some reactions in japan To: Masayuki Ida cc: common-lisp@SU-AI.ARPA, ida%UTOKYO-RELAY.CSNET@CSNET-RELAY.ARPA, mathis@USC-ISIF.ARPA In-Reply-To: <8605100330.AA08572@tansei.utyo.junet> Supersedes: <860511165045.5.RWK@WHITE-BIRD.SCRC.Symbolics.COM> Message-ID: <860511165153.6.RWK@WHITE-BIRD.SCRC.Symbolics.COM> [Please note: the character system I refer to as our "current" implementation is new, and will be released to customers this fall as part of Release 7.0 of our software.] Date: Sat, 10 May 86 12:30:08+0900 From: Masayuki Ida I am preparing a ducument on Kanji standard in japan for Common Lisp. The concepts in it is quite natural to Common Lisp, I think. But, I want to have opinions and advices from many persons as possible. The key ideas are follows; 1) include japanese-char data type and normalized-string data type. Japanese-char type is a class for JIS 6226, and is a subtype of string-char. (physically, JIS 6226 char occupies 2 byte each.) Make it a subtype of EXTENDED-STRING-CHAR instead. Or just CHARACTER. Because the character codes are two bytes long, many systems may wish to make their normal strings only hold "ordinary" characters (i.e. what are currently called string-char). What you are proposing here is an incompatible change to STRING-CHAR, and I don't believe it is really necessary. In our implementation, Japanese characters are SUBTYPEP of CHARACTER. STRING-CHAR's are characters that can be stored in ANY string. We have special strings that can hold ANY character (the type is, appropriately enough, STRING) Normalized-string type is a subtype of the string type, and its component characters are of japanese-char type characters. This is an extremely poor choice of names for this type. Besides, you're getting into specifying the implementation. NOT-normalized string may contain japanese-char and other char randomly. What about implementations which have no wish to make their usual strings huge to support Japanese? Since Japanese characters take two bytes, we're talking a minimum of three bytes per character. Implementations with a lot of documentation strings will find the cost of that documentation suddenly tripled. (Actually, you can do it with less, because Kanji does not actually need the full 2^16 codes. The rest of the languages (except things like Chinese) are small enough to fit in at the end, or the start, or wherever the implementation chooses. (Remember, CL never specifies the character codes for individual characters, just their meaning). 2) include string-normalize, normalized-string-p, and japanese-char-p at least. I take it string-normalize takes a string and generates a more compact representation? There's nothing wrong with that, and perhaps "normalize" is the right word here. However, specifying Japanese as the single and sole type that is "normalized" to is rather ungeneral. I don't think ANY string type should be named NORMALIZED, nor do I think there should be a NORMALIZED-STRING-P predicate that determines whether a string is of some specific type. Instead, NORMALIZED-STRING-P should say whether STRING-NORMALIZE will, in fact, do anything, or if it will just return its argument. About JAPANESE-CHAR-P: I am glad to see you have not tried to do this with the CHAR-FONT field, but rather included it into the CHAR-CODE. This is indeed the right way to support different character-set's, as opposed to character-styles (i.e. bold, italic, etc). CLtL did not make it clear what CHAR-FONT is intended for, but if you use CHAR-FONT, then you get characters which appear to be the "same" character, even though they are in different languages. We eventually decided that CHAR-FONT was so ill-specified as to be useless, and do not use it for anything, and CHAR-FONT-LIMIT is 1 in our system. 3) char-code-limit should be greater than 16 bit to hold japanese-char character. char-bits-limit has not always meaningfull for japanese-char. In our implementation, char-code-limit is 2^16, and it works fine. Of course, we have provision for extending things beyond char-code-limit as needed, but we have never needed that. One other thing: Please do not specify any standard for the values of CHAR-CODE belonging to specific characters. Doing so only invites conflicts between standards for different languages. For example, Hebrew and Arabic might easily choose the same range of values, because the standards groups weren't talking to each other, or didn't even know about each other. Or a standards group might choose a standard which would make life very hard for an implementation. Instead, specify that if these are to be written to a file, that it be done with a stream gotten by (OPEN PATHNAME :ELEMENT-TYPE 'EXTENDED-STRING-CHAR :DIRECTION :OUTPUT) or (OPEN PATHNAME :ELEMENT-TYPE 'CHARACTER :DIRECTION :OUTPUT) Then standardize on interchange and communication formats for files. For example, if there is an ISO standard for storing characters of different character-sets, you might write (OPEN PATHNAME :ELEMENT-TYPE 'EXTENDED-STRING-CHAR :DIRECTION :OUTPUT :FILE-DATA-FORMAT :ISO) This leaves implementations with their own file format free to work with that format by default. For example, our file format allows us to do a number of things which will not be part of any character standard, such as include diagrams, marks, etc. We would not want to abandon our file format wholesale. 4) length function invocation with japanese-char strings must return its apparent length, not the storage length. Indeed! CL has no concept of storage length. The length function must return the number of characters, which is the number of objects that can be accessed with ELT. I'm trying to reinforce what you're saying here slightly. An implementation that simply stores Japanese as pairs of characters is incorrect, even if LENGTH returns the right number, if ELT, AREF, etc. don't give back the entire Japanese character. I think the above idea will cope with various implementations including the usual english-text-only systems. If you have an idea to discuss, please let me know Thank you. Masayuki ida junet: ida@ccut.u-tokyo.junet Csnet/arpanet: ida%utokyo-relay.csnet@csnet-relay --------------------- follwoing is the reaction to the above message -------- 1) Prof. Kigen Hasebe told me that there is a kind of standard for AT&T UNIX. 2) Dr. Morisaki of NTT told me that MIT LCS had an experience to cope with japanese characters on their NIL in 1984 already. I don't know about NIL. I do know that we have been supporting Japanese characters for at least that long, and our experiences with it are part of the motivation for the design of our current character system. Several Common-lisp(-like) implementations told me that they have facility to cope with japanese characters with much the same idea I described above. At Jeida, the working group for japanese character handling in Common Lisp started at the last april.  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 10 May 86 23:03:18 EDT Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 10 May 86 19:54:41 PDT Received: ID ; Sat 10 May 86 22:55:48-EDT Date: Sat, 10 May 1986 22:55 EDT Message-ID: From: Rob MacLachlan To: common-lisp@SU-AI.ARPA Subject: New type specifier? I propose adding a new type specifier, VOID. It is subject to the same constraints as the VALUES specifier, and is used in a similar way. (THE VOID xxx) indicates that it is an error to use the value(s) of xxx, but the actual expression might evaluate to any number of values of any type. This can also be used for (FUNCTION foo (...) VOID), to indicate that the function has no meaningful value. Note that this is not the same as the NIL specifier (not to be confused with NULL). (THE NIL xxx) is always erroneous, since no expression can evaluate an object of type NIL. It has also been suggested that (VALUES) be used when no useful value is returned. The problem with this is that it is not erroneous for code to expect values when there are none, so the compiler cannot give an error message. Rob  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 10 May 86 12:37:47 EDT Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 10 May 86 09:28:44 PDT Received: from utokyo-relay by csnet-relay.csnet id ab07051; 10 May 86 12:27 EDT Received: by u-tokyo.junet (4.12/4.9J-1[JUNET-CSNET]) id AA22322; Sat, 10 May 86 12:47:21+0900 Received: by tansei.utyo.junet (4.12/4.9J) id AA08572; Sat, 10 May 86 12:30:08+0900 Date: Sat, 10 May 86 12:30:08+0900 From: Masayuki Ida Message-Id: <8605100330.AA08572@tansei.utyo.junet> To: common-lisp@SU-AI.ARPA, ida@UTOKYO-RELAY.CSNET, mathis@USC-ISIF.ARPA Subject: The first note on kanji, sent to junet site in Jan 1986 and some reactions in japan I am preparing a ducument on Kanji standard in japan for Common Lisp. The concepts in it is quite natural to Common Lisp, I think. But, I want to have opinions and advices from many persons as possible. The key ideas are follows; 1) include japanese-char data type and normalized-string data type. Japanese-char type is a class for JIS 6226, and is a subtype of string-char. (physically, JIS 6226 char occupies 2 byte each.) Normalized-string type is a subtype of the string type, and its component characters are of japanese-char type characters. NOT-normalized string may contain japanese-char and other char randomly. 2) include string-normalize, normalized-string-p, and japanese-char-p at least. 3) char-code-limit should be greater than 16 bit to hold japanese-char character. char-bits-limit has not always meaningfull for japanese-char. 4) length function invocation with japanese-char strings must return its apparent length, not the storage length. I think the above idea will cope with various implementations including the usual english-text-only systems. If you have an idea to discuss, please let me know Thank you. Masayuki ida junet: ida@ccut.u-tokyo.junet Csnet/arpanet: ida%utokyo-relay.csnet@csnet-relay --------------------- follwoing is the reaction to the above message -------- 1) Prof. Kigen Hasebe told me that there is a kind of standard for AT&T UNIX. 2) Dr. Morisaki of NTT told me that MIT LCS had an experience to cope with japanese characters on their NIL in 1984 already. Several Common-lisp(-like) implementations told me that they have facility to cope with japanese characters with much the same idea I described above. At Jeida, the working group for japanese character handling in Common Lisp started at the last april.  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 9 May 86 14:51:13 EDT Received: from HUDSON.DEC.COM by SU-AI.ARPA with TCP; 9 May 86 11:36:35 PDT Date: 9 May 86 14:39:00 EST From: "BACH::ROBBINS" Subject: RE: format ~nC To: "common-lisp" Reply-To: "BACH::ROBBINS" ---------------------Reply to mail dated 9-MAY-1986 12:58--------------------- >Is there a good reason ~C doesn't take an arg? I just naively tried > (format t "~&~VC~VC~%" count-1 char-1 count-2 char-2) >and was rewarded with one occurance of each character each time; the >counts had been thrown away. ~~ takes an arg. The FORMAT directives that output a constant character (~~, ~%, ~&, and ~|) take a count prefix parameter and use up no arguments. The ~C directive is more like ~A, ~S, ~G etc., these all output some representation of the next argument in the call to FORMAT and none of them take a count parameter. Is that a good reason? Hmm... -- Rich ------  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 9 May 86 12:43:57 EDT Received: from [192.10.41.223] by SU-AI.ARPA with TCP; 9 May 86 09:28:13 PDT Received: from FIREBIRD.SCRC.Symbolics.COM by SAPSUCKER.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 17318; Fri 9-May-86 12:25:38 EDT Date: Fri, 9 May 86 12:24 EDT From: David C. Plummer Subject: format ~nC To: common-lisp@SU-AI.ARPA Message-ID: <860509122416.6.DCP@FIREBIRD.SCRC.Symbolics.COM> Is there a good reason ~C doesn't take an arg? I just naively tried (format t "~&~VC~VC~%" count-1 char-1 count-2 char-2) and was rewarded with one occurance of each character each time; the counts had been thrown away. ~~ takes an arg.  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 7 May 86 20:52:31 EDT Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 7 May 86 17:41:16 PDT Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 482294; Wed 7-May-86 14:20:05-EDT Date: Wed, 7 May 86 14:20 EDT From: Kent M Pitman Subject: [JAR@MC.LCS.MIT.EDU: Problems with packages] To: Common-Lisp@SU-AI.ARPA Message-ID: <860507142048.9.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> Return-path: <@MIT-MC.ARPA:JAR@MC.LCS.MIT.EDU> Received: from MC.LCS.MIT.EDU (MIT-MC.ARPA) by SCRC-STONY-BROOK.ARPA via INTERNET with SMTP id 481541; 6 May 86 16:22:38-EDT Date: Tue, 6 May 86 16:25:07 EDT From: Jonathan A Rees Subject: Problems with packages To: KMP@SCRC-STONY-BROOK.ARPA In-reply-to: Msg of Thu 1 May 86 22:53 EDT from Kent M Pitman Message-ID: <[MC.LCS.MIT.EDU].905392.860506.JAR> Funny, I've been running into these same problems myself recently. Shadowing just doesn't work very well. One interesting glitch I cam across is that it's desirable to be able to say "use all symbols from package FOO except for X" but there's no way to say so. It doesn't work to shadow X if you want to inherit X from some other package. It doesn't work to enumerate the symbols you want from FOO because it might be very large (e.g. FOO = LISP). Is there any 3600 feature which lets one do this? (:USE ((FOO :EXCEPT (BAR BAZ)) FOO2)) In T and MIT Scheme shadowing isn't a problem because it works retroactively. Jonathan.  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 7 May 86 17:06:43 EDT Received: from XEROX.COM by SU-AI.ARPA with TCP; 7 May 86 13:54:46 PDT Received: from Cabernet.ms by ArpaGateway.ms ; 07 MAY 86 13:53:52 PDT Date: 7 May 86 13:53 PDT From: Bobrow.pa@Xerox.COM Subject: Re: A proposal In-reply-to: MURRAY@umass-cs.CSNET's message of Mon, 5 May 86 14:47 EST To: MURRAY%umass-cs.CSNet@CSNet-Relay.ARPA cc: common-lisp@su-ai.ARPA Message-ID: <860507-135352-1849@Xerox> I agree that a DEFSYSTEM facility is useful. However, what its specs should be are unclear. We just built an experimental system** using objects that also supports incremental changes as well as version control. Should facilities like these be included? It seems that we are far from having a good handle on what is needed. This is to support Dan Weinreb's contention that the system construction tool business is still very volatile. (** A copy of a short paper on defintion groups is available on request. Send Snail-mail address.)  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 7 May 86 07:36:36 EDT Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 7 May 86 04:28:59 PDT Date: Wed, 7 May 86 07:30:45 EDT From: "George J. Carrette" Subject: infix madness To: common-lisp@SU-AI.ARPA Message-ID: <[MC.LCS.MIT.EDU].905947.860507.GJC> And if you really want to go for it I can supply a version of the Famous CGOL lisp-front-end parser. It also defines a #$ readmacro, but likes to work mostly by creating a readtable such that all non-whitespace characters do an unread-char and then call CGOL-PARSE. CGOL source files then have an (eval-when (eval compile) (setq *readtable* *cgol-readtable*)) in the front, so that they really prefer that LOAD is defined as (DEFUN LOAD (...) (LET ((*READTABLE* *READTABLE*)) .....))  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 7 May 86 02:49:15 EDT Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 6 May 86 23:41:27 PDT Received: ID ; Wed 7 May 86 02:42:22-EDT Date: Wed, 7 May 1986 02:42 EDT Message-ID: From: Rob MacLachlan To: common-lisp@SU-AI.ARPA Subject: Re: Lexical references in DEFMACRO (let ((unique-id "foo")) (defun make-foo () (list unique-id () () ())) (defmacro foo-p (x) `(and (listp ,x) (eq (car ,x) ',unique-id)))) Although this macro may be obvious, it is non-obvious how it could be implemented, supposing that it was legal. Given that macros are expanded at compile time, our only choice would be to compute the lexical environment of the macro at compile time, i.e. eval an arbitrary amount of code surrounding the DEFMACRO. If we really believe that macros are just like functions, then we would conclude that the macro and the function must close over the *same* variable, despite that fact that the variable must first exist in the compiler. The only way that this could possibly work would be for the compiler to create the closure variable at compile time, and then arrange for it to be shared between all of the lisps which load the resulting binary; this is a neat trick. I think that the real problem is that macros and functions are fundamentally different; simplistic attempts to draw paralells between them will just result in confusion. Rob  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 6 May 86 21:05:57 EDT Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 6 May 86 17:50:26 PDT Date: Tue, 6 May 86 20:52:09 EDT From: "Glenn S. Burke" Subject: loop where? To: JVC@SU-SCORE.ARPA cc: common-lisp@SU-AI.ARPA Message-ID: <[MC.LCS.MIT.EDU].905569.860506.GSB> I recently (less than a week ago) converted the source of LOOP used in NIL (shared source with Zetalisp, but a bit more developed) to Common Lisp, and have it running in DEC VAXLISP at Palladian. When it has been demonstrated to be fairly stable, I will make it available, probably by anonymous FTP off of MC. This is not intended to comprise any "development" of LOOP. It is a conversion only, and is intended to be the official Common-Lisp version of NIL/Zetalisp LOOP. It is of course missing the iteration paths for hash tables and packages, since they are rather implementation dependent.  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 6 May 86 15:16:08 EDT Received: from [192.10.41.223] by SU-AI.ARPA with TCP; 6 May 86 12:02:31 PDT Received: from EUPHRATES.SCRC.Symbolics.COM by SAPSUCKER.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 15762; Tue 6-May-86 14:59:41 EDT Date: Tue, 6 May 86 14:58 EDT From: David A. Moon Subject: Re: Lexical references in DEFMACRO To: Gregor.pa@Xerox.COM cc: Common-Lisp@SU-AI.ARPA In-Reply-To: <860506-104653-4711@Xerox> Message-ID: <860506145832.9.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: 6 May 86 10:46 PDT From: Gregor.pa@Xerox.COM I thought the obvious defmacro was: (defmacro foo-p (x) `(and (listp ,x) (eq (car ,x) ',unique-id)))) which is the lexically binding of unique-id I had in mind. I will try not to be so terse next time. I see. I think I had a momentary brain failure in which I thought Common Lisp non-top-level DEFUN was intended to work like Scheme DEFINE. I think what's underlying all of this is that the provisions for non-top-level definitions in current Common Lisp are ill-thought-out and probably inconsistent. I don't recall the discussions predating the publication of the manual spending a lot of time on these issues. Getting this resolved, and a language definition that we can all agree is useful, makes sense, and is implementable, is something the new standardization and language cleanup process that is starting is going to have to attack. Your example is one more example of a problem with the current half attempt at non-top-level definitions that's going to have to be considered.  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 6 May 86 14:22:00 EDT Received: from USC-ISIF.ARPA by SU-AI.ARPA with TCP; 6 May 86 11:02:54 PDT Date: 6 May 1986 11:04-PDT Sender: MATHIS@USC-ISIF.ARPA Subject: X3J13 Approval From: MATHIS@USC-ISIF.ARPA To: Common-Lisp@SU-AI.ARPA Message-ID: <[USC-ISIF.ARPA] 6-May-86 11:04:44.MATHIS> X3J13, the Technical Committee for the standardization of Common Lisp, has been approved. The first meeting will be September 23 and 24, 1986, at CBEMA in Washington, DC. I am serving as convenor of that first meeting. I am also planning to have further information available at the Lisp Conference in Boston, August 4-6, 1986. I have sent another message (with the subject "Lisp Standardization") to everyone who has expressed interest in the standards process. I will continue to send general information to the whole Common Lisp Community, but most of the stuff about X3J13 will go to this other more specialized list. If you (or your company) are interested in X3J13, please let me know. I can also be reached at 9712 Ceralene Drive, Fairfax, Virginia 22032-1704 or (703)425-5923. -- Bob Mathis  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 6 May 86 13:59:54 EDT Received: from XEROX.COM by SU-AI.ARPA with TCP; 6 May 86 10:49:12 PDT Received: from Semillon.ms by ArpaGateway.ms ; 06 MAY 86 10:46:53 PDT Date: 6 May 86 10:46 PDT From: Gregor.pa@Xerox.COM Subject: Re: Lexical references in DEFMACRO In-reply-to: David A. Moon 's message of Mon, 5 May 86 20:04 EDT To: Moon@SCRC-STONY-BROOK.arpa cc: Common-Lisp@SU-AI.ARPA Message-ID: <860506-104653-4711@Xerox> I thought the obvious defmacro was: (defmacro foo-p (x) `(and (listp ,x) (eq (car ,x) ',unique-id)))) which is the lexically binding of unique-id I had in mind. I will try not to be so terse next time.  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 6 May 86 10:51:21 EDT Received: from HPLABS.ARPA by SU-AI.ARPA with TCP; 6 May 86 07:40:25 PDT Received: from hplabsc by hplabs.ARPA ; Tue, 6 May 86 07:40:31 pdt Received: by hplabsc ; Tue, 6 May 86 07:40:41 pdt Date: Tue, 6 May 86 07:40:41 pdt From: Jim Kempf Message-Id: <8605061440.AA03317@hplabsc> To: MURRAY%umass-cs.csnet@CSNET-RELAY.ARPA, common-lisp@su-ai.ARPA Subject: Re: A proposal My experience with using Common Lisp for software engineering is that it is less than ideal. As Kelly outlined in his note, the package system and provide-require are just insufficient for keeping track of dependencies in a large system. I think a properly structured DEFSYSTEM construct would certainly be of benefit; however, whether that should be part of the environment or part of the language is another question. Perhaps we need a standard environment (like U*nix) as well? In addition to the problem with large scale system building, the lack of seperation between a function interface and its implementation (such as occurs in Mesa and Ada) makes modification of software components in a large system difficult. The DECLARE facility is, again, insufficient, as are most object oriented dialects. DECLARE bundles the interface and implementation into one thing (the DEFUN), while most object oriented dialects allow (potentially untyped) parameters to messages, and hence suffer from the same problem as DECLARE-DEFUN. While a construct to aid seperation of function/message interfaces and implementations would help in large scale systems building, it may hamper the use of Common Lisp as a prototyping language, unless constructed so that a smooth transition between prototyping and production were possible. Jim Kempf hplabs!kempf  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 6 May 86 10:26:14 EDT Received: from BBNG.ARPA by SU-AI.ARPA with TCP; 6 May 86 07:16:13 PDT Date: 6 May 1986 10:17-EDT Sender: NGALL@G.BBN.COM Subject: Re: Help in writing infix macro in CL. From: NGALL@G.BBN.COM To: sridhar%tekecs%tektronix.csnet@RELAY.CS.NET Cc: common-lisp@SU-AI.ARPA Message-ID: <[G.BBN.COM] 6-May-86 10:17:38.NGALL> In-Reply-To: <8605052327.AA21173@tekecs.TEK> Date: Mon, 5 May 86 16:27:46 PDT From: "S. Sridhar" To: common-lisp@su-ai.ARPA Subject: Help in writing infix macro in CL. Message-ID: <8605052327.AA21173@tekecs.TEK> Is there a way to do the following using the reader macro functions of CLtL ? I want to have a reader macro that translates (a + b) to (+ a b). How can I remember the lisp object that was read before the macro character #\+. I would appreciate some pointers. -sridhar -------------------- As Scott pointed out, there is no way in CL to access what has been read prior to the execution of a read-macro. To do what you want, you would have to redefine the read-macro for #\( to save the elements seen so far in a list that is manipulatable via a global variable. A less ambitious approach might be to use [...] around infix expressions; then you wouldn't have to worry about breaking (...). -- Nick  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 6 May 86 10:23:18 EDT Received: from [192.10.41.223] by SU-AI.ARPA with TCP; 6 May 86 07:13:31 PDT Received: from FIREBIRD.SCRC.Symbolics.COM by SAPSUCKER.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 15557; Tue 6-May-86 10:11:55 EDT Date: Tue, 6 May 86 10:09 EDT From: David C. Plummer Subject: Help in writing infix macro in CL. To: Scott E. Fahlman , S. Sridhar cc: common-lisp@SU-AI.ARPA In-Reply-To: Message-ID: <860506100944.5.DCP@FIREBIRD.SCRC.Symbolics.COM> Date: Tue, 6 May 1986 08:52 EDT From: "Scott E. Fahlman" I don't think that you can write an infix reader just by defining new character macros for #\+ and friends. This new reader needs to get at the whole expression, either because it is caled directly by your program or because it is invoked when you see that first #\(, assuming that all your top-level expressions are parenthesized. Of course, the new reader can be built using the old one, or more specialized built-in functions, to do most of the work, but it can't wait until you hit an infix operator before it gets invoked. In Zetalisp and Symbolics Common Lisp (and probably other MIT-derived LispM dialects), there is a sharp-sign macro (altmode/lozenge) that invokes the infix reader. Therefore (lozenges changed to dollar signs): (equal '#$ a+b $ '(+ a b)) => T  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 6 May 86 10:19:12 EDT Received: from [192.10.41.223] by SU-AI.ARPA with TCP; 6 May 86 07:08:48 PDT Received: from FIREBIRD.SCRC.Symbolics.COM by SAPSUCKER.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 15550; Tue 6-May-86 10:07:06 EDT Date: Tue, 6 May 86 10:05 EDT From: David C. Plummer Subject: Re: Lexical references in DEFMACRO To: David A. Moon , Common-Lisp@SU-AI.ARPA In-Reply-To: <860505200405.1.MOON@EUPHRATES.SCRC.Symbolics.COM> Message-ID: <860506100516.4.DCP@FIREBIRD.SCRC.Symbolics.COM> Date: Mon, 5 May 86 20:04 EDT From: David A. Moon Date: 5 May 86 15:25 PDT From: Gregor.pa@Xerox.COM Another problem with having the lexical environment of a defmacro'd macro be the null environment is that you can't "macroize for speed" the following perfecly reasonable coding style: (let ((unique-id "foo")) (defun make-foo () (list unique-id () () ())) (defun foo-p (x) (and (listp x) (eq (car x) unique-id)))) Specifically, you couldn't turn the defun of foo-p into the seemingly obvious defmacro. I think if you actually write out the seemingly obvious defmacro, you will see that it's not so: (defmacro foo-p (x) `(and (listp ,x) (eq (car ,x) unique-id)))) which does not reference unique-id as a variable from the body of the macro, only from the expansion of the macro. ',unique-id Of course the inline proclamation was made to order for this. I wonder if it was intended to work for things not at top level. This can of worms should not be dealt with piecemeal. This can of worms includes storing FOOs in binary files. The string which is unique-id, by Gregor's intended semantics, must be the same in all bin files that have their roots with the make-foo above, and the loader somehow has to know all this. It might work in a single file, but to do multiple files starts getting into the realm of global unique ids and databases and so on.  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 6 May 86 10:08:07 EDT Received: from [192.10.41.223] by SU-AI.ARPA with TCP; 6 May 86 06:58:18 PDT Received: from CHICOPEE.SCRC.Symbolics.COM by SAPSUCKER.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 15541; Tue 6-May-86 09:56:43 EDT Date: Tue, 6 May 86 10:01 EDT From: Daniel L. Weinreb Subject: Why we should not try to add programming environments to the Common Lisp standard To: MURRAY%umass-cs.csnet@CSNET-RELAY.ARPA, common-lisp@SU-AI.ARPA In-Reply-To: The message of 5 May 86 15:47 EDT from MURRAY%umass-cs.csnet@CSNET-RELAY.ARPA Message-ID: <860506100109.0.DLW@CHICOPEE.SCRC.Symbolics.COM> Date: Mon, 5 May 86 14:47 EST From: MURRAY%umass-cs.csnet@CSNET-RELAY.ARPA While portability is the major concern, let us not forget that another benefit of standardization is that programmers can move to another project, company, or system and not have to learn an vastly different enviornment. This is an argument in favor of developing a standardized programming environment. One reason that Common Lisp came into existence was a widespread feeling that a group of us pretty much agreed on what Lisp is, or should be, and that it was time to consolidate and standardize on what we already understood. Language features that we felt were still under active development, and were not yet well understood, stable, and agreed upon, were omitted. I believe that there is general agreement that most programming environment facilities are still in the state of active development; there is not a widespread concensus about how they should work. Therefore, adoping them as part of the actual Common Lisp standard is not appropriate yet. However, this is one of the reasons for the concept of the "yellow pages" library of shared, portable programs. Such facilities can be placed into this library and made widely available. If experimentation, time, and experience lead to a broad concensus, then it's time to consider promoting the program to "white pages" status. I presume that the steering and/or technical committees will produce an official policy statement about this at some point. Now, I think Zetalisp's defsystem, while very powerful, it's fairly complicated, has horrible syntax, and isn't quite the right thing. By the way, the Software Products department of Symbolics agrees with this. Release 7 will have a completely redesigned facility that is simpler, has greatly improved syntax, and is closer to the right thing. It's called the "system construction tool", and was mentioned in the Release 7 announcement a couple of weeks ago. The reason I bring this up is to show that things are still in a state of active development, and too volatile to be cast in the concrete of the Common Lisp specification.  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 6 May 86 09:20:32 EDT Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 6 May 86 05:55:42 PDT Received: ID ; Tue 6 May 86 08:53:04-EDT Date: Tue, 6 May 1986 08:52 EDT Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: "S. Sridhar" Cc: common-lisp@SU-AI.ARPA Subject: Help in writing infix macro in CL. In-reply-to: Msg of 5 May 1986 19:27-EDT from S. Sridhar I don't think that you can write an infix reader just by defining new character macros for #\+ and friends. This new reader needs to get at the whole expression, either because it is caled directly by your program or because it is invoked when you see that first #\(, assuming that all your top-level expressions are parenthesized. Of course, the new reader can be built using the old one, or more specialized built-in functions, to do most of the work, but it can't wait until you hit an infix operator before it gets invoked. -- Scott  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 6 May 86 01:41:22 EDT Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 5 May 86 22:31:44 PDT Received: from umass-cs by csnet-relay.csnet id bc22579; 6 May 86 1:16 EDT Date: Mon, 5 May 86 14:47 EST From: MURRAY%umass-cs.csnet@CSNET-RELAY.ARPA To: common-lisp@su-ai.ARPA Subject: A proposal A major goal of Common-Lisp standardization is to make it possible to be able to write a system, and have that system run on any machine that runs common-lisp. Given this goal, The language should provide an easy way of packaging (no pun intended) up a system, such that it can be easily moved onto another machine. The package system provides a nice way to seperate out your system from anything existing on a machine, but I think most people would agree it is a pain when it comes to development. This is because a system of any size is generally broken into many files, and while developing, you don't necessarily load them all in, and in the "proper" order, before working on the some part of the system. Now many might say that dealing with this is an "enviornment issue", or sloppy programmer practice, such that you or your machines software should provide you with ways to deal with these problems. While portability is the major concern, let us not forget that another benefit of standardization is that programmers can move to another project, company, or system and not have to learn an vastly different enviornment. Another problem that arises with multiple files, is compiling them, such that some files needed to be loading before others, to get macros and functions defined. It appears that common-lisp is more oriented to dealing with single files, rather than a system with a group of them. The MODULES stuff is a pretty weak attempt, and seems more oriented towards a user of systems, rather than the systems themselves. Therefore, I think that we should seriously consider including something like the DEFSYSTEM of Zetalisp. Now, I think Zetalisp's defsystem, while very powerful, it's fairly complicated, has horrible syntax, and isn't quite the right thing. It think the defsystem we want should include file interface information that is currently dispersed through all the files of the system. The proposal is to have something like defsystem that would define the files, compile and load dependancies, packages to be created, the import and exporting of symbols within those packages. A file can indicate which part of the system it is. Using the Defsystem information, the file itself wouldn't need to include it all. Thus a file could have something like: (In-System "Robot" "Motor-Control") Which would indicate that this is module Motor-Control of the Robot system. Using the system information, your would know which package the file should be in. If the system information wasn't loaded, it would load it in, creating the package with all it's importing, exporting, shawdowing, etc. If files needed to be loaded before this one, it could either load them in, or maybe ask you if you want it to, or at least Warn you that they haven't been loaded. This way, while developing you wouldn't lose. This avoids having to have all that information redundantly specified in all the files. Most programmer do all of this by hand, so why not let the system doit. A software system could also provide other "Enviornment" tools, like letting you know what needs to be recompiled, making it easy to add imports and exports of symbols, nice display of file/module dependancies, etc. As far as compiling, again the system information could be consulted on an individual file basis. As with Zetalisp defsystem, you only need to say something like (MAKE-SYSTEM "ROBOT" :COMPILE) to have it do all the files, with all their dependancies. When you went to move the system to another machine, all the information would be in the defsystem, so if you need to change the name of packages, you would only need to do it there. It would also be a good place to put #+ReadTime conditionals, so you would only include files/modules for particular software systems. I may be wrong, but it seems most groups doing development have something similiar that they use already. I would be more than willing to write up a concrete proposal, and code up a portable version of it for testing, if the community is going to take it seriously. Kelly Murray University of Massachusetts  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 6 May 86 01:12:13 EDT Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 5 May 86 21:59:43 PDT Received: from tektronix by csnet-relay.csnet id ab22348; 6 May 86 0:45 EDT Received: by tektronix.TEK (5.31/6.10) id AA12247; Mon, 5 May 86 16:35:36 PDT Received: by tekecs.TEK (5.16/) id AA21173; Mon, 5 May 86 16:27:48 PDT From: "S. Sridhar" Message-Id: <8605052327.AA21173@tekecs.TEK> Date: Mon, 5 May 86 16:27:46 PDT To: common-lisp@su-ai.ARPA Subject: Help in writing infix macro in CL. Is there a way to do the following using the reader macro functions of CLtL ? I want to have a reader macro that translates (a + b) to (+ a b). How can I remember the lisp object that was read before the macro character #\+. I would appreciate some pointers. -sridhar  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 5 May 86 20:17:32 EDT Received: from [192.10.41.223] by SU-AI.ARPA with TCP; 5 May 86 17:06:38 PDT Received: from EUPHRATES.SCRC.Symbolics.COM by SAPSUCKER.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 15353; Mon 5-May-86 20:04:32 EDT Date: Mon, 5 May 86 20:04 EDT From: David A. Moon Subject: Re: Lexical references in DEFMACRO To: Common-Lisp@SU-AI.ARPA In-Reply-To: <860505-160136-4065@Xerox> Message-ID: <860505200405.1.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: 5 May 86 15:25 PDT From: Gregor.pa@Xerox.COM Another problem with having the lexical environment of a defmacro'd macro be the null environment is that you can't "macroize for speed" the following perfecly reasonable coding style: (let ((unique-id "foo")) (defun make-foo () (list unique-id () () ())) (defun foo-p (x) (and (listp x) (eq (car x) unique-id)))) Specifically, you couldn't turn the defun of foo-p into the seemingly obvious defmacro. I think if you actually write out the seemingly obvious defmacro, you will see that it's not so: (defmacro foo-p (x) `(and (listp ,x) (eq (car ,x) unique-id)))) which does not reference unique-id as a variable from the body of the macro, only from the expansion of the macro. Of course the inline proclamation was made to order for this. I wonder if it was intended to work for things not at top level. This can of worms should not be dealt with piecemeal.  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 5 May 86 19:11:33 EDT Received: from XEROX.COM by SU-AI.ARPA with TCP; 5 May 86 16:00:33 PDT Received: from Cabernet.ms by ArpaGateway.ms ; 05 MAY 86 16:01:36 PDT Date: 5 May 86 15:25 PDT From: Gregor.pa@Xerox.COM Subject: Re: Lexical references in DEFMACRO In-reply-to: edsel!sunvalleymall!eb@su-navajo.arpa (Eric Benson)'s message of Fri, 2 May 86 16:27:58 pdt To: edsel!sunvalleymall!eb@su-navajo.arpa cc: Common-Lisp@su-ai.arpa Message-ID: <860505-160136-4065@Xerox> Another problem with having the lexical environment of a defmacro'd macro be the null environment is that you can't "macroize for speed" the following perfecly reasonable coding style: (let ((unique-id "foo")) (defun make-foo () (list unique-id () () ())) (defun foo-p (x) (and (listp x) (eq (car x) unique-id)))) Specifically, you couldn't turn the defun of foo-p into the seemingly obvious defmacro.  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 5 May 86 19:09:21 EDT Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 5 May 86 15:55:29 PDT Date: Mon 5 May 86 15:55:55-PDT From: Janet Coursey Subject: loop where? To: common-lisp@SU-AI.ARPA Message-ID: <12204364397.39.JVC@SU-SCORE.ARPA> I need a public domain LOOP macro or FOR or general iterative construct to help translate zetalisp and interlisp to commonlisp. I was told that before I (recently) began reading this list such a request was made and answered. Please send me mail if you kept a copy or know from whence I can ftp or otherwise obtain it. Sincerely, Janet Coursey jvc@su-score -------  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 3 May 86 22:41:15 EDT Received: from XEROX.COM by SU-AI.ARPA with TCP; 3 May 86 19:33:22 PDT Received: from Burger.ms by ArpaGateway.ms ; 03 MAY 86 19:34:23 PDT Sender: "Larry_Masinter.PARC"@Xerox.COM Date: 3 May 86 19:33:20 PDT (Saturday) Subject: Re: MACROLET & FUNCTION From: Masinter.PARC@Xerox.COM To: yuasa@kurims.kurims.kyoto-u.junet.Arpa cc: Common-Lisp@SU-AI.Arpa In-Reply-to: yuasa%kurims.kurims.kyoto-u.junet:ARPA:Xerox's message of 2 May 86 05:49 Message-ID: <860503-193423-3089@Xerox> there's another possibility, which is [c] (MACROLET ((FOO ...)) (FUNCTION FOO)) == (FUNCTION FOO) i.e., MACROLET redefinitions are not seen by FUNCTION, but (FUNCTION FOO) always refers to either the FLET or LABELS definition of FOO or else the global definition. (I have a definition of MACROLET which does this; I'm not willing to argue that it is better than the others, but it is at least as consistent.)  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 3 May 86 10:21:08 EDT Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 3 May 86 07:10:22 PDT Received: ID ; Sat 3 May 86 10:11:16-EDT Date: Sat, 3 May 1986 10:11 EDT Message-ID: From: Rob MacLachlan To: edsel!sunvalleymall!eb@su-navajo.arpa (Eric Benson) Cc: Common-Lisp@SU-AI.ARPA Subject: Lexical references in DEFMACRO In-reply-to: Msg of 2 May 1986 19:27-EDT from edsel!sunvalleymall!eb at su-navajo.arpa (Eric Benson) Date: Friday, 2 May 1986 19:27-EDT From: edsel!sunvalleymall!eb at su-navajo.arpa (Eric Benson) Re: Lexical references in DEFMACRO The Common Lisp definition continues to surprise me. I had not noticed that DEFMACRO is not allowed to let its body refer to any lexically visible entities outside the DEFMACRO form. On the other hand, DEFUN is specifically allowed to refer to lexically visible entities. This deserves some explanation. It seems I am allowed to do this: (LET ((SOME-DATA-STRUCTURE (MAKE-SOME-DATA-STRUCTURE))) (DEFUN SOME-FUNCTION () (DO-SOMETHING-WITH SOME-DATA-STRUCTURE))) but not this: (LET ((SOME-DATA-STRUCTURE (MAKE-SOME-DATA-STRUCTURE))) (DEFMACRO SOME-MACRO () (MAKE-A-FORM-WITH SOME-DATA-STRUCTURE))) To do what I want in the second case I must do this: (LET ((SOME-DATA-STRUCTURE (MAKE-SOME-DATA-STRUCTURE))) (SETF (MACRO-FUNCTION 'SOME-MACRO) #'(LAMBDA (FORM ENVIRONMENT (DECLARE (IGNORE FORM ENVIRONMENT)) (MAKE-A-FORM-WITH SOME-DATA-STRUCTURE))))) Furthermore, in order to implement this restriction I must introduce a new special form, such as that used in Spice Lisp, to force a form to be evaluated in the null lexical environment. Thus it is impossible to live up to the suggestion in the implementation note on p.58, that macros should not expand into implementation-dependent special forms. This is a good point which I overlooked. It looks like this special form must become a part of the language, not because users need to use it directly, but becuase some macros must expand into it. It is obvious to me why the expansion functions defined by MACROLET must have this restriction; there is no environment at macroexpansion time to which they can refer. The expansion functions created by DEFMACRO, on the other hand, are not really very different from ordinary functions created by DEFUN. There is one difference, but it is outside the scope of the Common Lisp definition. Most (i.e. all) implementations of Common Lisp cause macros defined by DEFMACRO to be available for use while compiling the file in which they are defined. This is not required by the Common Lisp definition, but is part of the Lisp tradition. This is not true, see the bottom of p146 "If the compiler encounters a DEFMACRO..." It seems pretty clear that this *must* be part of the definition, since the programmer must make sure that her macros are defined before she uses them. If you require an explicit EVAL-WHEN, then nearly every program I have ever written would have to be changed. It should be obvious that this is only possible for macro definitions which occur at "top level." For example, it would be incorrect in this example to define THIS-MACRO at compile time: (WHEN SOME-CONDITION (DEFMACRO THIS-MACRO () (EXPAND-INTO-SOMETHING))) In my previous discussion of "top level forms", I explained why I also don't agree with this. The notion of a "top level form" just doesn't belong in a lexical Lisp. Implicit compiler evaluation such as putting DEFMACRO definitions in the compiler environment should happen no matter where the form appears. Similarly, any macro definition which refers to a lexically visible entity cannot be defined at compile time, since it cannot be a "top level" form. It seems to me that you are arguing much more effectively for the null DEFMACRO environment than you are arguing against the implicit evaluation. It is clear that they are mutually exclusive. Rob  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 2 May 86 19:42:46 EDT Received: from SU-NAVAJO.ARPA by SU-AI.ARPA with TCP; 2 May 86 16:30:38 PDT Received: by su-navajo.arpa with Sendmail; Fri, 2 May 86 16:30:40 pdt Received: from sunvalleymall.edsel.uucp by edsel.uucp (2.2/SMI-2.0) id AA12915; Fri, 2 May 86 16:29:20 pdt Return-Path: Received: by sunvalleymall.edsel.uucp (2.2/SMI-2.2) id AA07703; Fri, 2 May 86 16:27:58 pdt Date: Fri, 2 May 86 16:27:58 pdt From: edsel!sunvalleymall!eb@su-navajo.arpa (Eric Benson) Message-Id: <8605022327.AA07703@sunvalleymall.edsel.uucp> To: navajo!Common-Lisp@su-ai Subject: Lexical references in DEFMACRO The Common Lisp definition continues to surprise me. I had not noticed that DEFMACRO is not allowed to let its body refer to any lexically visible entities outside the DEFMACRO form. On the other hand, DEFUN is specifically allowed to refer to lexically visible entities. This deserves some explanation. It seems I am allowed to do this: (LET ((SOME-DATA-STRUCTURE (MAKE-SOME-DATA-STRUCTURE))) (DEFUN SOME-FUNCTION () (DO-SOMETHING-WITH SOME-DATA-STRUCTURE))) but not this: (LET ((SOME-DATA-STRUCTURE (MAKE-SOME-DATA-STRUCTURE))) (DEFMACRO SOME-MACRO () (MAKE-A-FORM-WITH SOME-DATA-STRUCTURE))) To do what I want in the second case I must do this: (LET ((SOME-DATA-STRUCTURE (MAKE-SOME-DATA-STRUCTURE))) (SETF (MACRO-FUNCTION 'SOME-MACRO) #'(LAMBDA (FORM ENVIRONMENT (DECLARE (IGNORE FORM ENVIRONMENT)) (MAKE-A-FORM-WITH SOME-DATA-STRUCTURE))))) Furthermore, in order to implement this restriction I must introduce a new special form, such as that used in Spice Lisp, to force a form to be evaluated in the null lexical environment. Thus it is impossible to live up to the suggestion in the implementation note on p.58, that macros should not expand into implementation-dependent special forms. It is obvious to me why the expansion functions defined by MACROLET must have this restriction; there is no environment at macroexpansion time to which they can refer. The expansion functions created by DEFMACRO, on the other hand, are not really very different from ordinary functions created by DEFUN. There is one difference, but it is outside the scope of the Common Lisp definition. Most (i.e. all) implementations of Common Lisp cause macros defined by DEFMACRO to be available for use while compiling the file in which they are defined. This is not required by the Common Lisp definition, but is part of the Lisp tradition. It should be obvious that this is only possible for macro definitions which occur at "top level." For example, it would be incorrect in this example to define THIS-MACRO at compile time: (WHEN SOME-CONDITION (DEFMACRO THIS-MACRO () (EXPAND-INTO-SOMETHING))) Similarly, any macro definition which refers to a lexically visible entity cannot be defined at compile time, since it cannot be a "top level" form. I suggest one of the following be done in the next edition of the manual: 1. Remove the sentence in the description of DEFMACRO which disallows references to lexically visible entities. This is an incompatible change, but is unlikely to affect many programs. It is mostly an upward-compatible change. 2. Add an explanation which justifies this restriction. The explanation would have to include some language explaining how this could be implemented, since it appears to contradict the implementation note on p.58.  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 2 May 86 19:21:26 EDT Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 2 May 86 16:02:56 PDT Received: from HOME.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 478959; Fri 2-May-86 17:41:19-EDT Date: Fri, 2 May 86 17:41 EDT From: Charles Hornig Subject: Environment Query Functions. To: "BACH::GREEK" , common-lisp In-Reply-To: The message of 28 Apr 86 11:36-EDT from "BACH::GREEK" Message-ID: <860502174133.3.HORNIG@HOME.SCRC.Symbolics.COM> Date: 28 Apr 86 10:36:00 EST From: "BACH::GREEK" I think the watchword is "short and sweet" as far as the environment query functions are concerned. Here's what we do for VAX LISP. And here's what we do for Symbolics Common Lisp. LISP-IMPLEMENTATION-TYPE is "VAX LISP". "Symbolics Common Lisp" LISP-IMPLEMENTATION-VERSION is something like "V2.0". "System 271.266, TMC5-IO4-COL-MIC microcode 384" MACHINE-TYPE is the machine name, like "DEC VAX 11/780" "DEC VAXstation II". "Symbolics 3600" MACHINE-VERSION is tough to call, so we return the SID register, which uniquely identifies the CPU. Not so great. A real long string which is a list of all of the components of the system with their serial numbers. MACHINE-INSTANCE is setable by the system manager/user. The host name of the machine. SOFTWARE-TYPE is "VMS" or "ULTRIX". "Lisp Machine" SOFTWARE-VERSION is whatever the operating system says its version is. A long string which describes the loaded versions of all systems. SHORT-SITE-NAME & LONG-SITE-NAME is setable by the system manager/user. ditto  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 2 May 86 15:59:15 EDT Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 2 May 86 12:36:46 PDT Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 478730; Fri 2-May-86 14:10:47-EDT Date: Fri, 2 May 86 14:10 EDT From: Kent M Pitman Subject: Problems with packages To: GJC@MC.LCS.MIT.EDU, RAM@C.CS.CMU.EDU cc: Common-Lisp@SU-AI.ARPA, KMP@SCRC-STONY-BROOK.ARPA In-Reply-To: <[MC.LCS.MIT.EDU].901826.860502.GJC>, Your message References: <860501225353.8.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> Message-ID: <860502141057.3.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> Date: Fri, 2 May 86 07:42:12 EDT From: "George J. Carrette" Subject: Problems with packages: work arounds. If you still have the (MACSYMA-MODULE ) as the first form in every file you can do what I do for DOE-MACSYMA, (macsyma-module ) => (eval-when (eval compile load) (or (find-package "MACSYMA") (error "bad news")) ... etc ...) The issue is not finding a work-around. Obviously I know how to achieve the computational effect. The issue is that: (a) no one should put their shadowed symbols list in more than one file because it just sets them up to lose by getting the various lists out of alignment with each other. (b) everyone who uses files that do IN-PACKAGE for a complicated package like the one I'm describing should probably want to do the same workaround. One purpose of language design is to make sure that idioms get names. Another is to make it convenient to get the appropriate error checking for those who may be too lazy to write the error conditional long-hand. Why should everyone have to invent a MACSYMA-MODULE routine? Introducing an IN-EXISTING-PACKAGE primitive would be good for everyone. By the way, another potential problem with the MACSYMA-MODULE scheme you outline is that you can't be sure on what package the MACSYMA-MODULE form will be read. As such, unless you are sure MACSYMA-MODULE is defined in all possible packages, the call to IN-PACKAGE must preceed the call to MACSYMA-MODULE so that MACSYMA-MODULE will get interned in the correct package, which defeats the purpose. Yes, it's possible to make the MACSYMA-MODULE thing work, but I don't think very portably and I don't think that when it fails it will fail gracefully. Yes, it's possible to make IN-PACKAGE work, but again when it fails it is not going to fail gracefully. I think the language should provide minimal support for common situations like this where the system could and should be doing error checking. It's only -very- rarely going to be the case that the person writes IN-PACKAGE and doesn't know whether he means IN-PACKAGE or IN-EXISTING-PACKAGE. That being the case, we should allow the person to say which he means and get the benefit that should come from such clarity of expression. Date: Fri, 2 May 1986 10:16 EDT From: Rob MacLachlan Date: Thursday, 1 May 1986 22:53-EDT From: Kent M Pitman To: Common-Lisp at SU-AI.ARPA Re: Problems with packages ... What happened was that I hit a bad timing window and it tried to resolve the `FOO' package at the instant the package was created but before the special stuff (like shadowing, importing, etc.) had been done. ... Sounds like an environment issue to me :-) Linguistic issues which make it impossible to construct correct environments are within our charter. I claim this is such an issue. While I'm on the subject of packages, I have a few other gripes to air... I'm really bothered that I have to say symbols as arguments to shadow. The 3600 implementation allows me to use strings, which CL doesn't define. CL should -require- strings as arguments to this function and should not allow symbols. Giving symbols as arguments to this function forces things to get created wrong and then hopes that things will get cleaned up correctly afterward. This reduces the ability to error-check if the symbol to be shadowed had already been interned for some reason other than the call to shadow. I don't quite follow what you are saying about "things getting created wrong." If the call to shadow is read in the package which them symbols are to be shadowed in, then: 1] The symbols get created as internal symbols in the package, in which case shadow does nothing but update the shadowing symbols list. 2] The symbols were already directly present in the package, in which case both reading and shadowing do nothing but update the shadowing symbols list. 3] The symbols are inherited from somewhere, in which case the "wrong" symbol is read, but nothing is "created wrong", since the symbol already existed. It is a bit odd that SHADOW takes a list of symbols and then just uses the names, but it doesn't have any bad side-effects that I can see. I would guess that consistency was the motivation for using symbols everywhere. Using symbols also lets those of us who dislike uppercase type the names of the arguments in lowercase. I may have been a bit vague in my original exposition, so let me give a sample of a problemsome situation. Suppose you put the following in a file: (IN-PACKAGE 'FOO) (SHADOW '(CAR)) Then suppose you type Suspend (or Control-B or whatever your asynchronous interrupt is for getting a Lisp breakpoint ...) while the file is loading and you (unknowingly) end up between the IN-PACKAGE and the SHADOW. You can verify that the FOO package exists, but might not think to verify that BAR has not yet been shadowed. Suppose you type (DEFUN FOO:CAR () 3) while in the breakpoint. The problem is that FOO:CAR will resolve to LISP:CAR because the shadowing has not yet been done. This is analagous to what happened to me in the multiprocessing situation the other day. Also, when (SHADOW '(CAR)) gets done, it will not know that you had previously interned FOO:CAR (in the breakpoint) because it thinks the reason it finds FOO:CAR interned locally. Also, if the implementation caches the results of doing (INTERN inherited-symbol-name package) for faster lookup later and remembers that FOO:CAR used to resolve to LISP:CAR, it can signal an error if it later changes. If shadow takes a symbol argument, the implementation can't reliably tell that you're doing something nasty because it can't tell if the only previous use of FOO:CAR (which resolved to LISP:CAR) was the one in the call to shadow or whether there were other, more substantial, uses of LISP:CAR which you might want to be warned about. Even leaving aside issues of asynchronous interrupts, there's no guaranteeing that someone else hasn't done: (IN-PACKAGE 'FOO) and then just worked in FOO for a while before you loaded a package that did (IN-PACKAGE 'FOO) (SHADOW '(CAR)) In that case, you can't appropriately flag any prior uses of CAR because the form which calls SHADOW has basically destroyed any debugging information that might have been around.  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 2 May 86 11:21:09 EDT Received: from BBNG.ARPA by SU-AI.ARPA with TCP; 2 May 86 08:07:29 PDT Date: 2 May 1986 11:10-EDT Sender: NGALL@G.BBN.COM Subject: FUNCTION and MACROLET From: NGALL@G.BBN.COM To: Common-Lisp@SU-AI.ARPA Message-ID: <[G.BBN.COM] 2-May-86 11:10:15.NGALL> In-Reply-To: <8605030043.AA01090@kurims.kyoto-u.junet> Date: Fri, 2 May 86 17:43:51 pdt From: yuasa@kurims.kurims.kyoto-u.junet To: Common-Lisp@SU-AI.ARPA Message-ID: <8605030043.AA01090@kurims.kyoto-u.junet> Subject: FUNCTION and MACROLET To sum up, there are two possibilities: [A] (MACROLET ((FOO ...)) (FUNCTION FOO)) causes an error, and SYMBOL-FUNCTION with non-function symbol also causes an error. [B] (MACROLET ((FOO ...)) (FUNCTION FOO)) returns some totally random object which, when invoked as a function, will cause an error. SYMBOL-FUNCTION with non-function symbol also returns something not a function. CLtL supports [B]. Also Guy's proposed clarification seems to support [B]. However, [B] forces the compiler to INVENT something not a function, and to silently generate code that returns the something, although this something is totally useless. Rather, the compiler should cause an error when processing the above MACROLET form. I prefer [A]. As Rob said, the difference of [A] and [B] do not matter actually. In addition, it will be straightforward to change an already existing implementation toward [A]. (Indeed, I think I could do the change in five minutes for KYOTO!!) The above discussions (and the discussions of Bob and Nick) are based on Nick's assumption that FUNCTION with a symbol should correspond to SYMBOL-FUNCTION in sense that a symbol as a variable corresponds to SYMBOL-VALUE). Is this what most people agree with? Yes, the description of FUNCTION in CLtL says ...; see SYMBOL-FUNCTION. The reader of CLtL might see the description of SYMBOL-FUNCTION. Perhaps he would like to say "yes, I saw it... so what?" Nick's assumption is wrong here. On pg. 32 it says "The result of evaluating a FUNCTION special form will always be a function." Thus, even in the current CLtL, FUNCTION and SYMBOL-FUNCTION are not defined to behave identically in the the case of a symbol that globally names a macro or special form. Given that FUNCTION is not defined to work with symbols naming non-functions and given that MACRO-FUNCTION can be used to assign a new name to a macro, and given that we probably want it to be illegal to give a new name to a special form (I think we discussed this aspect of SYMBOL-FUNCTION once), then I agree that [A] is the best solution (assuming that "causes an error" does not mean "signal an error" but merely "is an error"). -- Nick  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 2 May 86 11:07:10 EDT Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 2 May 86 07:54:17 PDT Received: ID ; Fri 2 May 86 10:55:02-EDT Date: Fri, 2 May 1986 10:54 EDT Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: Common-Lisp@SU-AI.ARPA In reply to: yuasa at kurims.kurims.kyoto-u.junet To sum up, there are two possibilities: [A] (MACROLET ((FOO ...)) (FUNCTION FOO)) causes an error, and SYMBOL-FUNCTION with non-function symbol also causes an error. [B] (MACROLET ((FOO ...)) (FUNCTION FOO)) returns some totally random object which, when invoked as a function, will cause an error. SYMBOL-FUNCTION with non-function symbol also returns something not a function. I think that the right move is to go with interpretation A, except that we would say "is an error" instead of "cuases an error". If existing implementations do something like B, they would still be allowed, but people could not count on this behavior in portable code, and it would be more tasteful to signal an error. In general, I think we need to allow implementors maximum leeway in dealing with the function cell and related structures -- the performance implications can be very substantial. We don't really need to use the function cell as a place to store random things, and the ability to do (setf (symbol-function 'foo) (symbol-function 'bar)) for non-functions is not worth much. -- Scott  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 2 May 86 10:27:16 EDT Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 2 May 86 07:16:06 PDT Received: ID ; Fri 2 May 86 10:16:55-EDT Date: Fri, 2 May 1986 10:16 EDT Message-ID: From: Rob MacLachlan To: Kent M Pitman Cc: Common-Lisp@SU-AI.ARPA Subject: Problems with packages In-reply-to: Msg of 1 May 1986 22:53-EDT from Kent M Pitman Date: Thursday, 1 May 1986 22:53-EDT From: Kent M Pitman To: Common-Lisp at SU-AI.ARPA Re: Problems with packages ... What happened was that I hit a bad timing window and it tried to resolve the `FOO' package at the instant the package was created but before the special stuff (like shadowing, importing, etc.) had been done. ... Sounds like an environment issue to me :-) While I'm on the subject of packages, I have a few other gripes to air... I'm really bothered that I have to say symbols as arguments to shadow. The 3600 implementation allows me to use strings, which CL doesn't define. CL should -require- strings as arguments to this function and should not allow symbols. Giving symbols as arguments to this function forces things to get created wrong and then hopes that things will get cleaned up correctly afterward. This reduces the ability to error-check if the symbol to be shadowed had already been interned for some reason other than the call to shadow. I don't quite follow what you are saying about "things getting created wrong." If the call to shadow is read in the package which them symbols are to be shadowed in, then: 1] The symbols get created as internal symbols in the package, in which case shadow does nothing but update the shadowing symbols list. 2] The symbols were already directly present in the package, in which case both reading and shadowing do nothing but update the shadowing symbols list. 3] The symbols are inherited from somewhere, in which case the "wrong" symbol is read, but nothing is "created wrong", since the symbol already existed. It is a bit odd that SHADOW takes a list of symbols and then just uses the names, but it doesn't have any bad side-effects that I can see. I would guess that consistency was the motivation for using symbols everywhere. Using symbols also lets those of us who dislike uppercase type the names of the arguments in lowercase. Rob  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 2 May 86 08:36:37 EDT Received: from SU-SHASTA.ARPA by SU-AI.ARPA with TCP; 2 May 86 05:28:12 PDT Received: by su-shasta.arpa with TCP; Fri, 2 May 86 05:28:12 pdt Received: by ntt.junet (4.12/4.7JC-7) CHAOS with CHAOS-MAIL id AA12816; Fri, 2 May 86 16:56:07 jst From: yuasa@kurims.kurims.kyoto-u.junet Received: by ntt.junet (4.12/4.7JC-7) CHAOS with CHAOS-MAIL id AA12634; Fri, 2 May 86 16:53:43 jst Received: by kurims.kyoto-u.junet (2.0/4.7) id AA01090; Fri, 2 May 86 17:43:51 pdt Date: Fri, 2 May 86 17:43:51 pdt Message-Id: <8605030043.AA01090@kurims.kyoto-u.junet> To: Common-Lisp@SU-AI.ARPA Subject: FUNCTION and MACROLET To sum up, there are two possibilities: [A] (MACROLET ((FOO ...)) (FUNCTION FOO)) causes an error, and SYMBOL-FUNCTION with non-function symbol also causes an error. [B] (MACROLET ((FOO ...)) (FUNCTION FOO)) returns some totally random object which, when invoked as a function, will cause an error. SYMBOL-FUNCTION with non-function symbol also returns something not a function. CLtL supports [B]. Also Guy's proposed clarification seems to support [B]. However, [B] forces the compiler to INVENT something not a function, and to silently generate code that returns the something, although this something is totally useless. Rather, the compiler should cause an error when processing the above MACROLET form. I prefer [A]. As Rob said, the difference of [A] and [B] do not matter actually. In addition, it will be straightforward to change an already existing implementation toward [A]. (Indeed, I think I could do the change in five minutes for KYOTO!!) The above discussions (and the discussions of Bob and Nick) are based on Nick's assumption that FUNCTION with a symbol should correspond to SYMBOL-FUNCTION in sense that a symbol as a variable corresponds to SYMBOL-VALUE). Is this what most people agree with? Yes, the description of FUNCTION in CLtL says ...; see SYMBOL-FUNCTION. The reader of CLtL might see the description of SYMBOL-FUNCTION. Perhaps he would like to say "yes, I saw it... so what?" -- Taiichi  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 2 May 86 07:48:08 EDT Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 2 May 86 04:40:26 PDT Date: Fri, 2 May 86 07:42:12 EDT From: "George J. Carrette" Subject: Problems with packages: work arounds. To: KMP@SCRC-STONY-BROOK.ARPA cc: Common-Lisp@SU-AI.ARPA In-reply-to: Msg of Thu 1 May 86 22:53 EDT from Kent M Pitman Message-ID: <[MC.LCS.MIT.EDU].901826.860502.GJC> If you still have the (MACSYMA-MODULE ) as the first form in every file you can do what I do for DOE-MACSYMA, (macsyma-module ) => (eval-when (eval compile load) (or (find-package "MACSYMA") (error "bad news")) ... etc ...)  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 2 May 86 00:57:23 EDT Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 1 May 86 21:33:57 PDT Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by SCRC-STONY-BROOK.ARPA via CHAOS with CHAOS-MAIL id 478192; Thu 1-May-86 22:53:42-EDT Date: Thu, 1 May 86 22:53 EDT From: Kent M Pitman Subject: Problems with packages To: Common-Lisp@SU-AI.ARPA Message-ID: <860501225353.8.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> I ran into a problem the other day in Symbolics (extended) Common Lisp where I was doing a DEFPACKAGE which specified some shadowed symbols and lossage resulted due to a bug where the package creation wasn't done atomically. For those not familiar with DEFPACKAGE, we can write: (DEFPACKAGE "FOO" (:USE "FRED") (:SIZE 10000.) (:IMPORT HACKS:FOO COLOR:PAINT MATH:SOLVE ...) (:SHADOW "JOE" "MARY" "SALLY") (:EXPORT "JOE" "PAINT")) The problem was that I was trying to read into the editor in one process a file on the `FOO' package while I was loading the system in another process which defined the `FOO' package. For those not familiar with the Lisp Machine architecture, both processes share the same global environment (including, therefore, package declarations). I was expecting that it was going to say that `FOO' wasn't defined and I was going to tell it to use `USER' for my editing purposes now while the system loaded. Something much worse happened... What happened was that I hit a bad timing window and it tried to resolve the `FOO' package at the instant the package was created but before the special stuff (like shadowing, importing, etc.) had been done. The editor managed to add some symbols to the `FOO' package before the process in the other window managed to process the shadows, resulting in lossage when the shadow information finally got processed and the system realized that the symbols in question had already been interned without knowing about the shadow information. In our environment, we can treat this as a simple bug and just have DEFPACKAGE run without interrupts or have it take an appropriate lock on the package during its creation so that any other process trying to do an intern or lookup blocks waiting for the operation to finish. However, in normal Common Lisp, because of the absence of DEFPACKAGE, there would be no way to do this because you can't really tell when you're done creating a package. IN-PACKAGE can't leave the package locked because it might be that no calls to SHADOW and friends follow. Even if they did follow, you can't tell when they're done following. What a mess. CL should have DEFPACKAGE. While I'm on the subject of packages, I have a few other gripes to air... I'm really bothered that I have to say symbols as arguments to shadow. The 3600 implementation allows me to use strings, which CL doesn't define. CL should -require- strings as arguments to this function and should not allow symbols. Giving symbols as arguments to this function forces things to get created wrong and then hopes that things will get cleaned up correctly afterward. This reduces the ability to error-check if the symbol to be shadowed had already been interned for some reason other than the call to shadow. The same situation applies to EXPORT, etc. -- except for IMPORT, for which it would seem perfectly reasonable to require symbols (and forbid strings). Finally, it bothers me that there isn't a version of IN-PACKAGE that doesn't require the package to exist. Macsyma has about 200 source files and every one of them starts with IN-PACKAGE. It also shadows about 20 symbols and I'm not (for reasons of modularity) going to repeat the SHADOW declaration at the top of every one of those files. I define the package early on and everything works mostly ok, but if someone were to read the files out of order, the package would get created incorrectly because no shadow information would get seen. Yet no error would get signalled because IN-PACKAGE would still create the package. I really want the file that declares the package to contain a call to IN-PACKAGE and all the other files to call some function IN-EXISTING-PACKAGE which errs if the package doesn't exist, but which otherwise does what IN-PACKAGE does.  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 1 May 86 21:40:26 EDT Received: from XEROX.COM by SU-AI.ARPA with TCP; 1 May 86 18:31:26 PDT Received: from Cabernet.ms by ArpaGateway.ms ; 01 MAY 86 18:27:22 PDT Date: 1 May 86 18:27 PDT From: Miller.pa@Xerox.COM Subject: Re: Does defmacro need a lexicality barrier? In-reply-to: Pavel.pa's message of 1 May 86 16:24 PDT To: Pavel.pa@Xerox.COM cc: Common-Lisp@SU-AI.ARPA Message-ID: <860501-182722-1807@Xerox> Date: 1 May 86 16:24 PDT From: Pavel.pa Subject: Does defmacro need a lexicality barrier? [...] What I would really like is a method for the construction of ``closures'' over the null lexical environment. As far as I can tell, Common Lisp does not supply such a mechanism What about (EVAL '#'(lambda (x y) ...) NIL) -- MarkM  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 1 May 86 20:25:09 EDT Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 1 May 86 17:11:11 PDT Received: ID ; Thu 1 May 86 20:11:54-EDT Date: Thu, 1 May 1986 20:11 EDT Message-ID: From: Rob MacLachlan To: Pavel.pa@XEROX.COM Cc: Common-Lisp@SU-AI.ARPA Subject: Does defmacro need a lexicality barrier? In-reply-to: Msg of 1 May 1986 19:24-EDT from Pavel.pa at Xerox.COM The definition of DEFMACRO clearly says that the body of the macro is in the null environment. Although "it is an error" to refer to an unbound variable, you do have to make the environment null because information related to a lexical binding around the defmacro would erroneously be attached any free variable with the same name in the body. In Spice Lisp, we have an internal special form IN-GLOBAL-ENVIRONMENT which is used for this exact purpose. Rob  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 1 May 86 19:34:25 EDT Received: from XEROX.COM by SU-AI.ARPA with TCP; 1 May 86 16:24:26 PDT Received: from Cabernet.ms by ArpaGateway.ms ; 01 MAY 86 16:24:08 PDT Date: 1 May 86 16:24 PDT From: Pavel.pa@Xerox.COM Subject: Does defmacro need a lexicality barrier? To: Common-Lisp@SU-AI.ARPA Message-ID: <860501-162408-1662@Xerox> It is not clear to me how defmacro is supposed to create the expansion function to be stored as the macro-function of the given symbol. The issues related to understanding the argument list are reasonably obvious, but those relating to the lexical scope of the function are not. Consider the following oversimplified outline for the definition of defmacro: (defmacro defmacro (name arg-list &body body) ... analyze the argument list and construct the pieces out of which ... an expansion funcion could be put together. Store the actual ... S-expression on the variable expansion-function. `(setf (macro-function ,name) ,expansion-function) ) This definition ignores such features as documentation strings, but what I'm really concerned about is what to put in the variable ``expansion-function''. If we set it to something like #'(lambda (form env) ...) then the macro body will have access to any variables in the lexical environment of the defmacro. It appears that we could fix that by changing #' into simply ': '(lambda (form env) ...) Unfortunately, this implies reasonably strongly that the macro body will not be compiled, since it is only a random list. I suppose that it is possible that the compiler would notice that this random list is being stuck somewhere that a funcallable object is supposed to go, but it doesn't sound either likely or correct. If I am worried about getting the expansion function compiled, but in the correct (null) lexical environment, I guess I can set ``expansion-function'' to (compile nil '(lambda (form env) ...)) This has the somewhat strange effect of preventing the existence of interpreted macros. Surely this is not the intent of the design of Common Lisp. What I would really like is a method for the construction of ``closures'' over the null lexical environment. As far as I can tell, Common Lisp does not supply such a mechanism. Am I just totally confused? Is this whole point moot? After all, what is the meaning of a defmacro that makes reference to lexical variables? If it ``is an error'', then I can use the #' solution above. What does everyone else do? Do we need a new special form ``with-null-lexical-environment''? Pavel  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 1 May 86 10:56:54 EDT Received: from [192.10.41.223] by SU-AI.ARPA with TCP; 1 May 86 07:46:43 PDT Received: from CHICOPEE.SCRC.Symbolics.COM by SAPSUCKER.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 13826; Thu 1-May-86 10:44:40 EDT Date: Thu, 1 May 86 10:48 EDT From: Daniel L. Weinreb Subject: editing a function definition To: Fahlman@C.CS.CMU.EDU, LOOSEMORE@UTAH-20.ARPA cc: common-lisp@SU-AI.ARPA In-Reply-To: Message-ID: <860501104847.8.DLW@CHICOPEE.SCRC.Symbolics.COM> Date: Wed, 30 Apr 1986 23:07 EDT From: "Scott E. Fahlman" My own opinion (none of which is or should be in the Common Lisp spec) is that an Emacs-like editor ought to zap you over to the right place in the right file. Indeed, this is what the traditional Lisp machine ED function does, and it's similar to several facilities provided in time-sharing system Lisps, such as LEDIT from MIT. I think the paragraph as the beginning of the "Debugging Tools" chapter needs some more-explicit text, explaining that the behavior of these functions, unlike those in the rest of the manual, is NOT intended to be fully specified by the Common Lisp definition; that they are only conventions to try to help users get started in different CL programming environments by providing some common names; and that portable programs cannot depend on their behavior. You can infer this from the existing text, but I think a more explicit warning is warranted, since this is such a departure from the philosopy of the rest of the definition of the language.  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 1 May 86 10:01:40 EDT Received: from HUDSON.DEC.COM by SU-AI.ARPA with TCP; 1 May 86 06:53:36 PDT Date: 1 May 86 09:40:00 EST From: "BARTOK::GREEK" Subject: Environment Query Functions. To: "common-lisp" Reply-To: "BARTOK::GREEK" I think the environment query functions like MACHINE-TYPE ought to be limited to human-readable information. If programs need to make decisions based on this information they should use te *FEATURES* list. All that aside, I certainly agree that a lot of this information needs to be registered. I volunteered to be the registrar about six months ago, but that led nowhere. Who really wants to be restricted in what they can do? - Paul ------  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 1 May 86 08:48:38 EDT Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 1 May 86 05:37:08 PDT Received: ID ; Thu 1 May 86 08:37:50-EDT Date: Thu, 1 May 1986 08:37 EDT Message-ID: From: Rob MacLachlan To: NGALL@BBNG.ARPA Cc: Common-Lisp@SU-AI.ARPA Subject: FUNCTION and MACROLET In-reply-to: Msg of 30 Apr 1986 18:55-EDT from NGALL at G.BBN.COM I'm not sure I agree that it would be an incompatible change to say that calling SYMBOL-FUNCTION with a non-function symbol is an error. The current manual guarantees nothing about what is currently returned, so no portable program can use SYMBOL-FUNCTION on non-function symbols. Saying that it "is an error" to use SYMBOL-FUNCTION on non-functions wouldn't require anyone to change anything, since implementations can choose to define SYMBOL-FUNCTION to do whatever it currently does in the non-function case. The only discernible use for SYMBOL-FUNCTION on non-function symbols is setting the SYMBOL-FUNCTION of one symbol to be the same as that of another: (setf (symbol-function 'new-macro) (symbol-function 'old-macro)) Note that nowhere in the manual does it say that this will work. There is no need to define it to work, since MACRO-FUNCTION can do the same job better. Rob  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 1 May 86 04:17:51 EDT Received: from MIT-REAGAN.ARPA by SU-AI.ARPA with TCP; 1 May 86 01:07:59 PDT Received: from DUANE.AI.MIT.EDU by MIT-REAGAN.ARPA via CHAOS with CHAOS-MAIL id 30625; Thu 1-May-86 04:09:49-EDT Date: Thu, 1 May 86 04:09 EDT From: Christopher Fry Subject: Environment Query Functions. To: greek%bach.decnet@hudson.dec.com, common-lisp@SU-AI.ARPA In-Reply-To: The message of 28 Apr 86 11:36-EDT from "BACH::GREEK" Message-ID: <860501040913.2.CFRY@DUANE.AI.MIT.EDU> I think the watchword is "short and sweet" as far as the environment query functions are concerned. Here's what we do for VAX LISP. LISP-IMPLEMENTATION-TYPE is "VAX LISP". LISP-IMPLEMENTATION-VERSION is something like "V2.0". MACHINE-TYPE is the machine name, like "DEC VAX 11/780" "DEC VAXstation II". MACHINE-VERSION is tough to call, so we return the SID register, which uniquely identifies the CPU. Not so great. MACHINE-INSTANCE is setable by the system manager/user. SOFTWARE-TYPE is "VMS" or "ULTRIX". SOFTWARE-VERSION is whatever the operating system says its version is. SHORT-SITE-NAME & LONG-SITE-NAME is setable by the system manager/user. There's a few reasons for these variables: -to help a user figure out what environment he's in -to help a program ... Generally programs care that certain values that ought to be the same are identical, and certain things that ought to be unique really are. An example of "the same" is, if 2 different lisps both run on a VAX 780, then they ought to have identical values for MACHINE-TYPE. An example of difficulty with cases for uniqueness might come in the SHORT-SITE-NAME for a site in Paris, France and Paris, Texas. [They BOTH might decide to use "ROME Air Force" ! ] The world is big, and there's lots of hardware/ operating systems out there, but with a little coordination we could: Provide reasonable values for these vars that were unique when they need to be and the same when they need to be. I propose that a clearinghouse for such names occur at ISI as part of the validation suite effort. We need to come up for rules of reasonability for names, and a mechanism for distributing the Known Nameset [say every 3 months?] so that people writting portable code can have at least some chance of doing it right. Maybe in the process of doing this we'll discover that certain of the above vars are useless, and/or that a few more should be added. All the more reason for centralizing the process.