Comment by timonoko
2 days ago
You do not need macros for anything. They are not the tool to "extend the language", but instructions for the compiler. And if the system does not even have a compiler, macros are useless, often incredibly stupid.
2 days ago
You do not need macros for anything. They are not the tool to "extend the language", but instructions for the compiler. And if the system does not even have a compiler, macros are useless, often incredibly stupid.
If you have an interpreter only, no compiler, using macros for metaprogramming anwyay at least prepares you for the eventuality that one day there will be a compiler. The macros will Just Work as before, only the expanded code is now processed by compiling.
Suppose you reject the idea that there will ever be a compiler. Macros are still useful for doing "compiler-like things" in the context of interpretation, like transforming code into something that will interpret better.
We can regard the interpreter as a virtual machine acting on a representation of the code; the macro system lets you manipulate the representation in a pre-computed pass, which has no further cost at run time.
If you have a code expansion pass on top of an interpreter, for supporting macros, you can use that as an excuse to perform built-in code transformations that are not macros; those enable you to have more flexibility in how special forms are implemented.
In TXR Lisp case is a macro (family) which performs certain optimizations like recognizing values in a range and emitting a table switch. This works interpreted or compiled:
It is faster to do some checks and interpret the sys:switch special form to dispatch by a numeric index than to do a large number of exhaustive comparisons.
Ultimately, the way we optimize interpretation is by compiling, but it can still be worth it to have better interpretation here and there.
You don't want to do this kind of optimization at run-time; you don't want the interpreter to be evaluating the condition "are these cases integers (or characters) in a tight range?". That's a property of the syntax in which the cases are constants; it wants to be pre-computed once.
TLDR, but you are (probably) describing somekind of builtin property.
I am just saying that the end-user do not need macros for much anything, unless she has some specific optimization in mind. Bloody annoying when they start making cryptic macros to "extend the language".
"Need" is a very tenuous word, because most of any tool stack consists of benefits.
End users benefit from things that they don't strictly need.
Once you start talking about what people don't need, it's hard to do it in a way such that they need Lisp but don't need macros.
Sometimes "need" is about dependencies; i.e. things you "need" are provided by upstreams; you stop needing things that you made yourself.
E.g. "I don't need objects. Because, well, I have lambdas and macros, and with that control over syntax and semantics, I made my own objects. So, strictly speaking, I do need objects, just don't need them from you or anyone else."
People disagree over what constitutes a benefit; something someone finds beneficial in their work is crap to someone else, and the easiest way to disparage someone else's beneficial thing is resort to the necessity rhetoric.
"Everything that I found beneficial in conducting my successful XYZ project, which got to a level of complexity and quality in so many years of effort and lines of code, was obviously necessary; all else is unnecessary."
A really sneaky way to do that is to repeatedly acknowledge the benefit of something while emphasizing the lack of necessity. With a sprinkle of FUD about possible harms that outweigh benefits ...
1 reply →