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

Somehow I missed this entire thread. Some responses below.

> Let me try to say what I understand out loud:
>
> 1. The existence of Stepper knowledge in the Lazy compiler creates a 'spiritual' dependency between the Lazy language and a tool in DrRacket (= Tool world). QUESTION: does this knowledge ever make sense outside of our tool suite? Could it be reused by a stack-tracing debuggger in a textual repl?
>
> 2. At the same time, this Tool knowledge is best injected into compilation just in case we want it. QUESTION: does some knowledge about Lazy compilation move into the Stepper if we don't inject the knowledge here?
>
> 3. I agree with John though I am actually hopeful that we can come up with a software architecture that eliminates the problem and isn't AOSD all the way. Is it possible to view this knowledge as a mixin that gets added to the Lazy compiler when the language lives in the Tool world?

It seems like most people agree that it's ok to add stepper syntax
properties to lazy racket. The problem is that the lazy language is
split between two files: lazy/lazy.rkt and racket/private/promise.rkt,
with promise.rkt also trying to be a generic library at the same time.
That was fine when a third party didnt need to communicate something
to both files at once but now the stepper does.

The duplicated function, stepper-syntax-property, is just
syntax-property with a 'stepper key. If I do what Eli says and only
use generic documented functions in promise.rkt, I can use
syntax-property, but I still need to somehow communicate the 'stepper
key to both lazy.rkt and promise.rkt.

Other languages wont have this problem because the implementation is
likely all in one place. Other tools for lazy racket may have this
problem if they need to communicate something to both lazy.rkt and
promise.rkt, but could possibly get away with it if everything can be
done in the lazy.rkt section of the language.


> One more minor aside I should have mentioned: Stephen's use of a macro here reads *much more
> nicely* than the way the rest of the stepper annotations explicitly inject the annotations using
> with-syntax; when I get time, I want to adopt this approach elsewhere.

That's actually your macro :) I just created other similar ones and
used it in more places than you did.