Received: from PARC-MAXC by SU-AI with TCP/SMTP; 14 Jul 83 20:27:28 PDT Date: 14 JUL 83 20:23 PDT From: JONL.PA@PARC-MAXC.ARPA Subject: Re: Top-level forms To: Guy.Steele@CMUA.ARPA, common-lisp@SAIL.ARPA cc: JONL.PA@PARC-MAXC.ARPA In response to the message sent 14 Jul 83 23:09 EDT (Thursday) from Guy.Steele@CMU-CS-A.ARPA Comments aside about compilng to "save space" etc (Interlisp *does* GC the compiled code objects, but still doesn't compile the top-level forms), I'm glad you used the phrase "equivalent to", for that allows a compiler/processor merely to macro-reduce the top-level form to standard primitive lisp and output that. Remember in MacLisp when we met the problem of top-level forms that used macros available to the compile-time environment, but not installed in the load-time environment? Still, this isn't a simple problem, for GSB (I think) had to have a way to defeat the macro-reduction of such forms, in one instance.  Received: from USC-ECL by SU-AI with TCP/SMTP; 14 Jul 83 20:20:26 PDT Received: from MIT-MC by USC-ECL; Thu 14 Jul 83 18:13:03-PDT Date: Thursday, 14 July 1983, 18:13-PDT From: BENSON at SPA-Nimbus Subject: Top level forms in a compiled file To: Bernard S. Greenberg , BENSON at NIMBUS, EAK at MIT-MC, common-lisp%SU-AI%USC-ECL at MIT-MC In-reply-to: The message of 14 Jul 83 13:47-PDT from Bernard S. Greenberg The evaluation order here is absolutely critical, and kills your whole thing. It is completely reasonable and extraordinarily common to call functions defined two lines above. I guess you could say, "Well, run it at the end, not at the beginning", but there could be load-time forms in your functions. This is handled in PSL by having function definitions add a call to FSET to the list of top level forms to be compiled. It is exactly as if DEFUN were just defined as a macro and didn't cause any special behavior on the part of the compiler! Just wrap (lambda () ...) around everything in the file, and compile it. (Not actually true, but the behavior is the same.) E.g. (defmacro defun (name &body body) `(setf (symbol-function ',name) #',(lambda ,@body))) Even defining a function twice in a single file and using both definitions works.  Received: from CMU-CS-A by SU-AI with TCP/SMTP; 14 Jul 83 20:12:45 PDT Received: from [128.2.254.192] by CMU-CS-PT with CMUFTP; 14 Jul 83 22:54:36 EDT Date: 14 Jul 83 2309 EDT (Thursday) From: Guy.Steele@CMU-CS-A To: common-lisp@SU-AI Subject: Top-level forms I strongly advocate that Common LISP compilers perform processing on top-level forms equivalent to making the form into a function of no arguments, compiling that, and then invoking it. --Guy  Received: from MIT-MC by SU-AI with TCP/SMTP; 14 Jul 83 19:53:37 PDT Date: Thursday, 14 July 1983, 18:34-PDT From: BENSON at SPA-Nimbus Subject: Compiling top level forms To: Kent M. Pitman , BSG at SCRC-TENEX Cc: Common-Lisp at SU-AI In-reply-to: The message of 14 Jul 83 14:41-PDT from Kent M. Pitman From: Kent M. Pitman To: BSG @ SCRC-TENEX cc: Common-Lisp @ SU-AI I seem to recall that the reason (or one of the reasons) for Maclisp not compiling random toplevel forms was due to address space. Binary space can't (straightforwardly) be reclaimed, so things like Macsyma which were address- space critical wanted to do lots of set-up stuff as toplevel forms so it could all be GC'd. Even on large address space machines, I could see putting such definitions on their own pages so they could get reclaimed while leaving the rest of the definitions loaded with them near each other to reduce paging. PSL also does not GC compiled code, but explicitly allocates and deallocates the space for the toplevel function. No pointer to it can be kept, in fact it never even exists as a full-fledged Lisp object. It could even conceivably be allocated on the stack (Yow!). Seriously, such a beast could be put in a temporary area on the 3600 and win big.  Received: from MIT-MC by SU-AI with TCP/SMTP; 14 Jul 83 14:42:00 PDT Date: 14 July 1983 17:41 EDT From: Kent M. Pitman To: BSG @ SCRC-TENEX cc: Common-Lisp @ SU-AI Date: Thursday, 14 July 1983, 16:47-EDT From: Bernard S. Greenberg ... I had often thought of compiling a little functionelle for each top-level form. I basically like this idea. You'd of course have to check first that it didn't macroexpand into def-forms, eval-when, etc. Just define (FOO) to mean the same as (DEFUN G0001 () (FOO)) (G0001). It wouldn't have to be implemented the same; just have equivalent behavior. I seem to recall that the reason (or one of the reasons) for Maclisp not compiling random toplevel forms was due to address space. Binary space can't (straightforwardly) be reclaimed, so things like Macsyma which were address- space critical wanted to do lots of set-up stuff as toplevel forms so it could all be GC'd. Even on large address space machines, I could see putting such definitions on their own pages so they could get reclaimed while leaving the rest of the definitions loaded with them near each other to reduce paging. Taking this scheme literally might also mean compiler warnings for special vars, undefined functions, etc. I think I could even learn to like that. Technically, people can currently write (PROGN (DEFUN F () (FOO ...)) (DEFMACRO FOO ...) (F)) and expect to win. FOO could even call F if the writer were creative. I'm willing to claim such code is bogus. The user can always fall back on (EVAL '(...)) if he wants truly uncompiled code.  Received: from USC-ECL by SU-AI with TCP/SMTP; 14 Jul 83 13:50:52 PDT Received: from MIT-MC by USC-ECL; Thu 14 Jul 83 13:49:38-PDT Received: from SCRC-BEAGLE by SCRC-TENEX with CHAOS; Thu 14-Jul-83 16:40:06-EDT Date: Thursday, 14 July 1983, 16:47-EDT From: Bernard S. Greenberg Subject: Top level forms in a compiled file To: BENSON%NIMBUS@MIT-MC, EAK@MIT-MC, common-lisp%SU-AI@USC-ECL In-reply-to: The message of 14 Jul 83 14:54-EDT from BENSON at SPA-NIMBUS Date: Thursday, 14 July 1983, 11:54-PDT From: BENSON at SPA-Nimbus Date: Thursday, 14 July 1983, 10:35-EDT From: Bernard S. Greenberg In order for the compiler to compile lambdas in top level forms, a solid theory of processing top-level function calls has to be developed There is a solution to this problem. Collect all the top level forms in the file into a function of no arguments and compile the function. When the compiled file is loaded, call the function and throw it away. This is the strategy I chose for PSL's compiler and binary loader. Thus, anonymous lambdas outside of named function definitions are compiled by the same means as those which are inside functions. Other advantages are conceptual simplicity, ease of implementation, and faster loading. Yes and no. This causes exactly the right things to happen to the forms themselves, but... There are problems with this approach. The top-level function which must be compiled is sometimes huge, much larger than any real function. Compilation is slower. People tend to be much sloppier in what they write at the top level than inside functions (because they never expected it to be compiled!). Top level forms sometimes modify the global state such that a monolithic compilation does not have the same semantics as incremental evaluation. The most common example of the latter is package manipulation, which changes the behavior of the reader. The evaluation order here is absolutely critical, and kills your whole thing. It is completely reasonable and extraordinarily common to call functions defined two lines above. I guess you could say, "Well, run it at the end, not at the beginning", but there could be load-time forms in your functions. I had often thought of compiling a little functionelle for each top-level form.  Received: from USC-ECL by SU-AI with TCP/SMTP; 14 Jul 83 11:59:31 PDT Received: from MIT-XX by USC-ECL; Thu 14 Jul 83 11:57:43-PDT Date: Thursday, 14 July 1983, 11:54-PDT From: BENSON at SPA-Nimbus Subject: Top level forms in a compiled file To: Bernard S. Greenberg , EAK at MIT-MC, common-lisp%SU-AI at USC-ECL In-reply-to: The message of 14 Jul 83 07:35-PDT from Bernard S. Greenberg Received: from USC-ECL by SU-AI with TCP/SMTP; 14 Jul 83 07:40:42 PDT Received: from MIT-MC by USC-ECL; Thu 14 Jul 83 07:39:50-PDT Received: from SCRC-BEAGLE by SCRC-TENEX with CHAOS; Thu 14-Jul-83 10:27:37-EDT Date: Thursday, 14 July 1983, 10:35-EDT From: Bernard S. Greenberg Subject: function specs To: EAK@MIT-MC, common-lisp%SU-AI@USC-ECL In-reply-to: The message of 13 Jul 83 23:00-EDT from Earl A. Killian Date: 13 July 1983 23:00 EDT From: Earl A. Killian Btw, I would consider any compiler that didn't compile the lambda in (putprop 'foo #'(lambda (x) (mumble-frotz x)) 'bar) to be broken. Surely, if the form above appears in the middle of a function. But what about forms that appear at the top level? I don't think there is a clear notion of what happens to top level forms that are not macro invocations. Traditionally, these forms go into the object file unmodified (just encoded). Should constant expressions be reduced? Should diagnostics be issued? Should internal macro calls be expanded? In order for the compiler to compile lambdas in top level forms, a solid theory of processing top-level function calls has to be developed, which implies a new, fundamental mode of meta-evaluation, viz., compiler-top-level, to be added to the current set of language-defined meta-evaluations (true evaluation and compilation). There is a solution to this problem. Collect all the top level forms in the file into a function of no arguments and compile the function. When the compiled file is loaded, call the function and throw it away. This is the strategy I chose for PSL's compiler and binary loader. Thus, anonymous lambdas outside of named function definitions are compiled by the same means as those which are inside functions. Other advantages are conceptual simplicity, ease of implementation, and faster loading. There are problems with this approach. The top-level function which must be compiled is sometimes huge, much larger than any real function. Compilation is slower. People tend to be much sloppier in what they write at the top level than inside functions (because they never expected it to be compiled!). Top level forms sometimes modify the global state such that a monolithic compilation does not have the same semantics as incremental evaluation. The most common example of the latter is package manipulation, which changes the behavior of the reader. Whether or not this exact approach is taken, I think it is quite reasonable to expect top level forms in a file being compiled to be treated the same as forms within function definitions, including diagnostics, constant sharing and compilation of lambda forms. -- Eric  Received: from USC-ECL by SU-AI with TCP/SMTP; 14 Jul 83 11:59:31 PDT Received: from MIT-XX by USC-ECL; Thu 14 Jul 83 11:57:43-PDT Date: Thursday, 14 July 1983, 11:54-PDT From: BENSON at SPA-Nimbus Subject: Top level forms in a compiled file To: Bernard S. Greenberg , EAK at MIT-MC, common-lisp%SU-AI at USC-ECL In-reply-to: The message of 14 Jul 83 07:35-PDT from Bernard S. Greenberg Received: from USC-ECL by SU-AI with TCP/SMTP; 14 Jul 83 07:40:42 PDT Received: from MIT-MC by USC-ECL; Thu 14 Jul 83 07:39:50-PDT Received: from SCRC-BEAGLE by SCRC-TENEX with CHAOS; Thu 14-Jul-83 10:27:37-EDT Date: Thursday, 14 July 1983, 10:35-EDT From: Bernard S. Greenberg Subject: function specs To: EAK@MIT-MC, common-lisp%SU-AI@USC-ECL In-reply-to: The message of 13 Jul 83 23:00-EDT from Earl A. Killian Date: 13 July 1983 23:00 EDT From: Earl A. Killian Btw, I would consider any compiler that didn't compile the lambda in (putprop 'foo #'(lambda (x) (mumble-frotz x)) 'bar) to be broken. Surely, if the form above appears in the middle of a function. But what about forms that appear at the top level? I don't think there is a clear notion of what happens to top level forms that are not macro invocations. Traditionally, these forms go into the object file unmodified (just encoded). Should constant expressions be reduced? Should diagnostics be issued? Should internal macro calls be expanded? In order for the compiler to compile lambdas in top level forms, a solid theory of processing top-level function calls has to be developed, which implies a new, fundamental mode of meta-evaluation, viz., compiler-top-level, to be added to the current set of language-defined meta-evaluations (true evaluation and compilation). There is a solution to this problem. Collect all the top level forms in the file into a function of no arguments and compile the function. When the compiled file is loaded, call the function and throw it away. This is the strategy I chose for PSL's compiler and binary loader. Thus, anonymous lambdas outside of named function definitions are compiled by the same means as those which are inside functions. Other advantages are conceptual simplicity, ease of implementation, and faster loading. There are problems with this approach. The top-level function which must be compiled is sometimes huge, much larger than any real function. Compilation is slower. People tend to be much sloppier in what they write at the top level than inside functions (because they never expected it to be compiled!). Top level forms sometimes modify the global state such that a monolithic compilation does not have the same semantics as incremental evaluation. The most common example of the latter is package manipulation, which changes the behavior of the reader. Whether or not this exact approach is taken, I think it is quite reasonable to expect top level forms in a file being compiled to be treated the same as forms within function definitions, including diagnostics, constant sharing and compilation of lambda forms. -- Eric  Received: from USC-ECL by SU-AI with TCP/SMTP; 14 Jul 83 11:59:31 PDT Received: from MIT-XX by USC-ECL; Thu 14 Jul 83 11:57:43-PDT Date: Thursday, 14 July 1983, 11:54-PDT From: BENSON at SPA-Nimbus Subject: Top level forms in a compiled file To: Bernard S. Greenberg , EAK at MIT-MC, common-lisp%SU-AI at USC-ECL In-reply-to: The message of 14 Jul 83 07:35-PDT from Bernard S. Greenberg Received: from USC-ECL by SU-AI with TCP/SMTP; 14 Jul 83 07:40:42 PDT Received: from MIT-MC by USC-ECL; Thu 14 Jul 83 07:39:50-PDT Received: from SCRC-BEAGLE by SCRC-TENEX with CHAOS; Thu 14-Jul-83 10:27:37-EDT Date: Thursday, 14 July 1983, 10:35-EDT From: Bernard S. Greenberg Subject: function specs To: EAK@MIT-MC, common-lisp%SU-AI@USC-ECL In-reply-to: The message of 13 Jul 83 23:00-EDT from Earl A. Killian Date: 13 July 1983 23:00 EDT From: Earl A. Killian Btw, I would consider any compiler that didn't compile the lambda in (putprop 'foo #'(lambda (x) (mumble-frotz x)) 'bar) to be broken. Surely, if the form above appears in the middle of a function. But what about forms that appear at the top level? I don't think there is a clear notion of what happens to top level forms that are not macro invocations. Traditionally, these forms go into the object file unmodified (just encoded). Should constant expressions be reduced? Should diagnostics be issued? Should internal macro calls be expanded? In order for the compiler to compile lambdas in top level forms, a solid theory of processing top-level function calls has to be developed, which implies a new, fundamental mode of meta-evaluation, viz., compiler-top-level, to be added to the current set of language-defined meta-evaluations (true evaluation and compilation). There is a solution to this problem. Collect all the top level forms in the file into a function of no arguments and compile the function. When the compiled file is loaded, call the function and throw it away. This is the strategy I chose for PSL's compiler and binary loader. Thus, anonymous lambdas outside of named function definitions are compiled by the same means as those which are inside functions. Other advantages are conceptual simplicity, ease of implementation, and faster loading. There are problems with this approach. The top-level function which must be compiled is sometimes huge, much larger than any real function. Compilation is slower. People tend to be much sloppier in what they write at the top level than inside functions (because they never expected it to be compiled!). Top level forms sometimes modify the global state such that a monolithic compilation does not have the same semantics as incremental evaluation. The most common example of the latter is package manipulation, which changes the behavior of the reader. Whether or not this exact approach is taken, I think it is quite reasonable to expect top level forms in a file being compiled to be treated the same as forms within function definitions, including diagnostics, constant sharing and compilation of lambda forms. -- Eric  Received: from USC-ECL by SU-AI with TCP/SMTP; 14 Jul 83 11:59:31 PDT Received: from MIT-XX by USC-ECL; Thu 14 Jul 83 11:57:43-PDT Date: Thursday, 14 July 1983, 11:54-PDT From: BENSON at SPA-Nimbus Subject: Top level forms in a compiled file To: Bernard S. Greenberg , EAK at MIT-MC, common-lisp%SU-AI at USC-ECL In-reply-to: The message of 14 Jul 83 07:35-PDT from Bernard S. Greenberg Received: from USC-ECL by SU-AI with TCP/SMTP; 14 Jul 83 07:40:42 PDT Received: from MIT-MC by USC-ECL; Thu 14 Jul 83 07:39:50-PDT Received: from SCRC-BEAGLE by SCRC-TENEX with CHAOS; Thu 14-Jul-83 10:27:37-EDT Date: Thursday, 14 July 1983, 10:35-EDT From: Bernard S. Greenberg Subject: function specs To: EAK@MIT-MC, common-lisp%SU-AI@USC-ECL In-reply-to: The message of 13 Jul 83 23:00-EDT from Earl A. Killian Date: 13 July 1983 23:00 EDT From: Earl A. Killian Btw, I would consider any compiler that didn't compile the lambda in (putprop 'foo #'(lambda (x) (mumble-frotz x)) 'bar) to be broken. Surely, if the form above appears in the middle of a function. But what about forms that appear at the top level? I don't think there is a clear notion of what happens to top level forms that are not macro invocations. Traditionally, these forms go into the object file unmodified (just encoded). Should constant expressions be reduced? Should diagnostics be issued? Should internal macro calls be expanded? In order for the compiler to compile lambdas in top level forms, a solid theory of processing top-level function calls has to be developed, which implies a new, fundamental mode of meta-evaluation, viz., compiler-top-level, to be added to the current set of language-defined meta-evaluations (true evaluation and compilation). There is a solution to this problem. Collect all the top level forms in the file into a function of no arguments and compile the function. When the compiled file is loaded, call the function and throw it away. This is the strategy I chose for PSL's compiler and binary loader. Thus, anonymous lambdas outside of named function definitions are compiled by the same means as those which are inside functions. Other advantages are conceptual simplicity, ease of implementation, and faster loading. There are problems with this approach. The top-level function which must be compiled is sometimes huge, much larger than any real function. Compilation is slower. People tend to be much sloppier in what they write at the top level than inside functions (because they never expected it to be compiled!). Top level forms sometimes modify the global state such that a monolithic compilation does not have the same semantics as incremental evaluation. The most common example of the latter is package manipulation, which changes the behavior of the reader. Whether or not this exact approach is taken, I think it is quite reasonable to expect top level forms in a file being compiled to be treated the same as forms within function definitions, including diagnostics, constant sharing and compilation of lambda forms. -- Eric  Received: from USC-ECL by SU-AI with TCP/SMTP; 14 Jul 83 07:40:42 PDT Received: from MIT-MC by USC-ECL; Thu 14 Jul 83 07:39:50-PDT Received: from SCRC-BEAGLE by SCRC-TENEX with CHAOS; Thu 14-Jul-83 10:27:37-EDT Date: Thursday, 14 July 1983, 10:35-EDT From: Bernard S. Greenberg Subject: function specs To: EAK@MIT-MC, common-lisp%SU-AI@USC-ECL In-reply-to: The message of 13 Jul 83 23:00-EDT from Earl A. Killian Date: 13 July 1983 23:00 EDT From: Earl A. Killian Btw, I would consider any compiler that didn't compile the lambda in (putprop 'foo #'(lambda (x) (mumble-frotz x)) 'bar) to be broken. Surely, if the form above appears in the middle of a function. But what about forms that appear at the top level? I don't think there is a clear notion of what happens to top level forms that are not macro invocations. Traditionally, these forms go into the object file unmodified (just encoded). Should constant expressions be reduced? Should diagnostics be issued? Should internal macro calls be expanded? In order for the compiler to compile lambdas in top level forms, a solid theory of processing top-level function calls has to be developed, which implies a new, fundamental mode of meta-evaluation, viz., compiler-top-level, to be added to the current set of language-defined meta-evaluations (true evaluation and compilation).  Received: from MIT-MC by SU-AI with TCP/SMTP; 13 Jul 83 20:08:40 PDT Date: 13 July 1983 23:00 EDT From: Earl A. Killian Subject: function specs To: common-lisp @ SU-AI In-reply-to: Msg of 12 Jul 1983 17:42-EDT from Howard Shrobe Btw, I would consider any compiler that didn't compile the lambda in (putprop 'foo #'(lambda (x) (mumble-frotz x)) 'bar) to be broken.  Received: from MIT-MC by SU-AI with TCP/SMTP; 12 Jul 83 19:45:22 PDT Date: 12 July 1983 22:44 EDT From: Kent M. Pitman Subject: Historical Footnote To: hes @ SCRC-VIXEN cc: Common-Lisp @ SU-AI Date: Tuesday, 12 July 1983, 17:42-EDT From: Howard Shrobe Re: function specs To: common-lisp@SU-AI ... (defmacro deffunny (name (symbol indicator) &body body) (let ((standin (gensym))) `(progn 'compile (defun ,standin ,args ,@body) (putprop ',symbol (fsymeval ',standin) ',indicator)))) which is vintage 1973 MacLisp whose demise was welcomed by all when the extended defun was introduced... Well, allowing for the obvious bugs in this definition (ARGS isn't bound anywhere, NAME isn't used, etc.), the 1973 syntax would have been... (defun deffunny macro (form) (prog (temp symbol indicator body standin) (setq temp (car (setq form (cdr form)))) (setq args (car (setq form (cdr form)))) (setq body (cdr form)) (setq symbol (car temp)) (setq indicator (cadr temp)) (setq standin (gensym)) (return (list 'progn ''compile (cons 'defun (cons standin (cons args body))) (list 'defprop symbol standin indicator))))) Of course, this STILL would not have worked reliably since if I'm not mistaken gensyms lose their uniqueness when output by the compiler, so you'd have interned symbols that looked like G0017 all over the place and if you loaded the results of separate compilations which had had the same gensym counter, you'd be clobbering functions back and forth accidentally. So this is, even today, not a reliable strategy. No heavy-duty point to be made here. Just wanted to remind you what "common" lisp looked like in 1973. We have come a longer way than you might remember. Still, as is obvious from the holes in the language, we have a long ways to go. The belief seems to be that premature standardization would be far worse than living with certain parts of the language fuzzily defined while we think things out...  Received: from SU-SCORE by SU-AI with TCP/SMTP; 12 Jul 83 19:22:25 PDT Received: from MIT-XX by SU-SCORE.ARPA with TCP; Tue 12 Jul 83 19:26:48-PDT Date: Tuesday, 12 July 1983, 19:17-PDT From: BENSON at SPA-Nimbus Subject: function specs To: Howard Shrobe , common-lisp at SU-AI In-reply-to: The message of 12 Jul 83 14:42-PDT from Howard Shrobe I believe that function specs were not included in Common Lisp because of the number of issues which they raised. I don't believe there were any strong objections to the concept itself, rather to the secondary consequnces of including them, such as: It is a pervasive language feature, comparable to type specifiers in scope, which would require a similar amount of explanation. It adds yet another semantic interpretation of lists, which conflicts with some existing ones, e.g. #'(lambda ...) and #'(:property ...) have very different meanings. It also means that lists need to be used where only symbols are now allowed, such as in RETURN-FROM block names. This may require changing some equality tests from EQ or EQL to EQUAL. For consistency, ((:property foo bar) x) should be legal as well as (funcall #'(property foo bar) x). This is not currently the case in Zetalisp. Despite these problems, I think that function specs probably should be included in Common Lisp in the next edition, if we can stand another round of discussion on something as fraught with peril as this. They are quite useful. Regarding another point in your message, it is very unfortunate that #'(lambda ...) forms not inside defuns are not compiled. For example, one might store functions in a hash table rather than on the property list of a symbol. A command processor might use an array of functions indexed by character codes. There is no function spec which refers to an entry in a hash table or an element of an array. This forces one into your Option 2 kludge if you want the function to be compiled. -- Eric  Received: from CMU-CS-C by SU-AI with TCP/SMTP; 12 Jul 83 19:21:45 PDT Received: ID ; Tue 12 Jul 83 22:22:54-EDT Date: Tue, 12 Jul 1983 22:22 EDT From: Scott E. Fahlman To: Howard Shrobe Cc: common-lisp@SU-AI.ARPA Subject: function specs In-reply-to: Msg of 12 Jul 1983 17:42-EDT from Howard Shrobe Let me try to reconstruct the history of functions specs (or their lack) in Common Lisp. 1. The Symbolics folks at one point noticed the lack of function specs and proposed adding a rather complex, fully extensible set of machinery for function specs. 2. There was a bit of confusion surrounding the whole thing -- several other complicated things, such as support for a flavor system, were being discussed at the same time and seemed to interact with this proposal. The proposal was also wrapped in some unfortunate terminology about function specs being the "name" of a function. That further confused the issue. This way of looking at it seemed natural to Moon et. al. but very unnatural to some of the rest of us. Anyway, the terminology was separable from the mechanics of the function spec proposal, but some of us didn't realize this in time. The result was that a number of us of us (including me) boggled at the apparent complexity of what was being proposed and began looking for a less complicated way of accomplishing the same end. 3. I came up with the idea of using any SETF-able form in the "name" slot of DEFUN as the place to put the resulting lambda or compiled function. (A symbol in that position would be special, in that the function goes in the FUNCTION cell rather than the VALUE cell.) It seemed to me that this had the advantage of not requiring a whole new set of machinery for defining these pseudo-names. However, my proposal had some bugs as well. 4. Both proposals attracted considerable support. We decided to leave the issue unresolved for the moment and think about it, rather than to arbitrarily grab one solution or the other. In the meantime, the solution of making up a name (or having a macro do it as you illustrated) seemed an entirely workable, if ugly, solution. 5. In the recent rush to wrap up the remaining loose ends so that Guy could get the manual out, I indicated to Moon that I was ready to accept a slightly simplified version of his proposal if he wanted to try again, but we both agreed that reopening this issue would probably lead to a lot of debate. We decided not to try to resolve this issue for the first edition of the manual, but to discuss it again after the first edition is out. So that's why Common Lisp does not currently include function specs. An implementation is allowed to add some sort of function spec as an extension. My guess is that when we all recover from the recent manual debate and the ensuing damage control, function specs will be one of the first items on the agenda. If we can all agree this time (and I am optimistic that we will), then these will go into all implementations sometime soon as an advertised extension, and will become "official" when the second edition of the manual comes out. Isn't politics fun? -- Scott  Received: from PARC-MAXC by SU-AI with TCP/SMTP; 12 Jul 83 18:19:16 PDT Date: 12 Jul 83 18:18:52 PDT (Tuesday) From: Masinter.PA@PARC-MAXC.ARPA Subject: Re: function specs In-reply-to: hes%VIXEN%MIT-MC's message of Tue, 12 Jul 83 17:42 EDT To: Howard Shrobe cc: common-lisp@SU-AI.ARPA Howie, as I recall (my manual is missing and I must recall), the (defun (foo bar) (x) (mumble-frotz x)) was disallowed, but that the first arg to defun COULD be an arbitrary SETFable form. I guess you have to write (defun (getprop foo bar) (x) (mumble-frotz x)) [apologies for bastard CommonLisp, but as I said, I don't have my manual handy].  Received: from MIT-MC by SU-AI with TCP/SMTP; 12 Jul 83 14:49:35 PDT Received: from SCRC-HOUSATONIC by SCRC-TENEX with CHAOS; Tue 12-Jul-83 17:38:39-EDT Date: Tuesday, 12 July 1983, 17:42-EDT From: Howard Shrobe Subject: function specs To: common-lisp@SU-AI Hi, while working on notes for a AAAI tutorial that I'm giving with Larry Masinter, I was informed that Common Lisp provides no means for defining a functional property of a symbol. I.e. you can't do the MacLisp (defun (foo bar) (x) (mumble-frotz x)) or even the LispMachine Lisp (defun (:property foo bar) (x) (mumble-frotz x)). I was shocked. I often write programs which work by dispatching to functions stored on property lists. Short of flavors or some such thing this is the cleanest style for coding many problems. Now without at least this minimal form of function-spec you're forced to do something much grosser: Option 1 is to do (putprop 'foo #'(lambda (x) (mumble-frotz x)) 'bar) in which case the compiler will probably not compile the lambda expression. Option 2 is to build a macro (defmacro deffunny (name (symbol indicator) &body body) (let ((standin (gensym))) `(progn 'compile (defun ,standin ,args ,@body) (putprop ',symbol (fsymeval ',standin) ',indicator)))) which is vintage 1973 MacLisp whose demise was welcomed by all when the extended defun was introduced. Can someone please explain to me what is being gained by not having function-specs. Naively Howie Shrobe  Received: from MIT-MC by SU-AI with TCP/SMTP; 6 Jul 83 13:36:41 PDT Date: Wednesday, 6 July 1983 16:34-EDT From: MOON at SCRC-TENEX To: Jonathan Rees Cc: common-lisp at SU-AI Subject: more misc. stuff In-reply-to: The message of Wed 6 Jul 83 14:10:00 EDT from Jonathan Rees Date: Wed, 6 Jul 83 14:10:00 EDT From: Jonathan Rees [8] Page 77: be careful about the use of the term "predicate". It has "traditionally" been used in two different ways - to mean a function which returns a truth value, and to mean an expression which computes a truth value. The CL manual elsewhere suggests the term "test" for the second concept. So in the descriptions of IF, WHEN, and UNLESS, use "test" instead of "pred" to name the test form. But a number of functions (including the sequence function) take a :TEST keyword whose value is a predicate function, not a form. So using the words predicate/test to reflect the function/form distinction will still be confusing. We either need a third word or else should append "-form" to anything that is a form. Fixed in Lambda calculus.  Received: from CMU-CS-C by SU-AI with TCP/SMTP; 6 Jul 83 11:51:24 PDT Received: ID ; 6-Jul-83 14:53:10 Date: Wed 6 Jul 83 14:53:06-EDT From: Dragon Subject: Re: more misc. stuff To: Rees@YALE.ARPA cc: common-lisp@SU-AI.ARPA In-Reply-To: Message from "Jonathan Rees " of Wed 6 Jul 83 14:47:09-EDT about -p vs p: the rule Guy is using is that if the thing to get a predicate has a hyphen in its name, and the p applies to the entire thing (eg. compiled-function, simple-string, string-char) then it gets a -p. If the thing does not have a hyphen (stream, zero, etc) or has a hyphen but the predicate would only apply to the part after the hyphen (can't think of an example but I know there's one out there somewhere) then it gets just a p. This has been corrected in the as-yet-unfinished followup to the laser edition. Monica -------  Received: from YALE by SU-AI with TCP/SMTP; 6 Jul 83 11:22:51 PDT Received: by YALE-BULLDOG via CHAOS; Wed, 6 Jul 83 14:12:03 EDT Date: Wed, 6 Jul 83 14:10:00 EDT From: Jonathan Rees Subject: more misc. stuff To: common-lisp@SU-AI.ARPA More nits. [4, continued] Note that there was nothing special about MACROLET as opposed to DEFMACRO or MACRO in my previous message. The following is just as confusing as the MACROLET example (remember that Common Lisp has lexical closures). (let ((x 5)) (defmacro foo (z) `(+ ,z ,x)) (foo 7)) Also, what about the following: (flet ((foo (z) z)) (defmacro foo (z) `(+ ,z ,x)) (foo 7)) Does the DEFMACRO alter the global function binding of FOO or the local function binding? [8] Page 77: be careful about the use of the term "predicate". It has "traditionally" been used in two different ways - to mean a function which returns a truth value, and to mean an expression which computes a truth value. The CL manual elsewhere suggests the term "test" for the second concept. So in the descriptions of IF, WHEN, and UNLESS, use "test" instead of "pred" to name the test form. [9] On naming of predicates: maybe there should be an explanation somewhere of how it is that some predicates are named with a "P" suffix, and others with a "-P" suffix. E.g.: input-stream-p compiled-function-p simple-string-p macro-p but streamp functionp string-charp stringp characterp zerop char-greaterp uppercasep What's the general rule? I have a feeling there almost is one. -------  Received: from MIT-MC by SU-AI with TCP/SMTP; 5 Jul 83 15:53:40 PDT Date: 5 July 1983 18:53 EDT From: George J. Carrette Subject: Who is implementing CL on the CDC 6400? To: fateman%UCBKIM @ UCB-VAX cc: Common-Lisp @ SU-AI Ask me that one again in about 3 months.  Received: from UCB-VAX by SU-AI with TCP/SMTP; 4 Jul 83 19:30:51 PDT Received: from UCBKIM.ARPA by UCBVAX.ARPA (3.346/3.33) id AA00564; 4 Jul 83 18:34:22 PDT (Mon) Date: 2 Jul 83 18:30:27 PDT (Sat) From: fateman%UCBKIM@Berkeley (Richard Fateman) Subject: Re: +0.0 vs. -0.0 vs. EQL Message-Id: <8307030130.7982@UCBKIM.ARPA> Received: by UCBKIM.ARPA (3.340/3.5) id AA07982; 2 Jul 83 18:30:27 PDT (Sat) To: @SU-AI:ALAN@MIT-MC, Common-Lisp@SU-AI If +0 and -0 conventions are implemented by means of an IEEE standard conforming arithmetic system, then they will compare equal at the instruction level. Who is implementing CL on the CDC 6400?  Received: from MIT-MC by SU-AI with TCP/SMTP; 4 Jul 83 09:54:24 PDT Received: from SCRC-BORZOI by SCRC-TENEX with CHAOS; Mon 4-Jul-83 11:07:18-EDT Date: Monday, 4 July 1983, 11:06-EDT From: Daniel L. Weinreb Subject: misc. stuff To: Rees%YALE@SU-DSN, common-lisp@SU-AI In-reply-to: The message of 30 Jun 83 14:20-EDT from Jonathan Rees Date: Thu, 30 Jun 83 14:20:16 EDT From: Jonathan Rees [1] Will there be a unified index in the next edition of the manual? I have the impression that Symbolics has decided that it is best to have one index instead of four or five. I certainly agree. Yes, we have. Actually, I think we now belive that it's best to have both kinds, but the one at the back (the one that's easy to find) should be a combined index. Guy, Jan Walker has figured out some good ways to do this in Scribe. [4] Pages 76 and 99: what is the lexical scope of the body of a macro definition? I.e., where do free variables (and functions) get their values? This needs clarification. E.g., what does the following mean? (setq x 8) (eval-when (compile) (setq x 2)) (let ((x 5)) (macrolet ((foo (z) `(+ ,z ,x))) (foo 7))) Does this evaluate to 9, 12, or 15? Does it matter whether the code is being "interpreted" or "compiled"? Can the manual be written in such a way as to let this be explicitly undefined? Well, I think it's always the case that if you run around using eval-when, things can behave differently "evaluted" than "compiled". I definitely do not think things like this should be left undefined; this is a fundamental issue of evaluation semantics. I think the only viable possibility is that it is defined to return 15 evaluated and 9 compiled, never 12. [7] Page 244. Is READ-DELIMITED-LIST defined to side-affect the syntax of its "char" argument in *READTABLE*, even if only temporarily? Presumably it would be implemented by temporarily defining a right-parenthesis-like readmacro character for "char", using UNWIND-PROTECT or something of the sort. If such an implementation is permitted, perhaps this should be mentioned. I agree, since this is exactly how we were going to implement it (I haven't gotten around to it yet).  Received: from MIT-MC by SU-AI with TCP/SMTP; 3 Jul 83 11:54:17 PDT Date: 3 July 1983 14:54 EDT From: Kent M. Pitman Subject: (EQL -0.0 +0.0) => NIL To: common-lisp @ SU-AI I definitely support the arguments presented in ALAN's note for making (EQL -0.0 +0.0) return NIL. Any other interpretation would pretty much destroy the useful properties of EQL's semantics. I would definitely also want (EQUAL '(DEFUN FOO () -0.0) '(DEFUN FOO () +0.0)) to return NIL. Perhaps changing the wording on p56 to "numbers of the same type with the same sign and magnitude" and omitting the reference to "=" would do; or would this not be appropriately general to complexes?  Received: from MIT-MC by SU-AI with TCP/SMTP; 2 Jul 83 23:12:45 PDT Date: Sunday, 3 July 1983 02:13-EDT From: DLW at SCRC-TENEX to: Common-Lisp at SU-AI Subject: +0.0 vs. -0.0 vs. EQL In-reply-to: The message of 2 Jul 1983 18:17 EDT from Alan Bawden Alan's message is a concise summary of the conclusions reached on an internal mailing list at Symbolics; all of the Symbolics team supports everything Alan says.  Received: from MIT-MC by SU-AI with TCP/SMTP; 2 Jul 83 15:17:13 PDT Date: 2 July 1983 18:17 EDT From: Alan Bawden Subject: +0.0 vs. -0.0 vs. EQL To: Common-Lisp @ SU-AI The Laser manual explains that the EQL function compares two numbers of the same type using =. This definition has been found wanting in the face of "negative zero", which a Common Lisp is allowed to support. (= +0.0 -0.0) => T according to the IEEE standard, and thus it follows that (EQUALP +0.0 -0.0) => T as well. It is also clear that (EQ +0.0 -0.0) => NIL. The question is what about (EQL +0.0 -0.0) and (EQUAL +0.0 -0.0)? EQUAL is defined to act like EQL on numbers (remember that (EQUAL 3 3.0) => NIL in Common Lisp), so these two issues stand together. A strict reading of the Laser manual, which currently says that two numbers of the same type are EQL just in case they are =, would lead one to conclude that (EQL +0.0 -0.0) => T. Unfortunately this violates the principles behind the original design of EQL. We added EQL to Common Lisp because we felt that certain pairs of otherwise indistinguishable objects failed to be EQ only for implementation dependent reasons. For example, two "different" 1000000000's on the CADR Lisp Machines are possible only because of the word size of the machine. On a 3600 Lisp Machine all such billions are EQ, but all trillions are not. But on both machines all billions, and all trillions, are EQL. We might define EQL by saying that two objects are EQL just in case there is a conceivable Common Lisp implementation in which those "same" two objects would have to be EQ. That definition of EQL is in complete agreement with the one in the Laser manual until one faces minus zero. In no conceivable Common Lisp implementation is -0.0 EQ to +0.0 (some implementations lack it altogether, but that isn't the same thing). EQL objects are intended to be indistinguishable except perhaps by using EQ. Yet -0.0 and +0.0 are distinguishable, by PRINTing them, or by use of the FLOAT-SIGN function, for example. Additionally, having -0.0 be EQUAL to +0.0 would introduce a new twist into the behavior of EQUAL. +0.0 and -0.0 would become the ONLY pair of objects that have distinct printed representations, yet are considered EQUAL. I think we must conclude that the Laser manual is simply being imprecise when it explains that EQL uses = to compare numbers, and that in fact we want it to be the case that (EQL +0.0 -0.0) => NIL.  Received: from CMU-CS-C by SU-AI with TCP/SMTP; 1 Jul 83 15:24:04 PDT Received: ID ; 1 Jul 83 18:22:53 EDT Date: Fri, 1 Jul 1983 18:22 EDT From: Scott E. Fahlman To: common-lisp@su-ai Subject: defmacro &optional OK, it sounds like most people who care about this issue prefer to have the default values for arguments in DEFMACRO be evaluated, as in Maclisp, since that is more general. I seem to be the only one who finds this ugly and/or confusing, so it must just be a bug in my internal representation. The manual should be clarified, preferably with an example, to make it clear that this is the intended behavior. -- Scott  Received: from MIT-ML by SU-AI with TCP/SMTP; 1 Jul 83 12:16:22 PDT Date: 1 July 1983 15:15 EDT From: George J. Carrette To: COMMON-LISP @ SU-AI I get confused trying to figure out why somebody would get confused with defmacro &optional evaluating its optional form specifications.  Received: from MIT-MC by SU-AI with TCP/SMTP; 1 Jul 83 01:31:23 PDT Date: 1 July 1983 04:31 EDT From: Alan Bawden Subject: &optional args in DEFMACRO To: Fahlman @ CMU-CS-C cc: common-lisp @ SU-AI In-reply-to: Msg of Fri 1 Jul 1983 03:47 EDT from Scott E. Fahlman Date: Fri, 1 Jul 1983 03:47 EDT From: Scott E. Fahlman (defmacro foo (a &optional (b 'b-default)) `(list ,a ,b)) (macroexpand (foo 'bar)) Which of the following is returned by the MACROEXPAND: X. (list 'bar b-default) Y. (list 'bar 'b-default) X, (assuming you meant (macroexpand '(foo 'bar))) because its is more general to allow the user to compute something. I personally would write: (defmacro foo (a &optional (b `b-default)) ...) and (defmacro foo (a &optional (b `'b-default)) ...) using backquote to emphasize that this is a form that will return a piece of code as a value. Note that a default is treated just like the body of a defmacro in terms of when it is evaluated etc. A default in a defun is also treated identically to the body of a defun.  Received: from MIT-MC by SU-AI with TCP/SMTP; 1 Jul 83 01:16:46 PDT Date: Friday, 1 July 1983 04:11-EDT From: MOON at SCRC-TENEX To: Scott E. Fahlman Cc: common-lisp at su-ai Subject: &optional args in DEFMACRO In-reply-to: The message of Fri 1 Jul 1983 03:47 EDT from Scott E. Fahlman The default values in defmacro are forms, to be evaluated if the corresponding subform of the invocation of the macro is missing, not automatically-quoted pieces of data. This provides the most generality. Admittedly this can be confusing.  Received: from CMU-CS-C by SU-AI with TCP/SMTP; 1 Jul 83 00:47:41 PDT Received: ID ; 1 Jul 83 03:47:47 EDT Date: Fri, 1 Jul 1983 03:47 EDT From: Scott E. Fahlman To: common-lisp@su-ai Subject: &optional args in DEFMACRO Consider the following bit of code: (defmacro foo (a &optional (b 'b-default)) `(list ,a ,b)) (macroexpand (foo 'bar)) Which of the following is returned by the MACROEXPAND: X. (list 'bar b-default) Y. (list 'bar 'b-default) In other words, is the default argument evaluated at macro-expansion time or is it quoted -- bound to its variable verbatim. The manual is silent on this, I think. To me, answer Y (quoted default) seems intuitively right: since A is bound to a verbatim chunk of the calling form, and B would be too if the calling form were long enough, it seems right to bind B to the default form without evaluation. However, the tradition from Maclisp seems to be that the default is evaluated, producing answer X. It seems that if you want an expansion like Y, you have to write the defmacro arglist as (a &optional (b ''b-default)). At least, that's what Maclisp just did when I tried this -- I'm not sure how old or how ingrained this decision is. Opinions? I guess that post-freeze conservatism would dictate that we should stick with the Maclisp definition, unless this is viewed as obviously wrong. In any event, the manual needs to be tightened here, if it's not too late. -- Scott  Received: from YALE by SU-AI with TCP/SMTP; 30 Jun 83 11:29:00 PDT Received: by YALE-BULLDOG via CHAOS; Thu, 30 Jun 83 14:28:21 EDT Date: Thu, 30 Jun 83 14:20:16 EDT From: Jonathan Rees Subject: misc. stuff To: common-lisp@SU-AI.ARPA Here are some of my random and more-or-less nit-picking remarks about the Laser Edition. [1] Will there be a unified index in the next edition of the manual? I have the impression that Symbolics has decided that it is best to have one index instead of four or five. I certainly agree. [2] Is LAMBDA not defined as a special form? If not, then sections 5.2.2 (LAMBDA-expressions) and 7.1.1 (description of FUNCTION) should make this clear. LAMBDA should be indexed somewhere. [3] Page 38, section 4.8, description of TYPE-OF: "TYPE-OF of one argument" should be just "TYPE-OF" (fifth and sixth lines of that paragraph). [4] Pages 76 and 99: what is the lexical scope of the body of a macro definition? I.e., where do free variables (and functions) get their values? This needs clarification. E.g., what does the following mean? (setq x 8) (eval-when (compile) (setq x 2)) (let ((x 5)) (macrolet ((foo (z) `(+ ,z ,x))) (foo 7))) Does this evaluate to 9, 12, or 15? Does it matter whether the code is being "interpreted" or "compiled"? Can the manual be written in such a way as to let this be explicitly undefined? [5] Page 196, third example in description of STRING-UPCASE et al.: (string-upcase "Dr. Livingston, I presume?" 6 10) should read (string-upcase "Dr. Livingston, I presume?" :start 6 :end 10) [6] Page 229. Section name "Shape-Sign Abbreviations" is misleading - the wo1d "abbreviation" seems pretty random here. Not all syntaxes introduced by # are abbreviations for anything - that is, there aren't other equivalent ways to write most of them. [7] Page 244. Is READ-DELIMITED-LIST defined to side-affect the syntax of its "char" argument in *READTABLE*, even if only temporarily? Presumably it would be implemented by temporarily defining a right-parenthesis-like readmacro character for "char", using UNWIND-PROTECT or something of the sort. If such an implementation is permitted, perhaps this should be mentioned. -Jonathan -------  Received: from CMU-CS-C by SU-AI with TCP/SMTP; 25 Jun 83 09:21:58 PDT Received: ID ; 25 Jun 83 12:21:33 EDT Date: Sat, 25 Jun 1983 12:21 EDT From: Scott E. Fahlman To: steele@CMU-CS-C Cc: common-lisp@su-ai Subject: &whole The manual currently is a bit hazy on where in a defmacro arglist the &whole keyword is legal. I'm assuming anywhere except after &key or &aux. All uses of this that I have seen are stand-alone, but there's no strong reason for the restriction. -- Scott  Received: from MIT-MC by SU-AI with TCP/SMTP; 24 Jun 83 08:08:51 PDT Date: 24 June 1983 11:08 EDT From: Richard E. Zippel Subject: [RZ at MC: Rational and complex numbers] To: Moon @ SCRC-TENEX cc: common-lisp @ SU-AI In-reply-to: Msg of 23 Jun 1983 17:51-EDT from David A. Moon THought it would be useful to mention that these comments I've been sending on numeric issues are really intended more for the 1990 version of Common Lisp than the one that has been frozen. My purpose in sending them was to get them into the record and give people something to think about.  Received: from MIT-MC by SU-AI with TCP/SMTP; 23 Jun 83 14:52:45 PDT Received: from SCRC-EUPHRATES by SCRC-TENEX with CHAOS; Thu 23-Jun-83 17:49:46-EDT Date: Thursday, 23 June 1983, 17:51-EDT From: David A. Moon Subject: [RZ at MC: Rational and complex numbers] To: common-lisp@SU-AI Cc: rz%MIT-MC@SU-DSN Here's a clarification from Rich Zippel of his feelings about rational and complex numbers. I am simply forwarding this to the group for informational purposes; I am not advocating doing anything about it at this time. My feeling is that he is talking at a much higher level than the Common Lisp language deals with. A system for modeling general rings, fields, and other algebras would be a valuable thing to have, but has little to do with the implementation of ordinary arithmetic in Lisp except that the ordinary numbers would be a subset of the data types in which the algebra system would deal. Then we must address the question of whether rational numbers are valuable enough in their own right (rather than as one particular algebra) that they belong in the language. The impression I get is that a number of people have felt that they would far rather use rational numbers than floating-point numbers for certain kinds of computations (e.g. IC layout). Date: Wednesday, 22 June 1983, 14:08-EDT From: Richard E. Zippel Subject: Rational and complex numbers To: Carl W. Hoffman Cc: Moon at SCRC-TENEX, rz at mit-mc Your second message on this topic completed what you said in your first message. I think you should have sent them both together. Were you really trying to say that the design of rationals as proposed for Common Lisp should not be used, or that better designs were possible? Why don't you make an alternate proposal? What I was trying to say, was that the current design of rationals in Common Lisp is inadequate and not sufficiently visionary. I personally think that not having a rational number system in Common Lisp is better than having one which will have to be removed at some later date when we understand the problem more fully. In particular I am afraid that we won't produce a new system, or will resist the introduction of such a system because of the investment that had been made in the current system. Making a good alternate proposal is a major research undertaking. Let me mention some of the issues and some ideas that should be pursued. You are trying to allow users to use algebraic structures based on the integers. There are three issues here: (1) Creation of algrebaic types (2) The gathering together of the appropriate algorithms/code for different types created by the user (3) A theory of coercion. (1) Creation of algebraic types: There are several mechanisms that might be used to create new structures. The following list some of the most important that should be provided by the system. (a) quotient structures: This is how rational numbers are constructed. The numerators and denominators need not come from the same domain, but the denominators must be a subset of the numerators. This allows you to deal with localization, farey sequenced and other mathematical structures. (b) Polynomials: You might think that adding algebraic numbers would be the next construction mechanism, but it is best to build it on top of polynomials. The coefficients must be the elements of some algebraic structure, the exponents are integers. (c) Modular structures. Some domain, were an element different from zero is now assumed to be zero. E.g., integers mod 5, gaussian integers. The guassian integers are polyonomials in X where we have assumed X^2 + 1 is zero. This allows more complex structures like algebraic functions. (d) Matrices, vector spaces, etc. With these constructors most interesting mathematic data structures can be built. (2) Getting the code together. Now that you can build arbitrarily complex structures you are faced with the problem of making sure the right algorithm is associated with a particular operation. This is one of the purposes of the Capsule paper. It describes some mechanisms that allow the creation of an algebraic structure to control the particular algorithms that are used for operations like plus and times. I could go into more detail here later if its interesting. (3) Coercion Coercion is the process of make semantic identification of an abstract mathematical object. Let describe what I've been calling a ``computational structure'' which is one way to deal with some of the problems of coercion. Computational structures consist of a set of domains which are in use (Z and Q are examples, there may be several Z's and Q's), and maps between the these domains. There may be more than one map between two domains. Certain of these maps are labeled as being canonical maps. When an operation like (+ A B) occurs, the following things happen: If A and B come from the same domain, then the + operation of that domain is used (that's the easy case, and the only one I believe should be implemented in Common Lisp now). If A and B are of different domains, then these two domains are located in the computational structure, and the canonical maps are followed to find a domain in which both elements can be considered. These elements are coerced into this new domain using the canonical maps, and the the operation is executed in the new domain. Notice that the new domain need not be the domain of A or B but can be a third domain. There are a lot of complications with the scheme just described, but some variation of it is probably OK. This should give you some idea the issues I'm worried about. [For Dave: Carl and I have spoken about this to some length already, so he can probably fill in many of the details.] It seems to me that you are asking for ways to represent 3*pi, 3*sqrt(2), etc., and, when divided by 4, have these yield (3/4)*pi, (3/4)*sqrt(2), etc. I would say that this has more to do with representing all of R (or with representing extensions of Z) than with the injections of Z into Q. Even if no changes are made to the current design (which is what I expect will happen), don't you feel that the advantages of having simple-minded rationals available in Common Lisp will outweigh the disadvantages? You don't have to use them if you don't want to. If you think this is clear enough and worth saving you might want to forward this to Common-Lisp.  Received: from RUTGERS by SU-AI with TCP/SMTP; 22 Jun 83 23:10:33 PDT Date: 23 Jun 83 02:10:24 EDT From: Dir LCSR Comp Facility Subject: Re: Memberp To: Fahlman@CMU-CS-C.ARPA cc: common-lisp@SU-AI.ARPA In-Reply-To: Message from "Scott E. Fahlman " of 22 Jun 83 01:20:00 EDT Don't take me too seriously. Remember that my comment was simply on the general grounds that we should stick as close to Lisp 1.5 as possible. There is no reason to pay any more attention to my opinion on this issue than in the 1587 other places where incompatibilities have been introduced over my protests. Frankly, I am inclined to agree with the LISPM users who responded, "after completely redesigning the language, why is everybody so upset about MEMBER?" Reminds me of straining out gnats while swallowing camels. Personally I don't want to swallow either gnats or camels, and you can expect to hear protests from me as a matter of principle whenever you deviate from Lisp 1.5. But Common Lisp seems to be commited to swallowing 2 camels, 3 hippopotami, and assorted small alligators. (It is my opinion that at this point the dreaded stacus spaghetticus dwimus could enter and no one would even notice.) So I don't see any reason to reopen things over MEMBER. -------  Received: from MIT-MC by SU-AI with TCP/SMTP; 22 Jun 83 08:36:45 PDT Received: from SCRC-BORZOI by SCRC-TENEX with CHAOS; Wed 22-Jun-83 11:29:35-EDT Date: Wednesday, 22 June 1983, 11:27-EDT From: Daniel L. Weinreb Subject: OPEN for :OUTPUT with version :NEWEST To: RAM%CMU-CS-C@SU-DSN Cc: common-lisp@SU-AI In-reply-to: The message of 22 Jun 83 07:28-EDT from Rob MacLachlan Date: Wed, 22 Jun 1983 07:28 EDT From: Rob MacLachlan In the DEC VAX implementation I have been using, the implementer evidently decided that if an explicit version is specified then an attempt to open for write will error, not supersede, regardless of the :if-exists option. Perhaps this is wrong, but the manual is not very clear on this point. It's definitely wrong, and I think it's clear from the manual that it's wrong, although the manual isn't completely clear about a lot of details of this stuff. It seems to me that the entire point of Pathnames is that they (may) permit implementation independant file handling code to be written. Implementers should be given plenty of rope, but it should be possible to say something as simple as "I want to write this file" in a portable fashion, or the whole exercise is pointless. Certainly. That's why I sent in my previous message. There has to be a defined way for all this stuff to work, or else it's useless for writing portable programs and should be removed from the manual. I think the former is the way to go. Another point about versions; not all operating systems have any real concept of versions. It would seem dubious to forbid an implementation of Common Lisp on UNIX. That's right; the manual ought to address this point. Actually, I think what will happen is that now that the Bible of Common Lisp is nearly finished, it is time to start writing the Talmud, you should pardon the analogy. That is, the Commentary and Interpretation by the Learned Rabbis of Common Lisp. The commentary on this chapter would say that in Rabbi Weinreb's opinion, the meaning of the scriptures is that on operating systems without version numbers, you simply ignore the version component of pathnames when doing an OPEN, and acts as if every pathname had an explicit numeric version of, say, 1, and all files in the file system are of version 1. This is what the Lisp Machine pathname system does, essentially.  Received: from MIT-MC by SU-AI with TCP/SMTP; 22 Jun 83 08:28:13 PDT Date: 22 June 1983 11:28 EDT From: Richard E. Zippel Subject: Rational and complex numbers To: Guy.Steele @ CMU-CS-A cc: common-lisp @ SU-AI In-reply-to: Msg of 12 Jun 83 2346 EDT () from Guy.Steele at CMU-CS-A Date: 12 Jun 83 2346 EDT (Sunday) From: Guy.Steele at CMU-CS-A To: Richard E. Zippel cc: common-lisp at SU-AI Re: Rational and complex numbers I do foresee one entirely plausible application for Gaussian integers, which is graphics applications. For discrete bit-map representations, Gaussian integers may be a very convenient representation. Some interesting work has been done at Yale on picture languages that use complex numbers. I also admit once again to harboring the secret ambition for some form of LISP to supplant FORTRAN... --Guy Another version of this would use an arbitrary two dimensional module instead of the complex numbers. For instance I suspect that if you associate the point (a, b) into a + sqrt(-163)*b, and then plot the powers of (1+ sqrt(-163)) you will get some interesting results. Similarly, taking a some image and then multiplying it by a complex number can lead to interesting versions of scaling. Finally, the wrap around types of windows we used in Space War might be best represented as GF(1031)[x]/(x^2+1) or something (actually GF(1024)xGF(1024) would be more natural).  Received: from CMU-CS-C by SU-AI with TCP/SMTP; 22 Jun 83 04:29:22 PDT Received: ID ; 22 Jun 83 07:28:13 EDT Date: Wed, 22 Jun 1983 07:28 EDT From: Rob MacLachlan To: Daniel L. Weinreb Cc: common-lisp@SU-AI, KMP%MIT-MC@SU-DSN Subject: OPEN for :OUTPUT with version :NEWEST In-reply-to: Msg of 22 Jun 1983 06:46-EDT from Daniel L. Weinreb I would agree that some clarification is called for. I have been in the position of having to write implementation independant file handling code for the Hemlock text editor I am working on, and I have had some difficulty. In the DEC VAX implementation I have been using, the implementer evidently decided that if an explicit version is specified then an attempt to open for write will error, not supersede, regardless of the :if-exists option. Perhaps this is wrong, but the manual is not very clear on this point. Another point about versions; not all operating systems have any real concept of versions. It would seem dubious to forbid an implementation of Common Lisp on UNIX. It seems to me that the entire point of Pathnames is that they (may) permit implementation independant file handling code to be written. Implementers should be given plenty of rope, but it should be possible to say something as simple as "I want to write this file" in a portable fashion, or the whole exercise is pointless. Rob  Received: from MIT-MC by SU-AI with TCP/SMTP; 22 Jun 83 03:47:39 PDT Date: 22 Jun 1983 0646-EDT From: Daniel L. Weinreb Subject: Re: OPEN for :OUTPUT with version :NEWEST To: KMP%MIT-MC@SU-DSN cc: common-lisp@SU-AI In-Reply-To: The message of 22 June 1983 03:54 EDT from Kent M. Pitman The intent of my clarification is simple: without that clarification, some of the OPEN options are meaningless or incomprehensible. If someone asks you "what happens if you OPEN for output with version :NEWEST and :IF-EXISTS :SUPERSEDE, does it use the existing latets file or create a new one?", it's unacceptable to just say "Well, it depends on the implementation, we wouldn't want to constrain any implementation to do any particular thing." Common Lisp's file model already includes the concept of versions, so we're not adding anything new. I'm not trying to overspecify how versions precisely work. The only distinction I'm drawing is between the two meanings that :newest can have (the input meaning and the output meaning, latest version or create new version), and pointing out that :IF-EXISTS controls which one of those happens, which was not at all obvious to me from the manual (Moon had to figure out that such was the implication of the manual). -------  Received: from MIT-MC by SU-AI with TCP/SMTP; 22 Jun 83 00:59:30 PDT Date: 22 June 1983 03:54 EDT From: Kent M. Pitman Subject: OPEN for :OUTPUT with version :NEWEST To: DLW @ SCRC-TENEX cc: common-lisp @ SU-AI In-reply-to: Msg of 21 Jun 1983 17:29-EDT from Daniel L. Weinreb Date: Tuesday, 21 June 1983, 17:29-EDT From: Daniel L. Weinreb The following should be made clear by explicit mention somewhere in the manual: Question: If you call OPEN, and the direction is :OUTPUT or :IO, and the version of the file is :NEWEST, what version number is used? Answer: If the :IF-EXISTS is :NEW-VERSION or unsupplied, then :NEWEST in the pathname means "a version number one higher than the highest version extant." In all other cases :NEWEST in the pathname means "the highest extant version." So if versions 1, 2, and 3 of a file exist, and you open the :NEWEST version for :OUTPUT, then you get version 4 if the :IF-EXISTS is :NEW-VERSION or unsupplied, but you get version 3 if the :IF-EXISTS is anything else (e.g. :SUPERSEDE, :APPEND, :OVERWRITE, :RENAME, et al). Perhaps I'm confused, but isn't it the job of the operating system to decide what the actual filename is? Must the language spec specify "one higher" or should it just say "newer" or "higher". It seems to me like this wouldn't mean any hardship for the users of CL and might make it easier for implementors of some CL systems depending on how the operating system they had treated version numbers (eg, some operating system might not assign a version until the CLOSE happened). My worry here is that we be careful about not defining detail where it's not necessary. I'm not arguing that my position as presented here is right; just requesting commentary/clarification of your intent. --kmp  Received: from CMU-CS-C by SU-AI with TCP/SMTP; 22 Jun 83 00:44:57 PDT Received: ID ; 22 Jun 83 03:44:05 EDT Date: Wed, 22 Jun 1983 03:44 EDT From: Scott E. Fahlman To: info-lispm-mit%mit-oz@mit-mc Cc: common-lisp@su-ai Subject: MEMBER Recently RMS polled asked the opinion of people on this list about the plan to change the definition of MEMBER in Common Lisp. Some of the responses indicated some confusion as to what we (the people who have been working for the last two years to hammer out a Common Lisp definition) are actually proposing. I would like to clarify this before too many people get too upset. For a long time, Lisp has had EQUAL and EQ versions of some of the important operators: MEMBER/MEMQ, DELETE/DELQ, etc. Modern lisps have a lot more data types and a lot more specialized equality predicates: EQL, =, STRING=, etc. Things began to multiply. At one point, we had some 600 of these sequence functions, including such gems as RASS-EQL and DEL-FROM-END-IF-NOT. The decision was made to to cut this number down by providing a small number of powerful generic functions that could be further specialized by the use of keywords. These generic functions were uniformly given the "good" names. Thus we have operators like REPLACE, REMOVE, POSITION, and MEMBER, each of which takes a :TEST keyword telling what sort of equality test to use. In all cases, the default test is EQL, by far the most useful. (Though they are redundant, we kept around MEMQ, DELQ, and ASSQ as historical monuments.) So, if you want something that does what (MEMBER x y) does in Maclisp, you have to say (MEMBER x y :TEST #'EQUAL) in Common Lisp. We considered many alternatives to this scheme: making EQUAL the universal default, having MEMBER default to EQUAL while the other functions default to EQL, or thinking up a new name for the function that does what MEMBER does. In the end, we decided to do what I described above. It seemed clear to us that this would be best in the long run, after everyone has forgotten the details of earlier Lisps, and it seemed like an easy (mechanizable) conversion to put the :TEST 'EQUAL into every MEMBER call in a file. I'm sure that many people will disagree with this choice, but it was not a frivolous or hasty decision; a lot of experienced Lisp implementors agonized for a long time over this one, and finally reached an agreement acceptable to all those participating in the Common Lisp design at that time. That is why we are reluctant to re-open the debate nine-months later, only days before the Common Lisp manual goes to press. -- Scott Fahlman  Date: 21 Jun 83 2320 PDT From: Dick Gabriel Subject: Common Lisp To: common-lisp@SU-AI There is a price and a benefit in seeking to make a new standard language. Being a new standard it can afford to regularize those features of the language that have been recognized as useful. A language like Lisp can grow by adding features pell-mell. The benefit is that when we re-make it we can improve it, though we may alter unimportant parts of the language that are part of its tradition. The price is to give up some habits and familiar paths of programming. When some group decides to implement ``Common Lisp'' except for those some features they like from an older Lisp, then that community has adopted a Common-Lisp-like Lisp. The Lisp they run is not Common Lisp; none of the guarantees of compatibility are extended to them: they must bear the brunt of modifying their code to run on other Common Lisps; and they must re-write other people's code to run on their Lisp. This is their choice. The idea behind a standard is that it is a standard. -rpg-  Received: from MIT-MC by SU-AI with TCP/SMTP; 21 Jun 83 22:50:15 PDT Date: 22 Jun 1983 0146-EDT From: RMS%MIT-OZ%MIT-MC@SU-DSN Subject: My poll of Lisp users To: common-lisp@SU-AI I have forwarded Fahlman's message to all the Lispm users and told them that I will let the MIT system users decide what I should do with MEMBER. Meanwhile, here are the answers I got. From: JBA@MIT-OZ Subject: Function MEMBER to be changed? I agree with you that member shouldn't be changed. From: ZVONA@MIT-OZ Surely Common Lisp conversion will entail many other changes in code. Why is this particular change important? From: EB@MIT-OZ I would prefer to see MEMBER use EQUAL for comparison, as now, because I often use MEMBER on lists of lists. From: DANNY@MIT-OZ I agree with you. From: Randy Davis let's hear it for upward compatibility; yes leave the names unchanged. ------- From: Christopher C. Stacy Since so many other things are going to break, I dont understand why MEMBER is such a big deal. From: Kent M. Pitman I vote yes for the change, as you probably already saw in my mail to Common Lisp. I was originally somewhat worried about this change, but having looked over my code, I find it actually breaks little or nothing. I suspect other people responding might not realize how little effect this will actually have. I have for a long time discouraged people from using MEMBER, which is the nicer name, when MEMQ would be more efficient. I think the name change will be beneficial to code appearance because the new definition of MEMBER is nearly always the appropriate one. When the final Common Lisp document becomes available, I may try to write some helpful facilities for translating existing code to Common Lisp, probably in Teco. This is definitely one of those changes that could be made relatively easily by such a program. From: Jeffrey P. Golden If you are recording votes on the MEMBER etc. CL issue, I strongly agree with your position on this. Not having been aware of the prior discussion amongst CLers on this, when GJC mentioned to me on 6/14 what they were planning to do to MEMBER etc. I immediately responded: 'Horrors, why didn't they just call their version MEMBERP?' (Not exactly in those words.) From: Bruce R. Donald I use member a lot to check for "Yes" (and other strings) in a list of menu choices. Also, (MEMBER VERTEX BOUNDARY) where BOUNDARY is a list of vertices and VERTEX is a DEFSTRUCT of :type list would not work with the common lisp MEMBER, no? From: dove at mit-dspg My personal code does not to my knowledge use member either for lists as members or strings. Thus, the update problem should not affect me. Besides, I have gotten somewhat used to changing things to remain compatible. From: KDF@MIT-OZ To: dove@mit-dspg I use MEMBER and ASSOC in cases where I really mean EQUAL, and MEMQ and ASSQ when I really want EQ. Changing MEMQ and ASSQ to use EQL seems reasonable, but such a change to MEMBER and ASSOC clearly do not. From: dove at mit-dspg Given that member is often used on the lispm to check for strings in things like menus, it seems that equal would be preferable. The crux of the issue seems to be the simplification of that code (and the ability to leave old code unmodified) versus speed. From: Dick@MIT-MC I agree that there is no reason to incompatibly change the meaning of any function unless absolutely necessary. It sure doesn't seem necesarry here. Dick -------  Received: from CMU-CS-C by SU-AI with TCP/SMTP; 21 Jun 83 22:21:14 PDT Received: ID ; 22 Jun 83 01:20:40 EDT Date: Wed, 22 Jun 1983 01:20 EDT From: Scott E. Fahlman To: rms%mit-oz@mit-mc, Common-Lisp@su-ai Subject: Memberp The comments that I have received on the MEMBERP issue indicate that, with the exception of Chuck Hedrick (and RMS himself), none of the people responsible for Common Lisp implementation efforts believe that it is a good idea to adopt RMS's changes in MEMBER and friends. Three different sets of reasons have been offered by the people responding: 1. People are not convinced that changing MEMBER to use EQL makes substantially more trouble for RMS and his users than changing MEMBER to MEMBERP would make for the rest of us, despite RMS's argument that we could go on using our version of MEMBER. 2. The original reasons why we chose to make this change (regularity in the choice of names leading to much less confusion in the long run) are still valid. 3. Frozen is frozen. It's hard enough to get consensus without reopening the debate every time someone wakes up and notices something he doesn't like. Even if we discount the opinions of the Symbolics people, who might be imagined to have political reasons for opposing RMS in this, the clear majority still seems to favor leaving the manual as it is, with MEMBER using EQL. As far as I'm concerned, that's the end of it. I hope that RMS will choose to remain compatible with Common Lisp despite this decision, but that's up to him. All of us have had to make some major compromises in the course of this effort, and so far everyone has stayed aboard. -- Scott  Received: from SU-DSN by SU-AI with PUP; 21-Jun-83 16:12 PDT Received: From MIT-XX by SU-DSN.ARPA; Tue Jun 21 15:55:41 1983 Received: from SCRC-BORZOI by SCRC-SPANIEL with CHAOS; Tue 21-Jun-83 17:29:43-EDT Date: Tuesday, 21 June 1983, 17:29-EDT From: Daniel L. Weinreb Subject: OPEN for :OUTPUT with version :NEWEST To: common-lisp at SU-AI The following should be made clear by explicit mention somewhere in the manual: Question: If you call OPEN, and the direction is :OUTPUT or :IO, and the version of the file is :NEWEST, what version number is used? Answer: If the :IF-EXISTS is :NEW-VERSION or unsupplied, then :NEWEST in the pathname means "a version number one higher than the highest version extant." In all other cases :NEWEST in the pathname means "the highest extant version." So if versions 1, 2, and 3 of a file exist, and you open the :NEWEST version for :OUTPUT, then you get version 4 if the :IF-EXISTS is :NEW-VERSION or unsupplied, but you get version 3 if the :IF-EXISTS is anything else (e.g. :SUPERSEDE, :APPEND, :OVERWRITE, :RENAME, et al).  Received: from MIT-MC by SU-AI with TCP/SMTP; 20 Jun 83 20:53:56 PDT Date: 20 Jun 1983 2351-EDT From: RMS%MIT-OZ%MIT-MC@SU-DSN To: common-lisp@SU-AI I asked the user community specifically whether they would rather see the new Common Lisp function named MEMBERP rather than MEMBER. This is not a poll on the question of aesthetic improvement of the language, such as might have been done last August (but for which a poll of the user community as a whole is less relevant than a poll of people interested in language design). I find from this poll that about half the users strongly wish to avoid a conversion, while the other half think it doesn't matter. If this extrapolates to the users of all the hundred or so Lisp machines in the world, that's a lot of users who would rather avoid the conversion. -------  Received: from USC-ECL by SU-AI with TCP/SMTP; 20 Jun 83 14:21:31 PDT Received: from MIT-MC by USC-ECL; Mon 20 Jun 83 14:18:32-PDT Received: from SCRC-BEAGLE by SCRC-TENEX with CHAOS; Mon 20-Jun-83 17:17:47-EDT Date: Monday, 20 June 1983, 17:14-EDT From: Bernard S. Greenberg Subject: keywordp To: common-lisp%su-ai@USC-ECL For the 1990 manual,... Every time I have written (keywordp x), I have had to change it to (and (symbolp x) (keywordp x)). I suppose the profound observation is that keywords are more like numbers than like symbols.  Received: from CMU-CS-C by SU-AI with TCP/SMTP; 19 Jun 83 18:03:22 PDT Received: ID ; 19 Jun 83 21:02:05 EDT Date: Sun, 19 Jun 1983 21:02 EDT From: Scott E. Fahlman To: common-lisp@su-ai Cc: rms%mit-oz%mit-mc@su-dsn Subject: MEMBER, etc. I agree with Stallman that at this point we should not be discussing the merits and aesthetics of MEMBER vs. MEMBERP. We did that once, and made a decision. The time for aesthetic improvements to the language (first edition) is over. For that reason, I find his poll of MIT users on whether they want good old-fashioned MEMBER to stay the way it is to be totally irrelevant to this discussion; last August, that might have been valuable input, but not now. I disagree strongly with Stallman's view that we have some obligation to make his proposed changes unless someone comes up with a compelling reason not to. Whether RMS heard about it or not, the manual is frozen and the presumption must be strongly in favor of not making any changes to it. It now requires a truly compelling reason to make any change. We are considering the MEMBER => MEMBERP change, if at all, because it is a sort of emergency request. Stallman's claim is that (1) changing to MEMBERP is so trivial a change that we should consider it even at this late date, (2) it costs existing implementations nothing to make the change, and (3) it causes the MIT/LMI/Stallman implementation terrible problems to leave MEMBER the way it currently is, with EQL as the default. In other words, according to RMS, the cost to him of not making the change is very much greater than cost to the rest of us of making the change. That is the ONLY reason that I can see why a change of this sort would be considered now. After thinking about this issue, I now believe that all three of the above-mentioned points are greatly exaggerated. (1) As we see from RMS's note, the proposal now is to alter MEMBER, ASSOC, RASSOC, DELETE, DELETE-IF, DELTE-IF-NOT, REMOVE, REMOVE-IF, and REMOVE-IF-NOT. In several cases, the proposal involves changing the sense of a test. The ASSOC and RASSOC functions are to be replaced with uses of FIND. This is not such a trivial change any more. (2) The claim is that since Common Lisp would no longer define MEMBER, ASSOC, RASSOC, DELETE, DELETE-IF, DELETE-IF-NOT, REMOVE, REMOVE-IF, and REMOVE-IF-NOT, those of us who have made the transition already (and our users) could just leave these functions as they are and add the new forms beside them. Thus, RMS claims, the cost of this conversion is zero for us. I can't speak for the other implementations, but we at CMU are quite strongly committed to working within the bounds of portable Common Lisp wherever possible. This means that if MEMBER is not a part of Common Lisp and MEMBERP is, we have to change our code to use MEMBERP. RMS is technically correct -- if we didn't do this, our code would still run -- but we are quite unwilling to have fossilized relics of earlier editions of Common Lisp sprinkled through our system. So, in realistic terms, the cost to us of making all of RMS's changes is far from zero. I'm not saying that it is a terrible cost, but it is significant. A far greater cost, in my opinion, would be the confusion in the minds of those users who have already made the transition to the new Common Lisp -- one of the most confusing things you can do is to make a decision on something like this, sell people on it, and then reverse it six months later. (3) After giving the matter some thought, I no longer believe that a one-time change-over to use the EQL versions of MEMBER and friends would be such a big deal for RMS and his users. In the time he has spent arguing about this, he could easily have implemented an Emacs or Zwei command to turn all occurrences of (MEMBER x y) in a file into (MEMBER x y :TEST #'EQUAL), and likewise for the other forms he's worried about. He might not WANT to make the changeover, but it would not be the terrible ordeal that he suggests. In fact, I believe that it would be no more work for him to make that change than for us to make the changes he proposes. A lot of people with a lot of working code have already made that change, and have lived to tell about it. So, while I thought it appropriate to bring Stallman's urgent request to the attention of this list, my own opinion is that the case is not strong enough to warrant making these changes to the language definition at the last minute. -- Scott  Received: from MIT-MC by SU-AI with TCP/SMTP; 19 Jun 83 15:58:03 PDT Date: 19 June 1983 18:57 EDT From: Kent M. Pitman Subject: MEMBER, MEMBERP To: Common-Lisp @ SU-AI cc: RMS @ MIT-MC When this subject came up the last time, it was argued by several people that most usages of MEMBER were due to people using numbers in lists, since numbers aren't guaranteed EQ. It was argued that most people were using MEMBER where they really didn't need all its power. I was mildly against this move when it originally came up, but in checking back over pieces of code I've written, there are very few places where it would matter and I'm inclined to buy the argument that those few places should be changed in the mechanical way suggested in order to clean up the language. I think the right approach to any compatibility packages might be to make a MACLISP: package which people could build inferiors to if they didn't like LISP:. It could shadow things like MEMBER, etc. and define them with the old semantics. I can't believe this problem is the only one of its kind in Common Lisp. There are other incompatible changes. Code will have to be looked over before it can be said to be running correctly anyway. At this point, I see the goal of compatibility to mean not that code would run directly but more that code could be mechanically translated (rather than requiring major re-thinking) in order to run. The implementors need to decide if this is in fact what they intend. If the claim that CL really needs to run code compatibly with existing dialects is true, there are a pile more changes we'd better start making right now. If, instead, the claim is that the language will successfully support a compatibility mode (eg, a MACLISP: package to build systems under, or a MACLISP => COMMON-LISP translator), then I think the change to MEMBER is certainly among the least dangerous of the changes being made and I think it's a very poor precedent to set. Common Lisp is, and always has been, dangerously on the brink of being too wishy-washy to be a good language in and of itself. It has had to yield to the needs of so many design constraints from so many applications that it's been difficult to pull together. My feeling is that its overall effect will probably be positive because it did actually rise above quibbles with absolute compatibility and try to present itself as less of a hodge-podge than most of the languages it seeks to make compatible. Regularization of naming and semantics of operators where it has happened, even where the possibility exists of introducing an incompatibility with some dialect, is perhaps the most important contribution of the language. I think we should just stand with the spec we've got, provide users with as much data we can about mechanical rewrites they'll need to do -- perhaps even programs to help with the rewrites -- and go with that.  Received: from MIT-MC by SU-AI with TCP/SMTP; 19 Jun 83 14:52:42 PDT Return-path: Mail-From: RMS created at 19-Jun-83 08:16:55 Date: Sunday, June 19, 1983 8:16AM-EDT From: Richard M. Stallman Subject: Function MEMBER to be changed? To: info-lispm-mit at MIT-OZ Remailed-date: 19 Jun 1983 1752-EDT Remailed-from: RMS%MIT-OZ%MIT-MC@SU-DSN Remailed-to: common-lisp@SU-AI It happens that the Common Lisp plan involves changing the function MEMBER (and ASSOC and DELETE and REMOVE) to use EQL instead of EQUAL for comparison. (EQL is like = on numbers, like EQ on everything else). I have urged them to call the new functions MEMBERP and other new names so that the old names MEMBER, ASSOC, etc. can be unchanged. I expect most of you prefer to have the existing names not change their meanings. I'd like to know whether you think this is important. Please send me mail about what you feel about this, and I will pass it on to the Common Lisp designers. (If you prefer to have MEMBER change, you can tell me that.)  Received: from CMU-CS-C by SU-AI with TCP/SMTP; 19 Jun 83 14:11:33 PDT Received: ID ; 19 Jun 83 17:10:42 EDT Date: Sun, 19 Jun 1983 17:10 EDT From: Scott E. Fahlman To: RMS%MIT-OZ%MIT-MC@SU-DSN Cc: common-lisp@SU-AI In-reply-to: Msg of 19 Jun 1983 16:13-EDT from RMS%MIT-OZ%MIT-MC at SU-DSN Please send a copy of your query on MEMBER to Common-Lisp@su-ai so that we can see exactly what people are responding to. Thanks. -- Scott  Received: from RUTGERS by SU-AI with TCP/SMTP; 19 Jun 83 13:42:29 PDT Date: 19 Jun 83 16:41:37 EDT From: Dir LCSR Comp Facility Subject: Re: MEMBER To: Fahlman@CMU-CS-C.ARPA cc: common-lisp@SU-AI.ARPA, RMS@MIT-MC.ARPA In-Reply-To: Message from "Scott E. Fahlman " of 18 Jun 83 23:51:00 EDT In general I favor any move that would cause Common Lisp to be more compatible with Lisp. I would be completely unsympathetic to someone who said that he needed a last-minute new feature. But in my opinion it is never too late to move back towards Lisp. -------  Received: from MIT-MC by SU-AI with TCP/SMTP; 19 Jun 83 13:40:17 PDT Date: 19 Jun 1983 1613-EDT From: RMS%MIT-OZ%MIT-MC@SU-DSN To: common-lisp@SU-AI I have asked the Lisp machine user community to say how important they consider the issue of MEMBER, etc. I will accumulate the replies and inform people of how the user community feels in a couple of days. It seems that there is a responsibility to ask them, not just system implementors and designers, since the decision will impact them as much as us. -------  Received: from MIT-MC by SU-AI with TCP/SMTP; 19 Jun 83 11:08:44 PDT Date: Sunday, June 19, 1983 2:05PM-EDT From: Richard M. Stallman Subject: MEMBER, etc. To: common-lisp at SU-AI It seems that people are starting to discuss the question of whether they, and the users of their Lisp systems, will benefit from renaming MEMBER to MEMBERP in Common Lisp. This subject is relevant to the question of whether to rename it, but is not the same subject. If anyone finds that his users would benefit from the renaming, that is an additional reason to make the renaming. But the fact that some Lisp system, such as NIL, has changed MEMBER, or is willing to change MEMBER, only means the absense of a reason to rename the function in Common Lisp. It is not any sort of reason NOT to rename it. If the renaming were done, presumably GSB would not want to change the definition of MEMBER a second time. That is fine. Common Lisp would no longer define MEMBER and there would be no reason he had to change it. Nobody would have to change it. NIL users would not be inconvenienced. There are only two reasons I can see which could be used to argue against the change: 1) the name MEMBER is a nicer name than MEMBERP (if it is one) 2) some people have written portable code that uses MEMBER. It seems clear that the amount of such portable code is small at this date compared to the amount of Lisp machine code. 1) is a matter of opinion and one could see it either way. The functions that are the problem are MEMBER, ASSOC, RASSOC, DELETE etc. and REMOVE etc. This is what I suggest to do about them: MEMBER -> MEMBERP ASSOC, RASSOC: Delete them. It is easy to use FIND for this purpose, as described in the documentation of FIND. This can be seen as making the design cleaner. REMOVE: Rename to FILTER, and change the sense of the test. That is, change :TEST to :TEST-NOT and vice versa; an element is kept if it passes the test. DELETE Rename to NFILTER and change the sense of the test. SUBSET is a possible alternative to FILTER. Or perhaps REMOVE -> FIlTER-MATCH, REMOVE-IF-NOT -> FILTER, REMOVE-IF -> FILTER-NOT.  Received: from CMU-CS-C by SU-AI with TCP/SMTP; 18 Jun 83 20:53:03 PDT Received: ID ; 18 Jun 83 23:51:58 EDT Date: Sat, 18 Jun 1983 23:51 EDT From: Scott E. Fahlman To: common-lisp@su-ai Cc: RMS@mit-mc Subject: MEMBER Richard Stallman phoned me today with an urgent request that we reconsider our earlier decision to have a MEMBER function that uses EQL as the default test. He wants us to use MEMBERP (or some other name) for this, so that various compatibility packages can go on providing MEMBER as a function with an EQUAL test. At one point, several of us (including me) advocated this move, but nobody could come up with a good name for the EQL-defualt version of MEMBER. I think that MEMBERP was considered at one point, but was rejected as being inconsistent with the way we are naming the other sequence and list functions. (No "P"'s hanging from any of the others.) Finally, either on the August '82 ballot or at the meeting, we decided to go with MEMBER as the name of the EQL-defualt function. It was observed that any file consistently using MEMBER in the old way could be translated automatically to (MEMBER x y :TEST #'EQUAL). Since then, a lot of code has been written that uses the new form of MEMBER, so there is a cost of converting new code back to balance against the cost of converting old code forward. I pointed out that we had frozen the manual, but RMS felt that this should be made a special case on the following grounds: 1. It is a trivial change that could be put into the manual and into our implementations at the last minute. 2. This issue is so important to him and to his user community that he would probably split with Common Lisp rather than convert to the new-style MEMBER. 3. Stallman (and, he says, also Greenblatt) was somehow under the impression that we had decided in August to leave MEMBER alone. He only just realized that the manual contradicts this, and was also taken by surprise by the "flag day" freeze -- he has not been following the Common Lisp mailing list. I am opposed to reopening this issue or any other issue at this point. However, I did agree to send a query to the Common Lisp mailing list to see whether there is significant support for this change, given Stallman's position. I am not in a position to assess how critical Stallman's implementation effort is to Lisp Machine users at MIT or what the effect might be of a split over this issue, so I didn't want to unilaterally rule out any change in our position. Opinions? -- Scott  Received: from MIT-MC by SU-AI with TCP/SMTP; 17 Jun 83 16:23:18 PDT Received: from SCRC-MENOTOMY by SCRC-TENEX with CHAOS; Fri 17-Jun-83 19:09:04-EDT Date: Friday, 17 June 1983, 19:25-EDT From: Robert A. Cassels Subject: Rounding on output To: Fahlman%CMU-CS-C@SU-DSN, Cassels%SCRC-TENEX%MIT-MC@SU-DSN Cc: Common-Lisp@SU-AI In-reply-to: The message of 16 Jun 83 20:59-EDT from Scott E. Fahlman Date: Thu, 16 Jun 1983 20:59 EDT From: Scott E. Fahlman Do we really have to lay down complicated rules for rounding of printed flonums in the white pages? I can't believe that all of these marginal cases matter. Why don't we just say that the results are supposed to be rounded appropriately and let the implementors worry about overflow conditions and how to break ties and what is done with the last bit. What happens on ties hardly matters, since there is only one value of exponent for which ties can occur. In general, I agree that accuracy in printing isn't so important. But there are enough strange behaviors when you drop a few bits that I believe it's worth the trouble. If Common Lisp is to be used for any sort of serious mathematical work, any rigor we can introduce will be appreciated down the road. Why stop with rational numbers? I would certainly like the reader to be accurate. Otherwise it's a real pain to write approximation routines with nice properties -- like monotonicity. Are we to be reduced to writing octal constants just to be sure that all the bits are right? How do you write PI (which is supposed to be "the best possible approximation") in a machine-independent manner?  Received: from CMU-CS-A by SU-AI with TCP/SMTP; 16 Jun 83 20:46:53 PDT Date: 16 Jun 83 2344 EDT (Thursday) From: Guy.Steele@CMU-CS-A To: Robert A. Cassels Subject: Re: Rounding on output CC: common-lisp@SU-AI In-Reply-To: "Robert A. Cassels's message of 16 Jun 83 17:47-EST" I agree with your clarified text on ideal floating-point I/O. For the last eight months I have been one month away from completing a paper containing what I claim, with proofs, to be a completely correct and accurate binary-to-decimal floating-point conversion algorithm. (It has been continuously punted in favor of the Common LISP Manual.) It is my hope that this algorithm will prove suitable for use in Common LISP implementations. --Guy  Received: from CMU-CS-C by SU-AI with TCP/SMTP; 16 Jun 83 17:59:32 PDT Received: ID ; 16 Jun 83 20:59:02 EDT Date: Thu, 16 Jun 1983 20:59 EDT From: Scott E. Fahlman To: Robert A. Cassels Cc: Common-Lisp@SU-AI Subject: Rounding on output In-reply-to: Msg of 16 Jun 1983 18:47-EDT from Robert A. Cassels Do we really have to lay down complicated rules for rounding of printed flonums in the white pages? I can't believe that all of these marginal cases matter. Why don't we just say that the results are supposed to be rounded appropriately and let the implementors worry about overflow conditions and how to break ties and what is done with the last bit. I am aware that rounding is a very serious matter in floating-point arithmetic, since if it is not done right the insignificant roundoff errors can accumulate and drop your space shuttle into the middle of Manhattan. But I don't think that such considerations apply in printed flonums, since it is hard for any substantial error to accumulate in a small number of print/read cycles. -- Scott  Received: from MIT-MC by SU-AI with TCP/SMTP; 16 Jun 83 15:50:25 PDT Received: from SCRC-MENOTOMY by SCRC-TENEX with CHAOS; Thu 16-Jun-83 18:49:50-EDT Date: Thursday, 16 June 1983, 18:47-EDT From: Robert A. Cassels Subject: Rounding on output To: kmp%MIT-MC@SU-DSN, Common-Lisp@SU-AI In-reply-to: The message of 16 Jun 83 17:02-EDT from Kent M. Pitman Date: Thursday, 16 June 1983, 17:02-EDT From: Kent M. Pitman With one exception, I have no special opinions about rounding on output and will take whatever is given. The exception is that the rounding should be defined to always produce a valid number, even if in some cases that means violating the normal rounding rule once in a while. In Maclisp, the largest flonum (octal 377777,,777777) can be typed in by 1.70141182e+38 but will type out as 1.70141183e+38, which cannot be re-read because it gives a numeric overflow error. I can't decide if this is relevant to ~G, etc. or just to general PRIN1, but figured this was as good a time as any to mention it... This problem is only vaguely related to "rounding". The real thing you are asking for (which is not true of most reader/printer pairs) is that the (read (print .)) be an identity. Most readers and printers are sloppy about that, especially for exponents of large magnitude. The current Lisp Machine reader is very sloppy. I think that the "valid number" requirement is in fact wrong. If I ask for your largest flonum to be printed to only one decimal place, I would certainly like to see 2.e+38, even though that is not a valid number. But invalid numbers should only occur when I specify the length of the printed result. So the correct wording of your requirement is something like: "The (binary) floating-point value read shall be closer to the decimal value than any other floating-point value of the same length." "The decimal value printed shall be closer to the (binary) floating-point value than it is to any other representable floating-point value of the same length." [Although that doesn't exactly rule out printing decimal values beyond the range of floats, I don't see how to word it without getting into ULPs (units in the last place) or other nasty stuff. Guy??]  Received: from MIT-MC by SU-AI with TCP/SMTP; 16 Jun 83 14:02:15 PDT Date: Thursday, 16 June 1983, 17:02-EDT From: Kent M. Pitman Subject: Rounding on output To: Common-Lisp at SAIL With one exception, I have no special opinions about rounding on output and will take whatever is given. The exception is that the rounding should be defined to always produce a valid number, even if in some cases that means violating the normal rounding rule once in a while. In Maclisp, the largest flonum (octal 377777,,777777) can be typed in by 1.70141182e+38 but will type out as 1.70141183e+38, which cannot be re-read because it gives a numeric overflow error. I can't decide if this is relevant to ~G, etc. or just to general PRIN1, but figured this was as good a time as any to mention it...  Received: from MIT-MC by SU-AI with TCP/SMTP; 16 Jun 83 11:32:27 PDT Date: Thursday, 16 June 1983 13:58-EDT From: MOON at SCRC-TENEX To: Robert A. Cassels Cc: Common-Lisp at SU-AI Subject: floating-point format In-reply-to: The message of 16 Jun 1983 12:13-EDT from Robert A. Cassels Decimal rounding of the digits printed, and tie-breaking according to system-dependent standards (IEEE for us) sounds reasonable to me.  Received: from SU-DSN by SU-AI with PUP; 16-Jun-83 11:18 PDT Received: From MIT-XX by SU-DSN.ARPA; Thu Jun 16 11:01:04 1983 Received: from SCRC-MENOTOMY by SCRC-SPANIEL with CHAOS; Thu 16-Jun-83 12:13:32-EDT Date: Thursday, 16 June 1983, 12:13-EDT From: Robert A. Cassels Subject: floating-point format To: Moon at SCRC-TENEX, Common-Lisp at SU-AI In-reply-to: The message of 31 May 83 23:41-EDT from David A. Moon Date: Tuesday, 31 May 1983, 23:41-EDT From: David A. Moon ... 16. Guy proposes the following treatment of floating point in FORMAT: ~w,d,pF ~w,d,x,pE ~w,d,pG The meanings of the arguments are exactly as for the FORTRAN-77 language as described in chapter 13 of the FORTRAN-77 standard, with the following exceptions and extensions: ... From ANSI X3.9 1978 (selected highlights from chapter 13) F editing: Optional blanks, optional sign, and a string of digits that contains a decimal point, rounded to d fractional digits. Leading zeros are not permitted except for an optional zero immediately to the left of the decimal point if the magnitude is less than one. The optional zero must appear if there would otherwise be no digits in the output field. [It says nothing about trailing zeros.] I guess we need to be specific about rounding. The spirit of Fortran, if not the letter, is that all digits printed are rounded in decimal. (Specified for F-format, but not for E-format.) Fortran rounding on ties is away from zero. (2.5 => 3, -2.5 => -3) IEEE says that binary-decimal conversions must respect the rounding mode, and the default rounding mode rounds to even on ties. Do we want to require that all digits printed be decimal-rounded for all formats? [I think so.] What rounding happens on ties? [I don't care -- either Fortran rounding or round-to-nearest-even is acceptable.]  Received: from SU-DSN by SU-AI with PUP; 15-Jun-83 09:37 PDT Received: From MIT-XX by SU-DSN.ARPA; Wed Jun 15 09:37:11 1983 Received: from SCRC-EUPHRATES by SCRC-SPANIEL with CHAOS; Wed 15-Jun-83 00:47:06-EDT Date: Wednesday, 15 June 1983, 00:44-EDT From: David A. Moon Subject: DEFCONSTANT and EQ To: common-lisp at su-ai In-reply-to: The message of 12 Jun 83 15:25-EDT from Scott E. Fahlman , The message of 8 Jun 83 16:19-EDT from Bernard S. Greenberg , The message of 8 Jun 83 21:11-EDT from Glenn S. Burke , The message of 8 Jun 83 14:46-EDT from Bernard S. Greenberg , The message of 8 Jun 83 14:11-EDT from Bernard S. Greenberg , The message of 8 Jun 83 09:55-EDT from Scott E. Fahlman , The message of 8 Jun 83 01:46-EDT from Guy.Steele at CMU-CS-A, The message of 8 Jun 83 01:40-EDT from Scott E. Fahlman , The message of 8 Jun 83 02:47-EDT from Kent M. Pitman , The message of 7 Jun 83 22:16-EDT from David A. Moon Date: 8 June 1983 0146-EDT (Wednesday) From: Guy.Steele@CMU-CS-A The initial-value form to DEFCONSTANT is conceptually evaluated at load time. DEFCONSTANT is an invitation to the compiler to susbtitute the value for occurrences of the constant *if* the compiler is smart enough to do so. DEFCONSTANT is not meant to side-effect the compiler's environment. (DEFCONSTANT FOO 3) (DEFCONSTANT BAR (+ FOO 6)) entitles the compiler to use the value 9 for BAR provided that it is smart enough to analyze what it going on (actually notall that hard: the first declaration entitles the compiler to substitute 3 for FOO, whereupon some simple constant folding reduces (+ 3 6) to 9). Date: Sun, 12 Jun 1983 15:25 EDT From: Scott E. Fahlman 1. DEFCONSTANT does not create a "symbol macro". Conceptually, it evaluates the init form at load time and sets the global special value of the variable to that value. It also causes this symbol to be CONSTANTP. The semantics of DEFCONSTANT differs from DEFVAR only in that you must supply an init and you are declaring to the compiler that the value of the variable will never be changed. The compiler can do whatever it wants to with that information, but it must preserve the variable-reference semantics. If the user violates this declaration, it it "is an error" and might cause bad things to happen, but it might not be signalled. 4. Given the above rules, if X is a constant defined by DEFCONSTANT, the compiler knows that it is safe to substitute the initial value V (quoted) for references to X if V is a number of any kind, a symbol, or any kind of immediate object whose creation involves no consing. A more complex compiler might be able to substitute for other kinds of V if it can prove that the value is consumed locally in a way that does not depend on EQ-ness, and that it cannot escape the local environment to be EQ-tested elsewhere. I agree with this. An example of your last sentence would be the byte-specifier argument to LDB. Date: Wednesday, 8 June 1983, 16:19-EDT From: Bernard S. Greenberg The loading of a DEFCONSTANT changes the symbol being defined in a (so far) unalterable fashion. There ought to be an in-language way to revoke this effect. This is important. UNDEFCONSTANT is a reasonable name. Date: 8 June 1983 21:11 EDT From: Glenn S. Burke The one thing which needs to be clearly specified is how the semantics of "added to the compilation environment" differs from what might be done by (eval-when (compile) ...). If, for instance, defmacro does not bash the runtime environment, then the user will have to use eval-when if the macro needs to be usable via the interpreter during the compilation. Eval-when should do exactly that: evaluate and bash the runtime environment. Always, without exception, no matter what "added to the compilation environment" might mean. My own experience is that it is generally a loss for "added to the compilation environment" to bash the runtime environment. I agree with this. (eval-when (compile ...) form) should eval form, no ifs, ands, or buts. Forms seen by the compiler and not inside an eval-when-compile should not affect the run-time environment, to the extent that is possible (it is unlikely to be possible for the package declaration forms). The manual should clearly document which forms affect the environment in which the compiler (and the user's macros) are running when seen by the compiler. Note that, contrary to several people's mail, packages are no help in keeping the run-time and compile-time environments straight, any time you are compiling a program that you also run in the compiler. Even in a system where the compiler is run in a separate Lisp, there is an issue when compiling a system of macros, for example, since it has to run in the compiler as well as being compiled. Getting back to DEFCONSTANT, evaluation of its initial-value subform should not affect the run-time environment -- the compiler should analyze the initial value, not EVAL it. Furthermore the value of the symbol should not change in the compiler's environment; the compiler should remember the constant value someplace else. Only when the DEFCONSTANT is actually loaded should the value of the symbol be changed. Later we might want to standardize some tools for getting at the compile-time environment. For instance, a macro running in the compiler can use CONSTANTP to determine that a symbol has been declared to be a DEFCONSTANT, and hence that its value won't change no matter what code is executed between two successive references [this is the sort of thing SETF needs to know, for example]. However the current language provides no way for that macro to find out what the actual value of the DEFCONSTANT is. And of course, given the above definition the compiler may not even -know- what the actual value of the DEFCONSTANT is going to be. Pathologically, (DEFCONSTANT FUBAR (MACHINE-INSTANCE)) (DEFCONSTANT SPAM (FUNCTION-HALTS-P 'BAZ)) Date: Wednesday, 8 June 1983, 14:46-EDT From: Bernard S. Greenberg The answer to "What kind of evaluator or meta- evaluator should be invoked on the second operand of DEFCONSTANT?" is "the compiler's pass-1 optimizer/reducer"! That is not something we do now, but there is no good reason why not. Actually we do do this in our "DEFSYSCONSTANT" stuff (which is associated with the Lisp cold-load generator, declaring constants that will be constant in the Lisp system being built.) But we don't do it yet in our Common Lisp DEFCONSTANT implementation. Date: 8 June 1983 02:47 EDT From: Kent M. Pitman I am still bothered that on the LispM, the compiler does a side-effect to my compile-time environment when it sees DEFSETF, for example. Indeed, this is wrong, and some day we have to get our act together and fix this kind of thing. It means that DEFSETF and SETF have to have explicit knowledge of the two separate environments, unless you don't want merely compiling a DEFSETF (without loading it) to affect the subsequent expansion of SETF in the same compilation.  Received: from SU-DSN by SU-AI with PUP; 15-Jun-83 09:37 PDT Received: From MIT-XX by SU-DSN.ARPA; Wed Jun 15 09:38:49 1983 Received: from SCRC-EUPHRATES by SCRC-SPANIEL with CHAOS; Wed 15-Jun-83 02:21:52-EDT Date: Wednesday, 15 June 1983, 02:21-EDT From: David A. Moon Subject: Re: Happy Flag Day To: Bernard S. Greenberg Cc: Common-Lisp at SU-AI In-reply-to: The message of 14 Jun 83 23:36-EDT from Bernard S. Greenberg Date: 14 Jun 1983 2336-EDT From: Bernard S. Greenberg Leave SUBST (historical reasons) and fix SUBSTITUTE &c. But (p. 182) SUBST new old tree &key :test :test-not :key SUBST-IF predicate new tree &key :key So historical reasons make no sense. No one proposes to make the args to SUBST be old first then new. I can live with whichever Guy decides to change (SUBST-IF or SUBSTITUTE-IF) as long as he makes them consistent.  Received: from RUTGERS by SU-AI with TCP/SMTP; 15 Jun 83 09:34:26 PDT Date: 15 Jun 83 12:14:08 EDT From: Dir LCSR Comp Facility Subject: consistency To: common-lisp@SU-AI.ARPA This is a general comment, not aimed at any specific message, but at a number that I have seen. If we try to make all of Common Lisp consistent in argument order and everything else, we are going to be here for years. In my opinion it is more important to keep it consistent with other dialects of Lisp. This is not supposed to be a new language. It originally started out to be a common subset of the various Maclisp dialects. Personally I wish it had stayed as that, but that is obviously impossible. However I would at least like it to continue to be a dialect of Lisp. This means that people who have studied a standard textbook in Lisp should be able to use it without finding that all of the functions have been renamed for "consistency", argument orders have been changed, etc. Of course we can always put back traditional functions that you have left out, but it is much harder for us to change back to traditional argument orders. -------  Received: from MIT-ML by SU-AI with TCP/SMTP; 15 Jun 83 05:30:04 PDT Date: 15 Jun 1983 0749-EDT From: Bernard S. Greenberg Subject: Re: Happy Flag Day To: Moon%SCRC-TENEX%MIT-ML@SU-DSN cc: Common-Lisp@SU-AI In-Reply-To: The message of Wednesday, 15 June 1983, 02:21-EDT from David A. Moon Return-path: Received: from SCRC-SPANIEL by SCRC-TENEX with CHAOS; Wed 15-Jun-83 02:22:19-EDT Received: from SCRC-EUPHRATES by SCRC-SPANIEL with CHAOS; Wed 15-Jun-83 02:21:52-EDT Date: Wednesday, 15 June 1983, 02:21-EDT From: David A. Moon Subject: Re: Happy Flag Day To: Bernard S. Greenberg Cc: Common-Lisp at SU-AI In-reply-to: The message of 14 Jun 83 23:36-EDT from Bernard S. Greenberg Date: 14 Jun 1983 2336-EDT From: Bernard S. Greenberg Leave SUBST (historical reasons) and fix SUBSTITUTE &c. But (p. 182) SUBST new old tree &key :test :test-not :key SUBST-IF predicate new tree &key :key So historical reasons make no sense. No one proposes to make the args to SUBST be old first then new. I can live with whichever Guy decides to change (SUBST-IF or SUBSTITUTE-IF) as long as he makes them consistent. ---------- OK, I believe this. -------  Received: from CMU-CS-A by SU-AI with TCP/SMTP; 14 Jun 83 21:07:08 PDT Date: 15 Jun 83 0002 EDT (Wednesday) From: Guy.Steele@CMU-CS-A To: common-lisp@SU-AI Subject: Darn! "addition" => "edition". I was typing so fast I blew it, and still didn't get the message out until 00:01. Sigh. --Guy  Received: from CMU-CS-A by SU-AI with TCP/SMTP; 14 Jun 83 21:06:29 PDT Date: 15 Jun 83 0001 EDT (Wednesday) From: Guy.Steele@CMU-CS-A To: common-lisp@SU-AI Subject: BONG BONG BONG BONG BONG BONG BONG BONG BONG BONG BONG BONG The window for technical changes to the First Edition of the Common LISP Manual has been *closed*. Reports of typographical errors and inconsistencies will still be gratefully welcomed. Continued technical discussion will be accumulated toward the second addition. Thanks to everyone for their efforts! --Guy  Received: from MIT-MC by SU-AI with TCP/SMTP; 14 Jun 83 20:54:36 PDT Date: 14 Jun 1983 2336-EDT From: Bernard S. Greenberg Subject: Re: Happy Flag Day To: Fahlman%CMU-CS-C@SU-DSN cc: BSG%SCRC-TENEX%MIT-MC@SU-DSN, Common-Lisp@SU-AI In-Reply-To: The message of Tue, 14 Jun 1983 23:10 EDT from Scott E. Fahlman Return-path: Received: from MIT-MC by SCRC-TENEX with CHAOS; Tue 14-Jun-83 23:12:18-EDT Received: ID ; 14 Jun 83 23:10:55 EDT Date: Tue, 14 Jun 1983 23:10 EDT From: Scott E. Fahlman To: Bernard S. Greenberg Cc: Common-Lisp@su-ai Subject: Happy Flag Day In-reply-to: Msg of 14 Jun 1983 15:33-EDT from Bernard S. Greenberg Well, BSG may get the prize for the last change to go in. I'm not completely sure whether the SUBST or SUBSTITUTE format is right, but we can't leave them inconsistent. Looks to me like SUBST and friends need to change. -- Scott ----- Leave SUBST (historical reasons) and fix SUBSTITUTE &c. Make my macros much happier, and makes for a simpler rule:predicate arg is always FIRST. -------  Received: from MIT-MC by SU-AI with TCP/SMTP; 14 Jun 83 20:26:53 PDT Date: 14 June 1983 23:26 EDT From: Kent M. Pitman To: Fahlman @ CMU-CS-C cc: Common-Lisp @ SU-AI If by "SUBST and friends" you mean "SUBST's friends", I am amenable. I agree the current setup is not going to help users remember things easily and am in favor of making them either all "new old/pred tree/seq" or "new old tree/seq"/"pred new tree/seq", with a slight bias for the former because I think the argument of program flexibility in its favor slightly outweighs the argument of pronouncibility.  Received: from CMU-CS-C by SU-AI with TCP/SMTP; 14 Jun 83 20:11:08 PDT Received: ID ; 14 Jun 83 23:10:55 EDT Date: Tue, 14 Jun 1983 23:10 EDT From: Scott E. Fahlman To: Bernard S. Greenberg Cc: Common-Lisp@su-ai Subject: Happy Flag Day In-reply-to: Msg of 14 Jun 1983 15:33-EDT from Bernard S. Greenberg Well, BSG may get the prize for the last change to go in. I'm not completely sure whether the SUBST or SUBSTITUTE format is right, but we can't leave them inconsistent. Looks to me like SUBST and friends need to change. -- Scott  Received: from USC-ECL by SU-AI with TCP/SMTP; 14 Jun 83 14:49:18 PDT Received: from MIT-XX by USC-ECL; Tue 14 Jun 83 14:47:41-PDT Received: from SCRC-BEAGLE by SCRC-SPANIEL with CHAOS; Tue 14-Jun-83 15:33:31-EDT Date: Tuesday, 14 June 1983, 15:33-EDT From: Bernard S. Greenberg Subject: Happy Flag Day To: Common-Lisp%SU-AI at USC-ECL Re: Consistency of if/if-not's: I would like to quote the following excerpts from the laser manual: (p. 182) SUBST new old tree &key :test :test-not :key SUBST-IF predicate new tree &key :key SUBST-IF-NOT predicate new tree &key :key NSUBST new old tree &key :test :test-not :key NSUBST-IF predicate new tree &key :key NSUBST-IF-NOT predicate new tree &key :key (p. 166) SUBSTITUTE newitem olditem sequence &key :from-end ... SUBSTITUTE-IF newitem test sequence &key ... SUBSTITUTE-IF-NOT newitem test sequence &key ... NSUBSTITUTE newitem olditem sequence &key :from-end ... NSUBSTITUTE-IF newitem test sequence &key ... NSUBSTITUTE-IF-NOT newitem test sequence &key ... Either SUBSTITUTE-IF and his minions are consistent, as according to Steele and Moon, because the predicate replaces the "old" argument, but SUBST-IF and friends are inconsistent because of historical considerations, OR SUBST-IF and friends are consistent with all of the others (not shown here), because the predicate argument is first in all of them, and SUBSTITUTE-IF and friends are inconsistent because they are wrong.  Received: from by SU-AI with PUP; 14-Jun-83 06:06 PDT Received: From MIT-XX by SU-DSN.ARPA; Tue Jun 14 06:07:13 1983 Date: Monday, 13 June 1983, 14:38-PDT From: Marc LeBrun Subject: New built-in package Strikes Back. To: Fahlman at CMU-CS-C Cc: moon%scrc-tenex at mit-mc, Common-Lisp at su-ai In-reply-to: The message of 12 Jun 83 19:29-PDT from Scott E. Fahlman Date: Sun, 12 Jun 1983 22:29 EDT From: Scott E. Fahlman Date: Sunday, 12 June 1983 21:23-EDT From: MOON at SCRC-TENEX Well, that's what I get for listening to Fahlman! Keywords now print out as "||:foo". Fixed momentarily... I propose that henceforth all silly lisp code be interned in a package named "(-". Symbols in this package would print as \(-:foo. -- Scott The Common Lisp hack of making keywords evaluate to themselves is just an evil idea whose only purpose is to save typing one character. The package name string for keywords shouldn't be "" but "'". Keywords would look like ':foo just as now. Old souces are compatible, and it has precedent in Steele's ASET'. It creates some interesting issues for READ, but not insurmountable ones. (Every time I want to see Benson turn green as Yoda I tell him this.)  Received: from MIT-MC by SU-AI with TCP/SMTP; 13 Jun 83 06:24:17 PDT Received: from SCRC-BEAGLE by SCRC-TENEX with CHAOS; Mon 13-Jun-83 09:21:01-EDT Date: Monday, 13 June 1983, 09:21-EDT From: Bernard S. Greenberg Subject: Substitute-if To: MOON%SCRC-TENEX%MIT-MC@SU-DSN, Common-Lisp@su-ai In-reply-to: The message of 10 Jun 83 22:28-EDT from MOON at SCRC-TENEX Date: Friday, 10 June 1983 22:28-EDT From: MOON at SCRC-TENEX Date: Friday, 10 June 1983, 16:10-EDT From: Bernard S. Greenberg Before we cast the language in stone, I would like some resolution of why substitute-if/nsubstitute-if have argument orders incongruous with the rest of the if/if-not's. I don't actually see what's incongruous about it. In the Laser edition, all of the -if/-if-not functions replace the "item" argument with the "test" argument; in other words replace the object being searched for with the function to search for it. substitute-if doesn't have the test as its first argument, but then substitute doesn't have the item as its first argument either. OK, I see the grand scheme here. My observation of inconsistency was based upon the fact that substitute/nsubstitute/if/if-not do not have their predicate argument first. I will modify my macrology appropriately.  Received: from CMU-CS-A by SU-AI with TCP/SMTP; 12 Jun 83 20:53:44 PDT Date: 12 Jun 83 2346 EDT (Sunday) From: Guy.Steele@CMU-CS-A To: Richard E. Zippel Subject: Re: Rational and complex numbers CC: common-lisp@SU-AI In-Reply-To: "Richard E. Zippel's message of 12 Jun 83 16:36-EST" Your points are well-taken, and I'm glad they are in the record. Originally, I suppose that the S-1 LISP implementation (of which I one implementor) was the primary proponent of complex numbers in Common LISP, out of a desire to be able to exploit the S-1 hardware and yet also able to develop software in other implementations. Hence the need for at least Cartesian complex floating-point data type. I do foresee one entirely plausible application for Gaussian integers, which is graphics applications. For discrete bit-map representations, Gaussian integers may be a very convenient representation. Some interesting work has been done at Yale on picture languages that use complex numbers. I also admit once again to harboring the secret ambition for some form of LISP to supplant FORTRAN... --Guy  Received: from CMU-CS-C by SU-AI with TCP/SMTP; 12 Jun 83 19:31:44 PDT Received: ID ; 12 Jun 83 22:29:50 EDT Date: Sun, 12 Jun 1983 22:29 EDT From: Scott E. Fahlman To: moon%scrc-tenex@mit-mc Cc: Common-Lisp@su-ai Subject: New built-in package In-reply-to: Msg of 12 Jun 1983 21:23-EDT from MOON at SCRC-TENEX Date: Sunday, 12 June 1983 21:23-EDT From: MOON at SCRC-TENEX To: Common-Lisp-jokes Received: from MIT-MC by CMU-CS-C (with SMTP); 12 Jun 83 21:23:00 EDT Well, that's what I get for listening to Fahlman! Keywords now print out as "||:foo". Fixed momentarily... I propose that henceforth all silly lisp code be interned in a package named "(-". Symbols in this package would print as \(-:foo. -- Scott  Received: from MIT-MC by SU-AI with TCP/SMTP; 12 Jun 83 19:05:36 PDT Date: 12 June 1983 21:22 EDT From: Richard E. Zippel Subject: Rational and complex numbers To: MOON @ SCRC-TENEX cc: common-lisp @ SU-AI In-reply-to: Msg of 12 Jun 1983 19:54-EDT from MOON at SCRC-TENEX Date: Sunday, 12 June 1983 19:54-EDT From: MOON at SCRC-TENEX To: Richard E. Zippel cc: common-lisp at SU-AI Re: Rational and complex numbers Is there really more than one reasonable injection of Z into Q? Any map that sends 1 to an element of Q (other than 0) and all the elements accordingly is reasonable. Basically, any time you are counting things by halves, thirds, fourths or some other fraction you are presuming a different injection. (otherwise known as scaling) It might be nice to be able to have integers with these scaling factors built in. (multiples of pi or pi/4 might be nice for trig calculations. Certainly radians would be a more palatable measure of angles if the scaling factor of pi were built in. acos(0) would be 1/2(radians). When converted to floating point (the reals) it would of course give 1.57 ...) Why should these conversions be any different from the standard one? (The answer is: because it is more common) I'm not suggesting that the natural coercion from Z to Q be thrown away as much as suggesting that there is a lot more power and flexibility lurking thee than w currently acknowledge.  Received: from MIT-MC by SU-AI with TCP/SMTP; 12 Jun 83 16:56:24 PDT Date: Sunday, 12 June 1983 19:54-EDT From: MOON at SCRC-TENEX To: Richard E. Zippel Cc: common-lisp at SU-AI Subject: Rational and complex numbers In-reply-to: The message of 12 Jun 1983 17:36 EDT from Richard E. Zippel Is there really more than one reasonable injection of Z into Q?  Received: from MIT-ML by SU-AI with TCP/SMTP; 12 Jun 83 16:22:41 PDT Date: 12 June 1983 19:22 EDT From: Glenn S. Burke Subject: EQL and byte specifiers To: MOON @ SCRC-TENEX cc: Common-Lisp @ SU-AI, Fahlman @ CMU-CS-C, ALAN @ MIT-MC EQL doesn't always work on them in NIL. (There are two formats.) I could change this if necessary.  Received: from MIT-MC by SU-AI with TCP/SMTP; 12 Jun 83 15:01:32 PDT Date: 12 June 1983 17:36 EDT From: Richard E. Zippel Subject: Rational and complex numbers To: common-lisp @ SU-AI This message is not intended to change any of the decisions that have been made in common lisp but to place into the record some comments on numbers that I hope will prove useful next time. The thrust of these comments are that the addition of these new data types to common lisp is premature---we still don't understand the issues of coercion and type extension well enough to define these particular types. What are the types trying to represent? One of the reasons that bignums are so important in Lisp that it allows us to deal with a mathematically reasonable and well defined domain, namely the rational integers as opposed to an ad hoc set of quantities: the bit patterns that fit into a word. In defining new data types for Lisp it should be clear what mathematical domain we are trying to represent with the new type. Floating point numbers are an attempt to represent the real numbers, but of course they are not a particulary good representation. IEEE arithmetic, with gradual underflow is better (quantities larger than the exponent range can be represented by infinities, and small numbers gradually lose precision as they get closer to 0), but a bigfloat representation (with bignum exponents) provides an even better model of the reals. Common Lisp rational numbers are an attempt to model the quotient field of the rational integers: Q. All elements of Q have distinct representations as common lisp rational numbers which is good. Now what does 1 mean? Is it an element of Z or Q? Here the problem is that we aren't sure, it depends on what else it is combined with. We are trying to make 1 serve double duty as multiplicative identity of both Z and Q, two very distinct rings. Of course there are injections of Z into Q, and even a canonical one which we can use when we accidentally combine an element of Z with one of Q, but there cases when other injections are more appropriate. It seems more natural to me, when writing programs, to make the coercion be more explicit. This is somewhat reminescent of the problems we once had when namelists and namestrings and pathnames could all be used interchangably. Considering the complex types, mixed complex seems a little silly from this point of view. Algebraically its not really a terribly interesting structure. Either you are trying to represent the complex numbers (C) or not. Mixing makes the internal coercions much more complicated and the resulting mathematical structures has almost as many peculiarities as fixnums. If you complexes are trying to represent C, then the two components should represent R as well as possible, integers, rational numbers and the like don't. The gaussian number (complexes with integers coefficients) are interesting, but why were they singled out? This is just one of a large number of different algebraic extensions of the integers. Numbers of the form a+b*sqrt(7) are just as useful as numbers of the form a+b*sqrt(-1). The same holds for complexes with rational coefficients. Of course, higher degree algebraic numbers are also reasonable candidates, as are polynomials and rational functions, matrices ... Fundamentally, my comment is that new data types have been introduced to common lisp, and we don't yet have a good model of what they are trying to represent and what the coercion mechanisms are to be between them. For those who don't know me, I am one of the people who helped develop Macsyma where we spent and are spending a great deal of time struggling with these very issues.  Received: from CMU-CS-C by SU-AI with TCP/SMTP; 12 Jun 83 14:06:12 PDT Received: ID ; 12 Jun 83 17:04:05 EDT Date: Sun, 12 Jun 1983 17:04 EDT From: Scott E. Fahlman To: Scott E. Fahlman Cc: Common-Lisp@SU-AI Subject: DEFCONSTANT and EQ In-reply-to: Msg of 12 Jun 1983 16:51-EDT from Scott E. Fahlman On second thought, I would like to withdraw point 3 of my earlier proposal, that byte-specifiers be slippery in the same sense that numbers are. In all of the cases that matter, the compiler can easily detect that the byte specifier is being consumed by the function that is using it; in all other cases, we can just refer to the special value in the usual EQ-preserving way. So we can get by with one less exceptional case here. Given this change, the only slippery objects are numbers (only the consed ones) and character objects in implementations where those are consed. These are precisely the objects that are treated differently by EQ and EQL. So what Common Lisp really guarantees is that (EQL X X) but not (EQ X X) in all cases. -- Scott  Received: from by SU-AI with PUP; 12-Jun-83 13:56 PDT Received: From CMU-CS-C by SU-DSN.ARPA; Sun Jun 12 13:57:39 1983 Received: ID ; 12 Jun 83 16:54:40 EDT Date: Sun, 12 Jun 1983 16:54 EDT From: Scott E. Fahlman To: Bernard S. Greenberg Cc: common-lisp%SU-AI@SU-DSN Subject: DEFCONSTANT and EQ In-reply-to: Msg of 12 Jun 1983 16:31-EDT from Bernard S. Greenberg What about "strings"? Can the compiler fail to preserve eqness of a defconstanted string? I think the answer is NO, the compiler cannot do replacemnt of constant strings in such a way as to destroy EQ-ness. If you allow this for strings, you pretty much have to allow it for every sequence, including lists, and we're back to symbol-macros again. -- Scott  Received: from CMU-CS-C by SU-AI with TCP/SMTP; 12 Jun 83 13:53:12 PDT Received: ID ; 12 Jun 83 16:51:06 EDT Date: Sun, 12 Jun 1983 16:51 EDT From: Scott E. Fahlman To: Common-Lisp@SU-AI Subject: DEFCONSTANT and EQ In-reply-to: Msg of 12 Jun 1983 16:45-EDT from MOON at SCRC-TENEX Oops, true. You can still count on EQL for numbers and characters. You probably should be able to count on EQUAL for byte specifiers, but not EQL. Maybe all you can count on for these is that every time you pass X to a function that takes byte-specifiers, it has the same effect. -- Scott  Received: from MIT-MC by SU-AI with TCP/SMTP; 12 Jun 83 13:46:34 PDT Date: Sunday, 12 June 1983 16:45-EDT From: MOON at SCRC-TENEX To: Scott E. Fahlman Cc: Alan Bawden , Common-Lisp at SU-AI Subject: DEFCONSTANT and EQ In-reply-to: The message of Sun 12 Jun 1983 16:15 EDT from Scott E. Fahlman Date: Sun, 12 Jun 1983 16:15 EDT From: Scott E. Fahlman All I am saying is that the description of EQ should contain a note that because of possible stack-allocation and other optimizations, implementations should not depend on (EQ X X) if the value of X is any kind of number, character object, or byte specifier, even though this might work most of the time in most implementations. They can depend on EQL. EQL doesn't work on byte specifiers in your implementation, if I remember correctly.  Received: from MIT-MC by SU-AI with TCP/SMTP; 12 Jun 83 13:36:20 PDT Date: 12 Jun 1983 1631-EDT From: Bernard S. Greenberg Subject: Re: DEFCONSTANT and EQ To: Fahlman%CMU-CS-C@SU-DSN cc: common-lisp@SU-AI In-Reply-To: The message of Sun, 12 Jun 1983 15:25 EDT from Scott E. Fahlman What about "strings"? Can the compiler fail to preserve eqness of a defconstanted string? -------  Received: from CMU-CS-C by SU-AI with TCP/SMTP; 12 Jun 83 13:17:33 PDT Received: ID ; 12 Jun 83 16:15:48 EDT Date: Sun, 12 Jun 1983 16:15 EDT From: Scott E. Fahlman To: Alan Bawden Cc: Common-Lisp@SU-AI Subject: DEFCONSTANT and EQ In-reply-to: Msg of 12 Jun 1983 16:06 EDT from Alan Bawden Well, I left those off the list because I assumed that they would be immediate in essentially every implementation, so the question is moot. However, this assumption might be unwarranted. We should probably say that numbers, character objects, and byte specifiers are all slippery in the same way. By the way, I am not proposing "slippery" as a new technical term here. No SLIPPERYP predicate. All I am saying is that the description of EQ should contain a note that because of possible stack-allocation and other optimizations, implementations should not depend on (EQ X X) if the value of X is any kind of number, character object, or byte specifier, even though this might work most of the time in most implementations. They can depend on EQL. -- Scott  Received: from MIT-MC by SU-AI with TCP/SMTP; 12 Jun 83 13:06:27 PDT Date: 12 June 1983 16:06 EDT From: Alan Bawden Subject: DEFCONSTANT and EQ To: Fahlman @ CMU-CS-C cc: Common-Lisp @ SU-AI In-reply-to: Msg of Sun 12 Jun 1983 15:25 EDT from Scott E. Fahlman Date: Sun, 12 Jun 1983 15:25 EDT From: Scott E. Fahlman 3. I would like to include byte-specifiers in this slippery class as well. Some implementations may choose to make these into numbers. In any event, these are things that you especially want to do replacement on. Is it conceivable that, in some implementation, character objects would be similarly slippery?  Received: from CMU-CS-C by SU-AI with TCP/SMTP; 12 Jun 83 12:27:39 PDT Received: ID ; 12 Jun 83 15:26:01 EDT Date: Sun, 12 Jun 1983 15:25 EDT From: Scott E. Fahlman To: common-lisp@su-ai Subject: DEFCONSTANT and EQ Well, nobody has expressed a strong opinion about the issue I raised, so let me make a proposal for what should appear in the manual. 1. DEFCONSTANT does not create a "symbol macro". Conceptually, it evaluates the init form at load time and sets the global special value of the variable to that value. It also causes this symbol to be CONSTANTP. The semantics of DEFCONSTANT differs from DEFVAR only in that you must supply an init and you are declaring to the compiler that the value of the variable will never be changed. The compiler can do whatever it wants to with that information, but it must preserve the variable-reference semantics. If the user violates this declaration, it it "is an error" and might cause bad things to happen, but it might not be signalled. 2. Numbers are particularly slippery items in Common Lisp. If you set X to a number, it is not necessarily the case that (EQ X X), though you can count on (EQL X X). This needs to be noted in the data type chapter, and also should be referred to under EQ and maybe under DEFCONSTANT. 3. I would like to include byte-specifiers in this slippery class as well. Some implementations may choose to make these into numbers. In any event, these are things that you especially want to do replacement on. 4. Given the above rules, if X is a constant defined by DEFCONSTANT, the compiler knows that it is safe to substitute the initial value V (quoted) for references to X if V is a number of any kind, a byte specifier, a symbol, or any kind of immediate object whose creation involves no consing. A more complex compiler might be able to substitute for other kinds of V if it can prove that the value is consumed locally in a way that does not depend on EQ-ness, and that it cannot escape the local environment to be EQ-tested elsewhere. 5. For now if you want the effect of symbol-macros, you have to do something like (defmacro x () '(a b c d e)) (print (x)) instead of (defconstant x '(a b c d e)) (print x) We may want to consider putting true symbol-macros into the next edition, but let's not worry about this now. They are convenient, but non-essential and somewhat confusing. -- Scott  Received: from MIT-MC by SU-AI with TCP/SMTP; 12 Jun 83 11:51:32 PDT Date: Sunday, 12 June 1983 14:47-EDT From: MOON at SCRC-TENEX To: Scott E. Fahlman Cc: common-lisp at su-ai, l170dd60 at cmu-cs-a Subject: EQ-preservation In-reply-to: The message of Sat 11 Jun 1983 18:05 EDT from Scott E. Fahlman Return-path: Received: from MIT-MC by SCRC-TENEX with CHAOS; Sat 11-Jun-83 18:10:31-EDT Received: from CMU-CS-C by SU-AI with TCP/SMTP; 11 Jun 83 15:05:13 PDT Received: ID ; 11 Jun 83 18:05:19 EDT Date: Sat, 11 Jun 1983 18:05 EDT From: Scott E. Fahlman To: David.Dill@CMU-CS-A (L170DD60) Cc: common-lisp@su-ai Subject: EQ-preservation In-reply-to: Msg of 11 Jun 1983 1416-EDT () from David.Dill at CMU-CS-A (L170DD60) The question is not whether two distinct numbers are EQ, but whether and in what conditions you can count on (EQ X X). If X has the semantics of a variable reference, then you can count on this, regardless of what is put in X. Not so in Maclisp, as I understand it. And maybe not so on the LM-2 in a certain weird case involving an interrupt between the two references to X (I forget whether or not it can happen). In both cases this only happens when X is a number of course. Does Common Lisp really undertake to guarantee (EQ X X) if the value of X is a number? The writeup on EQ in the Laser edition could be interpreted as either confirming or denying this. On an unrelated note, did you notice that someone sabotaged your mail header by putting backspaces into the "To Dill" line? I know I shouldn't throw stones, the header of this message I'm sending now is going to have a host you don't know about in it, because of Babyl.  Received: from CMU-CS-A by SU-AI with TCP/SMTP; 11 Jun 83 20:47:59 PDT Date: 11 June 1983 2309-EDT (Saturday) From: David.Dill@CMU-CS-A (L170DD60) To: common-lisp@su-ai Subject: EQness of numbers Message-Id: <11Jun83.230957.DD60@CMU-CS-A> I seem to have yielded to a personal prejudice against using EQ in common-lisp outside of implementation-level code (see flames of last year). The issue of whether two numbers with the same value are always EQ is indeed somewhat distinct from the issue of EQ preservation by DEFCONSTANT. Still, demanding EQL-equivalence but not EQ-equivalence provides the maximum preservation of identity while not screwing compiler optimizations. Using EQ on numbers (correctly) will probably be a relatively rare operation, which is not worth sacrificing generally applicable compiler optimizations for.  Received: from CMU-CS-C by SU-AI with TCP/SMTP; 11 Jun 83 15:05:13 PDT Received: ID ; 11 Jun 83 18:05:19 EDT Date: Sat, 11 Jun 1983 18:05 EDT From: Scott E. Fahlman To: David.Dill@CMU-CS-A (L170DD60) Cc: common-lisp@su-ai Subject: EQ-preservation In-reply-to: Msg of 11 Jun 1983 1416-EDT () from David.Dill at CMU-CS-A (L170DD60) The question is not whether two distinct numbers are EQ, but whether and in what conditions you can count on (EQ X X). If X has the semantics of a variable reference, then you can count on this, regardless of what is put in X. But if X could be expanded as a sort of macro into a constant value each time it is seen, then maybe (EQ X X) doesn't hold. -- Scott  Received: from CMU-CS-A by SU-AI with TCP/SMTP; 11 Jun 83 11:17:53 PDT Date: 11 June 1983 1416-EDT (Saturday) From: David.Dill@CMU-CS-A (L170DD60) To: common-lisp@su-ai Subject: EQ-preservation Message-Id: <11Jun83.141645.DD60@CMU-CS-A> We have this excellent predicate EQL that I thought was invented for just this purpose. DEFCONSTANT should be EQL-preserving. Anyone who counts on numbers being EQ is likely to lose when implementations have different thresholds of bignum-ness, or hacks like INUMs, anyway. -Dave  Received: from CMU-CS-C by SU-AI with TCP/SMTP; 11 Jun 83 05:27:13 PDT Received: ID ; 11 Jun 83 08:27:36 EDT Date: Sat, 11 Jun 1983 08:27 EDT From: Scott E. Fahlman To: Guy.Steele@CMU-CS-A Cc: common-lisp@SU-AI Subject: DEFCONSTANT In-reply-to: Msg of 9 Jun 1983 0100-EDT () from Guy.Steele at CMU-CS-A Guy, If people want to stay with the EQ preserving version of DEFCONSTANT, and not go to the macro-like definition, then maybe it would be good to note this business about numbers not staying EQ in a note attached to the DEFCONSTANT description. THat is one of the major places where this will come up. -- Scott  Received: from MIT-MC by SU-AI with TCP/SMTP; 10 Jun 83 19:29:12 PDT Date: Friday, 10 June 1983 22:28-EDT From: MOON at SCRC-TENEX to: Common-Lisp at su-ai Subject: Substitute-if In-reply-to: The message of 10 Jun 1983 16:10-EDT from Bernard S. Greenberg Date: Friday, 10 June 1983, 16:10-EDT From: Bernard S. Greenberg Subject: Substitute-if To: Common-Lisp%su-ai%SCRC-TENEX%MIT-MC@SU-DSN Before we cast the language in stone, I would like some resolution of why substitute-if/nsubstitute-if have argument orders incongruous with the rest of the if/if-not's. I don't actually see what's incongruous about it. In the Laser edition, all of the -if/-if-not functions replace the "item" argument with the "test" argument; in other words replace the object being searched for with the function to search for it. substitute-if doesn't have the test as its first argument, but then substitute doesn't have the item as its first argument either.  Received: from CMU-CS-A by SU-AI with TCP/SMTP; 10 Jun 83 18:54:51 PDT Date: 10 Jun 83 2153 EDT (Friday) From: Guy.Steele@CMU-CS-A To: Bernard S. Greenberg Subject: Re: Substitute-if CC: common-lisp@SU-AI In-Reply-To: "Bernard S. Greenberg's message of 10 Jun 83 15:10-EST" I don't see that the argument order of substitute-if is incongruous. Is your model that the TEST argument is alwaays the first one? My model is that the xxx-if argument order is identical to the xxx argument order except that the ITEM argument has been replaced by the one-argument predicate TEST. --Guy  Received: from MIT-MC by SU-AI with TCP/SMTP; 10 Jun 83 13:50:25 PDT Received: from SCRC-BEAGLE by SCRC-TENEX with CHAOS; Fri 10-Jun-83 16:10:10-EDT Date: Friday, 10 June 1983, 16:10-EDT From: Bernard S. Greenberg Subject: Substitute-if To: Common-Lisp%su-ai%SCRC-TENEX%MIT-MC@SU-DSN Before we cast the language in stone, I would like some resolution of why substitute-if/nsubstitute-if have argument orders incongruous with the rest of the if/if-not's.  Received: from CMU-CS-A by SU-AI with TCP/SMTP; 9 Jun 83 21:01:24 PDT Date: 9 June 1983 2400-EDT (Thursday) From: Guy.Steele@CMU-CS-A To: common-lisp@SU-AI Subject: New meaning for "Flag Day" The Great Mail Blizzard of '83 seems to have subsided, and the outstanding issues, nasty and otherwise, appear to be suitably dealt with. We have to choose a cutoff date, and now seems to be a good time. I propose to give yet another meaning to "Flag Day" (recall that, according to legend, it was on June 14, 1966, that Multics converted from old ASCII to new ASCII). If you have any outstanding problems or flames, please send those packets in by 23:59 on June 14, 1983. After that point I propose to terminate "elective" changes to the Common LISP manual. We will prepare a Dovered limited edition much like the previous ones (Laser, Colander, and Swiss Cheese) and send it out to all of you for the purpose of proofreading and implementation, but seek feedback only on typographical errors, outright errors or lies, and necessary improvements to the presentation. Technical discussion will no doubt continue, but should be considered after Flag Day as contributions toward the second edition or the Yellow Pages. I want to proceed as expeditiously as possible to publication. --Guy  Received: from MIT-MC by SU-AI with TCP/SMTP; 9 Jun 83 16:46:34 PDT Date: Thursday, 9 June 1983 19:44-EDT From: MOON at SCRC-TENEX To: common-lisp at su-ai Subject: Re: [Scott's message about EQ DEFCONSTANTs] Date: 9 June 1983 17:31 EDT From: Communications Satellite FAILED: common-lisp at SU-AI; Recipient name apparently rejected. Last reply was: {500 Syntax error in recipient specification.} Failed message follows: ------- Date: Thursday, 9 June 1983 16:18-EDT From: MOON at SCRC-TENEX To: Ron Cc: common-lisp at SU-AI Subject: Re: [Scott's message about EQ DEFCONSTANTs] In-reply-to: The message of 9 Jun 83 14:17:40 EDT from Ron Date: 9 Jun 83 14:17:40 EDT From: Ron DEFCONSTANT is defined in the manual to produce values that are EQUALP only. Not EQ. Not so. I assume you are referring to page 49 of the Laser edition. It says nothing about any relation between the values of different instances of open-coding of the variable by the compiler. What it does say is that if you evaluate the form (DEFCONSTANT var val) twice, it is an error unless the two values of val are EQUALP. But this misfeature has already been removed by a previous ballot.  Received: from RUTGERS by SU-AI with TCP/SMTP; 9 Jun 83 11:16:28 PDT Date: 9 Jun 83 14:17:40 EDT From: Ron Subject: Re: [Scott's message about EQ DEFCONSTANTs] To: Fahlman@CMU-CS-C.ARPA, common-lisp@SU-AI.ARPA In-Reply-To: Message from "Scott E. Fahlman " of 8 Jun 83 09:55:00 EDT DEFCONSTANT is defined in the manual to produce values that are EQUALP only. Not EQ. (ron) -------  Received: from CMU-CS-A by SU-AI with TCP/SMTP; 8 Jun 83 22:47:30 PDT Date: 9 June 1983 0100-EDT (Thursday) From: Guy.Steele@CMU-CS-A To: Scott E. Fahlman Subject: Re: DEFCONSTANT CC: common-lisp@SU-AI In-Reply-To: "Scott E. Fahlman's message of 8 Jun 83 08:55-EST" Regarding DEFCONSTANT and consed numbers, note that page 121 of the Laser edition notes that "numbers are not true objects", and cannot be relied upon to stay EQ. This is a special-case hack, of course, intended to allow NCOMPLR-type tricks. --Guy  Received: from USC-ECL by SU-AI with TCP/SMTP; 8 Jun 83 14:26:41 PDT Received: from MIT-MC by USC-ECL; Wed 8 Jun 83 14:24:23-PDT Received: from SCRC-BEAGLE by SCRC-TENEX with CHAOS; Wed 8-Jun-83 16:20:56-EDT Date: Wednesday, 8 June 1983, 16:19-EDT From: Bernard S. Greenberg Subject: UNDEFCONSTANT To: common-lisp%su-ai@usc-ecl The loading of a DEFCONSTANT changes the symbol being defined in a (so far) unalterable fashion. There ought to be an in-language way to revoke this effect.  Received: from MIT-ML by SU-AI with TCP/SMTP; 8 Jun 83 16:02:03 PDT Received: from SCRC-HOUSATONIC by SCRC-TENEX with CHAOS; Wed 8-Jun-83 19:00:19-EDT Date: Wednesday, 8 June 1983, 18:58-EDT From: Robert A. Cassels Subject: Loose ends To: Fahlman%CMU-CS-C@SU-DSN, common-lisp@su-ai In-reply-to: The message of 8 Jun 83 12:58-EDT from Scott E. Fahlman Date: Wed, 8 Jun 1983 12:58 EDT From: Scott E. Fahlman Just a couple of loose ends to tie up. I am swapping out for a few days and Guy may be in a position to finish up a draft of the manual before I return, so I would like to just propose a couple of things that will go in if nobody objects by the time he gets to them. I think that these proposals will be uncontroversial, but I've been wrong before on such issues. 1. FLOAT-SIGNIFICAND and FLOAT-INTEGER-SIGNIFICAND are now confusing names, given the change in semantics approved by the last ballot. I propose that these be called DECODE-FLOAT and INTEGER-DECODE-FLOAT, unless a better name is proposed within the next 24 hours or so. I propse that the determination of "better" will be done by Guy. 2. Whatever we call the functions listed above, it is proposed that they return a third value which is the sign of the number, in the format currently supplied by a one-arg call to FLOAT-SIGN. The rationale is similar to the rationale for combining the significand and the exponent: whenever you want any of these, you almost always want all of them. I suggest that we leave it up to Guy to decide whether, given this change, FLOAT-SIGN is useful enough to keep. There is probably still some use for the two-argument FLOAT-SIGN. I do agree that the functions in (1.) should return the sign as a third value. I guess I would like to amend slightly my proposal on FLOAT-DIGITS and FLOAT-PRECISION, to combine them into a single function returning two values, for reasons similar to those which led to combining FLOAT-SIGNIFICAND, etc. But I don't feel strongly about it or the names I proposed and am willing to leave it to Guy's judgement. (Guy -- you wondered why I wanted this information for printing. It's strictly for doing the thing suggested by the IEEE standard, where denormalized numbers are printed with leading zeros.)  Received: from MIT-ML by SU-AI with TCP/SMTP; 8 Jun 83 16:05:49 PDT Date: 8 June 1983 19:07 EDT From: Glenn S. Burke Subject: Loose ends To: Fahlman @ CMU-CS-C cc: common-lisp @ SU-AI Fine by me.  Received: from MIT-ML by SU-AI with TCP/SMTP; 8 Jun 83 18:09:20 PDT Date: 8 June 1983 21:11 EDT From: Glenn S. Burke Subject: defconstant, eval-when, etc. To: common-lisp @ SU-AI The one thing which needs to be clearly specified is how the semantics of "added to the compilation environment" differs from what might be done by (eval-when (compile) ...). If, for instance, defmacro does not bash the runtime environment, then the user will have to use eval-when if the macro needs to be usable via the interpreter during the compilation. Eval-when should do exactly that: evaluate and bash the runtime environment. Always, without exception, no matter what "added to the compilation environment" might mean. My own experience is that it is generally a loss for "added to the compilation environment" to bash the runtime environment. Extracting necessary declarative information from files in order to do multi-file compilation carefully is not actually that difficult, and we have some tools for doing this. (I bring this up because i was just shafted by this in a very big way bootstrapping LSB up in a lisp implementation which shall remain nameless. Unfortunately the bootstrap procedure cannot use LSB itself.)  Received: from MIT-MC by SU-AI with TCP/SMTP; 8 Jun 83 12:35:18 PDT Received: from SCRC-BEAGLE by SCRC-TENEX with CHAOS; Wed 8-Jun-83 14:47:26-EDT Date: Wednesday, 8 June 1983, 14:46-EDT From: Bernard S. Greenberg Subject: Re: DEFCONSTANT To: Guy.Steele%CMU-CS-A@SU-DSN Cc: common-lisp@SU-AI In-reply-to: The message of 8 Jun 83 01:46-EDT from Guy.Steele at CMU-CS-A Date: 8 June 1983 0146-EDT (Wednesday) From: Guy.Steele@CMU-CS-A The initial-value form to DEFCONSTANT is conceptually evaluated at load time. DEFCONSTANT is an invitation to the compiler to susbtitute the value for occurrences of the constant *if* the compiler is smart enough to do so. DEFCONSTANT is not meant to side-effect the compiler's environment. (DEFCONSTANT FOO 3) (DEFCONSTANT BAR (+ FOO 6)) entitles the compiler to use the value 9 for BAR provided that it is smart enough to analyze what it going on (actually notall that hard: the first declaration entitles the compiler to substitute 3 for FOO, whereupon some simple constant folding reduces (+ 3 6) to 9). --Guy Ingenious! This seems to be the best of all possible worlds (I admit candidly). Although I think, as per previous letters, the issue needs some definitional and documentation-wise sorting out, this does seem to solve all problems. The answer to "What kind of evaluator or meta- evaluator should be invoked on the second operand of DEFCONSTANT?" is "the compiler's pass-1 optimizer/reducer"! That is not something we do now, but there is no good reason why not.  Received: from MIT-MC by SU-AI with TCP/SMTP; 8 Jun 83 12:13:47 PDT Date: Wednesday, 8 June 1983 14:02-EDT From: MOON at SCRC-TENEX to: common-lisp at su-ai Subject: Loose ends In-reply-to: The message of Wed 8 Jun 1983 12:58 EDT from Scott E. Fahlman This is all okay with me.  Received: from MIT-MC by SU-AI with TCP/SMTP; 8 Jun 83 11:42:22 PDT Received: from SCRC-BEAGLE by SCRC-TENEX with CHAOS; Wed 8-Jun-83 14:13:01-EDT Date: Wednesday, 8 June 1983, 14:11-EDT From: Bernard S. Greenberg Subject: DEFCONSTANT To: Walter.VanRoggen%CMU-CS-A@SU-DSN, common-lisp@su-ai In-reply-to: <08Jun83.115058.WV50@CMU-CS-A> Date: 8 June 1983 1147-EDT (Wednesday) From: Walter van Roggen (C410WV50) Indeed, I have occasionally had problems with the compiler environment getting altered undesirably; DEFMACRO has the same effects you describe. Unlike what you say in (2), I believe that macros do get put into the compiler's environment. So the potential problems with DEFCONSTANT as I saw them are no different. In any case, I had hoped packages would help avoid confusion when compiling the compiler or the lisp system. Indeed. The Lisp Machine's compiler DOES NOT evaluate macro definitions at compile time, but effectively remembers them as local declarations, local to the file being compiled. They are saved in a place where MACROEXPAND knows how to find them. So on the Lisp Machine, the non-existent sins of DEFMACRO are not an excuse for similar behavior by DEFCONSTANT. Liber Laserum says only "the macro is added to the compilation environment", which is noncommital. The direct parent of Lisp Machine Lisp, MacLisp, indeed solved these problems via packages. Programs being compiled were compiled in a package (one of two) where none of the compiler's internal symbols were accessible. You could compile incompatible compilers with all the eval-when's you wanted, without any fear of breaking the compiler. The Lisp Machine (and Common Lisp) package systems, although far more general, do not enjoy this feature. This is the reason at the root of why we don't eval-when(compile) macros. eval-when(compile) is not an object for trepidation in an environment where the program being compiled lives in its own namespace, or in a batch compilation environment (the compiler is a separate program that you invoke from operating system command level), which is effectively the same thing. Even the Lisp Machine has two paradigms of compilation that are diametrically opposed on the issue of compilation side effects. When we compile files, we do so in such a way as to minimize side effect. When we compile editor buffers or pieces of editor buffers, we do so in such a way as to maximize side effect. Specifically, we "load" each top-level form immediately after we have compiled it. In this latter scenario, ALL of my supposedly problematic DEFCONSTANT examples do the "right thing". I tend to agree with KMP that the language spec needs work in the area of compile/load interactions, compilation environment mungs, etc. I think the language should either define behavior precisely or state what freedom of choice is open to the implementation. Defining precise behavior might mean that somebody has to turn their implementation inside out, while permitting enough freedom so that nobody has to turn their implementation inside out might, for instance, make DEFCONSTANT unspecifiable and/or unimplementable.  Received: from CMU-CS-C by SU-AI with TCP/SMTP; 8 Jun 83 09:58:08 PDT Received: ID ; 8 Jun 83 12:58:35 EDT Date: Wed, 8 Jun 1983 12:58 EDT From: Scott E. Fahlman To: common-lisp@su-ai Subject: Loose ends Just a couple of loose ends to tie up. I am swapping out for a few days and Guy may be in a position to finish up a draft of the manual before I return, so I would like to just propose a couple of things that will go in if nobody objects by the time he gets to them. I think that these proposals will be uncontroversial, but I've been wrong before on such issues. 1. FLOAT-SIGNIFICAND and FLOAT-INTEGER-SIGNIFICAND are now confusing names, given the change in semantics approved by the last ballot. I propose that these be called DECODE-FLOAT and INTEGER-DECODE-FLOAT, unless a better name is proposed within the next 24 hours or so. I propse that the determination of "better" will be done by Guy. 2. Whatever we call the functions listed above, it is proposed that they return a third value which is the sign of the number, in the format currently supplied by a one-arg call to FLOAT-SIGN. The rationale is similar to the rationale for combining the significand and the exponent: whenever you want any of these, you almost always want all of them. I suggest that we leave it up to Guy to decide whether, given this change, FLOAT-SIGN is useful enough to keep. 3. People have aksed for a clarification of the RECURSIVEP argument (I guess given the hyphen rules, this should not be RECURSIVE-P after all) to read and friends. The following items are affected: a. Top-level calls rebind the ## environment; recursive calls don't. b. Top-level calls establish the preserve-whitespace flag; recursive calls observe this but don't change it. c. Top-level calls establish the action to be taken if end-of-file is read. I have no objection to Moon's suggestion that an error in a recursive read, if it is in the middle of an object, always signals an "eof in middle of object" error. I am not sure whether a recursive call would ever have to handle an eof that would not want to cause such an error, but if so, the top-level eof switches should control the action. A bit more thought is needed here to decide just how to state this. d. In some implementations, a great deal of efficiency can be gained by checking certain things at top-level and not at every recursive call. (An example is pre-processing the stream into something lower-level for use within the call.) The RECURSIVEP argument provides some necessary information for such decisions. It would of course be possible to eliminate the RECURSIVEP argument and to do the same thing with a special variable -- this is true of every argument to every Lisp function. If we do that, we would have to document this variable so that error handlers and character macros that want to establish a new top-level dialogue can rebind it to its top-level value. (That would be a rare occurrence, but one that we ought to allow for.) We could have gone this way, but the necessary machinery is nearly identical, so I see no reason to re-open the argument. Let's stick with the RECURSIVEP argument.  Received: from CMU-CS-A by SU-AI with TCP/SMTP; 8 Jun 83 09:49:59 PDT Date: 8 June 1983 1150-EDT (Wednesday) From: Walter van Roggen (C410WV50) To: common-lisp@su-ai Message-Id: <08Jun83.115058.WV50@CMU-CS-A> - - - - Begin forwarded message - - - - Date: 8 June 1983 1147-EDT (Wednesday) From: Walter van Roggen (C410WV50) To: David A. Moon Subject: Re: DEFCONSTANT In-Reply-To: "David A. Moon's message of 7 Jun 83 21:16-EST" Message-Id: <08Jun83.114703.WV50@CMU-CS-A> Indeed, I have occasionally had problems with the compiler environment getting altered undesirably; DEFMACRO has the same effects you describe. Unlike what you say in (2), I believe that macros do get put into the compiler's environment. So the potential problems with DEFCONSTANT as I saw them are no different. In any case, I had hoped packages would help avoid confusion when compiling the compiler or the lisp system. But apparently the intent of DEFCONSTANT (according to Guy) is different from all 4 options you list: it's like DEFPARAMETER with an implicit declaration saying "if you can figure out what the value is without changing the semantics (i.e., not copying), go ahead and use it, else use the load-time value (which should be the same as just referring to the special value, since it's constant)". I'm happy with that definition. I just thought the one that corresponds to DEFMACRO is also very useful and deserves its own name;. ---Walter - - - - End forwarded message - - - -  Received: from CMU-CS-C by SU-AI with TCP/SMTP; 8 Jun 83 07:55:51 PDT Received: ID ; 8 Jun 83 09:55:02 EDT Date: Wed, 8 Jun 1983 09:55 EDT From: Scott E. Fahlman To: common-lisp@su-ai Subject: DEFCONSTANT A key question concerning DEFCONSTANT is whether two uses of the same constant must produce values that are EQ. Consider the following silly code fragment: (defconstant foo '(rabid wombat)) (defun bar () foo) (defun bletch () foo) (defun urgh () (eq (bar) (bletch))) Compile this and call URGH. If DEFCONSTANT has to work EXACTLY like load-time SETQ, then URGH is guaranteed to return T. This is the intuitive thing. However, if we require this, then it would take a very wily compiler indeed to ever do any compile-time substitution. Even if the URGH function were not present in the compiled file, the user could come along and write it at runtime. References that get consumed within a compiled function and not passed on out of it would be OK, but this is a new class of things to worry about. Adding something to a constant consumes it, but consing it into a list does not -- someone could still check for EQ on the constituent. Under these rules, our compiler would substitute for constant fixnum values, characters, symbols, and nothing else. The key question is whether the init form does any consing without "consuming" the result; we would just be lazy and panic at the first sight of a cons or unknown form. (We'd probably try to find a loophole by which we could include byte specifiers, but this is tricky since we use CONSes for them right now.) Note that if we replace '(rabid wombat) with 3.1415L0, in an implementation where this number is consed, we cannot do the substitution either, as long as URGH is supposed to return T. The above "intuitive" rules allow up about 90% of the places where you'd really like compile-time substitution -- fixnums are by far the most important case -- but leaves out constant lists, simple strings, and consed numbers. These could still appear in DEFCONSTANT, but you'd have to do a special-variable reference to get at them. We could instead state in the manual that two references to a constant symbol are not guaranteed to be EQ, and if you want EQ values you should use DEFVAR or DEFPARAMETER. This could be explained as a sort of macro: references to the symbol in compiled code are replaced (or can be replaced) with the init form, quoted. The init form is also evaluated at load time and the constant is bound to the result, so special-variable references to it at runtime work properly. I slightly favor the latter approach, since it greatly increases the utility of DEFCONSTANT and allows for all sorts of optimizations to occur. However, it is non-intuitive for the average user. I could go either way on this. I think that some of the implications for program verifiers and the like could be pretty deep -- referential transparency and all of that. Opinions? -- Scott  Received: from MIT-MC by SU-AI with TCP/SMTP; 7 Jun 83 23:45:13 PDT Date: 8 June 1983 02:47 EDT From: Kent M. Pitman Subject: DEFCONSTANT, etc To: Common-Lisp @ SU-AI Please note that (shudder) even though the value of the constant of FOO in (DEFCONSTANT FOO val) is not accessible except during compilation, any side effects done during the computation of val, eg, (DEFCONSTANT FOO (PUTPROP 'BAR '(BAZ) 'SOME-PROP)) will be available if the decision is made to do compile-time evaluation, so the problem on the LispM of side-effecting the runtime environment is a real one. I am still bothered that on the LispM, the compiler does a side-effect to my compile-time environment when it sees DEFSETF, for example. The issue of separation of runtime and compile time environments is a big one and I would suggest that there is probably a more orderly way of proceeding in this discussion rather than poking at the details of DEFSETF. Maybe we could make this discussion more general and talk first about what the effect of a compilation is on the compilation time environment. Also, one of the choices on Moon's (I think) list of 4 options of what to do with DEFCONSTANT said "DEFCONSTANTs are executed at compile time, but the values are restored after the compilation completes." I'm surprised he posed this; maybe he doesn't believe it, or maybe he has a better theory of this than I do, but in an environment as on the LispM where incremental compilation is possible, the idea of a compilation being "complete" and of persistence of assumptions is muddied considerably. In any case, if Common Lisp took a definite stand on generalizations about how the compiler and interpreter relate to one another, it would probably be easier to answer questions like the one about DEFCONSTANT. Also, it would be easier to think about DEFCONSTANT if someone posed some real examples of where they would want to use it. What its semantics should be is intimately tied to how it is suggested it be used. I find it hard to think usefully about scenarios of what (DEFCONSTANT FOO 3) should mean. --kmp  Received: from CMU-CS-A by SU-AI with TCP/SMTP; 7 Jun 83 22:50:24 PDT Date: 8 June 1983 0146-EDT (Wednesday) From: Guy.Steele@CMU-CS-A To: Bernard S. Greenberg Subject: Re: DEFCONSTANT CC: common-lisp@SU-AI In-Reply-To: "Bernard S. Greenberg's message of 7 Jun 83 12:21-EST" The initial-value form to DEFCONSTANT is conceptually evaluated at load time. DEFCONSTANT is an invitation to the compiler to susbtitute the value for occurrences of the constant *if* the compiler is smart enough to do so. DEFCONSTANT is not meant to side-effect the compiler's environment. (DEFCONSTANT FOO 3) (DEFCONSTANT BAR (+ FOO 6)) entitles the compiler to use the value 9 for BAR provided that it is smart enough to analyze what it going on (actually notall that hard: the first declaration entitles the compiler to substitute 3 for FOO, whereupon some simple constant folding reduces (+ 3 6) to 9). --Guy  Received: from CMU-CS-C by SU-AI with TCP/SMTP; 7 Jun 83 22:40:57 PDT Received: ID ; 8 Jun 83 01:40:40 EDT Date: Wed, 8 Jun 1983 01:40 EDT From: Scott E. Fahlman To: David A. Moon Cc: common-lisp@su-ai Subject: DEFCONSTANT In-reply-to: Msg of 7 Jun 1983 22:16-EDT from David A. Moon I guess I hadn't realized that there was a problem here. In Spice we will probably spawn a second Lisp process whenever we want to compile a file, though compilation of individual functions may be done within the Lisp where we live. The latter operation tends not to hit DEFCONSTANTs. I see no compelling reason why DEFCONSTANT values have to be available to EVAL during a compilation, as long as we carefully document that. As you say, if some such value must be available to a macro-expander function, the user can put it in an explicit EVAL-WHEN COMPILE and take his lumps. We might discover that the EVAL-WHEN form gets used so often that we want to make it a standard macro with a different name, but I bet it won't. Note also that if a DEFCONSTANT contains something that the compiler can't figure out at compile time, the compiler can just decline to open-code references to this constant and can code the reference as a normal special. The variable will get its value at load-time and everythign will work correctly, though perhaps more slowly than the user expected. Just how clever the compiler has to be is something that we should leave up to the implementor. We do not want the white pages to say that certain things must be open-coded. Even a quoted constant might not want to be open-coded if it is a huge list and the user has asked the compiler to optimize for size. I think this is Moon's option 2, though it might be 4 -- I'm not sure I grasp the difference. I could live with 1 (go ahead and clobber the variable), since we don't compile where we live anyway. Option 3, binding and unbinding the things a compilation might zap, strikes me as too hard to implement. -- Scott  Received: from MIT-MC by SU-AI with TCP/SMTP; 7 Jun 83 19:34:36 PDT Received: from SCRC-EUPHRATES by SCRC-TENEX with CHAOS; Tue 7-Jun-83 22:26:18-EDT Date: Tuesday, 7 June 1983, 22:16-EDT From: David A. Moon Subject: Re: DEFCONSTANT To: Walter van Roggen Cc: common-lisp@su-ai In-reply-to: <07Jun83.182018.WV50@CMU-CS-A> Date: 7 June 1983 1820-EDT (Tuesday) From: Walter van Roggen (C410WV50) My idea of how DEFCONSTANT should work is similar to how DEFMACRO works. Each DEFCONSTANT has an implied EVAL-WHEN (COMPILE LOAD EVAL) around it. The issue here is that if you do that the value of the variable (constant) gets changed in the Lisp in which you are running the compiler. This certainly has to be documented, and could be a serious problem if you are changing the value of a constant; suppose that the constant is something that is needed in order to run the compiler or the reader or some other low-level part of the Lisp system. For a concrete example, let's say that it's the value of some field in the readtable that means "open parenthesis." The only thing that is likely to save you is if all references to the constant were actually open-coded, and no important code is being run interpreted. Those of you on the list who use cross-compilers, rather than compiling in the Lisp environment in which you actually do your work, may not yet appreciate all the ways you can get into trouble by having the act of compiling a file (without loading it) change things in your Lisp world. The choices I see are (in no particular order): (1) DEFCONSTANT has an implied EVAL-WHEN (COMPILE LOAD EVAL) around it and hence compiling anything with a DEFCONSTANT in it is just like loading it. (2) A special constant-values table is set up by DEFCONSTANT and used by the compiler in certain contexts that have to be carefully documented. The important thing is that these constant values are not seen by the interpreter and not seen by SYMBOL-VALUE. This is very similar to the way the compiler treats macros, where MACROEXPAND searches the special table of macros that have been seen during the compilation, but EVAL doesn't. (3) DEFCONSTANTs are executed at compile time, but the values are restored after the compilation completes (perhaps a dynamic binding is created by the compiler when it sees a DEFCONSTANT, and the rest of the compilation runs inside of that binding.) (4) It is illegal to use a DEFCONSTANT in any but certain restricted contexts, i.e. compiling references to it. If you want it to be available to the interpreter during compilation, you must explicitly put in an EVAL-WHEN and face the consequences to the environment in which you are running the compiler. This is very similar to the way the compiler treats defuns.  Received: from CMU-CS-A by SU-AI with TCP/SMTP; 7 Jun 83 15:27:48 PDT Date: 7 June 1983 1820-EDT (Tuesday) From: Walter van Roggen (C410WV50) To: Bernard S. Greenberg Subject: Re: DEFCONSTANT CC: common-lisp@su-ai In-Reply-To: "Bernard S. Greenberg's message of 7 Jun 83 12:21-EST" Message-Id: <07Jun83.182018.WV50@CMU-CS-A> My idea of how DEFCONSTANT should work is similar to how DEFMACRO works. Each DEFCONSTANT has an implied EVAL-WHEN (COMPILE LOAD EVAL) around it. For most simple constants, yes, this is like DEFPARAMETER. But we definitely want to be able to have compile time constants available for the compiler to optimize on. That means we have to give up some sharing. For example, (defconstant eof-marker '(eof-marker)) (defun foo () eof-marker) (defun bar () eof-marker) and now (EQ (FOO) (BAR)) is not necessarily true. I think this is why we had to rename DEFCONST to DEFCONSTANT. I guess some examples in the manual would help. ---Walter  Received: from CMU-CS-C by SU-AI with TCP/SMTP; 7 Jun 83 09:13:10 PDT Received: ID ; 7 Jun 83 12:11:47 EDT Date: Tue, 7 Jun 1983 12:11 EDT From: Scott E. Fahlman To: George J. Carrette Cc: Common-Lisp@SU-AI In-reply-to: Msg of 7 Jun 1983 02:03 EDT from George J. Carrette You ask about the advantages of requiring complex numbers to be homogeneous in type. You calim that the cost of making this move is (1) More documentation to read. (2) More runtime checking when making complex numbers. (3) Reduction in possible objects to manipulate. Now, being a mere Lisp hacker and less mathematical than most, I cannot claim to understand these things, but let me take a stab at listing the advantages anyway: (1) Less and simpler documentation to read. Mixed types lead to complexity in the declaration system, at least. Also, I believe that users would find mixed-type complexes confusing -- I do. (2) Possibly greater runtime efficiency. Whenever you operate on a mixed-type complex (except for addition and subtraction), you have to do type-contagion at that point. With this restriction, implementations have the option to do the contagion once, when the number is created. (3) Reduction in possible objects to manipulate. With only the useful complex types around, and not ones that turn into homogeneous types when you use them but have to be kept in their original form otherwise, the few remaining types can receive more of the implementor's attention in the area of making them efficient. -- Scott  Received: from USC-ECL by SU-AI with TCP/SMTP; 7 Jun 83 07:23:18 PDT Received: from MIT-MC by USC-ECL; Tue 7 Jun 83 07:25:25-PDT Received: from SCRC-BEAGLE by SCRC-TENEX with CHAOS; Tue 7-Jun-83 10:09:52-EDT Date: Tuesday, 7 June 1983, 10:09-EDT From: Bernard S. Greenberg Subject: Pathname Conventions To: Common-Lisp%SU-AI@USC-ECL While all of Moon's observations on this subject are correct and reflect our experience, I nevertheless think it would be quite unwise to nail down the host/pathname-parsing relationship into the standard at this time. The corresponding set of features in the Lisp Machine system at this time is the subject of an ongoing debate, and in my mind, no proposed solution to the problems involved has overriding merit. In general, I feel queasy about the specification of the pathname system being in the spec at all. I think it is premature.  Received: from CMU-CS-C by SU-AI with TCP/SMTP; 7 Jun 83 12:10:31 PDT Received: ID ; 7 Jun 83 15:06:54 EDT Date: Tue, 7 Jun 1983 15:06 EDT From: Scott E. Fahlman To: common-lisp@su-ai Subject: Testing The mail giving the results of Ballot-B seems to be slow in making it through SU-AI. This is a test to see if that pathway is down, sluggish, or OK.  Received: from CMU-CS-C by SU-AI with TCP/SMTP; 7 Jun 83 10:56:20 PDT Received: ID ; 7 Jun 83 13:55:41 EDT Date: Tue, 7 Jun 1983 13:55 EDT From: Scott E. Fahlman To: common-lisp@su-ai Subject: Results of ballot B Results of Ballot B: --------------------------------------------------------------------------- B1. Proposed that we require both halves of a complex number to be of the same type, either both rationals or both floats of the same type: APPROVED. --------------------------------------------------------------------------- B2. Return a complex number from functions like (sqrt -1), where we would otherwise have to signal an error: APPROVED. Implementations are free to invent real-value-only functions or a *REAL-VALUES-ONLY* switch if they so choose. --------------------------------------------------------------------------- B3. MULTIPLE-VALUE-SETQ must take argument pairs like SETQ does: REJECTED. --------------------------------------------------------------------------- B4a. Remove FLOAT-EXPONENT and FLOAT-INTEGER-EXPONENT, and return those numbers as the second values from FLOAT-SIGNIFICAND and FLOAT-INTEGER-SIGNIFICAND: APPROVED. Now we need a new name for this. The best that Moon and I have been able to come up with is DECODE-FLONUM. PARSE-FLONUM says the right thing, but is very confusing. Any other suggestions? I will send out a mini-ballot on this and on whether this function should return the sign as a third value, flushing FLOAT-SIGN. B4b. Add new functions FLOAT-DIGITS and FLOAT-PRECISION: APPROVED. B4c. Require the result of FLOAT-INTEGER-SIGNIFICAND to reflect the precision of the floating-point number: APPROVED. --------------------------------------------------------------------------- B5. Add optional RECURSIVE-P argument to READ and friends: APPROVED. There was some discussion of exactly what the error action should be in recursive reads. I'll send out a proposal on this shortly. --------------------------------------------------------------------------- B6. Rename MERGE-PATHNAME-DEFAULTS to MERGE-PATHNAMES and eliminate the default-type argument: APPROVED. --------------------------------------------------------------------------- B7. Propose that we add a new slot, CONVENTION, to the pathname structure, and an optional CONVENTION argument to the PATHNAME and TRUENAME functions: withdrawn by the proposer (me). After considering Moon's arguments and some comments by Hedrick and Burke, I no longer believe this to be a good idea, at least in anything like the form proposed. Long-winded explanation: First, I am willing to accept that each known host follows exactly one file-naming convention. (The manual needs to claify that "host" names a file system, not a CPU.) Given a host, the convention can easily be found by a simple lookup in a site-specific table. So the argument that a convention slot in the pathname tells you how to print it, modify it, etc., is just an efficiency hack. Second, we must ask if there is a set of interesting cases where the convention is known but the host is not. One can imagine such cases -- "I don't know what CMU-WOMBAT is, but this sure looks like a unix namestring" -- but I can't think of any real context in which such partial information would be both available and useful. As Moon points out, there are not many cases in which the user would prefer to supply the namestring convention explicitly. Finally, there is the question of clarity. The real reason I favored this is that it seemed to me that the parsing of a file-name had two distinct phases, and it would make things much clearer if we separated them. First, the implementation must dive in and extract a host name from the namestring, and from that host name determine the convention. Exactly how that host-name extraction works is implementation-dependent, and will certainly change over time at most sites. It is a function of the set of conventions that an implementation is prepared to recognize. Some might just scan for anything before a "::", while others might also look for [foo] or see if there is something like "foo:" where "foo" is in the table of recognized hosts. Given the host, one can then do the site-dependent table lookup to determine the convention in effect. THEN one would parse the namestring using this convention argument as a guide. This parsing operation would be implementation-independent, given that na implementation wants to provide for a given convention: we would only need one unix-namestring parser, one ITS namestring parser, etc. So I was drawn to the separate convention machinery mostly by the increased clarity of such an account over the current description. What I now realize, however, is that if we want to make this boundary between the two phases of namestring parsing visible to the user, we have to standardize it. We have to provide a DETERMINE-CONVENTION function for namestrings and specify all of the things that it might or must return. We have to do this in such a way that we do not rule out extensions which would make use of a hierarchical organization of conventions or of partially-sepecified or ambiguous conventions. To do this in a standard way is a task that we could not possibly complete in time for the current manual, and it may not be a good idea in any event. Most namestring parsers will have this two-layered structure, but the potential variability of the interface between those layers is so great that we probably want to let that be an issue between each implementation and itself, at least for now. So, unless there are objections, I propose that we forget about the proposed convention argument to PATHNAME and TRUENAME, and that the CONVENTION argument to PARSE-NAMESTRING should be specified to take a known host-name: if this is supplied, the parsing will conform to the conventions of that host. I think that gives us a sufficient escape hatch for odd cases.  Received: from USC-ECL by SU-AI with TCP/SMTP; 7 Jun 83 10:22:39 PDT Received: from MIT-MC by USC-ECL; Tue 7 Jun 83 10:23:18-PDT Received: from SCRC-BEAGLE by SCRC-TENEX with CHAOS; Tue 7-Jun-83 13:22:11-EDT Date: Tuesday, 7 June 1983, 13:21-EDT From: Bernard S. Greenberg Subject: DEFCONSTANT To: common-lisp%su-ai@usc-ecl (Symbolics common-lisp-implementors may type D without reading: rephrase of Sat.'s flame.) I am perturbed about DEFCONSTANT. According to the Laser manual, DEFCONSTANT is just like DEFPARAMETER, but the compiler is free to write the new value into object code. While this sounds at first like an improvement, a more powerful form of DEFPARAMETER, it is in fact a RESTRICTED form of DEFPARAMETER. The issue of what-gets-put in the @i(initial-value) slot is a subtle one. All well and good for (defconstant foo 3), but how about (defconstant bar 6) (defconstant foo (+ bar 6)), which is legal, meaningful, common, useful, and non-problematic for DEFPARAMETER? How is (+ bar 6) supposed to be evaluated at compile time? (Note that DEFCONSTANT does this evaluation at load time, which is what you "really" want). If the compiler were to use EVAL, does that mean that bar was set at compile time by the first DEFCONSTANT, so that this might be meaningful? If the binding were in some "compiler temporary declaration", (such as the Lisp Machine compiler uses for macros defined in a file being compiled) EVAL could not be used. Compiling a file is NOT supposed to side-effect the environment. The use of eval-when(compile) flags explicitly such attempts, but does not make them harmless. Each such use has to be deliberated very carefully, to prevent making impossible the compilation of an incompatible version of the program. Do you have to say (eval-when (compile load eval) (defconstant bar 6)) (defconstant foo (+ bar 6)) to get meaningful results? Is this what we want? Should the DEFCONSTANT documentation discuss and recommend this? I will not even address the issue of (defun f (x) ..) (defconstant a (f 4)) but just throw it out for sport.... I think the use of DEFCONSTANT involves a tremendous amount of subtlety. It may be reasonable to restrict the @i(initial-value) operand of DEFCONSTANT to quoted or self-evaluating constants if the programmer (and the compiler) are to have any hope of figuring out what is going on.  Received: from MIT-MC by SU-AI with TCP/SMTP; 7 Jun 83 01:43:21 PDT Date: 7 June 1983 04:44 EDT From: Kent M. Pitman To: fahlman @ CMU-CS-C cc: Common-Lisp @ SU-AI Sorry, I mistook Moon's "yes" to be a note of support for the CONVENTIONS issue. To avoid further confusion on this issue, please just ignore my "yes" vote and consider Moon to have my proxy on this one... The LispM crowd has had hands-on experience with a multi-file-system pathname system for several years now and probably has the best insight into what's going to be needed.  Received: from MIT-MC by SU-AI with TCP/SMTP; 7 Jun 83 00:13:45 PDT Received: from SCRC-EUPHRATES by SCRC-TENEX with CHAOS; Tue 7-Jun-83 03:15:21-EDT Date: Tuesday, 7 June 1983, 03:09-EDT From: David A. Moon Subject: [Re: revenge of the ballot, B7] To: Glenn S. Burke Cc: KMP%MIT-MC@SU-DSN, common-lisp@SU-AI, fahlman%CMU-CS-C@SU-DSN In-reply-to: The message of 7 Jun 83 02:44-EDT from Glenn S. Burke Date: 7 June 1983 02:44 EDT From: Glenn S. Burke Kent pointed out that i referred to Moon's comments on pathname-convention and came up with a negative reply, unlike Moon. I came up with a negative reply too, but I'm such a spastic that I typed "yes" when I meant "no". Sorry about that.  Received: from MIT-ML by SU-AI with TCP/SMTP; 6 Jun 83 23:43:00 PDT Date: 7 June 1983 02:44 EDT From: Glenn S. Burke Subject: [Re: revenge of the ballot, B7] To: KMP @ MIT-MC cc: common-lisp @ SU-AI, fahlman @ CMU-CS-C Kent pointed out that i referred to Moon's comments on pathname-convention and came up with a negative reply, unlike Moon. This is because (based on those arguments) the original reason for it does not hold up. And while pathname-convention may not be an unreasonable thing to have, we would have to standardize on what it returned for it to be useful, and that could get complicated if you tried to allow perturbations of standard "conventions" (and "subtyping" of them etc.). I'm not against that, but it might even mean yet-another-ballot.  Received: from MIT-MC by SU-AI with TCP/SMTP; 6 Jun 83 23:01:00 PDT Date: 7 June 1983 02:03 EDT From: George J. Carrette To: Common-Lisp @ SU-AI I still haven't seen a convincing argument for why disallowing mixed-type complexes is needed for efficiency reasons. Given the generic arithmetic operators on non-complex numbers this restriction of form only makes my implementations more complicated and slower. I humbly submit that machines with complex-floating-point datatypes built-in can uses those instructions, and complicate their implementation, since it is worth it, and they can do it *without* requiring universal restrictions. It is a fairly standard sort of optimization. How about somebody giving a good argument here rather than a "I'm told that, but I really don't have the ... to know." It is somewhat puzzling that we have this uniformity rule embraced, at the same time we have #C(3 0) => 3, a rule which surely breaks some *easy* data-uniformity optimizations, although it certainly doesn't require that #C(3 0) always be stored as 3, only that it never escapes to the user as #C(3 0). Get my drift? On the subject of (SQRT -1.0), let us consider Macsyma, a program much used, even for floating point calculations. It never seemed to bother people that Macsyma had rational and complex numbers (of a sort), since sometimes it made for serendipity -- but errors are eventually caught -- and presumably it will be easier to DEBUG a program in common-lisp than in fortran, so the more powerful operators in CL can be forgiven. In any case the Macsyma *compiler* I wrote had two things, a switch TR_FLOAT_CAN_BRANCH_COMPLEX, somewhat of a kludge, and a form MODE_IDENTITY, like common-lisp's "THE." So people could write MODE_IDENTITY(FLOAT,SQRT(X)). They didn't mind the greater verbosity because they had Emacs... My attitude is that these features, such as "/" returning a rational, *cost* a certain amount, in changing code, and runtime perhaps, so that once we (our users) pay this price we (our users) aught to get the greatest flexibility for it. So here we have a rule about uniformity of complex numbers. What does it cost? (1) More documentation to read. (2) More runtime checking when making complex numbers. (3) Reduction in possible objects to manipulate. What are the universal benefits? (Non-universal ones should be gotten by restrictive declarations in my book.)  Received: from MIT-MC by SU-AI with TCP/SMTP; 6 Jun 83 22:26:14 PDT Received: from SCRC-EUPHRATES by SCRC-TENEX with CHAOS; Tue 7-Jun-83 01:16:57-EDT Date: Tuesday, 7 June 1983, 01:10-EDT From: David A. Moon Subject: NTH-VALUE To: common-lisp@SU-AI Even though this was turned down and I don't see it as being a major feature (just a minor one) I'll probably implement it next time I feel like breaking a compiler. Then we'll see whether anyone uses it.  Received: from CMU-CS-C by SU-AI with TCP/SMTP; 6 Jun 83 21:00:37 PDT Received: ID ; 6 Jun 83 23:59:55 EDT Date: Mon, 6 Jun 1983 23:59 EDT From: Scott E. Fahlman To: Dir LCSR Comp Facility Cc: common-lisp@SU-AI Subject: Revenge of the Ballot In-reply-to: Msg of 6 Jun 83 18:24:32 EDT from Dir LCSR Comp Facility B1. OK. One possible disadvantage is that floating-point contagion is not guaranteed to work. That is, floating point has an upper bound, whereas bignum's don't. What would you do with (COMPLEX 1E-5 ZILLION), where ZILLION is a very big bignum? We would do the same thing as we would do in the case of (+ 1E-5 ZILLION). We would try to float the ZILLION in this format, and if it was too large to fit, we'd get a floating-overflow error.  Received: from CMU-CS-A by SU-AI with TCP/SMTP; 6 Jun 83 20:13:41 PDT Date: 6 June 1983 2309-EDT (Monday) From: Guy.Steele@CMU-CS-A To: fateman%UCBKIM@UCB-VAX (Richard Fateman) Subject: Re: sqrt(-1) CC: common-lisp@SU-AI In-Reply-To: <8306062018.8926@UCBKIM.ARPA> (1+ fixnum) IS NOT NECESSARILY a fixnum in Common LISP. It is fairly important to the user that it not be. I'm reminded of Tom Lehrer's remark in his introduction to "New Math" on his album "That Was the Year That Was": "In the New Math, on the other hand, the *idea* is the important thing... *rather* than getting the right answer." If you're worried about the speed of code, then there are several ways to use declarations to say what you mean: (THE DOUBLE-FLOAT (SQRT D)) (SQRT (THE (SINGLE-FLOAT 0.0 ()) D)) for example. (The first guarantees the result of SQRT to be a double-float; the second guarantees the argument to be a non-negative single-float.) One can also use assertions if explicit run-time checking is desired. Perhaps, Dick, you have failed to realize that it is proposed to treat rational and floating-point complex numbers according to different rules. With rationals, as with integers (fixnums plus bignums) in MacLISP, the emphasis is on getting the one, true, mathematically correct answer, no matter what it takes. With floating-point, the emphasis is on sacrificing accuracy for speed (as well as finiteness of representation, as necessary in the case of irrational computations), *but* on sacrificing that accuracy in a predictable and controllable fashion. Common LISP's treatment of floating-point is essentially the traditional one. Automatic coercion is provided in the form of floating-point contagion rules, but these are never used in the case where one writes Common LISP code in as type-stringent a manner as one would be compelled to in a strongly-typed language such as FORTRAN. In the absence of such contagion, Common LISP's treatment of floating-point is entirely consistent with the usual usage, and in particular is completely consistent with the proposed IEEE floating-point standard. --Guy  Received: from CMU-CS-A by SU-AI with TCP/SMTP; 6 Jun 83 20:02:23 PDT Date: 6 June 1983 2258-EDT (Monday) From: Guy.Steele@CMU-CS-A To: Walter van Roggen (C410WV50) Subject: MANTISSA => SIGNIFICAND CC: common-lisp@SU-AI In-Reply-To: <06Jun83.181707.WV50@CMU-CS-A> The reason for not using the term "mantissa" is that in its popular use in the context of floating-point representations it is a misnomer. Technically, a a mantissa is the fractional part of a logarithm. The significand of a floating- point number is not the fractional part of a logarithm (the exponent), but a fraction by which the base raised to the exponent must be multiplied. --Guy  Received: from CMU-CS-A by SU-AI with TCP/SMTP; 6 Jun 83 19:45:48 PDT Date: 6 June 1983 2242-EDT (Monday) From: Guy.Steele@CMU-CS-A To: common-lisp@SU-AI Subject: Multiple-value-revenge of the Ballot B1. I favor eliminating the data type (COMPLEX type1 type2), and replacing it by the type (COMPLEX type). This simplifies the type systems, and removes an annoying glitch in the abbreviation mechanism, as Moon pointed out. It does strike me as a bit strange, however, that we would provide the specialized types (COMPLEX RATIONAL), (COMPLEX SHORT-FLOAT), (COMPLEX SINGLE-FLOAT), (COMPLEX DOUBLE-FLOAT), and (COMPLEX LONG-FLOAT), but not provide (COMPLEX T) [or at least (COMPLEX (AND NUMBER (NOT COMPLEX))) ]. I guess I could go either way on this one. If (COMPLEX T) is not supported, then certainly the rules of floating-point contagion should apply. B2. (sqrt -1) and friends. YES. B3. multiple-value-setq takes multiple pairs. NO. B4a. Double values from xxx-significand. Mildly opposed. We voted on this before, as I recall. B4b. float-digits and float-precision. Fine by me. They aren't needed for printing, especially if B4c is approved. However, their existence makes B4c easier to explain. B4c. Restriction on FLOAT-INTEGER-SIGNIFICAND. YES. I wanted to impose a limitation like this, but didn't figure out the correct formulation. B5. Recursive-p in READ and friends. YES. B6. merge-pathnames. YES. B7. file name convention argument. Mild YES. --Guy  Received: from MIT-MC by SU-AI with TCP/SMTP; 6 Jun 83 18:52:02 PDT Date: 6 June 1983 21:54 EDT From: Kent M. Pitman To: Common-Lisp @ SU-AI B1 Make both halves of a complex match in type: No opinion. B2 Let SQRT, etc. return complex values: Yes. I see no other choice. This is the generic name; if it doesn't do the generic thing, then complex numbers in Common Lisp will be a joke. For the case where Fateman worries that a correct (albeit complex) answer from SQRT is the wrong thing, I don't see why he can't just write his own error checking. I had a bit of trouble finding how you'd do the declarations in my Colander edition; in Maclisp, however, I would write something like: (LAMBDA (X) (DECLARE (FLONUM X)) (IF (MINUSP X) (ERROR "Arg is negative" X)) (FLONUM-IDENTITY (SQRT X))) B3 Make MULTIPLE-VALUE-SETQ take multiple arg pairs: Yes. I know people who'd probably write their own macro to do this sort of thing if it weren't provided primitively. Since it must be absolutely trivial to implement, I'd just as soon people use a standard name rather than force them to make up their own name for what amounts to the exact same thing. B4 FLOAT-SIGNIFICAND proposals: No opinion. B5 Changes to READ arguments: No. I am not sure I understand all the issues that are being dealt with, but for the set that I have thought about (read eof in middle of object, flushing extra close parens quietly at toplevel, flushing whitespace after toplevel read, etc), I am fairly convinced that the SUBREAD/READ distinction is a valid one in so far as I think that READ is being stretched too far and I think that this extra argument for recursive-p will cause us trouble later on. If we had flavorized streams, I would suggest that all streams support a :READ-TOPLEVEL message, such that (SEND STANDARD-INPUT :READ-TOPEVEL #'READ) was the thing to do to instantiate any read. Note that this doesn't force one to write pairs of functions, since any reader can replace #'READ. The :READ-TOPLEVEL thing would be responsible for peeking for EOF and exiting quietly, for flushing toplevel parens and whitespace, etc. The reader itself would just read characters and would err if an eof was encountered within. This is essentially a variation of the way :RUBOUT-HANDLER works on the LispM; the application is slightly different, but I expect it is the right thing. The problem one might expect to have with this is that people writing normal user programs with toplevel READ calls such as: (DEFUN PROMPT-AND-ADD-NUMBERS () (FORMAT T "~&Input numbers (end with a NIL): ") (DO ((L NIL (CONS FORM L)) (FORM (READ) (READ))) ((NULL FORM) (APPLY #'+ L)))) will have to bite the bullet and admit they are calling a toplevel READ. Hence, they would write: ... (FORM (SEND STANDARD-INPUT :READ-TOPLEVEL #'READ) (SEND STANDARD-INPUT :READ-TOPLEVEL #'READ)) ... which is admittedly a bit cumbersome. Of course, we don't have message passing yet (do we? -- things change so fast...), so it'd have to be slightly different syntax. I suggest (READ-TOPLEVEL #'READ) where, on the LispM, for example, you'd probably implement this as a call to the stream with a :RUBOUT-HANDLER message. Oh, there's one other thing that would make this a LOT more comfortable. The LispM has a function called PROMPT-AND-READ which is a nice abstract way of getting a prompt and doing a toplevel read with some datatype checking built in. I suggest that if we had this function, people would probably rarely use READ anyway, since its features are very much nicer. In summary, all I'm doing is funneling a lot of other people's ideas through in the form of an alternate proposal: * Flush the RECURSIVE-P extra arg. * Introduce a new function which can be called to do a toplevel READ so that we don't need function pairs. * Also introduce PROMPT-AND-READ as on the LispM which really does more what people usually want anyway. (Specifying how to extend PROMPT-AND-READ would also be helpful; I know it's extensible but I'm not sure if the LispM people tell their users how). B6 MERGE-PATHNAMES: Yes. B7 CONVENTION Yes.  Received: from CMU-CS-A by SU-AI with TCP/SMTP; 6 Jun 83 17:54:30 PDT Date: 6 June 1983 1817-EDT (Monday) From: Walter van Roggen (C410WV50) To: Fahlman@cmu-cs-c Subject: Ballot B CC: common-lisp@su-ai Message-Id: <06Jun83.181707.WV50@CMU-CS-A> [B1] ok [B2] yes [B3] no [B4a] yes. FLOAT-INTEGER-SIGNIFICAND seems to be new, though clear. I don't remember why we're calling it a significand; what's wrong with MANTISSA [B4b] ok. [B4c] yes, this is definitely worthwhile. [B5] ok [B6] yes [B7] ok. Are we still going to have logical pathnames? I'd rather not have to implement them, especially since the description & intent don't seem clear to me (examples?). As I see them, most of their functionality is provided with this new CONVENTION arg and by most underlying file systems. ---Walter  Received: from MIT-ML by SU-AI with TCP/SMTP; 6 Jun 83 17:02:52 PDT Date: 6 June 1983 20:04 EDT From: Glenn S. Burke Subject: Revenge of the Ballot To: Fahlman @ CMU-CS-C cc: common-lisp @ SU-AI B1, B2, B4, B5, and B6, are acceptable to me. (I do not claim particular mathematical competence however. And, B4a brings up some of the issues which were discussed privately with respect to nth-value, but i'm willing to believe that most of the time both values will be used.) B3. Yes, gross as multiple-value-psetq might be. If we are going to call it multiple-value-setq, we should do it up consistently. B7. CONVENTION. Probably not a good idea. I think Moon said everything for on this topic. The NIL pathname code is modeled pretty much after the Lisp machine code. It is in fact modularized such that the stuff which is applicable to a particular "convention" (in our simplified case, VMS FILES-11) is totally distinct from the other stuff which knows how to open streams etc. Similarly, i will be adding TOPS-20 and ITS "conventions" so that we can get on with having NIL read files over the chaos net. I could see having a pathname-convention function, but i'm not sure that it is reasonable to do so unless at least some of the possible returned values are standardized, and there might be additional hair of some "conventions" being "subconventions" of others.  Received: from RUTGERS by SU-AI with TCP/SMTP; 6 Jun 83 15:22:42 PDT Date: 6 Jun 83 18:24:32 EDT From: Dir LCSR Comp Facility Subject: Re: Revenge of the Ballot To: Fahlman@CMU-CS-C.ARPA cc: common-lisp@SU-AI.ARPA In-Reply-To: Message from "Scott E. Fahlman " of 6 Jun 83 03:01:00 EDT I am going to give one of three answers: Yes, No, OK, and abstain. OK means that it looks good to me, but I don't know enough for that fact to be significant. Abstain means I don't know enough to be able to tell whether it is even superficially plausible. B1. OK. One possible disadvantage is that floating-point contagion is not guaranteed to work. That is, floating point has an upper bound, whereas bignum's don't. What would you do with (COMPLEX 1E-5 ZILLION), where ZILLION is a very big bignum? B2. OK, although I have a sneaking suspicion that it might be useful to have either a REAL-SQRT function or the ability to say (SETQ *NO-COMPLEX-NUMBERS-PLEASE* T). You should realize that I also believe (CDR NIL) should be an error, and for the same reason. So for consistency, you should probably ignore this. B3. No, don't take pairs of arguments. B4a. abstain B4b. Yes B4c. abstain B5. abstain. My first reaction is negative. I somehow implemented a complete Lisp, including read macros, without needing to do this. I am always able to keep track of what is going on without requiring an explicit argument from the user. I can only conclude from the discussion that there must be something odd about Common Lisp such that this can't be done. I can't imagine what it would be, but if the Spice folks are convinced it is so, I will defer to them. (After all, I am stealing most of their implementation, so it would not be very gracious of me to refuse them the tools they feel they need to do it.) B6. OK B7. Yes, but can't we do a better job of defining what conventions are?. Instead of the magic identifier TOPS-20, maybe "HOST::DEVICE:NAME.TYPE.VERSION", or maybe this could be the DEFINITION property of TOPS-20. This assumes that no system will use letters as delimiters. If this is a problem, I can come up with a more general metasyntax. -------  Received: from UCB-VAX by SU-AI with TCP/SMTP; 6 Jun 83 13:17:26 PDT Date: 6 Jun 83 13:18:47 PDT (Mon) From: fateman%UCBKIM@Berkeley (Richard Fateman) Subject: Re: sqrt(-1) Message-Id: <8306062018.8926@UCBKIM.ARPA> Received: by UCBKIM.ARPA (3.340/3.5) id AA08926; 6 Jun 83 13:18:47 PDT (Mon) Received: from UCBKIM.ARPA by UCBVAX.ARPA (3.341/3.31) id AA04089; 6 Jun 83 13:13:10 PDT (Mon) To: ALAN@MIT-MC Cc: common-lisp@su-ai (1+ fixnum) IS a fixnum in Franz. It is fairly important to our compiler that it be. It could be important that sqrt returns a real for similar reasons. You can record my vote as saying that IF sqrt returns complex sometimes, then there should be another say, sqrt-real. If you want to treat arithmetic as 2nd class, a tradition in Lisp, fine.  Received: from MIT-MC by SU-AI with TCP/SMTP; 6 Jun 83 13:16:00 PDT Date: 6 June 1983 15:02 EDT From: Alan Bawden Subject: sqrt(-1) To: fateman @ UCBKIM cc: Common-Lisp @ SU-AI Date: 6 Jun 83 10:23:57 PDT (Mon) From: fateman%UCBKIM at Berkeley (Richard Fateman) Let us say you are free to choose a different form for the answer, depending on the value. That is what Alan Bawden says. I did not propose anything different from what is already done with bignums. Certain potential bignums are illegal because they can be represented with fixnums. Similarly certain potential rationals are to be illegal because they are not in lowest terms, the denominator is negative, or they can be represented with fixnums or bignums. Finally certain potential Gaussian rationals are to be disallowed because they can be represented using rationals, bignums or fixnums. Well, how about having the exponential function choose a different float format if the exponent would otherwise underflow or overflow? I proposed nothing resembling this. Neither did anybody else as far as I can see. If someone has an argument in favor of it, they should speak up, otherwise I suggest we dismiss the idea as a strawman you devised to give yourself something to argue against. Do you really know the cost of not knowing that sqrt(float) is a float? Is add1(fixnum) a fixnum? Sqrt(float) is a float for positive arguments and is a (complex float) for negative arguments. Or it will be if we so vote. If someone expects a real and gets 0+1*i, does it come out as 0? In which case is sqrt(-1) = 0 ? Are you serious? This is Lisp, what does it mean to "expect" a real? (SQRT -1) => #C(0 1), today and tomorrow. Are you serious about people using CL for arithmetic? If so, I suggest you find some people who are serious about using arithmetic, and have thought about it more. After reading your message I'm fairly certain that we have though about these issues more than you have. I have been carefully reading every word you send on this subject and so far your objections have consisted entirely of misunderstandings and bombast.  Received: from MIT-MC by SU-AI with TCP/SMTP; 6 Jun 83 11:47:02 PDT Date: Monday, 6 June 1983 14:46-EDT From: MOON at SCRC-TENEX to: common-lisp at su-ai Subject: Revenge of the Ballot In-reply-to: The message of Mon 6 Jun 1983 03:01 EDT from Scott E. Fahlman B1. No mixed-type complexes. Yes. B2. (SQRT -1.0) -> i, not an error. No vote. I don't understand the implications of introducing a complex number into a program that thought it was working entirely in the reals. B3. MULTIPLE-VALUE-SETQ takes 0,2,4,... args. Yes. I don't believe the claim that the format is completely different from SETQ; it looks completely the same to me. Why else the motivation to change the name to include "SETQ"? B4. Cassels float proposals. Yes. I'd like to see new names for FLOAT-{INTEGER-}SIGNIFICAND. Also the sign should be returned as a third value and FLOAT-SIGN should be flushed also, unless its two-argument form is deemed important, in which case the manual should include a note about it. B5. Recursive calls to READ supply a new optional arg. Yes, mostly. I don't think the eof actions should be controlled by the top-level call to READ; I think an eof in a recursive read is always an "eof in the middle of an object" error. Note that this doesn't include an eof that merely acts as a delimiter. For example: use top-level eof control args ' eof in the middle of an object 'foo eof not seen until next read I'd like to see a precise specification of what is controlled by the recursive-read flag, since I suspect that it is ONLY the ## environment, except for implementations (e.g. Maclisp) that optimize out some sort of decoding of the stream argument. B6. MERGE-PATHNAME-DEFAULTS -> MERGE-PATHNAMES Yes MERGE-PATHNAME-DEFAULTS is okay provided only that its default-type argument -not- be optional, or that it default to a function of the defaults rather than to a constant (especially a constant that isn't even a legal pathname component, as in the Laser manual!). But removing it entirely from the Common language is okay, too. B7. Pathname CONVENTION field. Yes. It's not that I'm terribly opposed to this, but it just doesn't seem to make any sense. How can the caller of PARSE-PATHNAME know what syntax a pathname is written in, except by consulting the guy who supplied the string? And how can the guy who supplied the string say what syntax it is in, other than by putting something in the string? The point is that the caller of PARSE-PATHNAME has no business saying what syntax the string is in, doesn't care what syntax it is, and in general cannot know what syntax it is. Since the caller of PARSE-PATHNAME doesn't know what syntactic convention to use, maybe his caller does; are you going to change a whole bunch of functions, such as OPEN, DELETE-FILE, LOAD, COMPILE-FILE, DRIBBLE, etc. to take a new CONVENTION argument? Then are you going to go one level higher up and make the Read File command in your editor take a CONVENTION argument, so it can parse the file name the user types in? This is crazy! The example of two file systems coexisting on the same host is bogus. If you're going to use file name syntax to distinguish between them, then what if they have the same syntax? All 3600s have two distinct file systems that use the same syntax. And what about the user who wants to be able to access files on both file systems, even if they have different syntax? If the way you tell them apart is not in the pathname, then how does the user say which pathnames are for which file system? Obviously the answer is that the "host" field in a pathname is not the name of a CPU, it is the name of a file system. If you have two file systems resident on the same piece of iron, they have different names. And conversely if you have one file system that is attached to a multiprocessor, you don't say which of the processors you want to access it through, you just say the name of the file system. I also have little faith in the usefulness of accessing a Tops-20 file system with Unix-convention pathnames, or in general accessing any host (file system) with a different convention than its native one; either the different convention is trivially different (maybe Tops-20 with quotation marks around the directory and the name and version delimited by spaces instead of dots), or it is semantically different (no version numbers, as in Unix), in which case it won't work.  Received: from UCB-VAX by SU-AI with TCP/SMTP; 6 Jun 83 10:32:19 PDT Date: 6 Jun 83 10:23:57 PDT (Mon) From: fateman%UCBKIM@Berkeley (Richard Fateman) Subject: sqrt(-1) Message-Id: <8306061723.6254@UCBKIM.ARPA> Received: by UCBKIM.ARPA (3.340/3.5) id AA06254; 6 Jun 83 10:23:57 PDT (Mon) Received: from UCBKIM.ARPA by UCBVAX.ARPA (3.341/3.31) id AA01721; 6 Jun 83 10:18:21 PDT (Mon) To: common-lisp@su-ai Actually, I am tired of bringing this stuff up, but let me point out some of the logical extensions. Let us say you are free to choose a different form for the answer, depending on the value. That is what Alan Bawden says. Well, how about having the exponential function choose a different float format if the exponent would otherwise underflow or overflow? How about having (pardon Maclisp syntax, which may in fact be wrong here) (do ((i 10.0 (times 10 i)))nil (print i)) print forever, starting with small floats (with small exponents), going to bigger floats, and then, in the interests of preserving mathematical properties like (x*10)/10 = x, going to bignum integers. Do you really know the cost of not knowing that sqrt(float) is a float? If someone expects a real and gets 0+1*i, does it come out as 0? In which case is sqrt(-1) = 0 ? Are you serious about people using CL for arithmetic? If so, I suggest you find some people who are serious about using arithmetic, and have thought about it more.  Received: from MIT-MC by SU-AI with TCP/SMTP; 6 Jun 83 09:48:36 PDT Date: 6 Jun 1983 1158-EDT From: Daniel L. Weinreb Subject: Re: Results of ballot A To: Fahlman%CMU-CS-C@SU-DSN cc: EAK%MIT-MC@SU-DSN, common-lisp@SU-AI In-Reply-To: The message of Sun, 5 Jun 1983 15:41 EDT from Scott E. Fahlman Well, likewise, if I write a program that loops four billion times calling CONS each time, that doesn't violate the Common Lisp standard in any way at all, yet it might reasonably be expected to fail in some implementations. So no implementation can possibly be valid. The intent of the requirement about minima for the maximum array size is presumably to make sure that the implementation can REPRESENT such arrays, even though attempting to CONS one at any time might run you out of free storage. I'm not sure how to phrase this in a completely clear way for the manual, but I don't think that getting rid of the 1024 thing is necessarily valid. -------  Received: from USC-ECL by SU-AI with TCP/SMTP; 6 Jun 83 07:18:36 PDT Received: from MIT-MC by USC-ECL; Mon 6 Jun 83 07:16:28-PDT Received: from SCRC-BEAGLE by SCRC-TENEX with CHAOS; Mon 6-Jun-83 10:09:57-EDT Date: Monday, 6 June 1983, 10:09-EDT From: Bernard S. Greenberg Subject: PARSE-INTEGER To: common-lisp%su-ai@usc-ecl As currently specified, PARSE-INTEGER will not accept signed integers. That's correct. It should, however, have a :sign-allowed keyword, default NIL, to allow this, right?  Received: from CMU-CS-C by SU-AI with TCP/SMTP; 6 Jun 83 07:58:14 PDT Received: ID ; 6 Jun 83 10:55:06 EDT Date: Mon, 6 Jun 1983 10:55 EDT From: Scott E. Fahlman To: common-lisp@su-ai Subject: Ballot clarification KMP has asked for a clarification on issue 5B. It seems clear enough to me, but what I'm asking for is a YES/NO vote on whether the proposed mechanism looks reasonable enough to you that you could live with it. Whichever way you vote on this, you are welcome to offer alternative suggestions that you like better: "Bring back SUB-READ", etc. The reason that I've phrased it this way is that I'm afraid that this issue will end up like DLET: 53 different plans and no consensus. That's fine for DLET, since we can defer the issue, but it would be awkward not to have a reader until the second edition, so if all the suggestions diverge, I am trying to get a feeling for whether my proposal is at least acceptable, if not optimal, in the eyes of this community. -- Scott  Received: from CMU-CS-C by SU-AI with TCP/SMTP; 6 Jun 83 07:47:44 PDT Received: ID ; 6 Jun 83 10:47:20 EDT Date: Mon, 6 Jun 1983 10:47 EDT From: Scott E. Fahlman To: Bernard S. Greenberg Cc: common-lisp@su-ai Subject: PARSE-INTEGER In-reply-to: Msg of 6 Jun 1983 10:09-EDT from Bernard S. Greenberg Bernie, Adding :SIGN-ALLOWED to PARSE-INTEGER seems like an uncontroversial suggestion, as long as it's not the first of N such messages. Unless someone pops up and objects, I will consider this to be approved. -- Scott  Received: from MIT-MC by SU-AI with TCP/SMTP; 6 Jun 83 01:36:08 PDT Date: 6 June 1983 04:38 EDT From: Alan Bawden Subject: Revenge of the Ballot To: Fahlman @ CMU-CS-C cc: Common-Lisp @ SU-AI In-reply-to: Msg of Mon 6 Jun 1983 03:01 EDT from Scott E. Fahlman I vote Yes for 1 and 2. I abstain from voting on all of the rest.  Received: from CMU-CS-C by SU-AI with TCP/SMTP; 6 Jun 83 01:10:34 PDT Received: ID ; 6 Jun 83 03:01:56 EDT Date: Mon, 6 Jun 1983 03:01 EDT From: Scott E. Fahlman To: common-lisp@su-ai Cc: fahlman@CMU-CS-C Subject: Revenge of the Ballot Ballot B: A few loose ends. With luck, this will be the final ballot before the manual is finalized for the first edition. There may be a couple of messages on single issues that pop up during final cleanup of the manual, but this should be the last multi-issue submission. Please reply by dawn, Tuesday morning. I plan to collate the answers later in the day on Tuesday. --------------------------------------------------------------------------- B1. Proposed that we require both halves of a complex number to be of the same type, either both rationals or both floats of the same type. The COMPLEX function will accept numeric arguments of mixed type, but it will do floating-point contagion of the usual sort (floats dominate rationals, floats of greater precision dominate those of lesser) before returning the complex number. [ I am not really qualified to have an opinion on this. It would make the system easier to implement, easier to understand, and it would get rid of an ugly exception or two. On some hardware (the S-1, for example) homogeneous-type complexes can be handled by the hardware, while mixed types are more awkward. Therefore, if none of the mathematicians in the audience has a good reason NOT to do this, it looks like a good move to me. ] --------------------------------------------------------------------------- B2. Proposed that we adopt Alan Bawden's suggestion that we return a complex number from functions like (sqrt -1), where we would otherwise have to signal an error. If not this, please indicate what you think we should do. [ Same comment as above. If we're going to have complexes (and we are), it seems wrong for (sqrt -1) not to return one. ] --------------------------------------------------------------------------- B3. Now that we have decided to change from MULTIPLE-VALUE to MULTIPLE-VALUE-SETQ, Moon says that we must have this form take pairs of arguments like SETQ and PSETQ. Yes or no? [ I say no. The format is completely different since there is a list of N variables and one value-producing form. I don't think anyone will assume that it must take pairs of variables (variable-lists, really) and values as SETQ does. To add this would be MORE confusing, not less. ] --------------------------------------------------------------------------- B4. Proposals by Robert Cassels to change FLOAT-SIGNIFICAND and friends. [ These all look like good changes to me. There were also a couple fo suggested clarifications to the manual that Guy can deal with. Vote on each part separately if you need to. ] B4a. Proposal: Remove FLOAT-EXPONENT and FLOAT-INTEGER-EXPONENT, and return those numbers as the second values from FLOAT-SIGNIFICAND and FLOAT-INTEGER-SIGNIFICAND. This would serve to make these functions more similar to the division functions, and emphasize the close relationship between the values. It also leads to slightly improved efficiency of implementation, particularly on systems with unnormalized (or denormalized) numbers, and those with "non-numeric" floating-point values [IEEE floating-point, anyone?] which must be checked. (I'm assuming that when one value is wanted, the other is almost always wanted also.) B4b: Proposal: Add new functions FLOAT-DIGITS and FLOAT-PRECISION. (FLOAT-DIGITS float) would return the number of (FLOAT-RADIX float) digits used in the representation of a floating-point number. (Including the "hidden bit", if any.) For most implementations, this is really a property of the type of float. (FLOAT-PRECISION float) would return the number of significant (float-radix float) digits present in float. Implementation: For implementations using only normalized numbers, these functions would be identical. (- (FLOAT-DIGITS float) (FLOAT-PRECISION float)) would reflect the degree of denormalization of float. These functions are needed to simplify the movement of floating-point numbers from one implementation to another. They are also needed to convert numbers from one base to another in a way which reflects the precision (doesn't print bogus digits). FLOAT-DIGITS could be computed for most implementations by (- (FLOAT-EXPONENT 1.0) (FLOAT-EXPONENT SINGLE-FLOAT-EPSILON)) or something like that. But making it a function seems cleaner than some sort of typecase. B4c. Proposal: Require the result of FLOAT-INTEGER-SIGNIFICAND to reflect the precision of the floating-point number. Currently, FLOAT-INTEGER-SIGNIFICAND is only required to satisfy the identity relating it to FLOAT-INTEGER-EXPONENT. That allows the result to be scaled by various powers of the radix, so long as the exponent is adjusted appropriately. So if @i[b] is (FLOAT-RADIX float) and @i[p] is (FLOAT-PRECISION float), the result of (FLOAT-INTEGER-SIGNIFICAND float) for non-zero float should be between (EXPT b p) (exclusive) and (EXPT b (1- p)) (inclusive). --------------------------------------------------------------------------- B5. We've stil got to settle the business of top-level vs. recursive calls to READ and friends. Having considered all of the mail that has flown by on this, I re-propose the following: All of the functions that now take EOF-ERRORP and EOF-VALUE arguments (except for READ-BYTE and READ-BINARY-OBJECT) will take an additional optional arg after EOF-VALUE. This arg, RECURSIVE-P, should be NIL if the function is called at the top level in a read, T otherwise. It defaults to NIL. If this is non-null, the eof actions are controlled not by the funciton's own controls, but by the top-level call. Also, only top-level calls rebind the ## environment, etc. I was thrown for a bit of a loop by Eric Benson's suggestion that read-macro functions have to know whether they are at top-level so that they will know whether their own calls to read are recursive or top-level. That seemed to require some heavy-duty changes until I realized that a macro-character function is always called within a READ, so it always wants to the calls it makes to be recursive, unless perhaps it is initiating some sort of top-level dialogue with the user instead of gobbling down more of the stream in which the macro character was read. Of course, this assumes that you don't call random character-macro functions directly, but that they only get called by the reader. [ I think this does it. Propose alternatives if you want to, but also please indicate whether you can live with this. ] --------------------------------------------------------------------------- B6. Rename MERGE-PATHNAME-DEFAULTS to MERGE-PATHNAMES and eliminate the default-type argument. (This is obtained from the defaults.) [ Suggested by the folks at Symbolics who have experience with these things. They claim that users get terribly confused if the default type present in the DEFAULTS argument is not used. Sounds good to me.] --------------------------------------------------------------------------- B7. Propose that we add a new slot, CONVENTION, to the pathname structure, and an optional CONVENTION argument to the PATHNAME and TRUENAME functions. This convention is used in parsing the argument, if it is a string, and is recorded in the resulting pathname structure so that the pathname can be turned back into a namestring in the same format. CONVENTION is a symbol, not a string; the collection of meaningful convention symbols is implementation-dependent. PARSE-NAMESTRING, which already has a convention argument, would be brought into conformity with this. The rule should be that the convention, if it is supplied, is used to guide the parsing, and an error is signalled if the string is not legal in this convention. If the convention is not supplied, the system will examine the string and attempt to deduce the convention in some grossly implementation-specific or site-specific way, perhaps by recognizing the host name and looking up that host's convention in a table. We should not specify anything about how this is done; in particular, do not specify that the host is delimited by "::". The point is that the current proposal (a simplified subset of the existing Lispm pathname facility) muddles together the notion of HOST (the machine or network node where the file resides) and CONVENTION (what file-naming convention is used in this file name). A host might be "CMUC"; its convention might be "TOPS-20". A convention runs on many hosts, and it is quite possible that some hosts will provide more than one convention. (Our 3600's may one day have a band full of Symbolics-format files and a band full of Spice-format files, coexisting happily; there are other examples around.) In any event, code can be more portable if it can deal with something as a Tops-20 filename than as "whatever CMUC is". Many places in the pathname section refer to some feature as "host-dependent", when in fact it depends on the convention. [ I'm in favor. ]  Received: from CMU-CS-A by SU-AI with TCP/SMTP; 5 Jun 83 19:45:23 PDT Date: 5 June 1983 2241-EDT (Sunday) From: Walter van Roggen (C410WV50) To: Fahlman@cmu-cs-c Subject: minimum multiple values CC: common-lisp@su-ai Message-Id: <05Jun83.224137.WV50@CMU-CS-A> For you multiple-value aficionados, remember that GET-DECODED-TIME returns 9 multiple values. BTW, I think using "MV-" as a prefix would encourage their use. ---Walter  Received: from MIT-ML by SU-AI with TCP/SMTP; 5 Jun 83 17:55:27 PDT Date: 5 June 1983 20:57 EDT From: George J. Carrette Subject: Complex Arguments, fear and loathing on the number line. To: ALAN @ MIT-ML cc: COMMON-LISP @ SU-AI My feeling is that adding simplification rules on the results of a function are ok as long as it doesn't get out of hand. One might write this: (defmethod ((complex complex) :plus) (x y) (make-complex (+ (send x :real) (send y :real)) (+ (send x :imag) (send x :imag)))) And if make-complex is a routine which checks for the simplification case I don't mind, although I would mind if this sets a precedent for more simplification rules. It could simply get very complex and slow down the implementations enough so that potential users would go back to their own devices such as MAKE-COMPLEX = CONS. That is why I would shy away from making any claims about disallowing certain forms of numbers. I find nothing wrong with #C(3.3 5) or #C(0.3 3/4), although it might not be easy to generate such a thing besides having typed it in. (e.g. (+ 3.3 #C(0 3/4)) is sure to produce #C(3.3 0.75) naturally, by 3.3 => #C(3.0 0.0) ; extend to complex by getting the ZERO of the type of 3.3) The same argument goes for various forms of non-uniform floating-point combinations. Even if somebody does type one in I don't see how a good implementation of the arithmetic would care. Maybe this is another good time to quote from the "Federalist Papers" about how it isn't a good idea to make a law against something that you can't fathom happening anyway.  Received: from CMU-CS-C by SU-AI with TCP/SMTP; 5 Jun 83 17:00:28 PDT Received: ID ; 5 Jun 83 20:00:33 EDT Date: Sun, 5 Jun 1983 20:00 EDT From: Scott E. Fahlman To: Alan Bawden Cc: Common-Lisp@SU-AI Subject: gaussian rationals, transcendental functions, etc. In-reply-to: Msg of 5 Jun 1983 18:58 EDT from Alan Bawden If Fateman has a specific gripe or a specific proposal to make, he should make it. If his only proposal is that we should eliminate complex numbers from the language until we can find a REAL mathematician who understands this stuff, all I can say if that it is too late to consider such a sweeping change, and will just have to muddle through with the motley assortment of talent available on this list. If we make some sort of mistake this time around, we can always correct it later. The suggestion that numbers like #C(3/4 3.14159) be eliminated has a certain appeal. Would the proposal extend to eliminating numbers like #C(1.0S0 1.0L0)? Yes. There would be exactly as many types of complex number as there are types of floating point, plus the type in which both halves are rational. The COMPLEX function and other functions that create complex numbers would take any mixture of arguments and would do the usual foating-point contagion at creation time. -- Scott  Received: from MIT-MC by SU-AI with TCP/SMTP; 5 Jun 83 15:57:40 PDT Date: 5 June 1983 18:58 EDT From: Alan Bawden Subject: gaussian rationals, transcendental functions, etc. To: Common-Lisp @ SU-AI Date: 5 Jun 83 11:13:57 PDT (Sun) From: fateman%UCBKIM at Berkeley (Richard Fateman) Frankly, complex arithmetic should not be designed by a consensus of Lisp hackers. The difference between mathematical theory and computation is perhaps not clear to Alan, but there is a difference between thinking mathematically and computationally. I believe I have now argued this point from both mathematical and computational standpoints, and have demonstrated how to fit the two together acceptably. I'll not continue to argue the issue. If a degree in mathematics and several years experience as a "Lisp hacker" don't qualify me to have an intelligent opinion on this subject in fateman's eyes, so be it. If anyone else would like to say something new on the subject... The issue raised by Fahlman about needing a rule that says that that putting in a real gets you a real answer if possible, is dealt with by specifying appropriate ranges for the transcendental functions. In the laser manual, GLS has already suggested ranges that have this property. (This is nothing new really, mathematicians have always chosen the principle values of such functions to satisfy Fahlman's rule.) Let me reiterate what I said yesterday: the only new behavior exhibited by that handful of transcendental functions, when given a pure real argument, would be the generation of a complex number in some cases, rather than an error. BTW, I accidentally excluded the EXPT function from my list of transcendental functions that have "questionable" (from a user-interface, or "computational" viewpoint) regions in the real part of their domains. So make that 7 functions with the "problem". The suggestion that numbers like #C(3/4 3.14159) be eliminated has a certain appeal. Would the proposal extend to eliminating numbers like #C(1.0S0 1.0L0)? Eliminating such mixed floating types might frowned upon by the masters of floating point, although I can also imagine that converting this to #C(1.0L0 1.0L0), (that is, converting to the maximum of the two precisions), would be acceptable to them.  Received: from CMU-CS-C by SU-AI with TCP/SMTP; 5 Jun 83 12:40:48 PDT Received: ID ; 5 Jun 83 15:41:01 EDT Date: Sun, 5 Jun 1983 15:41 EDT From: Scott E. Fahlman To: Earl A. Killian Cc: common-lisp@SU-AI Subject: Results of ballot A In-reply-to: Msg of 5 Jun 1983 15:26 EDT from Earl A. Killian Oops. No, requiring each implementation to support 4 Gigabytes of total array size is probably a bit extreme. It would rule out any implementation on most small computers such as the Vax and the 3600. -- Scott  Received: from MIT-MC by SU-AI with TCP/SMTP; 5 Jun 83 12:25:57 PDT Date: 5 June 1983 15:26 EDT From: Earl A. Killian Subject: Results of ballot A To: Fahlman @ CMU-CS-C cc: common-lisp @ SU-AI In-reply-to: Msg of Sun 5 Jun 1983 12:52 EDT from Scott E. Fahlman Gee, a 1024 x 1024 x 1024 array takes 2^30 words (4 Gigabytes). Does each implementation really have to support that?  Received: from UCB-VAX by SU-AI with TCP/SMTP; 5 Jun 83 11:12:41 PDT Date: 5 Jun 83 11:13:57 PDT (Sun) From: fateman%UCBKIM@Berkeley (Richard Fateman) Subject: gaussian rationals Message-Id: <8306051813.14080@UCBKIM.ARPA> Received: by UCBKIM.ARPA (3.340/3.5) id AA14080; 5 Jun 83 11:13:57 PDT (Sun) Received: from UCBKIM.ARPA by UCBVAX.ARPA (3.341/3.31) id AA11635; 5 Jun 83 11:12:52 PDT (Sun) To: common-lisp@su-ai Frankly, complex arithmetic should not be designed by a consensus of Lisp hackers. The difference between mathematical theory and computation is perhaps not clear to Alan, but there is a difference between thinking mathematically and computationally. For example, division by 0 is not defined in a mathematical field. Computationally, division by 0 must be treated SOME way. Similarly, -1 and -1+0*i can be said to be mathematically identical, but that says very little about how to compute with them. In particular, whether sqrt(*) gives an error or not. One view of sqrt(-4) is that it should return -2. The sign of the answer clearly indicates something funny went on. I would propose that rather than vote on complex arithmetic in this forum, real arithmetic only be specified, and allow someone at some later time specify a package for complex.  Received: from MIT-MC by SU-AI with TCP/SMTP; 5 Jun 83 11:11:16 PDT Date: Sunday, 5 June 1983 13:50-EDT From: MOON at SCRC-TENEX To: Common-Lisp at SU-AI Subject: Proposed elimination of mixed-type complex numbers In-reply-to: The message of Sun 5 Jun 1983 11:11 EDT from Scott E. Fahlman This would also eliminate the one-of-a-kind anomaly in type expressions that (COMPLEX FLOAT) is not the same as (COMPLEX FLOAT *), but rather is the same as (COMPLEX FLOAT FLOAT). The COMPLEX type expression would be allowed only a single "argument."  Received: from CMU-CS-C by SU-AI with TCP/SMTP; 5 Jun 83 10:53:49 PDT Received: ID ; 5 Jun 83 12:52:11 EDT Date: Sun, 5 Jun 1983 12:52 EDT From: Scott E. Fahlman To: common-lisp@su-ai Cc: fahlman@CMU-CS-C Subject: Results of ballot A Results of Ballot A: Evaluated by the same non-linear criteria as the last ballot, for the same non-linear reasons. There will be one last ballot, probably appearing later today. This will contain some proposals on recursive reading, file names, and a few odds and ends. That will probably be the last formal ballot before the manual goes to press. There will be a period of proofreading, however. --------------------------------------------------------------------------- A1. Add PARSE-INTEGER to replace the defunct PARSE-NUMBER: ACCEPTED. I take it that BSG's clarification to this is acceptable: this function does not parse the full Common Lisp integer syntax (including such things as #R) but just slurps down digits in the radix provided by the caller and returns an integer. --------------------------------------------------------------------------- A2. PROCLAIM evaluates its arguments: ACCEPTED. --------------------------------------------------------------------------- A3. Package name syntax: most people could accept either B or C, with a marked preference for B among most of those indicating a preference. I will take B as accepted and see what I can do to the "string-based" interface functions that worry Moon. At the very least, we can make these string-or-symbol and encourage users to use the symbol form so that they won't get confused about case. --------------------------------------------------------------------------- A4. Rearange args to VECTOR-PUSH and VECTOR-PUSH-EXTEND to match PUSH: ACCEPTED. --------------------------------------------------------------------------- A5. Add NTH-VALUE: REJECTED. The raw vote is almost exactly tied, but the negatives are more vehement, the implementors are predominately against, and the conservative principle that says in case of a tie we go with the status quo. --------------------------------------------------------------------------- A6. Add a set of primitives for named structures: REJECTED. Implementors of DEFSTRUCT and similar packages will be encouraged to confine any implementation-specific code for dealing with named structures in a small, easily changed part of the package. --------------------------------------------------------------------------- A7. Flush SET: REJECTED. Flush FSET: APPROVED. --------------------------------------------------------------------------- A8. Make (APPLY '(LAMBDA ...)) be an error: REJECTED. The debate over how far in the direction of Scheme we want to go will undoubtedly continue, and we may go farther in the second edition, but a complete restructuring of the traditional role of lambda and function names was generally viewed as unwise at this time. Users should be encouraged to use #'(LAMBDA ...) wherever appropriate. Guy should be encouraged to clarify the definitions of "function", "compiled function", and how all this relates to lexical closures in the manual. Certain things are inconsistent at present. --------------------------------------------------------------------------- A9. Reinstate VREF: REJECTED, narrowly. --------------------------------------------------------------------------- A10. Add integer seed to MAKE-RANDOM-STATE: In my opinion, Guy has single-handedly shot this down by showing that the desired functionality can be obtained through the existing mechansims, and that the proposed new mechanism cannot do this as well. Unless someone can show that this is wrong, I'm going to treat this proposal as REJECTED. --------------------------------------------------------------------------- A11. Add APPLYHOOK mechanism: APPROVED. (Sigh, now I have to go implement this thing -- still, it's probably worth the hassle.) --------------------------------------------------------------------------- A12. Add DLET: REJECTED. People favoring some form of this slightly outnumbered those who opposed it, but there was no agreement among those in favor on the exact form that this macro should take. So the competing plans will have to fight it out as yellow pages packages for now, and maybe by the second edition we'll have a clear winner. --------------------------------------------------------------------------- A13. Moon's proposed change to INTERN and FIND-SYMBOL: APPROVED. --------------------------------------------------------------------------- A14. Rename MULTIPLE-VALUE to MULTIPLE-VALUE-SETQ: APPROVED. Several people have proposed that we rename these things to "MV-". This was debated long ago, the "MULTIPLE-VALUE-" prefix won out over "MV-", and I take the matter as closed. Moon suggests that if we call this form "MULTIPLE-VALUE-SETQ" we must make it take pairs of arguments. I don't find this compelling, but I'll put this question on the last ballot. --------------------------------------------------------------------------- A15. Add constants indicating values of various limits (maximum array rank, etc.) in each implementation: APPROVED. Leave the values of these limits completely up to the implementation, with no minima: REJECTED. People felt that some sort of floor is required so that users could be sure that normal cases (a 3-D array with indices of 1024 on each dimension, for example) will be portable. I sense a willingness to let Guy choose a reasonable set of floor values, in consultation with the various implementors. The guiding principle should be that the limits are generous enough that reasonable human-written code will not push the limits, but not so generous that the ability to write a Common Lisp for a small machine is NEEDLESSLY impaired. A starting point might be proposal of 7 array dimensions, 50 named arguments (with no limit on rest args), and 7 return values. Implementations will be encouraged to make their own limits as generous as possible, so that even unreasonable machine-written code can be handled if this does not impact performance in a negative way. --------------------------------------------------------------------------- A16. Flush MACRO, add Guy's SET-MACRO: basically APPROVED. Several people suggested that SET-MACRO is a bad name, and proposed instead a MACRO-FUNCTION accessor upon which SETF works. If nobody objects strongly to this, I will take this modification as being approved. --------------------------------------------------------------------------- A17. Gaussian integers are to be stored in canonical form: APPROVED. Only a few people felt themselves to be qualified to vote on this, but these people strongly favored the proposal.  Received: from CMU-CS-C by SU-AI with TCP/SMTP; 5 Jun 83 08:10:24 PDT Received: ID ; 5 Jun 83 11:11:11 EDT Date: Sun, 5 Jun 1983 11:11 EDT From: Scott E. Fahlman To: Alan Bawden Cc: Common-Lisp@SU-AI Subject: Gaussian rationals In-reply-to: Msg of 5 Jun 1983 04:31 EDT from Alan Bawden Not being a mathematician -- in fact, the only things I really believe in are the integers from 0 through 1023, unless I have my shoes off -- I feel that I'm way out of my depth here. I was one of the people who didn't want complexes to be required at all, because I can't figure out who around here is going to implement them. But whenever we do get this installed, I would have no objection to Bawden's suggestion that we do the mathematically right thing here. Anyone who is depending on getting an error in some situation isn't writing portable Common Lisp anyway, and if the user is expecting an error on (SQRT -1) and instead gets #C(0 1), I see no problem there. The one problem I do see is that we don't want users to take (SQRT 4.0) and get a complex, so we need a rule that says that if you put a real in, floating or not, you get one out if possible. But if the user who gets back a complex can simply say to himself "Oh, that's an error if you're confined to the reals, but here is what it looks like otherwise", then I've got no problem. If we ever start distributing Common Lisp to grade schools we may want to put in ways to turn off complexes (or even fractions), but that's a special-purpose hack. While we're talking about canonical forms, I would like to propose once again that we require both halves of a complex to be of the same type: rationals or one of the flavors of float. You would do the appropriate floating-point contagion when the complex is created, not every time you want to use it. I may be revealing my naivete here, but this just looks like the right thing to do, pure and simple. It would clean up the notation and make life easier for implementations that want to put in special complex-number microcode or arrays for various complex types. I know that this was discussed before, but I don't remember any resolution of the problem -- it just sort of faded away. Is there really any coherent argument for keeping things like #C(2/3 3.33e-1) around? If nobody talks me out of this in the next few hours, I am tempted to put this on a ballot. -- Scott  Received: from MIT-MC by SU-AI with TCP/SMTP; 5 Jun 83 01:29:49 PDT Date: 5 June 1983 04:31 EDT From: Alan Bawden Subject: Gaussian rationals To: Common-Lisp @ SU-AI, fateman @ UCBKIM cc: Moon @ SCRC-TENEX The point is that -1 and -1+0*i are the same number in any clear way of thinking about the situation. To muddy the essential mathematics of the situation (that the real rationals are a sub-field of the Gaussian rationals) because of a user-interface issue (what users expect of certain transcendental functions), is downright wrong. I note that only a few transcendental functions have the potential user-interface problem alluded to. By the nature of a field, no rational function can escape from the reals. The GCD and LCM functions behave the same way when restricted to the ring of integers as they do when their domain is taken to be the ring of Gaussian integers. The NUMERATOR and DENOMINATOR functions can consequentially be naturally extended to Gaussian rationals. Various other miscellaneous functions like ABS and SIGNUM also naturally extend to the complex case. Only a handful of transcendental functions that have been traditionally expected to err when given certain real arguments, could now be expected to yield a complex result. The functions in question are: LOG, SQRT, ASIN, ACOS, ACOSH, and ATANH. If anyone can find any more, they should speak up. Not coincidentally, these are all functions that require the specification of branch cuts. These are also all functions that deal in floating point values. (Because floating point is the usual representation chosen for transcendental numbers. Another unfortunate tradition, but not one we are currently in a position to challenge.) Not being a great fan of floating point, I don't like being in a position where I have to suggest anything about these functions. However, since I seem to be the one on the crusade to clean up the Gaussian rationals, I feel I must make some proposal about what to do about these six functions. I'll offer 4 possibilities: 1. Surprise everyone. In Common Lisp, these six functions are complex-valued. People who expect (SQRT -1) to err are wrong. (I would favor this myself, but I appreciate the arguments against it.) 2. These six functions are real-values only. Introduce six more functions that have the full complex range. Nobody is surprised. People who want complexes say (COMPLEX-SQRT -1). (Actually more than six functions would need to be introduced; I presume we would want a COMPLEX-ASINH to match COMPLEX-ACOSH etc.) 3. These six functions are complex-valued as in 1., and we additionally introduce six new functions that are real-valued. People who want (SQRT -1) to be an error, have to say (REAL-SQRT -1) instead. (Again, more than six are really necessary.) 4. Since in all cases the answer is floating point, and since -1.0 and #C(-1.0 0.0) really ARE different, define these functions to return a complex result (in the questionable part of their domains) ONLY if given a floating point complex argument. Thus (SQRT -1), and (SQRT -1.0) are both errors, but (SQRT #C(-1.0 0.0)) is not. To get the effect of the COMPLEX-SQRT function, you would write something like (SQRT (COMPLEX X 0.0)). If we were to decide to do this, then the next issue we get to haggle is what (SQRT #C(1 1)) does (since you can hardly regard 1+i a a "questionable" part of the domain of SQRT!).  Received: from MIT-MC by SU-AI with TCP/SMTP; 4 Jun 83 15:14:43 PDT Date: 4 Jun 1983 1814-EDT From: Bernard S. Greenberg Subject: Re: Volume of mail (trivia) To: Guy.Steele%CMU-CS-A@SU-DSN cc: common-lisp@SU-AI In-Reply-To: The message of 4 June 1983 1749-EDT (Saturday) from Guy.Steele@CMU-CS-A Return-path: Received: from MIT-MC by SCRC-TENEX with CHAOS; Sat 4-Jun-83 17:59:09-EDT Received: from CMU-CS-A by SU-AI with TCP/SMTP; 4 Jun 83 14:52:03 PDT Date: 4 June 1983 1749-EDT (Saturday) From: Guy.Steele@CMU-CS-A To: common-lisp@SU-AI Subject: Volume of mail (trivia) If anyone cares, I received over 15000 (decimal!) lines of mail in the last eight days. Essentially all of it was about Common LISP. All this activity must imply that we are obviosuly (or at least boviously) making substantial progress. --Guy --------------- As Doug Hofstadter ALMOST did in last month's column, you should solicit from this list suggestions for decreasing the volume of mail..... -------  Received: from CMU-CS-A by SU-AI with TCP/SMTP; 4 Jun 83 14:52:03 PDT Date: 4 June 1983 1749-EDT (Saturday) From: Guy.Steele@CMU-CS-A To: common-lisp@SU-AI Subject: Volume of mail (trivia) If anyone cares, I received over 15000 (decimal!) lines of mail in the last eight days. Essentially all of it was about Common LISP. All this activity must imply that we are obviosuly (or at least boviously) making substantial progress. --Guy  Received: from UCB-VAX by SU-AI with TCP/SMTP; 4 Jun 83 10:41:37 PDT Date: 4 Jun 83 10:42:57 PDT (Sat) From: fateman%UCBKIM@Berkeley (Richard Fateman) Subject: Re: Gaussian rationals Message-Id: <8306041742.1846@UCBKIM.ARPA> Received: by UCBKIM.ARPA (3.340/3.5) id AA01846; 4 Jun 83 10:42:57 PDT (Sat) Received: from UCBKIM.ARPA by UCBVAX.ARPA (3.341/3.31) id AA23288; 4 Jun 83 10:42:07 PDT (Sat) To: @SU-AI:ALAN@MIT-MC, Common-Lisp@SU-AI, Moon@SCRC-TENEX Is log(-1) an error if -1 is real, but i*pi if -1 is -1+0*i and "log" means principal value? Previously I expressed my concern that language designers should not build in to the language ithmetic semantics or pragmatics that are controversial (or downright wrong: I recall Basic has the result of an overflow be 0). I wish you luck.