Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 20 May 87 14:37:46 EDT Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 20 May 87 11:23:06 PDT Received: from xavier by Think.COM via CHAOS; Wed, 20 May 87 14:24:21 EDT Date: Wed, 20 May 87 14:21 EDT From: Barry Margolin Subject: DISASSEMBLE, et all return values To: John Williams Cc: common-lisp@sail.stanford.edu In-Reply-To: <5464.8705201735@cvaxa.sussex.ac.uk> Message-Id: <870520142124.6.BARMAR@XAVIER.THINK.COM> Date: Wed, 20 May 87 17:35:43 gmt From: John Williams Am I right in thinking that Cltl does not specify the result(s) returned by the following functions: DISASSEMBLE DRIBBLE ED INSPECT PROCLAIM ROOM It doesn't specify return values in my copy of the book. That means that a portable program should not do anything with the values of these functions. As far as CLtL is concerned, they are only useful for their side-effects. barmar  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 20 May 87 13:55:41 EDT Received: from BFLY-VAX.BBN.COM by SAIL.STANFORD.EDU with TCP; 20 May 87 10:39:36 PDT To: common-lisp@sail.stanford.edu Date: 20 May 87 13:41:08 EDT (Wed) From: las@bfly-vax.bbn.com Regarding Roman numerals: Having recently visited Roman-numeral land, I too was curious about implementations that did not print Romam numerals above 3999 (new) or 4999 (old). Not recalling the entirety of my elementary school education, I consulted the Table of Numbers in Webster's Ninth New Collegiate Dictionary (page 812). Roman numerals above 1000 are written with "bars" above them. These have no ascii equivalent. Use of lower case is equivalent to the upper case use. Below, a hyphen following a letter is to be interpreted as a bar above it. The numerals above 1000 are: 5,000 V- 10,000 X- 100,000 C- 1,000,000 M- The question is: after the year 4999, how will Common Lisp print film copyright dates? - Larry Stabile  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 20 May 87 13:30:03 EDT Received: from [14.0.0.9] by SAIL.STANFORD.EDU with TCP; 20 May 87 10:13:14 PDT Received: from cvaxa.sussex.ac.uk by mv1.Cs.Ucl.AC.UK via Janet with NIFTP id aa09225; 20 May 87 18:07 BST From: John Williams Date: Wed, 20 May 87 17:35:43 gmt Message-Id: <5464.8705201735@cvaxa.sussex.ac.uk> To: common-lisp@sail.stanford.edu Am I right in thinking that Cltl does not specify the result(s) returned by the following functions: DISASSEMBLE DRIBBLE ED INSPECT PROCLAIM ROOM  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 20 May 87 13:09:25 EDT Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 20 May 87 09:55:48 PDT Received: from relay2.cs.net by RELAY.CS.NET id ad00189; 20 May 87 12:25 EDT Received: from ti-csl by RELAY.CS.NET id ad24696; 20 May 87 12:01 EDT Received: by tilde id AA16282; Wed, 20 May 87 08:54:45 CDT Message-Id: <2757506096-3811281@Jenner> Date: Wed, 20 May 87 08:54:56 CDT From: Patrick H Dussud To: dg%acorn@LIVE-OAK.LCS.MIT.EDU, "Daniel L. Cerys" Cc: common-lisp@SAIL.STANFORD.EDU, Acuff@SUMEX-AIM.STANFORD.EDU Subject: [dg%acorn@oak.lcs.mit.edu: Re: &REST] In-Reply-To: Msg of Tue, 19 May 87 09:58:50 EDT from "Daniel L. Cerys" Date: Sun, 17 May 87 17:56 est From: dg%acorn@oak.lcs.mit.edu Subject: Re: &REST To: Acuff@SUMEX-AIM.STANFORD.EDU Cc: common-lisp@SAIL.STANFORD.EDU Date: Fri, 15 May 87 14:01:46 PDT From: Richard Acuff For the record, in Release 3, TI has attempted, with apparent success, to remove the restrictions on using &REST lists outside of the dynamic scope of the parameter. (While increasing the performance of the system, to boot.) -- Rich ------- Are there exactly 0 restrictions now? Does this mean that removing the restrictions actually improved the performance of the system, or was that just coincidental? -dg There are 0 restrictions on using &REST lists outside of the dynamic scope of the parameter. The way we do it is the following: We have a new datatype for &rest args (A list on the stack). When somebody tries to store a pointer of type stack-list, the microcode triggers a copy. The copy process is recursive if the &rest args are nested. The copy is done is such a way that it preserves EQness. Since the data type check is hardware assisted, it is done without performance penalty. The performance improvement is coincidental. Patrick.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 20 May 87 12:15:13 EDT Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 20 May 87 08:59:32 PDT Received: ID ; Wed 20 May 87 11:51:45-EDT Date: Wed, 20 May 1987 11:51 EDT Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: "David C. Plummer" Cc: common-lisp@SAIL.STANFORD.EDU Subject: All arrays can be adjustable? In-reply-to: Msg of 20 May 1987 09:37-EDT from David C. Plummer Maybe if we could figure out how to express the various types of arrays using set language we wouldn't accidentally invert phrases. For example, I think everybody agrees that simple is a subset of (intersect not-adjustable not-fill-pointer not-displaced) That's the >only< thing that phrase says. It can't be inverted, conversed, contra-positived, or anything to say that simple arrays are not adjustable. The contra-positive (the only thing provably true) is that the UNION of adjustable, fill-pointered or displaced arrays is a subset of non-simple arrays. Gee, it's been a while since I hacked formal logic in any serious way, but it seems to be true that if X is a subset of the intersection of A, B, C, and D, then X is (provably) a subset of A. I cheated and used little pictures instead of contrapositives (my religion forbids the use of contrapositives, even among consenting adults), but I think it's still true. Maybe I should go audit a logic course and see what I'm doing wrong. -- Scott  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 20 May 87 12:10:25 EDT Received: from UCBARPA.Berkeley.EDU by SAIL.STANFORD.EDU with TCP; 20 May 87 08:51:39 PDT Received: by ucbarpa.Berkeley.EDU (5.57/1.25) id AA29057; Wed, 20 May 87 08:51:38 PDT Received: from ficl by franz (5.5/3.14) id AA20347; Wed, 20 May 87 08:20:10 PDT Received: by ficl (5.5/3.14) id AA16895; Wed, 20 May 87 08:20:04 PDT From: franz!ficl!jkf@ucbarpa.Berkeley.EDU (John Foderaro) Return-Path: Message-Id: <8705201520.AA16895@ficl> To: common-lisp@sail.stanford.edu Subject: adjustable arrays Date: Wed, 20 May 87 08:20:02 PDT To give another data point to the discussion: in our lisp (Extended Common Lisp) we have a variety of internal array implementations to satisify the various combinations of array features the user might select. I expect most other implemenations do likewise. Many of these internal implementations are adjustable however our lisp will refuse to adjust any array not explictly specified as adjustable by the user. Since we're going to extra work to refuse to do something that we could easily do, there should be a good reason for it, and in our case that reason is portabilty. If a user wants needs an adjustable array and doesn't specify it, then he'll find out right away instead of when he ports his code to another lisp. I don't feel that returning a adjustable array when the user doesn't ask for one 'is an error'. When you call 'make-array' you ask for the minimum set of features you need and the system returns the best thing it can. Implementations should be encouraged to return the best match to the user's request, thus if the user doesn't ask for an adjustable array, then returning an non-adjustable array is better than returning an adjustable one, but both are valid. - John Foderaro Franz Inc.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 20 May 87 11:55:47 EDT Received: from [192.10.41.109] by SAIL.STANFORD.EDU with TCP; 20 May 87 08:41:23 PDT Received: from CHICOPEE.SCRC.Symbolics.COM by ALDERAAN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 83482; Wed 20-May-87 11:31:34 EDT Date: Wed, 20 May 87 11:31 EDT From: Daniel L. Weinreb Subject: All arrays can be adjustable? To: Cyphers@YUKON.SCRC.Symbolics.COM cc: common-lisp@sail.stanford.edu In-Reply-To: <870519221837.3.CYPHERS@RAVEN.S4CC.Symbolics.COM> Message-ID: <870520113117.4.DLW@CHICOPEE.SCRC.Symbolics.COM> Date: Tue, 19 May 87 22:18 EDT From: Scott Cyphers Date: Tue, 19 May 87 21:34 EDT From: David A. Moon Date: Tue, 19 May 87 19:03:33 MDT From: sandra%orion@cs.utah.edu (Sandra J Loosemore) It's definitely wrong for make-array to randomly return adjustable arrays when the user doesn't specifically ask for them. I disagree. See below. I mopstly agree with you, but the bottom of page 28 seems to imply that you can make arrays which are not to be adjusted, and this is one of the properties of simple arrays. "and is not to have its size adjusted" is just another ambiguous phrase. I read this to mean "and its caller is not allowed to assume that it would work to adjust its size"; that is, it makes no promises that adjusting the size would work. There is no question what the intention of the writers of CLtL was. The idea of "simple" arrays was to provide a way for stock hardware implementations to implement simpler arrays more cheaply, without making any impositions on architectures in which there's no extra cost for more complex arrays. The wording in CLtL was intended to convey this idea, but apparently it falls short. Yes, it might be useful to have a feature that provides for an array that is guaranteed to signal an error if there is an attempt to adjust it. However, CL has no such feature, and I think it's only slightly useful. Arrays have enough features as it is; you have to draw the line somewhere.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 20 May 87 11:48:44 EDT Received: from [192.10.41.109] by SAIL.STANFORD.EDU with TCP; 20 May 87 08:36:23 PDT Received: from CHICOPEE.SCRC.Symbolics.COM by ALDERAAN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 83485; Wed 20-May-87 11:35:51 EDT Date: Wed, 20 May 87 11:35 EDT From: Daniel L. Weinreb Subject: Re: More FORMAT To: Daniels.pa@Xerox.COM, berman@vaxa.isi.edu cc: common-lisp@sail.stanford.edu In-Reply-To: <870519-161039-1087@Xerox> Message-ID: <870520113503.5.DLW@CHICOPEE.SCRC.Symbolics.COM> Line-fold: No Date: 19 May 87 16:10 PDT From: Daniels.pa@Xerox.COM Indeed, CLtL p. 296 explicitly states that if the fill pointer gets too large and the vector is not adjustable, an error should be signalled. However, it does not state that (make-array 5) produces an array that it not adjustable. No implementation is required to support explicitly non-adjustable arrays. It's too bad that CLtL is so unclear about this. But, for example, if you look at the documentation of :adjustable on p. 288, note the use of the word "must": this is trying to say that :adjustable t means that it "must" be adjustable, whereas :adjustable nil means that it need not be adjustable, although it can be.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 20 May 87 09:45:05 EDT Received: from [128.81.51.3] by SAIL.STANFORD.EDU with TCP; 20 May 87 06:35:41 PDT Received: from KOYAANISQATSI.S4CC.Symbolics.COM by DIAMOND.S4CC.Symbolics.COM via CHAOS with CHAOS-MAIL id 88382; Wed 20-May-87 09:33:14 EDT Date: Wed, 20 May 87 09:37 EDT From: David C. Plummer Subject: All arrays can be adjustable? To: Sandra J Loosemore , David A. Moon , David L. Andre , Scott Cyphers , Kent M Pitman , common-lisp@sail.stanford.edu In-Reply-To: <8705200103.AA04735@orion.utah.edu>, <870519213421.9.MOON@EUPHRATES.SCRC.Symbolics.COM>, <870519222134.7.DLA@LIMPKIN.S4CC.Symbolics.COM>, <870519221837.3.CYPHERS@RAVEN.S4CC.Symbolics.COM>, <870520024109.4.KMP@TSUKUBA.SCRC.Symbolics.COM> Message-ID: <870520093735.8.DCP@KOYAANISQATSI.S4CC.Symbolics.COM> Maybe if we could figure out how to express the various types of arrays using set language we wouldn't accidentally invert phrases. For example, I think everybody agrees that simple is a subset of (intersect not-adjustable not-fill-pointer not-displaced) That's the >only< thing that phrase says. It can't be inverted, conversed, contra-positived, or anything to say that simple arrays are not adjustable. The contra-positive (the only thing provably true) is that the UNION of adjustable, fill-pointered or displaced arrays is a subset of non-simple arrays.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 20 May 87 05:57:57 EDT Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 20 May 87 02:48:00 PDT Received: from LIVE-OAK.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 20 May 87 05:46-EDT Received: from PALLADIAN-JASPER.DialNet.Symbolics.COM by MIT-LIVE-OAK.ARPA via DIAL with SMTP id 43464; 20 May 87 05:42:35-EDT Received: from WHITBY.Palladian.COM by JASPER.Palladian.COM via INTERNET with SMTP id 1; 20 May 87 01:29:56-EDT Date: Wed, 20 May 87 01:01 EDT From: Don Morrison Subject: Re: More FORMAT To: berman@vaxa.isi.edu cc: Moon@stony-brook.scrc.symbolics.com, common-lisp@sail.stanford.edu In-Reply-To: <8705192222.AA05902@vaxa.isi.edu> Message-ID: <870520010156.3.DFM@WHITBY.PALLADIAN.COM> Reply-To: Don Morrison Date: Tue, 19 May 87 15:22:17 PDT From: Richard Berman I hope there is a way to have guaranteed non-adjustable arrays! Why? Is there any thing that non-adjustable arrays are good for the adjustable arrays are not? I thought it was just that you paid a performance hit for adjustability in some (typically non-special-microcode) implementations.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 20 May 87 02:54:19 EDT Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 19 May 87 23:42:25 PDT Received: from TSUKUBA.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 144502; Wed 20-May-87 02:41:11 EDT Date: Wed, 20 May 87 02:41 EDT From: Kent M Pitman Subject: adjustable arrays To: Moon@STONY-BROOK.SCRC.Symbolics.COM, sandra%orion@cs.utah.edu cc: common-lisp@sail.stanford.edu, kmp@STONY-BROOK.SCRC.Symbolics.COM In-Reply-To: <870519213421.9.MOON@EUPHRATES.SCRC.Symbolics.COM> Message-ID: <870520024109.4.KMP@TSUKUBA.SCRC.Symbolics.COM> I think you are both expressing reasonable and relatively coherent views of the world. The real problem is that CLtL is not explicit enough to distinguish between the two cases. It has insufficient concept exposition about adjustable arrays to clearly indicate the intent of the authors about what properties were intentional and which were accidental. Consequently, people made up their own concepts. The problem with incomplete specs like this is that there are multiple extrapolations which are compatible with the base spec, and those extrapolations are not necessarily compatible with each other. This result acts as a real barrier to portability at times. I can relate to Moon's claims because I use the lispm a lot and believe it to be an internally consistent correct reading of CLtL in this area. On the other hand, it's not what I had expected from reading the CL manual. As such, I know first hand that other people can have internally consistent but differing readings. I also know first hand that it's a pain to port code between dialects with conflicting views because it's hard to test the code in one implementation and have any confidence that it will run in the other. Whether we decide on the conservative reading that Sandra and others have pushed or the less conservative reading that Moon asserts was intended, the important thing is that the manual say clearly what will happen so that users can simply read the book and know what to expect with no need to do lengthy deductions about the consequences of what they have or have not read. I think the issues are clearly understood and little more is to be gained by prolonged debate at this time. A process (X3J13) exists for introducing changes/corrections to CLtL and I think that process should now be asked to do its job by addressing that issue.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 19 May 87 23:22:03 EDT Received: from [128.81.51.3] by SAIL.STANFORD.EDU with TCP; 19 May 87 19:59:54 PDT Received: from RAVEN.S4CC.Symbolics.COM by DIAMOND.S4CC.Symbolics.COM via CHAOS with CHAOS-MAIL id 88320; Tue 19-May-87 22:18:43 EDT Date: Tue, 19 May 87 22:18 EDT From: Scott Cyphers Subject: All arrays can be adjustable? To: Moon@STONY-BROOK.SCRC.Symbolics.COM, sandra%orion@cs.utah.edu cc: common-lisp@sail.stanford.edu In-Reply-To: <870519213421.9.MOON@EUPHRATES.SCRC.Symbolics.COM> Message-ID: <870519221837.3.CYPHERS@RAVEN.S4CC.Symbolics.COM> Date: Tue, 19 May 87 21:34 EDT From: David A. Moon Date: Tue, 19 May 87 19:03:33 MDT From: sandra%orion@cs.utah.edu (Sandra J Loosemore) It's definitely wrong for make-array to randomly return adjustable arrays when the user doesn't specifically ask for them. I disagree. See below. I mopstly agree with you, but the bottom of page 28 seems to imply that you can make arrays which are not to be adjusted, and this is one of the properties of simple arrays. One use of a non-adjustable array might be when you know that the array is big enough for your program, and if something which automatically adjusts adjustable arrays tries to adjust your array to make it bigger, that means your program is broken somehow. Rather than letting the array get grown until you run out of address space to discover this error, it would be desirable to get an error when the array tried to get bigger than the size you originally limited it to. Why something like this is tied up in the concept of "simple" arrays I don't know; it seems that an array which is able to provide this service may be less simple to implement in some implementations. Maybe the concept of "simple" is what is bogus?  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 19 May 87 23:20:26 EDT Received: from [128.81.51.3] by SAIL.STANFORD.EDU with TCP; 19 May 87 19:59:51 PDT Received: from LIMPKIN.S4CC.Symbolics.COM by DIAMOND.S4CC.Symbolics.COM via CHAOS with CHAOS-MAIL id 88321; Tue 19-May-87 22:21:35 EDT Date: Tue, 19 May 87 22:21 EDT From: David L. Andre Subject: All arrays can be adjustable? To: sandra%orion@cs.utah.edu cc: common-lisp@sail.stanford.edu, DLA@DIAMOND.S4CC.Symbolics.COM In-Reply-To: <8705200103.AA04735@orion.utah.edu> Message-ID: <870519222134.7.DLA@LIMPKIN.S4CC.Symbolics.COM> Date: Tue, 19 May 87 19:03:33 MDT From: sandra%orion@cs.utah.edu (Sandra J Loosemore) It's definitely wrong for make-array to randomly return adjustable arrays when the user doesn't specifically ask for them. I don't think the issue is whether or not users can tell whether arrays are simple or adjustable. The issue is what action CL primitives should take with respect to extending arrays, if that would be a plausible option of their contract.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 19 May 87 21:53:09 EDT Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 19 May 87 18:35:07 PDT Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 144366; Tue 19-May-87 21:34:22 EDT Date: Tue, 19 May 87 21:34 EDT From: David A. Moon Subject: All arrays can be adjustable? To: Sandra J Loosemore cc: common-lisp@sail.stanford.edu In-Reply-To: <8705200103.AA04735@orion.utah.edu> Message-ID: <870519213421.9.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Tue, 19 May 87 19:03:33 MDT From: sandra%orion@cs.utah.edu (Sandra J Loosemore) It's definitely wrong for make-array to randomly return adjustable arrays when the user doesn't specifically ask for them. I disagree. See below. From page 289: "If make-array is called with the :adjustable, :fill-pointer, and :displaced-to arguments all either unspecified or nil, then the resulting array is guaranteed to be a simple array." This actually sounds like a good problem for the cleanup committee to address. As I see it, a correct implementation needs to do two things: (1) Ensure that things like svref work correctly on things that are supposed to be simple arrays: (svref (make-array 3 :initial-element 'foo) 0) Of course. (2) Ensure that user programs can distinguish arrays that are supposed to be simple arrays from those that are not, regardless of whether or not simple arrays use the same internal representation as non-simple arrays. I don't see anything in CLtL that requires this. It seems like a bad idea, because it would require all implementations to be more complex without giving any benefit to the user. The concept of simple arrays exists because in some implementations they can be more efficient than full arrays, not because people have a need to write application programs that use simple arrays. Simple arrays don't give any extra expressive power. I do agree that this problem is similar to whether or not the implementation has specialized representations for arrays that can only contain a specified element type. However, this issue has the same semantic problems as above. Would you like to get a general vector back when you're expecting a simple string? Especially if it doesn't even print like a string? If you think about it for a moment I think you'll realize how false this analogy is. No one is proposing to change how anything prints, or indeed to do anything other than not enforce a restriction. The distinction between strings and general vectors is quite different from the distinction between simple arrays and full arrays. I believe Margolin's original analogy was a different one, referring to the lack of semantic problems when you ask for an array that can only hold integers and get an array that can hold anything.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 19 May 87 21:20:20 EDT Received: from CS.UTAH.EDU by SAIL.STANFORD.EDU with TCP; 19 May 87 18:02:29 PDT Received: by cs.utah.edu (5.54/utah-1.0) id AA12308; Tue, 19 May 87 19:03:37 MDT Received: by orion.utah.edu (5.54/utah-1.0-slave) id AA04735; Tue, 19 May 87 19:03:33 MDT Date: Tue, 19 May 87 19:03:33 MDT From: sandra%orion@cs.utah.edu (Sandra J Loosemore) Message-Id: <8705200103.AA04735@orion.utah.edu> Subject: All arrays can be adjustable? To: common-lisp@sail.stanford.edu From: barmar@Think.COM (Barry Margolin) Date: 19 May 87 23:07:00 GMT Date: Tue, 19 May 87 15:22:17 PDT From: Richard Berman I hope there is a way to have guaranteed non-adjustable arrays! Some systems (Maclisp, for example!) don't have non-adjustable arrays. The way to think of these things is as hints or declarations. Telling the system that you only plan on storing integers or that you don't plan on adjusting the array allows it to choose an optimal array format. If a particular implementation chooses not to perform a particular optimization it doesn't affect the semantics. barmar It's definitely wrong for make-array to randomly return adjustable arrays when the user doesn't specifically ask for them. From page 289: "If make-array is called with the :adjustable, :fill-pointer, and :displaced-to arguments all either unspecified or nil, then the resulting array is guaranteed to be a simple array." This actually sounds like a good problem for the cleanup committee to address. As I see it, a correct implementation needs to do two things: (1) Ensure that things like svref work correctly on things that are supposed to be simple arrays: (svref (make-array 3 :initial-element 'foo) 0) (2) Ensure that user programs can distinguish arrays that are supposed to be simple arrays from those that are not, regardless of whether or not simple arrays use the same internal representation as non-simple arrays. (simple-vector-p (make-array 3 :initial-element 'foo)) => true (simple-vector-p (make-array 3 :adjustable t)) => false I do agree that this problem is similar to whether or not the implementation has specialized representations for arrays that can only contain a specified element type. However, this issue has the same semantic problems as above. Would you like to get a general vector back when you're expecting a simple string? Especially if it doesn't even print like a string? -Sandra -------  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 19 May 87 19:33:09 EDT Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 19 May 87 16:18:41 PDT Received: from Cabernet.ms by ArpaGateway.ms ; 19 MAY 87 16:10:39 PDT Date: 19 May 87 16:10 PDT From: Daniels.pa@Xerox.COM Subject: Re: More FORMAT In-reply-to: Richard Berman 's message of Tue, 19 May 87 13:47:25 PDT To: berman@vaxa.isi.edu cc: common-lisp@sail.stanford.edu Message-ID: <870519-161039-1087@Xerox> I believe that all format directives not covered by the standard should be "is an error." This includes providing incorrect arguments to the format directives as well as using undefined format directives. Implementations are then free to ignore the colon in "~:%", signal an error, or even provide an extension that gives this a meaning. In the latter case, it would be nice if there were a mode that does flag nonstandard usages. ~@R and ~:@R are abominations, but if we have to have them, I agree that the standard should specify what ranges of numbers are covered by these directives. Cleanup committe: has anyone looked into this? I can not find any reference that indicates a string may be used as a stream. The nearest thing is on page 331, WITH-OUTPUT-TO-STRING. This appears to exactly describe the behavior described above (as if the following transformation had occured) (with-output-to-string (foo x) (format foo "test")) However, I don't find anything in FORMAT which says this is expected or allowed. Of course, (STREAMP X) => NIL. CLtL p. 386: "If destination is a string with a fill pointer, then in effect the output characters are added to the end of the string (as if by use of VECTOR-PUSH-EXTEND)." So the implementation in question was correct in appending the formatted output to the string. One of these implementations even violates this further, by extending X if it goes beyond 10 characters. I can find absolutely nothing to allow this, as it is not :adjustable. In fact, every possible justifying reference to allowing the above FORMAT would still cause an error (or would just ignore) in the case of over extension. Indeed, CLtL p. 296 explicitly states that if the fill pointer gets too large and the vector is not adjustable, an error should be signalled.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 19 May 87 19:23:55 EDT Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 19 May 87 16:08:01 PDT Received: from ueberweg by Think.COM via CHAOS; Tue, 19 May 87 19:09:55 EDT Date: Tue, 19 May 87 19:07 EDT From: Barry Margolin Subject: Re: More FORMAT To: Richard Berman Cc: David A. Moon , common-lisp@sail.stanford.edu In-Reply-To: <8705192222.AA05902@vaxa.isi.edu> Message-Id: <870519190744.8.BARMAR@UEBERWEG.THINK.COM> Date: Tue, 19 May 87 15:22:17 PDT From: Richard Berman Thanks for the ref: on page 386. As for some implementations defaulting to adjustable arrays, page 288 says, of the :adjustable keyword in make-array, "...if specified and not nil, indicates that it must be possible to alter the array's size dynamically after it is created. This argument defaults to nil." Granted, this does not say that a value of nil prohibits adjustability, but only that it must be adjustable if given non-nil. Do you interpret this as meaning "nil value *may* indicate it is possible to alter ...."? :adjustable T means "I plan on adjusting this array, so make sure it is adjustable." :adjustable NIL means "I don't plan on adjusting this array, so don't go out of your way to make it adjustable." The response to the latter on some systems is, "oh, it's no trouble." I hope there is a way to have guaranteed non-adjustable arrays! Some systems (Maclisp, for example!) don't have non-adjustable arrays. This is no different from the element type. If you specify :element-type 'integer you are requiring Lisp to create an array that can at least hold integers. It doesn't prohibit it from creating an array that can hold other things, too. The way to think of these things is as hints or declarations. Telling the system that you only plan on storing integers or that you don't plan on adjusting the array allows it to choose an optimal array format. If a particular implementation chooses not to perform a particular optimization it doesn't affect the semantics. barmar  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 19 May 87 18:36:47 EDT Received: from VAXA.ISI.EDU by SAIL.STANFORD.EDU with TCP; 19 May 87 15:23:59 PDT Posted-Date: Tue, 19 May 87 15:22:17 PDT Message-Id: <8705192222.AA05902@vaxa.isi.edu> Received: from LOCALHOST by vaxa.isi.edu (5.54/5.51) id AA05902; Tue, 19 May 87 15:22:29 PDT To: "David A. Moon" Cc: Richard Berman , common-lisp@sail.stanford.edu Subject: Re: More FORMAT In-Reply-To: Your message of Tue, 19 May 87 17:46:00 -0400. <870519174622.9.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Tue, 19 May 87 15:22:17 PDT From: Richard Berman Thanks for the ref: on page 386. As for some implementations defaulting to adjustable arrays, page 288 says, of the :adjustable keyword in make-array, "...if specified and not nil, indicates that it must be possible to alter the array's size dynamically after it is created. This argument defaults to nil." Granted, this does not say that a value of nil prohibits adjustability, but only that it must be adjustable if given non-nil. Do you interpret this as meaning "nil value *may* indicate it is possible to alter ...."? I hope there is a way to have guaranteed non-adjustable arrays! RB  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 19 May 87 18:25:46 EDT Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 19 May 87 15:11:29 PDT Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 144146; Tue 19-May-87 17:46:18 EDT Date: Tue, 19 May 87 17:46 EDT From: David A. Moon Subject: More FORMAT To: Richard Berman cc: common-lisp@sail.stanford.edu In-Reply-To: <8705192047.AA04062@vaxa.isi.edu> Message-ID: <870519174622.9.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Tue, 19 May 87 13:47:25 PDT From: Richard Berman .... (setq x (make-array 10 :element-type 'string-char :fill-pointer 0)) (format x "test") X => "test" I can not find any reference that indicates a string may be used as a stream. Look harder, it's right at the top of page 386. It's not being used as a stream, it's being used as a format destination. One of these implementations even violates this further, by extending X if it goes beyond 10 characters. I can find absolutely nothing to allow this, as it is not :adjustable. In some implementations all arrays are adjustable even if you didn't explicitly ask for an adjustable array in make-array.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 19 May 87 17:09:57 EDT Received: from VAXA.ISI.EDU by SAIL.STANFORD.EDU with TCP; 19 May 87 13:47:40 PDT Posted-Date: Tue, 19 May 87 13:47:25 PDT Message-Id: <8705192047.AA04062@vaxa.isi.edu> Received: from LOCALHOST by vaxa.isi.edu (5.54/5.51) id AA04062; Tue, 19 May 87 13:47:27 PDT To: common-lisp@sail.stanford.edu Subject: More FORMAT Date: Tue, 19 May 87 13:47:25 PDT From: Richard Berman Oh yeah, and what about using non-defined flags, like so: (FORMAT NIL "~:%") Ignore? Error? I am testing a couple implementations which handle such things differently (one implementation generaly ignores things which were not defined specifically in CLtL, the other always signals an error for such things.) MORE HAIR SPLITTING: Page 389, CLtL: as regards ~:@R, what if the arg is zero? There is no old roman for this. One implementation just prints 0, the other signals an error! Another case: ~:@R again. Given an argument above 3999, the "forgiving" implementation just prints it as a decimal integer. The "unforgiving" implimentation causes an error. Is this 'cuz the old romans didn't count pas 3999 or somethin'? The above is also true for ~@R. Now, for ~:R... Is there an authoritative source on how one spells the zero ordinance? Is it "ZEROTH" or "ZEROETH". These implementation give different results. ----------------------------- A related subject. Both these implementations accept the following: (setq x (make-array 10 :element-type 'string-char :fill-pointer 0)) (format x "test") X => "test" I can not find any reference that indicates a string may be used as a stream. The nearest thing is on page 331, WITH-OUTPUT-TO-STRING. This appears to exactly describe the behavior described above (as if the following transformation had occured) (with-output-to-string (foo x) (format foo "test")) However, I don't find anything in FORMAT which says this is expected or allowed. Of course, (STREAMP X) => NIL. One of these implementations even violates this further, by extending X if it goes beyond 10 characters. I can find absolutely nothing to allow this, as it is not :adjustable. In fact, every possible justifying reference to allowing the above FORMAT would still cause an error (or would just ignore) in the case of over extension. HELP! RB  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 19 May 87 15:33:59 EDT Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 19 May 87 12:20:33 PDT Received: ID ; Tue 19 May 87 15:19:54-EDT Date: Tue, 19 May 1987 15:19 EDT Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: Richard Berman Cc: common-lisp@SAIL.STANFORD.EDU Subject: ~% Directive In-reply-to: Msg of 19 May 1987 14:38-EDT from Richard Berman do you know what this should do? (FORMAT NIL "~-1%") Two choices: 1. "It is an error." 2. "Crank up the monitor's voltage and send a lethal blast of X-rays into the face of the person issuing such a silly command." Since not all machines can support solution 2, we should probably go with 1, even though 2 is the more elegant and long-lasting solution. But seriously, there seem to be a number of places in the format directives where negative numbers would make no sense. I don't think that all of these are explicitly flagged. This should probably be fixed up in the standard, but until then it seems reasonable to assume non-negative integers unless there's some obvious meaning for the negative case. -- Scott  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 19 May 87 14:52:19 EDT Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 19 May 87 11:36:16 PDT Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 143821; Tue 19-May-87 14:34:22 EDT Date: Tue, 19 May 87 14:34 EDT From: David A. Moon Subject: User-Visible Declarations and Proclamations To: MURRAY%cs.umass.edu@RELAY.CS.NET cc: common-lisp@SAIL.STANFORD.EDU In-Reply-To: The message of 18 May 87 12:04 EDT from MURRAY%cs.umass.edu@RELAY.CS.NET Message-ID: <870519143423.5.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Mon, 18 May 87 12:04 EDT From: MURRAY%cs.umass.edu@RELAY.CS.NET .... Since the code now works on both sequences and lists, it must test at run-time what kind of argument it has (similiar to the MAP-INTO code). This could be avoided if the type was declared to be a list or vector. I would like to solicit discussion on the possibility of providing one or more functions or variables in Common Lisp to provide information about any declarations or proclaimations that are in effect. Previous mail by a number of people has indicated a desire to be able to determine whether a variable has been proclaimed special (e.g. DEFVAR). This is another example of the general problem. For type declarations, something like (DECLARED-RESULT-TYPE Form) --> Type would allow macro-expanders to possibly generate much more efficient code. I imagine all systems with a compiler have this kind of a function in one form or another. A system could always just return T. What about defining the global variables *speed*, *safety*, and *compiler-speed* to be bound to their proclaimed values? Another possibility is to have one general function that takes as arguments what kind of information is requested. This sort of thing would probably be useful, although I think it's clear that it needs to be thought out a lot more carefully before standardizing on anything. However, I don't think you need it for your particular application. Just expand into a TYPECASE and rely on the compiler to constant-fold it if the type tests have known results due to declarations. Perhaps not all compilers do this optimization, but it's a reasonable optimization to expect.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 19 May 87 14:51:26 EDT Received: from VAXA.ISI.EDU by SAIL.STANFORD.EDU with TCP; 19 May 87 11:39:16 PDT Posted-Date: Tue, 19 May 87 11:38:22 PDT Message-Id: <8705191838.AA02897@vaxa.isi.edu> Received: from LOCALHOST by vaxa.isi.edu (5.54/5.51) id AA02897; Tue, 19 May 87 11:38:54 PDT To: common-lisp@sail.stanford.edu Subject: ~% Directive Date: Tue, 19 May 87 11:38:22 PDT From: Richard Berman Hi again. do you know what this should do? (FORMAT NIL "~-1%") CLtL pg 397 says "This outputs a #\Newline character, thereby terminating the current output line and beginning a new one (see TERPRI). ~n% outputs n newlines. No arg is used..." No mention of <1 values being ignored, errors, etc. Which is it? Eh? RB  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 19 May 87 01:35:49 EDT Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 18 May 87 22:22:45 PDT Received: from relay2.cs.net by RELAY.CS.NET id ae11645; 19 May 87 1:17 EDT Received: from cs.umass.edu by RELAY.CS.NET id ao13616; 19 May 87 1:11 EDT Date: Mon, 18 May 87 12:04 EDT From: MURRAY%cs.umass.edu@RELAY.CS.NET Subject: User-Visible Declarations and Proclamations To: common-lisp@SAIL.STANFORD.EDU X-VMS-To: CLMAIL Because of all the interest in the Maps, I've rewritten Dan Corkill's original code to handle sequences as well as lists (as well as other changes). The code is now available (I'm sending it out via Netmail), and Dan should have a paper on the Maps finished up real soon now. Since the code now works on both sequences and lists, it must test at run-time what kind of argument it has (similiar to the MAP-INTO code). This could be avoided if the type was declared to be a list or vector. I would like to solicit discussion on the possibility of providing one or more functions or variables in Common Lisp to provide information about any declarations or proclaimations that are in effect. Previous mail by a number of people has indicated a desire to be able to determine whether a variable has been proclaimed special (e.g. DEFVAR). This is another example of the general problem. For type declarations, something like (DECLARED-RESULT-TYPE Form) --> Type would allow macro-expanders to possibly generate much more efficient code. I imagine all systems with a compiler have this kind of a function in one form or another. A system could always just return T. What about defining the global variables *speed*, *safety*, and *compiler-speed* to be bound to their proclaimed values? Another possibility is to have one general function that takes as arguments what kind of information is requested. - Kelly Murray University of Massachusetts  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 18 May 87 20:51:48 EDT Received: from MIT-MULTICS.ARPA by SAIL.STANFORD.EDU with TCP; 18 May 87 17:36:13 PDT Acknowledge-To: Olasov@MIT-Multics.ARPA Date: Mon, 18 May 87 20:22 EDT From: Olasov@MIT-Multics.ARPA Subject: Communications packages in Common LISP To: common-lisp@SAIL.STANFORD.EDU Message-ID: <870519002252.487741@MIT-Multics.ARPA> Hello, Does anyone know of communications programs written in Common LISP for IBM 80286 type machines that can perform not only the usual modem software functions, i.e. dialing, receiving files, sending files, answering, etc. but which also allow the user to develop routines for processing character streams from the foreign host, and responding to them according to user specified directives? Alternatively, is anyone developing such applications? In either case, I'd be very interested to hear about these applications. Thanks, Ben Olasov  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 18 May 87 20:33:03 EDT Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 18 May 87 17:19:32 PDT Received: from xavier by Think.COM via CHAOS; Mon, 18 May 87 20:21:49 EDT Date: Mon, 18 May 87 20:18 EDT From: Barry Margolin Subject: Format To: Richard Berman Cc: common-lisp@sail.stanford.edu In-Reply-To: <8705182246.AA12230@vaxa.isi.edu> Message-Id: <870518201858.7.BARMAR@XAVIER.THINK.COM> Date: Mon, 18 May 87 15:46:42 PDT From: Richard Berman What should this do: (FORMAT () "~E" 3/4) I have one implementation that produces "0.75" and another that produces "7.5E-1". As far as I can detect, the latter MAY be correct. CLtL says, on page 393 about the ~E directive, "If all of [the parameters] are omitted, then the effect is to print the value using ordinary free-format exponential-notation output; prin1 uses this format for any non-zero number whose magnitude is less than 10^-3 or greater than or equal to 10^7. "If arg is a rational number, then it is coerced to be a single-float and then printed." It is unclear whether: (a) the same format used by prin1 for numbers in the given range should be used regardless of the range of the arg, or (b) if it should print like prin1. To me, that sentence strictly says that PRIN1 may contain code like the following: (when (and (not (= number 0.0)) (or (< number 1.0e-3) (>= number 1.0e7))) (format stream "~E" number)) which I guess corresponds to your (a). Whether that is what was intended is a different story.... barmar  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 18 May 87 19:01:39 EDT Received: from VAXA.ISI.EDU by SAIL.STANFORD.EDU with TCP; 18 May 87 15:46:52 PDT Posted-Date: Mon, 18 May 87 15:46:42 PDT Message-Id: <8705182246.AA12230@vaxa.isi.edu> Received: from LOCALHOST by vaxa.isi.edu (5.54/5.51) id AA12230; Mon, 18 May 87 15:46:45 PDT To: common-lisp@sail.stanford.edu Subject: Format Date: Mon, 18 May 87 15:46:42 PDT From: Richard Berman What should this do: (FORMAT () "~E" 3/4) I have one implementation that produces "0.75" and another that produces "7.5E-1". As far as I can detect, the latter MAY be correct. CLtL says, on page 393 about the ~E directive, "If all of [the parameters] are omitted, then the effect is to print the value using ordinary free-format exponential-notation output; prin1 uses this format for any non-zero number whose magnitude is less than 10^-3 or greater than or equal to 10^7. "If arg is a rational number, then it is coerced to be a single-float and then printed." It is unclear whether: (a) the same format used by prin1 for numbers in the given range should be used regardless of the range of the arg, or (b) if it should print like prin1. It seems the former interpretation may be correct, as it clearly states that the format used is used by prin1 "for any non-zero number whose magnitude...", and it is the *format* we are talking about, not "what prin1" does. I would like clarification of this point. Thanks in advance. RB  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 18 May 87 15:39:47 EDT Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 18 May 87 11:58:10 PDT Received: from relay2.cs.net by RELAY.CS.NET id ae05113; 18 May 87 14:19 EDT Received: from utokyo-relay by RELAY.CS.NET id el09318; 18 May 87 14:04 EDT Received: by u-tokyo.junet (5.51/4.9J-1[JUNET-CSNET]) id AA19470; Mon, 18 May 87 14:10:20 JST Received: by tansei.cc.u-tokyo.junet (4.12/6.2Junet) id AA06726; Mon, 18 May 87 14:06:46+0900 Date: Mon, 18 May 87 14:06:46+0900 From: Masayuki Ida Return-Path: Message-Id: <8705180506.AA06726@tansei.cc.u-tokyo.junet> To: common-lisp@SAIL.STANFORD.EDU, ida%tansei.u-tokyo.junet@RELAY.CS.NET Subject: A multi-byte character extension proposal Date: Mon, 18 May 87 09:44:19 JST From: moto@XXX.XXX.junet (MOTOYOSHI) To: ida@tansei.cc.u-tokyo.junet Subject: Kanji Proposal -------------------- Beginning of text -------------------- @Comment[-*- Mode: Text -*-] @heading[Digest] @heading[1. Hierarcy of characters and strings] Let the value of char-code-limit be large enough to include all characters. char > string-char >= internal-string-char > standard-char string >= internal-thin-string > simple-internal-thin-string simple-string >= simple-internal-thin-string string = (or internal-thin-string (vector string-char)) Type internal-thin-string and (vector string-char) are disjoint or identical. simple-string = (or simple-internal-thin-string (simple-array string-char (*))) Type simple-internal-thin-string and (simple-array string-char (*)) are disjoint or identical. notes: A > B means B is a subtype of A, A >= B means B is a subtype of A or B is equal to A. @Heading[2. Print width] Only standard characters are required to have fix-pitched print width. Use the newly introdued function 'write-width' to know the print width of an expression. @Heading[3. Functions] Functions dealing with strings should work as before, expect ones which change the contents of internal-thin-string to non internal-thin-char's. Functions producing strings should create (vector string-char), not internal-thin-string, unless they were explicitly specified. Funtions comaring strings should copare them elementwise. Therefore it is possible that a (vector string-char) is equal to an internal-thin-string. @newpage @Heading[1. A proposal for embedding multi-byte characters] The Kanji Working Group (KWG) examined implementation of facilities for multi-byte character to Common Lisp. This report is the result of many discussions of many proposals. Of course, this report doesn't satisfy all proposals, but it is very close. In order to decide on a final proposal, we chose essential and desirable characteristics of a working multi-byte character system. Chapter 2 describes these characteristics in some detail. Chapter 3 describes additional features to Common Lisp which will be useful not just for multi-byte character, but also for many other kinds of character sets. This chapter describes internal data structures. If this proposal is accepted in Common Lisp, it will be easy for countries to add original mechanisms. Chapters 4 describes proposed changes to @I[Common Lisp -- The Language] (CLtL). @Heading[2. Additional features for embedding multi-byte characters.] This chapter describes design principles which can be used to design multi-byte character language extensions to Common Lisp. There are many programming languages which can multi-byte characters. Most of them can use multi-byte character as string character data but not as variables or function names. It is necessary for programming languages like Lisp that use symbolic data to be able to process not only single-byte characters but also multi-byte characters. That is, it should be possible to use multi-byte characters in character string and symbols, and it must be possible to store both kinds of characters in them. Treating multi-byte characters just like other alpha-numeric characters means that multi-byte character must be treated as a single character object. Many of the present implementations of Lisp treat multi-byte character as pairs of bytes. Alternatively, they use a different data type which doesn't permit multi-byte character to be mixed with standard characters. Such systems are not useful for user. Thus, the basic design principles for embedding multi-byte character to Common Lisp are: @Begin[Itemize] Multi-byte character should be treated like single-byte character, that is, a multi-byte character is one character object. @End[Itemize] @Begin[Itemize] A program which was coded without explicit attention for multi-byte character should handle multi-byte character data as is. @End[Itemize] These principles provide sufficient functionality, but we can't ignore efficiency. So we considered the next principle: @Begin[Itemize] The performance of the system in terms of CPU and memory utilization should not be consideraly affected in programs which do not use multi-byte characters. @End[Itemize] This principle is contradictory to other principles, but this can't be ignored when we consider the users of actual systems, so we have to compromise. We think that following methods will satisfy both of these requirements. @Heading[3. Common parts which we implement.] This chapter describes the implementation of multiple character sets in Common Lisp. To treat multi-byte characters like single-byte characters, the multi-byte character must be included in the set of possible character codes. We consider the following implementation methods. @Begin[Itemize] Add multi-byte characters by setting the variable char-code-limit to a large number. @End[Itemize] In this case, the single-byte character set and the multi-byte character set must be ordered into a single sequence of character codes. This means multi-byte character set must not overlap with the single-byte character set. This method could be satisfied within most implementations with ease. If we use this method, it is possible to use multi-byte characters with fonts in Common Lisp, and operations that work for single-byte character will also work for multi-byte character without any change. This implementation method has problems with efficiency. In the case that the value of character code is greater than size of 1 byte (multi-byte characters are in this category), memory utilization is affected. A string containing only one single-byte character is 2 bytes long. The same problem would also occur with symbol p-names. If we can solve the problem for strings, we can solve other problems, so we will start by considering only strings. To avoid this memory utilization problem, it is possible to optimize and make single-byte character strings by packing internally. In other words, to have two kinds of data types and not show it to user. There is only one type of data from the viewpoint of users, which means that every function which uses strings will continue to work as defined. This can be implemented in almost everywhere without so many costs. The only problem occurs when a function attempts to put a multi-byte character into an optimized and packed sigle-byte-only string. To work according to the definition, the implementation must unpack the original packed string. This presents an implementation inefficiency which the user may find undesirable. One solution would be to @Begin[Itemize] Generate errors for operations that try to use multi-byte characters into single-byte string and presenting two string datatypes to users. @End[Itemize] We propose this latter implementation. Common lisp should have 2 string types to treat multi-byte characters efficiently. The first of these is @b[1string0], which stores any character of type @B[1string-char0], i.e., whose @I[2bits0] and @I[2font0] are both zero. The type of string is @B[1internal-thin-string0] which is the optimized character string. @B[1internal-thin-char0] is a subtype of @B[1character0] and can be inserted into string @B[1internal-thin-string0]. The predicate which tests for this type of character is @B[1internal-thin-char-p0]. The type @B[1internal-thin-char0] is a subtype of @B[1string-char0], and is a supertype of @B[1standard-char0]. The data type hierarchy for @B[1character0] and @B[1string0] is shown in figure 1. @b[1Internal-thin-char0] and @b[1string-char0] may be equal as it is possible that situations may arise where both sets describe the same character-set. This is equivalent to the type of system that has only one type of character from the viewpoint of the user as discussed in the previous chapter. This proposal permits both kinds of implementations. @newpage @Begin[Verbatim] character | string-char | internal-thin-char | standard-char @Center[Fig-1.a Structure of character type] string | ----------------------------------- | | | | simple-string | | | | internal-thin-string | (vector string-char) | | | ----------------------------------- | | | | simple-internal-thin-string (simple-array string-char (*)) @Center[Fig-1.b Structure of string type] @End[Verbatim] To compare @B[1string0] characters with @B[1internal-thin-string0] characters, it is necessary to convert both to the @B[1string-char0] format. This means that the same character is the same object regardless of whether it is found in an @B[1internal-thin-string0] or a normal @B[1string0]. Next we must discuss character input. The proposal does not discuss what is stored in files, nor what happens between the Lispimplementation and a terminal. Each system will implement this in itsown way. Instead, let us discuss the data as passed to lisp programs. We think that treating all input data as @B[1string0] is the safest possible course. Since a symbol's p-name string should not be modified, it can be optimized. This may cause performance problems for programs which use only single-byte characters. The variable @B[1*read-default-string-type*0] is provided for these programs. When its value is @B[1internal-thin-string0], the system expects single-byte characters only. so the system will return input data in the form of @B[1internal-thin-string0]. Though it is possible that the system may choose to ignore this variable. @newpage @Heading[4 Proposed changes to CLtL to support multiple character sets.] In this section, we list proposed modifications to CLtL. Chapters 13, 14 and 18 of CLtL are concerned very greatly with multi-byte character, so we specify modifications to these chapters by making a list of all constants, functions and variables. For other chapters we specify only additional and modifying parts. Those portions which are not mentioned are unchanged. @b(2 Data Types) @b(2.5.2 Strings) @begin(equation) "a string is a specialized vector .... type string-char"  "a string is a specialized vector .... type string-char or @B[internal-thin-char]" @end(equation) @b(2.15 Overlap,Inclusion and Disjointness of Types) a description of type string-char is changed to : Type standard-char is a subtype of @B[internal-thin-char]. @B[internal-thin-char] is a subtype of string-char. string-char is a subtype of character. and add the following : Type @B[internal-thin-string] is a subtype of vector because @B[internal-thin-string] means (vector internal-thin-char). a description of type string is changed to : Type string is a subtype of vector because string means (or (vector string-char) internal-thin-string). Type (vector string-char) and @B[internal-thin-string] are disjoint or equality. a description of type simple-vector,simple-string ... is changed to : Type simple-vector,simple-string and simple-bit-vector are disjoint subtype of simple-array because each one means (simple-array t (*)), (or (simple-array string-char (*)),(or (simple-array internal-thin-char (*)) and (simple-array bit (*)). and add following : Type simple-internal-thin-string means (simple-array internal-thin-char (*)) and is a subtype of @B[internal-thin-string]. Type (simple-array string-char (*)) and simple-internal-thin-string are disjoint or equality. @b(4 Type Specifiers) @b(4.1 Type Specifier Symbols) add followings to system defined type specifiers : simple-internal-thin-string internal-thin-string internal-thin-char @b(4.5 Type Specifiers That Specialize) "The specialized types (vector string-char) ... data types."  "The specialized types (vector internal-thin-char), (vector string-char) and (vector bit) are so useful that they have the special names string and bit-vector. Every implementation of Common Lisp must provide distinct representation for string and bit-vector as distinct specialized data types." @begin(equation) @b(13 Characters) @b(13.1 Character Attributes) char-code-limit@>[constant] char-font-limit@>[constant] char-bits-limit@>[constant] @b(13.2 Predicates on Characters) standard-char-p char@>[constant] graphic-char-p char@>[constant] @begin(quotation) a description "graphic characters of font 0 are all of the same width when printed" in the CLtL changed to "standard-char without #\Newline of font 0 are all of the same width when printed". @end(quotation) string-char-p char @>[function] internal-thin-char-p char@>[function] @begin(quotation) this function must be added. the argument char must be a character object. internal-thin-char-p is true if char can be stored into a internal-thin-string, and otherwise is false. @end(quotation) alpha-char-p char@>[function] upper-case-p char@>[function] lower-case-p char@>[function] both-case-p char@>[function] "If a character is either ... alphabetic."  "If a character is either uppercase or lowercase, it is necessarily character that alpha-char-p returns true." digit-char-p char &optional (radix 10)@>[function] alphanumericp char@>[function] char= character &rest more-characters@>[function] char/= character &rest more-characters@>[function] char< character &rest more-characters@>[function] char> character &rest more-characters@>[function] char<= character &rest more-characters@>[function] char>= character &rest more-characters@>[function] char-equal character &rest more-characters@>[function] char-not-equal character &rest more-characters@>[function] char-lessp character &rest more-characters@>[function] char-greaterp character &rest more-characters@>[function] char-not-greaterp character &rest more-characters@>[function] char-not-lessp character &rest more-characters@>[function] @b(13.3 Character Construction and Selection) char-code char@>[function] char-bits char@>[function] char-font char@>[function] code-char char &optional (bits 0) (font 0)@>[function] make-char char &optional (bits 0) (font 0)@>[function] @b(13.4 Character Conversion) character char@>[function] char-upcase char@>[function] char-downcase char@>[function] digit-char weight &optional (radix 10) (font 0)@>[function] char-int char@>[function] int-char char@>[function] char-name char@>[function] name-char char@>[function] @b(13.5 Character control-bit functions) char-control-bit@>[constant] char-meta-bit@>[constant] char-super-bit@>[constant] char-hyper-bit@>[constant] char-bit char name@>[function] set-char-bit char name newvalue@>[function] @b(14 Sequence) @b(14.1 Simple sequence functions) elt sequence index@>[Function] subseq sequence start &optional end@>[Function] copy-seq sequence@>[Function] length sequence@>[Function] reverse sequence@>[Function] nreverse sequence@>[Function] make-sequence type size &key :initial-element@>[Function] @b(14.2 Sequence connection) concatenate result-type &rest sequences@>[Function] map result-type function sequence &rest more-sequences@>[Function] some predicate sequence &rest more-sequences@>[Function] every predicate sequence &rest more-sequences@>[Function] notany predicate sequence &rest more-sequences@>[Function] notevery predicate sequence &rest more-sequences@>[Function] reduce function sequence@>[Function] &key :from-end :start :end :initial-value @b(14.3 Sequence correction) fill sequence item &key :start :end@>[Function] replace sequence1 sequence2 &key :start1 :end1 :start2 :end2@>[Function] remove item sequence@>[Function] &key :from-end :test :test-not :start :end :count :key remove-if test sequence@>[Function] &key :from-end :start :end :count :key remove-if-not test sequence@>[Function] &key :from-end :start :end :count :key delete item sequence@>[Function] &key :from-end :test :test-not :start :end :count :key remove-if test sequence@>[Function] &key :from-end :start :end :count :key remove-if-not test sequence@>[Function] &key :from-end :start :end :count :key remove-duplicates sequence@>[Function] &key :from-end :test :test-not :start :end :key delete-duplicates sequence@>[Function] &key :from-end :test :test-not :start :end :key subsutitute newitem test sequence@>[Function] &key :from-end :test :test-not :start :end :count :key subsutitute-if newitem test sequence@>[Function] &key :from-end :start :end :count :key subsutitute-if-not newitem test sequence@>[Function] &key :from-end :start :end :count :key nsubsutitute newitem test sequence@>[Function] &key :from-end :test :test-not :start :end :count :key nsubsutitute-if newitem test sequence@>[Function] &key :from-end :start :end :count :key nsubsutitute-if-not newitem test sequence@>[Function] &key :from-end :start :end :count :key @b(14.4 Search) find item sequence @>[Function] &key :from-end :test :test-not :start :end :key find-if test sequence @>[Function] &key :from-end :start :end :key find-if-not test sequence>[Function] &key :from-end :start :end :key position item sequence@>[Function] &key :from-end :test :test-not :start :end :key position-if test sequence@>[Function] &key :from-end :start :end :key position-if-not test sequence@>[Function] &key :from-end :start :end :key count item sequence@>[Function] &key :from-end :test :test-not :start :end :key count-if item sequence@>[Function] &key :from-end :start :end :key count-if-not item sequence@>[Function] &key :from-end :start :end :key mismatch sequence1 sequence2@>[Function] &key :from-end :test :test-not :key :start1 :start2 :end1 :end2 search sequence1 sequence2@>[Function] &key :from-end :test :test-not :key :start1 :start2 :end1 :end2 @b(14.5 Sort,merge) sort sequence predicate &key :key@>[Function] stable-sort sequence predicate &key :key@>[Function] merge result-type sequence1 sequence2 predicate &key :key@>[Function] @b(18 Strings) "the type string is identical ... (array string-char (*))."  "the type string is identical to the type (or (vector internal-thin-char) (vector string-char)), which in turn is the same as (or (array internal-thin-char (*)) (array string-char (*)))." @b(18.3 String Construction and Manipulation) make-string size &key :initial-element@>[function] @begin(quotation) add following : To make an internal-thin-string, you should use make-array or make-sequence. @end(quotation) @b(22 Input/Output) @b(22.2 Input Functions) @b(22.2.1 Output to Character Stream) add following : *read-default-string-type*@>[variables] @begin(quotation) The value is string or internal-thin-string. This determines string that the function read takes whether type string or internal-thin-string. @end(quotation) @b(22.3 Output Functions) @b(22.3.1 Output from Character Stream) @begin(quotation) add following : @end(quotation) write-width object@>[function] &key :unit-type :stream :escape :radix :base :circle :pretty :label :length :case :gensym :array @begin(quotation) This function returns the printed width as the value of the unit specified by :unit-type when then printed representation of object is written to the output stream specified by :stream. It returns nil when object includes control characters (#\Newline,#\Tab etc). The default of :unit-type is byte. The value which we can specify :unit-type depends on implementation. @end(quotation) @end(equation) @newpage @Heading[Appendix Proposed Japanese character processing facilities for Common Lisp.] In addition to the modification of CLtL, here are some suggestions for systems including Japanese characters. 1). How should system behave for Japanese characters both under unmodified part of CLtL and the part changed for multi-byte processing. 2). About function that are specific to Japanese and no at all related to multi-byte processing. Notes: All Japanese characters are constituent. JIS is a abreviation of Japanese Industry Standard. @begin(equation) @b(13. Characters) @b(13.1. Character Attributes) char-code-limit char @>[Function] @begin(quotation) The value of char-code-limit should be large enough to include Japanese characters, e.g. 65536. @end(quotation) @b(13.2. Predicates on Characters) standard-char-p char @>[Function] @begin(quotation) Return nil for all Japanese characters. @end(quotation) graphic-char-p char @>[Function] @begin(quotation) Return t for Japanese characters. @end(quotation) internal-thin-char-p char @>[Function] @begin(quotation) The result depends on each implementation that whether the Japanese character is in internal-thin-string or not. @end(quotation) alpha-char-p char @>[Function] @begin(quotation) Return nil for all character except alphabets in Japanese character. It depends on each implementation whether to return t or nil for alphabets in Japanese characters. @end(quotation) @newpage jis-char-p char@>[Function] @begin(quotation) The argument char has to be a character type object. jis-char-p is true if the argument is included in JIS C-6226, and otherwise false. @end(quotation) japanese-char-p char@>[Function] @begin(quotation) The argument char has to be a character type object. japanese-char-p is true if the argument is a Japanese character and is otherwise false. All characters that satisfy jis-char-p must satisfy japanese-char-p; other characters might. @end(quotation) kanji-char-p char@>[Function] @begin(quotation) The argument char has to be character type object. kanji-char-p is true if the argument is one of the 6353 Kanji characters in JIS C6226(3.1.8), the repeat symbol, the kanji numeric zero or the same as above symbol for a total of 6356 characters that also satisfy jis-char-p. @end(quotation) hiragana-char-p char@>[Function] @begin(quotation) The argument char has to be character type object. hiragana-char-p is true if the argument is one of the 83 hiragana characters in JIS C6226(3.1.4), the hiragana repeat symbol, or dakuten for a total of 85 characters that also satisfy jis-char-p. @end(quotation) katakana-char-p char@>[Function] @begin(quotation) The argument char has to be a character type object. katakana-char-p is true if the argument is one of the 86 hiragana characters in JIS C6226(3.1.5), long-sound-symbol, katakana-repeat symbol, or katakana-dakuten for a total of 89 characters that also satisfy jis-char-p. @end(quotation) kana-char-p char@>[Function] @begin(quotation) equivalence (or (hiragana-char-p char) (katakana-char-p char)) @end(quotation) upper-case-p char@>[Function] lower-case-p char@>[Function] both-case-p char@>[Function] @begin(quotation) These are nil if the argument does not satisfy alpha-char-p. Japanese characters which satisfy alpha-char-p should be treated as normal alphabetic characters. @end(quotation) @newpage digit-char-p char &optional (radix 10)@>[Function] @begin(quotation) digit-char-p is nil if the argument is a Japanese character. @end(quotation) alphanumericp char@>[Function] @begin(quotation) equivalence (or (alpha-char-p char) (not (null (digit-char-p char)))) @end(quotation) char= character &rest more-characters@>[Function] char/= character &rest more-characters@>[Function] char< character &rest more-characters@>[Function] char> character &rest more-characters@>[Function] char<= character &rest more-characters@>[Function] char>= character &rest more-characters@>[Function] @begin(quotation) The ordering of hiragana, katakana, kanji follows the JIS ordering. @end(quotation) @b(13.4 character Conversions) char-upcase char@>[Function] char-downcast char@>[Function] @begin(quotation) These return the argument if the argument does not satisfy alpha-char-p. It depends on the implementation whether these work on the alphabets included in JIS or not. But it should be consistent with upper-case-p, lower-case-p, both-case-p. @end(quotation) @end(equation)  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 18 May 87 15:10:03 EDT Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 18 May 87 11:50:56 PDT Received: from relay2.cs.net by RELAY.CS.NET id ac05113; 18 May 87 14:19 EDT Received: from utokyo-relay by RELAY.CS.NET id ek09318; 18 May 87 14:03 EDT Received: by u-tokyo.junet (5.51/4.9J-1[JUNET-CSNET]) id AA19456; Mon, 18 May 87 14:09:05 JST Received: by tansei.cc.u-tokyo.junet (4.12/6.2Junet) id AA06680; Mon, 18 May 87 14:05:32+0900 Date: Mon, 18 May 87 14:05:32+0900 From: Masayuki Ida Return-Path: Message-Id: <8705180505.AA06680@tansei.cc.u-tokyo.junet> To: common-lisp@SAIL.STANFORD.EDU, ida%tansei.u-tokyo.junet@RELAY.CS.NET Subject: Introduction to a multi-byte character extension In the separate mail, I posted a mail titled "A multi-byte character extension proposal", which has 740 lines. Since I posted mails on kanji manipulation in May 1986, I have been thinking of this problem. I organized the kanji WG under Jeida Common Lisp committee, and I welcomed Dr. Motoyoshi from Electro-technical Laboratory as the chair of the WG. I asked him and his group to make a proposal. Their porposal was first appeared on the academic meeting (IPSJ SIGSYM Jan. 1987) and then reported in the annual report of Jeida, then was refined into the english version I posted as a mail. I believe the contents are worth to distribute in USA and to have criticism and suggestions as a base for multi-byte character manipulation extension of Common Lisp. It is a report of our kanji WG to make a guide line for multi-byte character manipulation in Common Lisp, not by myself only, but by the contributions of all the members of kanji WG. kanji WG members: IKEO, J. (Fuji Xerox Co., Ltd.) KIMURA, K. (Toshiba Corp.) MURAYAMA, K. (Nippon Univac Kaisha, Ltd.) NAKAMURA, S. (Fujitsu, Ltd.) OKA, M. (Japan Radio Co., Ltd.) SAKAIBARA, K. (Hitachi Co., Ltd.) SHIOTA, E. (Nihon Symbolics Corp.) SUGIMURA, T. (Nippon Telegraph and Telephone Corp.) Especially, thanks to Mr. Shiota of Nippon Symbolics, who made a first english version. It has a digest, 4 chapters and one appendix; Digest 1. A proposal for embedding multi-byte characters 2. Additional features for embedding multi-byte characters 3. Common parts which we implement 4. Proposed changes to CLtL to support multiple character sets Appendix Proposed Japanese character processing facilities for Common Lisp We tried to split the general issues on multi-byte character extension and the japanese character manipulation. We hope this specification will fit to any other character set handling. Our proposal is based on the clear specification of CLtL for character data type. Roughly speaking, First, we give a value larger than 256, may be 65536 or larger, to *char-code-limit* constant. Second, for the implementation which do not need to have a multi-byte character feature, we propose internal-thin-things. Third, to handle multi-byte character properly, we propose write-width function. We did not make a conclusion on font- style- issue. And our proposal does not have a direct concern to the issue. We will welcome any comments on it. But we can not make a rapid answer to arpa. So, please dont haste. excuse me. We will make answers to the important questions considering our limited budget for communication. Masayuki Ida  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 18 May 87 11:24:00 EDT Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 18 May 87 08:10:58 PDT Received: ID ; Mon 18 May 87 11:10:08-EDT Date: Mon, 18 May 1987 11:10 EDT Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: Common-Lisp@SAIL.STANFORD.EDU, AIList@STRIPE.SRI.COM Subject: Mailing List for Lucid Users We have set up an ARPAnet mailing list, "lucites@c.cs.cmu.edu", for the exchange of information related to Lucid Common Lisp. This mailing list is meant to function as a sort of informal users' group; it is not under the control of Lucid, though some Lucid people will receive it. "Lucites" is an appropriate channel for queries, programming hints, and the sharing of software (large programs can be announced but should not be distributed over this mailing list). "Lucites" is not an appropriate channel for bug reports, commercial announcements, or sales pitches. Because our machine's capacity to forward mail is limited, we must reserve the right to refuse any request to add more than two recipients to the list from any given site; if you have three or more people who want to receive this mail, you are expected to set up you own local redistribution list or to direct the mail to a bulletin board that your people can access. (If anyone wants to set up a version of this list without such restrictions, please contact us and we will gladly turn the task over to you.) To get your name on the list, send mail to "lucites-request@c.cs.cmu.edu". Requests sent to us personally will be ignored. Requests sent to the mailing list as a whole will result in scorn and abuse being heaped upon you. If any address on the list starts bouncing mail sent to it, it will be excised from the list at once. Scott E. Fahlman David B. McDonald Computer Science Department Carnegie-Mellon University  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 18 May 87 09:11:26 EDT Received: from NADC.ARPA by SAIL.STANFORD.EDU with TCP; 18 May 87 06:03:07 PDT Date: 18 May 1987 08:58:24-EDT From: dml@NADC To: common-lisp@sail.stanford.edu Subject: Addition to mailing list. I am involved in design of both expert system shells and expert systems on PC/AT and Symbolics-3600 series. Please add me to your mailing list. Please send any recent info you have r about: Gold Hiill LISP, Symbolics Common Lisp , or Kyoto Common LISP. David Loewenstern Naval Air Development Center code 7013 Warminster, PA 18974-5000  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 17 May 87 18:41:22 EDT Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 17 May 87 15:32:23 PDT Received: from LIVE-OAK.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 17 May 87 18:30-EDT Received: from GOLD-HILL-ACORN.DialNet.Symbolics.COM by MIT-LIVE-OAK.ARPA via DIAL with SMTP id 43116; 17 May 87 18:29:57-EDT Received: from RAVEL.Gold-Hill.DialNet.Symbolics.COM by ACORN.Gold-Hill.DialNet.Symbolics.COM via CHAOS with CHAOS-MAIL id 69423; Sun 17-May-87 17:58:22-EDT Date: Sun, 17 May 87 17:56 est From: dg%acorn@oak.lcs.mit.edu To: Acuff@SUMEX-AIM.STANFORD.EDU Subject: Re: &REST Cc: common-lisp@SAIL.STANFORD.EDU Date: Fri, 15 May 87 14:01:46 PDT From: Richard Acuff For the record, in Release 3, TI has attempted, with apparent success, to remove the restrictions on using &REST lists outside of the dynamic scope of the parameter. (While increasing the performance of the system, to boot.) -- Rich ------- Are there exactly 0 restrictions now? Does this mean that removing the restrictions actually improved the performance of the system, or was that just coincidental? -dg  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 15 May 87 21:00:18 EDT Received: from ACORN.CS.ROCHESTER.EDU by SAIL.STANFORD.EDU with TCP; 15 May 87 17:47:40 PDT Received: from CASHEW.CS.ROCHESTER.EDU (CASHEW.CS.ROCHESTER.EDU) by ACORN.CS.ROCHESTER.EDU via INTERNET with SMTP id 12746; 15 May 87 20:48:15 EDT Date: Fri, 15 May 87 08:45 EDT From: Brad Miller Subject: Last message to list. To: common-lisp@sail.stanford.edu cc: miller@ACORN.CS.ROCHESTER.EDU Message-ID: <870515084522.9.MILLER@CASHEW.CS.ROCHESTER.EDU> Sender: miller@cs.rochester.edu Reply-To: miller@cs.rochester.edu Organization: University of Rochester, Department of Computer Science Postal-address: 617 Hylan Building, University of Rochester, Rochester NY 14627 Phone: 716-275-7747 Sorry, that wasn't meant for the entire list. Apologies, etc. Brad Miller ------ miller@cs.rochester.edu miller@acorn.cs.rochester.edu  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 15 May 87 17:20:14 EDT Received: from SUMEX-AIM.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 15 May 87 14:03:13 PDT Date: Fri, 15 May 87 14:01:46 PDT From: Richard Acuff Subject: Re: &REST To: berman@VAXA.ISI.EDU, common-lisp@SAIL.STANFORD.EDU In-Reply-To: <8705132124.AA02845@vaxa.isi.edu> Message-ID: <12302647619.45.ACUFF@SUMEX-AIM.STANFORD.EDU> For the record, in Release 3, TI has attempted, with apparent success, to remove the restrictions on using &REST lists outside of the dynamic scope of the parameter. (While increasing the performance of the system, to boot.) -- Rich -------  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 15 May 87 16:47:09 EDT Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 15 May 87 13:33:07 PDT Received: from LIVE-OAK.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 15 May 87 16:29-EDT Received: from PALLADIAN-JASPER.DialNet.Symbolics.COM by MIT-LIVE-OAK.ARPA via DIAL with SMTP id 42955; 15 May 87 16:29:59-EDT Received: from KITTYHAWK.Palladian.COM by JASPER.Palladian.COM via INTERNET with SMTP id 35711; 15 May 87 13:04:19-EDT Date: Fri, 15 May 87 13:03 EDT From: K. Shane Hartman Subject: Re: &REST To: Common-Lisp@sail.stanford.edu In-Reply-To: <8705142119.AA04811@bhopal.edsel.uucp> Message-ID: <870515130345.5.SHANE@KITTYHAWK.PALLADIAN.COM> Reply-To: K. Shane Hartman Date: Thu, 14 May 87 14:19:29 PDT From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White) ... But the kinds of folks who have tolerated the bug which Dan Wienreb so gloriously announced are not entirely stupid. There is a market, at least amongst some systems programmers who use lisp, to get the kind of "last-bit tweaking" performance that a stack-allocated &rest list would afford. Lucid's product will shortly be giving the user access to some of the underlying primitives which permit dynamic-extent consing (the 3600's "stack list" consing is one such example). ... In fact, we use stack allocated &REST lists exclusively. We tried using heap allocated &REST lists and found that it significantly impaired the performance of at least one large system. I think lisp vendors should be encouraged to provide this sort of feature. -[Shane]->  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 15 May 87 16:47:02 EDT Received: from ACORN.CS.ROCHESTER.EDU by SAIL.STANFORD.EDU with TCP; 15 May 87 13:31:40 PDT Received: from CASHEW.CS.ROCHESTER.EDU by ACORN.CS.ROCHESTER.EDU via CHAOS with CHAOS-MAIL id 12731; Fri 15-May-87 16:19:08 EDT Date: Fri, 15 May 87 04:16 EDT From: Brad Miller Subject: (REDUCE #'OVERHEAD (MAP ...)) To: MURRAY%cs.umass.edu@RELAY.CS.NET cc: common-lisp@SAIL.STANFORD.EDU, miller@ACORN.CS.ROCHESTER.EDU In-Reply-To: <8704290611.AA12297@cayuga.cs.rochester.edu> Message-ID: <870515041614.4.MILLER@CASHEW.CS.ROCHESTER.EDU> Sender: miller@cs.rochester.edu Reply-To: miller@cs.rochester.edu Organization: University of Rochester, Department of Computer Science Postal-address: 617 Hylan Building, University of Rochester, Rochester NY 14627 Phone: 716-275-7747 Date: Tue, 28 Apr 87 19:32 EDT From: MURRAY%cs.umass.edu@RELAY.CS.NET > From: James Larus > I use REDUCE quite frequently and recently ran across a strange > interaction between it and another CL feature. I was trying to > execute: > (reduce #'or (mapcar ...)) If you're doing a lot of stuff like this, maybe you should look into the "Generic Mapping Functions" that Daniel Corkill has defined. They do much of what REDUCE + MAP is used for, but the notion of combining the results of mapping is generalized, and is done more efficiently since it isn't always necessary to cons up the intermediate results. MAPCAR can be thought of as using CONS to combine mapping results. The above use of OR is generally done through SOME in Common Lisp, but is expressed using the Generalized Maps as MAPC-OR. EVERY is MAPC-AND, and MAPCAN (MAPC-NCONC) functionality is done better as MAPC-CONDCONS. MAPC-MAX is a popular one, as is MAPC-+ (MAPC-UNION, MAPC-AVERAGE, etc). There are also MAPL-xxx functions that operate on sucessive sublists. We have plans to extend these to work on sequences and not just lists, but haven't done it yet (:- of course, they handle circular-lists :-) The MAP-FUN general form takes a gob of keywords to allow just about any mapping combination to be defined, and all the others are defined in terms of it. They are Functions, but have Compiler transforms that convert them into very efficient DO loops. We can probably get the code to anyone interested. - Kelly Murray University of Massachusetts Sorry if this is a repeat, but I am very interested in your conjoined mapping functions... If you can mail it, terrific, if ftp access is better, let me know, or if you want a tape... Thanks, Brad Miller ------ miller@cs.rochester.edu miller@acorn.cs.rochester.edu  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 15 May 87 13:44:48 EDT Received: from AEROSPACE.AERO.ORG by SAIL.STANFORD.EDU with TCP; 15 May 87 10:34:31 PDT Received: by aerospace.aero.org (5.54/6.0.GT) id AA01230; Fri, 15 May 87 10:29:47 PDT Posted-Date: Fri, 15 May 87 10:29:32 -0800 Message-Id: <8705151729.AA01230@aerospace.aero.org> To: MATHIS@ada20.isi.edu Cc: common-lisp@sail.stanford.edu Subject: Re: Gold Hill's floating-point In-Reply-To: Your message of 15 May 1987 06:35-PDT. <[ADA20.ISI.EDU]15-May-87 06:35:47.MATHIS> Date: Fri, 15 May 87 10:29:32 -0800 From: coffee@aerospace.aero.org Bob Mathis notes, correctly, that my earlier reply to samalone assumed that you had all seen the original message. Mea culpa. The problem that _he_ had fixed was Gold Hill 286's habit of returning _weird_-looking floating-point results (multiple decimal points, etc.) after a period of use: apparently, this is due to pushing to DOS and leaving the 8087 or 80287 in an odd state that Gold Hill's interpreter does not correct on returning. The fix is to make the call (SYS::8087-FPP) after returning from DOS. I have my own (dos) function defined in USERINIT to provide a "press a key to return to Lisp" prompt if (dos) is called with an argument, so adding this call to that function has fixed the problem. The Hummingboard release uses the call (SYS::8087-FPP :emulate) in view of the absence of a physical numeric chip on that board, and I have seen no such bizarre behavior -- not this specific variety, I mean -- on it, so there is no apparent reason to do this on the Hummer. The general problem of floating-point creativity in GC 386 Developer continues, I'm sad to say: how about (log 1024 2) --> 9.53638... to double precision? The same result also occurs with single- or double-precision real arguments. Further, another user tells me that regular old non-Hummingboard GC386 does the same thing on her "Inboard" 386 card. BTW, I have mentioned the substantial enhancements to the editor as a major advantage of the Gold Hill 386 vs. 286 products; I learned yesterday that a new, compiled, enhanced editor (sounds exactly like the 386 version) is a key feature of the GC286 2.2 upgrade, $90. Since we're not seeing nearly the factor of five speed increase that Gold Hill claims versus "an AT" (maybe they ran against a 6 MHz machine? We're seeing speed ratios of from one to four with a Hummingboard in a DeskPro 386 against an 8-MHz DeskPro 286), consider this in your cost-effectiveness evaluation. A twelve- or sixteen-MHz 80286 with adequate RAM may be quite competitive, especially if (like us) you're doing pattern recognition in telemetry streams or other number- crunching things. Of course, the Hummingboard can be dropped right into any XT clone with a decent hard disk, an important factor if you already own such a box. I'm sorry if this extended discussion of microcomputer implementations has annoyed anyone: in general, I direct such comments to lang.lisp, and will continue to do so now that the loose ends on this exchange are (I believe) tied off. I would also like to stress that Gold Hill's people have been prompt, courteous, and helpful in our discussions of these problems and that I have every confidence that they will be quickly resolved. Regards, Pc^2  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 14 May 87 20:41:00 EDT Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 14 May 87 17:24:38 PDT Received: ID ; Thu 14 May 87 20:23:56-EDT Date: Thu, 14 May 1987 20:23 EDT Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: berman@VAXA.ISI.EDU Cc: common-lisp@SAIL.STANFORD.EDU Subject: documentation In-reply-to: Msg of 14 May 1987 17:37-EDT from berman at vaxa.isi.edu I think that only the specified symbols are required to work. Anything else "is an error". However, it is legal to extend the language so that other symbols or even non-symbols work. -- Scott  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 14 May 87 18:22:32 EDT Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 14 May 87 15:07:28 PDT Received: by navajo.stanford.edu; Thu, 14 May 87 15:04:56 PDT Received: from bhopal.edsel.uucp by edsel.uucp (2.2/SMI-2.0) id AA04439; Thu, 14 May 87 14:18:04 pdt Received: by bhopal.edsel.uucp (3.2/SMI-3.2) id AA04811; Thu, 14 May 87 14:19:29 PDT Date: Thu, 14 May 87 14:19:29 PDT From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White) Message-Id: <8705142119.AA04811@bhopal.edsel.uucp> To: navajo!common-lisp%sail.stanford.edu@navajo.stanford.edu Subject: Re: &REST For compatibility with the semantics of CLtL, Lucid chose to make the &rest arg be a true (heap-consed) list. But the kinds of folks who have tolerated the bug which Dan Wienreb so gloriously announced are not entirely stupid. There is a market, at least amongst some systems programmers who use lisp, to get the kind of "last-bit tweaking" performance that a stack-allocated &rest list would afford. Lucid's product will shortly be giving the user access to some of the underlying primitives which permit dynamic-extent consing (the 3600's "stack list" consing is one such example). The default for &REST lists will, of course, still be lists of indefinite extent. -- JonL --  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 14 May 87 17:56:50 EDT Received: from VAXA.ISI.EDU by SAIL.STANFORD.EDU with TCP; 14 May 87 14:38:47 PDT Posted-Date: Thu, 14 May 87 14:37:03 PDT Message-Id: <8705142137.AA11169@vaxa.isi.edu> Received: from LOCALHOST by vaxa.isi.edu (5.54/5.51) id AA11169; Thu, 14 May 87 14:37:05 PDT To: common-lisp@sail.stanford.edu Subject: documentation Date: Thu, 14 May 87 14:37:03 PDT From: berman@vaxa.isi.edu What should the following do? (documentation 'doc 'doc) Per page 440 of CLtL, there is a list of documentation types, but no mention of what to do if given some other symbol. Should it return NIL? Should it signal or "be" an error? Can it return some other arbitrary value, or is it totally up to the implementor? Likewise, (setf (documentation 'doc 'doc) "xyz"), I have an implementation here that allows documentation to work this way. It appears to more or less syntactic-sugar for property lists, 'cuz in the above case, the setf will put "xyz" on the symbol DOC as it documentation type DOC. I have another implementation which is strictly by the book in that if it is not on that list of legal documentation types, it signals an error. Note: The first implementation is a bit too relaxed--it allows (setf (documentation "FOO" 'doc) "xyz"), which is clearly incorrect 'cuz "Both arguments must be symbols". RB  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 14 May 87 16:28:17 EDT Received: from AEROSPACE.AERO.ORG by SAIL.STANFORD.EDU with TCP; 14 May 87 13:13:52 PDT Received: by aerospace.aero.org (5.54/6.0.GT) id AA12386; Thu, 14 May 87 13:04:07 PDT Posted-Date: Thu, 14 May 87 13:04:02 -0800 Message-Id: <8705142004.AA12386@aerospace.aero.org> To: samalone@athena.mit.edu Cc: common-lisp@sail.stanford.edu Subject: Re: Gold Hill's floating-point In-Reply-To: Your message of Thu, 14 May 87 13:37:25 EDT. <8705141737.AA19398@HADES.MIT.EDU> Date: Thu, 14 May 87 13:04:02 -0800 From: coffee@aerospace.aero.org Thanks -- this explains an annoying, but different, problem that also occurs under GC286 on an 80286/80287 machine. Thanks again (I'll put this into my definition of the (dos) function to make it automatic). - Peter C.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 14 May 87 14:23:49 EDT Received: from VAXA.ISI.EDU by SAIL.STANFORD.EDU with TCP; 14 May 87 11:07:44 PDT Posted-Date: Thu, 14 May 87 11:04:37 PDT Message-Id: <8705141804.AA05984@vaxa.isi.edu> Received: from LOCALHOST by vaxa.isi.edu (5.54/5.51) id AA05984; Thu, 14 May 87 11:04:45 PDT To: coffee@aerospace.aero.org Cc: berman@vaxa.isi.edu (Richard Berman), common-lisp@sail.stanford.edu Subject: Re: &REST In-Reply-To: Your message of Thu, 14 May 87 09:10:07 -0800. <8705141610.AA06471@aerospace.aero.org> Date: Thu, 14 May 87 11:04:37 PDT From: berman@vaxa.isi.edu Well, as for the "several Mac lisps", as I mentioned in my message this was told to me by Seth goldman and was not a matter of my personal experience. I did not name any names. He said ExperLisp DID behave incorrectly, but he didn't say which release. I am glad to hear that it is not as widespread as Seth implied. RB  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 14 May 87 12:28:47 EDT Received: from AEROSPACE.AERO.ORG by SAIL.STANFORD.EDU with TCP; 14 May 87 09:12:30 PDT Received: by aerospace.aero.org (5.54/6.0.GT) id AA06471; Thu, 14 May 87 09:10:19 PDT Posted-Date: Thu, 14 May 87 09:10:07 -0800 Message-Id: <8705141610.AA06471@aerospace.aero.org> To: berman@vaxa.isi.edu (Richard Berman) Cc: common-lisp@sail.stanford.edu Subject: Re: &REST In-Reply-To: Your message of 13 May 1987 1424-PDT (Wednesday). <8705132124.AA02845@vaxa.isi.edu> Date: Thu, 14 May 87 09:10:07 -0800 From: coffee@aerospace.aero.org Well, I don't know about "several of the Macintosh Lisps," but ExperCommon Release 2.2 handles (defun foo (&rest a) a);(foo 1 2 3) --> (1 2 3) correctly; so, for that matter, do Gold Hill's GC286 and GC386(Hummingboard) implementations. By the way, I've mentioned this in lisp news already, but watch out for the Hummingboard Lisp: it thinks that log of 1e6 to the base 10 is a double-precision value slightly greater than pi, reproducibly, and the rest of its math functions are similarly creative. It also gives incorrect results (not error _messages_, mind you, just wrong answers) running a version of Forgy's OPS5 that was only modified as necessary to make it run on GC286. Gold Hill's phone support has been courteous and sincerely interested, but for the moment we're in the incongruous position of using the Hummingboard as an unbelievably nice editor but doing serious testing and production on a plain-vanilla DeskPro 286...  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 13 May 87 18:29:15 EDT Received: from [192.10.41.109] by SAIL.STANFORD.EDU with TCP; 13 May 87 15:12:26 PDT Received: from CHICOPEE.SCRC.Symbolics.COM by ALDERAAN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 81313; Wed 13-May-87 18:10:48 EDT Date: Wed, 13 May 87 18:10 EDT From: Daniel L. Weinreb Subject: &REST To: berman@vaxa.isi.edu, common-lisp@sail.stanford.edu In-Reply-To: <8705132124.AA02845@vaxa.isi.edu> Message-ID: <870513181032.7.DLW@CHICOPEE.SCRC.Symbolics.COM> Date: 13 May 1987 1424-PDT (Wednesday) From: berman@vaxa.isi.edu (Richard Berman) My feelings are that the above efficiency hack is a bug, even though it may be "supported by hardware". Can anyone show me a valid justification for the above behavior? There isn't any justification. It's a bug. It's among the list of documented non-conformances of the Symbolics implementation, most of which are a whole lot less severe than this one. Unfortunately, it is extremely difficult to fix without an unacceptable impairment of performance in this implementation. "No excuse, sir."  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 13 May 87 17:45:45 EDT Received: from VAXA.ISI.EDU by SAIL.STANFORD.EDU with TCP; 13 May 87 14:26:22 PDT Received: by vaxa.isi.edu (4.12/4.7) id AA02845; Wed, 13 May 87 14:24:38 pdt From: berman@vaxa.isi.edu (Richard Berman) Message-Id: <8705132124.AA02845@vaxa.isi.edu> Date: 13 May 1987 1424-PDT (Wednesday) To: common-lisp@sail.stanford.edu Cc: berman@vaxa.isi.edu Subject: &REST Now, I'm SURE this one has come up, but here goes... In your favorite implementation of CL, try this: (DEFUN FOO (&REST A) A) (FOO 1 2 3) By direct experience, both TI (version 2) and Symbolics (Version 7) do not return (1 2 3). They have an efficiency hack wherein the cons space used to create the &REST arg is reused, and thus the pointer that is returned (which is a pointer to a list) is pointing to memory which does not contain the same thing as when the pointer was last evaluated. That is, he process of returning has the side effect of changing the contents of the list created when binding A. Seth Goldman tells me that several Macintosh Lisps also behave this way. CLtL, on page 61, states: "If there is a rest parameter, it is bound to a list of all as-yet-unprocessed arguments." This part works fine. These implementations DO make a list and bind it and all that. The symbolics manual specifically warns one to use copylist if you want to return any tail or sublist of an &REST argument (thus consing it in "real" memory). As I am putting together the test suite, I have run into a problem: Many tests actualy use &REST. These seem to expect to get a proper list and not some imaginary list that changes when the function returns. My feelings are that the above efficiency hack is a bug, even though it may be "supported by hardware". Can anyone show me a valid justification for the above behavior? So far, HP has an implementation that does the correct thing (returns the list). TI, in their version 3 software (which we are beta-ing) has fixed this. Note that page 60 clearly states, about the body in a lambda, "The body consists of any number of forms (possibly zero). These forms are evaluated in sequence, and the results of the last form only are returned as the results of the application..." This does not allow for any alteration of the results of the last form. OK? RB  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 12 May 87 21:12:32 EDT Received: from SCRC-YUKON.ARPA by SAIL.STANFORD.EDU with TCP; 12 May 87 17:52:41 PDT Received: from WHITE-BIRD.SCRC.Symbolics.COM by YUKON.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 207069; Tue 12-May-87 20:50:54 EDT Date: Tue, 12 May 87 20:50 EDT From: Robert W. Kerns Subject: atom type question To: Ram@C.CS.CMU.EDU cc: common-lisp@SAIL.STANFORD.EDU In-Reply-To: Message-ID: <870512205052.7.RWK@WHITE-BIRD.SCRC.Symbolics.COM> Date: Tue, 12 May 1987 10:05 EDT From: Ram@C.CS.CMU.EDU Date: Tuesday, 12 May 1987 06:00-EDT From: Christopher Fry ... Is ATOM supposed to be true of non-COMMON data types as well? I think the language in the manual pretty clearly indicates that the answer is yes, although there currently isn't much discussion of extensions to the type system. CONS is a subtype of COMMON and ATOM = (NOT CONS), therefore anything not COMMON must be an ATOM. In can't see any reason for wanting thing to be otherwise. If you want to add some new object that acts like a cons but isn't, then you can make it a subtype of cons. I agree with this, except I don't believe in the type COMMON. You can get the same result by omitting references to COMMON: If it's not a subtype of CONS, by ATOM = (NOT CONS), it must be an ATOM. Although CLTL says that "implementations may not unilaterally add subtypes to COMMON", I think that there is no way for a correct program to tell that you have added a subtype except in the cases where CLTL says that some types form an exhaustive partition of another type. Not even then, because you may be partitioning an one of those types further, or extending one to contain additional elements. COMMON is a joke. Without any clear statement of just what COMMONP is supposed to buy you, it's impossible to come up with any clear view of what it should mean. What happens if Common Lisp '89 comes out, and defines 6 new types? Without any advance knowledge of how this extension would be handled, you can't write you code defensively using COMMON. Instead, in situations where you try to handle all of the types in CL, I believe you should just use ETYPECASE naming the types you actually DO handle. Extended types will either fit in with types you implemented (say a new subtype of CONS will fit in with your LIST clause), or they won't.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 12 May 87 10:28:53 EDT Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 12 May 87 07:06:37 PDT Received: ID ; Tue 12 May 87 10:05:57-EDT Date: Tue, 12 May 1987 10:05 EDT Message-ID: Sender: RAM@ From: Ram@C.CS.CMU.EDU To: common-lisp@SAIL.STANFORD.EDU Subject: atom type question Date: Tuesday, 12 May 1987 06:00-EDT From: Christopher Fry Re: atom type question ... Is ATOM supposed to be true of non-COMMON data types as well? I think the language in the manual pretty clearly indicates that the answer is yes, although there currently isn't much discussion of extensions to the type system. CONS is a subtype of COMMON and ATOM = (NOT CONS), therefore anything not COMMON must be an ATOM. In can't see any reason for wanting thing to be otherwise. If you want to add some new object that acts like a cons but isn't, then you can make it a subtype of cons. Although CLTL says that "implementations may not unilaterally add subtypes to COMMON", I think that there is no way for a correct program to tell that you have added a subtype except in the cases where CLTL says that some types form an exhaustive partition of another type. Rob  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 12 May 87 09:57:24 EDT Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 12 May 87 06:36:58 PDT Received: ID ; Tue 12 May 87 09:36:19-EDT Date: Tue, 12 May 1987 09:36 EDT Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: common-lisp@SAIL.STANFORD.EDU Subject: atom type question In-reply-to: Msg of 12 May 1987 06:00-EDT from Christopher Fry CLtL says, p. 73 "The predicate ATOM is true if its argument is not a cons." Is ATOM supposed to be true of non-COMMON data types as well? My opinion: unless the non-Common data type is a subtype of CONS, ATOM should be true of it. -- Scott  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 12 May 87 06:11:47 EDT Received: from REAGAN.AI.MIT.EDU by SAIL.STANFORD.EDU with TCP; 12 May 87 03:01:02 PDT Received: from DESCARTES.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 39231; Tue 12-May-87 06:00:35 EDT Date: Tue, 12 May 87 06:00 EDT From: Christopher Fry Subject: atom type question To: common-lisp@sail.stanford.edu Message-ID: <870512060032.8.CFRY@DESCARTES.AI.MIT.EDU> CLtL says, p. 73 "The predicate ATOM is true if its argument is not a cons." Is ATOM supposed to be true of non-COMMON data types as well?  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 9 May 87 08:11:15 EDT Received: from MC.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 9 May 87 05:00:52 PDT Date: Sat 9 May 87 07:49:55-EDT From: "Thomas M. Breuel" Subject: Smalltalk-80 Classes for Symbolics and/or CommonLisp To: pcl-hackers%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU, common-lisp%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU, info-lispm%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU, lisp-forum%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU cc: tmb%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU Message-ID: <12300974291.86.TMB@OZ.AI.MIT.EDU> I am looking for an implementation of the Smalltalk-80 classes, or a subset of them, on the Symbolics 3600 and/or under Common Lisp. I am only interested in this for new program developments, not porting, so compatibility is not a strict requirement. Implementations using flavours or PCL are fine. If you have such a beast, or a pointer to one, please let me know. Thomas. tmb@prep.ai.mit.edu -------  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 8 May 87 20:36:48 EDT Received: from HPLABS.HP.COM by SAIL.STANFORD.EDU with TCP; 8 May 87 17:24:53 PDT Received: from hplabsc by hplabs.HP.COM with TCP ; Fri, 8 May 87 16:25:43 pdt Received: by hplabsc ; Fri, 8 May 87 16:26:06 pdt Date: Fri, 8 May 87 16:26:06 pdt From: Jim Kempf Message-Id: <8705082326.AA15913@hplabsc> To: common-lisp@sail.stanford.edu Subject: Rule System in CommonLoops/CLOS Anybody out there doing a rule system in CommonLoops or CLOS? There is some interest here in such, if it is publically available. Thanks. Jim Kempf kempf@hplabs.hp.com  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 5 May 87 21:36:58 EDT Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 5 May 87 18:25:46 PDT Received: ID ; Tue 5 May 87 21:24:59-EDT Date: Tue, 5 May 1987 21:24 EDT Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: Common-Lisp@SAIL.STANFORD.EDU, AIList@STRIPE.SRI.COM Subject: Kyoto Common Lisp addendum A clarification from Mr. Yuasa: To whom it may concern, It seems that the previous note of ours, announcing that we are looking for a free channel for KCL distribution, may have brought confusions and misunderstandings to many people. It may be mostly because only the facts were mentioned, with no explanation of the background necessary to understand our intention. Our intention is to make it clear that KCL is an academic free software. By "free", we mean that any one can get it free of charge, if he agrees the conditions we put in the License Agreement. It does NOT mean that anyone has any *free*dom for KCL. In particular, we have no intention to put KCL into the public domain. We would rather like to keep the identity of KCL, so that we can keep up its high quality. Some commercial organizations are now distributing KCL and they charge a certain amount of fees to their customers. These fees are exclusively for the distribution costs and the service they offer to their customers. We require no royalties to them. We are happy if more people have got the chance to use this software. It is a voluntary work if we give them technical help on their requests. Unfortunately, some people believe that we are receiving royalties for KCL. In order to overcome this wrong belief, we decided to look for a free channel for KCL distribution. Apparently, some KCL users (including potential users) do not need any maintenance service at all. We are glad to make KCL available to such users for free. Note that we do not intend to restrict the activities of commercial organizations for KCL distribution. We intend to give a choice to the user and to make it clear what the user is charged for by commercial organizations. Note also that some KCL versions require additional programs developed by commercial organizations and we cannot force them to make their code open to the public, though we expect them to do so. We are now seriously looking for a free channel. We already found some candidates, but it will take some time before we decide the best appropriate channel for our purpose. In case we cannot find an appropriate channel, we ourselves will directly distribute KCL. However, this will require a lot of work and we will have to spend a lot of time. So, this should be the last solution. Thanks. Taiichi Yuasa, Dr. Research Institute for Mathematical Sciences Kyoto University  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 1 May 87 17:55:44 EDT Received: from JADE.Berkeley.EDU by SAIL.STANFORD.EDU with TCP; 1 May 87 02:30:08 PDT Received: by jade.berkeley.edu (5.54 (CFC 4.22.3)/1.16.13) id AA27974; Fri, 1 May 87 02:17:44 PDT Message-Id: <8705010917.AA27974@jade.berkeley.edu> Return-Path: EMAILDEV%UKACRL.BITNET@WISCVM.WISC.EDU Received: By UK.AC.RL.IB (MAILER) ; Fri, 01 May 87 10:28:41 BST Via: UK.AC.BHAM.COMP-V1; 1 MAY 87 10:28:37 BST Date: 1-MAY-1987 10:25:30 From: BATTEN%UK.AC.BHAM.COMP-V1@ac.uk To: COMMON-LISP@sail.stanford.edu Subject: Notice on Kyoto Common Lisp distribution Reply-To: Batten%bham.ac.uk@seismo.css.gov Comment: Remailed at SAIL.STANFORD.EDU after delay caused by mailing list error. Perhaps KCL could be distributed through the GNU project? I think it needs a full common lisp. ian  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 30 Apr 87 17:12:55 EDT Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 30 Apr 87 13:55:35 PDT Received: ID ; Thu 30 Apr 87 16:56:31-EDT Date: Thu, 30 Apr 1987 16:56 EDT Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: common-lisp@SAIL.STANFORD.EDU Subject: Notice on Kyoto Common Lisp distribution Mr. Yuasa asked me to pass the following announcement along to the appropriate mailing lists in the U.S.: --------------------------------------------------------------------------- We, the Kyoto Common Lisp people have decided to distribute KCL through channels other than a commercial company, free of charge out of Japan. We are looking for a best possible channel but it may take some time. Please note the following: 1. We always claimed that no fee is charged for the source of KCL, and if any fee is charged, it is exclusively for the service of distribution, maintenance, etc. of the software. 2. We never received any kind of royality out of the software or service for it up to present. Research Institute for Mathematical Sciences Kyoto University Reiji Nakajima Taiichi Yuasa Masami Hagiya  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 30 Apr 87 14:27:17 EDT Received: from ACORN.CS.ROCHESTER.EDU by SAIL.STANFORD.EDU with TCP; 30 Apr 87 11:13:10 PDT Received: from CASHEW.CS.ROCHESTER.EDU by ACORN.CS.ROCHESTER.EDU via CHAOS with CHAOS-MAIL id 11948; Thu 30-Apr-87 14:00:56 EDT Date: Thu, 30 Apr 87 14:00 EDT From: Brad Miller Subject: (REDUCE #'OVERHEAD (MAP ...)) To: MURRAY%cs.umass.edu@RELAY.CS.NET cc: common-lisp@SAIL.STANFORD.EDU, miller@ACORN.CS.ROCHESTER.EDU In-Reply-To: <8704290611.AA12297@cayuga.cs.rochester.edu> Message-ID: <870430140059.2.MILLER@CASHEW.CS.ROCHESTER.EDU> Sender: miller@cs.rochester.edu Reply-To: miller@cs.rochester.edu Organization: University of Rochester, Department of Computer Science Postal-address: 617 Hylan Building, University of Rochester, Rochester NY 14627 Phone: 716-275-7747 Date: Tue, 28 Apr 87 19:32 EDT From: MURRAY%cs.umass.edu@RELAY.CS.NET I'd like to see more on this, if possible... Code/doc, etc.. I use MAP, MAPCAR, etc. a >lot<. Brad Miller ------ miller@cs.rochester.edu miller@acorn.cs.rochester.edu miller@rochester.arpa  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 29 Apr 87 17:25:25 EDT Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 29 Apr 87 14:07:06 PDT Received: from boethius by Think.COM via CHAOS; Wed, 29 Apr 87 13:48:47 EDT Date: Wed, 29 Apr 87 13:45 EDT From: Guy Steele Subject: CLtL typos list To: DALY@ibm.com, common-lisp@sail.stanford.edu In-Reply-To: <042487.112612.daly@ibm.com> Message-Id: <870429134554.3.GLS@BOETHIUS.THINK.COM> Date: 24 April 1987, 11:26:11 EDT From: Timothy Daly To those who have asked, yes there is a CLtL typos list. The header on the file says the directory is: /u/gis/tl/sla/corr.txt dated 12/6/85 My copy has been IBMeroxed through so many generations that it is almost unreadable. From the GIS in the pathname I assume the source is Guy Steele and I believe his tent is still pitched at CMU. Guy, if you receive this, is there a later version? Tim Daly DALY@IBM.COM Yes, there is a typos list, but the version of 12/6/85 is the latest one. For everyone's information, I have not been at CMU for over four years, and have not been in Pittsburgh for over two years (though I do love to visit as often as I can). For those who care: August 1980-December 1982 Assistant Professor, Carnegie-Mellon University January 1983-January 1985 Senior Scientist, Tartan Laboratories Assistant professor on leave, CMU January 1985-present Thinking Machines Corporation, Cambridge, MA --Guy  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 29 Apr 87 01:52:39 EDT Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 28 Apr 87 22:39:47 PDT Received: from relay2.cs.net by RELAY.CS.NET id ac13592; 29 Apr 87 1:28 EDT Received: from cs.umass.edu by RELAY.CS.NET id cf04612; 29 Apr 87 1:22 EDT Date: Tue, 28 Apr 87 19:32 EDT From: MURRAY%cs.umass.edu@RELAY.CS.NET To: common-lisp@SAIL.STANFORD.EDU Subject: (REDUCE #'OVERHEAD (MAP ...)) X-VMS-To: CLMAIL > From: James Larus > I use REDUCE quite frequently and recently ran across a strange > interaction between it and another CL feature. I was trying to > execute: > (reduce #'or (mapcar ...)) If you're doing a lot of stuff like this, maybe you should look into the "Generic Mapping Functions" that Daniel Corkill has defined. They do much of what REDUCE + MAP is used for, but the notion of combining the results of mapping is generalized, and is done more efficiently since it isn't always necessary to cons up the intermediate results. MAPCAR can be thought of as using CONS to combine mapping results. The above use of OR is generally done through SOME in Common Lisp, but is expressed using the Generalized Maps as MAPC-OR. EVERY is MAPC-AND, and MAPCAN (MAPC-NCONC) functionality is done better as MAPC-CONDCONS. MAPC-MAX is a popular one, as is MAPC-+ (MAPC-UNION, MAPC-AVERAGE, etc). There are also MAPL-xxx functions that operate on sucessive sublists. We have plans to extend these to work on sequences and not just lists, but haven't done it yet (:- of course, they handle circular-lists :-) The MAP-FUN general form takes a gob of keywords to allow just about any mapping combination to be defined, and all the others are defined in terms of it. They are Functions, but have Compiler transforms that convert them into very efficient DO loops. We can probably get the code to anyone interested. - Kelly Murray University of Massachusetts  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 29 Apr 87 01:24:47 EDT Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 28 Apr 87 22:12:17 PDT Received: from relay2.cs.net by RELAY.CS.NET id ac13332; 29 Apr 87 1:05 EDT Received: from cs.umass.edu by RELAY.CS.NET id ac04612; 29 Apr 87 1:02 EDT Date: Tue, 28 Apr 87 08:50 EDT From: MURRAY%cs.umass.edu@RELAY.CS.NET To: common-lisp@SAIL.STANFORD.EDU Subject: MULTIPLE-VALUES OR X-VMS-To: CLMAIL The idea behind Multiple Values is that they are more efficient and cleaner than the basic alternatives of returning a list, or stashing values in global variables. If using Multiple Values is going to be more costly than these alternatives, then their use will not be widespread. I think they have suceeded in this regard, and believe they will become more common at time goes on. However, I think MULTIPLE-VALUE-OR is a case where it fails to live up to its efficiency goals. I have written code that needed OR which returned multiple values, (and after spending a while tracking down a strange bug that ending up being OR not returning multiple values except if its the LAST form), I wrote it as a macro. I have since changed the code to store the results in global variables because it made the function much faster, and speed was important for this particular function. I would like to think Common Lisp implementors will provide non-consing &Rest args, since they are very useful for many things, as their use on the MIT-based Lisp Machines shows, but it is not a trivial task. MULTIPLE-VALUE-OR can be implemented without them (I'll give details if anyone really wants to know), but perhaps MULTIPLE-VALUE-OR just isn't that widely applicable to warrant special treatment to make it as efficient as possible. If people are happy with that, then I can live with using uglier mechanisms when speed and efficiency are important. - Kelly  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 27 Apr 87 18:36:38 EDT Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 27 Apr 87 15:17:43 PDT Received: from LIVE-OAK.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 27 Apr 87 18:15-EDT Received: from PALLADIAN-JASPER.DialNet.Symbolics.COM by MIT-LIVE-OAK.ARPA via DIAL with SMTP id 40029; 27 Apr 87 18:15:41-EDT Received: from WHITBY.Palladian.COM by JASPER.Palladian.COM via INTERNET with SMTP id 34140; 27 Apr 87 16:44:00-EDT Date: Mon, 27 Apr 87 16:45 EDT From: Don Morrison Subject: (reduce #'or ...) To: larus@paris.Berkeley.EDU cc: common-lisp@sail.stanford.edu In-Reply-To: <8704271906.AA22811@paris.Berkeley.EDU> Message-ID: <870427164540.5.DFM@WHITBY.PALLADIAN.COM> Reply-To: Don Morrison Date: Mon, 27 Apr 87 12:06:52 PDT From: larus@paris.Berkeley.EDU (James Larus) I use REDUCE quite frequently and recently ran across a strange interaction between it and another CL feature. I was trying to execute: (reduce #'or (mapcar ...)) Will using "some" solve your problems? I believe that (some #'f L) is equivalent to (reduce #'(lambda (x y) (or x y)) (mapcar #'f L) :initial-value nil), except that in most implementations it's faster and conses less, so long as f doesn't have side effects. The fact that and and or only evaluate as many of their arguments as necessary is hardwired into most LISPers spines, and many believe that using it as a control construct is often more perspicuous than the alternatives. I think it most unlikely that it'll be changed.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 27 Apr 87 17:06:58 EDT Received: from CS.ROCHESTER.EDU by SAIL.STANFORD.EDU with TCP; 27 Apr 87 13:38:16 PDT Received: by cayuga.cs.rochester.edu (5.52/a) id AA05810; Mon, 27 Apr 87 16:37:37 EDT Received: from loopback by ur-seneca.arpa id AA08517 (4.12z); Mon, 27 Apr 87 16:37:26 edt Message-Id: <8704272037.8517@ur-seneca.arpa> To: larus@paris.Berkeley.EDU (James Larus) Cc: common-lisp@sail.stanford.edu Subject: Re: (reduce #'or ...) In-Reply-To: Your message of Mon, 27 Apr 87 12:06:52 PDT. <8704271906.AA22811@paris.Berkeley.EDU> Date: Mon, 27 Apr 87 16:37:18 -0500 From: quiroz@rochester.arpa I agree it is a bad surprise to rediscover that OR is not a function, it happens to me rather often. These days I rely on things like: (some #' ) whenever I feel like doing (reduce #'or (mapcar #' )) I hope that is more or less what you need. (The s need not be the same, needless is to say the example above is not a mechanical equivalence.) =Cesar -------- Cesar Augusto Quiroz Gonzalez Department of Computer Science {allegra|seismo}!rochester!quiroz University of Rochester or Rochester, NY 14627 quiroz@cs.rochester.edu  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 27 Apr 87 17:05:58 EDT Received: from AEROSPACE.AERO.ORG by SAIL.STANFORD.EDU with TCP; 27 Apr 87 13:39:39 PDT Received: by aerospace.aero.org (5.54/6.0.GT) id AA11832; Mon, 27 Apr 87 13:31:39 PDT Posted-Date: Mon, 27 Apr 87 13:31:34 -0800 Message-Id: <8704272031.AA11832@aerospace.aero.org> To: common-lisp@sail.stanford.edu Subject: Very BIG "T" Date: Mon, 27 Apr 87 13:31:34 -0800 From: coffee@aerospace.aero.org > The only argument I can see for _requiring_ return of strictly T or NIL... > is that it promotes portability... Excuse me -- I missed the earlier message that observes how unpleasant it would be to keep a big, otherwise unused object around merely because it's being passed around as the non-NIL returned from a predicate. Good point. - Pc^2  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 27 Apr 87 15:27:47 EDT Received: from [128.32.150.46] by SAIL.STANFORD.EDU with TCP; 27 Apr 87 12:06:26 PDT Received: by paris.Berkeley.EDU (3.2/1.22) id AA22811; Mon, 27 Apr 87 12:06:56 PDT From: larus@paris.Berkeley.EDU (James Larus) Message-Id: <8704271906.AA22811@paris.Berkeley.EDU> To: common-lisp@sail.stanford.edu Subject: (reduce #'or ...) Date: Mon, 27 Apr 87 12:06:52 PDT I use REDUCE quite frequently and recently ran across a strange interaction between it and another CL feature. I was trying to execute: (reduce #'or (mapcar ...)) The problem is that OR is a macro, not a function, so that the idiom #'OR is disallowed by some (all?) Lisps. Even if the idiom was legal, REDUCE could not funcall OR. I can always define my own OR function, which is strict in both arguments, but that does not really fix the problem. I doubt that I am the first or last person to stumble across this interaction. I'd like to suggest to the committee cleaning up CL that they try unraveling the multiple semantics given to OR and AND. I think that the language would be cleaner if logical operations were seperated from control-flow. /Jim  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 27 Apr 87 14:38:06 EDT Received: from AEROSPACE.AERO.ORG by SAIL.STANFORD.EDU with TCP; 27 Apr 87 11:18:48 PDT Received: by aerospace.aero.org (5.54/6.0.GT) id AA10100; Mon, 27 Apr 87 11:15:03 PDT Posted-Date: Mon, 27 Apr 87 11:14:52 -0800 Message-Id: <8704271815.AA10100@aerospace.aero.org> To: common-lisp@sail.stanford.edu Cc: Masinter.pa@xerox.com Subject: Cleaning up predicate returns Date: Mon, 27 Apr 87 11:14:52 -0800 From: coffee@aerospace.aero.org > From: Masinter.pa@xerox.com > Subject: Re: A simple question > To: coffee@aerospace.aero.org > If this were to be "cleaned up", in which way should it go? > Should NOT, NULL, EQ and friends be required to return T or NIL always, > rather than the less-specified "true" and NIL? Would this adversely > affect performance? Are there any current implementations which don't > return T or NIL for predicates? I haven't put together a complete clean-up proposal yet, part of which would certainly be discussion of implementation costs (regarding which I have a bit of research to do!). We have to be able to take the type of a NIL, and to recognize NIL as a symbol, etc., so we can't realistically have (for example) ATOM return its argument if true and NIL otherwise. With CONSP, NUMBERP, STRINGP, INTEGERP, and all of the other predicates on CLtL 74-76 except LISTP & COMMONP, however, there's no ambiguity in returning the argument if true and NIL otherwise. I have grown accustomed to this behavior in the ExperTelligence Lisps, and have to remind myself when writing code that I'll need to port that this "filter" view of a predicate (as opposed to the traditional "Boolean" view) is not portable at this time. We have certainly grown used to the filter treatment of AND and OR, so I don't think we're Boolean bigots here, and requiring this would not break code unless it does things like testing for EQness to T instead of just using the returned value as the Boolean. The only argument I can see for _requiring_ return of strictly T or NIL, in these cases or in all of the currently indeterminate cases -- and it may be a good argument at that -- is that it promotes portability by preventing programmer reliance on a discretionary implementation that might, for example, have LISTP return the object if it is a non-empty list and return merely T for the empty list (nil otherwise). I don't favor this as standard behavior, since LISTP could then return either a list or the T atom as "true," meaning that code would need to check for each and be just as ugly (or worse) than if return is limited (or assumed to be limited) to T or NIL strictly. I stress that this is a "wouldn't it be nice if," based on my own ideas of what makes good-looking code, _not_ yet researched to the point that I call it a "proposal." The extent to which I get flamed will probably determine whether it dies immediately :-). I've run it past one other Lisper here and been "Boolean bashed": he thought this style much less readable. Of course, no one would _have_ to use the value as anything but a Boolean. Regards, Pc^2  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 27 Apr 87 14:25:47 EDT Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 27 Apr 87 11:09:38 PDT Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 125233; Mon 27-Apr-87 14:05:18 EDT Date: Mon, 27 Apr 87 14:04 EDT From: David A. Moon Subject: MULTPLE-VALUE-OR &rest args To: MURRAY%cs.umass.edu@RELAY.CS.NET cc: common-lisp@SAIL.STANFORD.EDU In-Reply-To: The message of 21 Apr 87 15:45 EDT from MURRAY%cs.umass.edu@RELAY.CS.NET Message-ID: <870427140455.2.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Tue, 21 Apr 87 15:45 EDT From: MURRAY%cs.umass.edu@RELAY.CS.NET >I don't think this conclusion follows from your previous paragraph. >If the proposed MULTIPLE-VALUE-OR can easily be implemented in terms of >existing primitives, such as MULTIPLE-VALUE-CALL, and would be efficient >if there were non-consing &rest arguments, and non-consing &rest arguments >are desirable for other reasons, then I think a more logical conclusion is >"because non-consing &rest arguments can only be done efficiently by low-level >implementation-specific code, they should be in Common Lisp." Are you just pointing out a flaw in my logic, or are you suggesting that Common Lisp REQUIRE certain &rest args to not cons? I was suggesting that a declaration which, like all declarations, encourages but does not require the compiler to generate a certain kind of code, could be added to Common Lisp. If it were added, it would be more broadly applicable than MULTIPLE-VALUE-OR, and would eliminate the need for MULTIPLE-VALUE-OR as a special language construct since it would make the portable definition of MULTIPLE-VALUE-OR efficient. The last sentence was not meant to logically follow from the previous -- I was merely re-iterating my point in requesting a MULTIPLE-VALUE-OR form, which is it can be efficiently implemented WITHOUT non-consing rest args. I might also add that using MULTIPLE-VALUE-CALL is going to require both a Lambda and a Block, in which the Return-From will end up being a Throw. You are assuming that (multiple-value-call #'(lambda ...) ...) cannot be compiled as efficiently as ((lambda ...) ...). I see no justification for assuming that.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 27 Apr 87 13:27:02 EDT Received: from seismo.CSS.GOV by SAIL.STANFORD.EDU with TCP; 27 Apr 87 10:08:21 PDT Received: from unido.UUCP by seismo.CSS.GOV (5.54/1.14) with UUCP id AA04143; Mon, 27 Apr 87 13:08:25 EDT Received: by unido.uucp with uucp; Mon, 27 Apr 87 18:03:36 +0100 Received: by gmdzi.UUCP id AA16067; Mon, 27 Apr 87 15:35:30 -0100 Date: Mon, 27 Apr 87 15:34+0100 From: "Juergen Christoffel" Subject: Pronunciation To: common-lisp@sail.stanford.edu Cc: KMP@stony-brook.scrc.symbolics.com In-Reply-To: <870426024148.2.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> Message-Id: <870427153401.6.JC@LISPM-1.GMD> Date: Sun, 26 Apr 87 02:41 EDT From: "Kent M Pitman" Could we please terminate this discussion before it leads to a rush of useless mail. [...] This mailing list reaches a huge number of people, many of whom are quite busy. [...] Kent, I agree. And, *please*, all of you listeners: when composing a reply, think twice before yanking in the whole message which spawned your reply. I don't need the original message that many times sent to me; normally it should be sufficient, to quote a part of it. So, please, stop this annoying habbit. Thank you, JC  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 26 Apr 87 02:51:16 EDT Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 25 Apr 87 23:41:34 PDT Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 124696; Sun 26-Apr-87 02:41:53 EDT Date: Sun, 26 Apr 87 02:41 EDT From: Kent M Pitman Subject: Pronunciation To: zs01#@andrew.cmu.edu cc: common-lisp@SAIL.STANFORD.EDU In-Reply-To: Message-ID: <870426024148.2.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> Could we please terminate this discussion before it leads to a rush of useless mail. I'm sure there are as many people who would suggest that `the other' pronunciation is better. It doesn't matter who's right. This mailing list reaches a huge number of people, many of whom are quite busy. Also, many mailers get bogged down a long time delivering each piece of mail sent. It's not worth the time spent either by the mailers or by the readers of the mail to debate issues which have such a large potential for going on forever, so little chance of being usefully resolved, and so little value even if resolved.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 26 Apr 87 00:42:52 EDT Received: from PO5.ANDREW.CMU.EDU by SAIL.STANFORD.EDU with TCP; 25 Apr 87 21:32:38 PDT Received: by po5.andrew.cmu.edu (5.54/3.15) id for common-lisp@SAIL.STANFORD.EDU; Sun, 26 Apr 87 00:33:24 EDT Received: via switchmail; Sun, 26 Apr 87 00:33:21 edt Received: FROM z.itc.cmu.edu VIA queuemail ID ; Sun, 26 Apr 87 00:32:36 edt Received: FROM z.itc.cmu.edu VIA qmail ID ; Sun, 26 Apr 87 00:30:17 edt Message-Id: X-Trace: MS Version 3.22 on ibm032 host z.itc.cmu.edu, by zs01 (623). Date: Sun, 26 Apr 87 00:30:14 edt From: zs01#@andrew.cmu.edu (Zalman Stern) To: common-lisp@SAIL.STANFORD.EDU Subject: Re: Pronunciation Cc: veracsd@A.ISI.EDU In-Reply-To: <[A.ISI.EDU]24-Apr-87 23:01:01.VERACSD> >>>>What is the proper pronunciation of PROG? Rhymes with "frog". And most code (with the exception of macro expansions) that uses them should croak. Sincerely, Zalman Stern  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 25 Apr 87 04:02:26 EDT Received: from A.ISI.EDU by SAIL.STANFORD.EDU with TCP; 25 Apr 87 00:51:48 PDT Date: 24 Apr 1987 23:01-EDT Sender: VERACSD@A.ISI.EDU Subject: Pronunciation From: VERACSD@A.ISI.EDU To: common-lisp@SAIL.STANFORD.EDU Cc: veracsd@A.ISI.EDU Message-ID: <[A.ISI.EDU]24-Apr-87 23:01:01.VERACSD> What is the proper pronunciation of PROG?  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 25 Apr 87 02:19:28 EDT Received: from AEROSPACE.AERO.ORG by SAIL.STANFORD.EDU with TCP; 24 Apr 87 23:07:25 PDT Received: by aerospace.aero.org (5.54/6.0.GT) id AA08928; Fri, 24 Apr 87 22:53:56 PST Posted-Date: Fri, 24 Apr 87 22:53:47 -0800 Message-Id: <8704250653.AA08928@aerospace.aero.org> To: Russ Smith Cc: common-lisp@sail.stanford.edu Subject: Re: A simple question In-Reply-To: Your message of 23 Apr 1987 13:42:18 EST (Thu). <546201738/smith@nrl-aic> Date: Fri, 24 Apr 87 22:53:47 -0800 From: coffee@aerospace.aero.org Page 71 of CLtL resolves any ambiguity on page 73 when it says, "We say that a predicate is true when it returns a non-nil value, and is false when it returns nil..."; thus implementors are free to let an expression like (null (null 'foo)) return GRAND_PIANO if they wish, but portability- oriented programmers are _not_ free to assume anything but non-nilness in the returned value. Personally, NUMBERP is the one that bothers me: it would be so nice to get back the argument if it is numeric, nil otherwise, but CLtL merely says that the value will be "true" and this is all that one may safely assume. Saying, as CLtL does, that (numberp x) is identical (as in three horizontal bars) to (typep x 'number) even tends to _suggest_ that the value _will_ be strictly T or nil, a loss in my opinion. Thanks for bringing this up--rationalization of this issue may be worth fighting for in the ANSI Common Lisp committee's "clean-up of Steele" phase. - Pc^2  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 24 Apr 87 11:55:08 EDT Received: from IBM.COM by SAIL.STANFORD.EDU with TCP; 24 Apr 87 08:42:59 PDT Date: 24 April 1987, 11:26:11 EDT From: Timothy Daly To: common-lisp@sail.stanford.edu Message-Id: <042487.112612.daly@ibm.com> Subject: CLtL typos list To those who have asked, yes there is a CLtL typos list. The header on the file says the directory is: /u/gis/tl/sla/corr.txt dated 12/6/85 My copy has been IBMeroxed through so many generations that it is almost unreadable. From the GIS in the pathname I assume the source is Guy Steele and I believe his tent is still pitched at CMU. Guy, if you receive this, is there a later version? Tim Daly DALY@IBM.COM  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 24 Apr 87 11:13:21 EDT Received: from NRL-AIC.ARPA by SAIL.STANFORD.EDU with TCP; 24 Apr 87 07:52:09 PDT Return-Path: Received: Fri, 24 Apr 87 06:19:15 est by nrl-aic.ARPA id AA01286 Date: 24 Apr 1987 06:01:42 EST (Fri) From: Russ Smith Subject: Re: A simple question To: David A. Moon Cc: spears@nrl-aic.arpa, common-lisp@sail.stanford.edu Message-Id: <546260502/smith@nrl-aic> In-Reply-To: David A. Moon's message of Thu, 23 Apr 87 1550 EDT (not (null '(a b c)) returns the correct value (CLtL definition of NOT, not Sun's...which, though apparently returning the correct value, is not documented entirely correctly). But this does not answer the question of what NULL is supposed to return. The definition given on page 73 is arguably ambiguous. What does "same operation" mean? Is this equivalence (one is just an alias for the other)? Or is it merely a way of saying that the functionality is somewhat similar as far as various interesting things are concerned? Note, for example, that the TYPEP and EQ triple-line equivalences given below the definition return true or false, not T or NIL. I remain perplexed.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 24 Apr 87 11:01:33 EDT Received: from DECWRL.DEC.COM by SAIL.STANFORD.EDU with TCP; 24 Apr 87 07:39:50 PDT Received: from decvax.dec.com by decwrl.dec.com (5.54.3/4.7.34) id AA28946; Fri, 24 Apr 87 06:40:48 PST Received: from admin.uucp (mcae) by cvbnet.uucp (2.0/SMI-2.0) id AA02955; Fri, 24 Apr 87 10:16:40 est Received: by admin.uucp (1.1/SMI-3.0DEV3) id AA13156; Fri, 24 Apr 87 10:12:41 EST Date: Fri, 24 Apr 87 10:12:41 EST From: decvax!cvbnet!admin!tbardasz@decwrl.DEC.COM (Ted Bardasz) Message-Id: <8704241512.AA13156@admin.uucp> To: cvbnet!decvax!decwrl!SAIL.STANFORD.EDU!COMMON-LISP@decwrl.DEC.COM Subject: Mailing List Hello, Could you please add me to the mailing list for: COMMON LISP My mail address is: decvax!cvbnet!basie!tbardasz@decwrl.dec.com Thank you very much, Ted Bardasz at Computervision Corp.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 24 Apr 87 02:49:41 EDT Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 23 Apr 87 23:38:15 PDT Received: by navajo.stanford.edu; Thu, 23 Apr 87 22:37:32 PST Received: from bhopal.edsel.com by edsel.uucp (2.2/SMI-2.0) id AA25848; Thu, 23 Apr 87 22:26:02 pst Received: by bhopal.edsel.com (3.2/SMI-3.2) id AA06964; Thu, 23 Apr 87 23:23:38 PDT Date: Thu, 23 Apr 87 23:23:38 PDT From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White) Message-Id: <8704240623.AA06964@bhopal.edsel.com> To: navajo!smith%nrl-aic.ARPA@navajo.stanford.edu Cc: navajo!common-lisp%sail@navajo.stanford.edu, navajo!spears%nrl-aic.arpa@navajo.stanford.edu In-Reply-To: Russ Smith's message of 23 Apr 1987 13:42:18 EST (Thu) Subject: A simple question What is the version number of your Sun Common Lisp ? try calling (lisp-implementation-version), or look at the initial greeting. Version 2 (and it's follow-ons) has been current since December 1986, and doesn't have the pessimization you reported, namely that (not (not x)) ==> x. Version 1 appears to have the problem. As has often been remarked, "The source of all bugs is pre-mature optimization." -- JonL --  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 23 Apr 87 23:35:39 EDT Received: from SCRC-YUKON.ARPA by SAIL.STANFORD.EDU with TCP; 23 Apr 87 20:22:00 PDT Received: from WHITE-BIRD.SCRC.Symbolics.COM by YUKON.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 198124; Thu 23-Apr-87 23:22:02 EDT Date: Thu, 23 Apr 87 23:21 EDT From: Robert W. Kerns Subject: Streams To: James R. Rauen cc: common-lisp@sail.stanford.edu In-Reply-To: <8704221755.AA00926@CLS.LCS.MIT.EDU> Message-ID: <870423232136.2.RWK@WHITE-BIRD.SCRC.Symbolics.COM> Date: 22 Apr 1987 1254-EST (Wednesday) From: rauen@CLS.LCS.MIT.EDU (James R. Rauen) I'm encountering some difficulties with synonym streams. Let's say I do the following: (defvar a *standard-input*) (defvar b *standard-output*) (defvar c (make-synonym-stream 'a)) (defvar d (make-synonym-stream 'b)) (defvar e (make-two-way-stream c d)) (setq a *standard-output*) Now stream C has been turned into an output stream. What is E now? Illegal. It's first argument is required to be an input stream. What does it answer to INPUT-STREAM-P? Probably T, in in many implementations. NIL if it actually checks its input stream. I can also cause trouble by changing the value of a synonym stream's variable from a character stream to a byte stream. Sure. CL gives you enough rope to hang yourself.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 23 Apr 87 22:13:36 EDT Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 23 Apr 87 18:58:27 PDT Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 123583; Thu 23-Apr-87 21:57:24 EDT Date: Thu, 23 Apr 87 21:57 EDT From: Kent M Pitman Subject: A simple question To: smith@NRL-AIC.ARPA, spears@NRL-AIC.ARPA cc: RWK@STONY-BROOK.SCRC.Symbolics.COM, DCP@STONY-BROOK.SCRC.Symbolics.COM, Common-Lisp@SAIL.STANFORD.EDU In-Reply-To: <870423210941.6.RWK@WHITE-BIRD.SCRC.Symbolics.COM> Message-ID: <870423215712.5.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> Some miscellaneous observations on this issue... In my opinion, it is not appropriate to document that NOT and NULL are the same even if they have identical behavior. If their intended uses differ (as I would claim they do), they are not interchangeable. Perhaps we can get this wording fixed in the upcoming manual. People should use NULL for lists and not for predicates as a matter of style. Although (NULL (NULL x)) is not "an error" in the CLtL sense, I'd put red marks next to it if I were teaching a programming course and someone turned in a program that did it. By the way, there are GC implications to returning the thing itself and not T. If the x was a large structure that was not otherwise pointed to, it would be a shame for it to not get GC'd just because someone was passing it around for truth value. Also, there are data abstraction issues. You run the risk of accidentally violating the integrity of private data structures if you give them away, and the compilers should be leary of optimizations that can do this kind of thing. In T (Yale Scheme), we actually created a whole line of operators called MEMBER?, ASSOC?, etc. which were like MEMBER, ASSOC, etc. but returned T/NIL for cases where abstraction and/or GC behavior was an issue. On the LispM, this optimization would be particularly funny for stack lists since I guess you could claim that a stack list could `rightly' be returned here (it being non-null, after all, regardless of what its ever-varying contents were). If you never used it for anything other than its existence and non-nullness... This optimization, by the way, is related to the (+ X 0) => X optimization, which can be pretty bizarre error-checking-wise when X is a string or some other non-addable quantity and SAFETY is high (because no error may get signalled where the intuition may be that one should be). Presumably the next CL standard should take some stand on optimizations like this so that users can know what to expect (or know to expect nothing) and implementors can know what to feel comfortable about providing.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 23 Apr 87 21:34:14 EDT Received: from SCRC-YUKON.ARPA by SAIL.STANFORD.EDU with TCP; 23 Apr 87 18:22:01 PDT Received: from WHITE-BIRD.SCRC.Symbolics.COM by YUKON.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 198073; Thu 23-Apr-87 21:09:50 EDT Date: Thu, 23 Apr 87 21:09 EDT From: Robert W. Kerns Subject: A simple question To: David C. Plummer cc: Russ Smith , common-lisp@sail.stanford.edu, spears@NRL-AIC.ARPA In-Reply-To: <870423155440.5.DCP@KOYAANISQATSI.S4CC.Symbolics.COM> Message-ID: <870423210941.6.RWK@WHITE-BIRD.SCRC.Symbolics.COM> Date: Thu, 23 Apr 87 15:54 EDT From: David C. Plummer Page 73 says several things. It says NULL returns true if the argument is (). To me at least, this implies NULL is used for flow/predicate and not for value. It goes on to say that NULL is the same as NOT. NOT (page 82) explicitly says NOT returns T or NIL. It also says NULL is the same as NOT. If you believe in transitive closure, one would conclude that (null (null something)) returns strictly T or NIL. Poor programs may be broken by this; better programs never use (null (null ...)) but instead express the better intent (not (null ...)). Personally, I would consider (null (null ...)) to be "an error" and that the compiler for the Sun should be able to get away with returning the inner argument. Things get worse when you separate nil and (). I disagree; after all, NOT is the same as NULL. (NOT (NULL ))?  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 23 Apr 87 16:27:16 EDT Received: from IMSSS by SAIL with PUP; 23-Apr-87 13:13 PDT Date: 23 Apr 1987 1310-PDT From: Rem@IMSSS Subject: Just for fun (NULL of NULL is identity) To: COMMON-LISP@SU-AI That "despicable" behaviour of NULL on the SUN when compiled, namely that (NULL (NULL 'FOO)) returns FOO instead of T, could have been obtained interpreted too if something like this had been done: (SETQ G*NON-NULL-VALUE 'T) ;Initial value (DEFUN MY-NULL (LL) (COND (LL (PROGN (SETQ G*NON-NULL-VALUE LL) 'NIL)) (T G*NON-NULL-VALUE))) Does CLtL explicitly forbid this? I don't think so. It defines "true" as anything not NIL, and says NULL is "true" if it argument is (). But it *does* say that (null x) is the same as (eq x '()), so presumably if you hack NULL then EQ must be hacked too, and also typep. -------  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 23 Apr 87 16:13:27 EDT Received: from [128.81.51.3] by SAIL.STANFORD.EDU with TCP; 23 Apr 87 12:55:02 PDT Received: from KOYAANISQATSI.S4CC.Symbolics.COM by DIAMOND.S4CC.Symbolics.COM via CHAOS with CHAOS-MAIL id 79392; Thu 23-Apr-87 15:54:33 EDT Date: Thu, 23 Apr 87 15:54 EDT From: David C. Plummer Subject: A simple question To: Russ Smith , common-lisp@sail.stanford.edu cc: spears@NRL-AIC.ARPA In-Reply-To: <546201738/smith@nrl-aic> Message-ID: <870423155440.5.DCP@KOYAANISQATSI.S4CC.Symbolics.COM> Date: 23 Apr 1987 13:42:18 EST (Thu) From: Russ Smith Page 73 contains a definition for NULL that may or may not say that NULL returns strictly T or NIL (see also page 82). What's the poop? Page 73 says several things. It says NULL returns true if the argument is (). To me at least, this implies NULL is used for flow/predicate and not for value. It goes on to say that NULL is the same as NOT. NOT (page 82) explicitly says NOT returns T or NIL. It also says NULL is the same as NOT. If you believe in transitive closure, one would conclude that (null (null something)) returns strictly T or NIL. Poor programs may be broken by this; better programs never use (null (null ...)) but instead express the better intent (not (null ...)). Personally, I would consider (null (null ...)) to be "an error" and that the compiler for the Sun should be able to get away with returning the inner argument. Things get worse when you separate nil and ().  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 23 Apr 87 16:06:47 EDT Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 23 Apr 87 12:50:15 PDT Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 123106; Thu 23-Apr-87 15:50:29 EDT Date: Thu, 23 Apr 87 15:50 EDT From: David A. Moon Subject: A simple question To: Russ Smith cc: common-lisp@sail.stanford.edu, spears@NRL-AIC.ARPA In-Reply-To: <546201738/smith@nrl-aic> Message-ID: <870423155015.3.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: 23 Apr 1987 13:42:18 EST (Thu) From: Russ Smith The "Cc"ed individual above uncovered an interesting difference between interpreted and compiled CommonLisp on a Sun workstation that generated a splurge of conversation here. In particular: (null (null '(a b c)) returns T when interpreted, but returns (a b c) when compiled. My question for you: Does (not (null '(a b c)) do the same thing in the same implementation, or does it always return T?  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 23 Apr 87 15:24:24 EDT Received: from NRL-AIC.ARPA by SAIL.STANFORD.EDU with TCP; 23 Apr 87 12:05:27 PDT Return-Path: Received: Thu, 23 Apr 87 14:05:35 est by nrl-aic.ARPA id AA10064 Date: 23 Apr 1987 13:42:18 EST (Thu) From: Russ Smith Subject: A simple question To: common-lisp@sail.stanford.edu Cc: spears@nrl-aic.arpa Message-Id: <546201738/smith@nrl-aic> The "Cc"ed individual above uncovered an interesting difference between interpreted and compiled CommonLisp on a Sun workstation that generated a splurge of conversation here. In particular: (null (null '(a b c)) returns T when interpreted, but returns (a b c) when compiled. On reading the **Sun** CommonLisp manual, this behavior, while possibly despicable, is permitted. On reading THE CommonLisp manual, things are not quite as obvious. Page 73 contains a definition for NULL that may or may not say that NULL returns strictly T or NIL (see also page 82). What's the poop?  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 22 Apr 87 14:30:13 EDT Received: from CLS.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 22 Apr 87 11:16:37 PDT Received: by CLS.LCS.MIT.EDU (4.12/4.7); Wed, 22 Apr 87 12:55:04 est From: rauen@CLS.LCS.MIT.EDU (James R. Rauen) Message-Id: <8704221755.AA00926@CLS.LCS.MIT.EDU> Date: 22 Apr 1987 1254-EST (Wednesday) To: common-lisp@sail.stanford.edu Subject: Streams I'm encountering some difficulties with synonym streams. Let's say I do the following: (defvar a *standard-input*) (defvar b *standard-output*) (defvar c (make-synonym-stream 'a)) (defvar d (make-synonym-stream 'b)) (defvar e (make-two-way-stream c d)) (setq a *standard-output*) Now stream C has been turned into an output stream. What is E now? What does it answer to INPUT-STREAM-P? I can also cause trouble by changing the value of a synonym stream's variable from a character stream to a byte stream. --Jim  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 22 Apr 87 02:27:57 EDT Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 21 Apr 87 23:09:30 PDT Received: from relay2.cs.net by RELAY.CS.NET id ab26960; 22 Apr 87 2:07 EDT Received: from cs.umass.edu by RELAY.CS.NET id bl27373; 22 Apr 87 1:58 AST Date: Tue, 21 Apr 87 15:45 EDT From: MURRAY%cs.umass.edu@RELAY.CS.NET To: common-lisp@SAIL.STANFORD.EDU Subject: MULTPLE-VALUE-OR &rest args X-VMS-To: CLMAIL >I think more to the heart of the matter is that Common LISP needs a way to grab, >inspect, and pass on an unknown number of multiple values without consing > (and yes, avoiding consing can be crucial for real applications > give the current state of the art for garbage collection > on conventional hardware). It's possible that, using >multiple-value-call, simply having some way of >doing non-consing &rest arguments may be sufficient. ... I whole-heartly agree that A) Unneccessary consing should always be avoided, B) it would be great to have &rest args that don't cons. I currently have plans to have a STACK-LIST declaration that declares that a &Rest is stack-allocated (as well as WITH-STACK-LIST, ala Lisp Machines) in my system. I would suggest that others consider this as well, but of course, it is only a declaration that could be ignored. (I already avoid consing for (&Rest ignore), which should be easy). My point is that MULTIPLE-VALUE-OR can only be done efficiently by low-level implementation-specific code, and thats why it should be in Common Lisp. >I don't think this conclusion follows from your previous paragraph. >If the proposed MULTIPLE-VALUE-OR can easily be implemented in terms of >existing primitives, such as MULTIPLE-VALUE-CALL, and would be efficient >if there were non-consing &rest arguments, and non-consing &rest arguments >are desirable for other reasons, then I think a more logical conclusion is >"because non-consing &rest arguments can only be done efficiently by low-level >implementation-specific code, they should be in Common Lisp." Are you just pointing out a flaw in my logic, or are you suggesting that Common Lisp REQUIRE certain &rest args to not cons? The last sentence was not meant to logically follow from the previous -- I was merely re-iterating my point in requesting a MULTIPLE-VALUE-OR form, which is it can be efficiently implemented WITHOUT non-consing rest args. I might also add that using MULTIPLE-VALUE-CALL is going to require both a Lambda and a Block, in which the Return-From will end up being a Throw. It might not Cons, but I wouldn't call that "Efficient" (Maybe Symbolics does function calls and throws more efficiently than a couple tests and a branch? If so, that is exactly why it should be in Common Lisp -- You do it your way, I'll do it mine). >By the way, I don't think a declaration for non-consing &rest arguments >should be necessary. It should be simple enough for any compiler to >recognize special cases such as the following, once implementors' >attention has been drawn to the desirability of such optimizations. Another >way of saying the same thing is that I think consing is an implementation >issue, not a language issue, just as much as whether integer multiplication >takes 1 microsecond or 10 microseconds. > (lambda (&rest values) > (when (first values) > (return-from block (values-list values)))) I guess you are saying Common Lisp shouldn't REQUIRE any &rest args not to cons. I certainly agree - it is properly in the domain of Optimizations. A declaration may not be always be necessary, but this is just about in the same category as determining whether a function has side-effects. You can sometimes prove it doesn't, but why go to all the bother if a very knowledgable and intelligent (compared to a compiler) programmer can simply tell you? - Kelly Murray  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 21 Apr 87 20:07:46 EDT Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 21 Apr 87 16:54:53 PDT Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 121218; Tue 21-Apr-87 19:54:57 EDT Date: Tue, 21 Apr 87 19:54 EDT From: David A. Moon Subject: MULTIPLE-VALUES, consing, and clarity To: goldman@VAXA.ISI.EDU cc: COMMON-LISP@SAIL.STANFORD.EDU In-Reply-To: <8704212004.AA03718@vaxa.isi.edu> Message-ID: <870421195424.1.MOON@EUPHRATES.SCRC.Symbolics.COM> This was discussed at enormous length early in the design of Common Lisp. Most of the mail discussions, draft manuals, and ballots have been archived, so if you really care that much, it's possible to reconstruct the discussion. I'll just say here that at one time MULTIPLE-VALUE-BIND did allow & keywords, but it was changed.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 21 Apr 87 18:20:35 EDT Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 21 Apr 87 15:06:51 PDT Received: from Cabernet.ms by ArpaGateway.ms ; 21 APR 87 15:07:53 PDT Date: 21 Apr 87 15:07 PDT From: Pavel.pa@Xerox.COM Subject: Re: MULTIPLE-VALUES, consing, and clarity In-reply-to: goldman@VAXA.ISI.EDU's message of 21 Apr 87 12:04 PST (Tuesday) To: goldman@VAXA.ISI.EDU cc: COMMON-LISP@SAIL.STANFORD.EDU Message-ID: <870421-150753-2649@Xerox> If you want to say (MULTIPLE-VALUE-BIND LAMBDA-LIST values-form ...) you can always say instead (multiple-value-call #'(lambda LAMBDA-LIST ...) values-form) The proverbial good compiler can still do the optimization you mentioned. If you don't like the syntax (and who could blame you), you could always make a macro for it. Pavel  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 21 Apr 87 17:41:32 EDT Received: from [128.81.51.3] by SAIL.STANFORD.EDU with TCP; 21 Apr 87 14:25:13 PDT Received: from KOYAANISQATSI.S4CC.Symbolics.COM (KOYAANISQATSI.S4CC.Symbolics.COM) by DIAMOND.S4CC.Symbolics.COM via INTERNET with SMTP id 78601; 21 Apr 87 17:24:18 EDT Date: Tue, 21 Apr 87 17:24 EDT From: David C. Plummer Subject: MULTIPLE-VALUES, consing, and clarity To: goldman@VAXA.ISI.EDU, COMMON-LISP@SAIL.STANFORD.EDU In-Reply-To: <8704212004.AA03718@vaxa.isi.edu> Message-ID: <870421172431.7.DCP@KOYAANISQATSI.S4CC.Symbolics.COM> Date: 21 Apr 1987 1204-PST (Tuesday) From: goldman@VAXA.ISI.EDU I'm sure this must have been suggested long ago, but I'd at least like to know why it is not part of common lisp: MULTIPLE-VALUE-CALL. (Naively, MULTIPLE-VALUE-BIND is a macro that turns into MULTIPLE-VALUE-CALL with a lambda-list of (&optional ,@varlist &rest ignore) ]  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 21 Apr 87 16:18:40 EDT Received: from VAXA.ISI.EDU by SAIL.STANFORD.EDU with TCP; 21 Apr 87 13:03:26 PDT Received: by vaxa.isi.edu (4.12/4.7) id AA03718; Tue, 21 Apr 87 12:04:52 pst Message-Id: <8704212004.AA03718@vaxa.isi.edu> Date: 21 Apr 1987 1204-PST (Tuesday) To: COMMON-LISP@SAIL.STANFORD.EDU From: goldman@VAXA.ISI.EDU Subject: MULTIPLE-VALUES, consing, and clarity Cc: goldman@VAXA.ISI.EDU I'm sure this must have been suggested long ago, but I'd at least like to know why it is not part of common lisp: From the point of view of writing clear code, as well as just good old symmetry, it seems unfortunate that we have the richness of LAMBDA-LISTs to pass information from calling environments into functions, but only the impoverished (MULTIPLE-VALUE-BIND Var* values-form ...) for communication in the reverse direction. I have found numerous cases where my code would be much clearer if I could write (MULTIPLE-VALUE-BIND LAMBDA-LIST values-form ...), using &rest, &key, and &optional receive parameters to help me "destructure" the information coming back from values-form -- including default values for optional parameters. I bring this up (again?) now only because of recent discussions about multiple values and consing. If I could write (multiple-value-bind (&rest values) values-producer (cond ((test values) (values-list values)) ...)) a good compiler could recognize that there was no need to cons up a list of values only to spread (a tail of) the list back onto the stack. [Of course, this is NOT upward compatible with the current multiple-value-bind, since the current one allows a mismatch between the number of variables being bound and the number of values being returned. How did THAT find its way into the specification, anyway? I suppose its an attempt to reduce the need for multiple-value-list when you don't know how many values might come back?] The main objection I see to allowing a lambda list is with maintenance -- adding additional return values from a function F could invalidate calls on F that were not prepared to accept (even if only to ignore) them.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 21 Apr 87 11:40:29 EDT Received: from MIT-MULTICS.ARPA by SAIL.STANFORD.EDU with TCP; 21 Apr 87 08:13:49 PDT Date: Tue, 21 Apr 87 01:02 EDT From: Hvatum@MIT-MULTICS.ARPA Subject: "Redefining" functions To: common-lisp@SAIL.STANFORD.EDU Message-ID: <870421050242.558425@MIT-MULTICS.ARPA> From: Steve Bacher (Draper Lab) From: Jim Kempf Subject: Re: Redefinition of Common Lisp Functions To: common-lisp at SAIL.STANFORD.EDU I guess I need to clarify my comments. I see two competing needs here: 1) On the one hand, system vendors and applications distributors require the option of not allowing users to redefine Common Lisp functions. Allowing users to do so makes supplying safe, good quality software difficult because regression testing becomes next to impossible. 2) On the other, researchers and people prototyping advanced applications might want to modify the semantics of certain Common Lisp functions for experimental purposes. I had in mind a third need: 3) User specifying a function whose name happens to conflict with the name of an already existing LISP function, not with the intent of changing the behavior of the LISP function, but with the purpose of defining a new function for use with that user's code only. The user may not know that the function already exists, and therefore will not qualify or shadow it wrt the package system or use FLET. Even if a non-used function name is chosen, who is to say that CL version II won't chew up that name and (depending on the implementation) break this guy's system? Conceivably the LISP system could be compiled so that calls to any built-in CL functions are done in a special "fast-call" way which bypasses actually referencing the function cells of those symbols. (Especially true for inline code.) Of course, this has the effect of making CommonLOOPS-style function-redefining impossible, but there ought to be other solutions to that problem. Which is the subject of another discussion that I don't feel qualified to participate in. - SEB   Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 21 Apr 87 11:39:52 EDT Received: from MIT-MULTICS.ARPA by SAIL.STANFORD.EDU with TCP; 21 Apr 87 08:13:14 PDT Date: Tue, 21 Apr 87 01:02 EDT From: Hvatum@MIT-MULTICS.ARPA Subject: Compiling CASE To: common-lisp@SAIL.STANFORD.EDU Message-ID: <870421050209.453617@MIT-MULTICS.ARPA> From: Steve Bacher (Draper Lab) From: Rob MacLachlan The package system will not protect Common LISP from having its functions redefined, since a user who wants to define his/her own CAR function will likely not call it USER:CAR; thus, since there is already a CAR in the LISP package, that's the one that will get defined. This is what SHADOW is for. But the point is that it still requires a specific user action which presumes knowledge that a built-in CL function is being redefined, be it explicit package prefixing or use of SHADOW. ...it is not reasonable to redefine system functions. True. However, if a programmer uses a name like ENCODE-UNIVERSAL-TIME as a "local" function (in the Franz sense?), such that the compiler doesn't make its definition globally available, this should be no problem. I guess FLET is the solution here. Otherwise, the LISP system should probably issue a warning, and possibly rename the function internally (where possible). I do not have in mind "redefining" CL functions in the sense of changing the behavior of pieces of the LISP system that use them. Rather, I mean defining new functions which happen to have names that are the same as existing CL functions. If the system is set up so as to protect itself properly from having pieces of itself suddenly change their behavior, there should be no problem. I think that if guidelines similar to those above are followed, programs that define functions with the same names as CL functions (NOT "redefine" those functions) can be portable. One more point: If you say that portability precludes implementation-dependent constructs, then we no longer have different CL-compatible implementations - just a single CL implementation with different code generators for different hardware. Maybe this is what we all REALLY want. Who knows? Of course internal compiler representations are highly implementation dependent, but this isn't necessarily a problem. One of the main things that source code walkers have been used for is writing "optimizing macros" for non-optimizing compilers. As long as the compiler adequately optimizes the code, macros can expand in a simple-minded way without understanding their arguments. Let's not try to unload the total optimizing burden on the compiler. Surely there are situations where a macro is in a far better position to know how to optimize a particular construct than the compiler, whose job is to optimize the general cases. Also, as far as internal representation of source code is concerned, no matter how fancy your compiler is, there's always got to be a phase where real source code is analyzed and converted to whatever internal form you like. Certainly transformations can be invoked at that level. What's more, user-written transformations necessarily operate on the source code, unless a LISP implementation is required to make its compiler's internal representation open for manipulation. - SEB   Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 21 Apr 87 11:13:55 EDT Received: from CS.UCL.AC.UK by SAIL.STANFORD.EDU with TCP; 21 Apr 87 03:59:28 PDT Received: from aiva.edinburgh.ac.uk by mv1.Cs.Ucl.AC.UK via Janet with NIFTP id aa00334; 20 Apr 87 18:23 WET From: Jeff Dalton Date: Mon, 20 Apr 87 19:21:25 GMT Message-Id: <21105.8704201921@aiva.ed.ac.uk> To: common-lisp@sail.stanford.edu Subject: Re: Re: Bignums are bogus? > From: Richard Fateman > The point about bignums is that you don't have to check for them > overflowing, because they don't. Something more dreadful happens first. > That's why 64bit or 1kbit bignums are no good. I agree. Bignums should be analogous to lists; representation based sublimits on size are acceptable only if they are so large that they are like running out of memory. True, arrays and floats have size limits for individual objects, but why should bignums be analogous to arrays and not to lists? Page 13 of Steele says "storage is automatically allocated as necessary". It's beginning to seem that this discussion may be even longer than the one of compiling CASE, perhaps because it's more trivial :-).  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 20 Apr 87 16:49:00 EDT Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 20 Apr 87 12:35:40 PDT Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 119912; Mon 20-Apr-87 13:23:57 EDT Date: Mon, 20 Apr 87 13:23 EDT From: David A. Moon Subject: MULTIPLE-VALUE-OR, and Consing To: MURRAY%cs.umass.edu@RELAY.CS.NET cc: common-lisp@SAIL.STANFORD.EDU In-Reply-To: The message of 18 Apr 87 19:34 EDT from MURRAY%cs.umass.edu@RELAY.CS.NET Message-ID: <870420132345.3.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Sat, 18 Apr 87 19:34 EDT From: MURRAY%cs.umass.edu@RELAY.CS.NET >I think more to the heart of the matter is that Common LISP needs a way to grab, >inspect, and pass on an unknown number of multiple values without consing > (and yes, avoiding consing can be crucial for real applications > give the current state of the art for garbage collection > on conventional hardware). It's possible that, using >multiple-value-call, simply having some way of >doing non-consing &rest arguments may be sufficient. ... I whole-heartly agree that A) Unneccessary consing should always be avoided, B) it would be great to have &rest args that don't cons. I currently have plans to have a STACK-LIST declaration that declares that a &Rest is stack-allocated (as well as WITH-STACK-LIST, ala Lisp Machines) in my system. I would suggest that others consider this as well, but of course, it is only a declaration that could be ignored. (I already avoid consing for (&Rest ignore), which should be easy). My point is that MULTIPLE-VALUE-OR can only be done efficiently by low-level implementation-specific code, and thats why it should be in Common Lisp. I don't think this conclusion follows from your previous paragraph. If the proposed MULTIPLE-VALUE-OR can easily be implemented in terms of existing primitives, such as MULTIPLE-VALUE-CALL, and would be efficient if there were non-consing &rest arguments, and non-consing &rest arguments are desirable for other reasons, then I think a more logical conclusion is "because non-consing &rest arguments can only be done efficiently by low-level implementation-specific code, they should be in Common Lisp." By the way, I don't think a declaration for non-consing &rest arguments should be necessary. It should be simple enough for any compiler to recognize special cases such as the following, once implementors' attention has been drawn to the desirability of such optimizations. Another way of saying the same thing is that I think consing is an implementation issue, not a language issue, just as much as whether integer multiplication takes 1 microsecond or 10 microseconds. (lambda (&rest values) (when (first values) (return-from block (values-list values))))  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 20 Apr 87 11:57:11 EDT Received: from GSWD-VMS.ARPA by SAIL.STANFORD.EDU with TCP; 20 Apr 87 06:58:24 PDT Received: from mycroft.GSD (mycroft.Gould.COM) by gswd-vms.ARPA (5.52/) Message-Id: <8704201356.AA13978@gswd-vms.ARPA> Date: Mon, 20 Apr 87 07:55:24 CST From: preece%mycroft@gswd-vms.ARPA (Scott E. Preece) To: COMMON-LISP@sail.stanford.edu Subject: Bigosities primerd!DOUG@ENX.Prime.PDN > The concept that 64 bits could be construed as a reasonable integer > limit is silly since there are many hardware architectures where a basic > arithmetic operation can be done on 64 bits in both integer and floating > point. Also 64 bits is only ~21 decimal digits. ---------- What has the size of the basic hardware operation size got to do with anything? Frankly, as long as the standard doesn't specify a minimum size for bignum coverage, I would say 64 bits would be conforming. I have never done any Lisp coding myself (outside of tests of our implementation) which required numbers bigger than 64 bits -- if I were going out shopping for a CL for my own use, that restriction wouldn't bother me. The most important thing is that each implementation make its limits clear, so that the porter knows if she has a chance of making the port in less than geological time and so that the shopper knows whether the implementation is suitable for the proposed use. I don't really care whether the limits are encoded as constants or printed on paper, but I would like the standard to require that they be available and that they be separated into representational limits and space limits. -- scott preece gould/csd - urbana uucp: ihnp4!uiucdcs!ccvaxa!preece arpa: preece@gswd-vms  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 20 Apr 87 11:54:23 EDT Received: from IBM.COM by SAIL.STANFORD.EDU with TCP; 20 Apr 87 06:25:36 PDT Date: 20 April 1987, 09:21:28 EDT From: Timothy Daly To: common-lisp@sail.stanford.edu Message-Id: <042087.092128.daly@ibm.com> Subject: Pavel's reply Quite right. The missing # isn't missing. Mea Culpa.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 20 Apr 87 11:18:54 EDT Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 20 Apr 87 08:04:56 PDT Received: from boethius by Think.COM via CHAOS; Mon, 20 Apr 87 09:54:32 EST Date: Mon, 20 Apr 87 10:51 EDT From: Guy Steele Subject: bignums are bogus To: Fahlman@c.cs.cmu.edu, sandra%orion@cs.utah.edu Cc: common-lisp@sail.stanford.edu, gls@think.com In-Reply-To: Message-Id: <870420105121.1.GLS@BOETHIUS.THINK.COM> I have a vague memory of sending to this mailing list, a couple of years ago, the observation that one could have MOST-POSITIVE-BIGNUM and MOST-NEGATIVE-BIGNUM, and probably each would occupy 1/3 of the total memory space.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 19 Apr 87 20:40:05 EDT Received: from CS.UTAH.EDU by SAIL.STANFORD.EDU with TCP; 19 Apr 87 17:26:52 PDT Received: by cs.utah.edu (5.54/utah-1.0) id AA14758; Sun, 19 Apr 87 18:29:35 MDT Received: by utah-orion.ARPA (5.31/4.40.2) id AA03009; Sun, 19 Apr 87 18:29:31 MDT Date: Sun, 19 Apr 87 18:29:31 MDT From: sandra%orion@cs.utah.edu (Sandra J Loosemore) Message-Id: <8704200029.AA03009@utah-orion.ARPA> Subject: Re: Bigosities Newsgroups: fa.common-lisp To: common-lisp@sail.stanford.edu References: <8704191810.AA14369@primerd.prime.com> In article <8704191810.AA14369@primerd.prime.com>, primerd!DOUG@ENX.Prime.PDN writes: > The concept that 64 bits could be construed as a reasonable integer > limit is silly since there are many hardware architectures where a > basic arithmetic operation can be done on 64 bits in both integer > and floating point. Also 64 bits is only ~21 decimal digits. > > Doug Maybe I should have put a few :-)'s in my original posting: I certainly wasn't intending 64-bit bignums as a serious proposal. My reason for throwing out the idea in the first place was to point out that integer overflow is bad news whether the limit on integer size is large or small, and also to point out that the manual doesn't *say* it has to be huge. If the limit is huge, we can maybe get away with some handwaving and saying that any program that runs up against the limit is wedged anyway. But that does not change the fact that there is a problem with overflow. -Sandra  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 19 Apr 87 13:43:16 EDT Received: from EDDIE.MIT.EDU by SAIL.STANFORD.EDU with TCP; 19 Apr 87 10:29:50 PDT Received: by EDDIE.MIT.EDU with UUCP with smail2.3 with sendmail-5.31/4.7 id ; Sun, 19 Apr 87 13:31:55 EDT Received: by primerd.prime.com (1.1/SMI-3.0DEV3/smail) id AA14369; Sun, 19 Apr 87 13:10:47 EST Message-Id: <8704191810.AA14369@primerd.prime.com> Received: (from user DOUG) by ENX.Prime.PDN; 17 Apr 87 10:20:06 EST Subject: Bigosities To: common-lisp@sail.stanford.edu From: primerd!DOUG@ENX.Prime.PDN Date: 17 Apr 87 10:20:06 EST The concept that 64 bits could be construed as a reasonable integer limit is silly since there are many hardware architectures where a basic arithmetic operation can be done on 64 bits in both integer and floating point. Also 64 bits is only ~21 decimal digits. Doug  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 19 Apr 87 01:30:37 EDT Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 18 Apr 87 22:15:17 PDT Received: from relay2.cs.net by RELAY.CS.NET id ac00469; 19 Apr 87 1:08 EDT Received: from cs.umass.edu by RELAY.CS.NET id am08685; 19 Apr 87 1:03 AST Date: Sat, 18 Apr 87 19:34 EDT From: MURRAY%cs.umass.edu@RELAY.CS.NET To: common-lisp@SAIL.STANFORD.EDU Subject: MULTIPLE-VALUE-OR, and Consing X-VMS-To: CLMAIL >From: Don Morrison >What are the semantics of MULTIPLE-VALUE-OR? ... It should be the same as OR, but return multiple-values. Since OR only conditionalizes on the first value, MULTIPLE-VALUE-OR does the same, but returns all the rest of the values as well. As standard with multiple-values, when less than asked for are returned, the extra are filled out with NIL's, so no-values is the same as a NIL value. >I think more to the heart of the matter is that Common LISP needs a way to grab, >inspect, and pass on an unknown number of multiple values without consing > (and yes, avoiding consing can be crucial for real applications > give the current state of the art for garbage collection > on conventional hardware). It's possible that, using >multiple-value-call, simply having some way of >doing non-consing &rest arguments may be sufficient. ... I whole-heartly agree that A) Unneccessary consing should always be avoided, B) it would be great to have &rest args that don't cons. I currently have plans to have a STACK-LIST declaration that declares that a &Rest is stack-allocated (as well as WITH-STACK-LIST, ala Lisp Machines) in my system. I would suggest that others consider this as well, but of course, it is only a declaration that could be ignored. (I already avoid consing for (&Rest ignore), which should be easy). My point is that MULTIPLE-VALUE-OR can only be done efficiently by low-level implementation-specific code, and thats why it should be in Common Lisp. - Kelly Edward Murray University of Massachusetts, Amherst  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 18 Apr 87 19:42:16 EDT Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 18 Apr 87 16:27:56 PDT Received: from LIVE-OAK.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 18 Apr 87 19:30-EDT Received: from GOLD-HILL-ACORN.DialNet.Symbolics.COM by MIT-LIVE-OAK.ARPA via DIAL with SMTP id 38740; 18 Apr 87 19:29:54-EDT Received: from PINK-FLOYD.Gold-Hill.DialNet.Symbolics.COM by ACORN.Gold-Hill.DialNet.Symbolics.COM via CHAOS with CHAOS-MAIL id 65237; Sat 18-Apr-87 19:17:01-EST Date: Fri, 17 Apr 87 10:39 EDT From: Randy%acorn@oak.lcs.mit.edu To: ghenis.pasa@Xerox.COM Subject: Re: SETF and pathname slots Cc: common-lisp@sail.stanford.edu Date: 16 Apr 87 17:01 PDT From: ghenis.pasa@Xerox.COM Should the standard require SETF to handle pathname slots? If we are going to have MAKE-PATHNAME, PATHNAME-DEVICE, etc, for consistency we should also have COPY-PATHNAME and be able to do things like (SETF (PATHNAME-TYPE old-path) "OLD"). Is there any reason not to? Probably not, since a lot of implementations might want to cache pathnames (so they are EQ). You could have COPY-PATHNAME take keyword arguments of slots to change in the copying process. Or you could probably use MERGE-PATHNAMES for these sorts of things. Random  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 18 Apr 87 17:57:14 EDT Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 18 Apr 87 14:44:05 PDT Received: ID ; Sat 18 Apr 87 17:44:56-EDT Date: Sat, 18 Apr 1987 17:44 EDT Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: common-lisp@SAIL.STANFORD.EDU Subject: OR if some argument returns no values To Rem at IMSSS: The manual doesn't say as far as I can tell what OR is supposed to do if one of the arguments doesn't return any values at all. Page 133-134: "If the caller of a function does not request multiple values, but the called function returns multiple values, then the first value is given to the caller and all the other values are discarded; if the called function produces zero values, then the caller gets NIL as a value." OR, COND, and friends do not expect multiple values from the sub-forms, except in certain tail-recursive poisitions. Seems pretty clear to me. Whether you like this behavior is another question. -- Scott  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 18 Apr 87 17:20:39 EDT Received: from HPLABS.HP.COM by SAIL.STANFORD.EDU with TCP; 18 Apr 87 14:06:58 PDT Received: from hpfclp.HP.COM by hplabs.HP.COM with TCP ; Sat, 18 Apr 87 10:52:47 pst Received: by hpfclp.HP.COM; Sat, 18 Apr 87 12:51:52 mst Date: Sat, 18 Apr 87 12:51:52 mst From: John Diamant Return-Path: Message-Id: <8704181951.AA22390@hpfclp.HP.COM> To: edsel!bhopal!jonl@navajo.stanford.edu Subject: Re: CLARIFICATION: [italics]package arguments. Cc: common-lisp@sail.stanford.edu > Contrary to what John Diamant suggested, I think that very few functions > fall into category (1). The vast majority seem to be in category (2). After looking through several pages of CLtL, I see that you are right that only a few fall in category (1). However, it is still a major leap to conclude (2) simply because the "must" is not listed for the function. If that were the intended interpretation, then a statement at the beginning of the section should say that. This is comparable to taking a word and saying in this sentence it means "A" and in this other sentence it means "B." It is still true that package means package, and not package name, so what you are talking about is still an extension, not something that can be concluded from the text. > There wasn't a lot of discussion back then about these points -- certainly > there was no serious objection to them. Probably the HP folks weren't > receiving the mail then? Well, that's probably true. I certainly wasn't, as I wasn't with HP 2 years ago. Even if the mailing list was being received, it could have been missed. However, when interpretations like that are "added" to CLtL, we need to be careful to record them for inclusion in further standards. Standards don't do us any good if people decide to reinterpret them beyond what is stated, simply because they don't like the standard. Note that I have no objection to your proposed enhancement, but it requires a clarification to the standard, not just a joint decision from some of the implementors. Regarding David Moon's comments: we will have to agree to disagree. I believe that any extension to CLtL should be clearly delineated or not included. I would be much happier if CLtL stated how this delineation must occur (explicitly requiring extensions to not be in the LISP package, possibly shadowing symbols that are, for instance). Portability is probably the most important feature of Common Lisp, and I hate to see such a lack of committment to it that if something isn't convenient because of portability issues, we just ignore the portability issue. John Diamant  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 18 Apr 87 16:04:57 EDT Received: from IMSSS by SAIL with PUP; 18-Apr-87 12:50 PDT Date: 18 Apr 1987 1159-PDT From: Rem@IMSSS Subject: OR if some argument returns no values To: Common-LISP@SU-AI The manual doesn't say as far as I can tell what OR is supposed to do if one of the arguments doesn't return any values at all. OR is defined in terms of COND, which likewise isn't documented in the no-return-value case. If CL doesn't support no-return-values at all within the general framework of multiple return values, then this question is moot. (Can an expert say whether no-return-values is as legal as one-return-value or multiple-return-values?) If CL *does* support no-return-values, or if that is a legitimate extension to the language, then my opinion is that it should "be an error" to do an OR (or COND) with one of the tests not returning any value at all, the logic being "if the function won't tell me what its answer is, how am I supposed to use that answer to make a decision?". AND and a few other functionoids may fall into this same category as OR and COND. -------  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 18 Apr 87 08:56:01 EDT Date: 18 Apr 87 0538 PDT From: Dick Gabriel Subject: Packages To: common-lisp@SAIL.STANFORD.EDU On the proposal: "Any argument described in this section as a package name or package may be either a string or a symbol." This, of course, makes the language just a little worse than it is. There is no rational sense in which a string or a symbol is a package. -rpg-  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 18 Apr 87 04:04:53 EDT Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 18 Apr 87 00:49:06 PDT Received: from LIVE-OAK.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 18 Apr 87 03:51-EDT Received: from PALLADIAN-JASPER.DialNet.Symbolics.COM by MIT-LIVE-OAK.ARPA via DIAL with SMTP id 38683; 18 Apr 87 03:49:17-EDT Received: from WHITBY.Palladian.COM by JASPER.Palladian.COM via INTERNET with SMTP id 33358; 18 Apr 87 03:45:01-EDT Date: Sat, 18 Apr 87 03:43 EDT From: Don Morrison Subject: OR and Multiple Values To: MURRAY%cs.umass.edu@RELAY.CS.NET, common-lisp@SAIL.STANFORD.EDU In-Reply-To: The message of 17 Apr 87 18:27 EDT from MURRAY%cs.umass.edu@RELAY.CS.NET Message-ID: <870418034319.5.DFM@WHITBY.PALLADIAN.COM> Reply-To: Don Morrison Date: Fri, 17 Apr 87 18:27 EDT From: MURRAY%cs.umass.edu@RELAY.CS.NET However, I'll take this opportuntiy to again ask for a MULTIPLE-VALUE-OR special form, since it cannot be defined without consing in Common-Lisp (I guess it COULD be a macro that expands into consing code, but the compiler would know about, but that is another discussion). What are the semantics of MULTIPLE-VALUE-OR? Does it a) return all the values returned by the first form with a non-null first value (since we're no longer implicitly expecting exactly one value what does it do in the case of zero values?) b) return all the values returned by the first form with all its values non-null (if there are zero values does that count as all non-null?) c) return all the values returned by the first form with any of its values non-null (if there are zero values does that count as none non-null?) d) return the maximum number of values returned by any forms with each slot chosen from the first form that returned non-null in that form (this one would require always evaluating all the forms, so I'm probably getting bogus here) e) return all the values returned by the first form that returned the maximum number of non-null values (even more bogus) f) ... I think more to the heart of the matter is that Common LISP needs a way to grab, inspect, and pass on an unknown number of multiple values without consing (and yes, avoiding consing can be crucial for real applications give the current state of the art for garbage collection on conventional hardware). It's possible that, using multiple-value-call, simply having some way of doing non-consing &rest arguments may be sufficient. For example, I believe the following gives something close to the semantics of (a) without consing, if the bogus declaration ensures that the &rest argument isn't consed (and, of course, if the implementors haven't introduced gratuitous consing, which is far from a sure thing, especially in multiple-value-call....). (defmacro multiple-value-or (&rest forms) ; don't care about this &rest `(block #0=#:mv-or-block ,@(mapcar #'(lambda (form) `(multiple-value-call #'(lambda (&rest #1=#:mv-or-args) ; this &rest musn't cons (declare (dynamic-extent #1#)) (when (first #1#) (return-from #0# (apply #'values #1#)))) ,form)) forms) nil)) For example, (multiple-value-or (mumble) (shout) (bellow)) -> (block #:mv-or-block (multiple-value-call #'(lambda (&rest #:mv-or-args) (declare (dynamic-extent #:mv-or-args)) (when (first #:mv-or-args) (return-from #:mv-or-block (apply #'values #:mv-or-args)))) (mumble)) (multiple-value-call #'(lambda (&rest #:mv-or-args) (declare (dynamic-extent #:mv-or-args)) (when (first #:mv-or-args) (return-from #:mv-or-block (apply #'values #:mv-or-args)))) (shout)) (multiple-value-call #'(lambda (&rest #:mv-or-args) (declare (dynamic-extent #:mv-or-args)) (when (first #:mv-or-args) (return-from #:mv-or-block (apply #'values #:mv-or-args)))) (bellow)) nil) (B) and (c) can be implemented by replacing "(when (first #1#)" by "(when (every #'identity #1#)" and "(when (some #'identity #1#)", respectively.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 18 Apr 87 01:51:02 EDT Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 17 Apr 87 22:36:24 PDT Received: from relay2.cs.net by RELAY.CS.NET id aa22296; 18 Apr 87 1:33 EDT Received: from cs.umass.edu by RELAY.CS.NET id cj03359; 18 Apr 87 1:28 AST Date: Fri, 17 Apr 87 19:51 EDT From: MURRAY%cs.umass.edu@RELAY.CS.NET To: common-lisp@SAIL.STANFORD.EDU Subject: Fixnums Bogus X-VMS-To: CLMAIL Just to throw my two cents in... It is undeniably a loophole that bignums don't have some minimum size, because fixnums don't have a minimum size, and thus one could "legally" get away with integers that only need to be big enough to hold other "defined" minimum values, such as ARRAY-DIMENSION-LIMIT, which must be greater than 1024. My question is: does anybody really use these constants to conditionalize their programs? It seems to me, either an implementation will run your program, or not. Without official validation, a system calling itself a "Common Lisp" can only be refering to its "spirit", (-: which likes to float around in a large virtual memory with many friends who speak microcode :-) Kelly  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 18 Apr 87 01:44:37 EDT Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 17 Apr 87 22:29:12 PDT Received: from relay2.cs.net by RELAY.CS.NET id ai22053; 18 Apr 87 1:22 EDT Received: from cs.umass.edu by RELAY.CS.NET id ce03359; 18 Apr 87 1:17 AST Date: Fri, 17 Apr 87 18:27 EDT From: MURRAY%cs.umass.edu@RELAY.CS.NET To: common-lisp@SAIL.STANFORD.EDU Subject: OR and Multiple Values X-VMS-To: CLMAIL > Is it reasonable to expect SOME to return multiple values? > What if the predicate returns multiple values? >>No, for the same reason that OR returns only a single value for clauses >>other than the last one. That is, the implicit NULL test "consumes" the >>values returned from the predicate, discarding all but the last one. I've always been a little disturbed by this fact. I suppose the extra effort to always insure multiple values are dealt with "properly" is probably not worth it in general. However, I'll take this opportuntiy to again ask for a MULTIPLE-VALUE-OR special form, since it cannot be defined without consing in Common-Lisp (I guess it COULD be a macro that expands into consing code, but the compiler would know about, but that is another discussion). - Kelly  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 18 Apr 87 00:34:44 EDT Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 17 Apr 87 21:21:09 PDT Received: by navajo.stanford.edu; Fri, 17 Apr 87 20:20:45 PST Received: from bhopal.edsel.com by edsel.uucp (2.2/SMI-2.0) id AA01217; Fri, 17 Apr 87 20:18:48 pst Received: by bhopal.edsel.com (3.2/SMI-3.2) id AA00738; Fri, 17 Apr 87 21:16:27 PDT Date: Fri, 17 Apr 87 21:16:27 PDT From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White) Message-Id: <8704180416.AA00738@bhopal.edsel.com> To: navajo!vrotney%vaxa.isi.edu@navajo.stanford.edu Cc: navajo!common-lisp%sail@navajo.stanford.edu In-Reply-To: navajo!vrotney@vaxa.isi.edu's message of Fri, 17 Apr 87 15:08:45 PDT Subject: CLARIFICATION: [italics]package arguments. Somewhere between 1 year ago and 2 years ago, I sent out a proposal to this list suggesting that the package functions of CLtL section 11.7 fall into four categories: (1) those whose argument is documented as "must be a package"; (2) those whose argument is documented as "a package"; (3) those whose argument is documented as a "name" of (or for) a package; (4) all the rest. Contrary to what John Diamant suggested, I think that very few functions fall into category (1). The vast majority seem to be in category (2). Both Symbolics and Lucid apparently, independently, made a decision to interpret the documentation of category (2) to mean that any argument reasonably coercible to a package would in fact be so coerced. That is, if the documentation goes out of its way to say "must be a package" for some functions, but doesn't do so for others, then it must be that the latter ones can be more generous in accepting alternate forms. This implies, for example, that a string or symbol could be supplied as the "pacakge" argument to UNINTERN; but the argument to PACKAGE-NICKNAMES can only be of type package, because it "must be a packge". There wasn't a lot of discussion back then about these points -- certainly there was no serious objection to them. Probably the HP folks weren't receiving the mail then? -- JonL --  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 18 Apr 87 00:23:22 EDT Received: from VAXA.ISI.EDU by SAIL.STANFORD.EDU with TCP; 17 Apr 87 21:09:03 PDT Received: from hpai00 (hpai00.isi.edu) by vaxa.isi.edu (4.12/4.7) id AA18659; Fri, 17 Apr 87 20:10:16 pst Received: by hpai00 ; Fri, 17 Apr 87 21:09:05 pdt From: vrotney@vaxa.isi.edu Message-Id: <8704180409.AA02941@hpai00> Date: Fri, 17 Apr 87 20:08:53 PDT Subject: Sec.11.7 [italics]package arguments. To: common-lisp@sail.stanford.edu X-Mailer: NMail [$Revision: 2.6 $] In the spirit of making CLTL a slightly better specification, what about the following extension? On page 182, extend the statement "Any argument described as a package name may be either a string or a symbol." to "Any argument described in this section as a package name or package may be either a string or a symbol." -------------------------------------------------------------------------------- Post Script: After sending the above message I realized that someone may interpret it too literally. My original message on this indicated that the functions in Sec.11.7 created a "misinterpretation portability trap" or what ever you want to call it. The above is a suggestion for an extension that means that all arguments in this section named [italics]package, be allowed to be a string or symbol, as they can be in some implementations. I suppose the extended sentence above could be worded better to help define what something described as a "package name" means. For example, "Any argument described in this section as a package name may be either a string or symbol. Any argument designated as [italics]package may be a package, string or symbol." In other words, reqardless of what most of us think CLTL says these package arguments can or can not be, a good future extension might be to specify exactly that all of these package arguments (except for a few) be allowed to be a package, string or symbol. Bill Vrotney USC/ISI -------  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 17 Apr 87 19:23:42 EDT Received: from VAXA.ISI.EDU by SAIL.STANFORD.EDU with TCP; 17 Apr 87 16:08:53 PDT Received: from hpai00 (hpai00.isi.edu) by vaxa.isi.edu (4.12/4.7) id AA16667; Fri, 17 Apr 87 15:10:06 pst Received: by hpai00 ; Fri, 17 Apr 87 16:08:56 pdt From: vrotney@vaxa.isi.edu Message-Id: <8704172308.AA02892@hpai00> Date: Fri, 17 Apr 87 15:08:45 PDT Subject: Re: CLARIFICATION: [italics]package arguments. To: common-lisp@sail.stanford.edu In-Reply-To: Your message of 17-Apr-87 10:18:00 X-Mailer: NMail [$Revision: 2.6 $] In the spirit of making CLTL a slightly better specification, what about the following extension? On page 182, extend the statement "Any argument described as a package name may be either a string or a symbol." to "Any argument described in this section as a package name or package may be either a string or a symbol." Bill Vrotney USC/ISI -------  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 17 Apr 87 15:15:10 EDT Received: from [192.10.41.109] by SAIL.STANFORD.EDU with TCP; 17 Apr 87 12:00:27 PDT Received: from EUPHRATES.SCRC.Symbolics.COM by ALDERAAN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 73021; Fri 17-Apr-87 14:59:12 EDT Date: Fri, 17 Apr 87 14:58 EDT From: David A. Moon Subject: Language extensions (formerly [italics]package arguments.) To: John Diamant cc: common-lisp@sail.stanford.edu In-Reply-To: <8704171816.AA06364@hpfcjrd.HP.COM> Message-ID: <870417145849.0.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Fri, 17 Apr 87 11:16:15 mst From: John Diamant > Or they can provide a "mode" in which extensions are > disabled as much as possible, to help users assure portability of "pure > CL" code. Conformity with the standard only means that an implementing > will correctly run correct CL programs. O.K. I stand corrected. It is not a violation of the standard per-say to provide such an extension. However, to do so without a mode like what you describe or a flag that provides warning messages when extensions are used is doing a grave disservice to the user. This is really the same issue as the list of exported symbols from the LISP package. Nowhere in CLtL does it say that extra symbols can't be exported, but you make portable code virtually impossible to write unless you require that. I believe the same is true for any extension. It must be clearly delineated either by being in a separate package (possibly shadowing the symbol in the LISP package) or it must provide some kind of feedback that the operation just performed is not Common Lisp. That CLtL does not discuss issues like this is, I think, extremely unfortunate. It does discuss this, on pages 1 through 3. (It discusses just the philosophy and doesn't get down to specific cases.) I think that providing tools to ease writing of portable code is a fine idea, and vendors should do so. I violently disagree with the idea that any implementation that does not come with a 100% perfect set of such tools is not Common Lisp. Note that CLtL pp.1-3 says that Common Lisp is a common dialect to which each implementation makes any necessary extensions, and that Common Lisp is designed to make it easy to write programs that depend as little as possible on machine-specific characteristics, but does not say that Common Lisp's purpose is to support writing of only programs that are 100% painlessly portable. Common Lisp would be a lot less interesting, and a lot less widespread, if that were so.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 17 Apr 87 14:30:03 EDT Received: from HPLABS.HP.COM by SAIL.STANFORD.EDU with TCP; 17 Apr 87 11:15:13 PDT Received: from hpfclp.HP.COM by hplabs.HP.COM with TCP ; Fri, 17 Apr 87 10:15:57 pst Received: from hpfcjrd.HP.COM by hpfclp.HP.COM; Fri, 17 Apr 87 12:14:56 mst Received: by hpfcjrd.HP.COM; Fri, 17 Apr 87 11:16:15 mst Date: Fri, 17 Apr 87 11:16:15 mst From: John Diamant Return-Path: Message-Id: <8704171816.AA06364@hpfcjrd.HP.COM> To: dlw@alderaan.scrc.symbolics.com Subject: Re: CLARIFICATION: [italics]package arguments. Cc: common-lisp@sail.stanford.edu > Would you please show us where in CLtL it says that accepting package > names is forbidden, and required to signal an error? "Must" means "must." This means that it "is an error" to do otherwise. Whether it signals an error or attempts to interpret what the user meant is at the discretion of the implementation. That means, at the least that the program was not a correct CL program. However, the second point applies here (see below). > Or they can provide a "mode" in which extensions are > disabled as much as possible, to help users assure portability of "pure > CL" code. Conformity with the standard only means that an implementing > will correctly run correct CL programs. O.K. I stand corrected. It is not a violation of the standard per-say to provide such an extension. However, to do so without a mode like what you describe or a flag that provides warning messages when extensions are used is doing a grave disservice to the user. This is really the same issue as the list of exported symbols from the LISP package. Nowhere in CLtL does it say that extra symbols can't be exported, but you make portable code virtually impossible to write unless you require that. I believe the same is true for any extension. It must be clearly delineated either by being in a separate package (possibly shadowing the symbol in the LISP package) or it must provide some kind of feedback that the operation just performed is not Common Lisp. That CLtL does not discuss issues like this is, I think, extremely unfortunate. John Diamant  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 17 Apr 87 13:15:19 EDT Received: from SCRC-YUKON.ARPA by SAIL.STANFORD.EDU with TCP; 17 Apr 87 09:58:58 PDT Received: from WHITE-BIRD.SCRC.Symbolics.COM by YUKON.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 195190; Fri 17-Apr-87 12:58:53 EDT Date: Fri, 17 Apr 87 12:58 EDT From: Robert W. Kerns Subject: SETF and pathname slots To: ghenis.pasa@Xerox.COM cc: common-lisp@sail.stanford.edu In-Reply-To: <870416-170308-1688@Xerox> Message-ID: <870417125836.3.RWK@WHITE-BIRD.SCRC.Symbolics.COM> Date: 16 Apr 87 17:01 PDT From: ghenis.pasa@Xerox.COM Should the standard require SETF to handle pathname slots? If we are going to have MAKE-PATHNAME, PATHNAME-DEVICE, etc, for consistency we should also have COPY-PATHNAME and be able to do things like (SETF (PATHNAME-TYPE old-path) "OLD"). Is there any reason not to? Careful. Not all systems have pathnames which can be modified. In our case, it's because we want to preserve EQness of pathnames with the same components. In other (hypothetical) cases, a pathname may be an operating-system-related object that you aren't allowed to directly modify; you request a new one. The answer is to treat (SETF (PATHNAME-NAME PATH) NEW-NAME) like (SETF PATH (MAKE-PATHNAME :NAME NEW-NAME :DEFAULTS PATH)). This is analogous with SETF of LDB.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 17 Apr 87 10:37:57 EDT Received: from [192.10.41.109] by SAIL.STANFORD.EDU with TCP; 17 Apr 87 07:23:20 PDT Received: from CHICOPEE.SCRC.Symbolics.COM by ALDERAAN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 72880; Fri 17-Apr-87 10:22:20 EDT Date: Fri, 17 Apr 87 10:18 EDT From: Daniel L. Weinreb Subject: Re: CLARIFICATION: [italics]package arguments. To: diamant%hpfclp@hplabs.HP.COM cc: common-lisp@sail.stanford.edu In-Reply-To: <8704162320.AA08469@hpfclp.HP.COM> Message-ID: <870417101821.7.DLW@CHICOPEE.SCRC.Symbolics.COM> Date: Thu, 16 Apr 87 16:20:21 mst From: John Diamant If, as I believe from my reading of Steele, package names are not allowed, then Symbolics is violating the standard, Would you please show us where in CLtL it says that accepting package names is forbidden, and required to signal an error? and thus lulling people into writing non-portable code (as you did). We opted for a strict interpretation, because code developed on our machines will have a much better chance of being portable. That's a very different question from "violating the standard". Supersets of the standard are explicitly allowed; the word "Common" in the name of "Common Lisp" is derived from the phrase "common subset". Any implementation can make tradeoffs between providing extended functionality, or providing only what's required by CLtL and nothing more, in any area, depending on which criteria are more important in that case. Or they can provide a "mode" in which extensions are disabled as much as possible, to help users assure portability of "pure CL" code. Conformity with the standard only means that an implementing will correctly run correct CL programs.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 17 Apr 87 00:51:37 EDT Received: from UCBVAX.Berkeley.EDU by SAIL.STANFORD.EDU with TCP; 16 Apr 87 21:37:42 PDT Received: by ucbvax.Berkeley.EDU (5.57/1.23) id AA23502; Thu, 16 Apr 87 20:40:18 PST Received: by mike (3.2/5.17) id AA14026; Thu, 16 Apr 87 21:38:08 PDT Date: Thu, 16 Apr 87 21:38:08 PDT From: fateman@mike.Berkeley.EDU (Richard Fateman) Message-Id: <8704170438.AA14026@mike> To: common-lisp@sail.stanford.edu Subject: Re: Bignums are bogus? The point about bignums is that you don't have to check for them overflowing, because they don't. Something more dreadful happens first. That's why 64bit or 1kbit bignums are no good. If you want 64 bit numbers or so, I suggest you use floating point. In fact, a CL-subset with only floating point might be useful, especially if exact-integer floats were printed like integers.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 16 Apr 87 23:24:39 EDT Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 16 Apr 87 20:11:59 PDT Received: from relay2.cs.net by RELAY.CS.NET id ac19928; 16 Apr 87 23:07 EDT Received: from atc.bendix.com by RELAY.CS.NET id ab18198; 16 Apr 87 23:04 AST Date: Thu, 16 Apr 87 15:33 EDT From: DON%atc.bendix.com@RELAY.CS.NET Subject: Bignums are bogus? To: common-lisp@SAIL.STANFORD.EDU X-VMS-To: IN%"common-lisp@sail.stanford.edu" >From: IN%"Rob MacLachlan " 16-APR-1987 12:52 >To: Sandra J Loosemore >Subj: bignums are bogus >I'm not a big bignum user, but I think it might be marginally >reasonable to support fixed-size 64 bit bignums. I suspect that 64 >bit bignums would take care of a large percentage of uses. This would >also keep get-universal-time happy for a while to come. I use bignums for set representations. I think 64 bits is far too small. I agree that something over a thousand would almost always suffice. Don Mitchell  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 16 Apr 87 22:36:40 EDT Received: from HPLABS.HP.COM by SAIL.STANFORD.EDU with TCP; 16 Apr 87 19:17:10 PDT Received: from hpfclp.HP.COM by hplabs.HP.COM with TCP ; Thu, 16 Apr 87 14:21:15 pst Received: by hpfclp.HP.COM; Thu, 16 Apr 87 16:20:21 mst Date: Thu, 16 Apr 87 16:20:21 mst From: John Diamant Return-Path: Message-Id: <8704162320.AA08469@hpfclp.HP.COM> To: vrotney@vaxa.isi.edu Cc: common-lisp@sail.stanford.edu Subject: Re: CLARIFICATION: [italics]package arguments. > Are the package functions that take a package argument in CLTL with > the name [italics]package allowed to have a string or symbol as that > argument? If so, HP take note, we had to make a lot of changes in our > Symbolics generated code to make it port to CL on the HPAIWS. If not, > then why not? No, they aren't. We looked very carefully in Steele for an indication that they were allowed, but they aren't. It quite clearly states on most of these functions that "The argument must be a package." A name of a package is not a package. The problem with being "nice" by stretching what the standard says is exactly the problem you have. If, as I believe from my reading of Steele, package names are not allowed, then Symbolics is violating the standard, and thus lulling people into writing non-portable code (as you did). We opted for a strict interpretation, because code developed on our machines will have a much better chance of being portable. Besides, if standard doesn't say what people want it to say, then it should be changed -- that doesn't mean language developers should ignore the standard because they don't like it. By the way, I don't know of any reason why the package functions couldn't take a name as well (except that for package-name, it wouldn't make much sense). John Diamant  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 16 Apr 87 20:58:44 EDT Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 16 Apr 87 17:35:58 PDT Received: ID ; Thu 16 Apr 87 20:37:18-EDT Date: Thu, 16 Apr 1987 20:37 EDT Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: ghenis.pasa@XEROX.COM Cc: common-lisp@SAIL.STANFORD.EDU Subject: SOME and Multiple Values In-reply-to: Msg of 16 Apr 1987 19:31-EDT from ghenis.pasa at Xerox.COM Is it reasonable to expect SOME to return multiple values? CLtL says: "SOME returns as soon as any invocation of predicate returns a non-nil value. SOME returns that value." What if the predicate returns multiple values? No, for the same reason that OR returns only a single value for clauses other than the last one. That is, the implicit NULL test "consumes" the values returned from the predicate, discarding all but the last one. -- Scott  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 16 Apr 87 20:24:58 EDT Received: from HPLABS.HP.COM by SAIL.STANFORD.EDU with TCP; 16 Apr 87 17:03:09 PDT Received: by hplabs.HP.COM ; Thu, 16 Apr 87 14:32:00 pst Received: from manpyrnova by pyramid.UUCP (5.52/UUCP-Project/rel-1.0/09-16-86) id AA12155; Thu, 16 Apr 87 14:51:24 PDT Received: by pyrnova.pyramid.COM (5.52/UUCP-Project/rel-1.0/09-11-86) id AA23093; Thu, 16 Apr 87 14:51:11 PDT Date: 16 Apr 1987 14:44 PDT From: David Bein Subject: Re: Bognumosity To: hplabs!common-lisp@sail.stanford.edu@hplabs.HP.COM Message-Id: <545606488/bein@pyrnova> Stan: I agree with the spirit of essentially unlimited size bignums. On most of the systems I know of, most-positive-fixnum is 27 bits or more, implying that a bignum that long would take at least 16 megabytes to represent unless one is willing to introduce a notion like floating point where low order bits are not represented beyond some limit, at which point why not use floating point to begin with. My system in fact adheres roughly to your suggestion, where technically a bignum 134217702 bits long can be allocated (most-positive-fixnum is 134217727 in my system). I think you'll find that doing anything with a bignum that long is next to impossible since other resources like scratch stack space may not accomodate multiple copies of something that large (which of course is not very interesting when it happens). I would almost suggest that if there is a limit, it be tied to notions like the largest float since a larger bignum can't be converted properly unless we introduce notions like floating-infinities into the language. If we do that however, we end up needing a definition for rational infinity. I don't have a good handle on what infinity means from an operational point of view. Maybe getting out of digit computers for a while would help -- :-) I too am uncomfortable with the idea that rational numbers overflow, but don't have any practical ideas about what do besides treat the problem as simply a resource problem which is what I am already doing. --David  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 16 Apr 87 20:22:48 EDT Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 16 Apr 87 17:03:10 PDT Received: from PinotNoir.ms by ArpaGateway.ms ; 16 APR 87 17:03:08 PDT Date: 16 Apr 87 17:01 PDT From: ghenis.pasa@Xerox.COM Subject: SETF and pathname slots To: common-lisp@sail.stanford.edu Message-ID: <870416-170308-1688@Xerox> Should the standard require SETF to handle pathname slots? If we are going to have MAKE-PATHNAME, PATHNAME-DEVICE, etc, for consistency we should also have COPY-PATHNAME and be able to do things like (SETF (PATHNAME-TYPE old-path) "OLD"). Is there any reason not to?  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 16 Apr 87 19:49:32 EDT Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 16 Apr 87 16:32:01 PDT Received: from PinotNoir.ms by ArpaGateway.ms ; 16 APR 87 16:33:00 PDT Date: 16 Apr 87 16:31 PDT From: ghenis.pasa@Xerox.COM Subject: SOME and Multiple Values To: common-lisp@sail.stanford.edu Message-ID: <870416-163300-1658@Xerox> Is it reasonable to expect SOME to return multiple values? CLtL says: "SOME returns as soon as any invocation of predicate returns a non-nil value. SOME returns that value." What if the predicate returns multiple values? Meta-question: As a matter of current semantics, are multiple values mandatory only when the standard EXPLICITLY says so?  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 16 Apr 87 19:25:07 EDT Received: from CS.UTAH.EDU by SAIL.STANFORD.EDU with TCP; 16 Apr 87 16:04:50 PDT Received: by cs.utah.edu (5.54/utah-1.0) id AA10150; Thu, 16 Apr 87 17:07:29 MDT Received: by utah-orion.ARPA (5.31/4.40.2) id AA03261; Thu, 16 Apr 87 17:07:25 MDT Date: Thu, 16 Apr 87 17:07:25 MDT From: sandra%orion@cs.utah.edu (Sandra J Loosemore) Message-Id: <8704162307.AA03261@utah-orion.ARPA> Subject: bugnums (er, bignums) To: common-lisp@sail.stanford.edu I realize that running out of memory is a more general problem, and in fact my main concern in bring this issue up was the representation issue and the fact the CLtL defines constants and states (or recommends) minimum values for the sizes of other kinds of objects, such as arrays and floats. If, as some people have pointed out, having a stated limit on integer size would be silly because "there's nothing you can do once you run out of memory anyway" (or comments to that effect), than it is equally silly to specify limits on the size of these other objects. I am *not* proposing any minimum limits on the *number* of objects an implementation can support: this is purely an issue of the *size* of a single object. As a secondary issue, I thought that clarifying the semantics of integer overflow might be useful to those of us working with small implementations on small machines; in my case, a M68K box with a meg of memory. It's unlikely that I'd be able to fit a full CL on this machine and I think that there are other features far more important to the "spirit" of the spec than support for huge bignums. (I'm all for adhering to the "spirit" of the spec, particularly since I don't have much chance of adhering to the letter!) The point is, I can make anybody's bignum implementation overflow, whether the maximum number of bits I can have is 32 or most-positive-fixnum. It just happens a lot more often if the limit is 32. Incidentally, I can think of a few other potential problems with trying to allocate large objects, other than the obvious representation or running-out-of-memory problems. For example, your operating system may impose a limit on the size of contiguous memory block you can snarf up. (I've already run into this using a C compiler with 16 bit ints -- malloc takes an "int" sized argument....) Or, your Lisp compiler may assume that 16 bits is sufficient to represent the displacement used for indexing into an array. -Sandra -------  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 16 Apr 87 18:32:18 EDT Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 16 Apr 87 15:17:36 PDT Received: from Cabernet.ms by ArpaGateway.ms ; 16 APR 87 15:14:24 PDT Date: 16 Apr 87 15:14 PDT From: Pavel.pa@Xerox.COM Subject: Re: typos in Cltl In-reply-to: Timothy Daly 's message of 16 April 1987, 14:48:02 EDT To: DALY@ibm.com cc: common-lisp@sail.stanford.edu Message-ID: <870416-151424-1516@Xerox> That example isn't a typo. Note that the list (a b) is a member of the second argument to UNION. This fact is even brought out specifically in the text as a reason to use :test-not #'mismatch instead of :test #'equalp. Pavel  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 16 Apr 87 18:31:24 EDT Received: from NRL-AIC.ARPA by SAIL.STANFORD.EDU with TCP; 16 Apr 87 15:12:57 PDT Return-Path: Received: Thu, 16 Apr 87 17:12:59 est by nrl-aic.ARPA id AA22340 Date: 16 Apr 1987 16:16:36 EST (Thu) From: Dan Hoey Subject: Re: How much memory for bignum or other large data structure? To: Robert Elton Maas Message-Id: <545606196/hoey@nrl-aic> In-Reply-To: Robert Elton Maas's message of Thu, 16 Apr 87 154955 est Cc: common-lisp@sail.stanford.edu Date: Thu, 16 Apr 87 15:49:55 est From: Robert Elton Maas To: common-lisp@SAIL.STANFORD.EDU Cc: hoey@nrl-aic.ARPA A program can be aware of how close it is getting to using all available memory (address space, swap space, etc.) by means of calls to the LISP (CL) system, and adjust its behaviour accordingly to avoid actually reaching the absolute limit. The hard part is actually defining portably how to do this. I can imagine it might be hard for some systems to implement a function to answer ``I want to make 50 100k-bit bignums, 100 10k fixnum-arrays, and maybe 10K of conses, is there space?''. Comments from implementors? Maybe the function should take a key like :VERY-MUCH to request GC if necessary. Then again, a negative answer to this query might be less than useful if the reason is that the system doesn't support 10k fixnum arrays. And I don't favor adding a ton of hair to allow the system to answer some of the fine-grained questions Maas proposes. In particular ... there would be a lot of extra parameters. Yes, but compared to the total memory available the limit parameters would be insignificant in size, thus no problem. I'm concerned about the space consumed in the bookshelf and interaural areas. Date: 16 Apr 1987 14:19:04 EST (Thu) From: Dan Hoey Simpler would be to use ARRAY-TOTAL-SIZE-LIMIT for this value. I don't understand this proposal. I was not proposing addition of runtime-related storage information, because that has so far remained outside of CL's scope (unless someone out there actually has MAKE-ARRAY (and CONS?) side-effect ARRAY-TOTAL-SIZE-LIMIT). What I advocate is that *if* some implementation has a representational limit on BIGNUMS, it should be required to provide it. And rather than add the 776th symbol to LISP (we may be running out!), I suggested using the same limit that guarantees the size of a bit vector. The system may be able to make a larger bignum than ARRAY-TOTAL-SIZE-LIMIT, but the same is true of bit vectors. What I want the parameters for is to determine whether a given implementation is a toy or a system. Dan  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 16 Apr 87 18:28:44 EDT Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 16 Apr 87 15:10:54 PDT Received: from Cabernet.ms by ArpaGateway.ms ; 16 APR 87 15:10:31 PDT Date: 16 Apr 87 15:14 PDT From: Masinter.pa@Xerox.COM Subject: bignums are bogus In-reply-to: various cc: common-lisp@sail.stanford.edu Message-ID: <870416-151031-1512@Xerox> The only practical way I know of dealing with storage limits and the like in a programmatic way is to treat reaching them as well defined exceptional situations which signal conditions. Programs that care, such as those in embedded systems, can catch those exceptional situations and do something reasonable with them, whether it is a bignum storage overflow or running out of CONS space. This is addressed in part in the exceptional-situations-in-Lisp proposal, which is still (apparently) in committee.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 16 Apr 87 17:39:51 EDT Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 16 Apr 87 14:19:12 PDT Received: by navajo.stanford.edu; Thu, 16 Apr 87 14:18:18 PST Received: from bhopal.edsel.com by edsel.uucp (2.2/SMI-2.0) id AA01743; Thu, 16 Apr 87 13:03:36 pst Received: by bhopal.edsel.com (3.2/SMI-3.2) id AA10792; Thu, 16 Apr 87 14:00:34 PDT Date: Thu, 16 Apr 87 14:00:34 PDT From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White) Message-Id: <8704162100.AA10792@bhopal.edsel.com> To: navajo!DLA%DIAMOND.S4CC.Symbolics.COM@navajo.stanford.edu Cc: navajo!sandra%orion%cs.utah.edu@navajo.stanford.edu, navajo!common-lisp%sail@navajo.stanford.edu In-Reply-To: David L. Andre's message of Thu, 16 Apr 87 12:29 EDT Subject: bignums are bogus re: I always favored a pair of variables MOST-POSITIVE-BIGNUM and MOST-NEGATIVE-BIGNUM. :-) As silly as this may sound, I actually ran up against this. Really! It turns out that most implementations have the bignum's length stored in some field of fixed size (say, n bits). I accidentally computed up such an item on a 3600 about a year or so ago (while writing the "bignum" paper for the 1986 Lisp conference). It seemed as though the computation was taking far too long. Ultimately, I tracked it down to the fact that the ephemeral GC couldn't find enough space to copy the fool thing (even though it had been created), so it fell into the debugger, and was trying to print out this loser for me. In base 10! -- JonL -- P.S. It never finised the base-10-conversion process.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 16 Apr 87 17:35:19 EDT Received: from GSWD-VMS.ARPA by SAIL.STANFORD.EDU with TCP; 16 Apr 87 14:10:01 PDT Received: from mycroft.GSD (mycroft.Gould.COM) by gswd-vms.ARPA (5.52/) Message-Id: <8704162108.AA04289@gswd-vms.ARPA> Date: Thu, 16 Apr 87 15:00:04 CST From: preece%mycroft@gswd-vms.ARPA (Scott E. Preece) To: COMMON-LISP@sail.stanford.edu Subject: Re: Bognumosity Fahlman@C.CS.CMU.: stanley shebs: >> I think we should introduce an INTEGER-LENGTH-LIMIT constant which would be >> the largest value that INTEGER-LENGTH could return. > Presumably, then we also need a constant called CONS-LIMIT, which is the > maximum allowable length of any list. After all, someone might want to > use a list of T's and NIL's instead of a bit vector, and it weakens the > standard if we don't tell him exactly how long this list can be. > > What we do if someone creates two of these maximum-length lists, or a > maximum-length list of maximum-length lists, I don't know, but we had > better decide, since it will weaken the standard if we are vague about > what is allowed here. ---------- The problem is that that is exactly what the limits DON'T do -- they don't guarantee that at any given moment the biggest array you can create is size x. I don't really think the various limits already provided are worth much. Once in a while they may allow someone to decide early on that porting a particular application to a particular implementation is infeasible (because it uses arrays, or whatever, that are bigger than a limit), but it can never give much assurance that an application which does respect the limits is portable to a particular implementation, since at any given moment there may not be space available to allocate an object, even though it of legal size for the implementation. The implementor is left with the problem of deciding what to advertise as the limits for her particular implementation. What will users care about? The largest array that can be allocated on an empty system with maximum memory? The largest array that can be allocated on an empty system with the smallest memory configuration sold? The largest array that can be allocated with memory in a "typical" configuration and already populated with a "typical" amount of pre-existing stuff? What's typical? Adding more limits doesn't seem to me to be very useful. -- scott preece gould/csd - urbana uucp: ihnp4!uiucdcs!ccvaxa!preece arpa: preece@gswd-vms  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 16 Apr 87 17:31:25 EDT Received: from GSWD-VMS.ARPA by SAIL.STANFORD.EDU with TCP; 16 Apr 87 14:02:44 PDT Received: from mycroft.GSD (mycroft.Gould.COM) by gswd-vms.ARPA (5.52/) Message-Id: <8704162101.AA04269@gswd-vms.ARPA> Date: Thu, 16 Apr 87 15:00:04 CST From: preece%mycroft@gswd-vms.ARPA (Scott E. Preece) To: COMMON-LISP@sail.stanford.edu Subject: Re: Bognumosity Fahlman@C.CS.CMU.: stanley shebs: >> I think we should introduce an INTEGER-LENGTH-LIMIT constant which would be >> the largest value that INTEGER-LENGTH could return. > Presumably, then we also need a constant called CONS-LIMIT, which is the > maximum allowable length of any list. After all, someone might want to > use a list of T's and NIL's instead of a bit vector, and it weakens the > standard if we don't tell him exactly how long this list can be. > > What we do if someone creates two of these maximum-length lists, or a > maximum-length list of maximum-length lists, I don't know, but we had > better decide, since it will weaken the standard if we are vague about > what is allowed here. ---------- The problem is that that is exactly what the limits DON'T do -- they don't guarantee that at any given moment the biggest array you can create is size x. I don't really think the various limits already provided are worth much. Once in a while they may allow someone to decide early on that porting a particular application to a particular implementation is infeasible (because it uses arrays, or whatever, that are bigger than a limit), but it can never give much assurance that an application which does respect the limits is portable to a particular implementation, since at any given moment there may not be space available to allocate an object, even though it of legal size for the implementation. The implementor is left with the problem of deciding what to advertise as the limits for her particular implementation. What will users care about? The largest array that can be allocated on an empty system with maximum memory? The largest array that can be allocated on an empty system with the smallest memory configuration sold? The largest array that can be allocated with memory in a "typical" configuration and already populated with a "typical" amount of pre-existing stuff? What's typical? Adding more limits doesn't seem to me to be very useful. -- scott preece gould/csd - urbana uucp: ihnp4!uiucdcs!ccvaxa!preece arpa: preece@gswd-vms  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 16 Apr 87 17:23:16 EDT Received: from SAIL.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 16 Apr 87 13:49:24 PDT X-Date-last-edited: 1987 April 16 12:48:04 PST (=GMT-8hr) From: Robert Elton Maas To:common-lisp@SAIL.STANFORD.EDU CC:hoey@nrl-aic.ARPA Subject:How much memory for bignum or other large data structure? Date: Thu, 16 Apr 1987 10:27 EDT From: Rob MacLachlan The problem with running out of storage has no special relation to bignums of course. Some programs may require data structures larger than some implementations can support on a given hardware configuration. This is a potential portability problem, but I see nothing that can be done about it. I do. A program can be aware of how close it is getting to using all available memory (address space, swap space, etc.) by means of calls to the LISP (CL) system, and adjust its behaviour accordingly to avoid actually reaching the absolute limit. In this way a program can effective utilize virtually all the memory available on any given machine at any given time, instead of setting some arbitrary portable limit on memory usage which may be far below that actually available. Several kinds of programs run better the more memory they actually use. Examples are: (1) Sort/merge, the more data that can be sorted in memory, the larger sorted-segments can be emitted from the first pass and the fewer disk-passes needed to merge the sorted-segments into a single sorted-segment; (2) Any planning/lookahead program such as game playing or robotics, the more data that can be stored in a tree structure or hash table representing choices already analyzed, the further ahead the program can look without having to recompute the same choices over and over again, and thus the better "intelligence" the program can exhibit. In addition to parameters on particular data types that determine their limits because of internal representation, every LISP implementation should provide a way for a running program to ask how much memory is remaining not currently in use (or in a system with different kinds of data in different kinds of memory, how much memory of a particular kind is not currently not in use). A program could ask once, and if the answer comes back too small then force a garbage-collect-completion and ask again, and if the answer is still too small the program truncates its expansion at that point. This facility is crucial enough for the kinds of "artificial intelligence" programs typical of LISP, and is trivial enough to implement in the underlying LISP system and virtually impossible to hack up by user-level programming, that it should be a *required* feature of every implementation, i.e. should be in the CL standard. Perhaps Common Lisp should specify a minimum maximum size for bignums and require that an error be signalled if this is ever exceeded. I would guess that a limit of a few thousand bits would meet every use except the most common, namely impressing non-lispers by typing (FACT 1000) and getting screens full of digits. If the limit is representational, then indeed an implementation-dependent largest-size-allowed parameter should be provided by the system. If the limit is due to total memory use, any system query specifically regarding bignums would have to use the memory-remaining information to compute the bignum-that-would-fit information, to account for memory already used and hence not available. For the factorial hack, the toplevel FACT function could first approximate the factorial by logarithms, check to see whether there is enough memory for that data, and if not then complain and advise the user what the maximum workable argument to FACT currently is. Date: Thu, 16 Apr 87 12:29 EDT From: David L. Andre I always favored a pair of variables MOST-POSITIVE-BIGNUM and MOST-NEGATIVE-BIGNUM. :-) Of course if this is based on memory available, only one of the two could exist at any time, and as soon as it existed it would contradict itself because there'd be no room left for the bignum you really wanted. (This explanation is in case anybody didn't fully get the joke.) Date: Thu, 16 Apr 87 13:14:13 MDT From: shebs%orion@cs.utah.edu (Stanley T. Shebs) Here's a (serious) meta-proposal: every type of potentially unbounded size must have limit parameters. This would include arrays of all types, numbers (both floats and rationals), packages, random states, compiled code, hash tables, and structures. There wouldn't be any need for a CONS-LIMIT, because individual conses are always the same size, and a possible LIST-LIMIT would not be meaningful, because LIST is (OR CONS NULL). I second that proposal (see the first part of my message) with amendment (clarification) that these limit parameters refer to representation rather than memory available. For example, if BIGNUMs are implemented in a recursive way, there may be no limit on their size whatsoever other than memory available, and some extremely gigantic but sparse BIGNUMs may in fact be representable while some smaller ones that aren't sparse wouldn't; in such a case the limit parameter would be INFINITY. But if the number-of-digits of a BIGNUM is a FIXNUM, then there's an absolute representational limit which is given in the proposed limit parameter. -- In addition to these limit parameters, of course, is my proposal for runtime memory-not-yet-used query. Right now the only limits are on arrays, fixnums, and floats, so there would be a lot of extra parameters. Yes, but compared to the total memory available the limit parameters would be insignificant in size, thus no problem. Date: 16 Apr 1987 14:19:04 EST (Thu) From: Dan Hoey Simpler would be to use ARRAY-TOTAL-SIZE-LIMIT for this value. I don't understand this proposal. If all arrays are stored in some special place in memory, that limits their total size without being affected by CONSs consuming memory elsewhere, that would make sense. Or do you mean the total number of elements in a single array of multiple dimensions (axes) because of a machine limit on the size of an index register? Please clarify?  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 16 Apr 87 17:19:10 EDT Received: from CS.UTAH.EDU by SAIL.STANFORD.EDU with TCP; 16 Apr 87 13:54:13 PDT Received: by cs.utah.edu (5.54/utah-1.0) id AA03494; Thu, 16 Apr 87 14:56:23 MDT Received: by utah-orion.ARPA (5.31/4.40.2) id AA02607; Thu, 16 Apr 87 14:56:17 MDT Date: Thu, 16 Apr 87 14:56:17 MDT From: shebs%orion@cs.utah.edu (Stanley T. Shebs) Message-Id: <8704162056.AA02607@utah-orion.ARPA> To: DLW@alderaan.scrc.symbolics.com, Fahlman@cmu-cs-c.arpa, shebs%orion@cs.utah.edu Subject: Re: Bognumosity Cc: common-lisp@sail.stanford.edu In case it wasn't clear, I was *not* trying to address the issue of the relation between number/size of objects and size of memory available. I'm well aware that there are many problems, *and* very little research on them (if anybody knows of anything, I want to hear about it). I shouldn't have said anything about embedded systems, they're irrelevant. What can and should be done is to formalize the limitations that implementors wire into the representations of data objects. Those limits will be there no matter how much or how little memory is available, since they have to do with the bit patterns of data structures. If you have a program that wants a 1025 element array in a Lisp that limits arrays to 1024 elements, making the heap bigger isn't going to help. stan  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 16 Apr 87 16:33:59 EDT Received: from CS.UCLA.EDU by SAIL.STANFORD.EDU with TCP; 16 Apr 87 13:17:25 PDT From: sdcrdcf!darrelj@CS.UCLA.EDU Received: by sdc.uucp (4.12/sdcrdcf) id AA05609; Thu, 16 Apr 87 12:54:57 pst Message-Id: <8704162054.AA05609@sdc.uucp> Received: from XAVIER by sdcrdcf with PUP; Thu, 16 Apr 87 12:54 PST Date: 16 Apr 87 12:59 PDT (Thursday) Subject: Re: bignums are bogus In-Reply-To: sdcjove!cs.utah.edu!sandra%orion (Sandra J Loosemore)'s message of Thu, 16 Apr 87 00:01:04 MDT To: sdcjove!cs.utah.edu!sandra%orion (Sandra J Loosemore) Cc: common-lisp%sail.stanford.edu You could always take the approach that Xerox did. Implement bignums in such an inefficient way that processing time grows to unacceptable levels before representation limits are anything close to reached! (Actually I only see a few possibilities for representation: a list of fragments [Xerox uses lists of 14 bit components]; arrays of fragments; or something your hardware supports which is sort of large: e.g. 128 bit floating or 31 digit packed decimal on IBM 370s, 99 digit decimal on Symbol-IIR, etc. The first two could be expected to support a million bits on almost anything from an IBM PC upwards. Operation time and "consing" overhead would be pretty grim. Only the array case might have an obvious hard upper bound. The third case would certainly verge on "broken" by almost any reasonable standards. Darrel  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 16 Apr 87 16:29:40 EDT Received: from [192.10.41.109] by SAIL.STANFORD.EDU with TCP; 16 Apr 87 13:10:02 PDT Received: from CHICOPEE.SCRC.Symbolics.COM by ALDERAAN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 72653; Thu 16-Apr-87 16:09:51 EDT Date: Thu, 16 Apr 87 16:06 EDT From: Daniel L. Weinreb Subject: Re: Bognumosity To: shebs%orion@cs.utah.edu, Fahlman@CMU-CS-C.ARPA cc: common-lisp@sail.stanford.edu In-Reply-To: <8704161914.AA01837@utah-orion.ARPA> Message-ID: <870416160605.2.DLW@CHICOPEE.SCRC.Symbolics.COM> Date: Thu, 16 Apr 87 13:14:13 MDT From: shebs%orion@cs.utah.edu (Stanley T. Shebs) There wouldn't be any need for a CONS-LIMIT, because individual conses are always the same size, But what if I wanted to write a program for, as you say, an embedded system, and I needed to know exactly how many cons cells I can create and be quite certain that I won't run out of memory? Conversely, if I know what the bignum limit is, and I stay within that limit, but make zillions of such legal bignums, then I might run out of virtual memory. So whether the individual object is of fixed size or of variable size doesn't really matter, for the purposes you're referring to.  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 16 Apr 87 15:52:44 EDT Received: from NRL-AIC.ARPA by SAIL.STANFORD.EDU with TCP; 16 Apr 87 12:37:30 PDT Return-Path: Received: Thu, 16 Apr 87 14:37:44 est by nrl-aic.ARPA id AA21715 Date: 16 Apr 1987 14:19:04 EST (Thu) From: Dan Hoey Subject: Re: Bognumosity To: common-lisp@sail.stanford.edu Message-Id: <545599144/hoey@nrl-aic> Date: Thu, 16 Apr 87 11:11:56 MDT From: shebs%orion@cs.utah.edu (Stanley T. Shebs) Message-Id: <8704161711.AA01398@utah-orion.ARPA> To: common-lisp@sail.stanford.edu I think we should introduce an INTEGER-LENGTH-LIMIT constant which would be the largest value that INTEGER-LENGTH could return. It should be specifed to be at least as large as MOST-POSITIVE-FIXNUM.... Simpler would be to use ARRAY-TOTAL-SIZE-LIMIT for this value. This is based on the duality of bignums and bit vectors. If implementors then want to represent bignums in some silly way that restricts them, they can then reduce their advertised ATSL (but not below 1024). I think a Lisp with 1K-bit bignums would be about as unusable as a lisp with 1K-element arrays. Dan  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 16 Apr 87 15:33:32 EDT Received: from IBM.COM by SAIL.STANFORD.EDU with TCP; 16 Apr 87 12:16:34 PDT Date: 16 April 1987, 14:48:02 EDT From: Timothy Daly To: common-lisp@sail.stanford.edu Message-Id: <041687.144803.daly@ibm.com> Subject: typos in Cltl There is a typo on p 277. The line reads: ((a b) #(f 3) .... it should read (#(a b) #(f 3) .... the dispatching macro character is missing. I didn't see this one in the list of typos dated 12/85. Is there a later one?  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 16 Apr 87 15:33:06 EDT Received: from CS.UTAH.EDU by SAIL.STANFORD.EDU with TCP; 16 Apr 87 12:11:42 PDT Received: by cs.utah.edu (5.54/utah-1.0) id AA28433; Thu, 16 Apr 87 13:14:17 MDT Received: by utah-orion.ARPA (5.31/4.40.2) id AA01837; Thu, 16 Apr 87 13:14:13 MDT Date: Thu, 16 Apr 87 13:14:13 MDT From: shebs%orion@cs.utah.edu (Stanley T. Shebs) Message-Id: <8704161914.AA01837@utah-orion.ARPA> To: Fahlman@c.cs.cmu.edu, shebs%orion@cs.utah.edu Subject: Re: Bognumosity Cc: common-lisp@sail.stanford.edu Any vagueness on max size of bignums is no more acceptable than it is for arrays or fixnums or floats, all of which have plenty of constants defining *their* limits! I think we should introduce an INTEGER-LENGTH-LIMIT constant which would be the largest value that INTEGER-LENGTH could return. Presumably, then we also need a constant called CONS-LIMIT, which is the maximum allowable length of any list. After all, someone might want to use a list of T's and NIL's instead of a bit vector, and it weakens the standard if we don't tell him exactly how long this list can be. That's part of my thesis work, so I won't insist on it being in the standard right now! A CONS-LIMIT of some sort would be necessary in a Lisp system that produces programs for embedded systems, however, so it's not as ridiculous as it appears to be... Maybe the scope of the smiley face at the end of your message was meant to be the whole message? Sorry, I was quite serious. If bignum size limits are silly, then why are array size limits not silly? Seems inconsistent. Here's a (serious) meta-proposal: every type of potentially unbounded size must have limit parameters. This would include arrays of all types, numbers (both floats and rationals), packages, random states, compiled code, hash tables, and structures. There wouldn't be any need for a CONS-LIMIT, because individual conses are always the same size, and a possible LIST-LIMIT would not be meaningful, because LIST is (OR CONS NULL). Right now the only limits are on arrays, fixnums, and floats, so there would be a lot of extra parameters. On the other hand, I've observed some rather wild variation in the number of bits in a random state, which affects the quality of random number generation. An unlucky user of packages may find that a package is implemented with a hash table, which is implemented with an array, which has an ARRAY-DIMENSION-LIMIT of 1024, limiting the total number of symbols in a package to that many. I'm sure we're all familiar with the sort of terminology that users apply to implementors when tricks like this come to light... Anyway, if all this is stupid, let me know and I'll shut up. stan  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 16 Apr 87 14:11:58 EDT Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 16 Apr 87 10:54:24 PDT Received: ID ; Thu 16 Apr 87 13:44:06-EDT Date: Thu, 16 Apr 1987 13:43 EDT Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: shebs%orion@cs.utah.edu (Stanley T. Shebs) Cc: common-lisp@SAIL.STANFORD.EDU Subject: Bognumosity In-reply-to: Msg of 16 Apr 1987 13:11-EDT from shebs%orion at cs.utah.edu (Stanley T. Shebs) Any vagueness on max size of bignums is no more acceptable than it is for arrays or fixnums or floats, all of which have plenty of constants defining *their* limits! I think we should introduce an INTEGER-LENGTH-LIMIT constant which would be the largest value that INTEGER-LENGTH could return. Presumably, then we also need a constant called CONS-LIMIT, which is the maximum allowable length of any list. After all, someone might want to use a list of T's and NIL's instead of a bit vector, and it weakens the standard if we don't tell him exactly how long this list can be. What we do if someone creates two of these maximum-length lists, or a maximum-length list of maximum-length lists, I don't know, but we had better decide, since it will weaken the standard if we are vague about what is allowed here. Let's just say that every legal Common Lisp must have at least N cons cells available to the user at all times, no matter what he may have used so far, or else it is not a legal Common Lisp. N should be at least a million. Or maybe N should be seven. A sufficiently tight standard will have no instances. Maybe the scope of the smiley face at the end of your message was meant to be the whole message? -- Scott  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 16 Apr 87 14:02:10 EDT Received: from TUNNEL.CS.UCL.AC.UK by SAIL.STANFORD.EDU with TCP; 16 Apr 87 10:41:38 PDT Received: from aiva.edinburgh.ac.uk by mv1.Cs.Ucl.AC.UK via Janet with NIFTP id aa08755; 16 Apr 87 13:06 WET From: Jeff Dalton Date: Thu, 16 Apr 87 14:04:58 GMT Message-Id: <1827.8704161404@aiva.ed.ac.uk> To: common-lisp@sail.stanford.edu, sandra <@cs.utah.edu:sandra@orion.arpa> Subject: Re: bignums are bogus > "Common Lisp in principle imposes no limit on the magnitude of an > integer. Note "in principle". > I don't know of any machine that has an infinitely large amount of memory, > or even an infinitely large address space. Practical limits of this sort also apply to things like the maximum number of conses, the maximum length of a list, etc. Presumably, you don't think lists are bogus... > I expect some implementations of bignums have other constraints as well: > assuming the number of bigits is a fixnum, storing the bigits in an array > (limiting the number of bigits to the maximum array size), or similar > representation-related problems. Well, if the representation imposes a limit lower than that imposed by the total storage available we might be justified in saying it is not a correct implementation. Of course, we would only be inclined to do this if the lower limit was relatively small (e.g. number of bigits in a byte). Now I suppose there'll be hundreds of these messages (at least as many as about compiling CASE).  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 16 Apr 87 13:27:01 EDT Received: from CS.UTAH.EDU by SAIL.STANFORD.EDU with TCP; 16 Apr 87 10:09:21 PDT Received: by cs.utah.edu (5.54/utah-1.0) id AA21692; Thu, 16 Apr 87 11:12:00 MDT Received: by utah-orion.ARPA (5.31/4.40.2) id AA01398; Thu, 16 Apr 87 11:11:56 MDT Date: Thu, 16 Apr 87 11:11:56 MDT From: shebs%orion@cs.utah.edu (Stanley T. Shebs) Message-Id: <8704161711.AA01398@utah-orion.ARPA> To: common-lisp@sail.stanford.edu Subject: Bognumosity It only hurts CL as a standard when people start talking about the "spirit" of the specification as a substitute for precision. Some symbolic algebra folks like really big numbers, starting at a "few thousand bits" and getting bigger. Bignums can also be a good representation technique for certain kinds of data structures (almost like bit vectors, but with different ops available). Any vagueness on max size of bignums is no more acceptable than it is for arrays or fixnums or floats, all of which have plenty of constants defining *their* limits! I think we should introduce an INTEGER-LENGTH-LIMIT constant which would be the largest value that INTEGER-LENGTH could return. It should be specifed to be at least as large as MOST-POSITIVE-FIXNUM, with the usual exhortation that "Implementors are encouraged to make this limit as large as practicable without sacrificing performance." :-) stan  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 16 Apr 87 12:44:08 EDT Received: from [128.81.51.3] by SAIL.STANFORD.EDU with TCP; 16 Apr 87 09:30:27 PDT Received: from LIMPKIN.S4CC.Symbolics.COM by DIAMOND.S4CC.Symbolics.COM via CHAOS with CHAOS-MAIL id 77351; Thu 16-Apr-87 12:29:18 EDT Date: Thu, 16 Apr 87 12:29 EDT From: David L. Andre Subject: bignums are bogus To: sandra%orion@cs.utah.edu, common-lisp@sail.stanford.edu Message-ID: <870416122902.2.DLA@LIMPKIN.S4CC.Symbolics.COM> I always favored a pair of variables MOST-POSITIVE-BIGNUM and MOST-NEGATIVE-BIGNUM. :-)  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 16 Apr 87 12:16:15 EDT Received: from [128.81.51.3] by SAIL.STANFORD.EDU with TCP; 16 Apr 87 08:59:26 PDT Received: from KOYAANISQATSI.S4CC.Symbolics.COM by DIAMOND.S4CC.Symbolics.COM via CHAOS with CHAOS-MAIL id 77243; Thu 16-Apr-87 09:32:15 EDT Date: Thu, 16 Apr 87 09:35 EDT From: David C. Plummer Subject: bignums are bogus To: Sandra J Loosemore , common-lisp@sail.stanford.edu In-Reply-To: <8704160601.AA15364@utah-orion.ARPA> Message-ID: <870416093545.0.DCP@KOYAANISQATSI.S4CC.Symbolics.COM> Character-Type-Mappings: (1 0 (NIL 0) (:FIX :BOLD :NORMAL) "CPTFONTCB") Fonts: CPTFONT, CPTFONTCB I believe the spirit of CL is to encourage implementations to make the maximum size of bignums "reasonably large". I also believe the spirit of CL is to have the lower limit be rather large, say at least 5000 bits. The smaller the size of the largest bignum, the more applications you lock out, such as symbolic algebras. If you make the maximum size of an integer be the maximum size of a fixnum, does that imply (+ most-positive-fixnum 1) generates an error? I agree that a CLtL-defined implementation-dependent constant describing the maximum number of bits of a bignum is consistent with CLtL; I'm not sure how applications would make use of it, other than (when (< maximum-number-of-bignum-bits 9342) (error "This application won't work on this machine; bignums are too small.")) BTW, the Symbolics 3600 implementation limits bignums to 2^28 bits. Applications that create such things are going to page like mad. The error that is generated when exceeding is along the lines (ash 1 most-positive-fixnum) 1Error: ASH shifting much too far to the left  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 16 Apr 87 11:59:41 EDT Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 16 Apr 87 08:33:23 PDT Received: ID ; Thu 16 Apr 87 11:05:25-EDT Date: Thu, 16 Apr 1987 10:27 EDT Message-ID: From: Rob MacLachlan To: sandra%orion@cs.utah.edu (Sandra J Loosemore) Cc: common-lisp@SAIL.STANFORD.EDU Subject: bignums are bogus In-reply-to: Msg of 16 Apr 1987 02:01-EDT from sandra%orion at cs.utah.edu (Sandra J Loosemore) Date: Thursday, 16 April 1987 02:01-EDT From: sandra%orion at cs.utah.edu (Sandra J Loosemore) To: common-lisp at sail.stanford.edu Re: bignums are bogus Three questions: (1) What is supposed to happen if the user attempts to create an integer larger than the implementation can support? A reasonable implementation would signal an error of some sort, although if paging space is physically exhausted it may be difficult for Lisp to recover gracefully. Many OS'es don't provide any way to user programs to tell how how much paging space is left, and tend to wedge in various ways when it exhausted. (2) If "it is an error" to create a bignum larger than the implementation can handle, how can user programs detect and avoid this situation? The problem with running out of storage has no special relation to bignums of course. Some programs may require data structures larger than some implementations can support on a given hardware configuration. This is a potential portability problem, but I see nothing that can be done about it. (3) Given that every implementation has some practical limit on the size of integers, but CLtL leaves that limit unspecified, is there any reason why an implementation couldn't choose to make that limit fairly small, like 32 or 64 bits or whatever the largest machine integer size is? For that matter, what if the maximum size of an integer just happened to be the maximum size of a fixnum? Your implementation might reasonably be considered to be unreasonable, and not in the spirit of the specification. As I said earlier, it is quite possible to build an implementation that compiles with the letter of a specification and is still totally unusable. I'm not a big bignum user, but I think it might be marginally reasonable to support fixed-size 64 bit bignums. I suspect that 64 bit bignums would take care of a large percentage of uses. This would also keep get-universal-time happy for a while to come. Perhaps Common Lisp should specify a minimum maximum size for bignums and require that an error be signalled if this is ever exceeded. I would guess that a limit of a few thousand bits would meet every use except the most common, namely impressing non-lispers by typing (FACT 1000) and getting screens full of digits. Rob  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 16 Apr 87 11:58:52 EDT Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 16 Apr 87 08:33:08 PDT Received: ID ; Thu 16 Apr 87 11:04:34-EDT Date: Thu, 16 Apr 1987 09:13 EDT Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: sandra%orion@cs.utah.edu (Sandra J Loosemore) Cc: common-lisp@SAIL.STANFORD.EDU Subject: bignums are bogus In-reply-to: Msg of 16 Apr 1987 02:01-EDT from sandra%orion at cs.utah.edu (Sandra J Loosemore) The intent of that passage is that the size of bignums should be *much* larger than the size of fixnums. It is true that the language does not require that bignums be able to exhaust *all* of the machine's available address space (or swap space), and that other implementation limits (such as the maximum array index being a fixnum) may intrude in some cases. But I think that any implementation that doesn't normally allow bignums of at least a few K bytes is cheating on the spirit, if not the letter, of the specification. As for how these things die when you finally reach the overflow point, I think that this was viewed as a rare enough thing that it wasn't worth trying to standardize it as a separate error type. Presumably you get the same effect that you would get if you exhausted the available space in some other way, or if you asked for an array bigger than the space remaining. It is tasteful for this to be a clean, recoverable error, but it is not required to be -- there has to be some freedom here, since operating systems vary in the control they give you over memory allocation and the amount of information they will give you about available space. -- Scott  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 16 Apr 87 11:58:32 EDT Received: from VAXA.ISI.EDU by SAIL.STANFORD.EDU with TCP; 16 Apr 87 08:37:52 PDT Received: from hpai00 (hpai00.isi.edu) by vaxa.isi.edu (4.12/4.7) id AA28527; Thu, 16 Apr 87 00:16:39 pst Received: by hpai00 ; Thu, 16 Apr 87 01:15:33 pdt From: vrotney@vaxa.isi.edu Message-Id: <8704160815.AA02532@hpai00> Date: Thu, 16 Apr 87 00:15:23 PDT Subject: CLARIFICATION: [italics]package arguments. To: common-lisp@SAIL.STANFORD.EDU X-Mailer: NMail [$Revision: 2.6 $] Are the package functions that take a package argument in CLTL with the name [italics]package allowed to have a string or symbol as that argument? If so, HP take note, we had to make a lot of changes in our Symbolics generated code to make it port to CL on the HPAIWS. If not, then why not? Bill Vrotney USC/ISI -------  Received: from SAIL.STANFORD.EDU (TCP 1200000013) by AI.AI.MIT.EDU 16 Apr 87 02:31:11 EDT Received: from CS.UTAH.EDU by SAIL.STANFORD.EDU with TCP; 15 Apr 87 22:58:29 PDT Received: by cs.utah.edu (5.54/utah-1.0) id AA02358; Thu, 16 Apr 87 00:01:08 MDT Received: by utah-orion.ARPA (5.31/4.40.2) id AA15364; Thu, 16 Apr 87 00:01:04 MDT Date: Thu, 16 Apr 87 00:01:04 MDT From: sandra%orion@cs.utah.edu (Sandra J Loosemore) Message-Id: <8704160601.AA15364@utah-orion.ARPA> Subject: bignums are bogus To: common-lisp@sail.stanford.edu (Time to get out the asbestos suit -- I'm sure this is going to generate a lot of flamage....) Quoting from CLtL (p 13): "Common Lisp in principle imposes no limit on the magnitude of an integer; storage is automatically allocated as necessary to represent large integers." This is the only statement I can find on the subject of how large integers can be in CL. I think we can probably all agree that every implementation does impose *some* limit on the size of integers; I don't know of any machine that has an infinitely large amount of memory, or even an infinitely large address space. I expect some implementations of bignums have other constraints as well: assuming the number of bigits is a fixnum, storing the bigits in an array (limiting the number of bigits to the maximum array size), or similar representation-related problems. Three questions: (1) What is supposed to happen if the user attempts to create an integer larger than the implementation can support? An easy way to do this would be to make several layers of calls to "ash": (let ((huge most-positive-fixnum)) (dotimes (i most-positive-fixnum) (setq huge (+ huge (ash huge huge)))) huge) (2) If "it is an error" to create a bignum larger than the implementation can handle, how can user programs detect and avoid this situation? If the constraint is in the representation, having a constant to indicate the maximum number of bits is a possibility, but if the problem is running out of memory, it wouldn't be of much use. (3) Given that every implementation has some practical limit on the size of integers, but CLtL leaves that limit unspecified, is there any reason why an implementation couldn't choose to make that limit fairly small, like 32 or 64 bits or whatever the largest machine integer size is? (I realize that doing so might break the Universal Time functions, but I've already noted that it's fairly easy to break other built-in functions as well, regardless of how big integers can be.) For that matter, what if the maximum size of an integer just happened to be the maximum size of a fixnum? -Sandra -------