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
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
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
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
4 matches
Mail list logo