[racket-dev] syntax-property guards? (was: Re: The Stepper strikes again)

From: John Clements (clements at brinckerhoff.org)
Date: Sat Aug 13 10:44:43 EDT 2011

Adding dev to followups, hope that's okay with all three of you.

On Aug 12, 2011, at 7:15 PM, Eli Barzilay wrote:

> A few seconds ago, Matthias Felleisen wrote:
>> This sounds wrong. The only way there can be a dependency is via
>> require.  So how can it not be checkable, never mind copy or
>> hand-coding.
> The stepper has some function that annotates syntaxes with a stepper
> specific value.  Stephen wanted to use this function but couldn't
> because there was a dependency cycle.  So to "resolve" it, he copied
> the function into `racket/private/promise' -- so now there's a bit of
> stepper code that is duplicated in the core.  The duplication is
> obvious problem #1.  The more subtle problem is the existence of code
> in the core that has no meaning without the stepper.

I'm coming a bit late to this party, but I disagree with at least some of this.

Actually, I want to disagree mostly with the "more subtle problem."

To start with, here's the basic motivating change to the code (lots like this):

-  (defsubst (~and x ...) (~ (and (! x) ...)) ~and *and)
+  (defsubst (~and x ...) (hidden-~ (and (hidden-! x) ...)) ~and *and)

That is, the code for lazy racket contains the knowledge about which things should be hidden by the stepper.  I would argue, in fact, that this is the *right* place for such knowledge. In particular, suppose you're developing the lazy stepper, and you want to say, "this thing here is hidden." How do you point to a particular expansion? You want to make an annotation in the code for the expansion itself.  The alternatives I can think of are all hideously fragile, unless you go to some AOSD approach, but I think that this would wind up being even more verbose, and not substantially less fragile.

That is, I think that the "subtle problem" above is not actually a problem at all.

Thing two: I agree that the duplication of code is a terrible idea.  However, I don't think that using syntax-track-origin is going to help at all.  The code that was duplicated here was basically a simple syntax-track-property, along with a dynamic check that ensures that the specified value is a legal one.  It's this dynamic check that's the added value, and I think that the choice between syntax-track-origin and syntax-property is orthogonal.

Basically, what we really want is a way to register a guard for particular syntax-property keys, and thinking about this, I can imagine this being pretty widely useful. I suppose the hard part is deciding who's allowed to attach a guard to a particular value's use as a syntax-property key, without compromising security.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4624 bytes
Desc: not available
URL: <http://lists.racket-lang.org/dev/archive/attachments/20110813/b3950039/attachment.p7s>

Posted on the dev mailing list.