I’ve been thinking about how to package macros across a variety of programming languages. Macros are the ability to generate code structures, which are then executed. For example, [“setnull”, “x”] might be compiled to x = null in JavaScript, which is then evaluated. Notice you cannot do this with functions — you can’t access un-evaluated arguments, like the name “x”, or the lexical environment in which it appears (to say nothing of dynamic scope).
It’s a hard problem. Clojure has some prior art in this space, but the packaging system relies on creating “their own world” — classes in Clojure aren’t really plain Java classes. Or more specifically, protocols are a completely different thing from what normal Java applications write their programs with.
I don’t think building one’s own programming world is a good thing when you bootstrap macros on top of an ecosystem. The most powerful use of this technique is, for example, to have native access to Numpy with python + lisp macros. You can’t really do that with a runtime that has to be embedded with all of your modules.
pg’s Bel has some interesting things to say about the topic, if you focus strictly on the interpreter. The ability for functions to be represented by lists — along with their lexical environment being represented by those same lists — is something that appears in elisp, but nowhere else I’ve seen. Self, maybe?
It’s an ongoing process. The reason I bring it up is that macros are one of the finest tools of metaprogramming available, so it’s a problem worth solving.
Rust macros are just programs that take source code as input and produce source code as output.
These programs can do anything that the user running them does.
You can compile them to WASM, ship them over the network, and run them on a WASM interpreter with restricted permissions, like "no file-system access, no random-number generator access, no network access", etc.
WASM runs very fast (compiled to native code), is supported on every platform that has a web browser or a WASM interpreter, of which there are many open source implementations available, and has no undefined behavior (WASM modules either fail to validate or trap during execution but they don't "read out of bounds" or "segfault").
So to me at least this is a solved problem.
I guess one can do the same with common lisp macros, but nowadays at least, the infrastructure for WASM is just much better.
> Most programs start out as nonprogrammable, closed applications, then painfully claw their way to programmability through the introduction of a limited script or macro facility, succeeded by an increasingly comprehensive interpretive macro language which grows like topsy and without a coherent design as user demands upon it grow. Finally, perhaps, the program is outfitted with bindings to existing languages such as C.
> An alternative to this is adopting a standard language as the macro language for a product. After our initial foray into the awful menu macro language that still burdens us, AutoCAD took this approach, integrating David Betz’ XLISP, a simple Lisp interpreter which was subsequently extended by Autodesk to add floating point, many additional Common Lisp functions, and, eventually, access to the AutoCAD database.
Sure, but Common Lisp has its own packaging system. Suppose you want to ship macros with python, or any other language; that’s the challenge.
It may seem strange to say that you can have macros in other languages, but you can. The key is to compile lists of expressions into code, and then evaluate the resulting code. But the hard part is “then what?”
It’s a hard problem. Clojure has some prior art in this space, but the packaging system relies on creating “their own world” — classes in Clojure aren’t really plain Java classes. Or more specifically, protocols are a completely different thing from what normal Java applications write their programs with.
I don’t think building one’s own programming world is a good thing when you bootstrap macros on top of an ecosystem. The most powerful use of this technique is, for example, to have native access to Numpy with python + lisp macros. You can’t really do that with a runtime that has to be embedded with all of your modules.
pg’s Bel has some interesting things to say about the topic, if you focus strictly on the interpreter. The ability for functions to be represented by lists — along with their lexical environment being represented by those same lists — is something that appears in elisp, but nowhere else I’ve seen. Self, maybe?
It’s an ongoing process. The reason I bring it up is that macros are one of the finest tools of metaprogramming available, so it’s a problem worth solving.