Macro expander is the class -- looked up
by name using standard java class loading mechanism
Unified environment for bindings
In opposition to declarative e.g., defining syntax from grammar
Full power of programming language can be brought to bear
Assume knowledge with CPP but not dylan
Won’t review lots of impoverished macro systems
Also referred to in brabrand and schwartzbach paper
Get language out and evolve it -- big part of success of Lisp was macro system
which allowed it to live on through OO and Logic languages
Sun's standard JavaTest framework sucks
from the point of view of test authoring;
it's very verbose to write
robust tests and tests involving exceptions just go on and on.
You have
to write extra code if you want to be able to tell from a test log exactly where
a failure occurred.
In fact, because it's so longwinded to test for
unexpected exceptions on a check-by-check basis
like the first case
people don't tend to bother, causing test suites to bomb out at the first such
failure.
Make up for lack of variable arguments
Example from Brabrand and Schwartzbach
Support domain specific languages
Data is easier to maintain
All macros are name based
Streamlined representation of code
Moral equivalents to sexprs
Moral equivalents to destructuring bind and backquote
More equivalents to read and write functions
Easier to manipulate than a full blown AST
More classes below names have Fragment as suffix
System translates #{ } into code that
generates Fragments
Ellipsis is not like scheme’s use
Avoid accidental collisions of macro
variables with program variables of the same name regardless of the context in
which a macro is used
Maintain consistency when macro variables refer to
identically named variables introduced within a given macro definition
Canonical instance created and used for querying
Can also be a GrammarConstraint which packages up tokens of frags as a lexer and
then calls nonterminal entry point of parser