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 the following: #lang racket (module string-server racket (require racket/generic) (provide gen:can-be-string can-be-string? (contract-out [to-string (-> any/c string?)] )) (define-generics can-be-string (to-string can-be-string) #:fast-defaults ([string? (define (to-string str) str)]))) (module buggy racket (require (submod ".." string-server)) (provide (struct-out buggy)) (struct buggy () #:methods gen:can-be-string [(define (to-string this) 'not-a-string)])) (require (submod "." string-server) (submod "." buggy)) (to-string (buggy)) This program raises an exception as expected, but blames the string-server module rather than the buggy module. The string-server module can deflect blame from itself by changing the contract of to-string to (-> (can-be-string/c [to-string (-> any/c string?)]) string?), but the result is even worse: now the error blames the enclosing module. The closest thing I've found to a solution is to abandon racket/generic and use a struct type property with a guard that performs lots of checks and eventually calls chaperone-procedure. Aside from being verbose and error-prone (in that it requires manually writing checks correctly rather than relying the contract system), it also doesn't really address the problem of blame, since errors from e.g. raise-arguments-error don't blame anything in particular. Is there a way to write the kind of contract I have in mind? Thanks, Philip -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.