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 >> <matth...@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.
smime.p7s
Description: S/MIME cryptographic signature
_________________________________________________ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
