Does this also mean that procedures like round, floor and ceiling will produce exact integers even when given an inexact argument? I am not sure this would be a good idea. For example consider: Now (round #i1e200) -> flonum of 64 bits. But (inexact->exact (round #i1e200)) -> exact integer of over 600 bits. Nevertheless the idea of making a distinction between integer? and inexact-integer? (or whatever you want to name them) seems to be a good idea. However, we already have integer? and exact-integer? Am I missing the pointe of the discussion? Jos
> -----Original Message----- > From: dev-boun...@racket-lang.org > [mailto:dev-boun...@racket-lang.org] On Behalf Of Robby Findler > Sent: 13 December 2010 14:29 > To: Sam Tobin-Hochstadt > Cc: dev@racket-lang.org > Subject: Re: [racket-dev] (round), etc. in Typed Racket > > On Sat, Dec 11, 2010 at 9:53 PM, Robby Findler > <ro...@eecs.northwestern.edu> wrote: > > [ ... talking about changing integer? to only recognize > exacts ... ] > > This seems like it would cause far too much breakage to far > too much > > code. I certainly wouldn't want to attempt it. Changing TR (as I > > suggest below) seems far easier. > > Well, I went and took a look at the tree for uses of integer? > and I'm finding that most of them have exact? nearby and some > of the ones that don't probably should. (I used DrRacket's > find in files with the regexp [^-]integer[?].) > > So, I'm changing my opinion to say that it would be feasible > to have integer? in #lang racket/base mean what the current > exact-integer? > means. Probably we'd want to add an inexact-integer? and then > legitimate uses of the current integer? predicate would turn > into (lambda (x) (or (integer? x) (inexact-integer? x))). > > It would be some work to make all of the changes in the tree > (and it would probably be polite to audit the latest version > of active planet > packages) but it doesn't seem to be as deadly as I'd feared. > Also, after having that look, I definitely think that if we > got to do this one over that integer? accepting only exacts > is wise; it seems too easy to allow inexacts to flow around > when you didn't mean to with the current definition of the predicates. > > Robby > _________________________________________________ > For list-related administrative tasks: > http://lists.racket-lang.org/listinfo/dev _________________________________________________ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev