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 rightly gets blamed when that doesn't happen. In the second case, `string-server` does protect itself (using `can-be-string/c`), but it protects itself against its callers, who now have the responsibility to pass it something reasonable. It doesn't (passes the `buggy` struct along), so it rightly gets blamed. To get the contract boundary that you want, I think you'd want to wrap the `buggy` constructor with a contract that makes it commit to producing a valid `can-be-string`. You could do this either when you export it from the `buggy` module, or by "laundering" it through a submodule before getting it to the main module. That way, it should end up being blamed. This is not a great solution, because you'd have to do this for every instance of the generic interface, but the class of boundaries you have in mind cannot currently be described, I think. Vincent On Mon, 22 May 2017 22:31:25 -0500, Philip McGrath wrote: > > 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. -- 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.
