On Fri, Sep 30, 2011 at 12:28 PM, Matthias Felleisen <matth...@ccs.neu.edu> wrote: > > I sent this to Matthew privately but I think we need to be > much more careful with 'interesting'. While you are right > about the 'wired into our code' part, I think the two of > you are wrong about the 'interesting' part. > > From a type perspective, the numeric tower comes with major > flaws and it would be wonderful if a language that divorces > itself from the old flawed Scheme world could make a clean > cut and do better.
I didn't mean to say that this wasn't interesting. The uninteresting thing, in my mind, is coping with the fallout of the specific changes that Vincent proposed. Some larger effort at a better design is whole different beast. Robby > But I am also the person who preaches 'the path from here to > there' and agree that the 'wired' argument for the existing > code base and outside consumers tells us that Racket isn't > the language that can fix these mistakes. > > > > > On Sep 30, 2011, at 12:32 PM, Robby Findler wrote: > >> This is my opinion, too. >> >> Robby >> >> On Fri, Sep 30, 2011 at 11:20 AM, Matthew Flatt <mfl...@cs.utah.edu> 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 >>> >> >> _________________________________________________ >> For list-related administrative tasks: >> http://lists.racket-lang.org/listinfo/dev > > _________________________________________________ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
