On Thu, Jun 9, 2016 at 2:24 PM, Alex Knauth <alexan...@knauth.org> wrote:
> > > There's `define-module-boundary-contract`, which does something similar to > `define/contract` except that it uses the module as a boundary instead of > creating it's own: > > http://docs.racket-lang.org/reference/attaching-contracts-to-values.html?q=contract%20module%20boundary#%28form._%28%28lib._racket%2Fcontract%2Fprivate%2Fprovide..rkt%29._define-module-boundary-contract%29%29 > > > Thanks Alex, that's helpful. Now there's an additional wrinkle. Let's say that `date` is provided by a private module and then re-provided from a public one. We can either: - use `date` without a contract internally and add the contract at the public module boundary, or - add the contract at the private module boundary (so that other modules in the same package are required to obey the contract), in which case we'd like to change the positive blame assignment when we re-export the identifier from the public module. The first option seems straightforward, given your previous reply. The second seems straightforward only if we're willing to add a contract to the already-contracted function. `recontract-out` is supposed to help with this case, but it only works if the identifier was originally provided with `contract-out`, and we can't use `contract-out`, since it won't allow the identifier to be used as a match expander. There doesn't seem to be a way to grab the un-contracted value from the impersonator created by either `define/contract` or `define-module-boundary-contract`. Ideally, I'd be able to specify a custom constructor (and match expander) with `struct`, and everything would be taken care of by `(provide (struct-out ...))` or `(provide/contract (struct ...))`. - Jon -- 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.
