Gareth McCaughan <gj...@dpmms.cam.ac.uk> writes: > Kent Pitman wrote:
> > I recall a proposal a long time ago to make
> > (setf (format nil "~D:~D:~D" x y z) "1:36:12.2")
> > work. [Don't think too hard about it. It has a lot of problems. > > But it *was* cute. A more practical solution we *should* consider > > would be regular expression processing.]
> Yow. How about extending it a little further?
> (progn (setf (* x x) 4) x) ==> either 2 or -2
> (progn (declare (type (integer 1 *) x y z) > (type (integer 3 *) n)) > (setf (+ (expt x n) (expt y n) (- (expt z n))) 0) > (list x y z n)) ==> ERROR: That equation has no solutions.
I have a better one.
(equalp P NP) => t nil
Cheers :)
-- Marco Antoniotti =========================================== PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY tel. +39 - 06 68 10 03 17, fax. +39 - 06 68 80 79 26 http://www.parades.rm.cnr.it/~marcoxa
>>>> In message <87zp31cd75....@pc-hrvoje.srce.hr> >>>> On the subject of "Re: READ-FROM-STRING considered unsafe? (was Re: Simple Function Question)" >>>> Sent on 19 May 1999 17:05:18 +0200 >>>> Honorable Hrvoje Niksic <hnik...@srce.hr> writes:
>> Sam Steingold <s...@goems.com> writes: >> > >>>> Honorable Hrvoje Niksic <hnik...@srce.hr> writes: >> > >> strings such as "2+3i", >> > oh please! "2+3i" is a complex number while "2+3j" is a symbol. >> >> "2+3j" is not a symbol here because we're talking about a >> hypothetical PARSE-NUMBER, not about the Lisp reader. Anyway, you
all right, an error then.
>> could also allow "2+3j", for all I care. I don't like being dragged
what about "2i"? "2i+3"? "2i+4j"?
>> too far into this discussion -- it's not like I have any idea why >> 2+3i would be any worse than 2+3j.
what about "2+3k"? how about "1+2i+3j+4k"?
>> > >> "2 + 3i" as complex numbers. >> > so, what should (parse-number "2 + 3i") return? 2? or #C(2 3)? >> The latter.
why? you mean `parse-number' will return something different from `parse-integer'?
-- Sam Steingold (http://www.goems.com/~sds) running RedHat6.0 GNU/Linux Micros**t is not the answer. Micros**t is a question, and the answer is Linux, (http://www.linux.org) the choice of the GNU (http://www.gnu.org) generation. A man paints with his brains and not with his hands.
>> > (setf (format nil "~D:~D:~D" x y z) "1:36:12.2")
>> > work. [Don't think too hard about it. It has a lot of problems.
>> Couldn't stop myself. Were these problems along the lines of >> constraining and defining the details of how exactly this would work >> or otherwise?
>Thinks about (setf (format nil "~D~D" x y) "123")
The problem is no different from something like C's sscanf("123", "%d%d", &x, &y). Obviously an input parser won't be a complete inverse of an output formatter. But this doesn't mean that the use of SETF of FORMAT as the interface is flawed.
-- Barry Margolin, bar...@bbnplanet.com GTE Internetworking, Powered by BBN, Burlington, MA *** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups. Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
Barry Margolin <bar...@bbnplanet.com> writes: > >Thinks about (setf (format nil "~D~D" x y) "123")
> The problem is no different from something like C's sscanf("123", "%d%d", > &x, &y). Obviously an input parser won't be a complete inverse of an > output formatter. But this doesn't mean that the use of SETF of FORMAT as > the interface is flawed.
I also thought along these lines. This is what gcc does:
> >>>> In message <87zp31cd75....@pc-hrvoje.srce.hr> > >>>> On the subject of "Re: READ-FROM-STRING considered unsafe? (was Re: Simple Function Question)" > >>>> Sent on 19 May 1999 17:05:18 +0200 > >>>> Honorable Hrvoje Niksic <hnik...@srce.hr> writes: > >> Sam Steingold <s...@goems.com> writes: > >> > >>>> Honorable Hrvoje Niksic <hnik...@srce.hr> writes: > >> > >> strings such as "2+3i", > >> > oh please! "2+3i" is a complex number while "2+3j" is a symbol.
> >> "2+3j" is not a symbol here because we're talking about a > >> hypothetical PARSE-NUMBER, not about the Lisp reader. Anyway, you
[...]
> >> > >> "2 + 3i" as complex numbers. > >> > so, what should (parse-number "2 + 3i") return? 2? or #C(2 3)? > >> The latter.
> why? you mean `parse-number' will return something different from > `parse-integer'?
What about 1.23? You mean parse-number WON'T return something different from parse-integer??
> -- > Sam Steingold (http://www.goems.com/~sds) running RedHat6.0 GNU/Linux > Micros**t is not the answer. Micros**t is a question, and the answer is Linux, > (http://www.linux.org) the choice of the GNU (http://www.gnu.org) generation. > A man paints with his brains and not with his hands.
>>>> In message <wtwvy4m9s4....@thcsv01.trafford.ford.com> >>>> On the subject of "Re: READ-FROM-STRING considered unsafe? (was Re: Simple Function Question)" >>>> Sent on 20 May 1999 09:21:15 +0100 >>>> Honorable Guy Footring <footr...@thcsv01.trafford.ford.com> writes:
>> Sam Steingold <s...@goems.com> writes: >> > >> > >> > >> "2 + 3i" as complex numbers. >> > >> > so, what should (parse-number "2 + 3i") return? 2? or #C(2 3)? >> > >> The latter. >> > >> > why? you mean `parse-number' will return something different from >> > `parse-integer'? >> >> What about 1.23? You mean parse-number WON'T return something >> different from parse-integer??
Sorry, I should have been more specific.
when both `parse-integer' and `parse-number' return, they should return the same number. when `parse-number' returns a non-integer, `parse-integer' should signal an error.
-- Sam Steingold (http://www.goems.com/~sds) running RedHat6.0 GNU/Linux Micros**t is not the answer. Micros**t is a question, and the answer is Linux, (http://www.linux.org) the choice of the GNU (http://www.gnu.org) generation. NY survival guide: when crossing a street, mind cars, not streetlights.
> >>>> In message <wtwvy4m9s4....@thcsv01.trafford.ford.com> > >>>> On the subject of "Re: READ-FROM-STRING considered unsafe? (was Re: Simple Function Question)" > >>>> Sent on 20 May 1999 09:21:15 +0100 > >>>> Honorable Guy Footring <footr...@thcsv01.trafford.ford.com> writes: > >> Sam Steingold <s...@goems.com> writes:
> >> > >> > >> "2 + 3i" as complex numbers. > >> > >> > so, what should (parse-number "2 + 3i") return? 2? or #C(2 3)? > >> > >> The latter.
> >> > why? you mean `parse-number' will return something different from > >> > `parse-integer'?
> >> What about 1.23? You mean parse-number WON'T return something > >> different from parse-integer??
> Sorry, I should have been more specific.
> when both `parse-integer' and `parse-number' return, they should return > the same number. when `parse-number' returns a non-integer, > `parse-integer' should signal an error.
Both (parse-integer "1 + 2i") and (parse-integer "1.23") raise an error unless :junk-allowed T is specified (at least under LWW4.1 ACL5.0 and an oldish Lucid Unix release).
I don't see that there is a problem with (parse-integer "1.23") => error (parse-integer "1.23" :junk-allowed t) => 1 (parse-float "1.23") => 1.23s0 ;should parse-float take a float type specifier? (parse-number "1.23") => 1.23s0 (parse-integer "1 + 3i") => error (parse-integer "1 + 3i" :junk-allowed t) => 1 (parse-float "1 + 3i") => error (parse-float "1 + 3i" :junk-allowed t) => error? 1.0s0? (parse-number "1 + 3i") => #C(1 3)
> -- > Sam Steingold (http://www.goems.com/~sds) running RedHat6.0 GNU/Linux > Micros**t is not the answer. Micros**t is a question, and the answer is Linux, > (http://www.linux.org) the choice of the GNU (http://www.gnu.org) generation. > NY survival guide: when crossing a street, mind cars, not streetlights.
In article <3136210744251...@naggum.no>, Erik Naggum <e...@naggum.no> wrote:
>* cba...@2xtreme.net (Christopher R. Barry) >| The analogous thing in Lisp with SETF of FORMAT should signal errors.
> FYI, SSCANF returns the number of objects successfully assigned. if you > use the previous value of unassigned variables, it's your own problem.
> BTW, I'd much prefer a binding form than a setting form, complete with > &OPTIONAL and &REST and all, like DESTRUCTURING-BIND.
>#:Erik
If it weren't done using the SETF syntax (which I also don't really care for -- its only virtue is "coolness factor"), I would probably just use a function that returns each of the parsed items as multiple values, which could be bound using MULTIPLE-VALUE-BIND:
(with-input-from-string (s "123 abcde 10") (multiple-value-bind (a b c) (parse-formatted "~d ~s ~o" s) (list a b c))) => (123 ABCDE 8)
-- Barry Margolin, bar...@bbnplanet.com GTE Internetworking, Powered by BBN, Burlington, MA *** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups. Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
Erik Naggum <e...@naggum.no> writes: > BTW, I'd much prefer a binding form than a setting form, complete with > &OPTIONAL and &REST and all, like DESTRUCTURING-BIND.
How would the filter be specified? What is your idea of that this would look like?
(format-bind (a b) "~R" "one hundred fifty-three" (list a b)) ==> Error: insufficient arguments error occurred when associating a value with B
(format-bind (a &optional b) "~R" "one hundred fifty-three" (list a b)) ==> (153 nil)
(format-bind (a b c) "~D~D~D" "123456" (list a b c)) ==> Error: insufficient arguments error occurred when associating a value with B or ==> (123456 nil nil) or something else???
Guy Footring <footr...@thcsv01.trafford.ford.com> writes: > I don't see that there is a problem with > (parse-integer "1.23") => error > (parse-integer "1.23" :junk-allowed t) => 1 > (parse-float "1.23") => 1.23s0 ;should parse-float take a float type specifier? > (parse-number "1.23") => 1.23s0
Note that the whole point of introducing PARSE-NUMBER is to remove the need for a PARSE-FLOAT.
Hrvoje Niksic <hnik...@srce.hr> writes: > Guy Footring <footr...@thcsv01.trafford.ford.com> writes:
> > I don't see that there is a problem with > > (parse-integer "1.23") => error > > (parse-integer "1.23" :junk-allowed t) => 1 > > (parse-float "1.23") => 1.23s0 ;should parse-float take a float type specifier? > > (parse-number "1.23") => 1.23s0
> Note that the whole point of introducing PARSE-NUMBER is to remove the > need for a PARSE-FLOAT.
But the whole point of introducing PARSE-FLOAT is to do what standards do best: to publish what with certainty all implementations already have.
The problem with PARSE-NUMBER is that it is, as described, almost certainly something no implementation presently has or needs, and for any given choice of textual representation of complexes it will likely satisfy only part of the community that thinks it wants a PARSE-NUMBER. (Sort of the way any specific religion like Catholicism or Protestantism or Judaism will satisfy only some subset of the people who think that religion should be taught in school because people always overoptimistically assume that when they ask for a cool thing under a general name that it will do the specifics in a way that is not only not general but that is fortuitously what suits them personally... so while all of Jews and Catholics and Protestants might sign letters to Congress saying they want religion in schools, many would end up also later signing letters saying "get that OTHER religion out of schools" if anyone ever took their proposal seriously.) I think people only want PARSE-NUMBER because they imagine they would all be able to agree on a semantics or that it doesn't matter to them that others won't like their choice because they're assuming they won't be in the set that gets the version they don't like. In practice, if PARSE-NUMBER parses floats and there is no PARSE-FLOAT, then people will be having to do contorted things to screen out representations they don't want (like rationals or complexes) and to reformat other representations they want to be more palatable to PARSE-NUMBER. I'd rather just give them building-blocks of PARSE-INTEGER and PARSE-FLOAT because those are surely in the implementation anyway and then let them build up anything application-specific that they need beyond that.
The number between the '%' and 'd' is the maximum length to scan, but the scan stops earlier if a non-digit is found. Also, scan always skips any white space before it starts reading the next number. All a bit of a mess, really, and not idempotent (which is what you'd like).
Incidentally, whitespace in the scan format is not significant, strangely. But this is not comp.lang.c. So, anyway, I suppose that for (setf (format ...) ...) you could also use the field widths of the format specifiers, to get over the problem of (setf (format nil "~D~D" x y) "123") (which I think should just make x 123 and y nil). Philip
-- The mail transport agent is not liable for any coffee stains in this message --------------------------------------------------------------------------- -- Philip Lijnzaad, lijnz...@ebi.ac.uk | European Bioinformatics Institute +44 (0)1223 49 4639 | Wellcome Trust Genome Campus, Hinxton +44 (0)1223 49 4468 (fax) | Cambridgeshire CB10 1SD, GREAT BRITAIN PGP fingerprint: E1 03 BF 80 94 61 B6 FC 50 3D 1F 64 40 75 FB 53
Hrvoje Niksic <hnik...@srce.hr> writes: > Guy Footring <footr...@thcsv01.trafford.ford.com> writes:
> > I don't see that there is a problem with > > (parse-integer "1.23") => error > > (parse-integer "1.23" :junk-allowed t) => 1 > > (parse-float "1.23") => 1.23s0 ;should parse-float take a float type specifier? > > (parse-number "1.23") => 1.23s0
> Note that the whole point of introducing PARSE-NUMBER is to remove the > need for a PARSE-FLOAT.
just because you have a PARSE-NUMBER doesn't mean PARSE-FLOAT PARSE-SINGLE-FLOAT, PARSE-DOUBLE-FLOAT PARSE-COMPLEX &c shouldn't exist. having the specific forms may be useful in declaring what exactly you mean.
PARSE-NUMBER may be implemented as a wrapper for the specific instances. how about requiring a type in addition to the string?
a fancier implementation could default to infering the type (much as the reader does), i.e., 1 is an integer, 1/2 is a rational, 1s3 is a single-float &c, and take a :type key argument to allow you to specify.
Johan Kullstam <kulls...@ne.mediaone.net> writes: > Hrvoje Niksic <hnik...@srce.hr> writes:
> > Guy Footring <footr...@thcsv01.trafford.ford.com> writes:
> > > I don't see that there is a problem with > > > (parse-integer "1.23") => error > > > (parse-integer "1.23" :junk-allowed t) => 1 > > > (parse-float "1.23") => 1.23s0 ;should parse-float take a float type specifier? > > > (parse-number "1.23") => 1.23s0
> > Note that the whole point of introducing PARSE-NUMBER is to remove the > > need for a PARSE-FLOAT.
> just because you have a PARSE-NUMBER doesn't mean PARSE-FLOAT > PARSE-SINGLE-FLOAT, PARSE-DOUBLE-FLOAT PARSE-COMPLEX &c shouldn't > exist. having the specific forms may be useful in declaring what > exactly you mean.
> PARSE-NUMBER may be implemented as a wrapper for the specific > instances. how about requiring a type in addition to the string?
Let's define N as (read-from-string NUMBER-AS-STRING) and TN as (type-of N).
Then, if (subtypep TN TYPE) == t, the number returned would be N of type TN; else parse-number should signal an error (or return nil, or whatever).
You cannot force N to be of type TYPE unless is possible to have objects for which (type-of OBJECT) == TYPE. Since BIGNUM and FIXNUM are an exhaustive partition of INTEGER, I suppose (perhaps I'm wrong) that if N is an INTEGER, an implementation will return BIGNUM or FIXNUM for (type-of N), and not INTEGER, so
(parse-number N :type 'INTEGER)
should return either a FIXNUM or a BIGNUM as appropriate.
So if someone wants to parse an INTEGER with parse-number, he should use :type 'INTEGER. Using :type 'BIGNUM should be a promise that *really* a BIGNUM is expected.
A problem: May seem counter-intuitive to have
(parse-number "1.0" :type 'DOUBLE-FLOAT)
to return an error, but (typep 1.0 'DOUBLE-FLOAT) is nil, so is not totally illogical. Hmmm...
Juanma Barranquero <barranqu...@laley-actualidad.es> wrote: >A problem: May seem counter-intuitive to have
>(parse-number "1.0" :type 'DOUBLE-FLOAT)
>to return an error, but (typep 1.0 'DOUBLE-FLOAT) is nil, so is not >totally illogical. Hmmm...
Not illogical, but it seems counter to what PARSE-NUMBER seems to be intended for. I thought we were discussing a function that could be used to parse data that isn't necessarily from a Lisp source, e.g. a user. We may want to read in a float, but does that mean that a user who is totally unfamiliar with Lisp should be expected to know that floats have to have an embedded decimal point? It would seem more useful, in this context, to have
(parse-number S :type T)
perform something similar to
(coerce (read-from-string S) T)
-- Barry Margolin, bar...@bbnplanet.com GTE Internetworking, Powered by BBN, Burlington, MA *** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups. Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
> to return an error, but (typep 1.0 'DOUBLE-FLOAT) is nil, so is not > totally illogical. Hmmm...
If you want 1.0 to be read as a DOUBLE-FLOAT, then you write it as 1.0d0. You could have also tried (COERCE 1.0 'DOUBLE-FLOAT) => 1.0d0. You should be able to parse floats as any subtype of FLOAT that you wish, even allowing truncation, since you can do
> > > Guy Footring <footr...@thcsv01.trafford.ford.com> writes:
> > > > I don't see that there is a problem with > > > > (parse-integer "1.23") => error > > > > (parse-integer "1.23" :junk-allowed t) => 1 > > > > (parse-float "1.23") => 1.23s0 ;should parse-float take a float type specifier? > > > > (parse-number "1.23") => 1.23s0
> > > Note that the whole point of introducing PARSE-NUMBER is to remove the > > > need for a PARSE-FLOAT.
> > just because you have a PARSE-NUMBER doesn't mean PARSE-FLOAT > > PARSE-SINGLE-FLOAT, PARSE-DOUBLE-FLOAT PARSE-COMPLEX &c shouldn't > > exist. having the specific forms may be useful in declaring what > > exactly you mean.
> > PARSE-NUMBER may be implemented as a wrapper for the specific > > instances. how about requiring a type in addition to the string?
> (PARSE-NUMBER "2.718281828" :type 'double-float) > Would be better. Contrary to CONCATENATE there is no &rest argument > to deal with. However what would you do with
yes. this reads better.
> (PARSE-NUMBER "2" :type 'NUMBER)
well, anything that would be a number equal to two, i think it would be ok. so as long as
(setq x (parse-number "2" :type 'number))
(and (numberp x) (= x 2))
returns t, i would be happy.
thus 2 or 2d0 could be valid values.
i think using the most specific type possible for the return would be best. hence i might be surprised if i didn't get a fixnum in the above case.
if you want a more specific answer, it would behoove you to be more specific!
* * *
the general reading problem, as i see it, is this:
in printing from lisp, you have lots of information such as the type. therefore format can make do with things like ~A which work with most anything.
when you read, you have no idea what you're reading. the type information needs to be inferred from syntax (like the full lisp-reader) or supplied from somewhere else (like parse-integer explicitly calls out integer).
in light of the asymmetry of knowledge wrt to type information, something like
(setf x (format "2" "~A"))
has no hope of working.
C has no idea what type anything is in. you have to explicitly supply types in the format string in both input and output cases. therefore printf and scanf format strings look (mostly) the same.[1]
since this problem is not limited to numbers, how would one go about reading some arbitrary type such as a vector or structure? perhaps we should say nothing about hash-tables.
[1] C cannot pass floats, only doubles hence both floats and doubles are printed with %f but scanned with %f and %lf respectively.
<bar...@bbnplanet.com> wrote: >I thought we were discussing a function that could be used >to parse data that isn't necessarily from a Lisp source, e.g. a user.
Then
(parse-number "1.0" :type 'FLOAT)
will do (or 'REAL, 'NUMBER). Use as general a type as needed. I assumed :type 'BIGNUM or 'DOUBLE-FLOAT or other more specific types would be used for reading data where we *know for sure* what's being read (not from the user, but from a C-generated file, for example). I see no contradiction.
>We may want to read in a float, but does that mean that a user who is >totally unfamiliar with Lisp should be expected to know that floats >have to have an embedded decimal point?
Then (float (parse-number NUMBER-AS-STRING :type 'REAL) 1.0d0) and check for errors.
>It would seem more useful, in this context, to have
>(parse-number S :type T)
>perform something similar to
>(coerce (read-from-string S) T)
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]
so in fact, as Marco Antoniotti pointed to me, if you want generality at read time, you're *forced* to ask for a more general type and coerce to (type-of N), i.e., a subtype of T and not T.
That's why I said that parse-number *cannot* always return the asked for type, but only a subtype of it. As I see it, it's a no-win situation. There are two sensible ways to define the return value of:
(parse-number N-AS-S :type T)
1.- You expect parse-number to coerce the number to T (with an error if it cannot deliver, as in the BIGNUM example), or
2.- parse-number returns a number of the most appropriate subtype of T, and you manually coerce the number and/or check for errors (as in the 'REAL example above) if needed.
I prefer the second alternative.
/L/e/k/t/u
P.S.: Sorry if I'm not being very intelligible; I've rewritten this message a couple times, but my English is failing me miserably :(
* Juanma Barranquero wrote: > (parse-number "1.0" :type 'DOUBLE-FLOAT) > to return an error, but (typep 1.0 'DOUBLE-FLOAT) is nil, so is not > totally illogical. Hmmm...
