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 racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/20201030190826.GA1988871%40williamjbowman.com.

Reply via email to