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 <div class="gmail_quote">On Mon, Oct 25, 2010 at 8:46 AM, Robby Findler <<a href="mailto:robby@eecs.northwestern.edu">robby@eecs.northwestern.edu</a>> wrote: <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> 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 <div><div></div><div class="h5"><<a href="mailto:m.douglas.williams@gmail.com">m.douglas.williams@gmail.com</a>> 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 <<a href="mailto:robby@eecs.northwestern.edu">robby@eecs.northwestern.edu</a>> > 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 >> <<a href="mailto:m.douglas.williams@gmail.com">m.douglas.williams@gmail.com</a>> 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 <<a href="mailto:mflatt@cs.utah.edu">mflatt@cs.utah.edu</a>> >> > 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: >> > <a href="http://lists.racket-lang.org/listinfo/dev" target="_blank">http://lists.racket-lang.org/listinfo/dev</a> >> > > > </div></div></blockquote></div>