Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!think.com!barmar From: barmar@think.com (Barry Margolin) Newsgroups: comp.lang.lisp Subject: Re: read-from-string problem Message-ID: <1990Dec22.003036.19513@Think.COM> Date: 22 Dec 90 00:30:36 GMT References: <1990Dec21.100843.15778@src.dec.com> <4920@idunno.Princeton.EDU> Sender: news@Think.COM Organization: Thinking Machines Corporation, Cambridge MA, USA Lines: 47 In article <4920@idunno.Princeton.EDU> eliot@phoenix.Princeton.EDU (Eliot Handelman) writes: >The question is, why not just do away with the optional arguments by >turning them into keywords? In other words, define READ like this: > >(defun read (&key (eof-error-p t) etc etc) ... ) > >This is a performance issue, right? If we were worried about performance of keyword arguments, this would be the last such function we'd bother optimizing. Common Lisp READ was defined as it was for compatibility with Maclisp, Zetalisp, and several other Lisps that Common Lisp was derived from. Just be glad they did away with the Maclisp kludge that permitted the first two arguments to be given in either order (i.e. if the first argument wasn't a stream, it was assumed to be the eof-error-p argument). READ-FROM-STRING was then defined as it was for consistency with both READ and the string functions. The arguments taken from READ are positional, while the string-related arguments are keywords. The Zetalisp READ-FROM-STRING function took the string-related arguments positionally as well, but so did its regular string functions. I suspect that most of us on X3J13 agree that READ-FROM-STRING's argument list was a mistake. Every few months a message is posted here or on the Symbolics user's group mailing list about this "bug" in some implementation of READ-FROM-STRING, and I'm sure the customer support people at all the Common Lisp vendors get their share of such reports as well. Unfortunately, it's too late to change READ and READ-FROM-STRING. The standardization process is at the stage where we are only making changes necessary to fix real problems. READ-FROM-STRING may be ugly and counterintuitive, but it works, and compatibility has higher precedence than esthetics. READ could be changed compatibly, since its current first argument cannot be a keyword (if the first argument is a stream, T, or NIL then the positional syntax is being used, otherwise the keyword syntax is being used), but I don't think many people find READ's syntax so unwieldy. READ-FROM-STRING can't be changed compatibly, because a keyword is an acceptable value for the first optional argument (that's the problem with defining boolean truth to be everything but NIL); we could do it if we were willing to turn the required string argument into a keyword argument as well, but I think that would be unappealing as well. -- Barry Margolin, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar