[racket-dev] Release for v5.0.2 has begun

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.williams at 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 <robby at 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.williams at 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 <mflatt at 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
>> >
>
>