Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 9 Dec 86 19:31:42 EST Received: from SUMEX-AIM.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 9 Dec 86 16:05:45 PST Date: Tue 9 Dec 86 16:03:11-PST From: Mark Richer Subject: X window system To: common-lisp@SU-AI.ARPA cc: richer@SUMEX-AIM.ARPA Message-ID: <12261524037.86.RICHER@SUMEX-AIM.ARPA> I am interested in extensions to Commonlisp that are interfaced to the X window system, especially using object-oriented programming. THere are groups at Berkeley, Utah, and so on that are doing this right now. I am putting together a mailing list on this and if you have something to share or would just like to be on the list let me know. I guess if you are interested in interfaces to SUN's new window system NEWS let me know also. Mark -------  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 8 Dec 86 16:16:42 EST Received: from [128.81.51.3] by SAIL.STANFORD.EDU with TCP; 8 Dec 86 12:56:21 PST Received: from PENG.S4CC.Symbolics.COM by DIAMOND.S4CC.Symbolics.COM via CHAOS with CHAOS-MAIL id 34724; Mon 8-Dec-86 15:53:43 EST Date: Mon, 8 Dec 86 15:53 EST From: susan watkins Subject: X3J13 mailing list To: MATHIS@ADA20.ISI.EDU cc: common-lisp@SU-AI.ARPA In-Reply-To: <[ADA20.ISI.EDU] 6-Dec-86 07:29:54.MATHIS> Message-ID: <861208155333.5.CHAOWATKINS@PENG.S4CC.Symbolics.COM> Date: 6 Dec 1986 07:29-PST From: MATHIS@ADA20.ISI.EDU The next X3J13 meeting will be in Dallas, TX, Dec 10-12, 1986. Topics on the agenda include the function cell value cell issue and a discussion of error systems. The first meeting included a discussion of object system proposals and "minor" corrections to the Steele book. There is a separate mailing list for X3J13. If you are interested, please reply directly to me. Please put me on the mailing list. Thanks. My arpa address is : chaowatkins@srcr-stony-brook.arpa [..... ] -- Bob Mathis, Convenor and Acting Chairman, X3J13  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 8 Dec 86 08:39:59 EST Received: from [128.81.51.3] by SAIL.STANFORD.EDU with TCP; 8 Dec 86 05:31:33 PST Received: from KOYAANISQATSI.S4CC.Symbolics.COM by DIAMOND.S4CC.Symbolics.COM via CHAOS with CHAOS-MAIL id 34474; Mon 8-Dec-86 08:29:36 EST Date: Mon, 8 Dec 86 08:29 EST From: David C. Plummer Subject: Underspecification of ~R To: Stanley T. Shebs , common-lisp@SU-AI.ARPA In-Reply-To: <8612060457.AA21384@utah-orion.ARPA> Message-ID: <861208082926.7.DCP@KOYAANISQATSI.S4CC.Symbolics.COM> Date: Fri, 5 Dec 86 21:57:09 MST From: shebs%utah-orion@utah-cs.arpa (Stanley T. Shebs) ... I would prefer to see "minus four" and have an error for negative cardinals, since "minus fourth" sounds pretty strange! (dolist (power '(-4 -2 0 2 4)) (format t "~A to the ~:R power~%" "X" power)) X to the minus fourth power X to the minus second power X to the zeroth power X to the second power X to the fourth power Doesn't sound strange to me. Sandra suggests "a lot" as the right way to print large integers, while I favor "many" (consider the New Guinea tribes whose number system is "one", "two", "three", "many"). There should also be a definite bound on integer size (I would make it low; "five decillion" also looks pretty strange). Finally, keep in mind that Americans and Britons do things differently above one million - perhaps the time zone returned by get-decoded-time should be used to decide whether to print "billion" or "milliard" (which do Canadians use anyway?). Security in obscurity? Some systems (e.g. Symbolics) punt after certain limits. (dotimes (i 10) (format t "10^~D ~@R~%" i (expt 10 i)))10^0 I 10^1 X 10^2 C 10^3 M 10^4 10000 10^5 100000 10^6 1000000 10^7 10000000 10^8 100000000 10^9 1000000000 (do ((i 8 (+ i 2))) ((> i 50)) (format t "10^~D ~R~%" i (expt 10 i))) 10^8 one hundred million 10^10 ten billion 10^12 one trillion 10^14 one hundred trillion 10^16 ten quadrillion 10^18 one quintillion 10^20 one hundred quintillion 10^22 ten sextillion 10^24 one septillion 10^26 one hundred septillion 10^28 ten octillion 10^30 one nonillion 10^32 one hundred nonillion 10^34 ten decillion 10^36 one undecillion 10^38 one hundred undecillion 10^40 ten duodecillion 10^42 one times ten to the forty-second power 10^44 one hundred times ten to the forty-second power 10^46 ten times ten to the forty-fifth power 10^48 one times ten to the forty-eighth power 10^50 one hundred times ten to the forty-eighth power One could possibly claim no "reasonable" program would be working properly (or was given proper inputs) if it ever tried to make such large numbers intelligible. Of course, the : and @ options could just be omitted... stan the obscure  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 8 Dec 86 01:59:53 EST Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 7 Dec 86 22:48:53 PST Received: from cs.umass.edu by csnet-relay.csnet id aq13844; 8 Dec 86 1:32 EST Date: Sun, 7 Dec 86 18:11 EDT From: ELIOT%cs.umass.edu@RELAY.CS.NET To: Common-lisp@SU-AI.ARPA Subject: Added Keyword argument to load. X-VMS-To: CSNET%"Common-lisp@su-ai.arpa" I would find a "compile" option for the LOAD function to be quite useful. It would be a simple, upwards compatible change to add a :COMPILE keyword argument whose values would be NIL (default), T or :IF-NEEDED. NIL and T would mean never and always. :IF-NEEDED would specify that LOAD should check the FILE-WRITE-DATE of the source and (possibly non-existent) previous binary file, and compile the source if the binary doesn't exist or is older than the source. This would not be intended to replace a full fledged source code control system or system rebuilder like the Lisp Machine supplies. It would be very useful for people, (like students) who write many small Lisp programs. Each semester I write several programs, none of which normally have more than five source files, and no complicated dependancies. However, I may be forced to move among many different machines, and it may be impossible for me to maintain a single library of "personal" utilities that can be accessed by all of the machines I use. With these needs in mind the two semantic issues of my proposal can be dealt with. (1) What should be done about compile-time/load-time dependancies. For example should there be any concern about loading macro libraries before compiling specific files. Answer: No. Those issues should be dealt with by a larger scale, probably implementation dependant utility. These issues are not critical for small (< 2000 lines) programs which is the scal of programs which this feature attempts to support. (2) How can LOAD determine which source file corresponds to which compiled file. Answer: (1) Load already is defined to know how to do this, because it can "in some implementation dependant way" choose whether to load a text or object version of the file. (2) It should check at least the files which it would otherwise load, and it should check the files which COMPILE-FILE would read and write if COMPILE-FILE were given the same argument. Implementations which don't distinguish compiled files would obviously be free to ignore this keyword.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 6 Dec 86 11:04:35 EST Received: from ADA20.ISI.EDU by SAIL.STANFORD.EDU with TCP; 6 Dec 86 07:57:58 PST Date: 6 Dec 1986 07:29-PST Sender: MATHIS@ADA20.ISI.EDU Subject: ANSI doings From: MATHIS@ADA20.ISI.EDU To: common-lisp@SU-AI.ARPA Message-ID: <[ADA20.ISI.EDU] 6-Dec-86 07:29:54.MATHIS> The next X3J13 meeting will be in Dallas, TX, Dec 10-12, 1986. Topics on the agenda include the function cell value cell issue and a discussion of error systems. The first meeting included a discussion of object system proposals and "minor" corrections to the Steele book. There is a separate mailing list for X3J13. If you are interested, please reply directly to me. We are also beginning to discuss how to take advantage of the open technical interchange which occurs here and then work that into X3J13 decision making about the eventual standard. Thoughts on this topic may be communicated directly to me or to the whole common-lisp mailing list. When a suggestion on how to do this is put together, I will be sure that it is circulated to the whole community (not just X3J13). -- Bob Mathis, Convenor and Acting Chairman, X3J13  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 6 Dec 86 00:05:01 EST Received: from UTAH-CS.ARPA by SAIL.STANFORD.EDU with TCP; 5 Dec 86 20:55:45 PST Received: by utah-cs.ARPA (5.31/4.40.2) id AA00374; Fri, 5 Dec 86 21:57:12 MST Received: by utah-orion.ARPA (5.31/4.40.2) id AA21384; Fri, 5 Dec 86 21:57:09 MST Date: Fri, 5 Dec 86 21:57:09 MST From: shebs%utah-orion@utah-cs.arpa (Stanley T. Shebs) Message-Id: <8612060457.AA21384@utah-orion.ARPA> To: common-lisp@su-ai.arpa Subject: Underspecification of ~R In the description of the various : and @ options to ~R (cardinals, ordinals, and two flavors of Roman numerals), it is said that any integer is printed in the appropriate way. How should negative and very large integers be handled? HP CL prints out a "negative " for negative cardinals and ordinals, and prints out various error messages for other cases. I would prefer to see "minus four" and have an error for negative cardinals, since "minus fourth" sounds pretty strange! Sandra suggests "a lot" as the right way to print large integers, while I favor "many" (consider the New Guinea tribes whose number system is "one", "two", "three", "many"). There should also be a definite bound on integer size (I would make it low; "five decillion" also looks pretty strange). Finally, keep in mind that Americans and Britons do things differently above one million - perhaps the time zone returned by get-decoded-time should be used to decide whether to print "billion" or "milliard" (which do Canadians use anyway?). Of course, the : and @ options could just be omitted... stan the obscure  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 5 Dec 86 20:49:10 EST Received: from ADA20.ISI.EDU by SAIL.STANFORD.EDU with TCP; 5 Dec 86 17:34:30 PST Date: 5 Dec 1986 12:05-PST Sender: MATHIS@ADA20.ISI.EDU Subject: is it real or is it... From: MATHIS@ADA20.ISI.EDU To: common-lisp@SU-AI.ARPA Message-ID: <[ADA20.ISI.EDU] 5-Dec-86 12:05:20.MATHIS> On page 56 of the November 1986 "High Technology Magazine" there is an unidentified person in a picture. Is it Danny Bobrow or some celebrity look-a-like that marketing found?  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 5 Dec 86 19:17:38 EST Date: 05 Dec 86 1604 PST From: Rich Alderson Subject: ANSI doings? To: common-lisp@SAIL.STANFORD.EDU Is anybody willing to post a precis of the current ANSI meetings?  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 4 Dec 86 02:33:00 EST Received: from HPLABS.HP.COM by SAIL.STANFORD.EDU with TCP; 3 Dec 86 23:18:09 PST Received: by hplabs.HP.COM ; Wed, 3 Dec 86 15:57:37 pst Received: from hplbgw (hplbgw) by hplb29a ; Wed, 3 Dec 86 15:50:39 pst Received: by hplbgw ; Wed, 3 Dec 86 15:50:22 pst Date: Wed, 3 Dec 86 15:50:22 pst From: Gregory Weeks Message-Id: <8612032350.AA00381@hplbgw> To: Soley@MIT-XX.ARPA, su-ai!common-lisp@hplabs.HP.COM, hplabs!!cad.cs.cmu.edu!spe@SAIL.STANFORD.EDU Subject: Re: Packages ....... Are you saying that (eql #'FOO:QUUX #'BAR:QUUX) => NIL, but (eql 'FOO:QUUX 'BAR:QUUX) => T ?? First (to say it politely) I don't see how your solution solves anything. Second, the more obvious solution of making (EQL 'FOO:QUUX 'BAR:QUUX) => T is (1) uneconomical, and (2) unteachable in the presence of (eql #'FOO:QUUX #'BAR:QUUX) => NIL. I guess my idea wasn't well-worded. Let me try to clarify. I would remove any association of symbols to packages, thus there would be no FU:QUUX, there would just be QUUX. However, QUUX's value and function would be attached to packages, thus we could speak of QUUX's function in package FU, or QUUX's value in package BAR. Thus we have separate name spaces for functions and values, without the ridiculosity of having to do interning, or string coercion whenever comparison of symbols is needed. -Sean Engelson- Hi. The notion you present is essentially the same as one I came up with. Here is a summary of how I see it all working. 1. Symbols with the same name are identical. Symbols do not have values, function-cells, package-cells, or property lists. 2. By definition, a BINDING associates a symbol and a "property" (another symbol) with a value. A PACKAGE is a set of bindings. At any given time, one package is current. 3. Defining constructs exist which create bindings and add them to the current package. There are also referencing constructs which access or mutate bindings. A binding may not be referenced before it has been defined! (So bindings can not be created with SETF.) (Names for defining constructs might be DEFVAR, DEFUN, DEFMACRO, DEFTYPE, DEFSTRUCT, and so on, all of which would be special cases of, say, DEFPROP.) 4. Constructs exist which allow a package to reference some of the bindings of other packages. However, no two distinct bindings with the same symbol and property may be referenceable (without qualifiers) in any one package. Also, no package may redefine a binding it did not define! The above notion eliminates all spurious name clashes. It has several drawbacks as far as Common Lisp is concerned. Here are the worst in my opinion. First, binding values are looked up (and possibly cached) as needed at run time. I don't see how to do this efficiently. Second, Common Lisp is already a standard, so major changes aren't reasonable. Finally, while the above is the best I could come up with, I feel that there is something else out there better. (For example, I don't know anything about locales.) Still, I think the idea you presented to be basically sound and semantically a significant improvement over the status quo. Good luck in getting Soley to see things the same way. Greg Weeks  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 3 Dec 86 02:37:03 EST Received: from REAGAN.AI.MIT.EDU by SAIL.STANFORD.EDU with TCP; 2 Dec 86 22:59:29 PST Received: from SINATRA.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 14027; Wed 3-Dec-86 01:58:41 EST Date: Wed, 3 Dec 86 01:58 EST From: CFry@OZ.AI.MIT.EDU Sender: Henry@OZ.AI.MIT.EDU Subject: Common EVAL To: Common-Lisp@SU-AI.ARPA cc: Henry@OZ.AI.MIT.EDU Message-ID: <861203015844.2.HENRY@SINATRA.AI.MIT.EDU> Reply-To: HENRY@AI.AI.MIT.EDU Common EVAL Henry Lieberman and Christopher Fry Abstract We propose that the Common Lisp standard be extended by adding to the language specification a short program, itself written in Common Lisp, to implement the EVAL function. The interpreters for every correct implementation of Common Lisp would be required to match the semantics of Common EVAL on valid Common Lisp expressions. It should treat other expressions as errors or as implementation dependent extensions. There are three cogent reasons for including a Common EVAL in the standard: First, since EVAL fixes the meaning of Lisp programs, it would insure uniformity of program semantics across implementations. Second, it would aid validation efforts, since the behavior of a particular implementation could always be compared to the behavior of Common EVAL. Third, it would facilitate the creation of debuggers and other program-manipulating programs that could be ported across Common Lisp implementations. ---------------------------------------------------------------------- One of the marvelous things about Lisp is that the language can be written in itself. In Lisp, programs can be data and data can be programs. The operation of the language itself can be described as a function written in the very same language: the EVAL function. Lisp advocates always point with pride to this fact as a major reason for Lisp's superiority over conventional languages. It is why Lisp has traditionally supported the best debugging environments. It is why Lisp can be used to write the program-manipulating programs which are essential in artificial intelligence work, and in building advanced interactive programming environments. Sadly, this important advantage is becoming steadily eroded by some of the modern production implementations of Lisp. The quest for efficiency and experimentation with esoteric programming constructs are leading to non-standard implementations of Lisp interpreters that foil attempts to make use of Lisp's self-descriptive capability. With Common Lisp, we have a unique opportunity to insure that the program-data equivalence which is one of Lisp's cornerstones remains available as Lisp implementations proliferate. But the English description in the Steele book is not detailed enough to exclude semantic deviations which frustrate serious developers of program-manipulating programs. Specifying the EVAL function as a Common Lisp program can provide a concise, precise, and easily understood description which could serve as a guide for implementors and a means by which to evaluate the results. Implementors would not be required to run the exact code for Common EVAL in their implementation. They could provide another implementation, which may be more efficient or include extra features, but they would be required to assure that their version matched the semantics of Common EVAL. Differences in behavior between a particular Lisp implementation and Common EVAL would be evidence for violations of the Common Lisp standard. Many advanced Lisp applications rely on the precise details of the operation of EVAL. Implementing a single-stepping debugger for Lisp code, for example, requires imitating EVAL on Lisp expressions, while inserting display operations and requesting input at events during evaluation. Lisp's extensibility makes it ideal for defining embedded application-dependent languages, which may even have a different control structure than Lisp's. Often, these languages need to "use Lisp" as a subset, call Lisp functions from code in the other language, or even invoke foreign language code from Lisp code. For the interface to be smooth, the language designer must be able to depend on how Lisp code is evaluated, perhaps including details such as variable environments and function definitions. Many programs which need to analyze Lisp programs statically require a "code walker", a program that determines which subexpressions of a Lisp expression represent code to be evaluated, and which represent data, like expressions which appear inside a QUOTEd list. Such code walkers, which separate the uses of Lisp expressions as programs from uses as data, appear in virtually every Lisp compiler. Smart pretty-printers that print expressions according to their semantics, indexers, or other "programmer's apprentice" tools need this, too. Code walkers anticipate the action of EVAL on an expression, so they are inextricably tied to EVAL's operation. With Common EVAL, a designer of a program-manipulating program can base their tools on the definition of Common EVAL rather than the details of a particular Lisp implementation. The implementor can then have confidence that the tools will work in all valid implementations of Common Lisp. This should significantly enhance Common Lisp's suitability for advanced applications. The interpreters for MIT-descended Lisp Machines by Symbolics, LMI and TI show how production implementations have compromised Lisp semantics. Surprisingly, if you look at the system's definition of the EVAL function, you will find that it only appears to be written in Lisp. It calls "subprimitives" which are special-cased by the compiler, compiling into specialized microcode, motivated by an attempt to make the Lisp interpreter more efficient. The subprimitives do things which, for example, violate the stack discipline of Lisp. The system's definition of EVAL cannot even be interpreted by EVAL itself! Because of the additional complexity that machine-dependent efficiency hacks add to the evaluator, it is no longer feasible to write an EVAL without subprimitives, and have any confidence that the results will be equivalent to the system's EVAL. If the code for the evaluator relies on subprimitives, it won't even be intelligible to the human reader literate only in Lisp. This is not to say that we are against subprimitives; obviously, they are necessary for such functions as CAR and EQ. The English description of the behavior of lowest level functions in the Steele book is adequate, as is the description of middle level functions like APPEND. It is only when the complexity of something like EVAL is reached that divergence among implementations becomes a real problem. Periodically, internal changes to a system's evaluator require changing any imitative implementation. For example, Symbolics recently changed the function cell of an interpreted function from containing a lambda expression to SI:DIGESTED-LAMBDA, which necessitated similar changes in any program which expected to interpret functions. A standard EVAL would clarify what representations a user could rely on, and clarify what representations an implementor could change without breaking system code or affecting users. Another central problem is that "extensions" to the Lisp language may be implemented in the interpreter by low-level constructs that cannot be directly implemented by a Lisp program. While Common Lisp is designed to permit extensions to the language, it should not allow extensions which rely on microcode and other non-Lisp implementation techniques to change the basic semantics of the language. Such extensions effectively prevent any program-manipulating program written in Common Lisp from operating on code containing the extensions. Spaghetti stacks in Interlisp are an example where an attempt to implement non-standard programming constructs wreaks havoc with the interpreter's semantics. It is impossible for an Interlisp user to write a stepping debugger capable of working on interpreted code that uses spaghetti stacks. Common EVAL should provide well-defined points in the evaluation process at which particular implementations could provide extensions, such as defining a new variety of functional object. How detailed should the Common EVAL implementation be? Everyone knows that it is possible to implement a wide range of meta-circular interpreters ranging from a one-page interpreter in the vein of the original Lisp 1.5 book, to one that is so detailed it specifies every bit and would probably run to hundreds of pages. Clearly, a middle course is called for. The interpreter should be the minimal size necessary to specify the interpreter in terms of calls to Common Lisp functions. It should probably take no more than ten pages to do this. It should be detailed enough to do things like specify the behavior of all the special forms, but does not have to be so detailed as to specify all the internal representations used by the evaluator. The interpreter may need a variety of helping functions to access representations of data structures, for example lexical variable binding environments. To avoid constraining the freedom of implementors to choose efficient representations for such data structures, Common EVAL could call abstract functions whose implementation would not be prescribed by the standard. Every implementation could provide its own EXTEND-ENVIRONMENT function, whose behavior would be specified by a description, in the manner of the Steele book. A simple Common Lisp implementation, for example implementing environments as ALISTs, could be shown for illustrative purposes without fixing the ALIST representation in every Common Lisp implementation. Finally, to illustrate the intent of our proposal more concretely, we present a short segment of Lisp code for a skeleton Common EVAL. Don't take this code too literally -- we mean it only to illustrate the style and the level of detail we would expect of the real Common EVAL, and as a springboard for discussion. #| Some notes about the code: - The LE package contains the lexical environment manipulator fns, many of which are yet to be written. If the CL community decides to provide advertised support for lexical environment functions, some of the functions here could be moved into to LISP package. - The NOT-CL package contains miscellaneous support functions for Common EVAL. - An implementation of eval is permitted to differ semantically from Common EVAL only by redefining NOT-CL:EVAL. This provides a well defined place for modifications to take place. Our default definition here simply errors, as would a pure CL implementation. Functions here which are called, not in CL, and intended to be defined by Common EVAL include: - APPLY - The lexical environment accessors. - The functions for handling individual special forms. - Closures and lexical functions are not dealt with yet. |# (defun eval (exp &optional lex-env) "currently doesn't check for lex-env fns. Right now, CL doesn't permit EVAL to take a 2nd arg. LEX-ENV defaults to the null lexical environment." (cond ((not-cl:self-evaluating-p exp) exp) ((symbolp exp) (not-cl:symbol-eval exp lex-env)) ((consp exp) (cond ((symbolp (car exp)) (cond ((macro-function (car exp)) (eval (macroexpand exp) lex-env)) ((special-form-p (car exp)) (not-cl:eval-special-function-call exp lex-env)) ((fboundp (car exp)) (apply (car exp) (not-cl:list-of-values (cdr exp) lex-env))) (t (not-cl:eval exp lex-env)))) ((and (consp (car exp)) (eq (car (car exp)) 'lambda)) (apply (car exp) (cdr exp))) (t (not-cl:eval exp lex-env)))) (t (not-cl:eval exp lex-env)))) (defun not-cl:self-evaluating-p (form) (or (numberp form) (stringp form) (characterp form) (keywordp form) (null form) (eq form t))) (defun not-cl:symbol-eval (symbol lex-env) "If SYMBOL is a variable in LEX-ENV, return its value. Else If SYMBOL is bound, return its value, else error." (if (le:boundp symbol) (le:symbol-value symbol lex-env) (if (boundp symbol) (symbol-value symbol) (error "Attempt to evaluate an unbound symbol ~S" symbol)))) (defun not-cl:list-of-values (list lex-env) (if list (cons (eval (car list) lex-env) (not-cl:list-of-values (cdr list) lex-env)))) (defun not-cl:eval-special-function-call (exp lex-env) (case (car exp) (block (not-cl:eval-block exp lex-env)) (catch (not-cl:eval-catch exp lex-env)) ;... (otherwise (error "not-cl:eval-special-function-call passed non-implemented special form ~S" exp)))) (defun not-cl:eval (exp &optional lex-env) (error "Eval passed non-CL form ~S" exp))  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 3 Dec 86 00:27:03 EST Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 2 Dec 86 21:13:46 PST Received: from Salvador.ms by ArpaGateway.ms ; 02 DEC 86 20:54:20 PST Date: 2 Dec 86 20:54 PST Sender: Miller.pa@Xerox.COM Subject: Re: Packages then and now In-reply-to: Jeff Barnett 's message of Tue, 2 Dec 86 18:25:23 PST To: jbarnett@nrtc.ARPA cc: common-lisp@SU-AI.ARPA From: Mark S. Miller Message-ID: <861202-205420-3471@Xerox> Date: Tue, 2 Dec 86 18:25:23 PST From: Jeff Barnett What I hope is that there will be a variety of implementations that experiment with the issues that bridge naming, encapsulation, and presentation. I don't know of an entirely satisfactory solution. Judging by the recent flames, I see that no one else does either. What is non-satisfactory about T's scheme? ----- MarkM  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 2 Dec 86 21:58:49 EST Received: from NRTC.ARPA by SAIL.STANFORD.EDU with TCP; 2 Dec 86 18:43:46 PST Date: Tue, 2 Dec 86 18:25:23 PST From: Jeff Barnett To: common-lisp@SU-AI.ARPA Subject: Packages then and now This note is in regargds to the recent conversation about packages. First, a few historical comments. The first appearance in the LISP world was in LISP2 where global program pieces, e.g., special variables, functions, macros, etc., where given a first and last name. (The first name was an integer in the range of 0 to 127.) Symbols, then called identifiers, had only one incarnation. LISP2 was done in the early 1960's. As far as I know, this looked just like the mechansim used by IBM assemblers from the early-middle 1950's. In both, there was a default package (first name) in which to put definitions unless the name of the defined object included an explicit package. Reference ambiguity was resolved, at compile time, by an ordered list of package names. If a symbol (rather than a full name) was used, if there was a definition in the first package on the list it was used; if not, the second one was tried, and so on. For the record, packages were called sections and the first name was really written second. The last attempt at a development along these lines was an implementation called CRISP done in the mid 1970's. In CRISP, symbols and names were different kinds of objects: SYMBOLP and NAMEP were different predicates and no object satisfied both. There were subtypes of name, e.g., variable, function, function with partially specified interface, etc. The mechanism was to protect system developers from each other; not to protect the system from the users. A name object had fields for its binding, type information (as specifically as known), its print name (two symbols) and junk for the GC. A symbol had fields for its printname, property list, and system property list. The system property list located all name objects with this primary name, i.e., all objects with this name in all the packages in which it existed. The property list was tree structured. A node on the property list was a 4-tuple: property name, property value, rest of property list, and inferior property list. The property functions took a list of indicators, e.g., (GET 'foo 'semantics 'lexicon 'phonetics) Usually, the names of the first property was the same as a package name. Most programs only used a single indicator while the layers below it used two. Though the qualification string could be indefinately nested, more than two indicators were rare. Further, the name qualification was only one deep though it could have been generalized. It was not for two reasons: (1) it didn't seem necessary and (2) the default rule became very complex. A finally historical note, these systems were meant for Programmers (with a capital P). They were not meant to separate the unwashed from each other. In fact it is clear that, without change they cannot do the whole job. As to the current state of affairs. I don't like the present package system very much. I happen to like the distinction between symbols as universals and names of program pieces. Unfortunately, in this standardization effort, a change as radical as this would imply is probably misguided. What I hope is that there will be a variety of implementations that experiment with the issues that bridge naming, encapsulation, and presentation. I don't know of an entirely satisfactory solution. Judging by the recent flames, I see that no one else does either. The work on object style programming in LISP will effect the future. Don't forget, that it is another mechanism whose stated purpose is similar: namely to allow development of different programs in the same environment AND development of the same program by multiple contributors.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 2 Dec 86 12:40:32 EST Received: from CS.UCL.AC.UK by SAIL.STANFORD.EDU with TCP; 2 Dec 86 09:28:41 PST Received: from aiva.edinburgh.ac.uk by mv1.Cs.Ucl.AC.UK via Janet with NIFTP id aa00737; 2 Dec 86 17:07 WET From: Jeff Dalton Date: Tue, 2 Dec 86 16:58:15 GMT Message-Id: <21159.8612021658@aiva.ed.ac.uk> To: Sean.Engelson@cad.cs.cmu.edu, Soley@xx.lcs.mit.edu, common-lisp@su-ai.arpa Subject: Re: Packages I believe Sean's suggestion is in intention equivalent to the proposal that packages be replaced by something like Scheme's environments (T's locales). That is, there would be only one symbol X, but it would have different values in different environments. This is the sort of thing that happens already, e.g. with closures. The difference is that these environments would be separate data objects from which you can import values (rather than their names), etc. Several people have already expressed the opinion that the environment approach is insufficiently developed to serve as a replacement for packages. That may be so. In any case, packages and environemnts are more or less independent since reference with respect to packages is resolved at read time and with respect to environments at some eval-like time. So it should be possible to experiment with environment-like approaches in Common Lisp. If anyone from the Scheme would like to explain how environments can be implemented efficiently I'd be interested, but perhaps this list isn't the best place to discuss it? -- Jeff  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 2 Dec 86 01:58:49 EST Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 1 Dec 86 22:47:24 PST Date: Tue, 2 Dec 1986 01:50 EST Message-ID: From: BROOKS%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU To: franz!ficl!jkf@UCBARPA.BERKELEY.EDU (John Foderaro) Cc: common-lisp@SU-AI.ARPA Subject: progv and dynamic variables In-reply-to: Msg of 2 Dec 1986 01:16-EST from franz!ficl!jkf at ucbarpa.Berkeley.EDU (John Foderaro) Aren't declarations illegal before a progv body? -john foderaro Pages 153-154 seem to imply so. I guess the CL I have in front of me has some extensions.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 2 Dec 86 01:35:09 EST Received: from UCBARPA.Berkeley.EDU by SAIL.STANFORD.EDU with TCP; 1 Dec 86 22:26:53 PST Received: by ucbarpa.Berkeley.EDU (5.57/1.18) id AA19366; Mon, 1 Dec 86 22:27:04 PST Received: from ficl by franz (5.5/3.14) id AA02598; Mon, 1 Dec 86 22:16:22 PST Received: by ficl (5.5/3.14) id AA27858; Mon, 1 Dec 86 22:17:00 PST From: franz!ficl!jkf@ucbarpa.Berkeley.EDU (John Foderaro) Return-Path: Message-Id: <8612020617.AA27858@ficl> To: BROOKS%OZ.AI.MIT.EDU@xx.lcs.mit.edu Cc: DALY@ibm.com, common-lisp@su-ai.arpa Subject: Re: progv and dynamic variables In-Reply-To: Your message of Mon, 01 Dec 86 22:04:00 EST. Date: Mon, 01 Dec 86 22:16:58 PST >> 3. >> (defun foo (a s v) >> (progv s v >> (declare (special a)) >> (print a))) >> The binding of `a' during the call to foo is lexical, but the >> reference in (print a) is dynamic. Aren't declarations illegal before a progv body? -john foderaro  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 1 Dec 86 22:52:46 EST Received: from [192.10.41.109] by SAIL.STANFORD.EDU with TCP; 1 Dec 86 19:45:44 PST Received: from CHICOPEE.SCRC.Symbolics.COM by ALDERAAN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 25355; Mon 1-Dec-86 22:43:50 EST Date: Mon, 1 Dec 86 22:46 EST From: Daniel L. Weinreb Subject: progv and dynamic variables To: DALY%ibm.com@MIT-MC.ARPA, common-lisp@SU-AI.ARPA In-Reply-To: <120186.135322.daly@ibm.com> Message-ID: <861201224611.0.DLW@CHICOPEE.SCRC.Symbolics.COM> Juse in case the sense of Rod's reply was not completely clear: the answer is that it is supposed to be 3, not 4, so the implementations were correct. PROGV always does a "special-bind" operation, regardless of what's going on with declarations. The reference to "a" is a lexical reference because there are no declarations making it a dynamic reference.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 1 Dec 86 22:08:52 EST Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 1 Dec 86 19:01:22 PST Date: Mon, 1 Dec 1986 22:04 EST Message-ID: From: BROOKS%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU To: "Timothy P. Daly" Cc: common-lisp@SU-AI.ARPA Subject: progv and dynamic variables In-reply-to: Msg of 1 Dec 1986 13:53:21 EST from Timothy P. Daly What should the following do: (defun foo (a s v) (progv s v (print a))) with: (foo 3 '(a) '(4)) The actual result is 3 but from the book description of PROGV on p112 it appears that it should be 4. I have tried this on 3 different common lisps with the same result. The `a' in (print a) refers to the lexical variable `a' named in foo's parameter list. The progv binds the dynamic variable `a'. You can get the answer to be 4 a number of ways: 1. (defvar a) (defun foo (a s v) (progv s v (print a))) This makes all references to `a' pervasively dynamic so even the call to foo binds the dynamic `a'. 2. (defun foo (a s v) (declare (special a)) (progv s v (print a))) Has the same effect on foo, but other functions can use a lexically scoped `a'. 3. (defun foo (a s v) (progv s v (declare (special a)) (print a))) The binding of `a' during the call to foo is lexical, but the reference in (print a) is dynamic.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 1 Dec 86 21:53:55 EST Received: from IBM.COM by SAIL.STANFORD.EDU with TCP; 1 Dec 86 18:47:08 PST Date: 1 December 1986, 13:53:21 EST From: "Timothy P. Daly" To: common-lisp@su-ai.arpa Message-Id: <120186.135322.daly@ibm.com> Subject: progv and dynamic variables What should the following do: (defun foo (a s v) (progv s v (print a))) with: (foo 3 '(a) '(4)) The actual result is 3 but from the book description of PROGV on p112 it appears that it should be 4. I have tried this on 3 different common lisps with the same result.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 1 Dec 86 18:22:16 EST Received: from LIVE-OAK.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 1 Dec 86 14:32:56 PST Received: from CHERRY.LCS.MIT.EDU by MIT-LIVE-OAK.ARPA via CHAOS with CHAOS-MAIL id 19849; Mon 1-Dec-86 17:31:31-EST Date: Mon, 1 Dec 86 17:32 EST From: Soley@MIT-XX.ARPA Subject: Re: Packages To: Sean.Engelson@cad.cs.cmu.edu, common-lisp@SU-AI.ARPA In-Reply-To: <533857218/spe@cad.cs.cmu.edu> Message-ID: <861201173212.2.SOLEY@CHERRY.LCS.MIT.EDU> Date: 1 Dec 1986 16:40-EST From: Sean.Engelson@cad.cs.cmu.edu Date: Mon, 1 Dec 86 16:25 EST From: Soley@MIT-XX.ARPA Are you saying that (eql #'FOO:QUUX #'BAR:QUUX) => NIL, but (eql 'FOO:QUUX 'BAR:QUUX) => T ?? I guess my idea wasn't well-worded. Let me try to clarify. I would remove any association of symbols to packages, thus there would be no FU:QUUX, there would just be QUUX. However, QUUX's value and function would be attached to packages, thus we could speak of QUUX's function in package FU, or QUUX's value in package BAR. Thus we have separate name spaces for functions and values, without the ridiculosity of having to do interning, or string coercion whenever comparison of symbols is needed. I don't see what this solves. You still need to /talk about/ functions attached to symbols in other packages, in order to apply them. I was just using "FOO:QUUX" as that syntax; are you suggesting something like ((function QUUX FOO) 1 2 3) for the current (FOO:QUUX 1 2 3) ?? And if you want the A package value of the symbol B, instead of A:B you have to type (value-of B 'A) or something? That's just syntax. And there're separate function/value/property slots for each symbol for each known package? I think this makes the world more complex, not simpler. I think in most cases you don't want the name of one of your symbols to be eq to another symbol that just happens to have the same name, but is in another package. -- Richard Soley  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 1 Dec 86 17:18:56 EST Received: from CAD.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 1 Dec 86 13:47:34 PST Date: 1 Dec 1986 16:40-EST From: Sean.Engelson@cad.cs.cmu.edu To: Soley@MIT-XX.ARPA, common-lisp@su-ai Subject: Re: Packages Message-Id: <533857218/spe@cad.cs.cmu.edu> Date: Mon, 1 Dec 86 16:25 EST From: Soley@MIT-XX.ARPA Subject: Packages To: Sean.Engelson@cad.cs.cmu.edu, common-lisp@SU-AI.ARPA ....... Are you saying that (eql #'FOO:QUUX #'BAR:QUUX) => NIL, but (eql 'FOO:QUUX 'BAR:QUUX) => T ?? First (to say it politely) I don't see how your solution solves anything. Second, the more obvious solution of making (EQL 'FOO:QUUX 'BAR:QUUX) => T is (1) uneconomical, and (2) unteachable in the presence of (eql #'FOO:QUUX #'BAR:QUUX) => NIL. I guess my idea wasn't well-worded. Let me try to clarify. I would remove any association of symbols to packages, thus there would be no FU:QUUX, there would just be QUUX. However, QUUX's value and function would be attached to packages, thus we could speak of QUUX's function in package FU, or QUUX's value in package BAR. Thus we have separate name spaces for functions and values, without the ridiculosity of having to do interning, or string coercion whenever comparison of symbols is needed. -Sean Engelson-  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 1 Dec 86 16:48:04 EST Received: from LIVE-OAK.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 1 Dec 86 13:26:26 PST Received: from CHERRY.LCS.MIT.EDU by MIT-LIVE-OAK.ARPA via CHAOS with CHAOS-MAIL id 19829; Mon 1-Dec-86 16:25:08-EST Date: Mon, 1 Dec 86 16:25 EST From: Soley@MIT-XX.ARPA Subject: Packages To: Sean.Engelson@cad.cs.cmu.edu, common-lisp@SU-AI.ARPA In-Reply-To: <533853280/spe@cad.cs.cmu.edu> Message-ID: <861201162542.1.SOLEY@CHERRY.LCS.MIT.EDU> Date: 1 Dec 1986 15:34-EST From: Sean.Engelson@cad.cs.cmu.edu To: common-lisp@su-ai Subject: Packages Message-Id: <533853280/spe@cad.cs.cmu.edu> This idea has probably been brought up before, but as a solution to the 'packages problem', without really any loos of functionality, I propose the following: To have symbols be universal, but their values and function definitions (maybe extended to all properties) be package-tied. Thus symbols are symbols and are EQ to each other in all the expectable cases, etc.., but we have the functionality of differing name spaces. This could be implemented by having a PACKAGE 'property' attached to different values of a symbol's property.. Pardon, but let me be the first to barf. Blech. Are you saying that (eql #'FOO:QUUX #'BAR:QUUX) => NIL, but (eql 'FOO:QUUX 'BAR:QUUX) => T ?? First (to say it politely) I don't see how your solution solves anything. Second, the more obvious solution of making (EQL 'FOO:QUUX 'BAR:QUUX) => T is (1) uneconomical, and (2) unteachable in the presence of (eql #'FOO:QUUX #'BAR:QUUX) => NIL. I don't think there's really a problem, and, if there is, I don't think this solves it. (Sorry for the legal reasoning in that sentence). -- Richard Soley  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 1 Dec 86 15:53:05 EST Received: from CAD.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 1 Dec 86 12:39:12 PST Date: 1 Dec 1986 15:34-EST From: Sean.Engelson@cad.cs.cmu.edu To: common-lisp@su-ai Subject: Packages Message-Id: <533853280/spe@cad.cs.cmu.edu> This idea has probably been brought up before, but as a solution to the 'packages problem', without really any loos of functionality, I propose the following: To have symbols be universal, but their values and function definitions (maybe extended to all properties) be package-tied. Thus symbols are symbols and are EQ to each other in all the expectable cases, etc.., but we have the functionality of differing name spaces. This could be implemented by having a PACKAGE 'property' attached to different values of a symbol's property..  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 1 Dec 86 13:05:15 EST Received: from UR-ACORN.ARPA by SAIL.STANFORD.EDU with TCP; 1 Dec 86 09:53:55 PST Received: from CASHEW.CS.ROCHESTER.EDU (CASHEW.CS.ROCHESTER.EDU) by ACORN.CS.ROCHESTER.EDU via INTERNET with SMTP id 2690; 1 Dec 86 12:51:52 EST Date: Mon, 1 Dec 86 12:53 EST From: Brad Miller Subject: eval and other topics To: Kent M Pitman cc: Common-Lisp@SU-AI.ARPA, miller@ACORN.CS.ROCHESTER.EDU In-Reply-To: <861126170437.1.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> Message-ID: <861201125315.0.MILLER@CASHEW.CS.ROCHESTER.EDU> Sender: miller@ACORN.CS.ROCHESTER.EDU Reply-To: miller@ACORN.CS.ROCHESTER.EDU Organization: University of Rochester, Department of Computer Science Postal-address: 617 Hylan Building, University of Rochester, Rochester NY 14627 Phone: 716-275-7747 Date: Wed, 26 Nov 86 17:04 EST From: Kent M Pitman Date: Wed, 26 Nov 86 15:50 EST From: Brad Miller ... While I certainly concur that a lexical eval is not a particularly good idea as far as a compiler writer is concerned (because it is very hard, and very inefficient), I think it is a TERRIFIC idea for USERS. I've needed the functionality several times, and each workaround is a total hack that has to be explained in about a page of extra documentation so the next poor slob that has to maintain my code can figure out why I wrote such dreadful code in the first place (and what it does). ... I (and I'm sure others on this list) would be very interested to see a sketch, explanation, or example of a place where you think LEXICAL-EVAL was essential. Personally, I can think of no places (other than in debuggging or situations closely related to debugging) where it was either essential or even appropriate. [....] Well, it's been a while since I gave up on doing things that way, so I don't have any code handy, but the idea was that given lexical scoping, one can then define functions with precisely defined scope rules, e.g. using flet. However, once I had defined these functions, I could not use eval on them, since they were invisible to the dynamic environment. The details of why I was trying to do this (seemingly) reasonable thing are hazy, but as I recall in one case, there were some functions (axioms for a horne clause theorem prover) that were evaluated normally by some routines that would 'interpret' the language by calling the routines by prefixing them with a string (to prevent name conflicts with CL functions). This was the hack - the better solution was to temporarily redefine these functions using flet so the threaded language could be interpreted directly, without globally redefining the lisp function. Since which function had to be called varied somewhat by context (modeled by which function actually did the interpretation) the same name could serve for each of these flets - since lexical scoping would not be ambiguous. Instead, with all functions globably defined, different strings were hacked into the pseudo-function call names, and then the (new) lisp stream could be eval'd. There may well be a better hack than this (actually, I'm not the one who ended up writing it, but I suppose I am responsible for it), however, I don't think anything might have surpassed the simple and clean elegance of a lexical-eval. Brad Miller ------ miller@rochester.arpa miller@ur-acorn.arpa  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 30 Nov 86 03:33:35 EST Received: from AI.AI.MIT.EDU by SAIL.STANFORD.EDU with TCP; 30 Nov 86 00:26:49 PST Date: Sun, 30 Nov 86 03:26:23 EST From: Alan Bawden Subject: EVAL To: Common-Lisp@SU-AI.ARPA In-reply-to: Msg of Wed 26 Nov 86 11:10 est from mike%acorn at mit-live-oak.arpa Message-ID: <124500.861130.ALAN@AI.AI.MIT.EDU> Date: Wed, 26 Nov 86 11:10 est From: mike at acorn Date: Wed, 26 Nov 86 00:24:12 EST From: Alan Bawden ... How do you compile (defun bind-x-then-call-f (x f) (funcall f `(cons x x)))... I just write (defun bind-x-then-call-f (x f) (eval `(funcall ,f '(cons ,x ,x)))... I presume you mean this to be (defun bind-x-then-call-f (x f) (eval `(funcall ',f '(cons ',x ',x)))). The quotes prevent an extra evaluation I doubt you intended. You can't rewrite BIND-X-THEN-CALL-F this way because before your rewrite it was the case that: (bind-x-then-call-f 7 #'cadr) ==> X but afterwords: (bind-x-then-call-f 7 #'cadr) ==> (QUOTE 7)  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 29 Nov 86 00:58:42 EST Received: from LIVE-OAK.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 28 Nov 86 13:41:19 PST Received: from GOLD-HILL-ACORN.DialNet.Symbolics.COM (DIAL|DIAL|4925473) by MIT-LIVE-OAK.ARPA via DIAL with SMTP id 19439; 28 Nov 86 16:30:19-EST Received: from BOSTON.Gold-Hill.DialNet.Symbolics.COM by ACORN.Gold-Hill.DialNet.Symbolics.COM via CHAOS with CHAOS-MAIL id 45600; Wed 26-Nov-86 11:09:57-EST Date: Wed, 26 Nov 86 11:10 est Sender: mike@acorn To: ALAN@AI.AI.MIT.EDU From: mike%acorn@mit-live-oak.arpa Subject: EVAL Cc: mike%acorn@LIVE-OAK.LCS.MIT.EDU, common-lisp@SU-AI.ARPA, Fahlman@C.CS.CMU.EDU, Sean.Engelson@CAD.CS.CMU.EDU Date: Wed, 26 Nov 86 00:24:12 EST From: Alan Bawden Date: Tue, 25 Nov 86 02:36 est From: mike%acorn at mit-live-oak.arpa Date: Sat, 22 Nov 86 17:32 EST From: Alan Bawden ... This demonstrates that LEXICAL-EVAL would have to be a new special form, rather than simply a function. This same issue seems to come up over and over. Will someone tell me what is wrong with the following argument:... I'm not quite sure what your proposed source transformation was supposed to demonstrate. How do you compile (defun bind-x-then-call-f (x f) (funcall f `(cons x x))) given that anyone can do (bind-x-then-call-f 'foo #'lexical-eval)? I just write (defun bind-x-then-call-f (x f) (eval `(funcall ,f '(cons ,x ,x))) and do this (bind-x-then-call-f 'foo #'eval) instead, which is to say I don't bother compiling it at all. I see no difference semantically here. Is there a tougher example, possibly involving closures? ... mike beckerle.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 26 Nov 86 20:45:16 EST Received: from AI.AI.MIT.EDU by SAIL.STANFORD.EDU with TCP; 26 Nov 86 17:34:07 PST Date: Wed, 26 Nov 86 20:34:26 EST From: Alan Bawden Subject: EVAL To: common-lisp@SU-AI.ARPA Message-ID: <123881.861126.ALAN@AI.AI.MIT.EDU> Date: 26 Nov 1986 11:29-EST From: Sean.Engelson at cad.cs.cmu.edu Date: Wed, 26 Nov 86 00:24:12 EST From: Alan Bawden ... How do you compile... Yes, but given lexical-eval as a special form, you couldn't do that. Which is exactly why my original message said: Date: Sat, 22 Nov 86 17:32 EST From: Alan Bawden ... This demonstrates that LEXICAL-EVAL would have to be a new special form, rather than simply a function. Perhaps lexical-eval could substitute lexical values for the variables in its argument, then eval the result? Perhaps it could use the more or less the same evaluator the interpreter uses, passing it an environment constructed by the compiler from the lexically apparent entities surrounding the occurrence of the LEXICAL-EVAL form. In painful detail: (defmacro lexical-eval (foo) `(sys:internal-lexical-eval ,foo (sys:the-surrounding-lexical-environment))) Where SYS:INTERNAL-LEXICAL-EVAL is an ordinary function that is an implementation dependent entry into the interpreter, and SYS:THE-SURROUNDING-LEXICAL-ENVIRONMENT is a special form that causes the compiler to create and return an implementation dependent datastructure that the interpreter can use to access the variables, block names, tagbody tags, and macro definitions apparent at that location. It is -incorrect- that an occurrence of LEXICAL-EVAL hopelessly cripples the compiler's ability to compile the surrounding code. A possible expansion of (SYS:THE-SURROUNDING-LEXICAL-ENVIRONMENT) might be: (list (list :read 'x (lambda () x)) (list :setq 'x (lambda (v) (setq x v))) (list :read 'y (lambda () y)) (list :setq 'y (lambda (v) (setq y v))) (list :return-from 'top (lambda (v) (return-from top v))) (list :go 'loop (lambda () (go loop)))) where X and Y are the lexically apparent variables, and TOP and LOOP are the lexically apparent block names and tagbody tags respectively. This datastructure would give the interpreter all the access it needs to the environment in question. I hope that most Common Lisp compilers can -already- successfully compile the above expression. Yes, I have ignored a couple of issues here (like the representation of the macro definition environment, and the possibility of returning multiple values from a block), but I don't see any fatal flaws, only complications that don't belong in a brief message. I'm still not advocating anything, I'm just trying to make sure we all know what we are flaming about.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 26 Nov 86 17:25:23 EST Received: from [128.81.51.90] by SAIL.STANFORD.EDU with TCP; 26 Nov 86 14:06:58 PST Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by WAIKATO.S4CC.Symbolics.COM via CHAOS with CHAOS-MAIL id 77582; Wed 26-Nov-86 17:05:04 EST Date: Wed, 26 Nov 86 17:04 EST From: Kent M Pitman Subject: eval and other topics To: miller@ACORN.CS.ROCHESTER.EDU cc: kmp@SCRC-STONY-BROOK.ARPA, Common-Lisp@SU-AI.ARPA In-Reply-To: <861126155002.1.MILLER@CASHEW.CS.ROCHESTER.EDU> Message-ID: <861126170437.1.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> Date: Wed, 26 Nov 86 15:50 EST From: Brad Miller ... While I certainly concur that a lexical eval is not a particularly good idea as far as a compiler writer is concerned (because it is very hard, and very inefficient), I think it is a TERRIFIC idea for USERS. I've needed the functionality several times, and each workaround is a total hack that has to be explained in about a page of extra documentation so the next poor slob that has to maintain my code can figure out why I wrote such dreadful code in the first place (and what it does). ... I (and I'm sure others on this list) would be very interested to see a sketch, explanation, or example of a place where you think LEXICAL-EVAL was essential. Personally, I can think of no places (other than in debuggging or situations closely related to debugging) where it was either essential or even appropriate. I seriously doubt that I can be convinced that it is a "terrific" idea for users in any case. The whole point of lexicality is to allow static analysis. The whole-point of LEXICAL-EVAL is to allow a Turing-powerful piece of code to modify the lexical environment in arbitrary ways, potentially thwarting many (probably most) useful kinds of static analysis which one might contemplate. The compiler is not pathological here -- any tool which tried to do program understanding (including macros, translators, optimizers, and human programmers) would have to expect trouble in the face of this primitive. I don't find this prospect "terrific".  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 26 Nov 86 16:33:35 EST Received: from UR-ACORN.ARPA by SAIL.STANFORD.EDU with TCP; 26 Nov 86 13:07:58 PST Received: from CASHEW.CS.ROCHESTER.EDU (CASHEW.CS.ROCHESTER.EDU) by ACORN.CS.ROCHESTER.EDU via INTERNET with SMTP id 2622; 26 Nov 86 15:49:21 EST Date: Wed, 26 Nov 86 15:50 EST From: Brad Miller Subject: eval and other topics To: common-lisp@su-ai.arpa cc: miller@ACORN.CS.ROCHESTER.EDU Message-ID: <861126155002.1.MILLER@CASHEW.CS.ROCHESTER.EDU> Sender: miller@ACORN.CS.ROCHESTER.EDU Reply-To: miller@ACORN.CS.ROCHESTER.EDU Organization: University of Rochester, Department of Computer Science Postal-address: 617 Hylan Building, University of Rochester, Rochester NY 14627 Phone: 716-275-7747 A large number of arguments against doing feature X for a while have been along the lines of: We shouldn't do feature X because then the compiler becomes harder, and couldn't optimize the code as much. While this may certainly be true (though it is more likely that the compiler would have to detect the use of feature X and THEN not optimize the code as much), I think it completely avoids the much deeper issue. I am a user of lisp. I am not a compiler writer (now). I don't CARE if such and so is easily compilable. I use lisp because it lets me express my ideas more easily than other languages do. If we stifle the growth of CL toward the lisp USER's needs, we will have a very fast, very compilable language that no one will want to use. I think that the questions that need to be asked when feature X is proposed is 1) is it a real problem? is there a simple mechanism that already exists to address the problem? If the proposal is syntactic sugar is it of the form that will allow program writers greater perspicuity? 2) does the proposed solution actually address the problem generically, or does it only address some instance? 3) can the solution be implemented at all? 4) is it reasonably upwards-compatible with the existing language? (not necessarily existing implementations). If not, is the scope of the change relatively small (will not require substantial rewrite of existing USER code, and/or the rewrite involved could be handled via a simple text transformation). 5) has the proposed solution actually been tried? Has it actually helped users who have run accross the problem? Does it otherwise constrain them? Is it intuitive? (i.e. is it something that seems to "fit" the language - nebulous I know, but this is an intuitive description too. Something like is it in the style of Lisp.) If the answers to the above are satisfactory, then I think there is a reasonably good case for adding the feature to the language. Minor difficulties like requiring smarter compilers, substantial rewrites to existing compilers, etc. is a complete side issue, I think. Mostly because if adding feature X allows a reasonable increase in USER productivity, who cares how much time it takes the COMPILER writer to implement it - that time is amortized over all the users who are now saving time with the new feature (or at least able to express themselves more clearly in CL, or whatever). Flames? Comments? Brad Miller PS: I bring this up because I mentioned the EVAL thing privately to Fahlman a few months ago back when he was controlling new discussion, and basically got back his original posting on the subject. While I certainly concur that a lexical eval is not a particularly good idea as far as a compiler writer is concerned (because it is very hard, and very inefficient), I think it is a TERRIFIC idea for USERS. I've needed the functionality several times, and each workaround is a total hack that has to be explaned in about a page of extra documentation so the next poor slob that has to maintain my code can figure out why I wrote such dreadful code in the first place (and what it does). ------ miller@rochester.arpa miller@ur-acorn.arpa  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 26 Nov 86 11:51:12 EST Received: from SCRC-YUKON.ARPA by SAIL.STANFORD.EDU with TCP; 26 Nov 86 08:34:07 PST Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by YUKON.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 126346; Wed 26-Nov-86 11:31:57 EST Date: Wed, 26 Nov 86 11:31 EST From: Kent M Pitman Subject: EVAL To: ALAN@AI.AI.MIT.EDU cc: mike%acorn@LIVE-OAK.LCS.MIT.EDU, common-lisp@SU-AI.ARPA, Fahlman@C.CS.CMU.EDU, Sean.Engelson@CAD.CS.CMU.EDU In-Reply-To: <123570.861126.ALAN@AI.AI.MIT.EDU> Message-ID: <861126113148.9.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> Date: Wed, 26 Nov 86 00:24:12 EST From: Alan Bawden Subject: EVAL To: mike%acorn@LIVE-OAK.LCS.MIT.EDU cc: common-lisp@SU-AI.ARPA, Fahlman@C.CS.CMU.EDU, Sean.Engelson@CAD.CS.CMU.EDU In-reply-to: Msg of Tue 25 Nov 86 02:36 est from mike%acorn at mit-live-oak.arpa Message-ID: <123570.861126.ALAN@AI.AI.MIT.EDU> Date: Tue, 25 Nov 86 02:36 est From: mike%acorn at mit-live-oak.arpa Date: Sat, 22 Nov 86 17:32 EST From: Alan Bawden ... This demonstrates that LEXICAL-EVAL would have to be a new special form, rather than simply a function. This same issue seems to come up over and over. Will someone tell me what is wrong with the following argument: I see no reason for "lexical-eval" or any eval with an environment arg. The following is a trivial source-to-source you can use to get the effect of a lexical eval: Suppose you wanted (defun foo (s-exp) (let ((x 5)) (flet ((bar (y) (+ x y))) (block here (tagbody :there (lexical-eval s-exp)))))) this is exactly equivalent to: (defun foo (s-exp) (eval `(let ((x 5)) (flet ((bar (y) (+ x y))) (block here (tagbody :there ,s-exp)))))) which does not use any "lexical-eval". Since the primary effect of the compiler is to eliminate lexical environments, any lexical "stuff" surrounding a call to "lexical-eval" can't really be compiled (not much anyway) since it all might be referred to by the s-expression being evaled. This being the case, the second form here, which just eval's the entire lexical scope, is roughly as efficient. No, it's -roughly- equivalent to: (defun foo (s-exp) (eval `(let ((s-exp ',s-exp)) (let ((x 5)) (flet ((bar (y) (+ x y))) (block here (tagbody :there ,s-exp))))))) and even then it doesn't address the issue of what happens if S-EXP contains code that destructively modifies the list structure in the object held by S-EXP. My rewrite, which at least appropriately binds the variable S-EXP, makes that be well-behaved, which is not a semantics-preserving transformation. I'm not quite sure what your proposed source transformation was supposed to demonstrate. How do you compile (defun bind-x-then-call-f (x f) (funcall f `(cons x x))) given that anyone can do (bind-x-then-call-f 'foo #'lexical-eval)? Right. Your remark about how this could be done as a special form thwarts the ability to do this (since you can't do #') and hides the potential problem in a fortuitous way. The real issue, of course, is that this is the power people -want-. They want things like EVAL-IN-CLOSURE, which are the problemsome cases, because the introduction of such into the language ties the hands of the compiler and doesn't allow any optimization. I think Mike's intent is correct, though, in that the situations where you might want LEXICAL-EVAL in cases that are constrained adequately so as not to break the language are handled adequately by his suggested rewrite using EVAL. The cases that are not handled by that rewrite -- and not at all by coincidence -- are the cases which strike fear in the hearts of compiler maintainers everywhere. Moreover, using LEXICAL-EVAL invites many of the name collision problems that the move to lexical scoping did away with. (DEFUN F (X Y) (+ X (EVAL Y))) used to be a problem in dynamic lisps because the local X and Y would interfere with the EVAL (at least in the interpreter and also in some compilers). In a lexical Lisp, such as CL, the name collision problem doesn't happen. Allowing people to do LEXICAL-EVAL there is just asking for the same unwanted name collisions that we were trying to get away with in CL. I concur with those who have said we should explicitly document the rationale for the absence of this primitive in the next CL language spec.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 26 Nov 86 11:47:09 EST Received: from CAD.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 26 Nov 86 08:34:05 PST Date: 26 Nov 1986 11:29-EST From: Sean.Engelson@cad.cs.cmu.edu To: Alan Bawden cc: common-lisp@su-ai.arpa Subject: Re: EVAL Message-Id: <533406551/spe@cad.cs.cmu.edu> In-Reply-To: Alan Bawden's mail message of Wed, 26 Nov 86 00:24:12 EST >Date: Wed, 26 Nov 86 00:24:12 EST From: Alan Bawden Subject: EVAL I'm not quite sure what your proposed source transformation was supposed to demonstrate. How do you compile (defun bind-x-then-call-f (x f) (funcall f `(cons x x))) given that anyone can do (bind-x-then-call-f 'foo #'lexical-eval)? Yes, but given lexical-eval as a special form, you couldn't do that. Perhaps lexical-eval could substitute lexical values for the variables in its argument, then eval the result? -Sean-  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 26 Nov 86 00:38:27 EST Received: from AI.AI.MIT.EDU by SAIL.STANFORD.EDU with TCP; 25 Nov 86 21:24:09 PST Date: Wed, 26 Nov 86 00:24:12 EST From: Alan Bawden Subject: EVAL To: mike%acorn@LIVE-OAK.LCS.MIT.EDU cc: common-lisp@SU-AI.ARPA, Fahlman@C.CS.CMU.EDU, Sean.Engelson@CAD.CS.CMU.EDU In-reply-to: Msg of Tue 25 Nov 86 02:36 est from mike%acorn at mit-live-oak.arpa Message-ID: <123570.861126.ALAN@AI.AI.MIT.EDU> Date: Tue, 25 Nov 86 02:36 est From: mike%acorn at mit-live-oak.arpa Date: Sat, 22 Nov 86 17:32 EST From: Alan Bawden ... This demonstrates that LEXICAL-EVAL would have to be a new special form, rather than simply a function. This same issue seems to come up over and over. Will someone tell me what is wrong with the following argument:... I'm not quite sure what your proposed source transformation was supposed to demonstrate. How do you compile (defun bind-x-then-call-f (x f) (funcall f `(cons x x))) given that anyone can do (bind-x-then-call-f 'foo #'lexical-eval)?  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 25 Nov 86 23:29:00 EST Received: from LIVE-OAK.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 25 Nov 86 20:05:28 PST Received: from GOLD-HILL-ACORN.DialNet.Symbolics.COM (DIAL|DIAL|4925473) by MIT-LIVE-OAK.ARPA via DIAL with SMTP id 19003; 25 Nov 86 19:02:40-EST Received: from BOSTON.Gold-Hill.DialNet.Symbolics.COM by ACORN.Gold-Hill.DialNet.Symbolics.COM via CHAOS with CHAOS-MAIL id 45101; Tue 25-Nov-86 02:35:23-EST Date: Tue, 25 Nov 86 02:36 est Sender: mike@acorn To: Alan@AI.AI.MIT.EDU From: mike%acorn@mit-live-oak.arpa Subject: EVAL Cc: Fahlman@C.CS.CMU.EDU, Sean.Engelson@CAD.CS.CMU.EDU, common-lisp@SU-AI.ARPA Date: Sat, 22 Nov 86 17:32 EST From: Alan Bawden Date: Thu, 20 Nov 1986 16:19 EST From: "Scott E. Fahlman" EVAL cannot easily be defined to work in the lexical environment in which it appears because that lexical environment is not around at runtime,.... Right. This demonstrates that LEXICAL-EVAL would have to be a new special form, rather than simply a function. This same issue seems to come up over and over. Will someone tell me what is wrong with the following argument: I see no reason for "lexical-eval" or any eval with an environment arg. The following is a trivial source-to-source you can use to get the effect of a lexical eval: Suppose you wanted (defun foo (s-exp) (let ((x 5)) (flet ((bar (y) (+ x y))) (block here (tagbody :there (lexical-eval s-exp)))))) this is exactly equivalent to: (defun foo (s-exp) (eval `(let ((x 5)) (flet ((bar (y) (+ x y))) (block here (tagbody :there ,s-exp)))))) which does not use any "lexical-eval". Since the primary effect of the compiler is to eliminate lexical environments, any lexical "stuff" surrounding a call to "lexical-eval" can't really be compiled (not much anyway) since it all might be referred to by the s-expression being evaled. This being the case, the second form here, which just eval's the entire lexical scope, is roughly as efficient. ...mike beckerle Gold Hill Computers.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 25 Nov 86 00:52:52 EST Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 24 Nov 86 21:34:10 PST Received: by navajo.stanford.edu; Mon, 24 Nov 86 21:31:53 PST Received: from bhopal.edsel.uucp by edsel.uucp (2.2/SMI-2.0) id AA18149; Mon, 24 Nov 86 19:39:31 pst Received: by bhopal.edsel.uucp (1.1/SMI-3.0DEV3) id AA05886; Mon, 24 Nov 86 19:38:38 PST Date: Mon, 24 Nov 86 19:38:38 PST From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White) Message-Id: <8611250338.AA05886@bhopal.edsel.uucp> To: navajo!sandra%utah-orion%utah-cs.arpa@navajo.stanford.edu Cc: navajo!common-lisp%su-ai.arpa@navajo.stanford.edu In-Reply-To: navajo!sandra%utah-orion@utah-cs.arpa's message of Mon, 24 Nov 86 14:00:10 MST Subject: hash table question SXHASH has the contract of returning the same value on things that "print alike". This is implicit in the definition of sxhash that says: "(equal x y) implies (= (sxhash x) (sxhash y))". [See CLtL p285; also the rule-of-thumb definition of EQUAL on p80.] In your example, you have two items which are EQ but not EQUAL [wait, read the rest before you judge this a contradiction]. Since they are not equal, you can't expect them to have the same sxhash values. The "two items" involved are two readings of the same "memory cell" at different times. Since it is "the same memory cell", the two items are EQ; but since an intrusive update occured during the time between the the two readings, "they" are no longer equal. I find it somewhat curious that the following dumb definition perfectly satisfies CLtL's requirements for SXHASH: (defun sxhash (x) 5) and this definition would give you the before/after equivalence you are asking about. How SXHASH differs fundamentally from the non-Common-Lisp function %POINTER available in ZetaLisp (or the LOC in Interlisp) is that it must be independent of the address of a "memory cell", if any, holding the object. CLtL tries to say this with language like "incarnation" and "core image". But, note how well the above dumb definition of sxhash satisfies this independence criterion! On the other hand, 5 really isn't a very good hashing function. It would give very poor distribution if it were the basis of gethash -- all entries would be in the same collision chain -- so it seems reasonable to descend into structures, even updatable structures, and compute a value that is, by design, potentially different after the object is updated. The value returned by %POINTER (and LOC) wouldn't be affected by the RPLACA in your example, but they have other problems: (1) they don't have the "equal[x,y] ==> sxhash[x] = sxhash[y]" property mentioned above, and (2) they don't remain the same over a relocating gc or a generational scavenge. If your point in asking this question is to examine the semantics of EQ-type hash tables, then I think there is general consensus that EQ-type tables don't simply mean that the "test" is EQ (as opposed to EQUAL), but that the collision chains are based upon the object "address" rather than the object "contents". EQ-testing hash tables with collision chains built the other way are certainly conceivable, but one wonders what value they would be. As I surmised in a previous note to this community, there is an unfortunate tendency to think that EQ-tables are "much faster" than EQUAL-tables, and the semantically wrong choice of :test is often made because of a mistaken conception about performance. [A typical place where EQ-type tables *are* indeed the correct choice is in circularity detection, or possibly in macro- expansion caches like MACROMEMO of MacLisp and CLISPARRAY of Interlisp]. This may also explain why there hasn't been a greater interest in opening up an independent :sxhash argument to MAKE-HASH-TABLE; EQ-type tables are only really useful when it is the "address" of the key that is important (rather than its contents), so suppying some other :sxhash argument wouldn't be as useful as the built-in %POINTER. Also, most people are reluctant to admit %POINTER/LOC as a primitive in the language since it is so deeply affected by memory-management strategy. -- JonL --  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 25 Nov 86 00:50:51 EST Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 24 Nov 86 21:30:39 PST Received: by navajo.stanford.edu; Mon, 24 Nov 86 21:28:23 PST Received: from bhopal.edsel.uucp by edsel.uucp (2.2/SMI-2.0) id AA18138; Mon, 24 Nov 86 19:37:15 pst Received: by bhopal.edsel.uucp (1.1/SMI-3.0DEV3) id AA05882; Mon, 24 Nov 86 19:36:21 PST Date: Mon, 24 Nov 86 19:36:21 PST From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White) Message-Id: <8611250336.AA05882@bhopal.edsel.uucp> To: navajo!sandra%utah-orion%utah-cs.arpa@navajo.stanford.edu Cc: navajo!common-lisp%su-ai.arpa@navajo.stanford.edu In-Reply-To: navajo!sandra%utah-orion@utah-cs.arpa's message of Wed, 19 Nov 86 09:11:01 MST Subject: type-of I had once thought of using TYPE-OF in the situation where I knew something was a defstruct, but didn't know it's name/type; however, just knowing that something is an instance of a defstruct isn't a portable question right now. Wasn't there a suggestion some time ago to have a new primitive function (or functions) for asking just these kinds of questions; i.e., is an object an instance of a structure defined without the :type option? and if so, what is its type name? -- JonL --  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 24 Nov 86 23:13:03 EST Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 24 Nov 86 19:59:27 PST Received: ID ; Mon 24 Nov 86 22:58:59-EST Date: Mon, 24 Nov 1986 22:58 EST Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: sandra%utah-orion@utah-cs.arpa (Sandra J Loosemore) Cc: common-lisp@SU-AI.ARPA Subject: hash table question In-reply-to: Msg of 24 Nov 1986 16:00-EST from sandra%utah-orion at utah-cs.arpa (Sandra J Loosemore) The hashing obviously will be messed up if you make destructive changes that would alter the key under which things are hashed. If you have things stored in an EQ hash table and you change the datum in such a way that the resulting objects are still EQ, things should still work. Ditto if you have a EQUAL hash-table and change an entry in some way that leaves it EQUAL to what it was before. But if you sneak in and change some list element from 3 to 'foo, the datum would no longer be hashed properly and you can only win if you remove the datum and then re-enter it into the hash-table. -- Scott  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 24 Nov 86 20:47:23 EST Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 24 Nov 86 17:24:53 PST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 8947; Mon 24-Nov-86 20:21:45 EST Date: Mon, 24 Nov 86 20:21 EST From: David A. Moon Subject: Re: hash table question To: Sandra J Loosemore cc: common-lisp@SU-AI.ARPA In-Reply-To: <8611250031.AA22562@utah-orion.ARPA> Message-ID: <861124202145.5.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Mon, 24 Nov 86 17:31:28 MST From: sandra%utah-orion@utah-cs.arpa (Sandra J Loosemore) Date: Mon, 24 Nov 86 18:39 EST From: Daniel L. Weinreb No, it doesn't always return true. sxhash is an "equal" hash, returning the same value for equal structures, even if they're not eq. Fine. So what happens if the cons I just clobbered was being used as a key in an "eq" hash table? Certainly the original cons is still "eq" to itself after it's been clobbered. Does this mean that an "eq" hash table *can't* look at the contents of an object to compute a hash index? (Actually, I can't think of any reason why one would *want* to perform destructive operations on an object that is being used as a hash key, and would be happy to see this made "an error".) Suppose you're doing object-oriented programming, and you're an old-line Lisp type who didn't make it past chapter 16 of CLtL, so you're implementing your objects as conses. Suppose the car of each cons is the class, while the cdr of each cons is a property-list containing the local state. Then it would be quite reasonable to simultaneously use these objects as :test 'eq hash-table keys and to perform destructive operations on them. The hashing, with :test 'eq, is using the object's identity as the key, not using the object's contents as the key. Thus I think the answer is that an "eq" hash table must not look at the contents of an object when it hashes. This could all be explained a whole lot better in the manual (although the language on p.282, distinguishing tables that hash on objects from tables that hash on tree structure, was probably intended to be the explanation of this.)  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 24 Nov 86 19:44:49 EST Received: from UTAH-CS.ARPA by SAIL.STANFORD.EDU with TCP; 24 Nov 86 16:30:28 PST Received: by utah-cs.ARPA (5.31/4.40.2) id AA28782; Mon, 24 Nov 86 17:31:32 MST Received: by utah-orion.ARPA (5.31/4.40.2) id AA22562; Mon, 24 Nov 86 17:31:28 MST Date: Mon, 24 Nov 86 17:31:28 MST From: sandra%utah-orion@utah-cs.arpa (Sandra J Loosemore) Message-Id: <8611250031.AA22562@utah-orion.ARPA> Subject: Re: hash table question To: Daniel L. Weinreb Cc: sandra%utah-orion@utah-cs.arpa, common-lisp@su-ai.arpa In-Reply-To: Daniel L. Weinreb , Mon, 24 Nov 86 18:39 EST Date: Mon, 24 Nov 86 18:39 EST From: Daniel L. Weinreb No, it doesn't always return true. sxhash is an "equal" hash, returning the same value for equal structures, even if they're not eq. Fine. So what happens if the cons I just clobbered was being used as a key in an "eq" hash table? Certainly the original cons is still "eq" to itself after it's been clobbered. Does this mean that an "eq" hash table *can't* look at the contents of an object to compute a hash index? (Actually, I can't think of any reason why one would *want* to perform destructive operations on an object that is being used as a hash key, and would be happy to see this made "an error".) -Sandra -------  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 24 Nov 86 18:54:51 EST Received: from [192.10.41.109] by SAIL.STANFORD.EDU with TCP; 24 Nov 86 15:43:14 PST Received: from CHICOPEE.SCRC.Symbolics.COM by ALDERAAN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 23873; Mon 24-Nov-86 18:41:14 EST Date: Mon, 24 Nov 86 18:39 EST From: Daniel L. Weinreb Subject: hash table question To: sandra%utah-orion@UTAH-CS.ARPA, common-lisp@SU-AI.ARPA In-Reply-To: <8611242100.AA21161@utah-orion.ARPA> Message-ID: <861124183912.0.DLW@CHICOPEE.SCRC.Symbolics.COM> No, it doesn't always return true. sxhash is an "equal" hash, returning the same value for equal structures, even if they're not eq. So the idea is that it does a tree walk and computes its number out of what it finds in the leaves. Since you've changed a leaf and it is no longer "equal" to what it used to be, it can have a new sxhash value, and probably does. This could have been spelled out in more detail in CLtL.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 24 Nov 86 16:13:35 EST Received: from UTAH-CS.ARPA by SAIL.STANFORD.EDU with TCP; 24 Nov 86 12:59:06 PST Received: by utah-cs.ARPA (5.31/4.40.2) id AA19611; Mon, 24 Nov 86 14:00:13 MST Received: by utah-orion.ARPA (5.31/4.40.2) id AA21161; Mon, 24 Nov 86 14:00:10 MST Date: Mon, 24 Nov 86 14:00:10 MST From: sandra%utah-orion@utah-cs.arpa (Sandra J Loosemore) Message-Id: <8611242100.AA21161@utah-orion.ARPA> Subject: hash table question To: common-lisp@su-ai.arpa Is hashing supposed to "work" if destructive operations are performed on the hashed object, or is the hash index computed for an object a function of what's "in" the object rather than the object itself? As an example, does this bit of code always return true? (let* ((cons (cons 'a 'b)) (before (sxhash cons)) (after (sxhash (rplaca cons 'foobar)))) (eql before after)) -Sandra -------  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 24 Nov 86 14:51:02 EST Received: from LIVE-OAK.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 24 Nov 86 11:34:50 PST Received: from GOLD-HILL-ACORN.DialNet.Symbolics.COM by MIT-LIVE-OAK.ARPA via DIAL with SMTP id 18517; 24 Nov 86 13:57:23-EST Received: from BOSTON.Gold-Hill.DialNet.Symbolics.COM by ACORN.Gold-Hill.DialNet.Symbolics.COM via CHAOS with CHAOS-MAIL id 44996; Fri 21-Nov-86 11:39:30-EST Date: Fri, 21 Nov 86 11:39 est Sender: mike@acorn To: a37078%ccut.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET From: mike%gold-hill-acorn@mit-live-oak.arpa Subject: question: EVAL Cc: common-lisp@SU-AI.ARPA, ida%u-tokyo.junet@RELAY.CS.NET Date: Fri, 21 Nov 86 17:49:44+0900 From: Masayuki Ida In the list of GLS, there is an EVAL extension to have an optional argument for 'environment'. will it be defined in the comming specification ? Is this only one argument ? Does the value of this optional 'environmental' argument have a defined syntax/semantics ? ida I have no qualms at all about adding the ability to address the current macro-expansion environment, and to pass it to eval. I have real difficulty with the ability to pass the complete lexical environment.I think the issue of whether to add complete environments for eval is one of the more controvercial ones in "the list of GLS". Having the ability to pass a lexical environment assumes the ability to access the lexical environment. There is currently no way to access this, it is implicitly passed by eval to evalhooks, and so on. Let me assume that you also want a way to access the current lexical environment, say by a function (get-current-env). I think any code which uses this environment would be impossible to compile, in the sense that the compiler probably couldn't do much with it. This would hold for the entire body of lexically surrounding code. For example: (defun wierd-function (s-expression) (block here (tagbody :tag (let ((x (foo s-expression))) (labels ((bar (y) (+ x y))) (eval s-exp (get-current-env))))))) The s-expression could draw on any of the environment here, so we can't optimize anything out of the environment. We can achieve the desired effect by writing: (defun wierd-function (s-expression) (eval `(block here (tagbody :tag (let ((x (foo s-expression))) (labels ((bar (y) (+ x y))) ,@s-exp)) Which is probably just about as good as the compiler could do anyway and doesn't use any environments. ...mike beckerle Gold Hill Computers  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 23 Nov 86 18:48:04 EST Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 23 Nov 86 15:38:39 PST Received: from Cabernet.ms by ArpaGateway.ms ; 23 NOV 86 15:38:36 PST Date: 23 Nov 86 15:38 PST From: Masinter.pa@Xerox.COM Subject: Re: (typep 3 'complex) => t In-reply-to: Rob MacLachlan 's message of Sun, 23 Nov 86 17:32 EST To: RAM@C.CS.CMU.EDU cc: common-lisp@SU-AI.ARPA Message-ID: <861123-153836-2807@Xerox> why don't you use (deftype complex-number (&optional type) (if type `(or ,type (complex ,type)) '(or rational complex))) e.g., (declare (type complex-number x)) means that either X is strictly complex or else a rational, while (declare (type (complex-number fixnum) x) means that either X is a fixnum or a (complex fixnum). It seems well within the bounds of the Common Lisp framework to use deftype to add types that are interesting to some compilers, without requiring that the types be added to every other implementation.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 23 Nov 86 17:42:57 EST Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 23 Nov 86 14:32:45 PST Received: ID ; Sun 23 Nov 86 17:32:41-EST Date: Sun, 23 Nov 1986 17:32 EST Message-ID: From: Rob MacLachlan To: Masinter.pa@XEROX.COM Cc: common-lisp@SU-AI.ARPA Subject: (typep 3 'complex) => t In-reply-to: Msg of 23 Nov 1986 17:13-EST from Masinter.pa at Xerox.COM But under my interpretation, (DECLARE (COMPLEX FIXNUM)) would be much more useful, since the it would be a declaration that the user could reasonably make, yet would give the system the useful information that both the realpart and imagpart are fixnums. In this case, the compiler could reasonably store the realpart and imagpart as separate fixnums, and would only have to canonicalize them when it is forced to pointerize the number. In the case of a float component type, there is no difference in the results of the two interpretations, since complex float types are not canonicalized. I think that the definition of complex rational types was not thoroughly thought out due to their novelty. If there were no RATIONAL type, then it would make sense to argue that COMPLEX should be useless by analogy with RATIO, but if we are trying to provide a useful type system, then it is silly. Perhaps COMPLEX should remain what everyone thought it was, but there is definitely a need for the type that I think COMPLEX ought to be. I think that there is a strong argument that my interpretation should get the "good" name, since it is what people will usually want to use. Rob  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 23 Nov 86 17:22:46 EST Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 23 Nov 86 14:13:45 PST Received: from Cabernet.ms by ArpaGateway.ms ; 23 NOV 86 14:13:43 PST Date: 23 Nov 86 14:13 PST From: Masinter.pa@Xerox.COM Subject: Re: (typep 3 'complex) => t In-reply-to: Rob MacLachlan 's message of Sun, 23 Nov 86 15:36 EST To: RAM@C.CS.CMU.EDU cc: common-lisp@SU-AI.ARPA Message-ID: <861123-141343-2764@Xerox> I'd thought all along that the COMPLEX type was intended to be the analog of RATIO, and not include those numbers which canonicalized to RATIONAL. Your message seems to assert that the description on p 47 implies otherwise, but it seems more reasonable that this is just a case of ambiguous wording. You claim "Due to the rule for complex canonicalization, it makes no sense to require the non-0 imagpart, since it makes the declaration useless for complex numbers with rational components." But it does make sense, and such declarations are useful, (well, as useful as RATIO declarations) for example: (typecase x (rational ... ) (complex (locally (declare (type complex x)) ...) ...) where one could assume within the scope of the declaration that realpart and imagpart could be optimized, for example.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 23 Nov 86 15:44:06 EST Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 23 Nov 86 12:36:25 PST Received: ID ; Sun 23 Nov 86 15:36:20-EST Date: Sun, 23 Nov 1986 15:36 EST Message-ID: From: Rob MacLachlan To: common-lisp@SU-AI.ARPA Subject: (typep 3 'complex) => t There is a bit of type sysem lossage that I noticed lately which is unrelated to the TYPE-OF discussion. My realization is that RATIONAL is a subtype of (COMPLEX NUMBER), since according to p47, "...this type encompasses those complex numbers that can result from giving numbers of the specified type to the function COMPLEX." Of course, (COMPLEX 3 0) => 3. This interpretation depends on the meaning of the phrase "complex numbers" in the above passage. This interperetation does not hold if "complex number" in the above passage means a number where (NOT (EQL (IMAGPART number) 0)). Due to the rule for complex canonicalization, it makes no sense to require the non-0 imagpart, since it makes the declaration useless for complex numbers with rational components. It seems that there is an analogy between COMPLEX and RATIONAL due to the similarity of the complex and rational canonicalization rules. 3 is a rational, since a rational can be canonicalized to an integer. Similarly, 3 is a complex since a complex can be canonicalized to an integer. The real problem is that there is no type which is to COMPLEX as RATIO is to RATIONAL, i.e. a type that represents complex numbers that have not been canonicalized. If my intepretation is correct, then the COMPLEX type with no component type specified is effectively equivalent to (AND NUMBER (NOT FLOAT)). This makes the COMPLEXP function fairly useless if it continues to be equivalent to (TYPEP ... 'COMPLEX). There is some mumbling about "may be different for declaration and discrimination" in the definition of the COMPLEX type specifier, but close reading suggests that this is irrelevant to the issue at hand, since it is really attempting to say that COMPLEX types are similar to ARRAY types in that the implementation has freedom in choosing component type specializations. Comparison with the similar hemming and hawing in the ARRAY definition supports this conclusion. Rob  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 23 Nov 86 00:01:45 EST Date: 22 Nov 86 2054 PST From: Dick Gabriel Subject: GET-SETF-METHOD To: common-lisp@SAIL.STANFORD.EDU This issue comes up every 6-12 months. Most recently, on December 13, 1985, Steele proposed a clarification, which he lists as `serious': (*) 107 Clarify that GET-SETF-METHOD and GET-SETF-METHOD-MULTIPLE-VALUE do not perform macro-expansion on the given form, and that in most contexts the usage should be (GET-SETF-METHOD (MACROEXPAND form env)). Indeed, the simplified example version of SETF given on page 108 should be changed to: Nine hours and 31 minutes later, Rob MacLachlan pointed out that this would not work because of setf methods. Two days, 11 hours, and 49 minutes later, Steele agreed. In the meantime, on December 14, 1985, Eric Benson pointed out that DEFINE-SETF-METHOD also needed an environment passed. On July 19 Plummer noticed it himself, and MacLachlan affirmed this observation. Several vendors made the change because it seemed a clear case of a mistake in the language rather than a clarification. I would say that VaxLisp and ExCL are not in error, but the usefulness of MACROLET is limited without this change. -rpg-  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 22 Nov 86 23:58:57 EST Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 22 Nov 86 20:51:54 PST Received: ID ; Sat 22 Nov 86 23:51:50-EST Date: Sat, 22 Nov 1986 23:51 EST Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: franz!ficl!jkf@ucbarpa.Berkeley.EDU (John Foderaro) Cc: COMMON-LISP@SU-AI.ARPA Subject: Macrolet and setf In-reply-to: Msg of 22 Nov 1986 21:52-EST from franz!ficl!jkf at ucbarpa.Berkeley.EDU (John Foderaro) >> (defun abc (n) >> (macrolet ((mmm (z) `(gethash ,z *bob*))) >> (setf (mmm n) 5))) I believe that the preceeding should be permitted, but it requires that get-setf-method be permitted to take a second, environment, argument. Such a change may have already been proposed. You're right, that's what it takes, and this change has already been proposed. It seemed pretty clear to everyone that this change was required in order for SETF of macros to work properly, so a number of implementations went ahead and added it (as an optional arg), even though there has been no mechanism whereby this change could be adopted officially. -- Scott  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 22 Nov 86 22:40:02 EST Received: from UCBARPA.Berkeley.EDU by SAIL.STANFORD.EDU with TCP; 22 Nov 86 19:32:14 PST Received: by ucbarpa.Berkeley.EDU (5.57/1.18) id AA14358; Sat, 22 Nov 86 19:32:14 PST Received: from ficl by franz (5.5/3.14) id AA22968; Sat, 22 Nov 86 18:51:35 PST Received: by ficl (5.5/3.14) id AA08389; Sat, 22 Nov 86 18:52:05 PST From: franz!ficl!jkf@ucbarpa.Berkeley.EDU (John Foderaro) Return-Path: Message-Id: <8611230252.AA08389@ficl> To: ricks%shambhala.Berkeley.EDU@BERKELEY.EDU (Rick L Spickelmier) Cc: COMMON-LISP@su-ai.arpa Subject: Re: Macrolet and setf In-Reply-To: Your message of Sat, 22 Nov 86 15:04:00 PST. <8611222304.AA02560@shambhala.berkeley.edu> Date: Sat, 22 Nov 86 18:52:02 PST >> (defun abc (n) >> (macrolet ((mmm (z) `(gethash ,z *bob*))) >> (setf (mmm n) 5))) I believe that the preceeding should be permitted, but it requires that get-setf-method be permitted to take a second, environment, argument. Such a change may have already been proposed. -john foderaro franz inc.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 22 Nov 86 22:29:45 EST Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 22 Nov 86 19:22:16 PST Received: from Cabernet.ms by ArpaGateway.ms ; 22 NOV 86 19:21:22 PST Date: 22 Nov 86 19:21 PST From: Pavel.pa@Xerox.COM Subject: Re: Macrolet and setf In-reply-to: ricks%shambhala.Berkeley.EDU@BERKELEY.EDU (Rick L Spickelmier)'s message of 22 Nov 86 15:04 PST (Saturday) To: ricks%shambhala.Berkeley.EDU@BERKELEY.EDU cc: COMMON-LISP@su-ai.arpa Message-ID: <861122-192122-2541@Xerox> Date: 22 Nov 86 15:04 PST (Saturday) From: ricks%shambhala.Berkeley.EDU@BERKELEY.EDU (Rick L Spickelmier) Are macros defined with macrolet allowed as place forms in setf? I have tried the following in VAXLISP and EXCL with both reporting that 'mmm' can not be used as a place form (interpreted and compiled). (defun abc (n) (macrolet ((mmm (z) `(gethash ,z *bob*))) (setf (mmm n) 5))) I believe that VAXLISP and EXCL are both in error. Xerox, Lucid, and Symbolics all do this correctly. Pavel  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 22 Nov 86 21:28:19 EST Received: from REAGAN.AI.MIT.EDU by SAIL.STANFORD.EDU with TCP; 22 Nov 86 18:20:29 PST Received: from PIGPEN.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 12445; Sat 22-Nov-86 21:20:12 EST Date: Sat, 22 Nov 86 21:20 EST From: Alan Bawden Subject: Re: EVAL To: Pavel.pa@Xerox.COM cc: common-lisp@SU-AI.ARPA In-Reply-To: <861122-170037-2387@Xerox> Message-ID: <861122212008.0.ALAN@PIGPEN.AI.MIT.EDU> Date: 22 Nov 86 17:00 PST From: Pavel.pa@Xerox.COM Date: Sat, 22 Nov 86 17:32 EST From: Alan Bawden Right. This demonstrates that LEXICAL-EVAL would have to be a new special form, rather than simply a function. Even if it were a special form, what code could the compiler generate for it? Would the presence of such a special form require turning off all optimizations having to do with the lexical environment and cause the compiler to create some sort of run-time environment structure containing names and such? Yecch. That would seem to be what you have to do. The variables that are lexically apparent at the site of the LEXICAL-EVAL would have to be handled somewhat more carefully than ordinary lexical variables. Presumably by bundling them up into some kind of explicit environment structure. In Common Lisp you would also have to include the current function definitions established by FLET, the current BLOCK names and TAGBODY tags, and the current macro definitions established by MACROLET. Please note that I have yet to express an opinion about this.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 22 Nov 86 20:49:35 EST Received: from UCBVAX.Berkeley.EDU by SAIL.STANFORD.EDU with TCP; 22 Nov 86 17:42:53 PST Received: by ucbvax.Berkeley.EDU (5.53/1.18) id AA16854; Sat, 22 Nov 86 17:42:37 PST Received: by shambhala.berkeley.edu (4.12/5.6) id AA02560; Sat, 22 Nov 86 15:04:06 pst From: ricks%shambhala.Berkeley.EDU@BERKELEY.EDU (Rick L Spickelmier) Message-Id: <8611222304.AA02560@shambhala.berkeley.edu> Date: 22 Nov 1986 1504-PST (Saturday) To: COMMON-LISP@su-ai.arpa Subject: Macrolet and setf Are macros defined with macrolet allowed as place forms in setf? I have tried the following in VAXLISP and EXCL with both reporting that 'mmm' can not be used as a place form (interpreted and compiled). (defun abc (n) (macrolet ((mmm (z) `(gethash ,z *bob*))) (setf (mmm n) 5))) Rick Spickelmier UC Berkeley  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 22 Nov 86 20:08:36 EST Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 22 Nov 86 17:00:55 PST Received: from Cabernet.ms by ArpaGateway.ms ; 22 NOV 86 17:00:37 PST Date: 22 Nov 86 17:00 PST From: Pavel.pa@Xerox.COM Subject: Re: EVAL In-reply-to: Alan Bawden 's message of Sat, 22 Nov 86 17:32 EST To: Alan@AI.AI.MIT.EDU cc: common-lisp@SU-AI.ARPA Message-ID: <861122-170037-2387@Xerox> Date: Sat, 22 Nov 86 17:32 EST From: Alan Bawden Right. This demonstrates that LEXICAL-EVAL would have to be a new special form, rather than simply a function. Even if it were a special form, what code could the compiler generate for it? Would the presence of such a special form require turning off all optimizations having to do with the lexical environment and cause the compiler to create some sort of run-time environment structure containing names and such? Yecch. Pavel  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 22 Nov 86 17:41:01 EST Received: from REAGAN.AI.MIT.EDU by SAIL.STANFORD.EDU with TCP; 22 Nov 86 14:33:00 PST Received: from PIGPEN.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 12420; Sat 22-Nov-86 17:32:40 EST Date: Sat, 22 Nov 86 17:32 EST From: Alan Bawden Subject: EVAL To: Fahlman@C.CS.CMU.EDU cc: Sean.Engelson@CAD.CS.CMU.EDU, common-lisp@SU-AI.ARPA In-Reply-To: Message-ID: <861122173233.4.ALAN@PIGPEN.AI.MIT.EDU> Date: Thu, 20 Nov 1986 16:19 EST From: "Scott E. Fahlman" EVAL cannot easily be defined to work in the lexical environment in which it appears because that lexical environment is not around at runtime, when the argument to EVAL arrives and the evaluation occurs. In any event, it would eliminate many of the benefits of lexical scoping to provide a loophole through which arbitrary forms might be smuggled into a lexical environment at runtime. For example, certain optimization are now possible because the compiler can examine all possible references to a lexically-bound variable by scanning the lexical block in which it is bound; thsi would go away in the presence of your LEXICAL-EVAL.... Right. This demonstrates that LEXICAL-EVAL would have to be a new special form, rather than simply a function.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 21 Nov 86 20:06:00 EST Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 21 Nov 86 16:57:10 PST Received: ID ; Fri 21 Nov 86 19:57:05-EST Date: Fri, 21 Nov 1986 19:57 EST Message-ID: From: Rob MacLachlan To: "Robert W. Kerns" Cc: common-lisp@SU-AI.ARPA Subject: TYPE-OF In-reply-to: Msg of 21 Nov 1986 15:58-EST from Robert W. Kerns Date: Friday, 21 November 1986 15:58-EST From: Robert W. Kerns To: Rob MacLachlan Date: Fri, 21 Nov 1986 09:36 EST From: Rob MacLachlan ... I don't know exactly what you mean by a "type inferencer", but for the kinds of type inferences that I could conceive of a Lisp compiler wanting to do, you definitely want the *most specific* type, and certainly don't want to return random things such as FIXNUM which represent implementation details rather than language semantics. Eh? You're contradicting yourself. Nope, (INTEGER 3 3) is more specific than FIXNUM, which is after all just (INTEGER most-negative-fixnum most-positive-fixnum). Compilers deal directly with implementation, and that's why you want something more specific, such as FIXNUM, rather than something at the level of language semantics, such as INTEGER. I think you're trying to argue that you want something more specific still, but that's not TYPE-OF's job. What we are trying to determine is what TYPE-OF's jobs is. I introduced my compiler example, not necessarily because I thought that TYPE-OF should do what my CTYPE-OF does, but because I wanted to challenge Ida's contention that TYPE-OF was useful for type inference. I.e. I am still trying to home in on a valid use for TYPE-OF. The way that type inference is done by my compiler is irrelevant; I simply wanted to show that Ida's TYPE-OF is useless in my type inferencer. In a recent message, I oversimplified TYPEP, [...] This mostly works. However, this depends on TYPE-OF returning the most-specific type, so for any appropriate type for an object, TYPE-OF will return something at least as specific, and which SUBTYPEP can decide on. Let me assert at this point, without proof, that there is no such single type. The problem is that TYPE-OF is inherently an information-losing operation. [...] I think we are agreeing violently. My main disagreement with you is over whether there is a way to make TYPE-OF as strongly defined as you want without pointlessly constraining the implementation, and if so whether it is worth the bother (and core). People have written a number of programs without a well-defined TYPE-OF/SUBTYPEP. It is not clear we should foist additional overhead on Common Lisp just to make the semantics of a nearly useless operation esthetically appealing. Rob  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 21 Nov 86 18:31:23 EST Received: from UTAH-CS.ARPA by SAIL.STANFORD.EDU with TCP; 21 Nov 86 15:19:00 PST Received: by utah-cs.ARPA (5.31/4.40.2) id AA20321; Fri, 21 Nov 86 16:20:00 MST Received: by utah-orion.ARPA (5.31/4.40.2) id AA07808; Fri, 21 Nov 86 16:19:56 MST Date: Fri, 21 Nov 86 16:19:56 MST From: sandra%utah-orion@utah-cs.arpa (Sandra J Loosemore) Message-Id: <8611212319.AA07808@utah-orion.ARPA> Subject: Re: type-of To: Robert W. Kerns Cc: common-lisp@su-ai.arpa In-Reply-To: Robert W. Kerns , Fri, 21 Nov 86 14:46 EST Two comments on your comments. First of all, neither TYPE-OF or SUBTYPEP is necessary for implementing TYPEP. In fact, doing it that way is probably the most inefficient implementation possible. In PCLS, for example, all of the built-in types like INTEGER or SIMPLE-STRING have predicates associated with them that can be found by a quick lookup procedure, and there is special logic for handling the more complicated type specifiers like (ARRAY ...). I agree that TYPE-OF should not be thrown out just because nobody uses it much, *provided* that the function is there because it implements some functionality users could not easily implement themselves. For the uses of TYPE-OF that people have mentioned so far, this is not the case. Here is a portable, 3-line function that will check an object against whatever set of type specifiers I think are appropriate in this situation: (defun my-type-of (object possible-type-spec-list) (dolist (type possible-type-spec-list t) (if (typep object type) (return type)))) The only case where this would fail would be if I do not know in advance what type specifiers I want to see returned. Gee whiz! Isn't that what TYPE-OF is supposed to do now? :-) -Sandra -------  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 21 Nov 86 16:14:37 EST Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 21 Nov 86 12:59:48 PST Received: from WHITE-BIRD.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 6852; Fri 21-Nov-86 15:57:48 EST Date: Fri, 21 Nov 86 15:58 EST From: Robert W. Kerns Subject: TYPE-OF To: Rob MacLachlan cc: Masayuki Ida , common-lisp@SU-AI.ARPA, ida%u-tokyo.junet@RELAY.CS.NET In-Reply-To: Message-ID: <861121155855.7.RWK@WHITE-BIRD.SCRC.Symbolics.COM> Date: Fri, 21 Nov 1986 09:36 EST From: Rob MacLachlan Date: Wed, 19 Nov 86 23:41:56+0900 From: Masayuki Ida To: common-lisp at SU-AI.ARPA, ida%u-tokyo.junet at RELAY.CS.NET Re: TYPE-OF D-Eval concept needs TYPE-OF. kinds of type inferencing system will also need TYPE-OF to determine the type. Here is a conversation with D-Eval: D-Eval>(+ 1 2) 3 ; FIXNUM Well, if all D-Eval uses Type-Of for is to print out the type, then it doesn't really matter what it returns. I had in mind a fragment of code that needed to use Type-Of. I don't know exactly what you mean by a "type inferencer", but for the kinds of type inferences that I could conceive of a Lisp compiler wanting to do, you definitely want the *most specific* type, and certainly don't want to return random things such as FIXNUM which represent implementation details rather than language semantics. Eh? You're contradicting yourself. Compilers deal directly with implementation, and that's why you want something more specific, such as FIXNUM, rather than something at the level of language semantics, such as INTEGER. I think you're trying to argue that you want something more specific still, but that's not TYPE-OF's job. Now, if A is known (due to declaration) to be (array (unsigned-byte 8)), then I could combine the fact that 7 is (integer 7 7) with that information to determine that the result of the addition is (integer 262 7), which is probably a useful thing to know. If all that I know is that 7 is FIXNUM, then all bets are off. If all you have is TYPE-OF and SUBTYPEP, yes, that is true. If you don't want to throw away information, keep the original object. In a recent message, I oversimplified TYPEP, because I'm trying to stay out of certain issues better handled in a paper, where hopefully I can be more careful and verbose. So I lied a little. Let's consider that lie for a moment. (My apologies for presenting all of this in such a fragmentary way). In that other message, I defined TYPEP as (defun typep (object type) (subtypep (type-of object) type)) This mostly works. However, this depends on TYPE-OF returning the most-specific type, so for any appropriate type for an object, TYPE-OF will return something at least as specific, and which SUBTYPEP can decide on. Let me assert at this point, without proof, that there is no such single type. The problem is that TYPE-OF is inherently an information-losing operation. The pair TYPE-OF/SUBTYPEP is actually a special case of a more general matching process that I really don't want to go into right now. The key point, however, is that TYPEP actually does some things that SUBTYPEP can't, because it actually has the object. The same is true of your "type merger" for addition, which should look at the actual object when it has one, and not call TYPE-OF. I didn't mention this on the mailing list as a valid use of Type-Of, since: 1] The compiler *is* the implementation, so it doesn't matter if it is implementiaton dependent. 2] The version of Type-Of that I am using in the compiler is optimized to return what the compiler considers most interesting, rather than what the user might consider most informative. For example, given a symbol, it returns (member ). This is an interesting approach. It reduces TYPE-OF/SUBTYPEP to TYPEP!  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 21 Nov 86 15:46:48 EST Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 21 Nov 86 12:31:44 PST Received: from WHITE-BIRD.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 6790; Fri 21-Nov-86 15:29:36 EST Date: Fri, 21 Nov 86 15:30 EST From: Robert W. Kerns Subject: TYPE-OF To: Guy Steele cc: DLW@ALDERAAN.SCRC.Symbolics.COM, a37078%ccut.u-tokyo.junet%utokyo-relay.csnet@relay.cs.net, common-lisp@SU-AI.ARPA, ida%u-tokyo.junet@relay.cs.net In-Reply-To: <861120151614.4.GLS@HILARION.THINK.COM> Message-ID: <861121153042.6.RWK@WHITE-BIRD.SCRC.Symbolics.COM> Date: Thu, 20 Nov 86 15:16 EST From: Guy Steele One might want (TYPE-OF 2) => (INTEGER 2 2), or perhaps just (INTEGER 2) and define (INTEGER x) <=> (integer x x). But this does not seem to generalize nicely to other data types. If the goal is that TYPE-OF should return the most specific possible type, then clearly when applied to object x it should return (MEMBER x), as that is the most specific type that contains x. But this is not very useful, and therefore this goal is not what we really want. --Guy Right. That's why I proposed specifying a "least specific" type, saying that "it must be at least this specific". Combine this with the requirement that whatever is actually returned must be understood by SUBTYPEP (i.e. SUBTYPEP of that type and the "least specific" type specified must return T T).  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 21 Nov 86 15:05:25 EST Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 21 Nov 86 11:51:57 PST Received: from WHITE-BIRD.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 6714; Fri 21-Nov-86 14:44:48 EST Date: Fri, 21 Nov 86 14:46 EST From: Robert W. Kerns Subject: type-of To: Sandra J Loosemore cc: common-lisp@SU-AI.ARPA In-Reply-To: <8611191611.AA14790@utah-orion.ARPA> Supersedes: <861121144528.4.RWK@WHITE-BIRD.SCRC.Symbolics.COM> Message-ID: <861121144625.5.RWK@WHITE-BIRD.SCRC.Symbolics.COM> Date: Wed, 19 Nov 86 09:11:01 MST From: sandra%utah-orion@utah-cs.arpa (Sandra J Loosemore) From: RWK@YUKON.SCRC.Symbolics.COM (Robert W. Kerns) Date: 18 Nov 86 21:04:00 GMT Here is an example of completely-portable code which depends on TYPE-OF returning the MOST specific type. (defun store-in-array-if-fits (object array &rest indicies) (let ((object-type (type-of object)) (array-type (array-element-type array))) (if (subtypep object-type array-type) ;; If the object fits, store it (setf (apply #'aref array indicies) object) ;; Doesn't fit, so store 0 instead. (setf (apply #'aref array indicies) 0)))) Sorry, I can't buy this motivation. All this example illustrates is that there is a good reason for having the TYPEP function around. (defun typep (object type) (subtypep (type-of object) type)) Yes, my example is a bit oversimplified; I was more interested in demonstrating portability than necessity. And the "important half" of TYPEP is SUBTYPEP, not TYPE-OF. But TYPEP doesn't let you make the decision about the type separately from the object in question. As it happens, in PCLS, TYPE-OF does go through a considerable amount of work to find the most specific type that it can. So, (TYPE-OF 0) returns BIT, which is correct but largely useless. My "gut feeling" is that what the user probably wants is either FIXNUM or INTEGER -- something which indicates how the object is represented internally, or (in other words) one of the set of types which CLtL says are disjoint. If the user is writing his code properly, he is using type-comparison (i.e. SUBTYPEP), so he doesn't really care. But your "gut feeling" is right, he probably doesn't care about anything more specific than FIXNUM. That's why I think it would be advantagious to more precisely specify TYPE-OF. Right now the spec could be read as requiring (TYPE-OF 0) => BIT. If we specify a "least specific" type (FIXNUM in this case), than any implementation which returns something *at least* as specific as FIXNUM is fine. If an implementation has reason for being more specific, however, it should be free to do so. I'll have to agree that TYPE-OF as defined now is pretty bogus. The only place I've ever had reason to use TYPE-OF in real code was to get a type to pass to COERCE or CONCATENATE, etc., when I wanted to ensure that two objects were of the same type; for example, both lists or whatever. But this is full of holes, too. For example, (coerce '#(a b c) (type-of (list))) may fail, depending on whether your favorite implementation thinks NIL is of type NULL, LIST, or SYMBOL. I ended up writing a specialized function to do what I wanted, without relying on TYPE-OF. This is just a matter of TYPE-OF not being specific enough together with COERCE not being general enough. If TYPE-OF is properly specific (i.e. NULL), and COERCE finds the "least supertype" of the argument type that it supports (for example, if you wrote it with TYPECASE or SUBTYPEP, rather than EQL), then there's no problem. Our entire user-interface in Release 7 is based on just type sort of question. It is fundamental to any theory of TYPEP, as well. I freely admit that it isn't often called, but that's not a reason to eliminate it, or to leave it sloppily specified. In short, I am not convinced that TYPE-OF would be particularly useful even if its definition were firmed up more. If nobody has any good use for this function, arguing over how it should behave is rather pointless. I think your own example contradicts this position.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 21 Nov 86 12:55:08 EST Received: from VAXA.ISI.EDU by SAIL.STANFORD.EDU with TCP; 21 Nov 86 09:44:50 PST Received: by vaxa.isi.edu (4.12/4.7) id AA11398; Fri, 21 Nov 86 09:45:10 pst Message-Id: <8611211745.AA11398@vaxa.isi.edu> Date: 21 Nov 1986 0945-PST (Friday) To: COMMON-LISP@SU-AI.ARPA From: wile@ISI-VAXA Subject: Package solution "motivation" I was afraid of that. Everyone jumped on the complaint and ignored the proposal. I'll complain more succinctly in a separate message. The problem I am trying to solve, as a producer of software that manipulates program specifications and implementations, is to allow my users to be as unconcerned with packages as possible. I have written a system, called Popart, which takes BNF grammars extended with regular expressions and operator precedence, a produces a parser, lexical analyzer, pretty printer, pattern matcher, (old style) structure editor, and transformation system for the language written in that grammar. Of course, I have tried to integrate the facility consistent with Common LISP conventions, rather than just deeming packages "red herrings" to be ignored. Generally, our use of Popart will be to allow users to specify the functionality of their application in a language we call Gist, transform that specification into a language we call Will, which will be automatically compiled into Common LISP. Yesterday's comment that "the user must have a firm model of the package structure" is right on. Consider the packages involved in the scenario above: Grammar parse tree structures Grammar constants Grammar grammar parse tree structures Grammar grammar constants Transformation definition language parse tree " " " " " " constants Transformation definitions themselves (their names, like divide-and-conquer, duplicate-arm-motion-removal, ...) User Gist symbols (Gist application package, e.g. relation names, agent names) User Will symbols (e.g. demon names, type definitions) LISP and below Obviously, creating the right defaulting mechanism is very important here. The first major decision was to put all grammar constants (begin, end, +, etc.) in the keyword package for all grammars. I would prefer to put them into the uninterned symbol (non)package, but I don't know how to read into that package. The reason I would prefer to do this is partially an efficiency issue. If I could read symbols that way, I could decide to put the (few) symbols whose packages matter (names of functions, defined entities in the users' languages) in that package. The only option I seem to have is to read everything into the user's package and change them into grammar constants when I see that that name has been used in the grammar. Perhaps I could read everything into the keyword package, but I had visions of creating lots of garbage keyword symbols. I don't know... Reading the symbol uninterned and then deciding where to intern it seems conceptually the right hook. Thus, the proposal to allow read an optional functional parameter to decide where to put the symbol. [Incidentally, the other defaults: Grammar grammar parse tree structures are in the parser's package. Transformation definition language parse trees are in the transformation system's package. Transformation definitions themselves are in the grammar's package for which language they are transformations. User Gist and Will symbols are in packages defined (used) by the user (just as function definitions, variable definitions, etc., are in Lisp) ] Sorry for the vitriolic attack. (I'd tried to make it many times before, with no proposed solution, so I'd resisted. I thought I was being positive with my proposal.) Perhaps now you understand my frustration... Dave Wile  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 21 Nov 86 11:19:04 EST Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 21 Nov 86 08:08:04 PST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 5975; Thu 20-Nov-86 20:24:05 EST Date: Thu, 20 Nov 86 20:23 EST From: David A. Moon Subject: Packages To: wile@ISI-VAXA.ARPA cc: COMMON-LISP@SU-AI.ARPA In-Reply-To: <8611182057.AA08142@vaxa.isi.edu> Message-ID: <861120202347.3.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: 18 Nov 1986 1257-PST (Tuesday) From: wile@ISI-VAXA I believe inclusion of packages is the worst mistake in Common LISP's design. There isn't a day goes by (when I actually get to program or debug) when I don't have package problems.... I am looking for conventions that make packages easier to live with. I am surprised that you have not noticed that Common Lisp does NOT require the programmer to use packages. The only packages Common Lisp requires you to know about are USER, LISP, and KEYWORD. You can ignore the distinction between USER and LISP, and pretend that KEYWORD symbols are just symbols with colons in their names, and get along just fine. Of course you don't get any of the benefits of packages this way, but you don't get any of the problems, either. Another way to look at it is that Common Lisp contains the Maclisp/Interlisp one-symbol-namespace dialect as a subset. I do not mean by this comment to stifle anyone's research into better modularity facilities for Lisp than packages. I am confident that something better will eventually be invented, developed, and tempered in the fire of real-life use. Several promising ideas have already come forth (starting at least 22 years ago, actually). If any of those ideas are so well-developed and problem-free that they are ready for universal adoption, I haven't heard about it yet, but I'm sure it's bound to happen eventually.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 21 Nov 86 09:53:11 EST Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 21 Nov 86 06:37:07 PST Received: ID ; Fri 21 Nov 86 09:36:58-EST Date: Fri, 21 Nov 1986 09:36 EST Message-ID: From: Rob MacLachlan To: Masayuki Ida Cc: common-lisp@SU-AI.ARPA, ida%u-tokyo.junet@RELAY.CS.NET Subject: TYPE-OF In-reply-to: Msg of Wed 19 Nov 86 23:41:56+0900 from Masayuki Ida Date: Wed, 19 Nov 86 23:41:56+0900 From: Masayuki Ida To: common-lisp at SU-AI.ARPA, ida%u-tokyo.junet at RELAY.CS.NET Re: TYPE-OF D-Eval concept needs TYPE-OF. kinds of type inferencing system will also need TYPE-OF to determine the type. Here is a conversation with D-Eval: D-Eval>(+ 1 2) 3 ; FIXNUM Well, if all D-Eval uses Type-Of for is to print out the type, then it doesn't really matter what it returns. I had in mind a fragment of code that needed to use Type-Of. I don't know exactly what you mean by a "type inferencer", but for the kinds of type inferences that I could conceive of a Lisp compiler wanting to do, you definitely want the *most specific* type, and certainly don't want to return random things such as FIXNUM which represent implementation details rather than language semantics. Suppose that I was examining the expression: (+ (aref a 3) 7) Now, if A is known (due to declaration) to be (array (unsigned-byte 8)), then I could combine the fact that 7 is (integer 7 7) with that information to determine that the result of the addition is (integer 262 7), which is probably a useful thing to know. If all that I know is that 7 is FIXNUM, then all bets are off. I didn't mention this on the mailing list as a valid use of Type-Of, since: 1] The compiler *is* the implementation, so it doesn't matter if it is implementiaton dependent. 2] The version of Type-Of that I am using in the compiler is optimized to return what the compiler considers most interesting, rather than what the user might consider most informative. For example, given a symbol, it returns (member ). Rob  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 21 Nov 86 09:20:47 EST Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 21 Nov 86 06:13:05 PST Received: ID ; Fri 21 Nov 86 09:12:26-EST Date: Fri, 21 Nov 1986 09:12 EST Message-ID: From: Rob MacLachlan To: Masayuki Ida Cc: common-lisp@SU-AI.ARPA, ida%u-tokyo.junet@RELAY.CS.NET Subject: question: EVAL In-reply-to: Msg of Fri 21 Nov 86 17:49:44+0900 from Masayuki Ida You can use Evalhook to evaluate a form in an environment, supposing that you can get your hands on one. Currently the only way to get your hands on a guaranteed evaluation environment is to use *evalhook* or *applyhook*. With such an environment, the semantics are well defined. Some implementations that don't have an evaluator don't support *evalhook* though... Rob  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 21 Nov 86 05:48:50 EST Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 21 Nov 86 02:42:07 PST Received: from utokyo-relay by csnet-relay.csnet id ac01740; 21 Nov 86 4:56 EST Received: by u-tokyo.junet (4.12/4.9J-1[JUNET-CSNET]) id AA11733; Fri, 21 Nov 86 18:10:26+0900 Received: by ccut.u-tokyo.junet (4.12/6.1Junet) id AA12885; Fri, 21 Nov 86 17:49:44+0900 Date: Fri, 21 Nov 86 17:49:44+0900 From: Masayuki Ida Message-Id: <8611210849.AA12885@ccut.u-tokyo.junet> To: common-lisp@SU-AI.ARPA, ida%u-tokyo.junet@RELAY.CS.NET Subject: question: EVAL In the list of GLS, there is an EVAL extension to have an optional argument for 'environment'. will it be defined in the comming specification ? Is this only one argument ? Does the value of this optional 'environmental' argument have a defined syntax/semantics ? ida  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 20 Nov 86 18:45:26 EST Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 20 Nov 86 15:27:20 PST Received: from Cabernet.ms by ArpaGateway.ms ; 20 NOV 86 14:24:35 PST Date: 20 Nov 86 14:24 PST From: Pavel.pa@Xerox.COM Subject: Re: fboundp question In-reply-to: Christopher Fry 's message of Thu, 20 Nov 86 06:12 EST To: cfry@OZ.AI.MIT.EDU cc: common-lisp@SU-AI.ARPA Message-ID: <861120-142435-4722@Xerox> Page 71: ``We say that a predicate `is true' when it returns a non-NIL value'' Page 90-91: ``FBOUNDP is true if the symbol has a global function definition. Note that FBOUNDP is true when the symbol names a special form or macro.'' Page 116: ``COND {(test {form}*)}* [Macro]'' Page 133: ``GO tag [Special Form]'' Therefore, (fboundp 'cond) => a non-NIL value (fboundp 'go) => a non-NIL value Nothing more is guaranteed by the language definition. Xerox and Lucid Lisps return T in both cases. Pavel  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 20 Nov 86 17:48:46 EST Received: from ELEPHANT-BUTTE.SCRC.SYMBOLICS.COM by SAIL.STANFORD.EDU with TCP; 20 Nov 86 14:33:25 PST Received: from CHICOPEE.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 111079; Thu 20-Nov-86 14:48:32 EST Date: Thu, 20 Nov 86 13:34 EST From: Daniel L. Weinreb Subject: TYPE-OF To: a37078%ccut.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET, common-lisp@SU-AI.ARPA, ida%u-tokyo.junet@RELAY.CS.NET In-Reply-To: <8611191441.AA16856@ccut.u-tokyo.junet> Message-ID: <861120133433.3.DLW@CHICOPEE.SCRC.Symbolics.COM> OK, I think it's clear that you don't really want TYPE-OF to return "the most specific type". Rather, you want it to be the case that TYPE-OF is well-defined for all objects in Common Lisp, and that the definition, which will be written out clearly somewhere, will tend to specify that more-specific rather than less-specific types be returned. If some implementation has its own even-more-specific type, TYPE-OF will not return it. Even so, I'm not sure I understand why you need TYPE-OF. As far as I can tell, almost the only useful thing to do with a type is to see whether some object is of that type, and that's what TYPEP is for. In your D-Eval example, evaluating (foo 1) returned 2 and printed out "; FIXNUM". If you had said (foo 0), it would have returned 1, but would it have printed out "; BIT"? Apparently not, because that's not in your list of number types. On the other hand, why doesn't 2 print out "; INTEGER"? That is, why does your list exclude BIT but include FIXNUM and BIGNUM? Whether an integer is a FIXNUM or not depends on the implementation, and usually it's better to hide it than draw attention to it. Same question for the different floating point formats. In order to make TYPE-OF fully-defined, some kinds of decisions have to be made, and some of them seem rather arbitrary (in the sense that it's not really clear which decision is best).  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 20 Nov 86 16:54:23 EST Date: 20 Nov 86 1250 PST From: Dick Gabriel Subject: TYPE-OF To: common-lisp@SAIL.STANFORD.EDU Given the recent re-discovery that TYPE-OF cannot be defined to have the same precise behavior in all Common Lisps, it seems we should rename `types' to be `sorts' and therefore rename `TYPE-OF' to be `SORT-OF.' -rpg-  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 20 Nov 86 16:45:03 EST Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 20 Nov 86 13:20:19 PST Received: ID ; Thu 20 Nov 86 16:19:24-EST Date: Thu, 20 Nov 1986 16:19 EST Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: Sean.Engelson@CAD.CS.CMU.EDU Cc: common-lisp@SU-AI.ARPA Subject: EVAL In-reply-to: Msg of 20 Nov 1986 13:28-EST from Sean.Engelson at cad.cs.cmu.edu Why is it that EVAL returns the value in the current DYNAMIC environment, rather than the lexical environment? Or perhaps the most recent binding (lexical unless a variable is special)? Or if this is necessary for some reason, why isn't there another function, say, LEXICAL-EVAL that does this? It seems rather strange to have a mainly lexically scoped language with no facility for lexical evaluation. EVAL cannot easily be defined to work in the lexical environment in which it appears because that lexical environment is not around at runtime, when the argument to EVAL arrives and the evaluation occurs. In any event, it would eliminate many of the benefits of lexical scoping to provide a loophole through which arbitrary forms might be smuggled into a lexical environment at runtime. For example, certain optimization are now possible because the compiler can examine all possible references to a lexically-bound variable by scanning the lexical block in which it is bound; thsi would go away in the presence of your LEXICAL-EVAL. So the language specifies that EVAL operates within the current dynamic environment and the null lexical environment, and it does not provide a way to pass a non-null lexical environment to EVAL. For debugging, it is useful to be able to access lexical variables by name, but this falls outside of the language proper. It does not need to be portable and it does not need to work in code that has been altered beyond recognition by the compiler. I must have answered this question a hundred times, both on this mailing list and elsewhere. We'd better put a "rationale" statement intot he next version of the manual, since people seem to find this more confusing than anything else (except maybe packages and case conversion). -- Scott  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 20 Nov 86 15:25:25 EST Received: from GODOT.THINK.COM by SAIL.STANFORD.EDU with TCP; 20 Nov 86 12:17:09 PST Received: from hilarion by Godot.Think.COM via CHAOS; Thu, 20 Nov 86 15:23:53 EST Date: Thu, 20 Nov 86 15:16 EST From: Guy Steele Subject: TYPE-OF To: DLW@alderaan.scrc.symbolics.com, a37078%ccut.u-tokyo.junet%utokyo-relay.csnet@relay.cs.net, common-lisp@su-ai.arpa, ida%u-tokyo.junet@relay.cs.net Cc: gls@aquinas.think.com In-Reply-To: <861120133433.3.DLW@CHICOPEE.SCRC.Symbolics.COM> Message-Id: <861120151614.4.GLS@HILARION.THINK.COM> One might want (TYPE-OF 2) => (INTEGER 2 2), or perhaps just (INTEGER 2) and define (INTEGER x) <=> (integer x x). But this does not seem to generalize nicely to other data types. If the goal is that TYPE-OF should return the most specific possible type, then clearly when applied to object x it should return (MEMBER x), as that is the most specific type that contains x. But this is not very useful, and therefore this goal is not what we really want. --Guy  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 20 Nov 86 15:04:52 EST Received: from SCRC-VALLECITO.ARPA by SAIL.STANFORD.EDU with TCP; 20 Nov 86 11:50:45 PST Received: from CHICOPEE.SCRC.Symbolics.COM by VALLECITO.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 71990; Thu 20-Nov-86 14:49:44 EST Date: Thu, 20 Nov 86 13:34 EST From: Daniel L. Weinreb Subject: TYPE-OF To: a37078%ccut.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET, common-lisp@SU-AI.ARPA, ida%u-tokyo.junet@RELAY.CS.NET In-Reply-To: <8611191441.AA16856@ccut.u-tokyo.junet> Message-ID: <861120133433.3.DLW@CHICOPEE.SCRC.Symbolics.COM> OK, I think it's clear that you don't really want TYPE-OF to return "the most specific type". Rather, you want it to be the case that TYPE-OF is well-defined for all objects in Common Lisp, and that the definition, which will be written out clearly somewhere, will tend to specify that more-specific rather than less-specific types be returned. If some implementation has its own even-more-specific type, TYPE-OF will not return it. Even so, I'm not sure I understand why you need TYPE-OF. As far as I can tell, almost the only useful thing to do with a type is to see whether some object is of that type, and that's what TYPEP is for. In your D-Eval example, evaluating (foo 1) returned 2 and printed out "; FIXNUM". If you had said (foo 0), it would have returned 1, but would it have printed out "; BIT"? Apparently not, because that's not in your list of number types. On the other hand, why doesn't 2 print out "; INTEGER"? That is, why does your list exclude BIT but include FIXNUM and BIGNUM? Whether an integer is a FIXNUM or not depends on the implementation, and usually it's better to hide it than draw attention to it. Same question for the different floating point formats. In order to make TYPE-OF fully-defined, some kinds of decisions have to be made, and some of them seem rather arbitrary (in the sense that it's not really clear which decision is best).  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 20 Nov 86 13:43:25 EST Received: from CAD.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 20 Nov 86 10:32:21 PST Date: 20 Nov 1986 13:28-EST From: Sean.Engelson@cad.cs.cmu.edu To: common-lisp@SU-AI.ARPA Subject: EVAL Message-Id: <532895293/spe@cad.cs.cmu.edu> Why is it that EVAL returns the value in the current DYNAMIC environment, rather than the lexical environment? Or perhaps the most recent binding (lexical unless a variable is special)? Or if this is necessary for some reason, why isn't there another function, say, LEXICAL-EVAL that does this? It seems rather strange to have a mainly lexically scoped language with no facility for lexical evaluation.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 20 Nov 86 13:32:48 EST Received: from [192.10.41.109] by SAIL.STANFORD.EDU with TCP; 20 Nov 86 10:20:40 PST Received: from CHICOPEE.SCRC.Symbolics.COM by ALDERAAN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 22688; Thu 20-Nov-86 13:19:12 EST Date: Thu, 20 Nov 86 13:20 EST From: Daniel L. Weinreb Subject: side comment To: common-lisp@SU-AI.ARPA Message-ID: <861120132014.2.DLW@CHICOPEE.SCRC.Symbolics.COM> Date: Wed, 19 Nov 1986 23:32 EST From: Rob MacLachlan Unless you have a better example, what you are really demonstrating is the horrible lossage in the definition of specialized array types. Side comment: This is what happens when experienced, well-intentioned Lisp experts decide to put an untested new idea into a language standard. In many, perhaps most, cases where we put in new ideas that had not been tested in "production" circumstances, we got nasty surprises much later. This is a fine thing to happen in a growing Lisp implementation, but not a fine thing to happen in a stable Lisp standard.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 20 Nov 86 10:55:51 EST Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 20 Nov 86 07:47:47 PST Received: from JONES.AI.MIT.EDU by OZ.AI.MIT.EDU via Chaosnet; 20 Nov 86 06:12-EST Date: Thu, 20 Nov 86 06:12 EST From: Christopher Fry Subject: fboundp question To: common-lisp@SU-AI.ARPA Message-ID: <861120061242.7.CFRY@JONES.AI.MIT.EDU> (fboundp 'cond) => ? (fboundp 'go) => ? I am not happy with the spec on symbol-function.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 20 Nov 86 10:17:00 EST Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 20 Nov 86 07:03:32 PST Received: ID ; Thu 20 Nov 86 09:34:07-EST Date: Wed, 19 Nov 1986 23:32 EST Message-ID: From: Rob MacLachlan To: "Robert W. Kerns" Cc: common-lisp@SU-AI.ARPA Subject: type-of In-reply-to: Msg of 18 Nov 1986 16:04-EST from Robert W. Kerns I have also done some thinking about types in connection with my project of writing a Common Lisp compiler that takes types seriously. I tend to agree Sandra that your example demonstrates a problem in the type system rather than a solution. Unless you have a better example, what you are really demonstrating is the horrible lossage in the definition of specialized array types. I agree that it might be useful to be able to determine if an object can be stored in an array, but I suggest that the problem be solved by adding an Array-Can-Hold-P predicate. The problem is that in principle, there is no reason why the "type" of object that can be stored in a specialized array must be representable with a Common Lisp type specifier. I guess that with your ARRAY-POSITIVE-POWER-OF-TWO-BIGNUM example, you were suggesting that it is always possible to do the back-mapping without losing information, but I don't think that it is a good idea to require this. Much of the confusion revolves around the lack of distinction between types and objects. When the implementation decides to create an instance of a type, it chooses a representation. This mapping between types and representations is neither injective nor surjective. The implementation may decide to discard information, as in (ARRAY SYMBOL) ==> (ARRAY T). It may also decide to add information, as in INTEGER ==> FIXNUM. Many functions in the language use the to-implementation mapping; I believe that only Type-Of and Array-Element-Type attempt to perform the from-implementation mapping. If these functions are ignored, then implementation's freedom to choose representations is totally invisible, and is restricted only by the requirements that certain types "are disjoint". I think that any attempt to use Type-Of or Array-Element-Type in code is highly suspect. The only such use that I know of is to find the type of an object which is known to be a structure; this is presumably what Class-Of does. Note that in this case, Type-Of is actually doing something totally different from what it normally does: it is making no attempt to return the "most specific type"; instead it is making a well-defined from-implementation mapping based on an explicitly defined type hierarchy. If we treated objects other than structures the same way, then we could make a similar back-mapping for them. This capability seems to be what Ida seems to be interested in, but it isn't what Type-Of does. Rob  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 20 Nov 86 03:04:34 EST Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 19 Nov 86 23:55:05 PST Received: from utokyo-relay by csnet-relay.csnet id aa09456; 19 Nov 86 10:53 EST Received: by u-tokyo.junet (4.12/4.9J-1[JUNET-CSNET]) id AA23688; Wed, 19 Nov 86 23:51:37+0900 Received: by ccut.u-tokyo.junet (4.12/6.1Junet) id AA16856; Wed, 19 Nov 86 23:41:56+0900 Date: Wed, 19 Nov 86 23:41:56+0900 From: Masayuki Ida Message-Id: <8611191441.AA16856@ccut.u-tokyo.junet> To: common-lisp@SU-AI.ARPA, ida%u-tokyo.junet@RELAY.CS.NET Subject: TYPE-OF This mail is the reply to RAM's mail and RWK's mail. (And I just read Fahlman's mail and Masinter' mail on posting this. this mail is not directly related to my committee work for the standardization) My trigger to think of TYPE-OF (and SUBTYPEP) is the definition of the Common Lisp interpreter including CommonLoops. I've been thinking of it since last November before PCL was there. (And presented a paper on Dec. 1985 in Japan) I named it Discriminating Eval (D-Eval). D-Eval is an executable model of Common Lisp scheme. D-Eval always keeps track of the type of a object. With this D-Eval, Common Lisp can, I think, bridge the object oriented world and lisp, and formal systems. I feel several researchers are independently working in near here. (If someone is interested in D-Eval I will send a version of it to anyone) Here is a conversation with D-Eval: D-Eval>(+ 1 2) 3 ; FIXNUM D-Eval>(cdr '(a)) () ; NULL D-Eval>(ndefmeth foo ((x integer)) (+ x 1)) FOO ; SYMBOL D-Eval>(foo 1) 2 ; FIXNUM ... Then, I will try to discuss. >Date: Mon, 17 Nov 1986 18:03 EST >From: Rob MacLachlan >Received: from CSNet-Relay by utokyo-relay; 19 Nov 86 12:58:34-JST (Wed) > > ... >It would also be wrong for NIL to be returned to indicate a random >object, since NIL is a meaningful type, but not one that any object >can posess. It would make more sense to return T or a new type such >as RANDOM. I understood. I confess that I did not make a deep consideration on random object prior to posting my mail. I am wrong. They should not goto NIL. Thank you. >I also have some doubts about the need to specify what Type-Of >returns. Could you demonstrate some code that needs to use Type-Of >and is adversely affected by different implementations? I suppose >that we could rigorously specify some function that does what you >want, but it shouldn't be Type-Of. D-Eval concept needs TYPE-OF. kinds of type inferencing system will also need TYPE-OF to determine the type. > > Rob > ---------- >Date: Tue, 18 Nov 86 16:04 EST >From: Robert W. Kerns >In-Reply-To: <8611170906.AA16158@ccut.u-tokyo.junet> >Received: from CSNet-Relay by utokyo-relay; 19 Nov 86 15:19:54-JST (Wed) > > ... Your question really relates to one of the core >issues of this topic. I think so if my image of SUBTYPEP is same as yours. > > ... And SUBTYPEP/TYPEP >is what answers the question "is this object suitable." >Given this model, there is no such thing as "too specific" >an answer from TYPE-OF. On the contrary, the concern should >be with "not specific enough". > >To address your specific points: > > Date: Mon, 17 Nov 86 18:06:12+0900 > From: Masayuki Ida > > ... > >For example, TYPE-OF of a number must return one of INTEGER, COMPLEX, FLOAT, >RATIO, or one of their subtypes (if any), or some other subtype of NUMBER. TYPE-OF of a number must return one of the FIXNUM, BIGNUM, RATIO, SHORT-FLOAT, SINGLE-FLOAT, DOUBLE-FLOAT, LONG-FLOAT, COMPLEX. If TYPE-OF can not return one of the above, it must return the type which is closer to the above terminal type. > >However, it does not make sense to specify that TYPE-OF return one >of FIXNUM or BIGNUM, rather than INTEGER; a system which implemented >all numbers as "BIGNA" would be correct, if inefficient. > >And a system might reasonably have two kinds of BIGNUM's, NEGATIVE-BIGNUM and >POSITIVE-BIGNUM. If you specify that TYPE-OF return just BIGNUM, >you prevent any program from distinguishing between them, when it >may be the program's advantage to make the distinction. NEGATIVE-BIGNUM and POSITIVE-BIGNUM are not defined in Common Lisp, though they are possible to exist. > >By over-specifying TYPE-OF, you can eliminate any implementation >flexibility or extensibility. TYPE-OF story and implementation flexibility are quite different. I think the definition of TYPE-OF is needed to keep Common Lisp as well-defined. It is the issue of formality. What I said is TYPE-OF should return the name of the symbol which is defined in the language specification. And, the value (type) should be at the bottom of hierarchy chart whenever it is possible. For example, (type-of ()) should not be SYMBOL as in some CL implementations, but NULL. > > ... >TYPE-OF returns POWER-OF-TWO-POSITIVE-BIGNUM, SUBTYPEP must return ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ this symbol is not in my dictionary. Again, I think TYPE-OF should not return implementation dependent things. >the values T T when asked if this is a subtype of BIGNUM, of INTEGER, >and of NUMBER. > >SUBTYPEP is the only predicate provided for comparing types; >it goes without saying that any code that uses something else >like EQUAL will not be portable. Any type you get back from >TYPE-OF you must interpret with SUBTYPEP. > > I had wrote a hierarchy chart based on 2.15. > which is attached on the japanese edition of CLtL. > > Here is a brief sketch of it. >The english version of CLtL would be clearer if it >included something like this. I think so. ( I already sent it to GLS) > > T>{pathname,stream,hash-table,readtable,package,random-state, > > 'nil' is for undefined object, say unreadable objects. >No, not NIL. T would be a better choice here than NIL! Thank you. As I answered to RAM's message, I am wrong. > > .... There is nothing wrong with having >an UNDEFINED type, however. ... Will you push to make UNDEFINED type ? I think its interesting. I want to add one more thing. (type-of "string") must return SIMPLE-STRING. SIMPLE-STRING is a subtype of STRING and SIMPLE-ARRAY simultaneously. If this call returns STRING, SIMPLE-ARRAY related things can not handle the things caused by (type-of "string"). Masayuki Ida  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 20 Nov 86 02:01:55 EST Received: from LIVE-OAK.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 19 Nov 86 22:54:25 PST Received: from GOLD-HILL-ACORN.DialNet.Symbolics.COM by MIT-LIVE-OAK.ARPA via DIAL with SMTP id 17359; 20 Nov 86 01:43:49-EST Received: from BOSTON.Gold-Hill.DialNet.Symbolics.COM by ACORN.Gold-Hill.DialNet.Symbolics.COM via CHAOS with CHAOS-MAIL id 44908; Wed 19-Nov-86 22:33:42-EST Date: Wed, 19 Nov 86 23:09 est Sender: mike@acorn To: wile@ISI-VAXA from: mike%acorn@mit-live-oak.arpa Subject: Packages: a modest solution. Cc: COMMON-LISP@SU-AI.ARPA Date: 18 Nov 1986 1257-PST (Tuesday) From: wile@ISI-VAXA Aha! I finally figured out the solution to the package problem! I believe inclusion of packages is the worst mistake in Common LISP's design. There isn't a day goes by (when I actually get to program or debug) when I don't have package problems. Often, they dominate the debugging time. I now type :: all the time, just so I don't have to think about whether the reader can figure out the right default. This seems like a problem to me, since you have no control over internal and external names anymore. I have a similarly explicit approach, but it preserves the internal/external symbol distinction: The biggest problem with packages is lack of education about how to avoid most of their pitfalls. I have found that if you avoid use-package or the options for :use to in-package and relatives, and you explicitly export and inport names, then package problems go away. The only packages which should be used are those which define the lisp language, i.e., lisp, but not SYS. This avoids most snafu's. The rule of thumb is "don't use a package unless you personally know every single exported symbol of that package and know that it doesn't conflict with any name you are using." This means basically that you should never use-package anything except package lisp. (even this causes problems, since lisp is such a big language that people frequently begin accidently redefining primitives like check-type, assert, etc. in embedded language systems.....) For example, we had a major problem with the function sys:lambda-list, which is supposed to take a symbol and print the lambda-list, and a bunch of code which uses an internal symbol "lambda-list" just as a local lexical var. If you load the files in the wrong order, you get a package problem. This is only since package lisp uses package sys, an unfortunate situation that can't be rectified easily. The solution was to make a moby export file which is read before almost anything, but this is really a kludge. The problem is really that lisp code has no business using the symbol "lambda-list" internally anywhere without recognizing the existance of that name as an internal part of the sys package. If you explicitly export and import the right symbols manually, then the code to do this automatically interns all the right things in the right places, i.e., in order to say that you are importing certain symbols you must introduce them to the reader properly qualified with a package prefix. Hence you won't die having to unintern some symbol which was read into the wrong place before the export/import happened. I'm in favor of leaving the package system as it is, but I think the manual (or a later spec) should contain alot of warnings about the kinds of problems that use-package causes. The naive user almost always thinks the easiest thing to do is have all his packages use each-other. And if he does experience package problems, then the naive view again is that making everything use everything solves these problems. There is no "DWIM-with-all-the-symbols"; the control of names in large systems requires a methodical, explicit approach. ...mike beckerle Gold Hill Computers  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 19 Nov 86 14:47:26 EST Received: from [192.10.41.109] by SAIL.STANFORD.EDU with TCP; 19 Nov 86 11:30:27 PST Received: from CHICOPEE.SCRC.Symbolics.COM by ALDERAAN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 22063; Wed 19-Nov-86 14:26:48 EST Date: Wed, 19 Nov 86 14:28 EST From: Daniel L. Weinreb Subject: Packages To: shebs%utah-orion@UTAH-CS.ARPA, common-lisp@SU-AI.ARPA In-Reply-To: <8611182249.AA11049@utah-orion.ARPA> Message-ID: <861119142829.4.DLW@CHICOPEE.SCRC.Symbolics.COM> Date: Tue, 18 Nov 86 15:49:29 MST From: shebs%utah-orion@utah-cs.arpa (Stanley T. Shebs) Somehow, I don't see it ever getting into the present form of CL. (Strange how CL is starting to look a little dated here and there...) Certainly. CL is an attempt to unify and codify a set of dialects that existed and were well-tested and understood as of a few years ago. The idea was to do basic cleanups, resolve differences between similar dialects into one large Common subset, and codify it and make it stable. That's what Common Lisp is all about. There are lots of exciting new ideas in Lisp that are being worked on, including locales and a lot of other things. To take every good new idea as it comes along, and "add it to" Common Lisp, will destroy the stabilty of the language and the confidence of the users outside the inner circle of Lisp innovators. These new ideas are great things, but the reaction to them should not be to "add them to the standard". A standard is useless if it isn't extremely stable. Common Lisp's purpose in life is to be a standard, and so stability is of paramount importance. Experimentation and new ideas in Lisp should continue, I hope in great quantity and strength, and there should always be new dialects. But it's not necessary to first "add it to Common Lisp".  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 19 Nov 86 11:33:01 EST Received: from UTAH-CS.ARPA by SAIL.STANFORD.EDU with TCP; 19 Nov 86 08:17:05 PST Received: by utah-cs.ARPA (5.31/4.40.2) id AA01245; Wed, 19 Nov 86 09:18:12 MST Received: by utah-orion.ARPA (5.31/4.40.2) id AA14790; Wed, 19 Nov 86 09:11:01 MST Date: Wed, 19 Nov 86 09:11:01 MST From: sandra%utah-orion@utah-cs.arpa (Sandra J Loosemore) Message-Id: <8611191611.AA14790@utah-orion.ARPA> Subject: type-of To: common-lisp@su-ai.arpa From: RWK@YUKON.SCRC.Symbolics.COM (Robert W. Kerns) Date: 18 Nov 86 21:04:00 GMT Here is an example of completely-portable code which depends on TYPE-OF returning the MOST specific type. (defun store-in-array-if-fits (object array &rest indicies) (let ((object-type (type-of object)) (array-type (array-element-type array))) (if (subtypep object-type array-type) ;; If the object fits, store it (setf (apply #'aref array indicies) object) ;; Doesn't fit, so store 0 instead. (setf (apply #'aref array indicies) 0)))) Sorry, I can't buy this motivation. All this example illustrates is that there is a good reason for having the TYPEP function around. As it happens, in PCLS, TYPE-OF does go through a considerable amount of work to find the most specific type that it can. So, (TYPE-OF 0) returns BIT, which is correct but largely useless. My "gut feeling" is that what the user probably wants is either FIXNUM or INTEGER -- something which indicates how the object is represented internally, or (in other words) one of the set of types which CLtL says are disjoint. I'll have to agree that TYPE-OF as defined now is pretty bogus. The only place I've ever had reason to use TYPE-OF in real code was to get a type to pass to COERCE or CONCATENATE, etc., when I wanted to ensure that two objects were of the same type; for example, both lists or whatever. But this is full of holes, too. For example, (coerce '#(a b c) (type-of (list))) may fail, depending on whether your favorite implementation thinks NIL is of type NULL, LIST, or SYMBOL. I ended up writing a specialized function to do what I wanted, without relying on TYPE-OF. In short, I am not convinced that TYPE-OF would be particularly useful even if its definition were firmed up more. If nobody has any good use for this function, arguing over how it should behave is rather pointless. -Sandra -------  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 19 Nov 86 11:03:57 EST Received: from UTAH-CS.ARPA by SAIL.STANFORD.EDU with TCP; 19 Nov 86 07:49:39 PST Received: by utah-cs.ARPA (5.31/4.40.2) id AA00592; Wed, 19 Nov 86 08:50:46 MST Received: by utah-orion.ARPA (5.31/4.40.2) id AA14443; Wed, 19 Nov 86 08:19:15 MST Date: Wed, 19 Nov 86 08:19:15 MST From: shebs%utah-orion@utah-cs.arpa (Stanley T. Shebs) Message-Id: <8611191519.AA14443@utah-orion.ARPA> To: common-lisp@su-ai.arpa Subject: Re: type-of If type-of is meant for interactive use, perhaps it should be moved to the miscellaneous chapter. Also, make it a macro that doesn't evaluate its argument :-) :-). stan  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 18 Nov 86 22:34:11 EST Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 18 Nov 86 19:09:35 PST Received: ID ; Tue 18 Nov 86 22:09:06-EST Date: Tue, 18 Nov 1986 22:09 EST Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: common-lisp@SU-AI.ARPA Subject: TYPE-OF Before we start debating proposals to improve TYPE-OF, we should probably try to figure out what we really want to accomplish. Then we will have some goals against which to measure the various proposals. Given that the Common Lisp type system is a lattice and not a simple tree, TYPE-OF (originally known as "one-argument TYPEP") was considered to be of very dubious value, and was almost dropped. It was kept in the language for only one purpose: to provide users with a quick and dirty way to examine various objects interactively to see what they are. For this purpose, the current definition is exactly right: each implementation should provide as detailed a description as it can manage conveniently. This is non-portable, but given the purpose of this function, portability is less valuable than getting as much information to the user as possible. CLTL (page 52-53) basically says that TYPE-OF is not meant to be used in code, except in a few odd situations that are adequately handled by the current definition. I sounds to me like Ida and Masinter have in mind some use of TYPE-OF within programs, and that such use is not adequately covered by TYPEP and TYPE-CASE. It seems to me that the best way to make progress is to first spell out this problem or problems, then decide whether TYPE-OF is the right way to solve the problem (as opposed to inventing some new form), and finally to think about how to change the definition of TYPE-OF. If these problems arise in the context of CommonLoops, then maybe CLASS-OF is the right form to use. -- Scott  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 18 Nov 86 22:33:29 EST Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 18 Nov 86 19:06:27 PST Received: ID ; Tue 18 Nov 86 22:05:54-EST Date: Tue, 18 Nov 1986 22:05 EST Message-ID: From: Rob MacLachlan To: miller@ROCHESTER.ARPA cc: common-lisp@SU-AI.ARPA Subject: Package functions not powerful enough? Your message is pretty unclear, but I think that there are adequate tools for explicitly resolving potential name conflicts. In the CMU Common Lisp package code, all conflict resolution is done with standard package functions, so it is clearly doable. Of course, as you make arbitrarily complex changes to the namespace, the code to do so becomes arbitrarily complex. Although I am fairly sure that there is a simpler solution than the one proposed, the cruftiness is a natural reflection of the mismatch between what you want the package system to do and what it was meant to do. The big problems that I see users having with the package system are due to their inaccurate models of the real semantics of the package system. This is encouraged by the current language in CLTL. One of the biggest misconceptions is that a symbol "belongs" to its home package. In fact, the home package has no semantics other than printing. A more fundamental problem is that the package system manipulates names, whereas users (quite reasonably) thing in terms of managing named objects. Rob  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 18 Nov 86 22:13:31 EST Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 18 Nov 86 18:51:52 PST Received: from Cabernet.ms by ArpaGateway.ms ; 18 NOV 86 18:07:06 PST Date: 18 Nov 86 18:08 PST Sender: Miller.pa@Xerox.COM Subject: Re: Packages: a modest solution. In-reply-to: wile@VAXA.ISI.EDU's message of 18 Nov 86 12:57 PST (Tuesday) To: wile@VAXA.ISI.EDU cc: COMMON-LISP@SU-AI.ARPA From: Mark S. Miller Message-ID: <861118-180706-2579@Xerox> Take a look at the T language. It has reified lexical environments. Such reified environments (called LOCALEs) seem able to do all that's valuable with packages, and are based on a clean scoping semantics. Modularity can be understood in terms of the abstract language and not its reader. I believe that if LOCALEs were added to CommonLisp, then (after new programmers grew up with it) packages would only be used for old code. This change can probably be made in an upwards compatible fashion. ----- MarkM  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 18 Nov 86 18:56:20 EST Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 18 Nov 86 15:39:25 PST Received: from Cabernet.ms by ArpaGateway.ms ; 18 NOV 86 15:24:08 PST Date: 18 Nov 86 15:24 PST From: masinter.pa@Xerox.COM Subject: Re: type-of In-reply-to: Robert W. Kerns 's message of Tue, 18 Nov 86 16:04 EST To: RWK@YUKON.SCRC.Symbolics.COM cc: common-lisp@SU-AI.ARPA Message-ID: <861118-152408-2377@Xerox> Here's a proposed level of specificity for type-of and subtypep which would be an improvement: Let Z be the set of "well-behaved" type specifiers. (To be listed). Then, for all Z: For all data X: if (typep x Z) => (subtypep (type-of x) z) This says that type-of has to return something specific enough that subtypep can deal with it. My candidate set of "well-behaved" subtypes are exactly those that are required to be distinct in Common Lisp: array, number, integer, complex, float, symbol, ratio, rational... This (a) isn't hard (b) is probably implemented by most common lisps anyway. The exact set of types identified as "well-behaved" is debatable, but I think it is wise to leave out any implementation dependent types, (long-float vs short-float, fixnum vs bignum), all of the non-intrinsic types (satisfies), or require the relation to be true of any types that are hard to calculate (things like nested ands and ors). There may be a more specific stringent specification of type-of and subtypep that people want to adopt, but its hard to imagine something *less* specific than this, yet this seems adequate for most of the purposes I know of.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 18 Nov 86 18:16:21 EST Received: from UTAH-CS.ARPA by SAIL.STANFORD.EDU with TCP; 18 Nov 86 14:53:59 PST Received: by utah-cs.ARPA (5.31/4.40.2) id AA21982; Tue, 18 Nov 86 15:55:05 MST Received: by utah-orion.ARPA (5.31/4.40.2) id AA11049; Tue, 18 Nov 86 15:49:29 MST Date: Tue, 18 Nov 86 15:49:29 MST From: shebs%utah-orion@utah-cs.arpa (Stanley T. Shebs) Message-Id: <8611182249.AA11049@utah-orion.ARPA> To: common-lisp@su-ai.arpa Subject: Packages I haven't found packages to be as much of a headache as some people on this list. They were both a pain and a necessity for PCLS, because the code is sort of half PSL and half CL, and many symbols of the same name exist in both packages (the psl: and lisp: packages don't use each other). User-type code (at least around here) tends to use packages sparingly - a program doesn't get its own package until it has a fat user manual and a community of users :-). As a consequence, adding the package operations occurs late in development, after the program has stabilized somewhat. Since there are no explicit package references in the source, there is a strong inducement to avoid adding explicit internal symbol references all over the place. The package fixes that have been proposed seem to me like bandaids, and not worth the effort. A *real* solution would promote environments to full first-class objects, and provide some good protocols for operating on them. Look to T for a first attempt, and to Eulisp for more concentrated efforts to get it right. Somehow, I don't see it ever getting into the present form of CL. (Strange how CL is starting to look a little dated here and there...) stan  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 18 Nov 86 16:29:49 EST Received: from SCRC-YUKON.ARPA by SAIL.STANFORD.EDU with TCP; 18 Nov 86 13:04:32 PST Received: from WHITE-BIRD.SCRC.Symbolics.COM by YUKON.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 121418; Tue 18-Nov-86 16:02:39 EST Date: Tue, 18 Nov 86 16:04 EST From: Robert W. Kerns Subject: type-of To: Masayuki Ida cc: common-lisp@SU-AI.ARPA, ida%u-tokyo.junet@RELAY.CS.NET In-Reply-To: <8611170906.AA16158@ccut.u-tokyo.junet> Message-ID: <861118160431.3.RWK@WHITE-BIRD.SCRC.Symbolics.COM> I'm considering writing a paper on the type system and the role of SUBTYPEP. (I've been working on an extension of the type system for the last year or so). Your question really relates to one of the core issues of this topic. I can think of a lot of analogies for TYPE-OF and SUBTYPEP, and maybe I'll develop one of them for the paper, but they all boil down to SELECTION of an object, and matching the object with something which ACCEPTS objects. The exact token which passes between the object and the acceptor of objects doesn't matter, so long as the information is there! Viewed in the abstract, it should be clear that the more information this token has, the more flexibility the acceptor has in deciding whether this object is suitable. The tokens, of course, are the type specifiers. The acceptor can be TYPE-CASE, CHECK-TYPE, or any function which handles only a certain range of types. And SUBTYPEP/TYPEP is what answers the question "is this object suitable." Given this model, there is no such thing as "too specific" an answer from TYPE-OF. On the contrary, the concern should be with "not specific enough". To address your specific points: Date: Mon, 17 Nov 86 18:06:12+0900 From: Masayuki Ida Is it absolutely impossible to define TYPE-OF more specific than the current CLtL ? I have been seen many problems derived from the underspecification of TYPE-OF. As one of the users of PCL since Feb. on several different CommonLisp implementation, I felt PCL might get more portability if TYPE-OF can be more defined. TYPE-OF's >>lack<< of restriction is essential for portability. It is SUBTYPEP which needs to be more carefully defined. I had sent a mail to several key persons about the possiblity of new definition of TYPE-OF, but thier answers were pesimistic to do so. The main reason of them is 'it is impossible or very hard to determine "the most-specific type" among lots of CL implementations.' It is wrong and impossible to define "the most-specific type". What you want to specify is the "least-specific type". I.e. we should specify that it must return a type *at least as specific as* X. X is then the LEAST-SPECIFIC type which TYPE-OF may return; it may, however, return something a good deal more specific. And it should, if at all possible. For example, TYPE-OF of a number must return one of INTEGER, COMPLEX, FLOAT, RATIO, or one of their subtypes (if any), or some other subtype of NUMBER. However, it is not good enough for it to return NUMBER. However, it does not make sense to specify that TYPE-OF return one of FIXNUM or BIGNUM, rather than INTEGER; a system which implemented all numbers as "BIGNA" would be correct, if inefficient. And a system might reasonably have two kinds of BIGNUM's, NEGATIVE-BIGNUM and POSITIVE-BIGNUM. If you specify that TYPE-OF return just BIGNUM, you prevent any program from distinguishing between them, when it may be the program's advantage to make the distinction. By over-specifying TYPE-OF, you can eliminate any implementation flexibility or extensibility. Along with this flexibility in what TYPE-OF returns goes a requirement that SUBTYPEP know the answer when comparing the result of TYPE-OF and whatever "least-specific type" that is specified. For example, if TYPE-OF returns POWER-OF-TWO-POSITIVE-BIGNUM, SUBTYPEP must return the values T T when asked if this is a subtype of BIGNUM, of INTEGER, and of NUMBER. SUBTYPEP is the only predicate provided for comparing types; it goes without saying that any code that uses something else like EQUAL will not be portable. Any type you get back from TYPE-OF you must interpret with SUBTYPEP. Here is an example of completely-portable code which depends on TYPE-OF returning the MOST specific type. (defun store-in-array-if-fits (object array &rest indicies) (let ((object-type (type-of object)) (array-type (array-element-type array))) (if (subtypep object-type array-type) ;; If the object fits, store it (setf (apply #'aref array indicies) object) ;; Doesn't fit, so store 0 instead. (setf (apply #'aref array indicies) 0)))) SUBTYPEP does explicitly the comparison that TYPEP does implicitly when given an object and a type. For example, when you write (TYPEP FOO 'BIGNUM) you don't have to worry about whether the BIGNUM type is split into POWER-OF-TWO-BIGNUM and NON-POWER-OF-TWO-BIGNUM's. Yet, a programmer writing lower-level code can use the same primitive to distinguish the two cases. For example: (defun count-bits (integer) (type-case integer (fixnum (count-fixnum-bits integer)) ;; Easy BIGNUM case (positive-power-of-two-bignum 1) ;; All other BIGNUM's (bignum (count-general-bignum-bits integer)))) This is the reason for the "most-specific" requirement in 2.15. If I implement the type (ARRAY POSITIVE-POWER-OF-TWO-BIGNUM) efficiently (by just storing the exponent), my first example continues to work, so long as TYPE-OF returns the most-specific type. If it instead just returned BIGNUM, as you propose, there would be no way to write code which would decide whether this particluar type of number will fit in this particular type of array. I know there are many implementation designs and we cannot standardize it. But, on the langauage specification level not on the hardware level, we can define "the most specific type" of object according to 2.15 of CLtL. Or 2.15 of CLtL should be updated to copy with TYPE-OF. I had wrote a hierarchy chart based on 2.15. which is attached on the japanese edition of CLtL. Here is a brief sketch of it. The english version of CLtL would be clearer if it included something like this. T>{pathname,stream,hash-table,readtable,package,random-state, sequence,symbol,array,character,number} sequence>{list,vector} list>{cons,null} symbol>{null} array>{vector,simple-array} vector>{string,bit-vector} simple-array>{simple-string,simple-bit-array,simple-vector} string>{simple-string} bit-vector>{simple-bit-vector} charcter>{string-char} string-char>{standard-char} number>{rational,float,complex} rational>{integer,ratio} integer>{fixnum,bignum} float>{short-float,single-float,double-float,long-float} where 'a>b' means 'a is the direct super of b, or b is just connected to a as a direct subtype' I tried to define 'terminal types' terminal-types={pathname,stream,hash-table,readtable,package, random-state,cons,null,simple-string, simple-bit-vector,simple-vector,standard-char,fixnum,bignum, ratio,short-float,single-float,double-float,long-float,complex} terminal-types are types which do not appear on the left of the above '>'. (keyword type was not appeared in 2.15, so keyword is not included here.) Roughly, I imagine the value of TYPE-OF should be, the symbol (not the list) of the most specific type among terminal-types or higher types which are listed above or nil. (do not permit the lower hardware dependent types) ** REQUIRE ** the lower hardware dependent types. 'nil' is for undefined object, say unreadable objects. No, not NIL. T would be a better choice here than NIL! First, there are several kinds of unreadable objects which already have types, such as COMPILED-FUNCTION. Second, NIL is defined to be the *empty* type, that is *no* objects are of type NIL. There is nothing wrong with having an UNDEFINED type, however. NIL will be a subtype of UNDEFINED, of course, and UNDEFINED will be a subtype of T. I am writing an educational CommonLoops interpreter (the first version was represented at the conf. of JSSST and IPSJ). in it, I have a strong desire to get the firm definition of TYPE-OF. More important is a firm definition of SUBTYPEP! SUBTYPEP is the key to using the result of TYPE-OF. I also have a suggestion from friends that 'there is a CLASS-OF in PCL'. but CLASS-OF also need the detailed definition on the built-in-classes. If CLASS-OF is the right things to discuss, I have no problem to shift the discussion to CLASS-OF. CLASS-OF is not the issue here. Masayuki Ida PS: there is no Ethernet-like link between US and Japan. (though there is a firm link between us) So, my response will be not timely. Sorry.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 18 Nov 86 16:17:47 EST Received: from VAXA.ISI.EDU by SAIL.STANFORD.EDU with TCP; 18 Nov 86 12:57:06 PST Received: by vaxa.isi.edu (4.12/4.7) id AA08142; Tue, 18 Nov 86 12:57:19 pst Message-Id: <8611182057.AA08142@vaxa.isi.edu> Date: 18 Nov 1986 1257-PST (Tuesday) To: COMMON-LISP@SU-AI.ARPA From: wile@ISI-VAXA Subject: Packages: a modest solution. Aha! I finally figured out the solution to the package problem! I believe inclusion of packages is the worst mistake in Common LISP's design. There isn't a day goes by (when I actually get to program or debug) when I don't have package problems. Often, they dominate the debugging time. I now type :: all the time, just so I don't have to think about whether the reader can figure out the right default. I truly miss the days when a symbol was a symbol--surely one of the most elegant features of Lisp 1.0 that's been lost. But, of course, almost everyone feels this way. They just don't know how to get around the problems packages seem to solve. Actually, I believe that object-oriented programming generic functions solve about half the problems packages are meant to solve; but they're not in Common LISP yet. Everyone also realizes that the "mistake" is in tying package determination to the reader. The reader simply has so little context that to determine where a symbol belongs has to be done very stupidly. The solution ultimately has to be a combination of the following: * determining the appropriate package becomes trivial, unnecessary or meaningless (keywords, generic functions, English commentary, lexically scoped variables and functions(!), or symbols with explicitly provided package names); * more sophisticated programs determine the package after reading has occurred (during a sort of "package expansion" phase); i.e., admit that Lisp has a parser. It is worth noting that the former category constitutes the bulk of the symbols used in programs, and that getting these symbols in the "wrong" package is the source of so much frustration and futility. To move toward this future world, in which package determination becomes decoupled from the reader, we simply need to make UNINTERNED symbol be the MOST common symbol to be used. The reader must be able to be told not to use default package. A solution might be to allow the read function to be passed a package determiner function, as an optional (keyword) argument. The determiner takes the result from read (uninterned symbols when no package was explicitly given via : or :: and a symbol was read) and returns the package expanded expression. Notice, I am not assuming that reading a symbol is the only result of read. In particular, the intelligent determination of packages comes from calling the package determiner on S-expressions returned by the reader (full of uninterned symbols and symbols with explicitly specified packages). I'm not claiming that it will be easy to write such functions (if it were, having the reader itself determine the package might be easy); I'm simply claiming that it's worth it! This must be defined carefully. At first blush, it may seem that the reader should not invoke the package expander in a bottom up fashion. Only the top level expression should be given to the expander. Then the expander could be allowed to smash structure. This assumes no read macros return previously defined structure (an invalid assumption, generally). Alternatively, perhaps the expander should be called on every sub-expression, with an extra argument indicating whether the top level expression is being passed. Clearly, the reader should be able to assume that if an uninterned symbol is determined to mean an interned symbol that the uninterned symbol can be deleted if it just created it... Present implementations of uninterned symbols cannot support this determiner idea well. To support this, uninterned symbols should print out very normally, perhaps in lower case without bars, instead of #:.... These symbols should be full-fledged symbols with values and function cells. Obviously, I am proposing that they not be syntactically distinguishable from interned symbols. Should (MAKE-SYMBOL "a") be EQ to itself (it isn't on Symbolics implementations). Is there any other way to create the uninterned symbol with that name? Comments? Dave Wile P.S. I am looking for conventions that make packages easier to live with. Since I have converted code from an existing Interlisp implementation in which all my global symbols were prefixed, I found using explicit package prefixes on all exported symbols (for emphasis) whereever they occur to be convenient. Naturally, I hid all the others and dropped the prefix. Any other folklore on this?  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 18 Nov 86 14:20:25 EST Received: from UR-ACORN.ARPA by SAIL.STANFORD.EDU with TCP; 18 Nov 86 10:57:59 PST Received: from CASHEW.CS.ROCHESTER.EDU (CASHEW.CS.ROCHESTER.EDU) by ACORN.CS.ROCHESTER.EDU via INTERNET with SMTP id 2316; 18 Nov 86 13:57:59 EST Date: Tue, 18 Nov 86 13:58 EST From: Brad Miller Subject: [miller@UR-ACORN.ARPA: Package functions not powerful enough?] To: common-lisp@su-ai.stanford.edu cc: miller@ACORN.CS.ROCHESTER.EDU Message-ID: <861118135804.5.MILLER@CASHEW.CS.ROCHESTER.EDU> Sender: miller@ACORN.CS.ROCHESTER.EDU Organization: University of Rochester, Department of Computer Science Postal-address: 617 Hylan Building, University of Rochester, Rochester NY 14627 Phone: 716-275-7747 Sorry if this is the second time thru - it looked like it bounced the first time. %%%%Forwarded Message%%%% From: Brad Miller Subject: Package functions not powerful enough? To: common-lisp@su-ai.stanford.edu Sender: miller@UR-ACORN.ARPA Hi all. I'm having a problem, which I think revolves around the package functions not really being powerful enough to "do the job" correctly. Here is an instance of the problem, since it is best illustrated by example: Assume the packages FOO and BAR, where FOO is on BAR's USE list. Assume that BAR has some symbol interned and marked as external, say 'frotz. The problem is, that given this package layout is part of some program implementation (i.e. not meant to be seen by the user) and the program wants to intern 'frotz as an external symbol in FOO, so any other packages that USE FOO would see this new definition. The program "knows" about 'frotz in BAR and wants BAR to shadow it's own definition of 'frotz over FOO's. (in fact, we can even assume it was interned with SHADOW). The problem is that there is no way to export the symbol from FOO without getting an error, because of the possible conflict with the symbol in BAR. What I would like is some capability to supply an option to EXPORT, like "export this symbol, and for any package there is a name conflict, make the local symbol shadow the newly exported one" or vice versa, etc., rather than makeing the user do it via the debugger. The only extremely crufty solution to this problem with the existing tools seems to be to unintern 'frotz from BAR, intern it in FOO, export it, then SHADOW it in BAR. Since in a more realistic example the number of packages 'frotz could be in is potentially large, this doesn't seem to be the best of plans, since each value of 'frotz must also be stored temporarily in the interim. To generalize the suggestion, I think that functions which have the opportunity of creating name conflicts (as defined in section 11.5 CLtL) should also allow the programmer to tell the system how they should be resolved in advance. (This is an upwards compatible improvement: the programmer need not give such "advice" and if none is given, the current definition obtains.) Brad Miller PS: reply to miller@rochester.arpa, not the address in the header, it will bounce. ------ miller@rochester.arpa miller@ur-acorn.arpa %%%%End Forwarded Message%%%% ------ miller@rochester.arpa miller@ur-acorn.arpa  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 18 Nov 86 11:34:14 EST Received: from UR-ACORN.ARPA by SAIL.STANFORD.EDU with TCP; 18 Nov 86 08:11:54 PST Received: from CASHEW.CS.ROCHESTER.EDU (CASHEW.CS.ROCHESTER.EDU) by ACORN.CS.ROCHESTER.EDU via INTERNET with SMTP id 2310; 18 Nov 86 11:12:21 EST Date: Tue, 18 Nov 86 11:12 EST From: Brad Miller Subject: Package functions not powerful enough? To: CL@ACORN.CS.ROCHESTER.EDU cc: miller@ACORN.CS.ROCHESTER.EDU Message-ID: <861118111222.3.MILLER@CASHEW.CS.ROCHESTER.EDU> Sender: miller@ACORN.CS.ROCHESTER.EDU Organization: University of Rochester, Department of Computer Science Postal-address: 617 Hylan Building, University of Rochester, Rochester NY 14627 Phone: 716-275-7747 Hi all. I'm having a problem, which I think revolves around the package funtions not really being powerful enough to "do the job" correctly. Here is an instance of the problem, since it is best illustrated by example: Assume the packages FOO and BAR, where FOO is on BAR's USE list. Assume that BAR has some symbol interned and marked as external, say 'frotz. The problem is, that given this package layout is part of some program implementation (i.e. not meant to be seen by the user) and the program wants to intern 'frotz as an external symbol in FOO, so any other packages that USE FOO would see this new definition. The program "knows" about 'frotz in BAR and wants BAR to shadow it's own definition of 'frotz over FOO's. (in fact, we can even assume it was interned with SHADOW). The problem is that there is no way to export the symbol from FOO without getting an error, because of the possible conflict with the symbol in BAR. What I would like is some capability to supply an option to EXPORT, like "export this symbol, and for any package there is a name conflict, make the local symbol shadow the newly exported one" or vice versa, etc., rather than makeing the user do it via the debugger. The only extremely crufty solution to this problem with the existing tools seems to be to unintern 'frotz from BAR, intern it in FOO, export it, then SHADOW it in BAR. Since in a more realistic example the number of packages 'frotz could be in is potentially large, this doesn't seem to be the best of plans, since each value of 'frotz must also be stored temporarily in the interim. To generalize the suggestion, I think that functions which have the opportunity of creating name conflicts (as defined in section 11.5 CLtL) should also allow the programmer to tell the system how they should be resolved in advance. (This is an upwards compatible improvement: the programmer need not give such "advice" and if none is given, the current definition obtains.) Brad Miller PS: reply to miller@rochester.arpa, not the address in the header, it will bounce. ------ miller@rochester.arpa miller@ur-acorn.arpa  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 17 Nov 86 18:21:56 EST Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 17 Nov 86 15:03:51 PST Received: ID ; Mon 17 Nov 86 18:03:28-EST Date: Mon, 17 Nov 1986 18:03 EST Message-ID: From: Rob MacLachlan To: Masayuki Ida Cc: common-lisp@SU-AI.ARPA, ida%u-tokyo.junet@RELAY.CS.NET Subject: type-of In-reply-to: Msg of Mon 17 Nov 86 18:06:12+0900 from Masayuki Ida I think that your suggestion is contrary to the intent of the specification. The "most specific" type can hardly ever be represented by symbol, since there is almost always a more specific type that does make use of a list type-specifier. Although it is difficult to specify just how specific the type must be, it is clearly a step in the wrong direction to require it to be a symbol. It would also be wrong for NIL to be returned to indicate a random object, since NIL is a meaningful type, but not one that any object can posess. It would make more sense to return T or a new type such as RANDOM. I also have some doubts about the need to specify what Type-Of returns. Could you demonstrate some code that needs to use Type-Of and is adversely affected by different implementations? I suppose that we could rigorously specify some function that does what you want, but it shouldn't be Type-Of. Rob  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 17 Nov 86 05:30:52 EST Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 17 Nov 86 02:18:18 PST Received: from utokyo-relay by csnet-relay.csnet id ab05487; 17 Nov 86 5:12 EST Received: by u-tokyo.junet (4.12/4.9J-1[JUNET-CSNET]) id AA04493; Mon, 17 Nov 86 18:10:46+0900 Received: by ccut.u-tokyo.junet (4.12/6.1Junet) id AA16158; Mon, 17 Nov 86 18:06:12+0900 Date: Mon, 17 Nov 86 18:06:12+0900 From: Masayuki Ida Message-Id: <8611170906.AA16158@ccut.u-tokyo.junet> To: common-lisp@SU-AI.ARPA, ida%u-tokyo.junet@RELAY.CS.NET Subject: type-of Is it absolutely impossible to define TYPE-OF more specific than the current CLtL ? I have been seen many problems derived from the underspecification of TYPE-OF. As one of the users of PCL since Feb. on several different CommonLisp implementation, I felt PCL might get more portability if TYPE-OF can be more defined. I had sent a mail to several key persons about the possiblity of new definition of TYPE-OF, but thier answers were pesimistic to do so. The main reason of them is 'it is impossible or very hard to determine "the most-specific type" among lots of CL implementations.' I know there are many implementation designs and we cannot standardize it. But, on the langauage specification level not on the hardware level, we can define "the most specific type" of object according to 2.15 of CLtL. Or 2.15 of CLtL should be updated to copy with TYPE-OF. I had wrote a hierarchy chart based on 2.15. which is attached on the japanese edition of CLtL. Here is a brief sketch of it. T>{pathname,stream,hash-table,readtable,package,random-state, sequence,symbol,array,character,number} sequence>{list,vector} list>{cons,null} symbol>{null} array>{vector,simple-array} vector>{string,bit-vector} simple-array>{simple-string,simple-bit-array,simple-vector} string>{simple-string} bit-vector>{simple-bit-vector} charcter>{string-char} string-char>{standard-char} number>{rational,float,complex} rational>{integer,ratio} integer>{fixnum,bignum} float>{short-float,single-float,double-float,long-float} where 'a>b' means 'a is the direct super of b, or b is just connected to a as a direct subtype' I tried to define 'terminal types' terminal-types={pathname,stream,hash-table,readtable,package, random-state,cons,null,simple-string, simple-bit-vector,simple-vector,standard-char,fixnum,bignum, ratio,short-float,single-float,double-float,long-float,complex} terminal-types are types which do not appear on the left of the above '>'. (keyword type was not appeared in 2.15, so keyword is not included here.) Roughly, I imagine the value of TYPE-OF should be, the symbol (not the list) of the most specific type among terminal-types or higher types which are listed above or nil. (do not permit the lower hardware dependent types) 'nil' is for undefined object, say unreadable objects. I am writing an educational CommonLoops interpreter (the first version was represented at the conf. of JSSST and IPSJ). in it, I have a strong desire to get the firm definition of TYPE-OF. I also have a suggestion from friends that 'there is a CLASS-OF in PCL'. but CLASS-OF also need the detailed definition on the built-in-classes. If CLASS-OF is the right things to discuss, I have no problem to shift the discussion to CLASS-OF. Masayuki Ida PS: there is no Ethernet-like link between US and Japan. (though there is a firm link between us) So, my response will be not timely. Sorry.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 14 Nov 86 13:08:00 EST Received: from MCC.COM by SAIL.STANFORD.EDU with TCP; 14 Nov 86 09:54:39 PST Date: Fri, 14 Nov 1986 11:52 CST Message-ID: From: AI.BOYER@MCC.COM To: common-lisp@su-ai Subject: sloop Bill Schelter has produced a lovely Common Lisp substitute for the Maclisp/Zetalisp loop construct called sloop. It is mostly upwards compatible with loop. This note describes where to get it, what's new, etc. Fahlman observes that any detailed discussion of the merits of this package should be directed to the cl-iteration mailing list. Sloop sources may be found in the file sloop.lisp on utexas-20.edu. The code is free. It was written by Schelter from scratch and is hence definitely free of any MIT or lisp machine company copyright claim. Like the original I.S.OPR facility in Interlisp, the sloop construct permits the addition of new "collection" type operators; for example, an averaging operation is defined. A very general facility different from that of loop's has been implemented to provide user extensible iteration paths. One can map over tree fringes, Common Lisp hash tables, or packages, e.g. (sloop for sym in-package 'user when (fboundp sym) collect sym). A "cross-product" concept has been added. Instead of writing something like: (loop for x in (l1) nconc (loop for y in (l2) collect (fn x y))) one may write: (sloop for x in (l1) sloop (for y in (l2) collect (fn x y))) Only one "collection site" is created and used during these two nested iterations. Like the original loop, sloop takes advantage of locatives to do collection more efficiently when they are available, e.g., on MIT type lisp machines. Sloop has been run in at least four dialects of Common Lisp on three different kinds of machines. I believe Schelter is definitely interested in reports of bugs and suggestions for improvements. Mail will reach him at atp.schelter@utexas-20.edu or at the Mathematics Department, University of Texas at Austin, Austin, Texas 78712.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 12 Nov 86 17:50:11 EST Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 12 Nov 86 14:34:58 PST Date: Wed, 12 Nov 1986 17:34 EST Message-ID: From: STEVER%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU To: common-lisp%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU Subject: Declarations within FLET Is there any reason why declarations aren't permitted before the body of an FLET? They ARE permitted before the body of a LET... Stever  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 11 Nov 86 16:12:59 EST Received: from LIVE-OAK.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 11 Nov 86 12:59:53 PST Received: from MIT-CHERRY.ARPA by MIT-LIVE-OAK.ARPA via CHAOS with CHAOS-MAIL id 16388; Tue 11-Nov-86 15:49:47-EST Date: Tue, 11 Nov 86 15:50 EST From: Soley@MIT-XX.ARPA Subject: Why is #'equalp not allowed in make-hash-table ? To: common-lisp@SU-AI.ARPA In-Reply-To: <8611071916.AA06073@bhopal.edsel.uucp> Message-ID: <861111155021.1.SOLEY@CHERRY.LCS.MIT.EDU> Along that line I wonder why the default isn't :test = #'EQUAL, rather than #'EQL? For symmettry with ASSOC, MEMBER, DELETE, REMOVE, etc. -- Richard  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 11 Nov 86 15:37:30 EST Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 11 Nov 86 12:20:36 PST Received: by navajo.stanford.edu; Tue, 11 Nov 86 12:17:26 PST Received: from bhopal.edsel.uucp by edsel.uucp (2.2/SMI-2.0) id AA03376; Fri, 7 Nov 86 11:17:31 pst Received: by bhopal.edsel.uucp (1.1/SMI-3.0DEV3) id AA06073; Fri, 7 Nov 86 11:16:24 PST Date: Fri, 7 Nov 86 11:16:24 PST From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White) Message-Id: <8611071916.AA06073@bhopal.edsel.uucp> To: navajo!sridhar%tekchips.tek.csnet%RELAY.CS.NET@navajo.stanford.edu Cc: navajo!common-lisp%su-ai.arpa@navajo.stanford.edu In-Reply-To: navajo!sridhar%tekchips.tek.csnet@RELAY.CS.NET's message of 06 Nov 86 11:43:08 PST (Thu) Subject: Why is #'equalp not allowed in make-hash-table ? About a year or so ago, there were two points about hash-tables receiving heavy discussion: 1) Why not permit any predicate of two arguments as the :test argument 2) Why not permit explicit specification of the "sxhashing" function. Several implementations, Lucid's included, have the capability of doing (1) with no extra work. However, the question posed by (2) raises the issue of consistency between the "numericalizing" function [i.e., whatever you might use in place of sxhash] and the "equivalencing" function [i.e., whatever you might use in place of equal]. Although there didn't seem to be general consensus on the issue, the proposal that seemed most consistent to me was: (A) Extend Common Lisp hash-tables to permit any two-argument predicate to be used as a :test function; and add an :sxhash argument which specifies the function to reduce an s-expression into the integer used in computing the collision chains (assuming you hash that way). (B) The default for the :sxhash argument for EQ/EQL type tables can be something internal (probably not documented or exported); the default for any other :test argument will be #'equal. This permits the extensions without having to address the issue of having a function which computes the address of a pointer (for EQ/EQL tables). Along that line I wonder why the default isn't :test = #'EQUAL, rather than #'EQL? (or better yet, #'EQUALP). The EQ/EQL semantics is almost never right when the table contains "complex" structures like lists, vectors, defstructs and so on, and typically has unfortunate consequences for relocating garbage collectors. Yet an EQUAL table can be just as "speedy" as an EQ/EQL one when the entries aren't such "complex" entities; so one should never try to switch semantics merely for "speed". This doesn't say that there is no place for EQ/EQL tables -- merely that they are often used for the wrong reasons. -- JonL --  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 10 Nov 86 22:33:49 EST Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 10 Nov 86 19:21:11 PST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 155303; Mon 10-Nov-86 22:19:54 EST Date: Mon, 10 Nov 86 22:19 EST From: David A. Moon Subject: Why is #'equalp not allowed in make-hash-table ? To: sridhar%tekchips.tek.csnet@RELAY.CS.NET cc: common-lisp@SU-AI.ARPA In-Reply-To: <8611061943.AA13331@tekchips.TEK> Message-ID: <861110221911.5.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: 06 Nov 86 11:43:08 PST (Thu) From: sridhar%tekchips.tek.csnet@RELAY.CS.NET I want to create a hash table in which the keys are lisp objects that satisfy #'equalp. CLtL does not allow #'equalp in :test argument to make-hash-table. Why? The :test argument to make-hash-table is not user-extensible because of the nature of hashing. Each :test function has to have a corresponding hashing function, which maps from an object to an integer that can be used as an index into the hash table. These two functions have to be consistent in the sense that for any two objects A and B, if the test function returns true when applied to A and B, then the hash function must return the same integer for both A and B. Because Common Lisp didn't want to provide portable ways for users to write hashing functions (in general this requires implementation dependent knowledge to do a good job), Common Lisp doesn't allow arbitrary predicates to be provided for the :test argument. I think your suggestion that equalp be added to the set of allowed predicates is a good one.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 7 Nov 86 13:45:39 EST Received: from [128.81.51.3] by SAIL.STANFORD.EDU with TCP; 7 Nov 86 10:14:45 PST Received: from KOYAANISQATSI.S4CC.Symbolics.COM by DIAMOND.S4CC.Symbolics.COM via CHAOS with CHAOS-MAIL id 25906; Fri 7-Nov-86 13:12:59 EST Date: Fri, 7 Nov 86 13:12 EST From: David C. Plummer Subject: DEFVAR To: Scott E. Fahlman , Kent M Pitman cc: Common-Lisp@SU-AI.ARPA In-Reply-To: Message-ID: <861107131230.3.DCP@KOYAANISQATSI.S4CC.Symbolics.COM> Date: Mon, 20 Oct 1986 13:45 EDT From: "Scott E. Fahlman" CLtL (p68) is not explicit on its intent about whether (DEFVAR FOO) is allowed to or intended to intialize FOO. I believe that everyone's intent was that (DEFVAR FOO) should leave FOO unbound. I would have sworn that the manual said this, but I guess it doesn't. Given that and the current syntax, there is the question of how the user is supposed to supply a doc string for the variable if no initial value is wanted. This was discussed in the past on one or two occasions. I think the general feeling was that SETF of DOCUMENTAITON was good enough in the rare case where this functionality is needed. I personally preferred the (defvar foo foo "foo's doc string") suggestion since that is one declarative form instead of (defvar foo) (setf (documentation 'foo) "foo's doc string") on the grounds that the latter is two forms, one declarative and one procedural, and is more clumsy. It's not at all clear this is "rare".  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 7 Nov 86 00:30:42 EST Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 6 Nov 86 21:20:25 PST Received: from tektronix by csnet-relay.csnet id aa05236; 6 Nov 86 15:46 EST Received: by tektronix.TEK (5.31/6.16) id AA12988; Thu, 6 Nov 86 11:43:04 PST Received: by tekchips.TEK (5.31/6.16) id AA13331; Thu, 6 Nov 86 11:43:11 PST Message-Id: <8611061943.AA13331@tekchips.TEK> To: common-lisp@SU-AI.ARPA Subject: Why is #'equalp not allowed in make-hash-table ? Date: 06 Nov 86 11:43:08 PST (Thu) From: sridhar%tekchips.tek.csnet@RELAY.CS.NET I want to create a hash table in which the keys are lisp objects that satisfy #'equalp. CLtL does not allow #'equalp in :test argument to make-hash-table. Why? Specifically I cannot have vectors as key values. For instance , how can you create a hash-table such that: (setf (gethash (setq a (vector 1 2 3)) hash-table) 'foo) (gethash a hash-table) => FOO T (gethash (vector 1 2 3 ) hash-table) => FOO T. --sridhar  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 3 Nov 86 23:17:35 EST Received: from LIVE-OAK.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 3 Nov 86 19:38:42 PST Received: from GOLD-HILL-ACORN.DialNet.Symbolics.COM (DIAL|DIAL|4925473) by MIT-LIVE-OAK.ARPA via DIAL with SMTP id 15523; 3 Nov 86 22:37:26-EST Received: from BOSTON.Gold-Hill.DialNet.Symbolics.COM by ACORN.Gold-Hill.DialNet.Symbolics.COM via CHAOS with CHAOS-MAIL id 43523; Mon 3-Nov-86 21:12:54-EST Date: Mon, 3 Nov 86 22:13 est Sender: mike@acorn To: RAM@C.CS.CMU.EDU From: mike%acorn@mit-live-oak.arpa Subject: DEFSTRUCT copier query Cc: samalone@ATHENA.MIT.EDU, common-lisp@SU-AI.ARPA Date: Mon, 3 Nov 1986 10:54 EST From: Rob MacLachlan Date: Monday, 3 November 1986 10:17-EST From: Re: DEFSTRUCT copier query (copy-bread (make-rye-bread :state 'stale :seeded-p nil)) A: #S(RYE-BREAD :STATE STALE :SEEDED-P NIL) or B: #S(BREAD :STATE STALE) This unclarity has been pointed out before, but there didn't seem to be any real consensus. I agree that it seems to be semantically cleaner to return an object of the same type as the argument. I think the only reasonable alternative would be to say that it is erronous. Since there doesn't seem to be any support for B, no one can complain if you implement A, although it may not be required for Common Lisp. Rob While we're at it, there are alot of problems with inheritance in defstruct. Another is, (defun (foo (:print-function (lambda ...))) (defun (bar (:include foo)) slot1 slot2) Now, does bar have a print function inherited from foo? Clearly it can't inherit the constructor function from foo since it doesn't have the same slots as foo, but the print function is more at issue. I think we should define :include to include only slots, and not any other functions by options. If CommonLoops catches on, and if the defstruct syntax is chosen, then we can specify the inheritance for objects of class STRUCTURE to be only this, and you can use a different class for inheriting other stuff. ....mike beckerle Gold Hill Computers  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 3 Nov 86 22:56:40 EST Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 3 Nov 86 19:36:48 PST Received: from Salvador.ms by ArpaGateway.ms ; 03 NOV 86 18:14:13 PST Date: 3 Nov 86 18:13 PST Sender: Bobrow.pa@Xerox.COM Subject: Re: DEFSTRUCT copier query In-reply-to: Pavel.pa's message of 3 Nov 86 11:57 PST To: Pavel.pa@Xerox.COM cc: RAM@C.CS.CMU.EDU, samalone@ATHENA.MIT.EDU, common-lisp@SU-AI.ARPA From: Danny Bobrow Message-ID: <861103-181413-5511@Xerox> Date: Mon, 3 Nov 86 10:54 EST From: Rob MacLachlan Date: Monday, 3 November 1986 10:17-EST From: (copy-bread (make-rye-bread :state 'stale :seeded-p nil)) A: #S(RYE-BREAD :STATE STALE :SEEDED-P NIL) or B: #S(BREAD :STATE STALE) Since there doesn't seem to be any support for B, no one can complain if you implement A, although it may not be required for Common Lisp. I can complain, and I would. I am strongly of the opinion that the function COPY-BREAD here should always create a value of type BREAD, not one of its subtypes. If you want to get the effect of A, let us create a new function COPY that copies any Lisp value at all. It seems strange to have several such functions, one for each section of the type space. I claim that such a function, along with COPY-BREAD having semantics B above, would provide all of the functionality desired in the cleanest way. Pavel Within the new emerging Common Lisp Object Standard, COPY will be specified as a generic function that copies its argument, producing an instance of the same type. Functions such as copy-bread would be an anomaly, but could mean what Pavel suggested. -- danny  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 3 Nov 86 16:54:05 EST Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 3 Nov 86 12:49:53 PST Received: from Cabernet.ms by ArpaGateway.ms ; 03 NOV 86 11:57:47 PST Date: 3 Nov 86 11:57 PST From: Pavel.pa@Xerox.COM Subject: Re: DEFSTRUCT copier query In-reply-to: Rob MacLachlan 's message of Mon, 3 Nov 86 10:54 EST To: RAM@C.CS.CMU.EDU cc: samalone@ATHENA.MIT.EDU, common-lisp@SU-AI.ARPA Message-ID: <861103-115747-5004@Xerox> Date: Mon, 3 Nov 86 10:54 EST From: Rob MacLachlan Date: Monday, 3 November 1986 10:17-EST From: (copy-bread (make-rye-bread :state 'stale :seeded-p nil)) A: #S(RYE-BREAD :STATE STALE :SEEDED-P NIL) or B: #S(BREAD :STATE STALE) Since there doesn't seem to be any support for B, no one can complain if you implement A, although it may not be required for Common Lisp. I can complain, and I would. I am strongly of the opinion that the function COPY-BREAD here should always create a value of type BREAD, not one of its subtypes. If you want to get the effect of A, let us create a new function COPY that copies any Lisp value at all. It seems strange to have several such functions, one for each section of the type space. I claim that such a function, along with COPY-BREAD having semantics B above, would provide all of the functionality desired in the cleanest way. Pavel  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 3 Nov 86 11:14:26 EST Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 3 Nov 86 07:55:07 PST Received: ID ; Mon 3 Nov 86 10:54:15-EST Date: Mon, 3 Nov 1986 10:54 EST Message-ID: From: Rob MacLachlan To: Cc: common-lisp@SU-AI.ARPA Subject: DEFSTRUCT copier query In-reply-to: Msg of 3 Nov 1986 10:17-EST from Date: Monday, 3 November 1986 10:17-EST From: Re: DEFSTRUCT copier query (copy-bread (make-rye-bread :state 'stale :seeded-p nil)) A: #S(RYE-BREAD :STATE STALE :SEEDED-P NIL) or B: #S(BREAD :STATE STALE) This unclarity has been pointed out before, but there didn't seem to be any real consensus. I agree that it seems to be semantically cleaner to return an object of the same type as the argument. I think the only reasonable alternative would be to say that it is erronous. Since there doesn't seem to be any support for B, no one can complain if you implement A, although it may not be required for Common Lisp. Rob  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 3 Nov 86 10:28:10 EST Received: from ATHENA.MIT.EDU by SAIL.STANFORD.EDU with TCP; 3 Nov 86 07:18:31 PST Received: by ATHENA (5.45/4.7) id AA10177; Mon, 3 Nov 86 10:18:01 EST From: Received: by ARES (5.45/4.7) id AA20604; Mon, 3 Nov 86 10:17:13 EST Date: Mon, 3 Nov 86 10:17:13 EST Message-Id: <8611031517.AA20604@ARES> To: common-lisp@sail.stanford.edu Subject: DEFSTRUCT copier query What is the defined behavior of the DEFSTRUCT-created copier function in the face of :INCLUDEd types? For instance, given: (defstruct bread (state 'freshly-baked)) (defstruct (rye-bread (:include bread)) (seeded-p t)) is the result of evaluating: (copy-bread (make-rye-bread :state 'stale :seeded-p nil)) A: #S(RYE-BREAD :STATE STALE :SEEDED-P NIL) or B: #S(BREAD :STATE STALE) I am hoping that the correct answer is A. A function with behavior B can be easily implemented in Common Lisp by any user who needs it, while a function with behavior A cannot be without hardwiring all of the subtypes (recursively) of the structure into the function, which seems like a harsh fate. --Stuart A. Malone  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 31 Oct 86 22:41:45 EST Received: from AI.AI.MIT.EDU by SAIL.STANFORD.EDU with TCP; 31 Oct 86 19:23:42 PST Date: Fri, 31 Oct 86 22:25:47 EST From: Jonathan A Rees Subject: [KLOTZ: defstruct initialization in :constructor ] To: common-lisp@SU-AI.ARPA Message-ID: <[AI.AI.MIT.EDU].113071.861031.JAR> Parameter lists for :CONSTRUCTOR's should act as much as possible like lambda lists. CLtL doesn't require this, but it seems like a good idea. - Jonathan Date: Thu, 2 Oct 86 20:31 EDT From: Leigh L. Klotz To: pgslcd at AI.AI.MIT.EDU cc: jar at AI.AI.MIT.EDU Re: defstruct initialization in :constructor Message-ID: <861002203146.1.KLOTZ@JOE-LOUIS.LCS.MIT.EDU> (DEFSTRUCT (STATIC-VARIABLE-CACHE-ENTRY (:CONSTRUCTOR MAKE-STATIC-VARIABLE-CACHE-ENTRY (REAL-OBJECT &AUX (VARIABLE (CAR REAL-OBJECT)) (UNIQUE-IDENTIFIER (CADR REAL-OBJECT))))) VARIABLE UNIQUE-IDENTIFIER REAL-OBJECT) The silver book doesn't explicitly say that the &aux's can depend on the real args, but it does say that &aux was included to make all desirable behaviors possible, and &aux forms in lambda can depend on the args. ...  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 31 Oct 86 16:47:47 EST Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 31 Oct 86 13:23:55 PST Received: by navajo.stanford.edu; Fri, 31 Oct 86 13:22:27 PST Received: from sunvalleymall.edsel.uucp by edsel.uucp (2.2/SMI-2.0) id AA03857; Fri, 31 Oct 86 12:33:15 pst Received: by sunvalleymall.edsel.uucp (1.1/SMI-3.0DEV3) id AA09846; Fri, 31 Oct 86 12:34:05 PST Date: Fri, 31 Oct 86 12:34:05 PST From: edsel!sunvalleymall!jlz@navajo.stanford.edu (Jan Zubkoff) Message-Id: <8610312034.AA09846@sunvalleymall.edsel.uucp> To: navajo!Common-lisp%sail@navajo.stanford.edu Cc: sunvalleymall!jlz@navajo.stanford.edu Subject: Call for Papers LISP AND SYMBOLIC COMPUTATION: An International Journal 10/27/86 CALL FOR PAPERS LISP AND SYMBOLIC COMPUTATION: An International Journal (LASC) is a new journal published by Kluwer Academic Publishers. Richard P. Gabriel, Lucid, Inc. and Guy L. Steele Jr., Thinking Machines, Inc. are Editors-in-Chief. The aim of this new journal is to present a forum for current and evolving symbolic computing, focusing on LISP and object-oriented programming. The scope includes: * Programming language notations for symbolic computing (e.g., data abstraction, parallelism, lazy evaluation, infinite data objects, self-reference, message-passing, generic functions, inheritance, encapsulation, protection, metaobjects). * Implementations and techniques (e.g., specialized architectures, compiler design, combinatory models, garbage collection, storage management, performance analysis, smalltalks, flavors, common loops, etc.). * Programming logics (e.g., semantics and reasoning about programs, types and type inference). * Programming environments and tools (e.g., Knowledge-based programming tools, program transformations, specifications, debugging tools). * Applications and experience with symbolic computing (e.g., real-time programming, artificial intelligence tools, experience with LISP, object-oriented programming, window systems, user interfaces, operating systems, parallel/distributed computing. ! REQUIREMENTS FOR SUBMISSION Timetable. Authors must submit five (5) complete copies of their papers. Notice of acceptance or rejection will be sent to the first author. Appearance. Each copy of the paper should be clearly legible. Papers should be printed on 8-1/2 by 11" paper, double spaced with at least 1 inch margins with no smaller than 12 pt. type. Title Page. Each copy of the paper must have a title page (separate from the body of the paper) containing the title of the paper, the names and addresses of all the authors. The affiliation appearing under the author's name should be the name of the organization for which the work was carried out. When this is no longer the author's current affiliation, the latter is given in the address footnote on the first page. The title page must specify one topic from the scopes listed on the reverse side of this page. Abstract. The abstract should be 150 to 200 words and should be short and direct. It should be informative enough to serve as a substitute for reading the paper itself. Work planned but not done should not be described in the abstract. Do not display formulas and do not use citation reference numbers. Review Criteria. Each paper will be reviewed by experts in the area specified from the scope as the topic of the paper. Acceptance will be based on overall merit and significance of the reported research, as well as the quality of the presentation. Please send papers to: Jan Zubkoff Associate Editor, LASC Lucid, Inc. 707 Laurel Street Menlo Park, CA 94025 edsel!jlz@su-navajo (415) 329-8400 Suggestions and inquiries to: Dick Gabriel Guy L. Steele Jr. Editor-in-Chief Editor-in-Chief Lucid, Inc. Thinking Machines, Inc. 707 Laurel Street 245 First Street Menlo Park, CA 94025 Cambridge, MA 02142 rpg@sail gls@think.COM (415) 329-8400 (617) 876-1111  Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 21 Oct 86 12:28:46 EDT Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 21 Oct 86 09:13:11 PDT Received: ID ; Tue 21 Oct 86 12:12:19-EDT Date: Tue, 21 Oct 1986 12:12 EDT Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: Brad Miller Cc: common-lisp@SU-AI.ARPA Subject: Applying functions to all the symbols in a package... In-reply-to: Msg of 21 Oct 1986 11:53-EDT from Brad Miller Back when the initial design was being done, we explicitly considered whether to go with MAP-SYMBOLS or DO-SYMBOLS. At the time, it seemed that most of us had the opposite religion from Mr. Miller. Most of us favored the iterative form, and I don't remember anyone arguing for the mapping form. A practical argument is that DO-SYMBOLS typically is used in situations where there are a LOT of symbols must be processed, and in the absence of a very clever compiler the MAP form would be slower due to the need for explicitly calling the supplied functional argument. I don't think that it would be worthwhile to include both forms just to accommodate both stylistic preferences. These facilities are not used often, so the occasional use of a less-favored style should not be a big hardship for anyone. And, of course, fanatical DO-haters can write a MAP-SYMBOLS macro easily enough, and not have to worry about what it expands into. -- Scott  Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 21 Oct 86 12:06:37 EDT Received: from UR-ACORN.ARPA by SAIL.STANFORD.EDU with TCP; 21 Oct 86 08:50:50 PDT Received: from UR-CASHEW.ARPA by UR-ACORN.ARPA via INTERNET with SMTP id 35577; 21 Oct 86 11:52:33-EDT Date: Tue, 21 Oct 86 11:53 EDT From: Brad Miller Subject: Applying functions to all the symbols in a package... To: common-lisp@SU-AI.ARPA cc: miller@UR-ACORN.ARPA Message-ID: <861021115308.3.MILLER@UR-CASHEW.ARPA> Sender: miller@UR-ACORN.ARPA Organization: University of Rochester, Department of Computer Science Postal-address: 617 Hylan Building, University of Rochester, Rochester NY 14627 Phone: 716-275-7747 Moon: 3 days, 13 hours, 15 minutes since the full moon. As a general rule, I find that as a style of coding, MAP and recursion are the most clear, iteration much less so, and GO's the least so. I realize this may be somewhat of a religious issue, so I won't go into why I despise iteration, with the possible exception of array manipulation. For this reason, I am somewhat surprised, that CL has iterative functions for fiddling with all they symbols in a package (i.e. DO-SYMBOLS and DO-EXTERNAL-SYMBOLS but no equivalent MAP forms (e.g. the zetalisp MAPATOMS and MAPATOMS-ALL). This is particularly surprising in light of the fact that almost every other MAP function has equivalent iterations forms, and vice-versa. I would like to suggest that such functions be added to the CL standard. I believe the zetalisp functions mentioned above are sufficient, and provide a clean user interface. This would be a downward compatible upgrade. Brad Miller ------ miller@rochester.arpa miller@ur-acorn.arpa  Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 20 Oct 86 14:01:26 EDT Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 20 Oct 86 10:46:12 PDT Received: ID ; Mon 20 Oct 86 13:45:49-EDT Date: Mon, 20 Oct 1986 13:45 EDT Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: Kent M Pitman Cc: Common-Lisp@SU-AI.ARPA Subject: DEFVAR In-reply-to: Msg of 16 Oct 1986 00:28-EDT from Kent M Pitman CLtL (p68) is not explicit on its intent about whether (DEFVAR FOO) is allowed to or intended to intialize FOO. I believe that everyone's intent was that (DEFVAR FOO) should leave FOO unbound. I would have sworn that the manual said this, but I guess it doesn't. Given that and the current syntax, there is the question of how the user is supposed to supply a doc string for the variable if no initial value is wanted. This was discussed in the past on one or two occasions. I think the general feeling was that SETF of DOCUMENTAITON was good enough in the rare case where this functionality is needed. -- Scott  Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 16 Oct 86 21:13:27 EDT Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 16 Oct 86 18:01:02 PDT Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 135094; Thu 16-Oct-86 13:23:35 EDT Date: Thu, 16 Oct 86 13:22 EDT From: David A. Moon Subject: ADJUST-ARRAY To: Common-Lisp@SU-AI.ARPA In-Reply-To: <861016004039.9.KMP@EMU.SCRC.Symbolics.COM> Message-ID: <861016132226.5.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Thu, 16 Oct 86 00:40 EDT From: Kent M Pitman CLtL (p297) says that it is "not permitted to call ADJUST-ARRAY on an array that was not created with the :ADJUSTABLE option." This strikes me as overly restrictive. Why don't we say that ADJUST-ARRAY always returns an adjusted array and that the argument array will be modified only if (ADJUSTABLE-ARRAY-P array) was true. This is no more unreasonable than the current specification for the DELETE function. I suspect people rely on arrays as updatable objects with identity a lot more often than they rely on lists that way. In other words, if ADJUST-ARRAY sometimes quietly returns a new array and leaves the old one unadjusted, there are likely to be other references to the old array that don't get updated, and hence there will be bugs. I always argued for making all arrays adjustable, for this reason. Given that we can't have that, I think your behavior is reasonable but it should not be the default because it could lead to undetected bugs. I have an application where this comes up and as nearly as I can tell, I must now go and simulate the effect of ADJUST-ARRAY in order to create an array to a new size and make sure it gets filled properly. It makes me sad that I should have to do this when there's a function already that comes so close to what I want. This is a good argument. This is a typical example of where Common Lisp went wrong by standardizing a new, untried idea instead of standardizing current practice, which would be okay except that what was standardized was a bundle of several primitives and the underlying primitives were not exposed, so that users can't easily define functions to hide the deficiencies they feel are present in the standardized bundle. I think there should be a new keyword argument to ADJUST-ARRAY that does what you want, or else a separate function for this purpose, as there was in Zetalisp (ARRAY-GROW). I don't think the default behavior of ADJUST-ARRAY should be changed, for reasons given above. I can't think of any good names for the keyword argument; the best I was able to come up with was :IF-NOT-ADJUSTABLE with values :ERROR and :COPY.  Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 16 Oct 86 19:25:32 EDT Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 16 Oct 86 16:00:38 PDT Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 135094; Thu 16-Oct-86 13:23:35 EDT Date: Thu, 16 Oct 86 13:22 EDT From: David A. Moon Subject: ADJUST-ARRAY To: Common-Lisp@SU-AI.ARPA In-Reply-To: <861016004039.9.KMP@EMU.SCRC.Symbolics.COM> Message-ID: <861016132226.5.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Thu, 16 Oct 86 00:40 EDT From: Kent M Pitman CLtL (p297) says that it is "not permitted to call ADJUST-ARRAY on an array that was not created with the :ADJUSTABLE option." This strikes me as overly restrictive. Why don't we say that ADJUST-ARRAY always returns an adjusted array and that the argument array will be modified only if (ADJUSTABLE-ARRAY-P array) was true. This is no more unreasonable than the current specification for the DELETE function. I suspect people rely on arrays as updatable objects with identity a lot more often than they rely on lists that way. In other words, if ADJUST-ARRAY sometimes quietly returns a new array and leaves the old one unadjusted, there are likely to be other references to the old array that don't get updated, and hence there will be bugs. I always argued for making all arrays adjustable, for this reason. Given that we can't have that, I think your behavior is reasonable but it should not be the default because it could lead to undetected bugs. I have an application where this comes up and as nearly as I can tell, I must now go and simulate the effect of ADJUST-ARRAY in order to create an array to a new size and make sure it gets filled properly. It makes me sad that I should have to do this when there's a function already that comes so close to what I want. This is a good argument. This is a typical example of where Common Lisp went wrong by standardizing a new, untried idea instead of standardizing current practice, which would be okay except that what was standardized was a bundle of several primitives and the underlying primitives were not exposed, so that users can't easily define functions to hide the deficiencies they feel are present in the standardized bundle. I think there should be a new keyword argument to ADJUST-ARRAY that does what you want, or else a separate function for this purpose, as there was in Zetalisp (ARRAY-GROW). I don't think the default behavior of ADJUST-ARRAY should be changed, for reasons given above. I can't think of any good names for the keyword argument; the best I was able to come up with was :IF-NOT-ADJUSTABLE with values :ERROR and :COPY.  Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 16 Oct 86 05:43:02 EDT Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 15 Oct 86 21:30:50 PDT Received: from EMU.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 134663; Thu 16-Oct-86 00:30:09 EDT Date: Thu, 16 Oct 86 00:28 EDT From: Kent M Pitman Subject: DEFVAR To: Common-Lisp@SU-AI.ARPA Message-ID: <861016002852.8.KMP@EMU.SCRC.Symbolics.COM> CLtL (p68) is not explicit on its intent about whether (DEFVAR FOO) is allowed to or intended to intialize FOO. For example, in Symbolics' Common Lisp FOO is left unbound but in VAXLISP it is initialized to NIL. The manual should state clearly whether an initialization occurs or be more up front if an ambiguity is in fact intended.  Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 16 Oct 86 04:51:14 EDT Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 15 Oct 86 21:43:08 PDT Received: from EMU.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 134668; Thu 16-Oct-86 00:41:53 EDT Date: Thu, 16 Oct 86 00:40 EDT From: Kent M Pitman Subject: ADJUST-ARRAY To: Common-Lisp@SU-AI.ARPA Message-ID: <861016004039.9.KMP@EMU.SCRC.Symbolics.COM> CLtL (p297) says that it is "not permitted to call ADJUST-ARRAY on an array that was not created with the :ADJUSTABLE option." This strikes me as overly restrictive. Why don't we say that ADJUST-ARRAY always returns an adjusted array and that the argument array will be modified only if (ADJUSTABLE-ARRAY-P array) was true. This is no more unreasonable than the current specification for the DELETE function. The way to be sure you were going to win would be to say: (SETQ X (ADJUST-ARRAY X ...)) just as you would do (SETQ X (DELETE ... X)) and in special cases you would know that you didn't have to do the SETQ. Does anyone really feel strongly that erring is necessary here? I have an application where this comes up and as nearly as I can tell, I must now go and simulate the effect of ADJUST-ARRAY in order to create an array to a new size and make sure it gets filled properly. It makes me sad that I should have to do this when there's a function already that comes so close to what I want.  Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 7 Oct 86 12:36:57 EDT Received: from [128.81.51.3] by SAIL.STANFORD.EDU with TCP; 7 Oct 86 09:16:57 PDT Received: from KOYAANISQATSI.S4CC.Symbolics.COM by DIAMOND.S4CC.Symbolics.COM via CHAOS with CHAOS-MAIL id 16849; Tue 7-Oct-86 12:15:13 EDT Date: Tue, 7 Oct 86 12:14 EDT From: David C. Plummer Subject: Re: printing structures To: Robert W. Kerns , Masinter.pa@Xerox.COM cc: common-lisp@SU-AI.ARPA In-Reply-To: <861007000135.2.RWK@WHITE-BIRD.SCRC.Symbolics.COM> Message-ID: <861007121449.5.DCP@KOYAANISQATSI.S4CC.Symbolics.COM> Date: Tue, 7 Oct 86 00:01 EDT From: Robert W. Kerns ... Back onto the original discussion: we added a variable *print-structure* We called ours *print-structure-contents* Nit: SYMBOLICS-COMMON-LISP:*PRINT-STRUCTURE-CONTENTS*, (or SCL:*PRINT-STRUCTURE-CONTENTS*) to be exact. which controlled how structures were printed by the default structure printer, in the same way that *print-array* controls array output. I'm reluctant to propose additions to the language, but if one was wanted, this seems like a logical choice. Indeed. Ditto. I set it to NIL in my init file for the same reasons other implementations have provided this extension.  Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 7 Oct 86 00:28:33 EDT Received: from SCRC-YUKON.ARPA by SAIL.STANFORD.EDU with TCP; 6 Oct 86 21:03:30 PDT Received: from WHITE-BIRD.SCRC.Symbolics.COM by YUKON.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 98732; Tue 7-Oct-86 00:01:02 EDT Date: Tue, 7 Oct 86 00:01 EDT From: Robert W. Kerns Subject: Re: printing structures To: Masinter.pa@Xerox.COM cc: common-lisp@SU-AI.ARPA In-Reply-To: <861005-200551-3386@Xerox> Message-ID: <861007000135.2.RWK@WHITE-BIRD.SCRC.Symbolics.COM> Date: 5 Oct 86 20:08 PDT From: Masinter.pa@Xerox.COM Separating out I/O for for inter-program communication and the user-interface is a good idea, but your proposal puts the burden on inter-program communication ("wrap this one form around the portion of your program which does I/O.") rather than on the user interface. I claim that's where the burden belongs. Programs interact with the user a lot more than they interact with other programs via read/print. And these interactions happen in a myriad unpredictable way (consider tracing, for example). The user-interface is global, it's the inter-program I/O that's localized, so that's why it gets the form wrapped around it. Besides and every time programms communicate, you have to think about whether what is being communicated can be communicated via read/print, whether you need *print-circle*, etc, anyway. Wouldn't it be simpler to suggest that implementors of a "top-level-loop" might want to bind a separate I/O environment for reading and printing (but not for execution)? That doesn't solve the problem. It isn't just a matter of printing the return values, it's error messages, messages from the program, debugging, etc. etc. Back onto the original discussion: we added a variable *print-structure* We called ours *print-structure-contents* which controlled how structures were printed by the default structure printer, in the same way that *print-array* controls array output. I'm reluctant to propose additions to the language, but if one was wanted, this seems like a logical choice. Indeed.  Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 6 Oct 86 14:09:11 EDT Received: from [192.10.41.109] by SAIL.STANFORD.EDU with TCP; 6 Oct 86 10:45:04 PDT Received: from CHICOPEE.SCRC.Symbolics.COM by ALDERAAN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 9317; Mon 6-Oct-86 13:43:14 EDT Date: Mon, 6 Oct 86 13:48 EDT From: Daniel L. Weinreb Subject: Printing Structures To: ELIOT%cs.umass.edu@CSNET-RELAY.ARPA, Common-Lisp@SU-AI.ARPA In-Reply-To: The message of 5 Oct 86 09:33 EDT from ELIOT%cs.umass.edu@CSNET-RELAY.ARPA Message-ID: <861006134816.4.DLW@CHICOPEE.SCRC.Symbolics.COM> Date: Sun, 5 Oct 86 09:33 EDT From: ELIOT%cs.umass.edu@CSNET-RELAY.ARPA I do not want the default printing format for structures changed. Symbolic's incorrect implementation of this has gotten me very upset. Just for the record, Symbolics's Release 7 (coming very soon) implements this in accordance with the standard. In general, Release 7 has far fewer variances with the CL spec than Release 6. We also have a special variable, called *print-structure-contents*, (default t, of course) that controls this behavior. That several implementations have found it necessary to adopt extensions to provide this ability suggests that the ability ought to be made part of the common standard.  Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 6 Oct 86 01:35:52 EDT Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 5 Oct 86 22:23:46 PDT Received: from umass-cs by csnet-relay.csnet id ac02811; 6 Oct 86 1:08 EDT Date: Sun, 5 Oct 86 09:33 EDT From: ELIOT%cs.umass.edu@CSNET-RELAY.ARPA To: Common-Lisp@SU-AI.ARPA Subject: Printing Structures X-VMS-To: CSNET%"Common-Lisp@Su-ai.arpa" I do not want the default printing format for structures changed. Symbolic's incorrect implementation of this has gotten me very upset. The default syntax is good at the begining of an implementation, when the data structures are being defined and you will be looking closely at all of the details. Eventually, I always define print functions for each defstruct. "Eventually" often means just before I implement the functions to create circular links. The default syntax is also good for teaching people about Lisp. It is much easier to explain how to use structures when you can show people exactly what is in them. It would be harder to convince people that nothing magical is going on if` if you had to define a print function while explaining it. As for lexical closures, and other system defined objects which do not behave well using the default syntax, nothing in CL should prevent the implementation from giving these objects special syntax. The default syntax applies to user defined structures. One more point. The default syntax is also best for testing out new Lisp features.  Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 6 Oct 86 00:26:15 EDT Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 5 Oct 86 21:15:32 PDT Date: Mon, 6 Oct 1986 00:14 EDT Message-ID: From: SOLEY@XX.LCS.MIT.EDU To: Dave.Touretzky@A.CS.CMU.EDU Cc: common-lisp@SU-AI.ARPA Subject: printing structures In-reply-to: Msg of 3 Oct 1986 23:57-EDT from Dave.Touretzky at A.CS.CMU.EDU Date: Friday, 3 October 1986 23:57-EDT From: Dave.Touretzky at A.CS.CMU.EDU I second Ramin Zabih's suggestion that the default way to print a structure should be to NOT show its components. If Common Lisp has to specify a default print convention, the # notation is a better choice. I third the suggestion, and further suggest *print-structure* control the action of the printer on structures (a la *print-array*), and default to not show components. These two are just general cases of "*print-readably*", so to speak; perhaps we should generalize? -- Richard Soley  Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 5 Oct 86 23:29:05 EDT Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 5 Oct 86 20:17:49 PDT Received: from Cabernet.ms by ArpaGateway.ms ; 05 OCT 86 20:05:51 PDT Date: 5 Oct 86 20:08 PDT From: Masinter.pa@Xerox.COM Subject: Re: printing structures In-reply-to: Robert W. Kerns 's message of Sat, 4 Oct 86 21:16 EDT To: RWK@YUKON.SCRC.Symbolics.COM cc: common-lisp@SU-AI.ARPA Message-ID: <861005-200551-3386@Xerox> Separating out I/O for for inter-program communication and the user-interface is a good idea, but your proposal puts the burden on inter-program communication ("wrap this one form around the portion of your program which does I/O.") rather than on the user interface. Wouldn't it be simpler to suggest that implementors of a "top-level-loop" might want to bind a separate I/O environment for reading and printing (but not for execution)? Back onto the original discussion: we added a variable *print-structure* which controlled how structures were printed by the default structure printer, in the same way that *print-array* controls array output. I'm reluctant to propose additions to the language, but if one was wanted, this seems like a logical choice.  Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 4 Oct 86 21:28:03 EDT Received: from SCRC-YUKON.ARPA by SAIL.STANFORD.EDU with TCP; 4 Oct 86 18:17:42 PDT Received: from WHITE-BIRD.SCRC.Symbolics.COM by YUKON.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 97828; Sat 4-Oct-86 21:15:41 EDT Date: Sat, 4 Oct 86 21:16 EDT From: Robert W. Kerns Subject: Re: printing structures To: Miles Bader cc: common-lisp@SU-AI.ARPA In-Reply-To: Message-ID: <861004211602.2.RWK@WHITE-BIRD.SCRC.Symbolics.COM> Date: Sat, 4 Oct 1986 02:28:46-EDT From: Miles Bader Of course, some people actually like to read in what they print. Why not just give different values to *print-length*, *print-level* and *print-circle* in your init file? -Miles As Common Lisp is currently designed, this just breaks programs that like to read in what they print. We provide a macro, WITH-STANDARD-IO-ENVIRONMENT which binds the I/O control variables to their standard values. This provides a sorely needed decoupling between I/O for inter-program communication and the user-interface. It is far easier to wrap this one form around the portion of your program which does I/O than it is to figure out what variables it depends on, and bind each of them. Even if you want a few non-standard bindings, it's easier to start with the standard bindings and rebind a few than to deal with each of them. I >strongly< recommend this be adopted. Once it's adopted, it's much easier to discuss changing the default global bindings for the I/O control variables to make the environment easier to use interactively. Without it, we'll just get caught up in the communications and compatibility issues.  Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 4 Oct 86 03:33:11 EDT Received: from SPICE.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 4 Oct 86 00:23:51 PDT Date: Sat, 4 Oct 1986 02:28:46-EDT From: Miles Bader Subject: Re: printing structures To: common-lisp@SU-AI.ARPA Message-ID: Of course, some people actually like to read in what they print. Why not just give different values to *print-length*, *print-level* and *print-circle* in your init file? -Miles  Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 4 Oct 86 00:14:13 EDT Received: from A.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 3 Oct 86 20:58:50 PDT Date: 3 Oct 86 23:57 EDT From: Dave.Touretzky@A.CS.CMU.EDU To: common-lisp@SU-AI.ARPA Subject: printing structures I second Ramin Zabih's suggestion that the default way to print a structure should be to NOT show its components. If Common Lisp has to specify a default print convention, the # notation is a better choice. The same problem shows up with closures: some implementations build closures that are circular or, at the very least, long and and hairy. They are a source of annoyance every time the user accidentally (or purposely) tries to print one. Since the Common Lisp standard deliberately says nothing about the representation of closures, maybe it shouldn't specify how they are printed. But it should at least SUGGEST to implementors that they should choose a printing convention doesn't screw the user by default, i.e. by trying to print something huge or circular. I like the Lisp Machine # notation just fine. -- Dave  Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 3 Oct 86 22:05:38 EDT Received: from REAGAN.AI.MIT.EDU by SAIL.STANFORD.EDU with TCP; 3 Oct 86 18:53:28 PDT Received: from NULLSTELLENSATZ.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 5075; Fri 3-Oct-86 21:53:47 EDT Date: Fri, 3 Oct 86 21:53 EDT From: Ramin Zabih Subject: Printing DEFSTRUCTs To: common-lisp@SU-AI.ARPA Message-ID: <861003215337.4.RDZ@NULLSTELLENSATZ.AI.MIT.EDU> The standard way of printing structures involves printing out all the slots in #S notation. The Common Lisp manual requires that structures print in this way unless the user specifies his own printing function in his structure definition (page 370). I don't think that this is a very useful way of printing structures, since a lot of structures are circular, and even those that aren't tend to be large in any program that isn't a toy. I would prefer that the default way of printing structures be changed to be more useful (for instance the way ZetaLisp DEFSTRUCTs used to print, which was as "#"). A less-preferable solution would involve a global variable that controls how structures default to printing. Ramin  Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 3 Oct 86 17:43:50 EDT Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 3 Oct 86 14:29:30 PDT Received: ID ; Fri 3 Oct 86 17:27:26-EDT Date: Fri, 3 Oct 1986 17:27 EDT Message-ID: From: Rob MacLachlan To: "Stephen E. Robbins" Cc: common-lisp@SU-AI.ARPA In-reply-to: Msg of 3 Oct 1986 16:36-EDT from Stephen E. Robbins Date: Friday, 3 October 1986 16:36-EDT From: Stephen E. Robbins ...Is the result of extracting past the end of a subsequence considered undefined? Stever Yes. Although it isn't explicitly stated when :END is discussed on page 246, the discussion doesn't make any sense otherwise. One could hypothesize a magical exception in the case where END is greater than the length, but there is nothing in the manual to support such a conclusion. There are many illegal things which are not explicitly stated to be illegal in the manual. Rob  Received: from SAIL.STANFORD.EDU by AI.AI.MIT.EDU 3 Oct 86 16:58:22 EDT Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 3 Oct 86 13:37:13 PDT Received: from MX.LCS.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 3 OCT 86 16:37:12 EDT Date: Fri, 3 Oct 86 16:36:39 EDT From: "Stephen E. Robbins" To: common-lisp@SU-AI.ARPA Message-ID: <[MX.LCS.MIT.EDU].950779.861003.STEVER> Hi! I'm doing a fair amount of string hacking right now. A lot of things involve comparing and manipulating substrings. I do most of this via the :START and :END arguments on the string functions. Symbolics Common Lisp blows up if you specify a :END which is greater than the length of a string. It also signals an error if you give a large :END to a subsequence extract with SUBSEQ. I looked through CLtL, but couldn't find any mention of this case. Is the result of extracting past the end of a subsequence considered undefined? Stever