lpznigel@clan.nott.ac.uk (Nigel Major) (12/20/90)
Hello there, In an effort to use read-from-string, I came across what seemed to me to be pretty odd behaviour. At first I thought it was a bug in my Common Lisp (Lucid 3.0 on a Sun 4/110), but the same thing happens in AKCL and Poplog CL, so I guess it is not. Would anyone like to explain it to me? > (read-from-string "abcdefgh" :start 2 :end 3) abc 3 > (read-from-string "abcdefgh" :end 3 :start 2) cdefgh 8 I had rather assumed that the first call should return cd, and that whatever the first call had returned, the second call should return the same. CLtL says of read-from-string that the keywords :start and :end delimit a substring in the same way as for other string functions. However, > (string= "abc" "xbc" :end2 2 :start1 1 :start2 1 :end1 2) t which seems to notice the start keywords and also not worry about the order of the keywords. Cheers, Nigel.
hall@aplcen.apl.jhu.edu (Marty Hall) (12/21/90)
In article <1990Dec20.115130.20493@cs.nott.ac.uk> nigel@psyc.nott.ac.uk (Nigel Major) writes: [...] >In an effort to use read-from-string, I came across what >seemed to me to be pretty odd behaviour. At first I thought >it was a bug in my Common Lisp (Lucid 3.0 on a Sun 4/110), but >the same thing happens in AKCL and Poplog CL, so I guess it >is not. Would anyone like to explain it to me? > >> (read-from-string "abcdefgh" :start 2 :end 3) >abc >3 >> (read-from-string "abcdefgh" :end 3 :start 2) >cdefgh >8 [...] I believe you are overlooking the fact that there are two optional arguments after the string and before the keywords. So your first two arguments after "abcdefgh" are taken as the values of eof-error-p and eof-value, respectively. > (read-from-string "abcdefgh" nil 'done :start 2 :end 3) C 3 (and identically if you switch the order of the keyword args) - Marty Hall ------------------------------------------------------ hall@aplcen.apl.jhu.edu, hall%aplcen@jhunix.bitnet, ..uunet!aplcen!hall Artificial Intelligence Lab, AAI Corp, PO Box 126, Hunt Valley, MD 21030
moore%cdr.utah.edu@cs.utah.edu (Tim Moore) (12/21/90)
In article <1990Dec20.115130.20493@cs.nott.ac.uk> nigel@psyc.nott.ac.uk (Nigel Major) writes: >Hello there, > >In an effort to use read-from-string, I came across what >seemed to me to be pretty odd behaviour. At first I thought >it was a bug in my Common Lisp (Lucid 3.0 on a Sun 4/110), but >the same thing happens in AKCL and Poplog CL, so I guess it >is not. Would anyone like to explain it to me? > >> (read-from-string "abcdefgh" :start 2 :end 3) >abc >3 >> (read-from-string "abcdefgh" :end 3 :start 2) >cdefgh >8 READ-FROM-STRING takes two optional parameters, EOF-ERROR-P and EOF-VALUE, like most reader functions. You were unwittingly supplying values for those parameters, so in your first example you only specified a value for :end (but not :start), and vice versa for the second example. > >I had rather assumed that the first call should return cd, >and that whatever the first call had returned, the second call >should return the same. CLtL says of read-from-string that the >keywords :start and :end delimit a substring in the same way as >for other string functions. They do. Both calls should return C: (read-from-string "abcdefgh" nil nil :end 3 :start 2) C 3 Tim Moore moore@cs.utah.edu {bellcore,hplabs}!utah-cs!moore "Ah, youth. Ah, statute of limitations." -John Waters
nori@kagaku.se.fujitsu.co.jp (Noritoshi Rokujo) (12/21/90)
In article <1990Dec20.115130.20493@cs.nott.ac.uk> lpznigel@clan.nott.ac.uk (Nigel Major) writes: Hello > >In an effort to use read-from-string, I came across what >seemed to me to be pretty odd behaviour. At first I thought >it was a bug in my Common Lisp (Lucid 3.0 on a Sun 4/110), but >the same thing happens in AKCL and Poplog CL, so I guess it >is not. Would anyone like to explain it to me? > The syntax of read-from-string is read-from-string string &optional eof-error-p eof-value &key ... So, you must specify optional arguments. >> (read-from-string "abcdefgh" :start 2 :end 3) should be like (read-from-string "abcdefgh" nil nil :start 2 :end 3) -- N. Rokujo, Fujitsu Ltd.
meehan@jumbo.pa.dec.com (Jim Meehan) (12/22/90)
Functions that take both optional and keyword arguments are a nuisance but yes, that's how they work, so (read-from-string "abcdefgh" nil nil :start 2 :end 3) is correct. Fortunately, there aren't very many in CLtL.
eliot@phoenix.Princeton.EDU (Eliot Handelman) (12/22/90)
In article <1990Dec21.100843.15778@src.dec.com> meehan@jumbo.pa.dec.com (Jim Meehan) writes:
;Functions that take both optional and keyword arguments are a nuisance
;but yes, that's how they work
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?
--eliotbarmar@think.com (Barry Margolin) (12/22/90)
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