I've wanted this several times (and written more than one ad-hoc partial version): a general-purpose combinator would be great!
On Fri, Oct 30, 2020 at 1:14 PM William J. Bowman <w...@williamjbowman.com> wrote: > > 1. make these functions, not macros > The main implementation is a procedure, but I think I need a macro to get > the > syntactic interface I want. Personally, I'd think about an approach like `->` and `dynamic->*`: a nice syntactic interface that covers most use-cases paired with a somewhat-less-ergonomic procedural interface for more comprehensive functionality, e.g. when aspects of the contract to be generated aren't statically known. On Fri, Oct 30, 2020 at 11:06 AM Ben Greenman <benjaminlgreen...@gmail.com> wrote: > 2. make "at least" the default behavior for dictof, add an option to > override (#:exact-keys?), and remove rho-dictof > To go a step further, I think there are two dimensions of "exactness": 1. Are keys other than those specified permitted? 2. Is a particular key required or optional? There are some combinations of answers to those questions that I think make for poor API design, but, in many of the cases when I've wanted these types of contracts, I've been working with messy pre-existing APIs (often JSON), which inhabit a whole lot of different points in this space. An even-more-general way of asking "Are keys other than those specified permitted?" would be, "What is the contract for a key–value pair not otherwise specified?", where `any/c` and `none/c` are important special cases. Even more generally, this could be a function to produce a contract à la `hash/dc`: I'll see if I can remember an example, but I think I've encountered APIs where this would have been useful. As far as "Is a particular key required or optional?", I'd want a nice syntax to specify this for all keys (I don't have a considered opinion about what the default should be), but I'd also want support for specifying it at the level of the individual key–value pair. Of course, even an implementation that didn't support all of this would be useful! -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. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/010001757ab1f633-6511db02-9764-4008-a0ec-088f33caafe9-000000%40email.amazonses.com.
