I read this months ago and it's still stuck in my head as proof of just how useful good old interpretation can be.
Just take a few bits of your interpreter and make them replaceable and you get a large space of analyses at your disposal. On top of that, these analyses are applicable to any language with an interpreter defined in this manner!
Now, if this approach can be extended to be shown to be cache-able (small changes => small re-evaluations) it could form a serious basis for a very powerful and user-friendly IDE and/or static analysis tool.
The Racket community has several of these tid bits which I just haven't seen take any hold in the rest of the POPL community.
For example: Racket's Redex showed us how we can have interpreters that we can typeset for our papers, but WebAssembly's working group decided to have their specification be separate to their reference implementation. Why not have them be the same in a literate document? Both Plotkin-style and Felleisen-style evaluation rules are interpreters, there's no reason to do the dull manual labour of re-implementing what you've already said!
1 comment
[ 3.0 ms ] story [ 12.4 ms ] threadJust take a few bits of your interpreter and make them replaceable and you get a large space of analyses at your disposal. On top of that, these analyses are applicable to any language with an interpreter defined in this manner!
Now, if this approach can be extended to be shown to be cache-able (small changes => small re-evaluations) it could form a serious basis for a very powerful and user-friendly IDE and/or static analysis tool.
The Racket community has several of these tid bits which I just haven't seen take any hold in the rest of the POPL community.
For example: Racket's Redex showed us how we can have interpreters that we can typeset for our papers, but WebAssembly's working group decided to have their specification be separate to their reference implementation. Why not have them be the same in a literate document? Both Plotkin-style and Felleisen-style evaluation rules are interpreters, there's no reason to do the dull manual labour of re-implementing what you've already said!