> You should be able to parse floats as any subtype of FLOAT that > you wish, even allowing truncation, since you can do
Yes, the thing is useless unless it can read 1.0 as any kind of float you like, otherwise you lose precision parsing "1.003984759478985" I'm not *sure* it's useless unless it can read "1" as a float too, I'd certainly like it to be able to if it existed, to save having to wrap all my calls to it by a COERCE.
On 25 May 1999 00:09:35 +0100, Tim Bradshaw <t...@tfeb.org> wrote:
>* *read-default-float-format* >double-float
Well, you're right. Still, that only means that an hypothetical parse-number would have to take *read-default-float-format* into account (or bind it to the default 'single-float).
What I thought we were discussing is how to determine if parse-number can be designed so its working is fully specified, logical (and/or intuitive) *and* useful. I think we've already determined it's not so trivial a function as to not be worth including in the standard; at least is far less trivial to implement than parse-integer.
So far, the problem is not if parse-number can read a float or not, but what to do when the data input and the asked-for type are in conflict. If the programmer has bound/set *read-default-float-format* to 'double-float and then he does
(parse-number "1.0" :type 'single-float)
what kind of error is that? A bug in the working (or specification) of parse-number, or a programmer error? I'd say the later. And anyway, for user input, as it's been said in earlier messages, it seems a lot less error prone to use more generic number types (FLOAT, REAL, INTEGER) and then coerce the result.
>PARSE-FLOAT is so much easier.
The parse-number we're discussing could act as a parse-integer, parse-rational, parse-float, parse-real and *still* have more specialized uses (with more specialized :type parameters). I definitively see it as very useful.
* barranqu...@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
* Johan Kullstam <kulls...@ne.mediaone.net> | [1] C cannot pass floats, only doubles hence both floats and doubles | are printed with %f but scanned with %f and %lf respectively.
FWIW, this is no longer true. ANSI C, published a decade ago, specified that if the prototype is in scope, a function call should coerce an argument to the appropriate numeric type, including short, float, etc, and the function can expect the object to have the specified type. if the prototype is not in scope, certain defaults apply that should cause an error to be reported when a conflicting prototype is seen.
the reason C cannot do %f as anything but double is that there is no prototype for printf (etc) that could request any particular type, hence the default conversions apply.
#:Erik -- @1999-07-22T00:37:33Z -- pi billion seconds since the turn of the century
On 25 May 1999 13:03:13 +0000, Erik Naggum <e...@naggum.no> wrote:
> 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 have no obsession with bignums and fixnums. I am merely stating that, were parse-number to be defined with a type parameter (like Johan Kullstam proposed, not me), Marco Antoniotti's concern about the behavior of
(parse-number "2" :type 'number)
is also valid with respect to the case when :type is a bignum, fixnum, rational, single-float, etc. and that the type of parse-number's result *cannot* be expected to be exactly the type T specified to parse-number, but only a subtype of it. That's all I'm saying (well, I'm also saying I still find parse-number to be potentially useful).
> 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.
* Juanma Barranquero wrote: > -----BEGIN PGP SIGNED MESSAGE----- > So far, the problem is not if parse-number can read a float or not, > but what to do when the data input and the asked-for type are in > conflict. If the programmer has bound/set *read-default-float-format* > to 'double-float and then he does > (parse-number "1.0" :type 'single-float) > what kind of error is that? A bug in the working (or specification) of > parse-number, or a programmer error? I'd say the later. And anyway, > for user input, as it's been said in earlier messages,
Half the point of the wretched thing is that it should be a *function*, something that returns a result dependent on its arguments, not on some obscure set of global variables.
It should also, I think, (as Kent Pitman pointed out) expose functionality that is required in an implementation anyway, which is what PARSE-FLOAT does, and PARSE-NUMBER does not do.
Erik Naggum <e...@naggum.no> writes: > 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.
Something like PEEK-READ and PEEK-READ-FROM-STRING
come to mind. Setting up an UNWIND-PROTECT form to deal with every error you might encounter in a rational way is just impossible.... How would you work out the details of this though?
But if you wanted access to the function's arguments would you then manually parse the string for them or would you want PEEK-READ-FROM-STRING to have some way of doing this to? If the former, then this doesn't seem _much_ better than parsing a "(...)" form and testing the CAR for FDEFINITION to see if it's a #<FUNCTION...> anyways.
Anyways, yes, CL needs at least a simple facility for doing this.
On 25 May 1999 18:11:43 +0100, Tim Bradshaw <t...@tfeb.org> wrote:
>Half the point of the wretched thing is that it should be a >*function*, something that returns a result dependent on its >arguments, not on some obscure set of global variables.
Well, we're discussing how should it work, so maybe that's a better solution (not depending of *read-default-float-format*, I mean). Let's not forget that parse-integer has a :radix keyword parameter and does not depend on the value of *read-base*.
>It should also, I think, (as Kent Pitman pointed out) expose >functionality that is required in an implementation anyway, which >is what PARSE-FLOAT does, and PARSE-NUMBER does not do.
Perhaps that's the better way, but I feel that, either parse-float ends being very similar to parse-number (accepting integer values and coercing them to floats, etc.), or the programmers will have to implement their own parse-number with parse-{integer,float} for reading user-supplied values and the like.
* Erik Naggum <e...@naggum.no> | 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.
* Christopher R. Barry <cba...@2xtreme.net> | Something like PEEK-READ and PEEK-READ-FROM-STRING | | (peek-read-from-string "1/0") | => #<DIVISION-BY-ZERO>
no, nothing like that at all. let's call it PRETEND-READ. what I want PRETEND-READ to return is the _type_ of the object READ would return, and it should _not_ do error processing. I actually want to capture the syntactic type of the object before it fails to get created.
| Cases like | | (ignore-errors | (read-from-string | "(arbitrary-function-call-invoking-massive-global-state-change)")) | | come to mind.
READ doesn't call EVAL voluntarily. and #. can be killed in two ways: binding *READ-EVAL* to NIL, and nuking #\# #\. in the readtable.
| But if you wanted access to the function's arguments would you then | manually parse the string for them or would you want | PEEK-READ-FROM-STRING to have some way of doing this to?
I think you just need to evaluate the above example expression to see what it actually returns.
| If the former, then this doesn't seem _much_ better than parsing a | "(...)" form and testing the CAR for FDEFINITION to see if it's a | #<FUNCTION...> anyways.
look, READ doesn't do _any_ magic with the forms it reads. READ converts the string representation produced by WRITE into the internal form once given to WRITE. that we write source code in like manner is no accident, but looking up the _values_ of symbols is not what READ does.
it seems to me you're thinking in some over-simplified Scheme terms.
BTW, in order to sanely capture errors when reading random input, I do some fairly complex shenanigans:
(defun safe-read-with-string (input) "Read an expression off of INPUT. Return the parse value and the string. If an error occurs, the error is returned in place of the value." (with-open-stream (string (make-string-output-stream)) (with-open-stream (echo (make-echo-stream input string)) (handler-case (let ((*read-suppress* t) (*read-eval* nil)) (read-preserving-whitespace echo) (values)) (error (error) (values error (get-output-stream-string string))) (:no-error () (let ((string (get-output-stream-string string))) (handler-case (values (read-from-string string) string) (error (error) (values error string)))))))))
this means I can easily capture the offending string, which I would otherwise lose, and use it for error messages, and I can be ensured that what has been read has been as complete an object as possible, as opposed to when reading stops short in the middle of a list and it's non-trivial to get yourself back on track unless you cop out and CLEAR-INPUT. ouch!
(that this function is also used to capture the string representation of the object because the string representation is subject to MD5 checksums only adds to its utility and does not detract from the principal problem.)
#:Erik -- @1999-07-22T00:37:33Z -- pi billion seconds since the turn of the century
* Juanma Barranquero wrote: > Perhaps that's the better way, but I feel that, either parse-float > ends being very similar to parse-number (accepting integer values and > coercing them to floats, etc.), or the programmers will have to > implement their own parse-number with parse-{integer,float} for > reading user-supplied values and the like.
Well, the problem is that PARSE-NUMBER (if it is rightly named) needs to deal with complexes and that's a huge nightmare. PARSE-REAL might be better.
On 26 May 1999 00:23:48 +0100, Tim Bradshaw <t...@tfeb.org> wrote:
>Well, the problem is that PARSE-NUMBER (if it is rightly named) needs >to deal with complexes and that's a huge nightmare. PARSE-REAL might >be better.
Yes, you're right. I read the comments by Sam Steingold about 2+3i, 2i+4j, etc. so I was very busy tiptoeing past the issue of complexes :)
