Received: from SU-AI.ARPA by AI.AI.MIT.EDU 29 Jun 86 20:18:07 EDT Received: from UTAH-CS.ARPA by SU-AI.ARPA with TCP; 29 Jun 86 17:09:59 PDT Received: by utah-cs.ARPA (5.31/4.40.2) id AA28711; Sun, 29 Jun 86 18:09:44 MDT Received: by utah-orion.ARPA (5.31/4.40.2) id AA12645; Sun, 29 Jun 86 18:09:30 MDT Date: Sun, 29 Jun 86 18:09:30 MDT From: shebs%utah-orion@utah-cs.arpa (Stanley Shebs) Message-Id: <8606300009.AA12645@utah-orion.ARPA> Newsgroups: fa.common-lisp Subject: Re: Error Signalling Summary: Expires: References: Sender: Reply-To: shebs@utah-orion.UUCP (Stanley Shebs) Followup-To: Distribution: Organization: University of Utah CS Dept Keywords: Apparently-To: common-lisp@su-ai.arpa In article Fahlman@C.CS.CMU.EDU (Scott E. Fahlman) writes: > >Or am I misunderstanding the goals of PCLS? We're not going to live with it forever, it's just a hack so we can learn CL implementation and figure out the right way to do a full CL. We've waffled about error checking and cringed at the storage overhead of #2, even though it's probably the best choice. >The thought was that the user might want to convey more information >about his preferences than would be possible in using binary-valued >switches. A limited range of numbers seemed like the most reasonable >and least confusing solution, though it's clearly not ideal. A number >of the more complex CLisp implementations make good use of the >multiplicity of values to fine-tune which optimizations their compiler >employs. It's *probably* not a portability problem that (safety 1) means something different in different implementations. PCLS uses the speed settings to switch various kinds of optimizations, but we didn't have much intuition about what the difference between (speed 2) and (speed 3) should be, and it seemed that users who were picky about those things were just as likely to want to know about PCLS's compiler flags that controlled each sort of optimization. No big deal, I guess. >-- Scott stan  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 29 Jun 86 19:29:27 EDT Received: from UTAH-20.ARPA by SU-AI.ARPA with TCP; 29 Jun 86 16:20:17 PDT Date: Sun 29 Jun 86 17:18:50-MDT From: SANDRA Subject: Error signalling To: common-lisp@SU-AI.ARPA Message-ID: <12218786489.6.LOOSEMORE@UTAH-20.ARPA> Let me get this straight: what is being proposed is that when *user* code is compiled with safety=0, *system* functions are allowed to bypass error checking? Presumably one would have to implement this by having two sets of system functions, the default one that does the error checks and another one that doesn't, and make the compiler smart enough to make the substitution when appropriate. Bleah -- I can see doing this manually for a few functions, but trying to cover all the places where CLtL says "it is an error" seems like a royal pain. If this is adopted as part of the standard, I'd also like to see some mechanisms to help automate the implementation provided. I think "user" code could also make good use of the same hooks for optional error checking. A minor point -- why restrict error checking to all-or-nothing? Some assumptions about argument values may be "safer" than others. If you set safety=3 you probably want to be extra paranoid and do *more* error checking than the default. In other words, the error checks should be qualified with a safety setting.... -Sandra -------  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 29 Jun 86 15:38:29 EDT Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 29 Jun 86 12:31:39 PDT Received: ID ; Sun 29 Jun 86 15:31:43-EDT Date: Sun, 29 Jun 1986 15:31 EDT Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: common-lisp@SU-AI.ARPA Subject: Error Signalling In reply to: shebs at utah-orion.UUCP (Stanley Shebs) Regarding your comment that PCLS is "pretty sleazy most of the time" with respect to argument checking and that "users seem to like it that way", it would of course be allowable for any self-proclaimed subset not to do this checking. Whether that's among the ways in which you would want to deviate from the standard is another question, but it's one for your group to decide internally, since you have declared that you don't intend to implement the full standard. (Or am I misunderstanding the goals of PCLS?) Anyway, in your later note you seem to agree that requiring this checking in the standard, except where the user has indicated that safety is not important, is OK with you, so I guess we have no disagreement. BTW, why not flush the silly numbers and use t,nil or else keyword names like :unsafe and :bombproof and :nuclear-qualified? 0s and 3s don't convey much meaning.... The thought was that the user might want to convey more information about his preferences than would be possible in using binary-valued switches. A limited range of numbers seemed like the most reasonable and least confusing solution, though it's clearly not ideal. A number of the more complex CLisp implementations make good use of the multiplicity of values to fine-tune which optimizations their compiler employs. -- Scott  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 29 Jun 86 15:01:47 EDT Received: from XEROX.COM by SU-AI.ARPA with TCP; 29 Jun 86 11:54:16 PDT Received: from Cabernet.ms by ArpaGateway.ms ; 29 JUN 86 11:37:35 PDT Date: 27 Jun 86 18:25 PDT Sender: Bobrow.pa@Xerox.COM Subject: Re: portability of pathnames In-reply-to: David A. Moon 's message of Mon, 23 Jun 86 21:14 EDT To: Moon@STONY-BROOK.SCRC.Symbolics.COM cc: NGALL@G.BBN.COM, common-lisp@SU-AI.ARPA From: Bobrow.pa@Xerox.COM (Danny Bobrow) Message-ID: <860629-113735-2153@Xerox> I have been looking at the documentation for logical path names and have been impressed by their utility. We had been trying to reinvent something with the similar properties for other purposes. I do not yet understand them well, but I think logical path names might fill much of the need expressed. We should look at them for Common Lisp. -- danny  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 29 Jun 86 14:56:58 EDT Received: from UTAH-CS.ARPA by SU-AI.ARPA with TCP; 29 Jun 86 11:49:56 PDT Received: by utah-cs.ARPA (5.31/4.40.2) id AA25909; Sun, 29 Jun 86 12:49:40 MDT Received: by utah-orion.ARPA (5.31/4.40.2) id AA12165; Sun, 29 Jun 86 12:49:29 MDT Date: Sun, 29 Jun 86 12:49:29 MDT From: shebs%utah-orion@utah-cs.arpa (Stanley Shebs) Message-Id: <8606291849.AA12165@utah-orion.ARPA> Newsgroups: fa.common-lisp Subject: Re: Error Signalling Summary: Expires: References: Sender: Reply-To: shebs@utah-orion.UUCP (Stanley Shebs) Followup-To: Distribution: Organization: University of Utah CS Dept Keywords: Apparently-To: common-lisp@su-ai.arpa In article Fahlman@C.CS.CMU.EDU (Scott E. Fahlman) writes: >2. The rigorous solution: For errors of the types described above, it is >REQUIRED that implementations signal an error in interpreted code. It >is also required that these errors be signalled in compiled code unless >(optimize (safety 0)) is in effect at compile time. This would be good - I bet a lot of system code would benefit from the scrutiny necessary to fix this up. Will increase size of implementations, especially those that need to have two versions of function (safe one calls unsafe one, of course, but still some overhead I think). BTW, why not flush the silly numbers and use t,nil or else keyword names like :unsafe and :bombproof and :nuclear-qualified? 0s and 3s don't convey much meaning.... stan  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 29 Jun 86 14:31:43 EDT Received: from UTAH-CS.ARPA by SU-AI.ARPA with TCP; 29 Jun 86 11:23:20 PDT Received: by utah-cs.ARPA (5.31/4.40.2) id AA25310; Sun, 29 Jun 86 12:22:58 MDT Received: by utah-orion.ARPA (5.31/4.40.2) id AA12060; Sun, 29 Jun 86 12:22:47 MDT Date: Sun, 29 Jun 86 12:22:47 MDT From: shebs%utah-orion@utah-cs.arpa (Stanley Shebs) Message-Id: <8606291822.AA12060@utah-orion.ARPA> Newsgroups: fa.common-lisp Subject: Re: Argument Lists Summary: Expires: References: Sender: Reply-To: shebs@utah-orion.UUCP (Stanley Shebs) Followup-To: Distribution: Organization: University of Utah CS Dept Keywords: Apparently-To: common-lisp@su-ai.arpa In article Fahlman@C.CS.CMU.EDU (Scott E. Fahlman) writes: > > It is not required that an > implementation signal an error when there are either too many or too few > arguments... > >I would have sworn that implementaitosn were required to signal an error >in this case, but a scan of CLtL seems to indicate that you are right. >The section on argument lists consistently says "is an error" and not >"signals an error". I can't remember (or imagine) why these cases >aren't required to signal an error, and I think this should be fixed. I thought the reason was that implementations shouldn't be required to do *any* checking as a part of function-calling protocol, since it would slow things down on stock hardware. >Does anyone disagree? It's fine as it stands. Error checking should be optional, except in the most infrequent or potentially catastrophic situations (i.e. package system). >Are there any implementations out there that >don't signal errors when a function is given too many or too few args? PCLS is pretty sleazy most of the time... people seem to like it that way :-) >-- Scott stan  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 29 Jun 86 14:23:25 EDT Received: from UTAH-CS.ARPA by SU-AI.ARPA with TCP; 29 Jun 86 11:17:05 PDT Received: by utah-cs.ARPA (5.31/4.40.2) id AA25203; Sun, 29 Jun 86 12:16:22 MDT Received: by utah-orion.ARPA (5.31/4.40.2) id AA12008; Sun, 29 Jun 86 12:16:11 MDT Date: Sun, 29 Jun 86 12:16:11 MDT From: shebs%utah-orion@utah-cs.arpa (Stanley Shebs) Message-Id: <8606291816.AA12008@utah-orion.ARPA> Newsgroups: fa.common-lisp Subject: Re: portability of pathnames Summary: Expires: References: <860623211400.6.MOON@EUPHRATES.SCRC.Symbolics.COM> Sender: Reply-To: shebs@utah-orion.UUCP (Stanley Shebs) Followup-To: Distribution: Organization: University of Utah CS Dept Keywords: Apparently-To: common-lisp@su-ai.arpa In article <860623211400.6.MOON@EUPHRATES.SCRC.Symbolics.COM> Moon@STONY-BROOK.SCRC.Symbolics.COM (David A. Moon) writes: >Get your hands on a Symbolics document set and read about Logical >Pathnames. If I understand your requirements, Logical Pathnames are >exactly what you're looking for. Logical pathnames are good in that they can be machine-independent. However, it seemed to me that they amounted to building a mini-filesystem within Common Lisp, and we have enough problems compromising on a basic language without trying to standardize on the operating system too! stan  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 29 Jun 86 14:17:24 EDT Received: from UTAH-CS.ARPA by SU-AI.ARPA with TCP; 29 Jun 86 11:09:44 PDT Received: by utah-cs.ARPA (5.31/4.40.2) id AA25027; Sun, 29 Jun 86 12:09:29 MDT Received: by utah-orion.ARPA (5.31/4.40.2) id AA11953; Sun, 29 Jun 86 12:09:18 MDT Date: Sun, 29 Jun 86 12:09:18 MDT From: shebs%utah-orion@utah-cs.arpa (Stanley Shebs) Message-Id: <8606291809.AA11953@utah-orion.ARPA> Newsgroups: fa.common-lisp Subject: Re: portability of pathnames Summary: Expires: References: <[G.BBN.COM]23-Jun-86 11:11:44.NGALL> Sender: Reply-To: shebs@utah-orion.UUCP (Stanley Shebs) Followup-To: Distribution: Organization: University of Utah CS Dept Keywords: Apparently-To: common-lisp@su-ai.arpa >From: "Scott E. Fahlman" >I came across your complaint about portability of pathnames and the >problems with make-pathname. I was just wondering if >you had anything specific to propose. I submit there are NO portable things to be done with pathnames. Even something as innocuous as (load "foo-bar-baz") isn't going to be portable to machines with only short filenames, or ones that don't allow hyphens in filenames. Proposals that the implementation can map names around are bogus, since in the simplest case (changing chars in the name) things like (with-open-file (s1 "foo-bar-baz" :direction :output) (with-open-file (s2 "foo_bar_baz" :direction :output) ...)) will get pretty strange, and in the most complex case, the implementation must have its own mini-filesystem to conform to the standard. As things stand now, you can't have a Common Lisp on a machine without a filesystem! More plausibly, you can't have one where random objects like floating-point numbers designate files (a la the EZ programming environment). In the practice of porting programs, I've had to put all explicit filenames and pathname operations into machine-specific files. Even something like (merge-pathnames :type "lisp" :defaults "/usr/games/doctor") is not guaranteed to work on a Unix implementation that decides (correctly) that Unix files don't really have types. My proposal: flush all pathname stuff entirely. Pathnames are abstract objects with no user-visible components. The PATHNAME function still exists to coerce other kinds of objects (probably strings) into pathnames; OPEN and other operations need not look any different. TRUENAME is probably still worthwhile, but none of the others are truly portable, so there's little point in standardizing on them. Implementations can provide whatever ones are appropriate. There's a certain analogy with character bits and fonts, the main difference being that more people feel compelled to do *something* with pathnames. The standard is so full of loopholes that once one gets outside the realm of vanilla Unix/VMS/Tops-20 filenames, any pathname manipulation is just not going to work right. So let's shrink the standard and not exercise ourselves trying to design a filesystem interface that will accommodate every strangeness invented by the OS people. stan  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 29 Jun 86 14:06:23 EDT Received: from XEROX.COM by SU-AI.ARPA with TCP; 29 Jun 86 10:57:56 PDT Received: from Cabernet.ms by ArpaGateway.ms ; 29 JUN 86 10:02:31 PDT Date: 26 Jun 86 15:36 PDT From: Masinter.pa@Xerox.COM To: common-lisp@su-ai.ARPA Message-ID: <860629-100231-1314@Xerox> Sounds like I wasn't clear enough. When I suggested portable programs "stick within the set of standard characters" I was referring to "the Common Lisp character set" as defined on pp 20-21 of "Common Lisp the Language" by Guy L. Steele Jr. as follows: "The Common Lisp character set consists of a space character #\Space, a newline character #\Newline, and the following ninety-four non-blank printing characters or their equivalents..." It looks awfully specific to me, and I'm not sure what our friends at IBM or Japan would be chuckling about. In reply to KMPs other points: "It's important to distinguish between implementation dependent behavior and unpredictable behavior. Many things in Common Lisp are conceptually well-defined even though they vary from implementation to implementation. For example, the behavior of (1+ MOST-POSITIVE-FIXNUM) varies in detail from implementation to implementation, but conceptually it does not. I don't think that it's inappropriate to describe a program as having useful commands bound to keys and to tell the user to type "?" to see a list of the commands available." I agree whole-heartedly with this analysis and the appropriateness of the situation you describe. "The issue is much bigger than you make it out to be and if you claim it to be fatal, then I claim you're attacking the whole notion of whether CL can be portable..." I object to your claim: I firmly believe that CL can be portable and I'm making no such attack. That's the point of this whole discussion. I think that this is in fact one of the few intrinsicly non-portable parts of the language. I agree that CHAR-BITS-LIMIT is in the same class as "MOST-POSITIVE-FIXNUM". The issue as I see it is: does this abstraction *encourage* or *discourage* users from writing portable programs? I claim that this particular feature works against portability: It is my belief that having "char-bits" in the book will encourage users who are working in an implementation which supports "char-bits" to rely upon "char-bits" in their programs, with a nod to the fact "well, those lusers without char-bits just can't use this program". If char-bits were *not* in the standard, then the writer of a portable program would set aside a table somewhere, which said: ; implementation-dependent table of character codes and their functions #\control-A delete-next-character #\control-R retype-line and clearly identify that these were not "standard" (in the sense of pp 20-21) characters. Let me put it in terms of a more definite proposal in terms of chapter and verse: a) eliminate constants char-code-limit, char-font-limit and char-bits-limit, and instead have a constants: char-integer-limit [Constant] The value of char-integer-limit is a non-negative integer that is the upper exclusive bound on values produced by the function char-integer. ... string-char-integer-limit [constant] The value of string-char-integer-limit is the upper exclusive bound on values produced by the funcion char-integer for characters which satisfy string-char-p. [Implementation note: older Common Lisps can implement this by (defconstant char-integer-limit (+ char-code-limit char-font-limit char-bits-limit)) (defconstant string-char-integer-limit char-code-limit)] b) change the wording of char-upcase and char-downcase to omit references to "characters with non-zero bits". [note: I detect an inconsistency in the description of char-upcase on p. 241, which in the second paragraph says that it returns a character object with the same font and bits attributes but with possibly a different code, and in the last paragraph says that they have no effect on characters with non-zero bits attributes] c) eliminate functions char-code, char-bits, char-font, code-char, make-char from the standard. [Compatibility note: users with older common lisp programs may want to define char-code as (mod (char-int char) string-char-integer-limit)) and similarly make the other ones as transforms on char-integers] d) eliminate the constants char-control-bit char-meta-bit char-super-bit char-hyper-bit and the functions char-bit set-char-bit. [Compatibility note: users with older common lisp programs who want to use these features can define these constants as 1 2 4 8 respectively, and define (defun char-bit char name (int-char (logtest (int-char char) (* string-char-integer-limit (ecase name (:control 1) (:meta 2) ...))))))  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 29 Jun 86 11:51:19 EDT Received: from HPLABS.HP.COM by SU-AI.ARPA with TCP; 29 Jun 86 08:46:30 PDT Received: from hplmlg by hplabs.HP.COM ; Sun, 29 Jun 86 08:44:59 pdt Received: by hplmlg ; Sun, 29 Jun 86 08:44:43 pdt From: Martin Griss Message-Id: <8606291544.AA02251@hplmlg> Date: Sunday, June 29, 1986 08:44:39 Subject: Re: Argument lists: a proposal to shoot at To: DCP@QUABBIN.SCRC.Symbolics.COM Cc: GRISS%hplmlg@hplabs.HP.COM, common-lisp@su-ai.ARPA In-Reply-To: Your message of 27-Jun-86 16:10:00 X-Sent-By-Nmail-Version: 04-Nov-84 17:14:46 I am in favor of DCP's suggested use of multiple-values returned to return a number of the useful values. Perhaps the first argument or two could be the most "useful". I also think we may also need another function, or this function with a keyword argument to get the names of the keyword parameters. Martin -------  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 29 Jun 86 00:05:50 EDT Received: from UTAH-20.ARPA by SU-AI.ARPA with TCP; 28 Jun 86 21:00:19 PDT Date: Sat 28 Jun 86 21:58:43-MDT From: SANDRA Subject: Re: portability of pathnames To: Fahlman@C.CS.CMU.EDU cc: common-lisp@SU-AI.ARPA In-Reply-To: Message-ID: <12218575298.7.LOOSEMORE@UTAH-20.ARPA> I'm afraid I don't have a real good proposal to offer on this issue, other than to describe how we have tackled the issue in PCLS, which currently handles VMS and Unix file systems and has hooks for a few others. Basically, we view the pathname as consisting of a "place" (the host, device, and directory), a name, and a type, and don't do too much with versions. There are consistent conventions for the name and type on all machines; ie, you can pass lowercase strings with no delimiters to make-pathname and get something reasonable. (If there are characters in the strings which are invalid for that particular file system, some appropriate kind of translation usually occurs automagically.) The specification of the "place" parts of the pathname, on the other hand, are machine dependent. Although the hooks are there to support it, we never pass "place" components to make-pathname in portable code. Instead, we use merge-pathnames. (We generally only worry about this when we are trying to find a library file, and in that case the namestring for the "place" is stored in a global variable; "places" are usually installation-specific anyway.) There really seem to be only three situations that probably cover about 95% of the cases where you want to muck with pathnames: (1) The user has supplied a complete file name as a string and you want to find that file. (2) You are looking for a file with a given name and type in one of several possible places -- often the default place. (3) You have somehow acquired a complete pathname and you want to find a file in the same place with the same name, but with a different extension. (Like creating a FOO.BIN file in the same place that you found the corresponding FOO.LISP.) I would be very happy to see the standard firmed up just enough so that you can do these three operations in a portable manner. At the very least, the manual should make clear what operations are guaranteed to work on all implementations and which are implementation-specific extensions. -Sandra -------  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 28 Jun 86 18:37:46 EDT Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 28 Jun 86 15:31:15 PDT Received: from utokyo-relay by csnet-relay.csnet id ad29627; 28 Jun 86 18:30 EDT Received: by u-tokyo.junet (4.12/4.9J-1[JUNET-CSNET]) id AA07604; Sat, 28 Jun 86 15:16:56+0900 From: yuasa%kurims.kurims.kyoto-u.junet%utokyo-relay.csnet@CSNET-RELAY.ARPA Received: by nttlab.ntt.junet (4.12/5.0) with TCP; Sat, 28 Jun 86 13:31:09 jst Received: by kurims.kurims.kyoto-u.junet (2.0/6.1Junet) id AA00258; Sat, 28 Jun 86 12:01:01+0900 Date: Sat, 28 Jun 86 12:01:01+0900 Message-Id: <8606280301.AA00258@kurims.kurims.kyoto-u.junet> To: common-lisp%su-ai.arpa%u-tokyo.junet@CSNET-RELAY.ARPA Subject: DRIBBLE Some people detected that DRIBBLE in KCL works quite differently from other, American Common Lisp systems. The differences certainly came from the incomplete description of DRIBBLE (page 443). While other debugging tools depend highly on implementatins, DRIBBLE could be given more detailed definition independent of the implementation. Here are my inquiries which, I think, should be made clear. 1. Is it an error to turn DRIBBLE on, while it is on already? If it is allowed, then what action should the system take? Especially, "which DRIBBLE" should (DRIBBLE) turn off? 2. Does (DRIBBLE ) supercede the specified file if it exists already? Or, does it append? Do you need any additional parameter to specify this? 3. Which stream variables should (DRIBBLE ) rebind? CLtL says only that (DRIBBLE ) rebinds *STANDARD-INPUT* and *STANDARD-OUTPUT*. What about other variables such as *TERMINAL-IO* ? 4. Suppose that (DRIBBLE ) rebinds *STANDARD-INPUT*. Are the followings are legal uses of DRIBBLE? If legal, what actions should the system take? 4a. >(dribble "foo.log") >(let ((*standard-input* ...)) .... (dribble) ....) 4b. >(let ((*standard-input* ...)) ... (dribble "foo.log") ...) >(dribble) Note: Currently, KCL causes an error in the case of 4a. This is because, at the exit from the LET form, *STANDARD-OUTPUT* is rebound to a broadcast stream that includes an already closed stream to foo.log. -- Taiichi  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 27 Jun 86 20:45:02 EDT Received: from SCRC-QUABBIN.ARPA by SU-AI.ARPA with TCP; 27 Jun 86 17:33:54 PDT Received: from FIREBIRD.SCRC.Symbolics.COM by QUABBIN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 14434; Fri 27-Jun-86 20:31:57 EDT Date: Fri, 27 Jun 86 20:31 EDT From: David C. Plummer Subject: Error Signalling To: Scott E. Fahlman , David C. Plummer cc: common-lisp@SU-AI.ARPA In-Reply-To: Supersedes: <860627203125.9.DCP@FIREBIRD.SCRC.Symbolics.COM> Message-ID: <860627203148.0.DCP@FIREBIRD.SCRC.Symbolics.COM> Date: Fri, 27 Jun 1986 20:04 EDT From: "Scott E. Fahlman" I think changing "is an error" in all cases to "signals an error" would violate the /Portability/ motivation on page 1 of the Silver Bible. I think we (or the standards committee) have to carefully at all the "is an error" and decide if it should be "signals an error". Many of us agree number of argument checking should be signalled unless safety is completely turned off, and that even then implementations are encouraged to check. Please, let's not go running off on a tangent. I was not suggesting that EVERY case of "is an error" be changed to "signals an error". I was merely asking whether people thought that cases like the ones I enumerated (arg count checking, arg type checking for certain built-in functions, and array bounds checking) should be tightened up. Sorry. Yes for all three of those, unless safety is turned completely off, and even then implementations are encouraged to be safe if possible. After we've decided how to handle these cases in general we can start discussing which errors are so hard to check that they should be exempt from the signalling requirement. Sounds fair. -- Scott -- Not Scott  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 27 Jun 86 20:44:01 EDT Received: from SCRC-QUABBIN.ARPA by SU-AI.ARPA with TCP; 27 Jun 86 17:32:57 PDT Received: from FIREBIRD.SCRC.Symbolics.COM by QUABBIN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 14433; Fri 27-Jun-86 20:31:35 EDT Date: Fri, 27 Jun 86 20:31 EDT From: David C. Plummer Subject: Error Signalling To: Scott E. Fahlman , David C. Plummer cc: common-lisp@SU-AI.ARPA In-Reply-To: Message-ID: <860627203125.9.DCP@FIREBIRD.SCRC.Symbolics.COM> Date: Fri, 27 Jun 1986 20:04 EDT From: "Scott E. Fahlman" I think changing "is an error" in all cases to "signals an error" would violate the /Portability/ motivation on page 1 of the Silver Bible. I think we (or the standards committee) have to carefully at all the "is an error" and decide if it should be "signals an error". Many of us agree number of argument checking should be signalled unless safety is completely turned off, and that even then implementations are encouraged to check. Please, let's not go running off on a tangent. I was not suggesting that EVERY case of "is an error" be changed to "signals an error". I was merely asking whether people thought that cases like the ones I enumerated (arg count checking, arg type checking for certain built-in functions, and array bounds checking) should be tightened up. Sorry. Yes for all three of those, unless safety is turned completely off, and even then implementations are encouraged to be safe if possible. After we've decided how to handle these cases in general we can start discussing which errors are so hard to check that they should be exempt from the signalling requirement. -- Scott  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 27 Jun 86 20:11:03 EDT Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 27 Jun 86 17:05:13 PDT Received: ID ; Fri 27 Jun 86 20:04:23-EDT Date: Fri, 27 Jun 1986 20:04 EDT Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: "David C. Plummer" Cc: common-lisp@SU-AI.ARPA Subject: Error Signalling In-reply-to: Msg of 27 Jun 1986 15:55-EDT from David C. Plummer I think changing "is an error" in all cases to "signals an error" would violate the /Portability/ motivation on page 1 of the Silver Bible. I think we (or the standards committee) have to carefully at all the "is an error" and decide if it should be "signals an error". Many of us agree number of argument checking should be signalled unless safety is completely turned off, and that even then implementations are encouraged to check. Please, let's not go running off on a tangent. I was not suggesting that EVERY case of "is an error" be changed to "signals an error". I was merely asking whether people thought that cases like the ones I enumerated (arg count checking, arg type checking for certain built-in functions, and array bounds checking) should be tightened up. After we've decided how to handle these cases in general we can start discussing which errors are so hard to check that they should be exempt from the signalling requirement. -- Scott  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 27 Jun 86 19:50:13 EDT Received: from [192.10.41.41] by SU-AI.ARPA with TCP; 27 Jun 86 16:36:21 PDT Received: from FIREBIRD.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 31499; Fri 27-Jun-86 15:55:57 EDT Date: Fri, 27 Jun 86 15:55 EDT From: David C. Plummer Subject: Error Signalling To: mike%gold-hill-acorn@mit-live-oak.arpa, Fahlman@C.CS.CMU.EDU cc: common-lisp@SU-AI.ARPA In-Reply-To: The message of 27 Jun 86 11:20 EDT from mike@ALLEGHENY.SCRC.Symbolics.COM Message-ID: <860627155542.1.DCP@FIREBIRD.SCRC.Symbolics.COM> Date: Fri, 27 Jun 86 10:20 EST From: mike@a Date: Thu, 26 Jun 1986 23:14 EDT From: "Scott E. Fahlman" ..... The question we should address is what we should say about such errors in the standard for Common Lisp. There are three options: 1. The status quo: each of these things "is an error", but it is entirely up to the implementor whether and under what circumstances to detect and signal these errors. I'd say this is a non-spec. It should be possible for an implementation to detect ALL errors. To say something is an error, but to not require the implementation to detect it is to make it impossible for programmers to debug code (unless you like hex core dumps...) 2. The rigorous solution: For errors of the types described above, it is REQUIRED that implementations signal an error in interpreted code. It is also required that these errors be signalled in compiled code unless (optimize (safety 0)) is in effect at compile time. As far as I'm concerned, this is the only reasonable position to take. In general, I think the phrase "is an error" in CLtL should be interpreted as "signals an error unless action is taken to ignore the condition through declarations." I don't see any difficulty in implementation here for Gold Hill. It "is an error" to do (let ((array (make-array 5 :element-type '(unsigned-byte 13)))) (setf (aref array 4) (ash 1 15))) but it would be damn inefficient to REQUIRE all implementations to support every single possibility. In this case, there are a gazillion array types, but only a limitted number that can be implemented. In the symbolics implementation, the above make-array returns an array that is capable of storing 16 bit "bytes" because we "happen" to have an array type that stores such things with less overhead than a general can-hold-anything array. I think changing "is an error" in all cases to "signals an error" would violate the /Portability/ motivation on page 1 of the Silver Bible. I think we (or the standards committee) have to carefully at all the "is an error" and decide if it should be "signals an error". Many of us agree number of argument checking should be signalled unless safety is completely turned off, and that even then implementations are encouraged to check. 3. Sitting on the fence: The conditions stated in option 2 are not required in the spec, but they are "recommended". We will soon need to make a formal decision about what goes into the spec. I'd like to know what people think of these three options -- please try to be brief. Also, if you represent an implementation group, please indicate whether the requirement in option 1 would make real I assume you mean option 2. trouble for you, regardless of whether you favor it. The question is not whether you could install this by next Tuesday, but whether it would be a problem to meet this tightened requirement in a release nine months or a year from now. -- Scott ...mike beckerle Gold Hill Computers  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 27 Jun 86 19:49:40 EDT Received: from [192.10.41.41] by SU-AI.ARPA with TCP; 27 Jun 86 16:38:45 PDT Received: from FIREBIRD.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 31541; Fri 27-Jun-86 16:10:38 EDT Date: Fri, 27 Jun 86 16:10 EDT From: David C. Plummer Subject: Argument lists: a proposal to shoot at To: Guy Steele , common-lisp@SU-AI.ARPA In-Reply-To: <860626123445.9.GLS@BOETHIUS.THINK.COM> Message-ID: <860627161029.2.DCP@FIREBIRD.SCRC.Symbolics.COM> Date: Thu, 26 Jun 86 12:34 EDT From: Guy Steele In the following function descriptions, assume that the argument function has Q required parameters and P &optional parameters, and that R, K, or A is true iff the function has respectively a &rest, &key, or &allow-other-keys lambda-keyword. ... Point of design philosophy: &aux "parameters" aren't anybody's business at this level of abstraction. I don't deny that for the sake of debuggers this information, and such other information as the names of parameters, may be desired. Other ideas for consideration: I think the max number of parameters before the &rest is useful. Why not one function that returns just about everything as multiple values? Something like (values min-required-args max-spead-args takes-rest-arg-p takes-keywords-p allows-other-keywords-p) Consider a system that allows the programmer to override the argument list with a declaration, such as (defun foo (a b &rest c) (declare (arglist symbol indicator &key package value &allow-other-keys)) ...) Do these functions return what the function really wants or what the user says it wants? Consider the case (defun make-raster-array (width height &rest make-array-keywords &key &allow-other-keys) (apply #'make-array (list height width make-array-keywords))) Here, there are keywords accepted, but it isn't really clear which ones, since this is an abstraction on top of make-array. [I don't have a good answer to this one.]  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 27 Jun 86 19:41:26 EDT Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 27 Jun 86 16:21:55 PDT Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 42668; Fri 27-Jun-86 19:19:45 EDT Date: Fri, 27 Jun 86 19:19 EDT From: Kent M Pitman Subject: FUNCTION-MAX-ARGS,etc To: Moon@SCRC-STONY-BROOK.ARPA cc: COMMON-LISP@SU-AI In-Reply-To: <860627181505.4.MOON@EUPHRATES.SCRC.Symbolics.COM> Message-ID: <860627191955.5.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> MACSYMA would probably want to use FUNCTION-MIN-ARGS, etc. inside its equivalent of EVAL and/or APPLY. A function which returns all possible information from one function might be excess overhead in that situation. I really like the idea of separate functions. We moved away from the Maclisp ARRAYDIMS which returned type+dim information and provided separate functions to get the type, dimensions list, individual dimensions, etc for arrays for what I believe are analogous reasons. By the way, anything with &KEY automatically allows arbitrarily many arguments. Does that simplify things? eg, consider: (DEFUN FOO (&KEY A) A) (FOO :A 1 :A 2 :A 3 :A 4 ...) which is clearly defined on p62 to be legal and to return 1. Keyword mismatches are, therefore, not in the domain of argument -number- checking, but rather in the domain of argument -type- checking. I'm not saying that's what I'd like, but it's hard to see any other interpretation.  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 27 Jun 86 19:05:04 EDT Received: from SRI-KL.ARPA by SU-AI.ARPA with TCP; 27 Jun 86 15:32:40 PDT Date: Fri 27 Jun 86 10:04:27-PDT From: David Singer Subject: Re: Argument Lists To: common-lisp%SU-AI@SRI-KL A simple proposal is to provide ARGUMENT-LIST, and also FORM-IS-VALID-CALL i.e. takes the result of ARGUMENT-LIST and a call form and tells you whether the call form is valid for the given argument list; a second result might perhaps be a suitable error message if result1 is false. This would enable user-interface construction tools to check calls without all a lot of fussing with max, min, keywords, rest etc. Of course if you really wanted to know what was happening, you could always have a function which returned an association list showing how the bindings would go in such a call ... -------  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 27 Jun 86 19:03:22 EDT Received: from SCRC-QUABBIN.ARPA by SU-AI.ARPA with TCP; 27 Jun 86 15:21:54 PDT Received: from EUPHRATES.SCRC.Symbolics.COM by QUABBIN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 14356; Fri 27-Jun-86 18:20:15 EDT Date: Fri, 27 Jun 86 18:19 EDT From: David A. Moon Subject: Error Signalling To: common-lisp@SU-AI.ARPA In-Reply-To: Message-ID: <860627181913.5.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Thu, 26 Jun 1986 23:14 EDT From: "Scott E. Fahlman" The question we should address is what we should say about such errors in the standard for Common Lisp. There are three options: 1. The status quo: each of these things "is an error", but it is entirely up to the implementor whether and under what circumstances to detect and signal these errors. 2. The rigorous solution: For errors of the types described above, it is REQUIRED that implementations signal an error in interpreted code. It is also required that these errors be signalled in compiled code unless (optimize (safety 0)) is in effect at compile time. 3. Sitting on the fence: The conditions stated in option 2 are not required in the spec, but they are "recommended". #2 has always been the policy in Symbolics' implementation. That's an implementation design decision. I don't feel qualified to judge whether #2 should be the language specification, or whether it's better for the language to permit laxer implementations.  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 27 Jun 86 19:01:22 EDT Received: from SCRC-RIVERSIDE.ARPA by SU-AI.ARPA with TCP; 27 Jun 86 15:17:37 PDT Received: from EUPHRATES.SCRC.Symbolics.COM by RIVERSIDE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 30414; Fri 27-Jun-86 18:16:20 EDT Date: Fri, 27 Jun 86 18:15 EDT From: David A. Moon Subject: Re: Argument lists: a proposal to shoot at To: common-lisp@SU-AI.ARPA In-Reply-To: <860627144507.7.GLS@BOETHIUS.THINK.COM> Message-ID: <860627181505.4.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Fri, 27 Jun 86 14:45 EDT From: Guy Steele Date: 26 Jun 1986 19:17-EDT From: NGALL@G.BBN.COM How about keeping the number of functions down and eliminating the 'encoding' in MAX-ARGS, and using correct terminology with the following one-function alternative to FUNCTION-MIN-ARGS, -MAX-ARGS, -HAS-KEYWORD-PARAMETERS, and -KEYWORD-PARAMETERS. I think FUNCTION-KEYWORD-PARAMETER-P addresses an idiom common enough to warrant its own function. FUNCTION-PARAMETERS function [Function] Returns Q, P, R, K, a list of keywords explicitly accepted by the function (order undefined), and A. Note that if K is false, the list is necessarily empty. I like one function to return all the information better than a bunch of separate functions. As for whether it's better to return min-and-max or required-and-optional, in all these years I've never made up my mind on that point. I do think it's a good idea for the presence of &rest or &key not to throw away the information about how many positional parameters there are, even if some of the proposed uses for that information are bad ideas. In the min-and-max model, max could be the maximum number of positional parameters, thus you have to look at (OR R K) to know whether this is actually the maximum you are permitted to pass. I have to admit (blush) that another design criterion I employed implicitly was that it should be possible to acquire most of the information without either consing on the fly or requiring an explicit pre-stored list of the keywords. I don't understand how the information would be accessible at all if there was not a pre-stored list. Perhaps you have some clever implementation in mind? If this is really important, we could have both FUNCTION-PARAMETERS and FUNCTION-KEYWORD-PARAMETER-P, with some way to tell FUNCTION-PARAMETERS not to bother creating the list. But I like it better with just one function. Anyway I know how to not be bothered by consing on the fly. In your proposal for FUNCTION-PARAMETERS, I observe that returning K is redundant: K is true iff [(the keyword list is not empty) or A]. That's not to say that returning K separately isn't a good idea. (defun foo (&key) ...) has some semantic meaning, namely that if this function is ever extended it's going to take keyword parameters. If you don't think this is a realistic example, see CLtL page 427. I don't think clever elimination of the K return value is advisable.  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 27 Jun 86 18:58:26 EDT Received: from BBNG.ARPA by SU-AI.ARPA with TCP; 27 Jun 86 13:34:07 PDT Date: 27 Jun 1986 16:32-EDT Sender: NGALL@G.BBN.COM Subject: Re: Argument lists: a proposal to shoot at From: NGALL@G.BBN.COM To: gls@ZARATHUSTRA.THINK.COM Cc: common-lisp@SU-AI.ARPA Message-ID: <[G.BBN.COM]27-Jun-86 16:32:34.NGALL> In-Reply-To: <860627144507.7.GLS@BOETHIUS.THINK.COM> Date: Fri, 27 Jun 86 14:45 EDT From: Guy Steele To: NGALL@G.BBN.COM, gls@ZARATHUSTRA Subject: Re: Argument lists: a proposal to shoot at In-Reply-To: <[G.BBN.COM]26-Jun-86 19:17:24.NGALL> Message-ID: <860627144507.7.GLS@BOETHIUS.THINK.COM> Date: 26 Jun 1986 19:17-EDT From: NGALL@G.BBN.COM How about keeping the number of functions down and eliminating the 'encoding' in MAX-ARGS, and using correct terminology with the following one-function alternative to FUNCTION-MIN-ARGS, -MAX-ARGS, -HAS-KEYWORD-PARAMETERS, and -KEYWORD-PARAMETERS. I think FUNCTION-KEYWORD-PARAMETER-P addresses an idiom common enough to warrant its own function. FUNCTION-PARAMETERS function [Function] Returns Q, P, R, K, a list of keywords explicitly accepted by the function (order undefined), and A. Note that if K is false, the list is necessarily empty. I have to admit (blush) that another design criterion I employed implicitly was that it should be possible to acquire most of the information without either consing on the fly or requiring an explicit pre-stored list of the keywords. Yes. I worried about returning the list of keywords, when all the user wanted to know was min and max args, for example. I guess I figured that pre-stored lists weren't a very high price to pay. I'm ambivalent about returning the list vs. returning the the number of keyword args. and bringing back FUNCTION-KEYWORD-PARAMETERS. In your proposal for FUNCTION-PARAMETERS, I observe that returning K is redundant: K is true iff [(the keyword list is not empty) or A]. That's not to say that returning K separately isn't a good idea. Not true. (lambda (&key)...) is legal. --Guy -- Nick --Guy -- Nick  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 27 Jun 86 14:58:07 EDT Received: from GODOT.THINK.COM by SU-AI.ARPA with TCP; 27 Jun 86 11:44:05 PDT Received: from boethius by Godot.Think.COM via CHAOS; Fri, 27 Jun 86 14:44:00 edt Date: Fri, 27 Jun 86 14:45 EDT From: Guy Steele Subject: Re: Argument lists: a proposal to shoot at To: NGALL@G.BBN.COM, gls@ZARATHUSTRA Cc: common-lisp@SU-AI.ARPA, gls@AQUINAS In-Reply-To: <[G.BBN.COM]26-Jun-86 19:17:24.NGALL> Message-Id: <860627144507.7.GLS@BOETHIUS.THINK.COM> Date: 26 Jun 1986 19:17-EDT From: NGALL@G.BBN.COM How about keeping the number of functions down and eliminating the 'encoding' in MAX-ARGS, and using correct terminology with the following one-function alternative to FUNCTION-MIN-ARGS, -MAX-ARGS, -HAS-KEYWORD-PARAMETERS, and -KEYWORD-PARAMETERS. I think FUNCTION-KEYWORD-PARAMETER-P addresses an idiom common enough to warrant its own function. FUNCTION-PARAMETERS function [Function] Returns Q, P, R, K, a list of keywords explicitly accepted by the function (order undefined), and A. Note that if K is false, the list is necessarily empty. I have to admit (blush) that another design criterion I employed implicitly was that it should be possible to acquire most of the information without either consing on the fly or requiring an explicit pre-stored list of the keywords. In your proposal for FUNCTION-PARAMETERS, I observe that returning K is redundant: K is true iff [(the keyword list is not empty) or A]. That's not to say that returning K separately isn't a good idea. --Guy -- Nick --Guy  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 27 Jun 86 11:01:58 EDT Received: from HOPKINS-EECS-BRAVO.ARPA by SU-AI.ARPA with TCP; 27 Jun 86 07:53:15 PDT Date: Fri, 27 Jun 86 10:43:45 EDT From: Marty Hall To: common-lisp@su-ai.ARPA Subject: Getting on the mailing list. I have heard that I could be added to the Common LISP mailing list by requesting here. If that is OK, please add me. I am losing my uucp access, so lists like Net.Lang.LISP are no longer available to me. Are there others like that around? Thanks! Marty Hall hall@hopkins-eecs-bravo.arpa  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 27 Jun 86 10:48:19 EDT Received: from MIT-LIVE-OAK.ARPA by SU-AI.ARPA with TCP; 27 Jun 86 07:38:02 PDT Received: from GOLD-HILL-ACORN.DialNet.Symbolics.COM (DIAL|DIAL|4925473) by MIT-LIVE-OAK.ARPA via DIAL with SMTP id 3304; 27 Jun 86 10:37:26-EDT Received: from BOSTON.Gold-Hill.DialNet.Symbolics.COM by ACORN.Gold-Hill.DialNet.Symbolics.COM via CHAOS with CHAOS-MAIL id 26406; Fri 27-Jun-86 10:38:13-EDT Date: Fri, 27 Jun 86 10:36 EST From: mike@a To: NGALL@G.BBN.COM Reply-to: mike%gold-hill-acorn@mit-live-oak.arpa Subject: Re: Argument lists: a proposal to shoot at Cc: gls@ZARATHUSTRA.THINK.COM, common-lisp@SU-AI.ARPA Date: 26 Jun 1986 19:17-EDT From: NGALL@G.BBN.COM ....... Your encoding scheme does not let me see the number of 'probably-stack-based' parameters (i.e., P+Q) given a function that has a &rest param and no &key params. This makes it impossible to provide an encapsulation that would use &rest only where necessary (it would force the use of a &rest parameter for all args beyond the required parameters). Sorry, but inferring anything about 'probably stack based' at run time just turns my stomach. Why not ask how many are 'register based'? Why not just call (disassemble ...)???? There are three kinds of things going on here. One is to somehow figure out how to call a function so you can avoid a run time error, etc. This is best served I think by enhancing (type-of ...) for funcallable objects. The second is for programming environments, which is best served by keeping argument lists around on a property list, or something, since the idea is to inform a programmer how the call works, and to give him some idea of the semantics of the arguments by allowing access to the actual argument names. The third, and most troublesome is so that programs can reason about how arguments are passed, i.e., can do things like 'probably register based', and so on. Why is this needed? I think we should provide (arglist ...) which returns the literal arglist of functions, to address user interface considerations. We shouldn't break the function abstraction any more than that. ...mike beckerle Gold Hill Computers  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 27 Jun 86 10:35:23 EDT Received: from HPLABS.HP.COM by SU-AI.ARPA with TCP; 27 Jun 86 07:22:37 PDT Received: from hplabsc by hplabs.HP.COM ; Fri, 27 Jun 86 07:21:19 pdt Received: by hplabsc ; Fri, 27 Jun 86 07:22:08 pdt Date: Fri, 27 Jun 86 07:22:08 pdt From: Jim Kempf Message-Id: <8606271422.AA07719@hplabsc> To: Fahlman@C.CS.CMU.EDU, lee%hplles@HPLABS.HP.COM Subject: Re: Case sensitive reading. Cc: common-lisp@SU-AI.ARPA The CL function READ-LINE (CLtL pg. 378) can be used to read in general text without case conversion. Tokenization can then be done by parsing this string. Jim Kempf kempf@hplabs  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 27 Jun 86 10:34:29 EDT Received: from MIT-LIVE-OAK.ARPA by SU-AI.ARPA with TCP; 27 Jun 86 07:21:42 PDT Received: from GOLD-HILL-ACORN.DialNet.Symbolics.COM by MIT-LIVE-OAK.ARPA via DIAL with SMTP id 3301; 27 Jun 86 10:21:38-EDT Received: from BOSTON.Gold-Hill.DialNet.Symbolics.COM by ACORN.Gold-Hill.DialNet.Symbolics.COM via CHAOS with CHAOS-MAIL id 26404; Fri 27-Jun-86 10:22:22-EDT Date: Fri, 27 Jun 86 10:20 EST From: mike@a To: Fahlman@C.CS.CMU.EDU Reply-to: mike%gold-hill-acorn@mit-live-oak.arpa Subject: Error Signalling Cc: common-lisp@SU-AI.ARPA Date: Thu, 26 Jun 1986 23:14 EDT From: "Scott E. Fahlman" ..... The question we should address is what we should say about such errors in the standard for Common Lisp. There are three options: 1. The status quo: each of these things "is an error", but it is entirely up to the implementor whether and under what circumstances to detect and signal these errors. I'd say this is a non-spec. It should be possible for an implementation to detect ALL errors. To say something is an error, but to not require the implementation to detect it is to make it impossible for programmers to debug code (unless you like hex core dumps...) 2. The rigorous solution: For errors of the types described above, it is REQUIRED that implementations signal an error in interpreted code. It is also required that these errors be signalled in compiled code unless (optimize (safety 0)) is in effect at compile time. As far as I'm concerned, this is the only reasonable position to take. In general, I think the phrase "is an error" in CLtL should be interpreted as "signals an error unless action is taken to ignore the condition through declarations." I don't see any difficulty in implementation here for Gold Hill. 3. Sitting on the fence: The conditions stated in option 2 are not required in the spec, but they are "recommended". We will soon need to make a formal decision about what goes into the spec. I'd like to know what people think of these three options -- please try to be brief. Also, if you represent an implementation group, please indicate whether the requirement in option 1 would make real I assume you mean option 2. trouble for you, regardless of whether you favor it. The question is not whether you could install this by next Tuesday, but whether it would be a problem to meet this tightened requirement in a release nine months or a year from now. -- Scott ...mike beckerle Gold Hill Computers  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 27 Jun 86 03:27:05 EDT Received: from KIM.Berkeley.EDU by SU-AI.ARPA with TCP; 27 Jun 86 00:19:36 PDT Received: by kim.Berkeley.EDU (5.51/1.14) id AA18214; Fri, 27 Jun 86 00:18:29 PDT From: franz!fizzy!jkf@kim.berkeley.edu Received: from fizzy by franz (5.5/3.14) id AA29888; Thu, 26 Jun 86 22:36:21 PDT Received: by fizzy (4.12/3.14) id AA02675; Thu, 26 Jun 86 22:36:50 pdt Return-Path: Message-Id: <8606270536.AA02675@fizzy> To: Lee Schumacher Cc: common-lisp@su-ai.arpa Subject: Re: Case sensitive reading. In-Reply-To: Your message of Thu, 26 Jun 86 17:47:03 GMT. <8606270047.AA06350@hplles> Date: Thu, 26 Jun 86 22:36:48 PDT re: I no longer follow this mailing list, but i'm told that someone recently suggested that there be some mechanism for turning on case-sensitivity in the reader. Our common lisp has a mechanism for turning on case sensitivity. It is an extension. Write to me if you want more details. - john foderaro franz inc.  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 27 Jun 86 00:01:58 EDT Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 26 Jun 86 20:51:50 PDT Received: ID ; Thu 26 Jun 86 23:51:03-EDT Date: Thu, 26 Jun 1986 23:51 EDT Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: NGALL@BBNG.ARPA Cc: common-lisp@SU-AI.ARPA Subject: Argument lists: a proposal to shoot at In-reply-to: Msg of 26 Jun 1986 19:17-EDT from NGALL at G.BBN.COM Your encoding scheme does not let me see the number of 'probably-stack-based' parameters (i.e., P+Q) given a function that has a &rest param and no &key params. This makes it impossible to provide an encapsulation that would use &rest only where necessary (it would force the use of a &rest parameter for all args beyond the required parameters). Sorry, maybe I'm being dense, but I don't understand this. What is it that an encapsulation can do better if it can see P+Q ? Why do you want to rip the lid off this particular black box? -- Scott  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 26 Jun 86 23:29:51 EDT Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 26 Jun 86 20:14:41 PDT Received: ID ; Thu 26 Jun 86 23:14:48-EDT Date: Thu, 26 Jun 1986 23:14 EDT Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: common-lisp@SU-AI.ARPA Subject: Error Signalling In-reply-to: Msg of 26 Jun 1986 00:56-EDT from Glenn S. Burke We don't need anything like *RSET. Common Lisp provides the user with an appropriate way of specifying whether speed or error checking is preferred: the OPTIMIZE declaration. Most good implementations detect and signal argument count, argument type, array bounds, and similar errors, except when the user has indicated that speed is valued more than safety (some use SPEED > SAFETY, others use SAFETY = 0). Actually, that statement is somewhat backwards: signalling these errors appropriately is one of my criteria for a "good implementation". The question we should address is what we should say about such errors in the standard for Common Lisp. There are three options: 1. The status quo: each of these things "is an error", but it is entirely up to the implementor whether and under what circumstances to detect and signal these errors. 2. The rigorous solution: For errors of the types described above, it is REQUIRED that implementations signal an error in interpreted code. It is also required that these errors be signalled in compiled code unless (optimize (safety 0)) is in effect at compile time. 3. Sitting on the fence: The conditions stated in option 2 are not required in the spec, but they are "recommended". I think that 2, the rigorous solution, is clearly the best approach for standardization and for portability of code. However, we should adopt this only if there is a fairly strong consensus in its favor, and only if it doesn't make too much toruble for existing implementations. If those conditions are not met, we should go with the status quo. I'm undecided about option 3. Should a spec get into the recommendation business? In many cases where we can't actually require things, recommendations may help to keep divergence to a minimum. We will soon need to make a formal decision about what goes into the spec. I'd like to know what people think of these three options -- please try to be brief. Also, if you represent an implementation group, please indicate whether the requirement in option 1 would make real trouble for you, regardless of whether you favor it. The question is not whether you could install this by next Tuesday, but whether it would be a problem to meet this tightened requirement in a release nine months or a year from now. -- Scott  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 26 Jun 86 21:23:59 EDT Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 26 Jun 86 18:12:59 PDT Received: ID ; Thu 26 Jun 86 21:09:55-EDT Date: Thu, 26 Jun 1986 21:09 EDT Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: Lee Schumacher Cc: common-lisp@SU-AI.ARPA Subject: Case sensitive reading. In-reply-to: Msg of 26 Jun 1986 17:47-EDT from Lee Schumacher The Lisp reader was designed primarily for reading Lisp code. There are all sorts of things in other computer languages that would tend to choke it. Case sensitivity is one of them. It is unreasonable to expect that there would be a few built-in switches you could throw to turn the Lisp reader into a C parser or even a C tokenizer. On the other hand, there are lots of built-in facilities that would make it a relatively strightforward matter to write such a thing from scratch. -- Scott  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 26 Jun 86 21:00:35 EDT Received: from HPLABS.HP.COM by SU-AI.ARPA with TCP; 26 Jun 86 17:48:20 PDT Received: from hplles by hplabs.HP.COM ; Thu, 26 Jun 86 17:46:34 pdt Received: by hplles ; Thu, 26 Jun 86 17:47:06 pdt From: Lee Schumacher Message-Id: <8606270047.AA06350@hplles> Date: Thursday, June 26, 1986 17:47:03 Subject: Case sensitive reading. To: common-lisp@su-ai X-Sent-By-Nmail-Version: 04-Nov-84 17:14:46 I no longer follow this mailing list, but i'm told that someone recently suggested that there be some mechanism for turning on case-sensitivity in the reader. As evidence for a need for this, I recently wrote a simple package to analyze some C code. I discovered, to my annoyance, that the only way to preserve the case info (which I needed) was to copy the read-token function from the common lisp source, remove the char-upcase calls, and then make a new readtable with each call to read-token replaced with a call to my version ! Not good. Lee Schumacher -------  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 26 Jun 86 19:25:27 EDT Received: from BBNG.ARPA by SU-AI.ARPA with TCP; 26 Jun 86 16:17:52 PDT Date: 26 Jun 1986 19:17-EDT Sender: NGALL@G.BBN.COM Subject: Re: Argument lists: a proposal to shoot at From: NGALL@G.BBN.COM To: gls@ZARATHUSTRA.THINK.COM Cc: common-lisp@SU-AI.ARPA Message-ID: <[G.BBN.COM]26-Jun-86 19:17:24.NGALL> In-Reply-To: <860626123445.9.GLS@BOETHIUS.THINK.COM> Date: Thu, 26 Jun 86 12:34 EDT From: Guy Steele To: common-lisp@SU-AI.ARPA Subject: Argument lists: a proposal to shoot at Message-ID: <860626123445.9.GLS@BOETHIUS.THINK.COM> In the following function descriptions, assume that the argument function has Q required parameters and P &optional parameters, and that R, K, or A is true iff the function has respectively a &rest, &key, or &allow-other-keys lambda-keyword. FUNCTION-MIN-ARGS function [Function] Returns Q, the minimum number of arguments that must be supplied when the function is called. FUNCTION-MAX-ARGS function [Function] Returns (AND (OR (NOT R) K) (+ Q P)), that is, the maximum number of arguments, exclusive of arguments for keyword parameters, that may be supplied when the function is called. A return value of NIL indicates that there is no such maximum, that is, the function has a &rest parameter and no &key parameters. (Note that if a function has keyword parameters, exactly (+ Q P) arguments have to be supplied before the arguments that will be interpreted for keyword parameters.) Your encoding scheme does not let me see the number of 'probably-stack-based' parameters (i.e., P+Q) given a function that has a &rest param and no &key params. This makes it impossible to provide an encapsulation that would use &rest only where necessary (it would force the use of a &rest parameter for all args beyond the required parameters). How about keeping the number of functions down and eliminating the 'encoding' in MAX-ARGS, and using correct terminology with the following one-function alternative to FUNCTION-MIN-ARGS, -MAX-ARGS, -HAS-KEYWORD-PARAMETERS, and -KEYWORD-PARAMETERS. I think FUNCTION-KEYWORD-PARAMETER-P addresses an idiom common enough to warrant its own function. FUNCTION-PARAMETERS function [Function] Returns Q, P, R, K, a list of keywords explicitly accepted by the function (order undefined), and A. Note that if K is false, the list is necessarily empty. FUNCTION-KEYWORD-PARAMETER-P function keyword [Function] Returns two values. If the function directly accepts the keyword as the name of a keyword parameter (that is, the keyword parameter appeared in the parameter list of the function), then the values T T are returned. If the function does not accept the keyword directly, but its parameter list contained &allow-other-keywords, then the values T NIL are returned. Otherwise the values NIL NIL are returned. Note that FUNCTION-KEYWORD-PARAMETER-P may be correctly applied to any function, even one that was not declared with &key (the values NIL NIL are always returned for such a function). ... Point of design philosophy: &aux "parameters" aren't anybody's business at this level of abstraction. I don't deny that for the sake of debuggers this information, and such other information as the names of parameters, may be desired. Agreed. --Guy -- Nick  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 26 Jun 86 12:42:04 EDT Received: from GODOT.THINK.COM by SU-AI.ARPA with TCP; 26 Jun 86 09:33:42 PDT Received: from boethius by Godot.Think.COM via CHAOS; Thu, 26 Jun 86 12:33:44 edt Date: Thu, 26 Jun 86 12:34 EDT From: Guy Steele Subject: Argument lists: a proposal to shoot at To: common-lisp@SU-AI.ARPA Cc: gls@AQUINAS Message-Id: <860626123445.9.GLS@BOETHIUS.THINK.COM> In the following function descriptions, assume that the argument function has Q required parameters and P &optional parameters, and that R, K, or A is true iff the function has respectively a &rest, &key, or &allow-other-keys lambda-keyword. FUNCTION-MIN-ARGS function [Function] Returns Q, the minimum number of arguments that must be supplied when the function is called. FUNCTION-MAX-ARGS function [Function] Returns (AND (OR (NOT R) K) (+ Q P)), that is, the maximum number of arguments, exclusive of arguments for keyword parameters, that may be supplied when the function is called. A return value of NIL indicates that there is no such maximum, that is, the function has a &rest parameter and no &key parameters. (Note that if a function has keyword parameters, exactly (+ Q P) arguments have to be supplied before the arguments that will be interpreted for keyword parameters.) FUNCTION-HAS-KEYWORD-PARAMETERS function [Function] Returns two values, K and A. FUNCTION-KEYWORD-PARAMETER-P function keyword [Function] Returns two values. If the function directly accepts the keyword as the name of a keyword parameter (that is, the keyword parameter appeared in the parameter list of the function), then the values T T are returned. If the function does not accept the keyword directly, but its parameter list contained &allow-other-keywords, then the values T NIL are returned. Otherwise the values NIL NIL are returned. Note that FUNCTION-KEYWORD-PARAMETER-P may be correctly applied to any function, even one that was not declared with &key (the values NIL NIL are always returned for such a function). FUNCTION-KEYWORD-PARAMETERS function [Function] Returns a list of all keywords that the argument function accepts directly. Note that FUNCTION-KEYWORD-PARAMETERS may be correctly applied to any function, even one that was not declared with &key (an empty list is always returned for such a function). Point of design philosophy: &aux "parameters" aren't anybody's business at this level of abstraction. I don't deny that for the sake of debuggers this information, and such other information as the names of parameters, may be desired. --Guy  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 26 Jun 86 10:43:33 EDT Received: from GODOT.THINK.COM by SU-AI.ARPA with TCP; 26 Jun 86 07:32:17 PDT Received: from boethius by Godot.Think.COM via CHAOS; Thu, 26 Jun 86 10:32:19 edt Date: Thu, 26 Jun 86 10:33 EDT From: Guy Steele Subject: Lisp & FP conference siting To: SCHMIDT@SUMEX-AIM.ARPA Cc: Common-Lisp@SU-AI.ARPA In-Reply-To: <12217732662.51.SCHMIDT@SUMEX-AIM.ARPA> Message-Id: <860626103321.1.GLS@BOETHIUS.THINK.COM> Date: Wed 25 Jun 86 15:49:59-PDT From: Christopher Schmidt Who made the decision to locate the ACM Lisp & FP conference away from AAAI? I didn't make the decision, nor do I have any official position at this year's conference; but I was program chairman for the 1984 conference, and local arrangements chairman for the 1982 conference, so I can speak from experience. I doubt I'm the only would-be attendee who rates only one conference per year and benefited from co-location. I don't imagine there were a lot of people that had problems with the overlap with the AAAI tutorials. Co-location caused a minor headache in 1982, namely that AAAI, being the larger conference and planned further ahead, tended to use up resources in the host city. It was difficult to find lecture halls and hotel space. It was also necesssary to pick a banquet activity different from the activities planned by AAAI. Co-location caused a major headache in 1984. Overlap with tutorials was not a problem, but despite our best efforts to coordinate, paper sessions of the two conferences overlapped, because AAAI became larger that year (3 full days instead of 2 1/2). This resulted in decreased attendance. I happen to be a sub-area chairman for AAAI this year, and so know something about how it is organized as well. This year AAAI is running five full days of paper sessions, for the most part with four or five parallel tracks! Even if in the same city, the only way to avoid conflict would have been to schedule the Lisp conference for the preceding or following week. Furthermore, the facilities in Philadelphia are not ideal, being spread out; AAAI by itself is going to have to use shuttle buses. I am in sympathy with your complaint; it's going to be hard for me, too, to attend both of them. However, given that they have to be in separate weeks, it's not that bad to zoom between Boston and Philadelphia over the weekend. (Admittedly, that's easy for me to say, here in Boston.) I joined the ACM in large part because I hoped I would find out about this sort of thing in advance or (god forbid) vote on this sort of issue. I attended both the '82 and '84 conferences and I STILL haven't received any kind of announcement of this year's conference. The exchanges in the Common-Lisp DL were the first I heard of it. The call for papers appeared in the December 1985 SIGPLAN Notices; this call indicated the conference site (MIT). The conference has been listed in the Calendar of Events in the Communications of the ACM since last November. Note that AAAI is not an ACM function. There was also a mailing, which you should have received if you belong to one of the relevant SIGs. Are the location and timing for '88 decided yet? If the Lisp & FP conference can't be held in conjunction with AAAI, it would better be displaced by 6 months than 1 week in my opinion. Back-to-back conferences require too much time away from work in one block. --Christopher I don't have the information to respond to this. I'm sure the conference organizers are interested in feedback such as this. Some questions of interest are: if both conferences are to be held in August after all, should they be back-to-back or separated by a week or two? Is it better to hold them on the same side of, say, Nebraska or on different sides? P.S. I apologize in advance for sending this to the Common-Lisp list, but I couldn't think of a more appropriate forum. ------- [Dick, I hate to do this to you, but...] I would say it is reasonable to raise the issue on this mailing list, but please let's not have a hundred flames follow on the same subject. It would be better to send comments directly to this year's general chairman for the conference, who is: Richard P. Gabriel Lucid, Inc. 707 Laurel St. Menlo Park, CA 94025 --Guy  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 26 Jun 86 01:05:14 EDT Received: from AI.AI.MIT.EDU by SU-AI.ARPA with TCP; 25 Jun 86 21:56:03 PDT Date: Thu, 26 Jun 86 00:56:51 EDT From: "Glenn S. Burke" Subject: arglists, error checking To: common-lisp@SU-AI.ARPA Message-ID: <[AI.AI.MIT.EDU].61762.860626.GSB> In NIL we have arglist information as part of "debugging info" now. This is separate from what is used for actually checking the arguments to a (compiled) function, which is inline coded in the function entry (sometimes with an out-of-line call, but the call is at the start of the compiled function and occurs unconditionally). Using the optimize declaration appropriately can make this check go away. &KEY is handled out-of-line always, but the partitioning of arguments into required/optional/rest is where the number-of-arguments check occurs, and that precedes the &key parsing. Anyway, this means that any kind of *RSET check would also have to be done in some cumbersome fashion since the decision to check or not is made at compile time.  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 25 Jun 86 23:02:44 EDT Received: from AI.AI.MIT.EDU by SU-AI.ARPA with TCP; 25 Jun 86 19:47:04 PDT Date: Wed, 25 Jun 86 22:47:28 EDT From: Jonathan A Rees Subject: Argument lists To: DCP@SCRC-QUABBIN.ARPA cc: common-lisp@SU-AI.ARPA, Pavel.pa@XEROX.COM, Fahlman@C.CS.CMU.EDU In-reply-to: Msg of Tue 24 Jun 86 16:19 EDT from David C. Plummer Message-ID: <[AI.AI.MIT.EDU].61696.860625.JAR> Date: Tue, 24 Jun 86 16:19 EDT From: David C. Plummer If CL does not come to require number of argument checking, I guess its time to require *RSET to fill the gap. Seriously. Programmers should be allowed to say "I want number of arguments checking, damn it" if the system doesn't automatically provide that. [After all, if you don't want number of argument checking, you can just code your lambda list beginning with &optional and ending with &rest ignore.] Sorry, I really don't understand your point. My point was NOT to take a stand on whether or not checking was desirable; all I wanted to say was that wrong-number-of-arguments is in the same class of error situations as CAR of a symbol or out-of-nounds AREF. So if you think CL must have *RSET-like switches controlling what happens when a wrong number of arguments is passed [I don't think it should], it follows that CL must also have *RSET-like things controlling what happens when CAR of a symbol is taken. If you believe that wrong number of arguments must signal an error [I don't think that should be dictated either], then for consistency so must CAR of a symbol. Jonathan  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 25 Jun 86 19:03:14 EDT Received: from SUMEX-AIM.ARPA by SU-AI.ARPA with TCP; 25 Jun 86 15:49:08 PDT Date: Wed 25 Jun 86 15:49:59-PDT From: Christopher Schmidt Subject: Lisp & FP conference siting To: Common-Lisp@SU-AI.ARPA Message-ID: <12217732662.51.SCHMIDT@SUMEX-AIM.ARPA> Who made the decision to locate the ACM Lisp & FP conference away from AAAI? I doubt I'm the only would-be attendee who rates only one conference per year and benefited from co-location. I don't imagine there were a lot of people that had problems with the overlap with the AAAI tutorials. I joined the ACM in large part because I hoped I would find out about this sort of thing in advance or (god forbid) vote on this sort of issue. I attended both the '82 and '84 conferences and I STILL haven't received any kind of announcement of this year's conference. The exchanges in the Common-Lisp DL were the first I heard of it. Are the location and timing for '88 decided yet? If the Lisp & FP conference can't be held in conjunction with AAAI, it would better be displaced by 6 months than 1 week in my opinion. Back-to-back conferences require too much time away from work in one block. --Christopher P.S. I apologize in advance for sending this to the Common-Lisp list, but I couldn't think of a more appropriate forum. -------  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 24 Jun 86 23:47:39 EDT Received: from BBNG.ARPA by SU-AI.ARPA with TCP; 24 Jun 86 20:36:06 PDT Date: 24 Jun 1986 23:35-EDT Sender: NGALL@G.BBN.COM Subject: Re: Common Lisp 2000 From: NGALL@G.BBN.COM To: jeff%aiva.edinburgh.ac.uk@CS.UCL.AC.UK Cc: Fahlman@C.CS.CMU.EDU, common-lisp@SU-AI.ARPA Cc: eulisp%inria.uucp@CS.UCL.AC.UK Message-ID: <[G.BBN.COM]24-Jun-86 23:35:31.NGALL> In-Reply-To: <19836.8606231339@aiva.ed.ac.uk> Date: Mon, 23 Jun 86 14:39:41 -0100 From: Jeff Dalton To: Fahlman@c.cs.cmu.edu, snyder <@hplabs.hp.com:snyder@hplsny> Subject: Common Lisp 2000 Message-ID: <19836.8606231339@aiva.ed.ac.uk> How do people feel about making changes like immutable/mutable whatevers part of the ANSI/ISO standard instead of waiting for Common Lisp 2000? I don't mean this particular change, which after all we might decide we don't want at all, but rather changes of this magnitude. The EuLisp proposals for the ISO standard do contain suggestions on this scale. -- Jeff -------------------- I'd rather see our limited resources spent on trying to get what we have into clear and consistent shape, so that we will really be able to call CL a standard. -- Nick  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 24 Jun 86 21:52:08 EDT Received: from XEROX.COM by SU-AI.ARPA with TCP; 24 Jun 86 18:20:54 PDT Received: from Cabernet.ms by ArpaGateway.ms ; 24 JUN 86 18:20:40 PDT Date: 24 Jun 86 18:20 PDT From: Pavel.pa@Xerox.COM Subject: Re: raster graphics In-reply-to: Jim Kempf 's message of Tue, 24 Jun 86 13:39:41 pdt To: kempf%hplabsc@hplabs.HP.COM cc: DCP@QUABBIN.SCRC.Symbolics.COM, common-lisp@SU-AI.ARPA Message-ID: <860624-182040-2960@Xerox> PLEASE!! Stop right here and move this discussion to the CL-Graphics list! It doesn't belong here and does belong there! Pavel  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 24 Jun 86 20:41:37 EDT Received: from [192.10.41.41] by SU-AI.ARPA with TCP; 24 Jun 86 17:05:30 PDT Received: from FIREBIRD.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 29030; Tue 24-Jun-86 16:17:23 EDT Date: Tue, 24 Jun 86 16:19 EDT From: David C. Plummer Subject: Argument lists To: Jonathan A Rees , Fahlman@C.CS.CMU.EDU cc: common-lisp@SU-AI.ARPA, Pavel.pa@XEROX.COM In-Reply-To: <[AI.AI.MIT.EDU].60667.860623.JAR> Message-ID: <860624161952.7.DCP@FIREBIRD.SCRC.Symbolics.COM> Date: Mon, 23 Jun 86 21:57:45 EDT From: Jonathan A Rees Date: Mon, 23 Jun 1986 21:23 EDT From: Scott E. Fahlman The section on argument lists consistently says "is an error" and not "signals an error". I can't remember (or imagine) why these cases aren't required to signal an error, and I think this should be fixed. Does anyone disagree? Are there any implementations out there that don't signal errors when a function is given too many or too few args? There are plenty of Lisp and Scheme implementations which have a mode in which such errors are not signalled or reliably detected. The two which spring to my mind are Maclisp and T, but I suspect that any Lisp that has a similar go-for-the-speed feature (PSL? Rutgers/UCI Lisp? ...) will fail to signal an error when a compiled function of a fixed number of arguments is passed a wrong number of arguments. I can't say I know of any such Common Lisp implementation, but it's certainly easy to imagine one. I don't see why this situation should be any different from any other kind of domain error, like AREF'ing out of bounds. You can certainly get speed improvements on stock hardware if you don't check number of arguments (you can eliminate a compare instruction, save space, etc.). Consistency is more important than speed, of course: if, for whatever reason, an error must be signalled in this case, then so should errors be signalled in most places which are now defined to "be an error". Otherwise, on what principle do you distinguish these two kinds of situation? If CL does not come to require number of argument checking, I guess its time to require *RSET to fill the gap. Seriously. Programmers should be allowed to say "I want number of arguments checking, damn it" if the system doesn't automatically provide that. [After all, if you don't want number of argument checking, you can just code your lambda list beginning with &optional and ending with &rest ignore.]  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 24 Jun 86 17:02:44 EDT Received: from HPLABS.HP.COM by SU-AI.ARPA with TCP; 24 Jun 86 13:46:03 PDT Received: from hplabsc by hplabs.HP.COM ; Tue, 24 Jun 86 13:44:52 pdt Received: by hplabsc ; Tue, 24 Jun 86 13:39:41 pdt Date: Tue, 24 Jun 86 13:39:41 pdt From: Jim Kempf Message-Id: <8606242039.AA10124@hplabsc> To: DCP@QUABBIN.SCRC.Symbolics.COM, common-lisp@SU-AI.ARPA Subject: Re: raster graphics How does this fit in with existing graphics standards (GKS, etc.)? Jim Kempf kempf@hplabs  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 24 Jun 86 16:23:09 EDT Received: from CS.UCL.AC.UK by SU-AI.ARPA with TCP; 24 Jun 86 13:02:55 PDT Received: from aiva.edinburgh.ac.uk by 44d.Cs.Ucl.AC.UK via Janet with NIFTP id a014975; 23 Jun 86 15:24 BST From: Jeff Dalton Date: Mon, 23 Jun 86 14:39:41 -0100 Message-Id: <19836.8606231339@aiva.ed.ac.uk> To: Fahlman@c.cs.cmu.edu, snyder <@hplabs.hp.com:snyder@hplsny> Subject: Common Lisp 2000 Cc: common-lisp@su-ai.arpa, eulisp%inria.uucp@Cs.Ucl.AC.UK How do people feel about making changes like immutable/mutable whatevers part of the ANSI/ISO standard instead of waiting for Common Lisp 2000? I don't mean this particular change, which after all we might decide we don't want at all, but rather changes of this magnitude. The EuLisp proposals for the ISO standard do contain suggestions on this scale. -- Jeff  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 24 Jun 86 15:56:35 EDT Received: from [192.10.41.41] by SU-AI.ARPA with TCP; 24 Jun 86 12:34:25 PDT Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 28407; Tue 24-Jun-86 00:37:43 EDT Date: Tue, 24 Jun 86 00:35 EDT From: Kent M Pitman Subject: Why are char bits portable? To: Masinter.PA@XEROX.ARPA cc: Common-Lisp@SU-AI.ARPA In-Reply-To: <860619-123848-1153@Xerox> References: <860620120906.9.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> Message-ID: <860624003515.3.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> [This message was sent last Friday but got returned due to some network problems. Apologies to anyone who gets duplicate copies.] Date: 19 Jun 86 12:32 PDT From: Masinter.pa@Xerox.COM Subject: Re: Why aren't char bits portable? To: common-lisp@su-ai.ARPA In-Reply-to: KMP%SCRC-STONY-BROOK:ARPA's message of Monday, June 9, 1986 12:23 pm Message-ID: <860619-123848-1153@Xerox> Char-bits aren't portable because they are a property of the physical keyboard of the machine, and, most keyboards don't have bits that correspond to them. ("Most" when enumerating all keyboards, computer keyboards, keyboards on machines that run lisp, or even accepted standards (DIN, ANSI) for keyboards.) The best thing that a "portable" program can do to cope with the variety of keyboards is twofold: a) stick as much as possible within the set of standard characters I assume the Japanese and IBM folks monitoring this discussion got a good chuckle out of this one. I'm not sure what you mean by the set of standard characters. Much of the CL spec is explicitly vague on the issue in order to not preclude major changes in either character set or number of shift chars provided. b) mark the mapping of keys to characters as a clear implementation-dependent part of programs that have to go beyond the standard characters. It's important to distinguish between implementation dependent behavior and unpredictable behavior. Many things in Common Lisp are conceptually well-defined even though they vary from implementation to implementation. For example, the behavior of (1+ MOST-POSITIVE-FIXNUM) varies in detail from implementation to implementation, but conceptually it does not. I don't think that it's inappropriate to describe a program as having useful commands bound to keys and to tell the user to type "?" to see a list of the commands available. You may have to do this for more reasons than just char bits. Maybe some commands won't turn themselves on for other reasons. Eg, maybe some setup code will not enable a certain command because MOST-POSITIVE-FIXNUM is too small, or SINGLE-FLOAT-EPSILON is too big, or MACHINE-INSTANCE returns NIL, or whatever. The issue is much bigger than you make it out to be and if you claim it to be fatal, then I claim you're attacking the whole notion of whether CL can be portable... and I don't know if CL programs can ever be truly portable, but I believe we can fix the language such that they can be usefully portable. Char-bits have no more place in the "standard" than does double-bucky-coke-bottle. [For those who don't know the term, a bucky bit is a generalized shift bit. Control, Meta, Super, and Hyper are examples of such bits.] This just isn't so. ITS Teco and ITS Emacs (which was ported to TOPS-20) uses char bits quite portably, even though huge numbers of Emacs users have only ASCII keyboards. The compatibility there works remarkably gracefully. I had written a ton of programs which presumed that there was a control bit. Teco's reader just took care of knowing what kind of keyboard users were on, automatically translating ascii 001 to an A with the Control bit set, etc. In the case of ;, which cannot be controllified in ASCII, Emacs provided c-^ as an prefix which would put a control bit on the next char typed and pass that through. That way, I could type c-^ A and get a Control-A. I also note that I use my Lisp Machine from home (on an Ambassador terminal) and it does exactly the same trick. There's a front end processor which takes c-^ char into c-char, ESC char into m-char, c-] char into s-char, etc. It even lets me type Resume, Abort, End etc. by c-_ R, c-_ A, c-_ E, etc. The point is that Lisp itself manages this, and any program I write sees "normal" chars with bucky bits properly attached. CL makes no statements about keyboards at all. There's nothing to say that you don't have a tablet or voice input device managing your I/O. All we say is that there are functions which read characters from streams. How those characters end up being placed on the stream is pretty much left up to the particular implementation. So I just don't believe this argument. As long as users of a portable program can get to all the relevant commands, they don't tend to complain that their keyboard (which perhaps has no META key) cannot type META-X. They just don't use META-X -- presumably they get the same functionality some other way. But users who have a META key -do- complain when there's functionality available and a free key that the functionality could be attached to. The current CL strategy for bucky bits allows me the ability to deal with exactly this problem -- attaching things to chars when they're available and not when they're not. Why would you want to deny me the opportunity to do that? Presumably if it wouldn't be a natural thing on your machine, then you just don't implement the bits for your implementation, and my programs will never try to use them, and your users won't think to complain because they won't have funny shift keys that suggest they -should- be using them. Also, the presence of bucky bits in CL may help encourage some keyboard vendors to add bits. If we say "let's not use these bits because no keyboard vendors provide them", then I fear that at their next design meeting, they'll say "let's not provide these bits because no languages seem to use them". Someone's got to take the first step. We already have. I see no reason to back off on it if people (eg, me) are using it productively.  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 24 Jun 86 15:39:40 EDT Received: from SCRC-QUABBIN.ARPA by SU-AI.ARPA with TCP; 24 Jun 86 12:24:49 PDT Received: from FIREBIRD.SCRC.Symbolics.COM by QUABBIN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 12852; Tue 24-Jun-86 15:23:27 EDT Date: Tue, 24 Jun 86 15:26 EDT From: David C. Plummer Subject: raster graphics To: common-lisp@SU-AI.ARPA Message-ID: <860624152614.1.DCP@FIREBIRD.SCRC.Symbolics.COM> I'm not on the special interest mailing list for graphics, so I don't know if this has been touched on. I encourage people who are considering proposing a CL graphics extension to read the Symbolics 6.1 Release Notes regarding changes to arrays, section 2.1.2, pages 5 through 12. The important concept is the abstraction of 2 dimentional arrays of pixels into things called rasters. The problem is that arrays are indexed by row,column and rasters are indexed by x,y, but x=column,y=row. Therefore, if you simply wrote raster code using AREF it would look awkward: (aref some-array y x) Along the same lines, rasters have width and height (generally thought of in that order), but 2D arrays have rows and columns, and again, the two are exchanged. The documentation includes a variety of functions to deal with this, for example, (raster-aref some-raster x y) which turns into the appropriate aref, and (decode-raster-array some-raster) which returns as multiple values the width and height. One reason we did this was to aid in the conversion from the Release-6-and-before column major system to the CL-and-Release-7 row major system. It allowed user source code to run in either system, since the system provided the correct abstraction for each. I have since come to believe the abstraction is worthy in its own right, and hope that something like it would appear as part of a CL graphics extension.  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 24 Jun 86 14:32:24 EDT Received: from [192.10.41.41] by SU-AI.ARPA with TCP; 24 Jun 86 11:15:24 PDT Received: from EUPHRATES.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 28102; Mon 23-Jun-86 14:40:13 EDT Date: Mon, 23 Jun 86 14:39 EDT From: David A. Moon Subject: Argument Lists To: Common-Lisp@SU-AI.ARPA Message-ID: <860623143926.8.MOON@EUPHRATES.SCRC.Symbolics.COM> There seems to be general agreement that there should be a standard function that returns the minimum and maximum number of arguments accepted by a given function. But what about functions that take &KEY arguments?  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 24 Jun 86 13:02:58 EDT Received: from BBNG.ARPA by SU-AI.ARPA with TCP; 24 Jun 86 09:49:18 PDT Date: 24 Jun 1986 12:47-EDT Sender: NGALL@G.BBN.COM Subject: Re: defconstant From: NGALL@G.BBN.COM To: common-lisp@SU-AI.ARPA Message-ID: <[G.BBN.COM]24-Jun-86 12:47:31.NGALL> In-Reply-To: <8606240407.AA00961@kurims.kurims.kyoto-u.junet> Date: Tue, 24 Jun 86 13:07:15+0900 From: nttlab!kurims!yuasa@kurims.kurims.kyoto-u.junet To: nttlab!Shasta!common-lisp@su-ai.arpa Subject: defconstant Message-ID: <8606240407.AA00961@kurims.kurims.kyoto-u.junet> ... Our implemenatation for constant references in compiled code is based on the following statement of CLtL page 68. DEFCONSTANT name initial-value [doc] [Macro] ... DEFCONSTANT ... does assert that the value of the variable NAME is *fixed* and does license the compiler to build assumptions about the value into programs being compiled. My interpretation is that the compiler can safely assume that variable NAME will never be MAKUNBOUNDed. With this interpretation, Nick's example above is certainly an error. As far as I know, this interpretation of mine does not contradict any CLtL statements, as Scott said in his message: I have been thinking about this issue for a while, and I now agree with Taiichi: MAKUNBOUND is a form of assignment (it is even in the assignment section of CLtL!); therefore my example violated the assertion made by defconstant, since the value of the constant had no value (i.e., a different value) at load time. What bothered me (and still does) is that the "test" for violation occured at load time, which I had never seen before nor expected. But I should not have let my expectations color my interpretation of CLtL. I even think that your implementation is "safer", in that programmers are prevented from loading their files in a different order than they compiled them. Your handling of defconstant is simple and elegant, keep it in. But be prepared for a few complaints since no (?) other implementation has adopted your implementation technique. -- Nick  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 24 Jun 86 11:16:56 EDT Received: from CS.UCL.AC.UK by SU-AI.ARPA with TCP; 24 Jun 86 08:08:11 PDT Received: from aiva.edinburgh.ac.uk by 44d.Cs.Ucl.AC.UK via Janet with NIFTP id a017573; 23 Jun 86 21:02 BST From: Jeff Dalton Date: Mon, 23 Jun 86 20:55:31 -0100 Message-Id: <23498.8606231955@aiva.ed.ac.uk> To: KMP@scrc-stony-brook.arpa, NGALL@bbng.arpa Subject: Re: Argument Lists and ADVISE Cc: COMMON-LISP@su-ai.arpa, Fahlman@c.cs.cmu.edu Date: 23 Jun 1986 12:31-EDT From: NGALL@arpa.bbng Subject: Re: Argument Lists Without information as to the number of required, optional, and (in some implementations?) keyword arguments (and in the case of keyword arguments, the names of the keywords), the encapsulation function will be forced to do unnecessary consing (because it will have to use &rest) and use a less efficient form of function calling (in most impl.), APPLY. If you can't find out the argument list, you can of course still write something like ADVISE without using &REST provided that the user must specify an argument list for the new definition. This is not such a bad thing, because the user might, after all, want to advise the function to take different arguments. And you can avoid APPLY if the user has to explicitly call the old definition using a name like FORWARD or OLD-f (it has to be distinct from the actual function name because the new definition may want to call itself). The syntax could be like DEFUN, e.g., from my Franz .lisprc file: (define-embedding putd (name def) (if (and *notice-redefinitions* (getd name)) (msg name " redefined (putd)" N)) (call-forward name def)) This is not to say that ARGUMENT-LIST wouldn't be useful, though. -- Jeff  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 24 Jun 86 06:20:08 EDT Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 24 Jun 86 03:14:06 PDT Received: ID ; Tue 24 Jun 86 06:14:16-EDT Date: Tue 24 Jun 86 06:14:16-EDT From: vijay Subject: Pl. put me on the list. To: common-lisp@SU-AI.ARPA Message-ID: <12217332943.37.SARASWAT@C.CS.CMU.EDU> vas@k.cs.cmu.edu Thanks, Vijay. -------  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 24 Jun 86 03:25:29 EDT Received: from XEROX.COM by SU-AI.ARPA with TCP; 24 Jun 86 00:19:06 PDT Received: from Cabernet.ms by ArpaGateway.ms ; 24 JUN 86 00:18:40 PDT Date: 24 Jun 86 00:15 PDT From: Pavel.pa@Xerox.COM Subject: Re: Argument Lists In-reply-to: "Scott E. Fahlman" 's message of Mon, 23 Jun 86 22:58 EDT To: Fahlman@C.CS.CMU.EDU cc: common-lisp@SU-AI.ARPA Message-ID: <860624-001840-2332@Xerox> The info about Max and Min args must be around at runtime if you do the checking. Do you plan to eliminate the arg-count info if the users turns on this optimization, or will the info still be around? The info about min and max need only exist implicitly in the compiled code, if the number-check is implemented in macro-code. If it's done in microcode as a part of function call, then it will likely be a part of the function header and thus considerably easier to get at. In the former case, turning on the optimization would remove the information. Pavel  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 24 Jun 86 03:11:32 EDT Received: from SU-SHASTA.ARPA by SU-AI.ARPA with TCP; 24 Jun 86 00:02:29 PDT Received: by su-shasta.arpa; Tue, 24 Jun 86 00:00:34 PDT From: nttlab!kurims!yuasa@kurims.kurims.kyoto-u.junet Received: by nttlab.ntt.junet (4.12/5.0) with TCP; Tue, 24 Jun 86 14:40:16 jst Received: by kurims.kurims.kyoto-u.junet (2.0/6.1Junet) id AA00961; Tue, 24 Jun 86 13:07:15+0900 Date: Tue, 24 Jun 86 13:07:15+0900 Message-Id: <8606240407.AA00961@kurims.kurims.kyoto-u.junet> To: nttlab!Shasta!common-lisp@su-ai.arpa Subject: defconstant Cc: nttlab!Shasta!FAHLMAN@c.cs.cmu.edu, nttlab!Shasta!NGALL@bbng.arpa >From: Shasta!NGALL@G.BBN.COM >Message-Id: <[G.BBN.COM]20-Jun-86 22:29:37.NGALL> > >File foo contains: > >(defconstant const ...) >... > >File bar contains: > >(defun zap (x) > ... (reference const x) ...) > >Now suppose that I compile file bar in an environment in which I have >already loaded foo. Thus the compiler will recognize that the >reference to const in zap is a reference of a constant. > >.... > >But how about an implementation that does the following: It >substitutes a reference to a slot in the compiled function's "constant >vector" (i.e., the piece of data where most implementations store >constant values). BUT it does not init the slot at compile time (like >most implementations), instead, it generates code that will init. the >slot to the value that const has at load time! >.... > >What do you think? By the way, thre does exist such an >implementation: KCL. > > -- Nick Our implemenatation for constant references in compiled code is based on the following statement of CLtL page 68. DEFCONSTANT name initial-value [doc] [Macro] ... DEFCONSTANT ... does assert that the value of the variable NAME is *fixed* and does license the compiler to build assumptions about the value into programs being compiled. My interpretation is that the compiler can safely assume that variable NAME will never be MAKUNBOUNDed. With this interpretation, Nick's example above is certainly an error. As far as I know, this interpretation of mine does not contradict any CLtL statements, as Scott said in his message: >From: "Scott E. Fahlman" >Subject: defconstant >In-Reply-To: Msg of 20 Jun 1986 22:29-EDT from NGALL at G.BBN.COM > >I agree with Nick's analysis. A reference to a constant may be compiled >as a variable reference or the value of the constant at compile time may >be wired into the code, but if the latter is done, this should not >depend on the constant having been initialized at load time. I agree >that the manual is too vague on this point, and should be clarified. If my interpretation is not what CLtL intends, I am very glad to change our implementation, whether or not the intension is stated explicitly in CLtL. However, before doing the change, let me tell you some details about KCL. >I suspect that KCL handles Defconstant this way in order to optimize the >use of lists as constants, while still observing the requirement that >all references to the constant must be EQL to one another, but this is a >very tricky business and is probably not worth the trouble it takes to >get it right. > >-- Scott It IS worth the trouble!! The KCL loader, when it loads a compiled code file, stores the values of constants into fixed locations (NOT into a "constant vector" as Nick guessed). Each reference to a constant within a compiled code directly refers to the fixed location. This referencing operation IS faster than retrieving the value from the symbol cell, which requires some kind of indexing (hardware indexing, perhaps). (The portable C code generated by the KCL compiler looks as if it references constants by indexing, but this is one of the well-known C fakes commonly used by C programmers.) -- Taiichi  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 24 Jun 86 01:36:25 EDT Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 23 Jun 86 22:24:53 PDT Received: from umass-cs by csnet-relay.csnet id ar23860; 24 Jun 86 1:14 EDT Date: Mon, 23 Jun 86 14:59 EST From: MURRAY%cs.umass.edu@CSNET-RELAY.ARPA To: common-lisp@SU-AI.ARPA Subject: Argument-lists and friends I asked for this function a while ago. I feel handicapped without being able to quickly see the arglist to a function. Without this function, we now put the arglist in the docstring, which is probably a good idea anyway. But that does require you to have a docstring for the function. That may be fine for user-interface, but the more important problem is for it to be program accessable. I think it is important that a common-lisp interpretor can be written in common-lisp. To do this, there are three things that my Visual Stepper has to hack in an implemention dependant way: 1. What the argument list is to a function. For this I need the entire arglist, with &AUX variables and init forms as well. If a system provides anything less, it is useless except to find the minimum and max arg count. 2. The body to the function. 3. Whether a binding should be special. For uncompiled objects, the first two things should be accessable without any overhead. For compiled objects, it may be asking to much for this information. In this case, you should at least be able to get the min and max number of args, to do code analysis. I think the following proposed functions should be optional in common-lisp, but strongly encouraged to be supported: FUNCTION-ARGLIST that takes a symbol and returns the DEFUN supplied argument-list, and a second value of T, if the first value is meaningful. If the second value is NIL, then the first value is meaningless. FUNCTION-BODY takes a symbol and returns the body of the defun (with the BLOCK around it), and again a second value indicating the validity of the first one. FUNCTION-ARGCOUNT takes a symbol and returns two values, minimum argcount and max argcount, or NIL for both indicating invalidity. Each of this functions should signal an error if the symbol is not a function. In the case of a macros, we could have analogous MACRO-xx functions, so one could interpret macro expansions. Alternatively, the above functions could take any function-object as well as a symbol, so *macroexpand-hook* could be used to interpret macro expansions, giving the function-object argument to the above functions. Just to complete my need, I propose SPECIAL-VARIABLE-P to return T, if a symbol is globally special. Kelly Murray  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 24 Jun 86 01:24:42 EDT Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 23 Jun 86 22:16:08 PDT Received: from umass-cs by csnet-relay.csnet id al23860; 24 Jun 86 1:12 EDT Date: Mon, 23 Jun 86 13:22 EST From: ELIOT%cs.umass.edu@CSNET-RELAY.ARPA To: Common-Lisp@SU-AI.ARPA Subject: Error Checking in SUBSEQ I feel strongly that it is a bad idea to spend effort looking for weird ways to interpret meaningless arguments to functions. The only MAIL advantage to this is that it increases the functionality of CL without increasing the number of functions in it, a dubious advantage. This amounts to the same thing as "overloading operators" in more ugly (i.e. traditional) programming languages, which is known to make it hard for compilers and programmers. It is much better to define new functions (or syntactically distinguishable variants, such as :FROM-END) for new functionality. This allows the programmer to tell the compiler/computer much more about his intended use of the function. This enables the language implementor to support more fine-grained error checking, and better compilations. Several years ago while I was working on the editor for NIL, the unlderlying error checking facilities were improved. This showed several cases where I had called %STRING-SUBSEQ as if it took (string start end) arguments, instead of (string start count) arguments. I don't remember what effect this had, but the bug had been there for a long time. As far as I am concerned it is better to decrease functionality so that error checking can be improved than to increase functionality at the expense of error checking. Error checking is our friend.  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 23 Jun 86 23:07:25 EDT Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 23 Jun 86 19:58:53 PDT Received: ID ; Mon 23 Jun 86 22:59:02-EDT Date: Mon, 23 Jun 1986 22:58 EDT Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: Pavel.pa@XEROX.COM Cc: common-lisp@SU-AI.ARPA Subject: Argument Lists In-reply-to: Msg of 23 Jun 1986 22:48-EDT from Pavel.pa at Xerox.COM In Interlisp, it is not an error to be given extra arguments (they are silently thrown away) or too few (all arguments are implicitly optional and default to NIL). While Xerox Common Lisp will signal an error in such cases, we will also provide a setting of the optimize declarations that will disable the checking for performance reasons. The info about Max and Min args must be around at runtime if you do the checking. Do you plan to eliminate the arg-count info if the users turns on this optimization, or will the info still be around? -- Scott  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 23 Jun 86 23:00:38 EDT Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 23 Jun 86 19:51:30 PDT Received: ID ; Mon 23 Jun 86 22:51:26-EDT Date: Mon, 23 Jun 1986 22:51 EDT Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: Jonathan A Rees Cc: common-lisp@SU-AI.ARPA Subject: Argument lists In-reply-to: Msg of 23 Jun 1986 21:57-EDT from Jonathan A Rees Yes, you're right. Wrong number of arguments should be treated like AREF'ing out of bounds or type violations. The manual currently says that these things are errors, but not that they must signal an error. A good implementation will signal errors in most of these cases unless compiled for maximal speed and minimal safety, but implementations are not currently required to do this. You ask about philosophy. Here's my current view -- it has evolved a bit in the last couple of years: There are three good reasons to document something as "being" an error, but not as "signalling" one: first, it might be a place where we imagine someone will want to extend the language, and where we want to leave that possibility open; second, it might be an error that (perhaps only on some architectures) is just impossible to detect with a reasonable amount of effort; third, it might be a place where a few cycles can be saved by not checking for the error. It seems to me that, if we were doing this from scratch, we ought to treat these cases differently. Specifically, I would go with four classes of errors: 1. Errors that must always be signalled, and that portable code can count on having signalled. These are errors where little speed-up would result from allowing them to go undetected. 2. Errors that must normally be signalled, but that need not be if code is compiled with safety = 0. Most of the current "is an error" conditions, including wrong number of args, out-of-bounds array refs, and most type violations, would fall in here. 3. Errors that are too hard to detect, and which need not be signalled. Non-terminating code might be an example. 4. Errors that must be signalled unless an implementation deliberately chooses to extend the language in this area, and documents that it has done so. I'm not sure how much of this we ought to allow. I suspect that this is too large a change to think about for the current set of revisions. No legal and portable user code would be affected, but I suspect that some implementations would require a lot of revision in order to comply with the tightened requirements of case 2. -- Scott  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 23 Jun 86 22:56:10 EDT Received: from XEROX.COM by SU-AI.ARPA with TCP; 23 Jun 86 19:48:40 PDT Received: from Cabernet.ms by ArpaGateway.ms ; 23 JUN 86 19:48:49 PDT Date: 23 Jun 86 19:48 PDT From: Pavel.pa@Xerox.COM Subject: Re: Argument Lists In-reply-to: "Scott E. Fahlman" 's message of Mon, 23 Jun 86 21:23 EDT To: Fahlman@C.CS.CMU.EDU cc: common-lisp@SU-AI.ARPA Message-ID: <860623-194849-2250@Xerox> Are there any implementations out there that don't signal errors when a function is given too many or too few args? In Interlisp, it is not an error to be given extra arguments (they are silently thrown away) or too few (all arguments are implicitly optional and default to NIL). While Xerox Common Lisp will signal an error in such cases, we will also provide a setting of the optimize declarations that will disable the checking for performance reasons. Pavel  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 23 Jun 86 22:10:20 EDT Received: from AI.AI.MIT.EDU by SU-AI.ARPA with TCP; 23 Jun 86 18:56:56 PDT Date: Mon, 23 Jun 86 21:57:45 EDT From: Jonathan A Rees Subject: Argument lists To: Fahlman@C.CS.CMU.EDU cc: common-lisp@SU-AI.ARPA, Pavel.pa@XEROX.COM In-reply-to: Msg of Mon 23 Jun 1986 21:23 EDT from Scott E. Fahlman Message-ID: <[AI.AI.MIT.EDU].60667.860623.JAR> Date: Mon, 23 Jun 1986 21:23 EDT From: Scott E. Fahlman The section on argument lists consistently says "is an error" and not "signals an error". I can't remember (or imagine) why these cases aren't required to signal an error, and I think this should be fixed. Does anyone disagree? Are there any implementations out there that don't signal errors when a function is given too many or too few args? There are plenty of Lisp and Scheme implementations which have a mode in which such errors are not signalled or reliably detected. The two which spring to my mind are Maclisp and T, but I suspect that any Lisp that has a similar go-for-the-speed feature (PSL? Rutgers/UCI Lisp? ...) will fail to signal an error when a compiled function of a fixed number of arguments is passed a wrong number of arguments. I can't say I know of any such Common Lisp implementation, but it's certainly easy to imagine one. I don't see why this situation should be any different from any other kind of domain error, like AREF'ing out of bounds. You can certainly get speed improvements on stock hardware if you don't check number of arguments (you can eliminate a compare instruction, save space, etc.). Consistency is more important than speed, of course: if, for whatever reason, an error must be signalled in this case, then so should errors be signalled in most places which are now defined to "be an error". Otherwise, on what principle do you distinguish these two kinds of situation? Jonathan  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 23 Jun 86 21:54:03 EDT Received: from SCRC-YUKON.ARPA by SU-AI.ARPA with TCP; 23 Jun 86 18:30:40 PDT Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by YUKON.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 43011; Mon 23-Jun-86 15:50:51 EDT Date: Mon, 23 Jun 86 15:50 EDT From: Kent M Pitman Subject: portability of pathnames To: Fahlman@CMU-CS-C.ARPA cc: SANDRA@UTAH-20.ARPA, JAR@MIT-MC.ARPA, Moon@SCRC-STONY-BROOK.ARPA, KMP@SCRC-STONY-BROOK.ARPA, COMMON-LISP@SU-AI.ARPA In-Reply-To: References: <860530014715.8.MOON@EUPHRATES.SCRC.Symbolics.COM>, <12210074365.15.LOOSEMORE@UTAH-20.ARPA>, The message of 29 May 86 16:21-EDT from Jonathan A Rees , <12210693019.8.LOOSEMORE@UTAH-20.ARPA> Message-ID: <860623155040.8.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> Date: Sun, 22 Jun 1986 20:30 EDT From: "Scott E. Fahlman" To: SANDRA Cc: common-lisp@SU-AI.ARPA I'm going through old mail to make a list of issues we need to settle, or at least work on. I came across your complaint about portability of pathnames and the problems with make-pathname. I was just wondering if you had anything specific to propose. If not, I'll just add this to the agenda of things we collectively need to think about, but I'm not sure there's a good solution to be had. By the way, in my work with Macsyma I've seen most of the same problems as Sandra mentioned in her message that kicked off this line of conversation. She sounded in that message like she expected to get dumped on, but I hope that she's neither dumped on nor ignored. Most of those comments were very to the point. I do take very minor issue with her remark that the package issue seems a small one next to the other issues she cited. My reason for pushing so hard to get these package issues resolved is that they impede everyone's ability to get a foothold in a Lisp they're trying to port to. If we can't get expressions to read the same in each each Lisp, then we're stripped even of the ability to talk about language problems at the level of expressions and must too frequently resort to discussions of the meaning of source text. Also, in practice, implementation-specific workarounds are something you can get to much more easily once the syntactic barriers are resolved. But I don't mean to diminish the importance of these other issues. Pathnames are a horror to use in CL. Here's a list of the gripes I have with pathnames which come to mind just off the top of my head; I'm sure if I though harder I could think of others. Maybe Sandra could add some of her favorites... * Canonical case. If you study the Symbolics pathname system, you'll note that elaborate pains are taken to make the case of the components be stored in uppercase for interchange purposes even if they're composed as a namestring in another case. This allows the internal representation of the Unix pathname /joe/math.text and the Tops-20 pathname MATH.TEXT to use the same internal notation, with a name of "MATH" and type of "TEXT", and allows cross-file-system merging to be done correctly. The result of the current system is that one must write gross things like: (MAKE-PATHNAME :NAME THE-GIVEN-NAME :TYPE (IF *LOWERCASE-FILENAMES-P* "text" "TEXT")) and initialize the *LOWERCASE-FILENAMES-P* variable on the basis of implementation-specific information. As Moon points out, the Symbolics pathname system does this sort of thing invisibly, and people interested in how to fix this should study the documentation. It may seem hairy, but a portable file system interface is going to necessarily be somewhat hairy just because of the variance of file systems. I think given the constraints, it's not gratuitously hairy. * What can go in a host slot? CLtL don't say whether a Lisp implementation on host "FOO" is required to treat :HOST "FOO" the same as :HOST NIL or :HOST "" in MAKE-PATHNAME. In fact, nothing says whether "FOO:" or "FOO::" might be allowed (depending on what the native notation was for hosts was); I definitely don't think they should be, but there's nothing I can find protecting me from an implementation making this the -only- way to notate a host. * What can go in a directory slot? CLtL says it can hold a string, but it doesn't say whether the string contains any notational devices. eg, on VMS, is "FOO" ok for a directory or do you want "[FOO]". "FOO" would seem the most portable, since it doesn't get involved in the fact that TOPS-20 might want "" and the LispM might want ">FOO>" but it all doesn't matter much anyway because if you want to talk about subdirs, "FOO.BAR" doesn't completely hide the implementation because it works for systems that use the notation "" or "[FOO.BAR]" but not that use ">FOO>BAR" or "/FOO/BAR". Without this much information, the kinds of operations you can do on the contents are unreasonably limited. On the LispM, you say :DIRECTORY "JOE" but in VAXLISP you say :DIRECTORY "[JOE]". The LispM idea of allowing this to contain a list of directory names, as in ("FOO" "BAR") to mean /FOO/BAR or >FOO>BAR> is clearly more reasonable and I can't imagine why it was not adopted. * Canonical types. The extension which is used for certain standard kinds of files varies from implementation to implementation. eg, some systems call text files .txt and others .text. Some call lisp files .lsp, others .lisp, and others .clisp. Some call binary files .BIN, others .FAS, and so on. It would be nice if we'd adopted the LispM's canonical type system such certain dignified file types could be predefined for use with portable programs. Thus, (MAKE-PATHNAME :NAME "FOO" :TYPE :LISP) could refer to "FOO.LISP" in some implementations, "foo.l" in others, etc. * This business about semi-standard features like :NEWEST and :OLDEST is a pain. We need those features, but we should fully enumerate the entire set of possible contents and exactly what they denote, even if not everyone supports them all. It should be possible to construct a program that would be "ready for anything". Perhaps each implementation could keep a list of which keywords were valid for that implementation. * No way is provided for creating a relative pathname. This would be very useful for merging purposes even on systems which don't provide a namestring syntax for pathnames. It is especially essential in the absence of a clear specification of what the directory slot contains. * On issue is that there are so many fields which are allowed to contain implementation-dependent gunk as to make those fields are effectively write-only. * Printing pathnames. We provide no convenient way to print a pathname. On the LispM you can do (FORMAT T "~A" pathname) but not all implementations support that because CLtL doesn't say it should work. Doing (FORMAT T "~A" (NAMESTRING pathname)) seems dumb since, among other things, it forces gratuitous consing. * How do you compare pathnames? EQUAL pathnames are not obliged to be EQ. Since pathnames contain all these options for implementation-dependent featurism, the user is not able to write a PATHNAME-EQUAL. As far as I can tell, an implementation in which a directory slot of "FOO.BAR" and ("FOO" "BAR") are equivalent is not constrained to return T for EQUAL on two pathnames which contain identical things except one uses "FOO.BAR" and the other uses ("FOO" "BAR"). Indeed, even doing (EQUAL (NAMESTRING X) (NAMESTRING Y)) isn't good enough because, for example, VAX VMS allows logical names like "FOO:[.BAR]X.Y" to expand into "DEV1A:[FOO][.BAR]X.Y". I don't care if "FOO:[.BAR]X.Y" is PATHNAME-EQUAL to "DEV1A:[FOO][.BAR]X.Y" because that's a semantic issue that may get caught up in how the FOO logical device is implemented, but I do care that "DEV1A:[FOO][.BAR]X.Y" and "DEV1A:[FOO.BAR]X.Y" are PATHNAME-EQUAL because that's just a syntactic issue ... but I see no way of writing a portable PATHNAME-EQUAL. * I consider it to be a complete bug (and the only one that I've seen which I believe to also be a bug in the Symbolics pathname system) that you can't create a non-hosted pathname. eg, in the case of someone doing (MERGE-PATHNAMES "" "FOO") and later planning to do (MERGE-PATHNAMES * "JOE::") where "::" is the host syntax used by the book, if you force the first merge to put a host on, then the second merge won't pick up the "JOE" and the wrong thing will happen. This actually came up in MACSYMA and I was forced to invent my own pathname system which holds a CL pathname in a slot and also holds host-valid-p info that it keeps set to NIL after the first merge above (which must be done via MY-MERGE-PATHNAMES, not CL's MERGE-PATHNAMES) so that MY-MERGE-PATHNAMES can correctly do the second merge. * The phrase "in which case no parsing is needed, but an error check may be made for matching hosts" at the end of the first paragraph of the description of PARSE-NAMESTRING on p414 is an invitation to disaster since we don't specify how to obtain even the current machine's host name or in what syntax it should be presented in order to make this function happy. For example, (PARSE-NAMESTRING "FOO.LISP") in VAXLISP might return #S(PATHNAME :HOST "PETER" :DEVICE NIL :DIRECTORY NIL :NAME "FOO" :TYPE "LISP" :VERSION NIL) but (PARSE-NAMESTRING "FOO.LISP" "PETER") errs telling me that host "" and "PETER" conflict. I might report this as a bug and maybe they'd even fix it for me but I'd have nothing to fall back on if they disagreed because CLtL certainly doesn't come out and claim it's a bug. * The description of the pathname system offers no examples of using it any non-trivial way. All the examples use strings as arguments, but that's just the problem. In portable applications, strings just don't work. Sometimes, you're merging something that was typed in by the user but rarely is it being merged with something else typed by the user. The other thing is often something your program wanted to have wired in. If you tried to write even the simplest program using the given primitives in an even slightly non-trivial way, the problem would become apparent. eg, try to figure out how to specify the examples on p141 or p415 in a portable way. To put yourself in the right frame of mind, replace "DUMPER" on p414 with "MACSYMA" or "KEE" or "MYCIN" or something that you don't think of as TOPS-20 specific. The example on p415 is hard just as it is, for exactly the reasons of canonical types I've mentioned above. What am I expected to write? Top of p423 is the only place CLtL tries to do this, and it more or less succeeds in this trivial case ... except for the fact MERGE-PATHNAME-DEFAULTS isn't in the index and I suspect never made it into the spec. Any way you cut it, these three examples just don't do enough to illustrate what you can and can't do with the given primitives. I do think pathnames useful only for the most trivial purposes in CL. I don't think this means we should flush them. I think we should seriously study systems, particularly those offered by the LispM vendors, where there's been success in dealing with multiple file systems, and then I think we should agree on the additional mechanisms necessary to make things really work.  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 23 Jun 86 21:30:17 EDT Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 23 Jun 86 18:23:10 PDT Received: ID ; Mon 23 Jun 86 21:23:17-EDT Date: Mon, 23 Jun 1986 21:23 EDT Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: Pavel.pa@XEROX.COM Cc: common-lisp@SU-AI.ARPA Subject: Argument Lists In-reply-to: Msg of 23 Jun 1986 19:51-EDT from Pavel.pa at Xerox.COM It is not required that an implementation signal an error when there are either too many or too few arguments... I would have sworn that implementaitosn were required to signal an error in this case, but a scan of CLtL seems to indicate that you are right. The section on argument lists consistently says "is an error" and not "signals an error". I can't remember (or imagine) why these cases aren't required to signal an error, and I think this should be fixed. Does anyone disagree? Are there any implementations out there that don't signal errors when a function is given too many or too few args? -- Scott  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 23 Jun 86 21:25:21 EDT Received: from SCRC-QUABBIN.ARPA by SU-AI.ARPA with TCP; 23 Jun 86 18:16:03 PDT Received: from EUPHRATES.SCRC.Symbolics.COM by QUABBIN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 12526; Mon 23-Jun-86 21:14:15 EDT Date: Mon, 23 Jun 86 21:14 EDT From: David A. Moon Subject: Re: portability of pathnames To: NGALL@G.BBN.COM cc: common-lisp@SU-AI.ARPA In-Reply-To: <[G.BBN.COM]23-Jun-86 11:11:44.NGALL> Message-ID: <860623211400.6.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: 23 Jun 1986 11:11-EDT From: NGALL@G.BBN.COM .... The point I am trying to make is that pathnames really should be 100% implementation independent, including the contents of each of the components.... Get your hands on a Symbolics document set and read about Logical Pathnames. If I understand your requirements, Logical Pathnames are exactly what you're looking for. When they (we) were looking at the Zetalisp pathname system, most of the Common Lisp designers would not accept logical pathnames because they didn't see any use for them. It probably was also because logical pathnames were never explained very well. Perhaps we ought to be rethinking that decision now. If you get a chance to look at that documentation, I'm curious to hear your opinion about whether that, or something like it, should be added to Common Lisp.  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 23 Jun 86 21:19:42 EDT Received: from HPLABS.HP.COM by SU-AI.ARPA with TCP; 23 Jun 86 18:10:11 PDT Received: from hplsny by hplabs.HP.COM ; Mon, 23 Jun 86 18:08:51 pdt Received: by hplsny ; Mon, 23 Jun 86 18:08:35 pdt From: Alan Snyder Message-Id: <8606240108.AA02427@hplsny> Date: Monday, June 23, 1986 18:08:27 Subject: Re: Namestring&pathstring returning shared structure To: DCP@QUABBIN.SCRC.Symbolics.COM Cc: common-lisp@su-ai.ARPA In-Reply-To: Your message of 23-Jun-86 10:03:00 X-Sent-By-Nmail-Version: 04-Nov-84 17:14:46 CLU solved this problem by making STRING a different type than ARRAY of CHARACTER, and by making STRINGs immutable. We found having immutable STRINGs to be extremely useful: one can pass a string to a procedure or return it from a procedure without worrying that someone might destructively modify it! This idea was such a win that a later revision of CLU had both immutable and mutable arrays and immutable and mutable records. It must be a bitch to write an editor in CLU, or do you just implement lines as arrays of characters instead of as strings, thereby losing the textual benefit of debugging and having to write separate output routines to display these "strings"? Actually, the Ted editor (written in CLU) did use strings to represent lines of text. I believe using immutable strings is not uncommon, as it allows an EQ-test in display update. -------  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 23 Jun 86 20:24:16 EDT Received: from HPLABS.HP.COM by SU-AI.ARPA with TCP; 23 Jun 86 17:15:41 PDT Received: from hpljl by hplabs.HP.COM ; Mon, 23 Jun 86 17:14:12 pdt Received: by hpljl ; Mon, 23 Jun 86 17:15:49 pdt Date: Mon, 23 Jun 86 17:15:49 pdt From: Joachim H. Laubsch Message-Id: <8606240015.AA06020@hpljl> To: common-lisp@su-ai.ARPA Subject: common lisp mailing list Could You put me on this mailing list? Joachim Laubsch HPLabs  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 23 Jun 86 20:03:36 EDT Received: from XEROX.COM by SU-AI.ARPA with TCP; 23 Jun 86 16:55:45 PDT Received: from Cabernet.ms by ArpaGateway.ms ; 23 JUN 86 16:53:14 PDT Date: 23 Jun 86 16:51 PDT From: Pavel.pa@Xerox.COM Subject: Re: Argument Lists In-reply-to: "Scott E. Fahlman" 's message of Sat, 21 Jun 86 22:54 EDT To: Fahlman@C.CS.CMU.EDU cc: MILNES%cgi.CSNet@CSNet-Relay.ARPA, common-lisp@SU-AI.ARPA Message-ID: <860623-165314-2126@Xerox> Date: Sat, 21 Jun 86 22:54 EDT From: "Scott E. Fahlman" Every implementation has some way of determining at runtime the minimum and maximum argument counts for a function, so functions to report these could be added at very little cost. Where in CLtL does it say this? It is not required that an implementation signal an error when there are either too many or too few arguments, so I can't see why this information must be available in every implementation. I don't disagree with the position that it would be very useful, but it isn't (yet) required. Pavel  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 23 Jun 86 19:53:15 EDT Received: from XEROX.COM by SU-AI.ARPA with TCP; 23 Jun 86 16:44:18 PDT Received: from Cabernet.ms by ArpaGateway.ms ; 23 JUN 86 16:40:49 PDT Date: 23 Jun 86 16:40 PDT From: Pavel.pa@Xerox.COM Subject: Re: Namestring&pathstring returning shared structure In-reply-to: David C. Plummer 's message of Mon, 23 Jun 86 10:03 EDT To: DCP@QUABBIN.SCRC.Symbolics.COM cc: snyder%hplsny@hplabs.HP.COM, Fahlman@C.CS.CMU.EDU, common-lisp@SU-AI.ARPA Message-ID: <860623-164049-2116@Xerox> Date: Mon, 23 Jun 86 10:03 EDT From: David C. Plummer It must be a bitch to write an editor in CLU, or do you just implement lines as arrays of characters instead of as strings, thereby losing the textual benefit of debugging and having to write separate output routines to display these "strings"? The Cedar system at PARC provides an immutable string type called ROPE's (thick strings) and the editor in fact uses them. Once you know that the strings are immutable, you can play all sorts of fun games with their representation, including sharing structure all over the place and getting (nearly) constant-time concatenation and substring operations with very slightly degraded fetch performance. Immutable strings are an extremely big win and I hope to have us (Xerox) implement them for our Lisp in the relatively near future. Pavel  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 23 Jun 86 16:31:47 EDT Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 23 Jun 86 13:04:50 PDT Received: ID ; Mon 23 Jun 86 16:04:32-EDT Date: Mon, 23 Jun 1986 16:04 EDT Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: Jeff Dalton Cc: common-lisp@SU-AI.ARPA Subject: Common Lisp 2000 How do people feel about making changes like immutable/mutable whatevers part of the ANSI/ISO standard instead of waiting for Common Lisp 2000? I don't mean this particular change, which after all we might decide we don't want at all, but rather changes of this magnitude. The EuLisp proposals for the ISO standard do contain suggestions on this scale. I sent out a message a couple of weeks ago describing my own views on what guidelines we should follow in developing a proposed ANSI/ISO standard definition for Common Lisp. Basically, the view was that Common Lisp is already a de facto standard with many implementaitons and many users. Any tinkering we do on the way to making it an official standard has to consider the costs of each change, in terms of existing implementations, application code, user skills, and documents, as well as any benefits the change might bring. I believe that the guidelines I suggested accurately reflect the views of the overwhelming majority of the Common Lisp community (there was only one dissenting message), and unless that view is shown to be in error, I expect that the new Common Lisp definition we are developing will follow them. With Common Lisp we have achieved an important goal: unifying the commercial part of the Lisp community behind a single dialect. Developing an official standard for Common Lisp will help to cement that goal, and will give the commercial world something stable and usable to hang on to while work continues on better Lisps for the future. All of us would like to see better, cleaner Lisp systems in use eventually, and I applaud the efforts of the Eulisp people to develop a more rational dialect of Lisp and to explore the potential for formal methods in defining a system of this size. I see no conflict between this work going forward and the adoption of a standard for Common Lisp. In fact, if the competitive aspect were eliminated, I think that it would be much easier for the EuLisp group to stick to their vision of truth and beauty: no need to make the sorts of compromises that would be required to win over companies in the short run. In addition, it would make it easier for us to contribute ideas to the EuLisp development, and for the EuLisp people to participate in our attempts to clarify Common Lisp in minor ways. The stumbling block, as I see it, is the insistence by some of the Eulisp people that there must be only one Lisp standard in the forseeable future, and that that place must be reserved for an "acceptable" dialect, and not the one that everyone is using. The commercial AI world has just, at great expense, settled on Common Lisp, and they are not going to make any more radical changes in the next couple of years, regardless of what we or EuLisp or ISO might do. In a couple of years (sooner than the year 2000, I think), the industry might be ready to shift to EuLisp or some version of Scheme or a version of Common Lisp that is cleaned up in more radical ways. I'd like to see that happen, when the time is right and when the new candidate has established itself on its merits. It will happen sooner if we can give the people in industry a period of relative stability by adopting Common Lisp as a standard in the meantime. -- Scott  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 23 Jun 86 14:36:49 EDT Received: from MC.LCS.MIT.EDU by SU-AI.ARPA with TCP; 23 Jun 86 11:28:46 PDT Received: from CCC.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 23 JUN 86 14:30:37 EDT Date: 23 Jun 1986 14:27:21-EDT From: uucp@MIT-CCC From gjc%mc.ARPA Mon Jun 23 13:42:13 1986 remote from lmi-angel Received: from LMI-MOE by lmi-angel.ARPA (4.12/4.7) with CHAOS id AA00822; Mon, 23 Jun 86 13:40:31 edt Date: Monday, 23 June 1986, 13:40-EDT From: lmi-angel!gjc%mc.ARPA Subject: Namestring&pathstring returning shared structure To: mitccc!DCP%QUABBIN.SCRC.Symbolics.COM%mc@angel.ARPA Cc: mitccc!common-lisp%SU-AI%mc@angel.ARPA Message-Id: <[LMI-MOE].23-Jun-86 13:40:18.GJC> Why stop at strings Dave? Another win would be immutable list structure. Think of it, (as the CLU'ist remarked) you can pass a whole list to a function without having to worry about the possible RPLACA or RPLACD operations it may do! Actually, one could make this into a serious suggestion. Certainly most systems have so-called pure areas, for example, in the LMI system you get a write-into-read-only-memory error if you do (setf (aref (get-pname 'foo) 0) #\X), and perhaps this feature could actually be presented in a system-independant way. Something along the lines of "if the pure-structure feature is provided then the primitives should be called PURE-COPY (or PURCOPY) and PURE-P." -gjc  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 23 Jun 86 12:43:27 EDT Received: from BBNG.ARPA by SU-AI.ARPA with TCP; 23 Jun 86 09:34:48 PDT Date: 23 Jun 1986 12:31-EDT Sender: NGALL@G.BBN.COM Subject: Re: Argument Lists From: NGALL@G.BBN.COM To: KMP@SCRC-STONY-BROOK.ARPA Cc: Fahlman@C.CS.CMU.EDU, COMMON-LISP@SU-AI.ARPA Message-ID: <[G.BBN.COM]23-Jun-86 12:31:52.NGALL> In-Reply-To: <860622025257.9.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> Date: Sun, 22 Jun 86 02:52 EDT From: Kent M Pitman To: Fahlman@C.CS.CMU.EDU Subject: Argument Lists Message-ID: <860622025257.9.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> ... Personally, I think something that computes minimum/maximum number of arguments should be put into the language. I'll defer any recommendation about something which gets the ARGLIST itself until I've thought harder about the implications. If ARGLIST is put in, it should probably be under the name ARGUMENT-LIST. -------------------- One tool that would greatly benefit from information about the lambda-list (the correct Lisp name for a parameter list or [sic] argument list) is a portable "advise" tool (ala InterLisp and ZetaLisp). Without information as to the number of required, optional, and (in some implementations?) keyword arguments (and in the case of keyword arguments, the names of the keywords), the encapsulation function will be forced to do unnecessary consing (because it will have to use &rest) and use a less efficient form of function calling (in most impl.), APPLY. The minimum acceptable functionality for a function providing lambda-list info (I'll call it LAMBDA-LIST) would be the for it to return the number of required args, the number of requireds+optionals (or just the number of optional, if you prefer), and a flag indicating whether or not a &rest/&key is present. I would prefer that the function return the number of required args, the number of optional args, a list of keyword names, a flag indicating whether an &rest parameter exists, and a flag indicating whether or not an &allow-other-keys exists. But I realize that the keyword info. may be a bit of a burden on some implementations. The truly right way to do it is, as Mike Beckerle suggested, return the type spec (but I wouldn't include the parameter names). But I doubt that implementors want to invest that much effort in it. -- Nick  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 23 Jun 86 11:31:06 EDT Received: from BBNG.ARPA by SU-AI.ARPA with TCP; 23 Jun 86 08:13:46 PDT Date: 23 Jun 1986 11:11-EDT Sender: NGALL@G.BBN.COM Subject: Re: portability of pathnames From: NGALL@G.BBN.COM To: Fahlman@C.CS.CMU.EDU Cc: LOOSEMORE@UTAH-20.ARPA, common-lisp@SU-AI.ARPA Message-ID: <[G.BBN.COM]23-Jun-86 11:11:44.NGALL> In-Reply-To: Date: Sun, 22 Jun 1986 20:30 EDT From: "Scott E. Fahlman" To: SANDRA Subject: portability of pathnames In-Reply-To: Msg of 29 May 1986 22:20-EDT from SANDRA Message-ID: I'm going through old mail to make a list of issues we need to settle, or at least work on. I came across your complaint about portability of pathnames and the problems with make-pathname. I was just wondering if you had anything specific to propose. If not, I'll just add this to the agenda of things we collectively need to think about, but I'm not sure there's a good solution to be had. -- Scott -------------------- I don't remeber what Sandra's suggestion was, but I have one: On page 409 of CLtL it says, "names can be fit into a certain canonical, implementation-independent form called a pathname." But on page 412 it says, "What values are allowed for components of a pathname depends, in genneral, on the pathname's host." Given this latter statement, it seems that the only implementation-independent thing about the form of a pathname is that it has 6 components! (Even this isn't totally true, since some implementations that don't support versions may not allow assignment of anything to the version component!) CLtL does state that there are conventions for the components. What I would like is for these conventions to be required. For example, in every implementation, one may give MAKE-PATHNAME a :type argument that is either a string (and CLtL should specify that there are no pathname specific restrictions on the length of the string) of NIL or :WILD (such is currently the TYPE convention). The host convention also makes sense. When I say that all implementations must accept a string of any length or, in the case of a host, accept a list of strings, I do not mean that such a pathname must be convertable into a legal namestring. I merely mean that an application should should be able to generate pathnames as it sees fit and delay the 'legality' check until it actually wants to interface to the file system. For example, my application uses names that are <= 10 chars. If I move to a CL that supports names only <= 8 chars, I have to go through a lot of work to port. But if I can stuff the longer names into a pathname legally, then a can merely wrap my file-system interface (e.g., a call to open) with code that would convert my pathname into a pathname that this system could handle (e.g., by using some of thje chars avail for the TYPE). The point I am trying to make is that pathnames really should be 100% implementation independent, including the contents of each of the components. There should be no limitations on the components (e.g., length of strings, length of lists, whether a list is allowed in this impl.) other than the conventions on pg. 412. It is the conversion of a pathname to a namestring (and vice versa) that should impose the limitations. And the standard should state that all pathnames are implicity converted to host-dependent namestings before actually being used in a file-system operation. The one significant change to the pathname conventions will have to be to the wording in the description of the conventions of the device, directory, and name: "...can each be a string (with host dependent rules on allowed characters and length) or possibly some other Common Lisp data structure)..." This would have to be changed to remove the wording about "host dependent rules" (remember, these rules should only come into play when converting to a namestring) and to flush the legality of "some other CL data structure". Whats wrong with just allowing strings, lists of strings, :wild, and nil? Does nayone use anything else already? Would it be that hard to switch to lists? Finally, it should be stated that what you assign to a pathname component is what you get back when you reference it, no implicit conversion or copying. This pretty much turns pathnames into merely organizers of information, they don't process what is assigned to them, they just store it. It is the process of converting to a namestring that processes the info, based on implementation independent info. -- Nick  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 23 Jun 86 11:25:38 EDT Received: from MIT-LIVE-OAK.ARPA by SU-AI.ARPA with TCP; 23 Jun 86 08:13:06 PDT Received: from GOLD-HILL-ACORN.DialNet.Symbolics.COM by MIT-LIVE-OAK.ARPA via DIAL with SMTP id 3026; 23 Jun 86 11:13:51-EDT Received: from BOSTON.Gold-Hill.DialNet.Symbolics.COM by ACORN.Gold-Hill.DialNet.Symbolics.COM via CHAOS with CHAOS-MAIL id 25300; Mon 23-Jun-86 11:13:34-EDT Date: Mon, 23 Jun 86 11:12 EST Sender: mike@a To: Dave.Touretzky@A.CS.CMU.EDU From: mike%gold-hill-acorn@mit-live-oak.arpa "Mike Beckerle" Subject: Re: Argument Lists Cc: common-lisp@SU-AI.ARPA Date: 22 Jun 86 22:01 EDT From: Dave.Touretzky@A.CS.CMU.EDU One compromise might be to include ARGUMENT-LIST in the language but specify that the argument lists of compiled functions may not be accessible. So people writing programmer's aids for handling interpreted code (as I have done) can still get the info they want without being forced to rip apart closure objects or SI:DIGESTED-LAMBDA forms. There should probably be a compiler declaration to force argument list info to be preserved (or thrown away), for applications like Brian Milnes' where you need the info in compiled code. The default fate of argument lists in compiled functions can be left up to the implementation. We should not compromise on number of args info though; that should be available for all functions, compiled or not. By the way, what will the convention be for indicating that a function has an &rest arg? I guess one could just return the value of call-arguments-limit. -- Dave Asking for the number of args at run time, or whether the function takes an &rest arg is asking for type information about functions. Someone else might want to know the number of results, or possibly the types of the arguments, etc. Common Lisp already has typing features which address these kinds of problems. For example, the type-of operation can be used for this purpose, i.e., why not do: (type-of (symbol-function 'foo)) and have it return the function type specifier, which might be: (function (t t &optional t &rest list) t) This could then be parsed to determine the number of args info, or any other available type info about the function. Requiring that number-of-args be available is tantamount to requiring type-of to always be able to return a function signature containing at least the right number of arguments. In other words, it is equivalent to asking that the type-of function be required to return alot more information than CLtL currently specifies. I think type-of should be required to return a function type specifier for function objects, and that the lambda list in the specifier must reflect the arity, as well as use of &key, &optional, &rest, etc. Argument-list should then be defined in terms of type-of. Note that since type-of returns a function type specifier instead of an actual lambda-list, there is no loss of abstraction here, i.e., only the type of each argument is shown, not the name of it. This may be a bug, since at the user-interface level, most use of arglist is to look at the names of the args to determine their order, not their type. Extending the function spec syntax is one way to fix this, i.e., (function ((the integer x) &optional ((the list foo) nil)) t) Also, number-of-args is quite ambiguous in the presence of &key, &optional, and &rest args, and would be especially troublesome with respect to macros, where nested lambda lists can be used. ...mike beckerle Gold Hill Computers  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 23 Jun 86 10:13:56 EDT Received: from SCRC-RIVERSIDE.ARPA by SU-AI.ARPA with TCP; 23 Jun 86 07:06:28 PDT Received: from FIREBIRD.SCRC.Symbolics.COM by RIVERSIDE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 27642; Mon 23-Jun-86 10:05:35 EDT Date: Mon, 23 Jun 86 10:03 EDT From: David C. Plummer Subject: Re: Namestring&pathstring returning shared structure To: Alan Snyder , Fahlman@C.CS.CMU.EDU cc: common-lisp@SU-AI.ARPA In-Reply-To: <8606222130.AA03808@hplsny> Message-ID: <860623100356.9.DCP@FIREBIRD.SCRC.Symbolics.COM> Date: Sunday, June 22, 1986 14:30:31 From: Alan Snyder CLU solved this problem by making STRING a different type than ARRAY of CHARACTER, and by making STRINGs immutable. We found having immutable STRINGs to be extremely useful: one can pass a string to a procedure or return it from a procedure without worrying that someone might destructively modify it! This idea was such a win that a later revision of CLU had both immutable and mutable arrays and immutable and mutable records. It must be a bitch to write an editor in CLU, or do you just implement lines as arrays of characters instead of as strings, thereby losing the textual benefit of debugging and having to write separate output routines to display these "strings"? Something to think about for Common Lisp 2000...  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 22 Jun 86 22:19:37 EDT Received: from A.CS.CMU.EDU by SU-AI.ARPA with TCP; 22 Jun 86 19:03:27 PDT Date: 22 Jun 86 22:01 EDT From: Dave.Touretzky@A.CS.CMU.EDU To: common-lisp@SU-AI.ARPA Subject: Re: Argument Lists In-Reply-To: <860622025257.9.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> One compromise might be to include ARGUMENT-LIST in the language but specify that the argument lists of compiled functions may not be accessible. So people writing programmer's aids for handling interpreted code (as I have done) can still get the info they want without being forced to rip apart closure objects or SI:DIGESTED-LAMBDA forms. There should probably be a compiler declaration to force argument list info to be preserved (or thrown away), for applications like Brian Milnes' where you need the info in compiled code. The default fate of argument lists in compiled functions can be left up to the implementation. We should not compromise on number of args info though; that should be available for all functions, compiled or not. By the way, what will the convention be for indicating that a function has an &rest arg? I guess one could just return the value of call-arguments-limit. -- Dave  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 22 Jun 86 22:04:36 EDT Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 22 Jun 86 17:30:08 PDT Received: ID ; Sun 22 Jun 86 20:30:13-EDT Date: Sun, 22 Jun 1986 20:30 EDT Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: SANDRA Cc: common-lisp@SU-AI.ARPA Subject: portability of pathnames In-reply-to: Msg of 29 May 1986 22:20-EDT from SANDRA I'm going through old mail to make a list of issues we need to settle, or at least work on. I came across your complaint about portability of pathnames and the problems with make-pathname. I was just wondering if you had anything specific to propose. If not, I'll just add this to the agenda of things we collectively need to think about, but I'm not sure there's a good solution to be had. -- Scott  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 22 Jun 86 21:59:18 EDT Received: from [192.10.41.41] by SU-AI.ARPA with TCP; 22 Jun 86 18:43:44 PDT Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 27337; Sun 22-Jun-86 02:55:46 EDT Date: Sun, 22 Jun 86 02:52 EDT From: Kent M Pitman Subject: Argument Lists To: Fahlman@C.CS.CMU.EDU cc: KMP@SCRC-STONY-BROOK.ARPA, COMMON-LISP@SU-AI.ARPA References: Message-ID: <860622025257.9.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> About 20% of the 10000 symbols in MACSYMA have have no function cell, value, or properties. The average length of those symbols' names is 7.33. Some are probably used as constants within programs, including plist indicators and catch tags, but I can't believe that all of them are. I'm more inclined to believe that most of these are arguments to functions and other variables (eg, for LET, PROG, etc) which are being retained for debugging. Sometime when I have more time, maybe I'll try to track down more details. Symbolics have no real problem with retaining such information on the 3600, but I'm not sure what the cost/benefit trade-off is of requiring that this information be retained in implementations that are tighter on address space. Also, I should mention that MACSYMA wants to be able to detect the maximum and minimum number of arguments a function takes, but doesn't really have a lot of important uses for the whole argument list. The only real argument I can think of for anyone wanting the actual argument list is as a user-interface/self-documentation feature, which is an issue that may be best left up to individual systems. I expect that some people will disagree with this, though. Personally, I think that ARGLIST is something of an abstraction violation when used in some of the ways that I've seen it used, because it exposes the names the user was using internally and in some cases that may reveal artifacts of the implementation which ought not be revealed for reasons either of abstraction or proprietariness or both. Of course, APROPOS is in the same boat, so I won't suggest there's no precedent for such operations in CL. There's also a question of how fast ARGLIST wants to be. Some implementations may have to cons this back up, but some users may be wanting something that's fast enough to use as a check before actually trying to apply a function in order to head off wrong-number-of-arguments errors before they happen. The latter application may not be happy with the speed required to cons an arglist. Having more than one function to get these two things would seem better than having one sledge-hammer that always computes twice as much info as it needs to and then makes you throw half of that information away. Storing ARGLIST information out of core would reduce the size requirement, but would likely make it unacceptably slow for any kind of number-of-args checking. Also, unlike documentation strings which you can simply drop the pointers to when you're done using them, symbols that were in the arglist read from an out-of-core file would continue to be interned unless you explicitly uninterned them, and you can't do that very safely unless you know for sure the symbol hadn't been interned prior to the call to ARGLIST. So over time, you'd end up accumulating all the information in core in a non-GC-able way. Maybe that would be OK, but it's worth thinking carefully about to be sure. Personally, I think something that computes minimum/maximum number of arguments should be put into the language. I'll defer any recommendation about something which gets the ARGLIST itself until I've thought harder about the implications. If ARGLIST is put in, it should probably be under the name ARGUMENT-LIST.  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 22 Jun 86 17:38:28 EDT Received: from HPLABS.HP.COM by SU-AI.ARPA with TCP; 22 Jun 86 14:31:43 PDT Received: from hplsny by hplabs.HP.COM ; Sun, 22 Jun 86 14:30:45 pdt Received: by hplsny ; Sun, 22 Jun 86 14:30:39 pdt From: Alan Snyder Message-Id: <8606222130.AA03808@hplsny> Date: Sunday, June 22, 1986 14:30:31 Subject: Re: Namestring&pathstring returning shared structure To: Fahlman@C.CS.CMU.EDU Cc: common-lisp@su-ai.ARPA In-Reply-To: Your message of 21-Jun-86 12:41:00 X-Sent-By-Nmail-Version: 04-Nov-84 17:14:46 CLU solved this problem by making STRING a different type than ARRAY of CHARACTER, and by making STRINGs immutable. We found having immutable STRINGs to be extremely useful: one can pass a string to a procedure or return it from a procedure without worrying that someone might destructively modify it! This idea was such a win that a later revision of CLU had both immutable and mutable arrays and immutable and mutable records. Something to think about for Common Lisp 2000... Alan -------  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 21 Jun 86 23:08:22 EDT Received: from BBNG.ARPA by SU-AI.ARPA with TCP; 21 Jun 86 20:00:30 PDT Date: 21 Jun 1986 22:59-EDT Sender: NGALL@G.BBN.COM Subject: Re: Namestring&pathstring returning shared structure From: NGALL@G.BBN.COM To: Fahlman@C.CS.CMU.EDU Cc: masinter.PARC@XEROX.COM, COMMON-LISP@SU-AI.ARPA Message-ID: <[G.BBN.COM]21-Jun-86 22:59:24.NGALL> In-Reply-To: Date: Sat, 21 Jun 1986 12:41 EDT From: "Scott E. Fahlman" To: masinter.PARC@XEROX.COM Subject: Namestring&pathstring returning shared structure Message-ID: Signaling an error or doing a copy when someone destructively modifies the string for a symbol's name is a pain. If there's a problem here, we should simply make sure the user never gets his hands on such a string by copying on the way in and copying again on the way out. However, I'm not convinced that there's a problem here, except that the manual does not state clearly enough that this string is shared, registered in a hash table, and should not be messed with. Are people really in danger of screwing themselves here? -- Scott -------------------- I agree that all that is needed is more clarity in the manual as to which functions are guaranteed to return unshared structures, which functions return shared structures, and which functions for which the sharability of the object returned is undefined. I think I may have misled people into thinking that I was only worried about the interaction of pathnames and symbol-names. I was just using it as an example on implicit sharing (one that caused me a lot of grief in porting to KCL). But there are many other examples of possible character sharing between strings (e.g., string-trim, parse-namestring, package-name, intern, etc.). Implementations such as KCL, which use separate string headers and bodies (which are just raw sequences of chars.) will typically just create a new string header which points into an existing string body whenever possible. Unless the user knows when to be on the alert for this, s/he will eventually come to grief. -- Nick  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 21 Jun 86 23:03:00 EDT Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 21 Jun 86 19:55:01 PDT Received: ID ; Sat 21 Jun 86 22:54:48-EDT Date: Sat, 21 Jun 1986 22:54 EDT Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: MILNES%cgi.csnet@CSNET-RELAY.ARPA Cc: common-lisp@SU-AI.ARPA Subject: Argument Lists In-reply-to: Msg of Wed 18 Jun 86 19:17 ??? from MILNES%cgi.csnet at CSNET-RELAY.ARPA In response to your request for a portable Common Lisp facility to access any function's argument list and also its minimum and maximum arg counts: I think that the overwhelming majority of implementations provide some sort of function for accessing the argument list. The names that the user gave to the arguments can be a very useful form of automatic documentation, so this info is just too valuable not to make available in some form at runtime. I'm sure that if we took a poll, however, we would find many different formats in use for reporting this information. For example, do we return the original arglist, with all of the default-argument forms in place, or just the variable names and which ones are optional, rest, etc. I think that it would be valuable to agree on the format for reporting the arglist and include it in the language as a standard or semi-standard facility so that we can all use it in the same way on various machines and so that code can make use of this. (Various help systems would make good use of this info.) We might want to make this a "semi-standard" feature, meaning that it is optional, but do it this way if you do it at all, since very small implementations might not want to pay the price to keep this info around at runtime. Then again, we added docuemntation strings as a required facility and nobody complained -- these are kept outside the Lisp in a separate file in some implementations, and the arglist info could be kept there as well. Every implementation has some way of determining at runtime the minimum and maximum argument counts for a function, so functions to report these could be added at very little cost. These, too, would be useful, though you could derive this from the arglist info if you had to. -- Scott  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 21 Jun 86 21:06:45 EDT Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 21 Jun 86 17:53:15 PDT Received: ID ; Sat 21 Jun 86 20:53:12-EDT Date: Sat, 21 Jun 1986 20:53 EDT Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: "Hiroshi G. Okuno" Cc: common-lisp@SU-AI.ARPA Subject: negative index for the sequence In-reply-to: Msg of 21 Jun 1986 03:27-EDT from Hiroshi G. Okuno I find the use of negative indices to mean "count backward from the end of the sequence" is very confusing, especially in the Common Lisp sequence functions, may of which already have a :FROM-END option and other complexities. This wouldn't be so bad in SUBSEQ alone, but then it would make that function different from all the others in how it handles indices. Maybe this convention works well in TAO, but I don't think it would work well in Common Lisp. -- Scott  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 21 Jun 86 16:43:12 EDT Received: from [192.10.41.41] by SU-AI.ARPA with TCP; 21 Jun 86 13:36:17 PDT Received: from CHICOPEE.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 26595; Fri 20-Jun-86 10:34:25 EDT Date: Fri, 20 Jun 86 10:37 EDT From: Daniel L. Weinreb Subject: Re: Why aren't char bits portable? To: Masinter.pa@XEROX.ARPA, common-lisp@SU-AI.ARPA In-Reply-To: <860619-123848-1153@Xerox> Message-ID: <860620103733.1.DLW@CHICOPEE.SCRC.Symbolics.COM> I agree with everything you say in your message, except that I would modify the conclusion somewhat. I believe that the intent of including "bits" in the standard is to allow for the fact that some of the "bits" are gaining some amount of currency as ad hoc standards. In particular, there are now several terminals on the market that have a "Meta" key, which is used by many Emacs-family editors. (The Ann Arbor Ambassador and the Teleray something (2000?) come to mind.) A program that wants to be universally portable, of course, cannot depend on the presence of such key on the user's keyboard. However, it is not hard to imagine a program that wants to be portable, but also wants to allow any user who has a Meta key to take advantage of it. (Indeed, many Emacs-family editors have this property.) I believe the intention of the "bits" feature was to help out such programs. While I'm not sure that all the details of the "bits" feature in the standard are ideal, nevertheless I wanted to point out that the entire feature is not necessarily bankrupt.  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 21 Jun 86 12:47:56 EDT Received: from SUMEX-AIM.ARPA by SU-AI.ARPA with TCP; 21 Jun 86 09:42:23 PDT Date: Sat 21 Jun 86 09:36:00-PDT From: Hiroshi G. Okuno Subject: negative index for the sequence (correction) To: Okuno@SUMEX-AIM.ARPA, gls@ZARATHUSTRA.THINK.COM cc: common-lisp@SU-AI.ARPA In-Reply-To: <12216516165.13.OKUNO@SUMEX-AIM.ARPA> Message-ID: <12216616005.17.OKUNO@SUMEX-AIM.ARPA> My original message contains a bug. The sentence > Of course, if the non-negative index which corresponds to a negative one > exceeds the bound of the sequence, an error is signalled. should read If (abs ) is out-of-range, an error is signalled. Thanks, - Gitchang - -------  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 21 Jun 86 12:47:00 EDT Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 21 Jun 86 09:41:33 PDT Received: ID ; Sat 21 Jun 86 12:41:36-EDT Date: Sat, 21 Jun 1986 12:41 EDT Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: masinter.PARC@XEROX.COM Cc: COMMON-LISP@SU-AI.ARPA Subject: Namestring&pathstring returning shared structure Signaling an error or doing a copy when someone destructively modifies the string for a symbol's name is a pain. If there's a problem here, we should simply make sure the user never gets his hands on such a string by copying on the way in and copying again on the way out. However, I'm not convinced that there's a problem here, except that the manual does not state clearly enough that this string is shared, registered in a hash table, and should not be messed with. Are people really in danger of screwing themselves here? -- Scott  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 21 Jun 86 04:14:26 EDT Received: from CS.UCL.AC.UK by SU-AI.ARPA with TCP; 21 Jun 86 01:07:33 PDT Received: from aiva.edinburgh.ac.uk by 44d.Cs.Ucl.AC.UK via Janet with NIFTP id a000440; 20 Jun 86 18:35 BST From: Jeff Dalton Date: Fri, 20 Jun 86 18:33:54 -0100 Message-Id: <3983.8606201733@aiva.ed.ac.uk> To: Fahlman@c.cs.cmu.edu, jeff <@Cs.Ucl.AC.UK:jeff@aiva.edinburgh.ac.uk> Subject: Re: Common LISP meeting at Lisp Conference Cc: common-lisp@su-ai.arpa Date: Thu, 19 Jun 1986 19:53 EDT From: "Scott E. Fahlman" There was talk of a Common Lisp meeting at the Lisp Conference. We don't currently plan to have a general session on Common Lisp at the Lisp conference, though there will be some assorted Common Lisp activities happening there, probably including a meeting on object-oriented facilities. Good. I would also like to mention that the August EuLisp meeting is going to take place in Boston during the conference: Date: Tue, 17 Jun 86 11:17:12 bst From: jap To: eulisp@uucp.inria I sent off a message to Bert Halstead (cc'ed to Bob Mathis) about trying to arrange a room for a meeting for those interested in LISP standardisation. That was passed to Richard Gabriel, who contacted me yesterday. He is keen that there should be some meeting where our working group and the assorted CL folks can get together. I have suggested the Tuesday evening as being the best time. I think it's important that the different groups interested in standard- ization have a chance to talk directly, especially since the overlap between the two mailing lists is not that great. -- Jeff  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 21 Jun 86 03:39:22 EDT Received: from SUMEX-AIM.ARPA by SU-AI.ARPA with TCP; 21 Jun 86 00:29:44 PDT Date: Sat 21 Jun 86 00:27:34-PDT From: Hiroshi G. Okuno Subject: negative index for the sequence To: gls@ZARATHUSTRA.THINK.COM cc: common-lisp@SU-AI.ARPA In-Reply-To: <860619212728.1.GLS@THORLAC.THINK.COM> Message-ID: <12216516165.13.OKUNO@SUMEX-AIM.ARPA> > Well, SUBSEQ must check the length if it is defined to SIGNAL an error for > an out-of-bound index. > > --Guy If the length check is performed in SUBSEQ, a negative index may be considered as a convention of -n == (- (length ) n) where n > 0. For example, (subseq #(a b c d e) -3 -1) = (subseq #(a b c d e) 2 4) = #(c d e) Of course, if the non-negative index which corresponds to a negative one exceeds the bound of the sequence, an error is signalled. This convention is very useful for string manipulations. In fact, a negative index is supported in TAO and used extensively in a kana-kanji conversion programs. - Gitchang - -------  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 21 Jun 86 00:58:36 EDT Received: from XEROX.COM by SU-AI.ARPA with TCP; 20 Jun 86 21:53:00 PDT Received: from Burger.ms by ArpaGateway.ms ; 20 JUN 86 21:53:01 PDT Sender: "Larry_Masinter.PARC"@Xerox.COM Date: 20 Jun 86 21:52:46 PDT (Friday) Subject: Re: Namestring&pathstring returning shared structure From: masinter.PARC@Xerox.COM To: Rem@IMSSS.Arpa cc: COMMON-LISP@SU-AI.Arpa In-Reply-to: Rem%IMSSS:ARPA's message of Friday, June 20, 1986 1:41 pm Reply-to: masinter.PARC@Xerox.COM Message-ID: <860620-215301-1126@Xerox> From as early as 1972, Interlisp in all implementations performed "copy on write for substrings of pnames". This required neither BIBOP or page tables or tag bits. This is one "is an error" condition that is fairly painful: it isn't determinable by even the most careful amount of flow analysis, much less a simple syntactic check. To change "it is an error to destructively modify the pname of a symbol", it is necessary to either introduce copy-on-write or else change it to "signals an error". If the former is controversial, would you accept the latter?  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 21 Jun 86 00:31:46 EDT Received: from SU-GLACIER.ARPA by SU-AI.ARPA with TCP; 20 Jun 86 21:26:15 PDT Received: by su-glacier.arpa with Sendmail; Fri, 20 Jun 86 21:26:08 pdt Received: from pachyderm.UUCP (pachyderm.ARPA) by mips.UUCP (4.12/4.7) id AA11371; Fri, 20 Jun 86 18:25:31 pdt Received: by pachyderm.UUCP (4.12/4.7) id AA12833; Fri, 20 Jun 86 18:15:25 pdt Date: Fri, 20 Jun 86 18:15:25 pdt From: mips!pachyderm.earl@su-glacier.arpa (Earl Killian) Message-Id: <8606210115.AA12833@pachyderm.UUCP> To: glacier!LOOSEMORE@UTAH-20.ARPA Cc: common-lisp@SU-AI.ARPA In-Reply-To: SANDRA's message of Fri 20 Jun 86 10:31:15-MDT Subject: require I certainly hope that REQUIRE does something at compile time. The whole purpose of REQUIRE was to make exactly this sort of thing painless.  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 20 Jun 86 23:11:27 EDT Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 20 Jun 86 20:04:16 PDT Received: ID ; Fri 20 Jun 86 23:03:40-EDT Date: Fri, 20 Jun 1986 23:03 EDT Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: NGALL@BBNG.ARPA Cc: common-lisp@SU-AI.ARPA Subject: defconstant In-reply-to: Msg of 20 Jun 1986 22:29-EDT from NGALL at G.BBN.COM I agree with Nick's analysis. A reference to a constant may be compiled as a variable reference or the value of the constant at compile time may be wired into the code, but if the latter is done, this should not depend on the constant having been initialized at load time. I agree that the manual is too vague on this point, and should be clarified. I suspect that KCL handles Defconstant this way in order to optimize the use of lists as constants, while still observing the requirement that all references to the constant must be EQL to one another, but this is a very tricky business and is probably not worth the trouble it takes to get it right. -- Scott  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 20 Jun 86 22:38:06 EDT Received: from BBNG.ARPA by SU-AI.ARPA with TCP; 20 Jun 86 19:30:31 PDT Date: 20 Jun 1986 22:29-EDT Sender: NGALL@G.BBN.COM Subject: defconstant From: NGALL@G.BBN.COM To: common-lisp@SU-AI.ARPA Message-ID: <[G.BBN.COM]20-Jun-86 22:29:37.NGALL> Consider the following: File foo contains: (defconstant const ...) ... File bar contains: (defun zap (x) ... (reference const x) ...) Now suppose that I compile file bar in an environment in which I have already loaded foo. Thus the compiler will recognize that the reference to const in zap is a reference of a constant. In some implementations, the value of const will be substituted for const. In others, const may be treated like any other special variable. But how about an implementation that does the following: It substitutes a reference to a slot in the compiled function's "constant vector" (i.e., the piece of data where most implementations store constant values). BUT it does not init the slot at compile time (like most implementations), instead, it generates code that will init. the slot to the value that const has at load time! Thus, if I loaded bar before loading foo, I will cause an error, since const is undefined at the time bar is loaded. My questions are: Is this a legal implemenation of defconstant? If not, how does CLtL forbid it? In my opinion, it is not legal CL. I base this on the fact that defconstant, like defvar and defparameter, defines a variable (albeit one which about which the compiler may make assumptions). And nowhere in CLtL does it state that it is an error to load a piece of code that conatains a reference of a variable that is unbound at load time. CLtL only requires that the varibable have a value at the moment the reference is evaluated. The only argument in favor of considering such behavior legal would be based on the statement "defconstant ... [asserts] that the value of the variable NAME is fixed" One could argue that the value of the variable at compile time was different from the value at load time (i.e., the value UNBOUND), and thus the assertion has been contradicted. What do you think? By the way, thre does exist such an implementation: KCL. -- Nick  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 20 Jun 86 17:50:51 EDT Received: from HPLABS.HP.COM by SU-AI.ARPA with TCP; 20 Jun 86 14:40:32 PDT Received: from hplsny by hplabs.HP.COM ; Fri, 20 Jun 86 14:39:03 pdt Received: by hplsny ; Fri, 20 Jun 86 14:38:59 pdt From: Alan Snyder Message-Id: <8606202138.AA03317@hplsny> Date: Friday, June 20, 1986 14:38:52 Subject: Re: require To: LOOSEMORE@UTAH-20.ARPA Cc: common-lisp@su-ai.ARPA In-Reply-To: Your message of 20-Jun-86 10:31:15 X-Sent-By-Nmail-Version: 04-Nov-84 17:14:46 Consider the following piece of code: (in-package 'me) (require 'foo) ; Module FOO creates package FOO (foo:some-function) There is nothing wrong with this when you run it through the interpreter, but it dies when you try to compile it. Why? Because the call to REQUIRE doesn't get evaluated at compile time, thus module FOO doesn't get loaded, package FOO isn't created and SOME-FUNCTION isn't made an external symbol. The manual has taken some pains to describe how you should order the calls to set up the package environment and load various modules at the beginning of each file, but it doesn't seem to interact with the compiler very well. Your example demonstrates why REQUIRE should implicitly be evaluated by the compiler. I believe one can also deduce this fact from the examples in the chapter on packages (assuming them to be compilable), but it is not stated explicitly in the definition. Making REQUIRE so it is always implicitly (eval-when (eval compile load)...) would solve the problem, but this would create problems, too. I have at least one utility where I want one module loaded at compile time to provide definitions for some rather hairy macros, and another (much smaller) module around at load time which contains a few functions for runtime support. It would be nice if (EVAL-WHEN (EVAL LOAD) (REQUIRE ...)) did the trick, but unfortunately EVAL-WHEN has been explicitly defined NOT to be able turn off implicit compile-time evaluation. I believe that it should do this, and argued so a long time ago. Alan -------  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 20 Jun 86 15:39:59 EDT Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 20 Jun 86 12:23:59 PDT Received: ID ; Fri 20 Jun 86 15:23:47-EDT Date: Fri, 20 Jun 1986 15:23 EDT Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: COMMON-LISP@SU-AI.ARPA Subject: Namestring&pathstring returning shared structure In-reply-to: Msg of 20 Jun 1986 15:05-EDT from Rem at IMSSS In reply to: Rem at IMSSS Putting in a copy-on-modify facility is much too radical a change to deal with this particular problem. We will clarify the document. -- Scott  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 20 Jun 86 15:27:38 EDT Received: from IMSSS by SU-AI with PUP; 20-Jun-86 12:10 PDT Date: 20 Jun 1986 1205-PDT From: Rem@IMSSS Subject: Namestring&pathstring returning shared structure To: COMMON-LISP@SU-AI It seems to me that the user needs some way to know whether a string is being shared or not, so he/she can copy it before modifying it if it is being shared and avoid the extra copy if it has already been copied. Alternately the CL system should perform copy-on-modify automatically to avoid the programmer having to make this decision. Thus either make the manual more precise so it says exactly which functions work in place and which make copies (this may be too restrictive), or implement some kind of readonly memory i.e. copy-on-write. Many machines don't have a way to do this in hardware (trapping on modify, causing LISP to punt and copy first then try the modify again), but this could be done within the tagged or paged LISP architecture. In a tagged system such as PSL, simply have two different tags on string-pointers, one that is normal, and one that is DON'T EVER MODIFY THIS IN PLACE. The string-modifying operations would discriminate between these two tags, whereas normal string stuff would just accept both as strings and pass the tag along when building into structure. In a paged system such as BIBOP, readonly strings could be on special pages. Are there any CL implementations which don't use BIBOP nor a tagged architecture, where there is no obvious method for protecting PNAMEs against accidental modification in place? -------  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 20 Jun 86 12:43:36 EDT Received: from UTAH-20.ARPA by SU-AI.ARPA with TCP; 20 Jun 86 09:32:41 PDT Date: Fri 20 Jun 86 10:31:15-MDT From: SANDRA Subject: require To: common-lisp@SU-AI.ARPA Message-ID: <12216352996.24.LOOSEMORE@UTAH-20.ARPA> Consider the following piece of code: (in-package 'me) (require 'foo) ; Module FOO creates package FOO (foo:some-function) There is nothing wrong with this when you run it through the interpreter, but it dies when you try to compile it. Why? Because the call to REQUIRE doesn't get evaluated at compile time, thus module FOO doesn't get loaded, package FOO isn't created and SOME-FUNCTION isn't made an external symbol. The manual has taken some pains to describe how you should order the calls to set up the package environment and load various modules at the beginning of each file, but it doesn't seem to interact with the compiler very well. Making REQUIRE so it is always implicitly (eval-when (eval compile load)...) would solve the problem, but this would create problems, too. I have at least one utility where I want one module loaded at compile time to provide definitions for some rather hairy macros, and another (much smaller) module around at load time which contains a few functions for runtime support. I'm inclined to think that this is another manifestation of fundamental defects in the package system, combined with general vagueness on what kind of processing goes on at compile time. Unfortunately, I don't really have any good solutions for either problem. It seems like what we really need is some mechanism to declare that REQUIRE and various other defining forms (like DEFSTRUCT, DEFTYPE, DEFMACRO, etc.) should be evaluated at compile time, *unless* you specify otherwise. Or, maybe a "defenvironment" construct to take the place of random function calls to set up the package system and miscellaneous environment. -Sandra Loosemore -------  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 20 Jun 86 06:39:01 EDT Received: from REAGAN.AI.MIT.EDU by SU-AI.ARPA with TCP; 19 Jun 86 23:45:50 PDT Received: from DUANE.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 37144; Fri 20-Jun-86 02:46:35-EDT Date: Fri, 20 Jun 86 02:45 EDT From: Christopher Fry Subject: Achieving portability, how? To: COMMON-LISP@SU-AI.ARPA In-Reply-To: The message of 18 Jun 86 12:03-EDT from Rem@IMSSS Message-ID: <860620024525.9.CFRY@DUANE.AI.MIT.EDU> There seem to be several ways to achieve portability: ... (3) Provide tools for examining the text (source) of a program and reporting any non-portable syntax. These tools could be used anywhere. Agreed, no matter what else is decided. Nice candidate for the yellow pages. It could check each function call to a valid CL fn that you were passing a correct number of args to it as well. That would go a long way to catching those calls to CL fns where an implementation added that addition &optional arg which is illegal.  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 20 Jun 86 06:15:50 EDT Received: from REAGAN.AI.MIT.EDU by SU-AI.ARPA with TCP; 19 Jun 86 23:44:10 PDT Received: from DUANE.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 37142; Fri 20-Jun-86 02:45:00-EDT Date: Fri, 20 Jun 86 02:43 EDT From: Christopher Fry Subject: Achieving portability, how? To: Rem@IMSSS, COMMON-LISP@SU-AI.ARPA In-Reply-To: The message of 18 Jun 86 12:03-EDT from Rem@IMSSS Message-ID: <860620024352.8.CFRY@DUANE.AI.MIT.EDU> There seem to be several ways to achieve portability: (3) Provide tools for examining the text (source) of a program and reporting any non-portable syntax. These tools could be used anywhere. Agreed, no matter what else is decided. Nice candidate for the yellow pages. It could check each function call to a valid CL fn that you were passing a correct number of args to it as well. That would go a long way to catching those calls to CL fns where an implementation added that addition &optional arg which is illegal.  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 20 Jun 86 05:41:20 EDT Received: from REAGAN.AI.MIT.EDU by SU-AI.ARPA with TCP; 19 Jun 86 23:38:31 PDT Received: from DUANE.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 37141; Fri 20-Jun-86 02:39:22-EDT Date: Fri, 20 Jun 86 02:38 EDT From: Christopher Fry Subject: Argument Lists To: MILNES%cgi.csnet@CSNET-RELAY.ARPA, common-lisp@SU-AI.ARPA In-Reply-To: The message from MILNES%cgi.csnet@CSNET-RELAY.ARPA Message-ID: <860620023813.7.CFRY@DUANE.AI.MIT.EDU> From: Brian Milnes @cgi.csnet.com We here at CGI have run into several cases where we would like to be able to access the argument list format for functions and macros in a system independent manner. The symbolics and the TI support a function arglist which returns the lambda list for a function; we are using this to provide a command like ctr-A, which describes a functions argument list, in Knowledge Craft. I also would like a Common Lisp way of determining the minimum and maximum number of arguments taken by a given function; ARGLIST gives you info about &optional, &rest and keyword args from which you can get min and max arg count if you want it. Have we missed this functionality in CLtL ? Do others of you out there miss this functionality ? Could it be simply and safely added to CL ? I vote for adding arglist, but not minimum-args and maximum-args, though I have to admit I've had to write that functionality myself.  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 20 Jun 86 05:40:47 EDT Received: from [192.10.41.41] by SU-AI.ARPA with TCP; 19 Jun 86 23:28:05 PDT Received: from EUPHRATES.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 26471; Fri 20-Jun-86 02:27:13 EDT Date: Fri, 20 Jun 86 02:26 EDT From: David A. Moon Subject: packages and portability To: common-lisp@SU-AI.ARPA In-Reply-To: <8606161358.AA08975@decwrl.DEC.COM> Message-ID: <860620022603.4.MOON@EUPHRATES.SCRC.Symbolics.COM> I don't have anything to add to this discussion, other than to mention that what Symbolics does is essentially identical to what Ugo Buy described in his message of 16 June, except that the default value for the :USE argument to MAKE-PACKAGE and IN-PACKAGE is as documented in CLtL. LISP is a nickname on the package named COMMON-LISP. The package containing our extended version of Common Lisp is named SYMBOLICS-COMMON-LISP, the same as the name of the language it implements except in all upper case.  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 20 Jun 86 05:04:00 EDT Received: from GODOT.THINK.COM by SU-AI.ARPA with TCP; 19 Jun 86 18:58:38 PDT Received: from thorlac by Godot.Think.COM via CHAOS; Thu, 19 Jun 86 21:26:12 edt Date: Thu, 19 Jun 86 21:27 EDT From: Guy Steele Subject: out-of-range subsequences To: Dave.Touretzky@A.CS.CMU.EDU, common-lisp@SU-AI.ARPA Cc: gls@AQUINAS In-Reply-To: <8606190724.AA13736@Zarathustra.Think.COM> Message-Id: <860619212728.1.GLS@THORLAC.THINK.COM> Date: 18 Jun 86 17:57 EDT From: Dave.Touretzky@A.CS.CMU.EDU Watch me ride on both sides of the fence here. I think (SUBSEQ s x y) should only return an error if x<0 or y<0. I see no reason to force an expression like (SUBSEQ #(a b c) 0 9) to return an error when it could return a perfectly useful value instead. There are lots of cases for lots of functions where one could dream up a "perfectly useful value" to return in a currently erroneous situation. For example, inasmuch as (CAR 'NIL) = (CDR 'NIL) = NIL, maybe we should define (CAR 9) = (CDR 9) = 9. (Or perhaps (CAR 9) = 1 and (CDR 9) = 4.) If we were to define (SUBSEQ #(a b c) 1 9) to be #(b c), then I don't see why we should restrict the indices to be non-negative: why not (SUBSEQ #(a b c) -9 2) = #(a b) as well? Here are two more arguments against returning an error. First, whether or not SUBSEQ returns an error, it still has to check the length of the sequence in order to do the right thing. So if we force the user to write (SUBSEQ x 0 (min 5 (length x))) the length gets checked twice: once by the user code, and once by SUBSEQ. This seems wasteful. Well, SUBSEQ must check the length if it is defined to SIGNAL an error for an out-of-bound index. If we only require that an out-of-bound index IS an error, then no check is required in principle (although an implementation may make such a check in practice). The second argument is that for lists, there is already precedent for permitting out of range indexing, e.g. (NTH '(a b c) 7) returns NIL rather than an error. I don't object to ELT returning an error in this case because there's no more natural thing to do in the case of vectors. (Consing up an returning a new empty vector would be a dumb idea.) But in the case of SUBSEQ there is a perfectly good behavior, namely, return as much of the sequence as actually exists. The behavior of NTH is a "natural" consequence of (CAR NIL) = (CDR NIL) = NIL. The index for NTH must be non-negative, says the spec. -- Dave --Guy  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 20 Jun 86 04:52:00 EDT Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 19 Jun 86 16:53:48 PDT Received: ID ; Thu 19 Jun 86 19:53:18-EDT Date: Thu, 19 Jun 1986 19:53 EDT Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: Jeff Dalton Cc: common-lisp@SU-AI.ARPA Subject: Common LISP meeting at AAAI In-reply-to: Msg of Wed 18 Jun 86 12:32:52 -0100 from Jeff Dalton There was talk of a Common Lisp meeting at the Lisp Conference. We don't currently plan to have a general session on Common Lisp at the Lisp conference, though there will be some assorted Common Lisp activities happening there, probably including a meeting on object-oriented facilities. As far as I know, there has have never been any plans for Common Lisp activities at the AAAI conference in Philly, except for the usual trade show. Any indication to the contrary was probably a typo. -- Scott  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 19 Jun 86 17:46:56 EDT Received: from CS.UCL.AC.UK by SU-AI.ARPA with TCP; 19 Jun 86 14:37:48 PDT Received: from aiva.edinburgh.ac.uk by 44d.Cs.Ucl.AC.UK via Janet with NIFTP id a004652; 18 Jun 86 18:18 BST From: Jeff Dalton Date: Wed, 18 Jun 86 12:32:52 -0100 Message-Id: <8625.8606181132@aiva.ed.ac.uk> To: BRANDON@ibm.com, Fahlman@c.cs.cmu.edu Subject: Re: Common LISP meeting at AAAI Cc: common-lisp@su-ai.arpa I'm confused. Are we talking about a meeting at AAAI or at the Lisp conference? I was planning to attend only the former.  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 19 Jun 86 16:50:16 EDT Received: from [192.10.41.41] by SU-AI.ARPA with TCP; 19 Jun 86 08:37:52 PDT Received: from CHICOPEE.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 25649; Thu 19-Jun-86 11:32:20 EDT Date: Thu, 19 Jun 86 11:35 EDT From: Daniel L. Weinreb Subject: (MAKE-BROADCAST-STREAM) To: KMP@STONY-BROOK.SCRC.Symbolics.COM cc: COMMON-LISP@SU-AI.ARPA In-Reply-To: <860619030046.6.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> Message-ID: <860619113522.4.DLW@CHICOPEE.SCRC.Symbolics.COM> Date: Thu, 19 Jun 86 03:00 EDT From: Kent M Pitman ... reminds me, though. I wouldn't mind it if CL offered COPY-STRING and maybe even COPY-CONS -- again for the sake of perspicuity. I believe that the intention was that COPY-SEQ was sufficiently perspicuous for copying strings. I presume it was assumed that COPY-LIST and COPY-TREE were what people needed the most often, and COPY-CONS wasn't something that would be needed so often to justify specific inclusion of such a function given that it's easy to write yourself. (A lot of value judgements, about which things would be sufficiently useful to so many people that having it pre-included in the language, had to be made during the design of the language; naturally there's no single right answer in any particular case.)  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 19 Jun 86 16:49:48 EDT Received: from [192.10.41.41] by SU-AI.ARPA with TCP; 19 Jun 86 08:24:17 PDT Received: from CHICOPEE.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 25632; Thu 19-Jun-86 11:22:27 EDT Date: Thu, 19 Jun 86 11:25 EDT From: Daniel L. Weinreb Subject: out-of-range subsequences To: Dave.Touretzky@CMU-CS-A.ARPA, common-lisp@SU-AI.ARPA In-Reply-To: The message of 18 Jun 86 17:57 EDT from Dave.Touretzky@A.CS.CMU.EDU Message-ID: <860619112526.2.DLW@CHICOPEE.SCRC.Symbolics.COM> Date: 18 Jun 86 17:57 EDT From: Dave.Touretzky@A.CS.CMU.EDU I think (SUBSEQ s x y) should only return an error if x<0 or y<0. I see no reason to force an expression like (SUBSEQ #(a b c) 0 9) to return an error when it could return a perfectly useful value instead. To take a simple function and then make its definition inconsistent with the spirit of the language, just to squeeze in an extra feature, is the way to make the language inconsistent and hard to learn. Here are two more arguments against returning an error. First, whether or not SUBSEQ returns an error, it still has to check the length of the sequence in order to do the right thing. So if we force the user to write (SUBSEQ x 0 (min 5 (length x))) the length gets checked twice: once by the user code, and once by SUBSEQ. This seems wasteful. To take a simple function and then make its definition inconsistent with the spirit of the language, just to save a few microseconds, is another way to make the language inconsistent and hard to learn. The second argument is that for lists, there is already precedent for permitting out of range indexing, e.g. (NTH '(a b c) 7) returns NIL rather than an error. But there is no such precedent for arrays, nor for sequences in general. NTH, unfortunately, needs to behave that way for consistency, on the grounds that one would expect that NTH could be defined the obvious way using CAR and CDR, and CAR and CDR both return NIL when given NIL. (Indeed, the whole business of CAR of NIL was one of those features shoehorned into the language for a little extra convenience, at the cost of consistency. As we used to say at MIT about TECO macros: "A moment of convenience; a lifetime of regret.")  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 19 Jun 86 16:49:29 EDT Received: from XEROX.COM by SU-AI.ARPA with TCP; 19 Jun 86 07:43:59 PDT Received: from Burger.ms by ArpaGateway.ms ; 19 JUN 86 07:29:10 PDT Sender: "Larry_Masinter.PARC"@Xerox.COM Date: 19 Jun 86 07:24:45 PDT (Thursday) Subject: Re: (MAKE-BROADCAST-STREAM) From: masinter.PARC@Xerox.COM To: KMP@SCRC-STONY-BROOK.Arpa cc: NGALL@G.BBN.COM, COMMON-LISP@SU-AI.Arpa, KMP@SCRC-STONY-BROOK.Arpa In-Reply-to: KMP%SCRC-STONY-BROOK:ARPA's message of Thursday, June 19, 1986 12:25 am Reply-to: masinter.PARC@Xerox.COM Message-ID: <860619-072910-1230@Xerox> *discard-output-stream* is more descriptive, even to those who are used to NUL: and /dev/nul/ and the like.  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 19 Jun 86 16:47:26 EDT Received: from [192.10.41.41] by SU-AI.ARPA with TCP; 19 Jun 86 00:02:58 PDT Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 25367; Thu 19-Jun-86 03:02:04 EDT Date: Thu, 19 Jun 86 03:00 EDT From: Kent M Pitman Subject: (MAKE-BROADCAST-STREAM) To: NGALL@G.BBN.COM cc: COMMON-LISP@SU-AI.ARPA, KMP@SCRC-STONY-BROOK.ARPA Message-ID: <860619030046.6.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> Calling (MAKE-BROADCAST-STREAM) to make a null output stream is about as perspicuous as doing (APPEND X '()) to COPY-LIST X... which may account for why I hadn't thought to do it. In spite of its grunginess, it does at least satisfy my need (if not my want). So perhaps we could still think about offering *NULL-OUTPUT-STREAM* or some such to free some people from the need to be so clever. ... reminds me, though. I wouldn't mind it if CL offered COPY-STRING and maybe even COPY-CONS -- again for the sake of perspicuity.  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 19 Jun 86 16:45:59 EDT Received: by kurims.kurims.kyoto-u.junet (2.0/6.1Junet) id AA00861; Tue, 17 Jun 86 19:27:09+0900 Date: Tue, 17 Jun 86 19:27:09+0900 Message-Id: <8606171027.AA00861@kurims.kurims.kyoto-u.junet> To: nttlab!Shasta!Fahlman@C.CS.CMU.EDU Subject: What are special forms? Cc: common-lisp@SU-AI.ARPA I have been worrying about what are meant by "special forms". CLtL defines, in Page 56, that If the first element (of a list form) is one of the symbols appearing in Table 5-1, then the list is called a /special form/. According to this definition, (SETQ X 1) is a special form but the symbol SETQ is not. Indeed, the caption of Table 5-1 (page 57) explicitly says that the table lists *Names* of Common Lisp special forms. Thus, SETQ certainly is a symbol that names special forms such as (SETQ X 1) and (SETQ). So far, so good. Right below Table 5-1, CLtL says The set of special forms is fixed .... This is still OK. The set of special forms consists of infinite number as its elements, but anyway it is fixed. However, in the next paragraph, it says The set of special forms is kept very small ... Small (!!!) an infinite set is ??? The sentense should rather be The set of special form names is kept very small ... The name SPECIAL-FORM-P enlarges such a kind of confusion between special forms and special form names. The name of the function should rather be SPECIAL-FORM-NAME-P or something like that. I am writing this message because I really got confused to read the following message. Date: Mon, 16 Jun 1986 22:52 EDT From: "Scott E. Fahlman" .... There's no such thing as a FEXPR in Common Lisp, though some implementations may use such a thing internally in implementing specia forms. I'll assume that you mean "special form" or "special operator" or whatever we are calling it. I think that Compiled-Function-P and Function-P should answer NIL for special forms. Does this mean, for example, (COMPILED-FUNCTION-P '(SETQ X 1)) => NIL (FUNCTION-P '(SETQ X 1)) => NIL or (COMPILED-FUNCTION-P (SPECIAL-FORM-P 'SETQ)) => NIL (FUNCTION-P (SPECIAL-FORM-P 'SETQ)) => NIL ? The latter interpretation seems to contradict CLtL, which says A returned non-NIL value (of SPECIAL-FORM-P) is typically a function of ... Incidentally, I would like to ask you what "globally" means in the following sentence in the CLtL description of SPECIAL-FORM-P in Page 91. If the symbol globally names a special form, .... I am sorry if there still is a sort of consensus in US Lisp people in this issue. But please keep it in mind that CLtL and common-lisp@su-ai are the only references to me. -- Taiichi  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 19 Jun 86 16:45:40 EDT Received: from SCRC-RIVERSIDE.ARPA by SU-AI.ARPA with TCP; 18 Jun 86 13:00:21 PDT Received: from CHICOPEE.SCRC.Symbolics.COM by RIVERSIDE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 25514; Wed 18-Jun-86 15:58:41 EDT Date: Wed, 18 Jun 86 16:01 EDT From: Daniel L. Weinreb Subject: Re: Out-of-range subsequences To: preece%ccvaxa@GSWD-VMS.ARPA, COMMON-LISP@SU-AI.ARPA In-Reply-To: <8606181414.AA11649@gswd-vms.ARPA> Message-ID: <860618160109.6.DLW@CHICOPEE.SCRC.Symbolics.COM> It's not a question of pickiness, but one of consistency. Common Lisp takes a uniform attitude about addressing outside the boundaries of an array, and all functions should follow the convention.  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 19 Jun 86 16:44:31 EDT Received: from seismo.CSS.GOV by SU-AI.ARPA with TCP; 18 Jun 86 21:33:03 PDT Received: from kddlab.UUCP by seismo.CSS.GOV with UUCP; Thu, 19 Jun 86 00:01:35 EDT From: kddlab!yuasa@kurims.kurims.kyoto-u.junet Received: by kddlabs.junet ; Wed, 18 Jun 86 18:33:58+0900 Return-Path: Received: by kddlabs.junet ; Wed, 18 Jun 86 18:33:46+0900 Received: by titan.junet (4.12/6.0Junet) id AA00768; Wed, 18 Jun 86 15:58:05 jst Received: by nttlab.ntt.junet (4.12/4.7JC-7) with TCP id AA28412; Wed, 18 Jun 86 12:31:20 jst Received: by kurims.kurims.kyoto-u.junet (2.0/6.1Junet) id AA00861; Tue, 17 Jun 86 19:27:09+0900 Date: Tue, 17 Jun 86 19:27:09+0900 Message-Id: <8606171027.AA00861@kurims.kurims.kyoto-u.junet> To: nttlab!Shasta!Fahlman@C.CS.CMU.EDU Subject: What are special forms? Cc: common-lisp@SU-AI.ARPA I have been worrying about what are meant by "special forms". CLtL defines, in Page 56, that If the first element (of a list form) is one of the symbols appearing in Table 5-1, then the list is called a /special form/. According to this definition, (SETQ X 1) is a special form but the symbol SETQ is not. Indeed, the caption of Table 5-1 (page 57) explicitly says that the table lists *Names* of Common Lisp special forms. Thus, SETQ certainly is a symbol that names special forms such as (SETQ X 1) and (SETQ). So far, so good. Right below Table 5-1, CLtL says The set of special forms is fixed .... This is still OK. The set of special forms consists of infinite number as its elements, but anyway it is fixed. However, in the next paragraph, it says The set of special forms is kept very small ... Small (!!!) an infinite set is ??? The sentense should rather be The set of special form names is kept very small ... The name SPECIAL-FORM-P enlarges such a kind of confusion between special forms and special form names. The name of the function should rather be SPECIAL-FORM-NAME-P or something like that. I am writing this message because I really got confused to read the following message. Date: Mon, 16 Jun 1986 22:52 EDT From: "Scott E. Fahlman" .... There's no such thing as a FEXPR in Common Lisp, though some implementations may use such a thing internally in implementing specia forms. I'll assume that you mean "special form" or "special operator" or whatever we are calling it. I think that Compiled-Function-P and Function-P should answer NIL for special forms. Does this mean, for example, (COMPILED-FUNCTION-P '(SETQ X 1)) => NIL (FUNCTION-P '(SETQ X 1)) => NIL or (COMPILED-FUNCTION-P (SPECIAL-FORM-P 'SETQ)) => NIL (FUNCTION-P (SPECIAL-FORM-P 'SETQ)) => NIL ? The latter interpretation seems to contradict CLtL, which says A returned non-NIL value (of SPECIAL-FORM-P) is typically a function of ... Incidentally, I would like to ask you what "globally" means in the following sentence in the CLtL description of SPECIAL-FORM-P in Page 91. If the symbol globally names a special form, .... I am sorry if there still is a sort of consensus in US Lisp people in this issue. But please keep it in mind that CLtL and common-lisp@su-ai are the only references to me. -- Taiichi  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 19 Jun 86 16:43:57 EDT Received: from [192.10.41.41] by SU-AI.ARPA with TCP; 18 Jun 86 21:06:47 PDT Received: from EUPHRATES.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 25327; Thu 19-Jun-86 00:05:24 EDT Date: Thu, 19 Jun 86 00:01 EDT From: David A. Moon Subject: Structure sharing To: NGALL@G.BBN.COM, Scott E. Fahlman cc: common-lisp@SU-AI.ARPA In-Reply-To: <[G.BBN.COM]18-Jun-86 23:08:42.NGALL>, Message-ID: <860619000135.1.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: 18 Jun 1986 23:08-EDT From: NGALL@G.BBN.COM KCL recently surprised me with the following behavior: (setf foo 'filename) => FILENAME (setf bar (namestring foo)) => "FILENAME" (setf bar (nstring-downcase bar)) => "filename" foo => {causes error} It seems that in KCL. namestring of a symbol merely returns a simple-string whose characters are SHARED with the print-name of the symbol FILENAME! Date: Wed, 18 Jun 1986 23:35 EDT From: "Scott E. Fahlman" Page 168: "It is an extremely bad idea to modify a string being used as the print name of a symbol. Such a modification may tremendously confuse the function READ and the package system." Does this tell us whether the behavior of NAMESTRING in KCL is valid or invalid? I think it's valid, but nothing in the manual directly supports that claim. From: NGALL@G.BBN.COM again I think it would be a good idea for CLtL to explicity state that unless otherwise noted, a given function may return an object that shares structure with another object. And it would help to give a few examples like parse-namestring and namestring to point out the non-obvious consequences. It sounds like the agenda of language clarifications ought to include such an item.  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 19 Jun 86 16:43:15 EDT Received: from GSWD-VMS.ARPA by SU-AI.ARPA with TCP; 18 Jun 86 20:40:59 PDT Received: from ccvaxa.GSD (ccvaxa.ARPA) by gswd-vms.ARPA (5.9/) id AA12295; Wed, 18 Jun 86 22:40:09 CDT Message-Id: <8606190340.AA12295@gswd-vms.ARPA> Date: Wed, 18 Jun 86 22:38:31 cdt From: preece%ccvaxa@gswd-vms.ARPA (Scott E. Preece) To: COMMON-LISP@su-ai.arpa Subject: Unsolicited typeout > VAXLISP 1.2 (for example) outputs "FOO compiled." every time COMPILE > or COMPILE-FILE compiles something. Symbolics' Common Lisp (for > example) does not. This is very problemsome if I want a program that > secretly compiles things to have identical I/O behavior in both > systems. > From: Kent M Pitman ---------- I don't know for certain about VAXLISP, but since it's a Spice derivative you might try setting *verbose* (maybe that's compiler::*verbose*) to NIL. That specifically turns off compiler progress messages. -- scott preece gould/csd - urbana ihnp4!uiucdcs!ccvaxa!preece  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 19 Jun 86 16:42:42 EDT Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 18 Jun 86 20:36:54 PDT Received: ID ; Wed 18 Jun 86 23:35:07-EDT Date: Wed, 18 Jun 1986 23:35 EDT Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: NGALL@BBNG.ARPA Cc: common-lisp@SU-AI.ARPA Subject: Structure sharing In-reply-to: Msg of 18 Jun 1986 23:08-EDT from NGALL at G.BBN.COM Page 168: "It is an extremely bad idea to modify a string being used as the print name of a symbol. Such a modification may tremendously confuse the function READ and the package system."  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 19 Jun 86 16:42:21 EDT Received: from C.CS.CMU.EDU by SU-AI.ARPA with TCP; 18 Jun 86 20:29:08 PDT Received: ID ; Wed 18 Jun 86 23:29:14-EDT Date: Wed, 18 Jun 1986 23:29 EDT Message-ID: Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" To: common-lisp@SU-AI.ARPA Subject: What are special forms? In-reply-to: Msg of Tue 17 Jun 86 19:27:09+0900 from nttlab!kurims!yuasa at kurims.kurims.kyoto-u.junet In response to: nttlab!kurims!yuasa at kurims.kurims.kyoto-u.junet This issue was discussed on Common Lisp some time ago, perhaps before the network connections to Japan were working. We had all fallen into the habit of using the term "special form" to refer to both the entire form and the symbol (such as SETQ) that names the form. Someone pointed out that this was sloppy and potentially confusing. He proposed that we refer to the symbol as a "special operator", reserving the name "special form" for the entire list. This seemed like a good clarification to all of us, but there was some disagreement about whether the potential for confusion was great enough to justify changing the name SPECIAL-FORM-P to SPECIAL-OPERATOR-P. This was never resolved. It is on my list of things that we need to settle. So what my message meant to say was that (Compiled-Function-P 'setq) => nil. Incidentally, I would like to ask you what "globally" means in the following sentence in the CLtL description of SPECIAL-FORM-P in Page 91. If the symbol globally names a special form, .... I beleive that the word "globally" is superfluous in this sentence. At one time it was contemplated that forms like FLET might locally redefine symbols that are special-forms (menaing special operators) at top level. I believe that the manual now says explicitly that it is illegal to redefine special forms, though I can't find that pasage right now. -- Scott  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 19 Jun 86 16:41:55 EDT Received: from BBNG.ARPA by SU-AI.ARPA with TCP; 18 Jun 86 20:09:22 PDT Date: 18 Jun 1986 23:08-EDT Sender: NGALL@G.BBN.COM Subject: Structure sharing From: NGALL@G.BBN.COM To: common-lisp@SU-AI.ARPA Message-ID: <[G.BBN.COM]18-Jun-86 23:08:42.NGALL> KCL recently surprised me with the following behavior: (setf foo 'filename) => FILENAME (setf bar (namestring foo)) => "FILENAME" (setf bar (nstring-downcase bar)) => "filename" foo => {causes error} It seems that in KCL. namestring of a symbol merely returns a simple-string whose characters are SHARED with the print-name of the symbol FILENAME! As far as I can tell, this kind of sharing is perfectly legit, even though it is very unintuitive. Even parse-namestring returns a pathname that shares characters with the string it was given! I think it would be a good idea for CLtL to explicity state that unless otherwise noted, a given function may return an object that shares structure with another object. And it would help to give a few examples like parse-namestring and namestring to point out the non-obvious consequences. -- Nick  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 19 Jun 86 16:41:22 EDT Received: from BBNG.ARPA by SU-AI.ARPA with TCP; 18 Jun 86 19:53:52 PDT Date: 18 Jun 1986 22:52-EDT Sender: NGALL@G.BBN.COM Subject: Re: Unsolicited typeout From: NGALL@G.BBN.COM To: KMP@SCRC-STONY-BROOK.ARPA Cc: COMMON-LISP@SU-AI.ARPA Message-ID: <[G.BBN.COM]18-Jun-86 22:52:08.NGALL> In-Reply-To: <860618170258.3.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> Date: Wed, 18 Jun 86 17:02 EDT From: Kent M Pitman To: COMMON-LISP@SU-AI.ARPA Subject: Unsolicited typeout Message-ID: <860618170258.3.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> ... In general, I feel that the next edition of the manual should make it very clear that certain kinds of actions (such as output to *STANDARD-OUTPUT*) are implicitly forbidden unless there is an explicit statement to the contrary. The same text should also expressly allow anything to do output to *ERROR-OUTPUT* at any time, since that can be safely bound to something else in contexts where warnings need to be suppressed without affecting the "normal" I/O behavior of the program in question. Agreed. By the way, I get tired of writing (WITH-OUTPUT-TO-STRING (*STANDARD-OUTPUT*) ...) around things that I want to portably suppress output from (and then throwing away the result string). It's inefficient and doesn't say what I mean. In the absence of a protocol for making generalized user-defined streams, I would like very much if we would provide a WITH-OUTPUT-DISCARDED special form (or macro) that would say and do what I really mean to be doing. Alternatively, if there were a variable that held a stream that did this output and I could do (LET ((*STANDARD-OUTPUT* *NULL-OUTPUT-STREAM*)) ...), that would suffice. How 'bout (defvar *null-output-stream* (make-broadcast-stream)) -- Nick  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 19 Jun 86 16:40:25 EDT Received: from GODOT.THINK.COM by SU-AI.ARPA with TCP; 18 Jun 86 14:48:10 PDT Received: from wenceslas by Godot.Think.COM via CHAOS; Wed, 18 Jun 86 17:47:35 edt Date: Wed, 18 Jun 86 17:48 EDT From: Guy Steele Subject: Out-of-range subsequences To: DLW@QUABBIN.SCRC.Symbolics.COM, Daniels.pa@Xerox.COM, common-lisp@SU-AI.ARPA Cc: gls@AQUINAS In-Reply-To: <860618082448.8.DLW@CHICOPEE.SCRC.Symbolics.COM> Message-Id: <860618174850.1.GLS@WENCESLAS.THINK.COM> Date: Wed, 18 Jun 86 08:24 EDT From: Daniel L. Weinreb Date: 17 Jun 86 14:43 PDT From: Daniels.pa@Xerox.COM In particular, is (subseq #(1 2 3) 0 5) an error? What an excellent example of the sort of thing that the manual really needs to be more explicit about. Our implementation signals an error. It certainly seems to me that it ought to. About the best I have to offer is that the manual says that start and end "should be integer indices into the sequence". I would interpret "into the sequence" and meaning "between 0 and the length of the sequence, inclusive", but I grant that there is considerable latitude for controversy here. --Guy  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 19 Jun 86 16:39:43 EDT Received: from [192.10.41.41] by SU-AI.ARPA with TCP; 18 Jun 86 14:13:01 PDT Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 24980; Wed 18-Jun-86 17:04:00 EDT Date: Wed, 18 Jun 86 17:02 EDT From: Kent M Pitman Subject: Unsolicited typeout To: COMMON-LISP@SU-AI.ARPA Message-ID: <860618170258.3.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> I have a problem about functions doing unsolicited typeout. The manual is somewhat silent on this issue and the next edition should make its intent more clear. For example, the manual makes no statement about whether CONS or EQUAL does typeout, but I hope we agree that it's not a good idea for them to do so. I think the manual should be tightened up in this regard. VAXLISP 1.2 (for example) outputs "FOO compiled." every time COMPILE or COMPILE-FILE compiles something. Symbolics' Common Lisp (for example) does not. This is very problemsome if I want a program that secretly compiles things to have identical I/O behavior in both systems. I suppose I could bind *STANDARD-OUTPUT* around calls to COMPILE but that seems a little silly. And besides, VAXLISP 1.2 outputs compiler warnings to *STANDARD-OUTPUT* rather than *ERROR-OUTPUT*, so I'd also miss warnings if I bound *STANDARD-OUTPUT* (something that wouldn't happen in Symbolics' Common Lisp). I can't call these bugs in VAXLISP, because the manual doesn't say that COMPILE doesn't do typeout to *STANDARD-OUTPUT*. Nor does it say that COMPILE is obliged to call WARN (or even to simulate its behavior) when reporting problems. Nevertheless, I hope that a future standard will be written in such a way that things like this could be treated as simple bugs. In general, I feel that the next edition of the manual should make it very clear that certain kinds of actions (such as output to *STANDARD-OUTPUT*) are implicitly forbidden unless there is an explicit statement to the contrary. The same text should also expressly allow anything to do output to *ERROR-OUTPUT* at any time, since that can be safely bound to something else in contexts where warnings need to be suppressed without affecting the "normal" I/O behavior of the program in question. By the way, I get tired of writing (WITH-OUTPUT-TO-STRING (*STANDARD-OUTPUT*) ...) around things that I want to portably suppress output from (and then throwing away the result string). It's inefficient and doesn't say what I mean. In the absence of a protocol for making generalized user-defined streams, I would like very much if we would provide a WITH-OUTPUT-DISCARDED special form (or macro) that would say and do what I really mean to be doing. Alternatively, if there were a variable that held a stream that did this output and I could do (LET ((*STANDARD-OUTPUT* *NULL-OUTPUT-STREAM*)) ...), that would suffice. I might be ammenable to a new stream, *WINDY-OUTPUT* which was a stream to which "extra" output could be sent in situations where extra-verbose output might or might not be allowed. I'd have to study this in more detail before committing to it, but I thought I'd note the idea. eg, COMPILE and COMPILE-FILE mentioned above might could use this, and also LOAD (which I complained in earlier mail types out the name of every function loaded in some implementations but not in others). I'm not sure if we could make this rigorous enough to be useful, but at least people could bind *WINDY-OUTPUT* to *NULL-OUTPUT-STREAM*.  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 19 Jun 86 16:38:42 EDT Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 18 Jun 86 16:39:47 PDT Received: from cgi by csnet-relay.csnet id aa29386; 18 Jun 86 19:30 EDT Date: Wed, 18 Jun 86 19:17 ??? From: MILNES%cgi.csnet@CSNET-RELAY.ARPA To: common-lisp@SU-AI.ARPA Subject: Argument Lists From: Brian Milnes @cgi.csnet.com We here at CGI have run into several cases where we would like to be able to access the argument list format for functions and macros in a system independent manner. The symbolics and the TI support a function arglist which returns the lambda list for a function; we are using this to provide a command like ctr-A, which describes a functions argument list, in Knowledge Craft. I also would like a Common Lisp way of determining the minimum and maximum number of arguments taken by a given function; this would allow the CRL-OPS compiler to determine a left hand side predicate call has the correct number of arguments so that it does not cause an error and leave the RETE pattern matching network in an inconsistent state. Have we missed this functionality in CLtL ? Do others of you out there miss this functionality ? Could it be simply and safely added to CL ? -Brian  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 19 Jun 86 16:38:02 EDT Received: from [192.10.41.41] by SU-AI.ARPA with TCP; 18 Jun 86 16:21:14 PDT Received: from EUPHRATES.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 25142; Wed 18-Jun-86 18:47:39 EDT Date: Wed, 18 Jun 86 18:46 EDT From: David A. Moon Subject: Achieving portability, how? To: COMMON-LISP@SU-AI.ARPA In-Reply-To: The message of 18 Jun 86 12:03 EDT from Rem@IMSSS Message-ID: <860618184650.6.MOON@EUPHRATES.SCRC.Symbolics.COM> In reply to REM's message: I thought the goals of Common Lisp were as stated on the first three (arabic-numbered) pages of the manual, whereas you are calling for Common Lisp to be a collection of very-close-to-identical implementations on a wide variety of machines, with portability virtually guaranteed. That would probably be a useful thing to have, at least if it were free, but it's a big change of direction and ought to be discussed as a change of direction rather than as an obvious clarification of what we were doing all along.  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 19 Jun 86 16:37:37 EDT Received: from GSWD-VMS.ARPA by SU-AI.ARPA with TCP; 18 Jun 86 13:56:12 PDT Received: from ccvaxa.GSD (ccvaxa.ARPA) by gswd-vms.ARPA (5.9/) id AA12065; Wed, 18 Jun 86 15:55:19 CDT Message-Id: <8606182055.AA12065@gswd-vms.ARPA> Date: Wed, 18 Jun 86 15:54:21 cdt From: preece%ccvaxa@gswd-vms.ARPA (Scott E. Preece) To: COMMON-LISP@su-ai.arpa Subject: Re: Out-of-range subsequences > It's not a question of pickiness, but one of consistency. Common Lisp > takes a uniform attitude about addressing outside the boundaries of an > array, and all functions should follow the convention. From: Daniel L. > Weinreb ---------- Well, if your clarify the definition to say that subsequences end at the end of the underlying sequence, then you're NOT addressing outside the boundaries of the array. However, I'm changing our implementation, even as we speak, to signal an error, since that seems to be the consensus. -- scott preece gould/csd - urbana ihnp4!uiucdcs!ccvaxa!preece  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 19 Jun 86 16:36:48 EDT Received: from [192.10.41.41] by SU-AI.ARPA with TCP; 18 Jun 86 14:13:01 PDT Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 24980; Wed 18-Jun-86 17:04:00 EDT Date: Wed, 18 Jun 86 17:02 EDT From: Kent M Pitman Subject: Unsolicited typeout To: COMMON-LISP@SU-AI.ARPA Message-ID: <860618170258.3.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> I have a problem about functions doing unsolicited typeout. The manual is somewhat silent on this issue and the next edition should make its intent more clear. For example, the manual makes no statement about whether CONS or EQUAL does typeout, but I hope we agree that it's not a good idea for them to do so. I think the manual should be tightened up in this regard. VAXLISP 1.2 (for example) outputs "FOO compiled." every time COMPILE or COMPILE-FILE compiles something. Symbolics' Common Lisp (for example) does not. This is very problemsome if I want a program that secretly compiles things to have identical I/O behavior in both systems. I suppose I could bind *STANDARD-OUTPUT* around calls to COMPILE but that seems a little silly. And besides, VAXLISP 1.2 outputs compiler warnings to *STANDARD-OUTPUT* rather than *ERROR-OUTPUT*, so I'd also miss warnings if I bound *STANDARD-OUTPUT* (something that wouldn't happen in Symbolics' Common Lisp). I can't call these bugs in VAXLISP, because the manual doesn't say that COMPILE doesn't do typeout to *STANDARD-OUTPUT*. Nor does it say that COMPILE is obliged to call WARN (or even to simulate its behavior) when reporting problems. Nevertheless, I hope that a future standard will be written in such a way that things like this could be treated as simple bugs. In general, I feel that the next edition of the manual should make it very clear that certain kinds of actions (such as output to *STANDARD-OUTPUT*) are implicitly forbidden unless there is an explicit statement to the contrary. The same text should also expressly allow anything to do output to *ERROR-OUTPUT* at any time, since that can be safely bound to something else in contexts where warnings need to be suppressed without affecting the "normal" I/O behavior of the program in question. By the way, I get tired of writing (WITH-OUTPUT-TO-STRING (*STANDARD-OUTPUT*) ...) around things that I want to portably suppress output from (and then throwing away the result string). It's inefficient and doesn't say what I mean. In the absence of a protocol for making generalized user-defined streams, I would like very much if we would provide a WITH-OUTPUT-DISCARDED special form (or macro) that would say and do what I really mean to be doing. Alternatively, if there were a variable that held a stream that did this output and I could do (LET ((*STANDARD-OUTPUT* *NULL-OUTPUT-STREAM*)) ...), that would suffice. I might be ammenable to a new stream, *WINDY-OUTPUT* which was a stream to which "extra" output could be sent in situations where extra-verbose output might or might not be allowed. I'd have to study this in more detail before committing to it, but I thought I'd note the idea. eg, COMPILE and COMPILE-FILE mentioned above might could use this, and also LOAD (which I complained in earlier mail types out the name of every function loaded in some implementations but not in others). I'm not sure if we could make this rigorous enough to be useful, but at least people could bind *WINDY-OUTPUT* to *NULL-OUTPUT-STREAM*.  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 19 Jun 86 16:35:52 EDT Received: from [128.32.130.7] by SU-AI.ARPA with TCP; 18 Jun 86 13:45:25 PDT Received: by kim.Berkeley.EDU (5.51/1.14) id AA05061; Wed, 18 Jun 86 13:45:44 PDT Received: from fimass by franz (5.5/3.14) id AA03704; Wed, 18 Jun 86 11:40:28 PDT Received: by fimass (5.5/3.14) id AA19280; Wed, 18 Jun 86 10:38:28 PST From: franz!fimass!jkf@kim.Berkeley.EDU (John Foderaro) Return-Path: Message-Id: <8606181838.AA19280@fimass> To: "BIZET::BUY" Cc: common-lisp@su-ai.arpa Subject: Re: packages and portability In-Reply-To: Your message of 18 Jun 86 11:23:00 EST. <8606181548.AA28606@kim.Berkeley.EDU> Date: Wed, 18 Jun 86 10:38:22 PST >> I think that site specific extensions may be of various kinds. For >> example, the VAX LISP implementation of FORMAT includes 8 directives in >> addition to those specified in CLtL. This is an upward compatible change and doesn't force double definitions. >> In the same implementation, >> APROPOS and APROPOS-LIST make use of DO-SYMBOLS rather than >> DO-ALL-SYMBOLS, as specified in CLtL. This is a good example of the kind of extensions we want to avoid. It isn't upward compatible and it is only going to confuse the poor user who is trying to program in common lisp using CLtL. Why not choose other names for your apropos functions? >> In ZETALISP the special form IF >> can take more than three arguments and arguments after the second are >> assumed to be the ELSE clause with an implicit PROGN. I also dislike the common lisp 'if' special form, but rather than modify it, I wrote a new macro, and gave it the name 'if*'. In your case I would suggest something similar. I don't like typing 'if*' when I really mean 'if', but the benefits far outweigh this inconvenience. Besides, now code using 'if*' can be ported as long as I carry along the definition of my if* macro. >> ... >> Consequently, the approach of providing two distinct implementations >> for certain extended CLtL objects may facilitate writing portable code. I disagree only slightly with this: you can write portable code regardless of the package layout, where your package setup helps is in testing for non-portableness (both by compiling the code and running it). But as the saying goes, "Testing only proves the presence of bugs, not the absence", thus we agree that it would be foolish to use this as the only mechanism to test for portability. And how can one ever test whether the user is using the correct version of 'apropos' in your system? The previous sentence is perhaps the key point: unless we can agree to assign one meaning to each of the functions in common lisp, how can we ever achieve portability? If the presence of double definitions is a license to change CLtL functions at will, then I would be against using double definitions for that reason alone. -john foderaro franz inc.  Received: from SU-AI.ARPA by AI.AI.MIT.EDU 19 Jun 86 16:12:11 EDT Received: from XEROX.COM by SU-AI.ARPA with TCP; 19 Jun 86 13:03:43 PDT Received: from Cabernet.ms by ArpaGateway.ms ; 19 JUN 86 12:38:48 PDT Date: 19 Jun 86 12:32 PDT From: Masinter.pa@Xerox.COM Subject: Re: Why aren't char bits portable? To: common-lisp@su-ai.ARPA In-Reply-to: KMP%SCRC-STONY-BROOK:ARPA's message of Monday, June 9, 1986 12:23 pm Message-ID: <860619-123848-1153@Xerox> Char-bits aren't portable because they are a property of the physical keyboard of the machine, and, most keyboards don't have bits that correspond to them. ("Most" when enumerating all keyboards, computer keyboards, keyboards on machines that run lisp, or even accepted standards (DIN, ANSI) for keyboards.) The best thing that a "portable" program can do to cope with the variety of keyboards is twofold: a) stick as much as possible within the set of standard characters b) mark the mapping of keys to characters as a clear implementation-dependent part of programs that have to go beyond the standard characters. Char-bits have no more place in the "standard" than does double-bucky-coke-bottle. Larry