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

5 minutes ago, John Clements wrote:
> 
> On Aug 13, 2011, at 1:34 PM, Carl Eastlund wrote:
> 
> > How about instead of "in spirit", we focus on program logic.
> > There is no semantic dependence on the typechecker -- Racket can
> > tell what the program does without it.  However, programmers
> > cannot read that code and know what it is for and whether it is
> > correct without reference to the typechecker.  That's a meaningful
> > dependency.  It makes maintaining that line of code 100% dependent
> > on the typechecker.
> 
> I feel we're getting perilously close to writing a paper about the
> essence of AOSD....

Actually all of my (admittedly pretty limited) experience with any
kind of AOP is that the problem is resolved by mutating hook values.
The same as adding methods to generic functions is done in CLOS.


> Regard a piece of code as a machine.  Not a specification of a
> machine, but the actual machine.
> 
> Now, tools like the stepper and typechecker need to be able to refer
> to "that part of the machine, right there." There are various ways
> of doing it, but what we've chosen to do (add a piece to the machine
> that's superfluous except when the machine is run using a particular
> mode or tool) has the advantage that it's robust.

It's true that you avoid such mutation which makes things more robust.
But from a SD perspective, I see it as making things less robust...


> It doesn't necessarily break when other parts of the code around it
> change, and it's obvious to anyone modifying the code that you need
> to think about that annotation when you change the code.

...and that's a good explanation why I see it as less robust:
currently, I'm responsible for the code in `racket/private/promise'.
I knew that code well, and I could fix it, extend it, etc.  But now
there's a part of that code that I have no knowledge of -- it stands
in the way of me doing this kind of work.  It's now preconditioned
with me passing changes onto Stephen to approve, or study the stepper
to know how it should change.

On the other hand, if the property is made *completely* independent of
the stepper (in name, functoinality, implementation, and spirit), then
I'd have some explanation of the property that I could use to know how
to deal with that piece of code when I do such revisions.

The same exact thing holds for Sam's `match' hack: just having a
"typechecker" in the name means that the `match' maintainer[*]
wouldn't just change that code without asking Sam about it -- since
it's not clear what the semantics of that thing is.  In that sense it
is very different from `disappeared-use', which is a concept that does
not depend on the syntax cheker.

[*] The fact that they're the same person is probably a strong reason
that this dependency happened in the first place.  If someone else
would maintain `match', then Sam would need to convince that person
that they should add it, and my guess is that most reasonable people
would object to adding arbitrary names into their code.

-- 
          ((lambda (x) (x x)) (lambda (x) (x x)))          Eli Barzilay:
                    http://barzilay.org/                   Maze is Life!