Thanks for the info. It makes sense that if I drop down to the lower level of struct definition that I would need to do the same with contracts.
> On Apr 15, 2015, at 6:07 PM, Robby Findler <[email protected]> > wrote: > > I think you have to drop to the lower-level and work directly with the > 'contract' form. The implementation of contract-out might provide some > inspiration. But the contract system actually exports the identifier > as syntax in order to be able to pick up the name of the party that is > importing the function. > > Sorry I don't have a better answer for you. > > Robby > > >> On Wed, Apr 15, 2015 at 1:29 PM, Jon Zeppieri <[email protected]> wrote: >> I'm trying to provide a struct, the struct type of which uses >> prop:procedure and prop:match-expander, and I'd like the procedure to >> have a contract. >> >> If I simply (provide <identifier>) then both the procedure binding and >> transformer binding are exported, but if I (provide/contract >> [<identifier> <contract>]), then only the procedure is exported, and I >> can't separately export the transformer binding with the same name. >> >> Presumably, I could attach a contract to the procedure prior to >> exporting it -- I could, for example, define it using define/contract >> -- but then the wrong module would be blamed. >> >> What's the best way to handle this case? >> >> -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 [email protected]. >> 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
