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 <gneu...@comcast.net> 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 racket-users...@googlegroups.com. > > 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 racket-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/3de9c8ac-fa4f-44c3-8ce1-dcf041ecb8c1n%40googlegroups.com.
