I'm not sure, but I have a feeling Ben's suggestion to make them functions instead of macros wasn't about the performance implications of macros. I think it was about this particular symmetry:
- A (list 1 'apple "banana") is a (list/c number? symbol? string?) - A (hash 'a 1 'b "foo") is a (dictof 'a number? 'b string?) That is, when the keys are known statically, all the functions for creating dictionaries and hashes typically go with a flat and alternating sequence of key-value arguments. I think a contract combinator for dicts where the keys are known should have the same shape. One other point: dictof is a confusing name. We would have list/c and listof, vector/c and vectorof, and hash/c and dictof. And the first two pairs would make the exact opposite decision as the third pair about which name is for the heterogeneous known-size case and which is for homogeneous collections. Honestly I'd suggest naming it heterogeneous-dict/c. The contract will almost always span multiple lines no matter how long a name you pick, and I'm sick and tired of guessing which one of list/c, listof, *list/c, and list*of is the one I actually want. Words are underrated. On Friday, October 30, 2020 at 12:43:02 PM UTC-7 William J. Bowman wrote: > Thanks for the feedback! Some of these were not concerns for my use case, > so I’ll do a bit more design before submitting something. > > -- > Sent from my phoneamajig > > > On Oct 30, 2020, at 12:36, George Neuner <[email protected]> wrote: > > > > > >> On 10/30/2020 3:08 PM, William J. Bowman wrote: > >> Let me aid this discussion by copying in the ~10 lintes of code in > question: > >> > >> > (define-syntax (dictof syn) > >> > (syntax-parse syn > >> > [(_ (k:id pred?) ...) > >> > (quasisyntax/loc syn > >> > (dictof/proc `((k . ,pred?) ...)))])) > >> > > (define ((dictof/proc spec) h) > >> > (and (eq? (dict-keys h) (dict-keys spec)) > >> > (for/and ([(k pred?) (in-dict spec)]) > >> > (pred? (dict-ref h k))))) > >> > >> The macro is merely a syntactic transformation to 1 line of code that > implements > >> the functionality of the contract at run-time. > >> Is there some reason to avoid macros in this particular case? > > > > There's rarely any problem with macros that only provide syntactic sugar. > > > > The issues wrt contracts are how heavy are the dictionary functions. The > FOR loop is concerning because the check time is proportional to the size > of the dictionary [again recalling that contracts live on in release code]. > > > > For performance it would be better to enforce the predicate on values as > they are entered, and then assume anything already in the dictionary is > correct. It is sensible to provide a function that validates the whole > dictionary, but I would make it something the programmer has to invoke > deliberately rather than a contract to be enforced at (even just 1st in > module) mention of the dictionary. > > > > YMMV, > > George > > > > -- > > 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]. > > To view this discussion on the web visit > https://groups.google.com/d/msgid/racket-users/95997336-33d4-5c5b-b329-9ea691fe59ef%40comcast.net > . > -- 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]. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/3de9c8ac-fa4f-44c3-8ce1-dcf041ecb8c1n%40googlegroups.com.
