[racket-dev] syntax taints instead of syntax certificates

From: Carl Eastlund (cce at ccs.neu.edu)
Date: Wed Jun 29 22:12:01 EDT 2011

On Wed, Jun 29, 2011 at 10:10 PM, Eli Barzilay <eli at barzilay.org> wrote:
> A few seconds ago, Eli Barzilay wrote:
>> 8 minutes ago, Carl Eastlund wrote:
>> > On Wed, Jun 29, 2011 at 9:19 PM, Matthew Flatt <mflatt at cs.utah.edu> wrote:
>> > > I've pushed a change to Racket's macro system that throws out the
>> > > syntax-certificate system and adds a syntax-taint system.
>> > >
>> > >
>> > > Syntax taints, like syntax certificates before, are intended to
>> > > protect macro expansions from abuse. "Abuse" means using
>> > > `local-expand' to extract a piece of an expansion, then putting the
>> > > piece in a new context or using `datum->syntax' to access unexported
>> > > module bindings using the piece's lexical context. Meanwhile,
>> > > program-processing tools like `errortrace' or languages like
>> > > `typed/racket' are supposed to pull apart expansions and reorganize
>> > > them; code inspectors remain the way to distinguish trusted tools and
>> > > languages from potential abusers.
>> > >
>> > > Things you need to know:
>> > >
>> > >  * When writing a macro (without `syntax-rules', `define-syntax-rule',
>> > >   or `syntax-id-rules'), apply `syntax-protect' to the macro's result
>> > >   syntax object to protect it from abuse. The `syntax-rules', etc.,
>> > >   forms use `syntax-protect' automatically.
>> >
>> > Does this mean we should be updating all our old macros now, and
>> > adding syntax-protect as boilerplate to (nearly) all of our new
>> > macros?  How often is a manual syntax-protect necessary?  It's great
>> > to have a system we can reason about, but the nice thing about
>> > certificates was that they were invisible most of the time.  It
>> > looks like you're suggesting that at least the use of syntax-protect
>> > is going to become ubiquitous in this new system.
>>
>> That's exactly what I'm worried about too.  (I was going to try things
>> out first, but the build crashed.)
>
> An attempt to clarify what's unclear to me: if I'm supposed to almost
> always "arm" the result of a transformer, then why not have the
> expander do that for me, and add some new thing so in the exceptional
> cases I could do
>
>  (define-syntax (foo stx)
>    (dont-arm ...blah...))
>
> ?  (Apologies if this is explained in the guide section.)

I was about to ask the same thing.  The default seems to be backward,
which at first glance doesn't seem hard to fix.

>> Actually, the certificate system was good enough at being invisible
>> that explaining the new system in terms of it isn't effective (at
>> least for me) since certificates were this complicated thing that you
>> need to be aware of in some rare cases but 5 minutes after you're done
>> you'd re-forget what you read.  (Again, this is all for a subjective
>> value of "you", of course.)



Posted on the dev mailing list.