Re: [racket-users] Contracts for generic interfaces (or struct type properties?)

2017-05-24 Thread Ben Greenman
On Wed, May 24, 2017 at 3:56 PM, Philip McGrath wrote: > I think support for this sort of boundry would be a valuable addition to > the generics library. +2, one for me and one on behalf of issue #1440 -- You received this message because you are subscribed to the Google Groups "Racket Users

Re: [racket-users] Contracts for generic interfaces (or struct type properties?)

2017-05-24 Thread Philip McGrath
I was interested after getting your reply in what racket/dict does, it it seems to get blamed for bad implementations of the dict-set method: (struct bad-dict () #:methods gen:dict [(define (dict-set this k v) 'not-a-new-dict)]) (dict-set (bad-dict) 'a #t) dict-set: broke its own contra

Re: [racket-users] Contracts for generic interfaces (or struct type properties?)

2017-05-23 Thread Vincent St-Amour
Hi Philip, I don't think you can express the contract boundary you have in mind using the generics library as it is. The blame you see for both contracts makes sense. In the first case, `string-server` is not protecting itself from bad inputs (uses `any/c`) yet promises to return a string. It rig

[racket-users] Contracts for generic interfaces (or struct type properties?)

2017-05-22 Thread Philip McGrath
I'm running into trouble in trying to give contracts to methods from generic interfaces (in the sense of racket/generic) that assign blame to the implementor of a bad method implementation. This seems like it's probably a common problem, so I'm hoping a solution exists. For an example, consider th