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

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
<robby at 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.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
> >> >
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/dev/archive/attachments/20101025/06af9f4a/attachment.html>