gen:dict contracts

[Andrew Kent]

I personally find the performance overhead added by the dependent contracts in racket/dict to be too burdensome for general use in large applications. I would be much happier if the default interface was instead comprised of the simple contracts the documentation for gen:dict seems to suggest.

Am I in a small minority with this opinion? Would people be amicable to a PR that simplified these contracts? Or would losing the extra contract checking be a noticeable drawback for some projects?

As an anecdotal side note: this overhead initially gave me a bad taste in my mouth for Racket's generics (I initially thought they were to blame for the performance slowdown). It wasn't until later that I realized the overhead from using generics is _quite reasonable_ (I've used them in Typed Racket to speed things up in fact) and that really this is an issue of the pros and cons of using expressive, dependent contracts. Anyway, I hope others haven't been similarly turned off to generics (which are awesome!) if they've noticed undesirable overhead while trying out racket/dict.

Best,
Andrew

P.S. I think ideally both interfaces should be provided (one with simple contracts and one without) but doing this right might require some tools that haven't been invented yet (in particular, this seems like another use case for what I like to call "negotiable contracts," which would allow modules to provide multiple contract options for identifiers that a requiring module could then specify at compile time which they want with a require form -- I should really get on this...)

[Robby Findler]

I think that the contract system has a lot of room for improvement in
the dependent contract checking. In particular, if you think about the
actual checks that happen for these particular contracts, I think you
could believe that they aren't more expensive than the independent
variants. Of course, convincing the contract system of that .....

but maybe it makes sense for there to be some special case in the
contract system for these specific contracts. They have been trouble
for some time now.

Robby

> --
> You received this message because you are subscribed to the Google Groups
> "Racket Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to racket-dev+...@googlegroups.com.
> To post to this group, send email to racke...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/racket-dev/2fcb793a-c808-4093-ba5a-ce3b35413905%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Matthias Felleisen]

> P.S. I think ideally both interfaces should be provided (one with simple contracts and one without) but doing this right might require some tools that haven't been invented yet (in particular, this seems like another use case for what I like to call "negotiable contracts," which would allow modules to provide multiple contract options for identifiers that a requiring module could then specify at compile time which they want with a require form -- I should really get on this…)



1. I think this is a place where we could experiment with ‘option contracts’.

2. I think this also makes a great place where we could experiment with supplying two variants:

— gen:dict-with
- gen:dict-out

or whatever. They can use the same source module in a private directory and offer two interfaces.

We could even go to three. The interesting question would then become whether people
switch to . . . -with when things blow up inside of gen:dict so that they get better
error messages. That would partly confirm our ‘contract pressure’ conjecture.

In general I don’t see why we need more work per se. We can offer several options,
including option contracts.

— Matthias