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. _________________________________________________ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
