I had always assumed that case-lambda just checked alternatives in order until one matched - like a cond. But, that was just an assumption on my part and subject to being absolutely wrong. [But, if it is correct I would expect case-> to allow overlapping contracts.]
Another thing I just noticed is that the documentation says that case-lambda is provided by scheme/base and scheme - and doesn't mention racket/base or racket. To me that implies that isn't available in the racket language, but I'm sure it is. Is that a documentation error? But lambda says the same thing, so I guess it is a misinterpretation on my part of what scheme versus racket means in the docs. Doug On Mon, Oct 25, 2010 at 8:46 AM, Robby Findler <ro...@eecs.northwestern.edu>wrote: > Thanks, that's a great example. The idea (at least from the contract's > point of view) is that there are two different functions with one name > that have two different arities, I think. > > So maybe the right way to bring back case-> is that contracts that > match functions should come with some way to find out what arities > they can match (this is kind of there implicitly now, but probably > needs to be explicit) and then say that either there is no overlap or > there is an ordering so that, given a function with some specific > arity (arities) it gets slotted into particular parts of the contracts > inside the case->. (thinking a little bit, I guess that we'd have to > say that there should not be any overlap or else we'd have to kind of > mix and match parts of contracts to parts of functions that seems > pretty complex (if that's too opaque I can give an example to explain > what I meant)) > > Robby > > On Mon, Oct 25, 2010 at 9:06 AM, Doug Williams > <m.douglas.willi...@gmail.com> wrote: > > Here is one example. > > > > (make-discrete-histogram > > (case-> (->r ((n1 integer?) > > (n2 (and/c integer? > > (>=/c n1))) > > (dynamic? boolean?)) > > discrete-histogram?) > > (->r ((n1 integer?) > > (n2 (and/c integer? > > (>=/c n1)))) > > discrete-histogram?) > > (-> discrete-histogram?))) > > > > This code predates optional and keyword parameters. In cases like this, I > > can rewrite them using optional parameters. > > > > But, in the random distribution functions it is the first argument that > is > > optional and that won't work. So, for example the flat (i.e., uniform) > > distribution includes a contract: > > > > (case-> (->r ((r random-source?) > > (a real?) > > (b (>/c a))) > > real?) > > (->r ((a real?) > > (b (>/c a))) > > real?))) > > > > I'm not sure that one can be easily rewritten in the current contract > > system. [I think I would have to move the b > a constraint into the code > > itself in the current contract system. Or, change the argument order and > > break backward compatibility.] > > > > Doug > > > > > > On Sun, Oct 24, 2010 at 6:23 PM, Robby Findler < > ro...@eecs.northwestern.edu> > > wrote: > >> > >> The new case-> only supports simple contracts, that's right. If you > >> have more complex ones that it would be helpful to support (and can > >> share them), that would help us guide our efforts. > >> > >> Thanks, > >> Robby > >> > >> On Sun, Oct 24, 2010 at 7:04 PM, Doug Williams > >> <m.douglas.willi...@gmail.com> wrote: > >> > The main problem I'm having is that the code has been around awhile > and > >> > hasn't been fully converted to Racket - in particular it uses the > scheme > >> > language (instead of the racket language) and uses (require (lib > >> > contract)). > >> > All of that seems to mean that I can't just add #:flat? #t - I get a > >> > message > >> > that vector-of doesn't accept keyword arguments. And, the case-> > >> > contracts > >> > use ->r, which apparently isn't supported anymore. All that means that > I > >> > can't just switch to the racket language and new contracts. So, I > have > >> > some > >> > conversion work to do. > >> > > >> > On the case-> problem, it seems it no longer supports anything but ->. > >> > Is > >> > there something I am missing there? > >> > > >> > Doug > >> > > >> > On Sun, Oct 24, 2010 at 8:53 AM, Matthew Flatt <mfl...@cs.utah.edu> > >> > wrote: > >> >> > >> >> At Fri, 22 Oct 2010 21:31:43 -0600, Doug Williams wrote: > >> >> > Matthew, would it make more sense to have unsafe-vector-ref (and > >> >> > related > >> >> > functions) be the more general function and unsafe-vector*-ref be > the > >> >> > one > >> >> > that doesn't work on chaperoned vectors? That is just swap the > >> >> > definitions. > >> >> > That way user code that is already using unsafe-vector-ref (etc) > will > >> >> > continue to work. > >> >> > > >> >> > As it stands, existing code that has unsafe-vector-ref (etc) will > >> >> > often > >> >> > still work (in the sense of not getting any error or crashing), but > >> >> > just > >> >> > gives the wrong results. For example, if you run science-test.ss > from > >> >> > the > >> >> > examples directory in the science collection, there are no errors. > >> >> > But, > >> >> > some > >> >> > of the answers are wrong - for example the very first one, the > gamma > >> >> > function. [In other cases, like the FFT routines, there are either > >> >> > run-time > >> >> > errors or crashes.] > >> >> > > >> >> > Anyway, if it isn't too late, I think swapping the definitions > would > >> >> > make > >> >> > more sense and be safer. > >> >> > >> >> I've gone back and forth. I agree that it would be safer, but > >> >> `vector-ref' is safer still, and I think of the job of `unsafe-X' as > >> >> providing the lowest possible overhead over `X'. It seems nicer to me > >> >> to have `*' mean "somewhere in between" rather than "even faster". > Then > >> >> again, it seems bad that `vector?' (plus index bounds) isn't enough > to > >> >> guard `unsafe-vector-ref'. > >> >> > >> >> Overall, at this point in the release cycle, I'm inclined to leave > >> >> things where they are (i.e., it may be too late). But let's hear more > >> >> opinions from those who use `unsafe-vector-ref' and > >> >> unsafe-vector*-ref'. > >> >> > >> > > >> > > >> > _________________________________________________ > >> > For list-related administrative tasks: > >> > http://lists.racket-lang.org/listinfo/dev > >> > > > > > >
_________________________________________________ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
