Hacker News Reader

Comment by throw-qqqqq | Hacker News Reader

Generally, it enables type-safe, ahead-of-time compiled code to perform work at compile time that would require runtime execution in many other languages

View on HN

That's true but it's not the most important aspect of macros. Macros let you define a new language that describes your problem solution more directly than you can in raw Lisp. In other words they let you create a Domain-Specific Lamguage (DSL). You can create DSLs in other languages too but it's so difficult that it's uncommon. In Lisp it's so easy that DSLs are a primary programming technique.

I don't think that moving the evaluation to compile time is something you can just ignore when discussing macros. It's an important differentiator between macros and Fexprs[1].

IME, the primary use case for macros in Lisps is language extension, a step before a DSL. For every `loop` there are thousands of `with-x` macro implementations. See the macro-writing macros in Alexandria/Serapeum for the most common patterns.

Also, some dynamic languages (Io, Prolog, Groovy) support DSLs through non-macro mechanisms. DSLs in those languages are as easy (or easier) to implement as in Lisps; however, they tend to be less performant. So, again, compile-time macro execution does matter for the DSL use case, too.

[1] https://en.wikipedia.org/wiki/Fexpr

In the case of Prolog, term and goal expansion are arbitrary compile-time execution mechanisms, completely isomorphic with macros, and are referred to as macro mechanisms.

The characterization of it not being "compile-time macro execution" is strange, what do you think these predicates are doing?

Good point. I was thinking about meta-interpreters (and it's still possible I misunderstood or misremembered how they work!), but you're right; I should have at least been more precise.

Thanks for linking to Fexpr's. I've thinking about "functions with lazily evaluated arguments" recently, and trying to understand how they are different from macros. So I was basically thinking about fexprs.

I have some reading to do, but overall it seems like macros are favored instead of fexprs. Macros completely avoid some environment handling issues.

The only language with Fexprs that I used was Io. In Io, unevaluated code is represented as a tree of Message nodes, and for each call, an activation record is instantiated and provided to the called method body. That reified Call object lets you access the caller's environment and the raw Message chains passed as arguments. You can then decide whether to evaluate those messages, which ones, how many times, and in what context/environment. It's a very niche language, but if you want to see Fexprs "in action", that's the best place to look at (at least to my knowledge) - they are central to Io's design rather than an advanced feature nobody touches. It's even mentioned on the front page[1]:

> Messages as Code — Messages form trees that can be inspected and rewritten at runtime. Argument evaluation can be deferred, so if, while, and for are implementable in Io itself.

[1] https://iolanguage.org/

> I don't think that moving the evaluation to compile time is something you can just ignore when discussing macros.

Sure but you've also got CTFE in languages that lack a proper macro system such as C++. The defining characteristic (IMO) is the access to and ease of manipulating the AST on the fly. And any time you're outputting an AST you're going to need access to the compiler at which point the line between run time and compile time becomes blurred and arbitrarily nested.

I don’t disagree, but I think this is a matter of taste: i.e. which aspect you’d consider more important.

You can create DSLs without macros, for example by parsing and interpreting at runtime, but macros let you move much of that logic to compile time.

For me, that's the killer feature: writing code that looks dynamic or interpreted, but ends up as compiled code.

Reply on news.ycombinator.com