Here's another minimally-tested sample implementation. A more robust solution might try to chaperone the struct type, as well, to protect reflective access to the constructor—but I wonder if that really makes sense when you are working with prefab structs. If you can explain more about your requirements, it might be possible to suggest better approaches.
On Sun, May 9, 2021 at 7:57 PM Ryan Culpepper <rmculpepp...@gmail.com> wrote: > I'm not clear on what constraints you're working under with respect to > modules, but hopefully you can adapt this to your needs. > > One option is to use a combination of `define-module-boundary-contract` > (or `define/contract`) and `define-match-expander` to bind a name that can > be used as a contracted constructor and as a match pattern. (If you want to > extend the struct type, though, you still need to use the real one.) > > Another option would be to "forge" a new compile-time struct-info based on > the original struct-info but replacing the constructor. > > Minimally tested sample implementations attached. > > Ryan > > > On Mon, May 10, 2021 at 12:23 AM Sage Gerard <s...@sagegerard.com> wrote: > >> I have a project with 57 prefab structure types. I need to construct >> instances using a *local* contract (module level contracts do not fit my >> needs here). Since I cannot define guards, the solution is easy enough. >> (struct foo (num) #:prefab) >> (define/contract make-foo (-> real? foo?) foo) >> >> Problem: I already have a few hundred constructor calls without >> contracts. I could either A) rewrite them all to use contracted >> constructors, or B) attach local contracts in a sweet spot so that I don't >> have to rewrite anything else. >> >> I prefer option B, but it doesn't look like I can attach a local contract >> to a constructor with `struct` alone, or even with an impersonator. When I >> hack around to rebind or hide the constructor's identifier, I break >> compatibility with `match` and `defstruct*`. >> >> If you were in my position, what would you do? >> -- >> >> ~slg >> >> -- >> 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. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/racket-users/0a16cfbe-4789-a939-796e-5f6f9da21626%40sagegerard.com >> <https://groups.google.com/d/msgid/racket-users/0a16cfbe-4789-a939-796e-5f6f9da21626%40sagegerard.com?utm_medium=email&utm_source=footer> >> . >> > -- > 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. > To view this discussion on the web visit > https://groups.google.com/d/msgid/racket-users/CANy33qmngGoVoAok6%2BR885jkh8MroMqYHpOd6XtjCSH7iiESQA%40mail.gmail.com > <https://groups.google.com/d/msgid/racket-users/CANy33qmngGoVoAok6%2BR885jkh8MroMqYHpOd6XtjCSH7iiESQA%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/01000179539521f3-7e3fc7cf-409e-4574-8917-5d2ef798fa1c-000000%40email.amazonses.com.
prefab-transformer.rkt
Description: Binary data
