From ... From: Erik Naggum Subject: Re: PARSE-NUMBER Date: 1999/05/25 Message-ID: <3136626193196687@naggum.no>#1/1 X-Deja-AN: 481882696 References: <87ogjiibfi.fsf@pc-hrvoje.srce.hr> <374c27a9.339323521@news.mad.ttd.net> <37514102.345811360@news.mad.ttd.net> <37526d4c.357147961@news.mad.ttd.net> mail-copies-to: never Organization: Naggum Software; +47 8800 8879; http://www.naggum.no Newsgroups: comp.lang.lisp * barranquero@laley-actualidad.es (Juanma Barranquero) | What you're proposing is not very different of what I've suggested in | my previous post, I think. I suppose you say "something similar to" | because of that: | | USER(56): (coerce (read-from-string "1") 'bignum) | Error: Can't coerce 1 to type BIGNUM. | [condition type: SIMPLE-ERROR] pardon me, but why this obsession with bignums and fixnums? like all types, they do partition a value space, but in a different way than most types. you can have the numeric value 1 in any numeric type, but the implementation artifact of machine integers means it cannot be a bignum (unless you allow unnormalized bignums, but I digress). whether an integer is a bignum or a fixnum should be none of your concern (unless you have severe performance constraints, but I digress). I think you will find the answer sooner (whatever it is you're seeking) if you don't trouble yourself with such things. FWIW, I would like to know the object type of the object that would most likely be created if READ (etc) were applied to a string. (that's "most likely" because I don't want error handling until I actually want the object, and I don't want to go ahead and read the string with all the attendant side effects until I'm sure I want the result. error handling is great, but it necessarily happens after the error has occurred, and that is not sufficient at all times.) #:Erik -- @1999-07-22T00:37:33Z -- pi billion seconds since the turn of the century