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

On Aug 16, 2011, at 7:39 PM, Matthias Felleisen wrote:

> 
> On Aug 16, 2011, at 5:42 PM, Sam Tobin-Hochstadt wrote:
> 
>> On Tue, Aug 16, 2011 at 5:31 PM, Matthias Felleisen
>> <matthias at ccs.neu.edu> wrote:
>>> 
>>> Eli is right in principle. I sense that we are facing the same kind of problems we faced when we created mixins and then again when we created continuation marks.  We need annotations time and again and they couple parts of our system more closely than necessary. Problem is, we don't seem to see or have an abstraction that eliminates this coupling.
>> 
>> Aren't syntax properties precisely this abstraction?
> 
> 
> It is a mechanism and as such it is an abstraction. But is it the best possible abstraction? 
> 
> The use of symbols means the use of a protocol: "when I see 'x, I will perform action A."  So the identity of the symbol is critical. And that means we're tying together the two (+) components that are subject to the protocol. If the symbol changes in one of them, the other one breaks (the type checker, the stepper). 
> 
> That's Dan's rule: don't use symbols to impose protocols. (Today's add1 day for Dan.) 
> 
> What you really want is a name (variable). So at a minimum, two components should rely on a shared module that exports a variable to be used instead of a symbol. Then you could use (gensym) and nobody could mess with the symbol. Identity would be enforced afresh every time you start the system. 
> 
> But once you introduce a random name, you see that you want some other mechanism that 'mixes' into the compilation process as needed. 

I don't see this.  In fact, I believe that the existing syntax system probably already supports this, in allowing the use of non-symbols as syntax-property keys.  I just use symbols to increase transparency.

What Eli is proposing, AFAICT, is not in fact a new abstraction, but a more disciplined--I might say, way *too* disciplined--use of the ones we have.

In particular, the code for the teaching languages currently has many points where a syntax-property is added saying, in effect, "the stepper needs to treat this piece specially." There are many instances of this that could probably be cleaned up and eliminated. For instance, the stepper has a 'stepper-binding-type' property, used thusly (from internal-docs.txt):

"stepper-binding-type :
 this is actually unrelated to macro expansion. It differentiates
 between the various kinds of lexical bindings.

 [ 'macro-bound ] : this variable's binding was inserted by a macro
 [ 'let-bound ] : this variable's binding was in a let/*/rec
 [ 'lambda-bound ] : this variable's binding was in a lambda
 [ 'non-lexical ] : this variable's identifier-binding is not
      'lexical (i.e., unbound, top-level, or a module binding"

My guess is that in 2011, this information can probably be recovered from the syntax tree somehow.

On the other hand, there are properties like this one:

"stepper-replace :

  This is like stepper-skipto/discard, except that it makes the
  stepper replace the expression the property is attached to by the
  value of the property.
"      

... which is a straight-up cheat: it's saying, "hey stepper, use this expression instead of the one that you think should go here."  I would have to see exactly where this one is used, to see whether there's a more general way to tackle this.

In general, then, I think that Eli's suggestions are sensible; I'm just not sure whether the payoff is worth the cost.

John

p.s.: I *still* think that the ability to place guards on syntax properties could be a big win. In fact, one advantage of not using symbols here is that you could perhaps check this statically.








-------------- 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/20110821/ef98dd5b/attachment.p7s>