lexing -> parsing/macro expansion -> compilation of core language
The macro expansion phase removes all uses of macros and produces a
program in the core language (which has no macros).
The idea is that a user can extend the language with new features.
As long as a program that uses the new feature can be transformed
into an equivalent program that doesn't use the feature, it can
be implemented with a macro transformation.
Macros are needed when the user wants a construct that:
- uses a non-standard evaluation order
- introduces new bindings
- remove boiler-plate (not covered by functions)
- analyzes program elements at compile time
Non-standard evaluation order
What the programmer can use macros depend on how powerful the macro system is.
Reasonable macro systems can be used to implement pattern matching (non-standard evaluation order) and object systems. Implementing, say, pattern matching as a macro
has the advantage that it can be done within the language without changing the compiler.
General constructs such as pattern matching are usually provided by the standard library
of a language - but users are free to experiment with their own versions if they have special needs.
Removing boiler plate
In my 6502 emulator I have two macros `define-register` and `define-flags`.
This allows me to define the registers of the CPU as:
(define-register A) ; accumulator ( 8 bit)
(define-register X) ; index register ( 8 bit)
(define-register Y) ; index register ( 8 bit)
(define-register SP) ; stack pointer ( 8 bit)
(define-register PC) ; program counter (16 bit)
And the individual flags of the status register are defined as:
(define-flags
(C 0 carry) ; contains the result affecting the flag (set if result < #0x100 )
(Z 1 zero) ; contains the last byte affecting the flag
(I 2 interrupt) ; boolean
(D 3 decimal-mode) ; boolean
(B 4 break) ; boolean
(U 5 unused) ; true
(V 6 overflow) ; 0 or 1
(S 7 sign)) ; contains the last byte affecting the flag
Note that macro expansion happens on compile time. Thus there is no overhead at runtime.
Notes
The convention in languages with macros is to use them only if functions can't do the job.
Since macros follow non-standard evaluation order, macros need to be documented carefully.
Over time one finds the balance of when to use them and when not to.
[In the beginning everything looks like a nail.]
Language exploration
An often overlooked positive effect of macros is that the entire community can experiment with new language features.
It's no longer just the "compiler team" that have the ability to add new features. This means that iteration of language design happen faster.
> An often overlooked positive effect of macros is that the entire community can experiment with new language features.
Sure, that sounds positive - but with enough macros, you can turn "your" version of the language into something completely unrecognizable to people that are only familiar with the "basic" version (or, otherwise said: congratulations, you've got yourself a DSL!), and I would say that's a rather negative effect...
TeXInfo is a plain-TeX system that rewrites the parser to a completely new syntax, whilst maintaining compatibility with importing and linking to other libraries. It is extensively used, especially in emacs.
The compilation process is more or less:
The macro expansion phase removes all uses of macros and produces a program in the core language (which has no macros).The idea is that a user can extend the language with new features. As long as a program that uses the new feature can be transformed into an equivalent program that doesn't use the feature, it can be implemented with a macro transformation.
Macros are needed when the user wants a construct that:
Non-standard evaluation orderWhat the programmer can use macros depend on how powerful the macro system is. Reasonable macro systems can be used to implement pattern matching (non-standard evaluation order) and object systems. Implementing, say, pattern matching as a macro has the advantage that it can be done within the language without changing the compiler. General constructs such as pattern matching are usually provided by the standard library of a language - but users are free to experiment with their own versions if they have special needs.
Removing boiler plate
In my 6502 emulator I have two macros `define-register` and `define-flags`.
This allows me to define the registers of the CPU as:
And the individual flags of the status register are defined as: Note that macro expansion happens on compile time. Thus there is no overhead at runtime.Notes
The convention in languages with macros is to use them only if functions can't do the job. Since macros follow non-standard evaluation order, macros need to be documented carefully. Over time one finds the balance of when to use them and when not to. [In the beginning everything looks like a nail.]
Language exploration
An often overlooked positive effect of macros is that the entire community can experiment with new language features. It's no longer just the "compiler team" that have the ability to add new features. This means that iteration of language design happen faster.