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? -- William J. Bowman On Fri, Oct 30, 2020 at 03:04:04PM -0400, George Neuner wrote: > > On 10/30/2020 1:14 PM, William J. Bowman wrote: > > Thanks! One follow-up: > > > > > 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. > > > > Is there some reason to avoid macros? > > You certainly can use macros in the implementation, but just remember that > macros evaluate at compile time and most contracts have to be checked at > runtime: so a contract can't *exclusively* be a macro ... runtime code has > to be generated. > > Robby's comment about code size is relevant also: contracts are not debug > mode only like assertions in C ... Racket's contracts live on in release > mode compiles, so you want to minimize the amount of runtime code required > to implement them. > > 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/20201030190826.GA1988871%40williamjbowman.com.
