Of course, if you're okay with a longer email. Before that, thank you both for volunteering your time to code something out. I enjoyed running into a `define-module-boundary-contract` in the wild for the first time.
I sometimes print output in a (read)able form because I like analyzing my logs. The data I print includes prefab structures, with type ids matching the topic they cover or the statements they make. You can see that I declare prefab structure (sub)types cutely labeled "messages" here. [1] The idea is that I can either print (for example) a $package:output:built instance as a localized string, or just toss the instance itself into writeln. When I read instances back from a port, the struct accessors will help me filter and match. Hopefully all this shows where my head is. Now for the problem. Look at [2], but don't worry about what it means. I just wanted you to see the constructor call in the exception handler. If I made a mistake and wrote that line such the exception was placed directly in the instance, then I wouldn't be able to (read) that instance back later! I cannot allow #<...> forms in my output, or some symbol soup that happens to be readable, but doesn't constitute the value it used to be. TL;DR I want to protect the invariant `(equal? V (read (open-input-string (~s V))))` for each V I print to an output port. Finally, as to why I didn't want the module boundary contract. The module that declares prefab structure types is also primarily responsible for creating all instances of those types. I rarely cross module boundaries when applying the constructors. [1]: https://github.com/zyrolasting/xiden/blob/master/package.rkt#L49 [2]: https://github.com/zyrolasting/xiden/blob/master/security.rkt#L100 On 5/9/21 8:02 PM, Philip McGrath wrote: > 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). -- ~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/a28f5e1e-93e2-d16d-48ab-32168dd42745%40sagegerard.com.
