I will implement the change locally, and see what a DrDr house call reports.
If that sounds promising, I'll check PLaneT packages too. (On a side note, house calls are great! It would be nice to have something like that for PLaneT too. Something like: download all the packages, make sure they build, and if they have tests, make run them. That would be useful any time someone makes a backwards-incompatible change.) Vincent At Fri, 30 Sep 2011 10:20:36 -0600, Matthew Flatt wrote: > > I think this is a good change for the next language, but not for `#lang > racket'. > > As confusing as the current `integer?' may be, I think its definition > is deeply wired into our code, tests, and documentation. I may guess > wrong, but my best estimate of the hassle for this change is that it's > too much trouble for too little payoff, and we could spend our energy > on more interesting things. > > At Fri, 30 Sep 2011 11:59:25 -0400, Vincent St-Amour wrote: > > On a more general note, do we really need inexact integers? > > > > The behavior of `integer?' is confusing, and I don't see especially > > compelling reasons to keep it this way. The subject comes up every > > couple of months on the mailing list, so we should do something about it. > > > > Here's a proposal: > > `integer?' becomes the same as `exact-integer?' (which is kept for > > backwards compatibility). > > `positive-integer?' and `nonnegative-integer?' are added as > > equivalents to their `exact' counterparts. > > `inexact-integer?' is added, to cover for the use case of checking is > > an inexact number has been rounded. > > > > I volunteer to implement this if we agree that this is the right > > thing. > > > > Vincent > > > > > > > > At Fri, 30 Sep 2011 07:16:22 -0600, > > Doug Williams wrote: > > > > > > Another such annoyance is than (min 1 +inf.0) => 1.0 - because if any > > > argument is inexact, the result is inexact. I don't think this makes sense > > > in the case of infinities. Infinities are very useful as initial values > > > for > > > things that are being minimized or maximized, but there is always the need > > > for inexact->exact to protect against the (unexpected) coercion. > > > > > > This is all from the original R5RS and continued in R6RS - but, we aren't > > > that language. > > > > > > Could we get an exception to the coercions in the case of +/-inf.0? Or an > > > alternative min/max that don't do it? > > > > > > On Fri, Sep 30, 2011 at 6:53 AM, Matthias Felleisen > > <matth...@ccs.neu.edu>wrote: > > > > > > > > > > > exact-round is preferred. > > > > > > > > > > > > > > > > On Sep 30, 2011, at 8:51 AM, Eli Barzilay wrote: > > > > > > > > > Yesterday, Ryan Culpepper wrote: > > > > >> The pragmatic answer is you generally have to write > > > > >> > > > > >> (inexact->exact (round x)) > > > > >> > > > > >> which is annoying, but no one has yet bothered to add a standard > > > > >> library function for this, as far as I know. > > > > > > > > > > [From the annoyed side, especially since that thing tends to come in > > > > > bunches which can make some quick code look much heavier than it is:] > > > > > > > > > > Maybe it's time to add something for that? `eround'? (But even > > > > > `exact-round' would be better than the above.) > > > > > > > > > > -- > > > > > ((lambda (x) (x x)) (lambda (x) (x x))) Eli > > > > > Barzilay: > > > > > http://barzilay.org/ Maze is > > > > > Life! > > > > > _________________________________________________ > > > > > For list-related administrative tasks: > > > > > http://lists.racket-lang.org/listinfo/users > > > > > > > > _________________________________________________ > > > > For list-related administrative tasks: > > > > http://lists.racket-lang.org/listinfo/users > > > > > > _________________________________________________ > > For list-related administrative tasks: > > http://lists.racket-lang.org/listinfo/dev _________________________________________________ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
