This is so damn cool. And most people won’t even see why.
They won’t realize just how amazingly cool it is that you can grab any block of code in a block closure (the [ ] syntax*), and extend that object with more behavior. And how if you have that object you can I introspect the craziest things out of it, including of course, the source it was derived from, and hence, an AST. There’s no need to make a new compiler pass, or a special tool mod. The “reserved” keyword of any doesn’t have to be bolted into the whole language, it’s just a variable that can be treated specially in this context, and only this context, so you don’t have to have special meta variables leak into the whole system.
* disclaimer: I participated in the inclusion of John and Dons excellent work into the VisualWorks IDE back in the day. I also saw “once” introduced into the Smalltalk system, a lazy runtime way of memoizing block values in place. Oh the things you could do with BlockClosure extension methods.
* aside, my favorite closure syntax of all time, way better than elixirs shorthand & stuff, or fn -> things, or trailing closures
This is roughly the same problem as syntactical macros in non-Lisp syntax languages.
There needs to be a way to indicate a "hole" (metavariable/unquote) in the syntax tree, and depending on the complexity of the language's grammar, that might be somewhat difficult, eg. in C++ having a hole for a type declaration runs into the common ambiguity between declarations (constructor calls) and expressions (regular calls).
This needs to be worked around by eg. having multiple types of holes to disambiguate...
For the article, the idea of using an "any" prefix on identifiers instead of eg. operators such as ` , ... (Lisp macros) is an interesting solution, as it does not require extending the grammar of the language... although it's not applicable in all situations (eg. for matching grammar elements where identifiers are not allowed).
For a very regular language like Smalltalk though, it's pretty good.
Grammar-based rewriting has a long line of history and research, so there's a deep well of knowledge to be mined if you feel like hitting up Google Scholar...
This is so damn cool. And most people won’t even see why.
They won’t realize just how amazingly cool it is that you can grab any block of code in a block closure (the [ ] syntax*), and extend that object with more behavior. And how if you have that object you can I introspect the craziest things out of it, including of course, the source it was derived from, and hence, an AST. There’s no need to make a new compiler pass, or a special tool mod. The “reserved” keyword of any doesn’t have to be bolted into the whole language, it’s just a variable that can be treated specially in this context, and only this context, so you don’t have to have special meta variables leak into the whole system.
* disclaimer: I participated in the inclusion of John and Dons excellent work into the VisualWorks IDE back in the day. I also saw “once” introduced into the Smalltalk system, a lazy runtime way of memoizing block values in place. Oh the things you could do with BlockClosure extension methods.
* aside, my favorite closure syntax of all time, way better than elixirs shorthand & stuff, or fn -> things, or trailing closures
This is roughly the same problem as syntactical macros in non-Lisp syntax languages.
There needs to be a way to indicate a "hole" (metavariable/unquote) in the syntax tree, and depending on the complexity of the language's grammar, that might be somewhat difficult, eg. in C++ having a hole for a type declaration runs into the common ambiguity between declarations (constructor calls) and expressions (regular calls). This needs to be worked around by eg. having multiple types of holes to disambiguate...
For the article, the idea of using an "any" prefix on identifiers instead of eg. operators such as ` , ... (Lisp macros) is an interesting solution, as it does not require extending the grammar of the language... although it's not applicable in all situations (eg. for matching grammar elements where identifiers are not allowed). For a very regular language like Smalltalk though, it's pretty good.
Grammar-based rewriting has a long line of history and research, so there's a deep well of knowledge to be mined if you feel like hitting up Google Scholar...
For modern implementations, there's eg. ast-grep and semgrep: https://ast-grep.github.io/ https://semgrep.dev/docs/writing-rules/pattern-syntax