Irrational fear of macros

Melvin's quip regarding macros, while harmless in itself, is, I fear, a symptom
of a real problem.  One of the muses for parrot and perl 6 has always been
the inaccessibilty of the perl 5 code base.  Perl 5's reliance upon
macros has been cited often as a source of confusion, by those attempting to grasp
the subtle mullings of perl's muddled internals.  This observation, either half baked
or over cooked, I can't tell which, has engendered, in some, an irrational fear of
macros.

Suppose for a moment, that instead of using a macro, a Parrot implementor writes a series
of functions to provide "simplified" interfaces to one rather complex function.  
This new Bzyantine API makes a tradeoff, it increases the efficiency of the programmer,
while degrading runtime performance, and dramatically increasing the complexity of the 
namespace.  With time, as the simplified API functions are designed to address the
most common cases, or more appropriately, those the implementor thought would be common,
the relationship of each of descendants to the source function becomes obscured through
usage patterns and ignorance.  This is largely because those functions, which are 
encountered the most frequently, are those most likely to be used and understood by 
new contributors.  This is a basic evolutionary case for survival of the specialist,
the special cases become the norm.  Welcome to the reinvention of the Perl 5 problem.

Perl 5's problem with macros is not that they are macros, or that their names are funny,
or even that there are so many of them.  The problem really is that too many of them
remain largely undocumented, under-utilized, or over-exposed.  They are confusing
because the rational for their existence and the current usage cases no longer 
complement each other.  Lacking a widely accessible, living memory of the implementor's
intent, the APIs descended into indecipherability, a natural result for any dead language.
Don't kid yourself, Parrot's internal API is a language, it is the vocabulary through
which all concepts expressible in Parrot are constructed, and that which is not often 
repeated, in any language, dies.

If Parrot is to avoid perl 5's legacy, a dictionary, a work to explain the usage of 
each element of the API.  Parrot needs a rosetta stone, through which future implementors 
will decipher and re-interpret the decisions made years in the past.  With such a device, 
I believe we can overcome our irrational fear of macros, and prevent history from repeating 
itself.  Parrot's api can be expansive and expressive and comprehendsible, iff we
document the tower of babble.

If you knew why the macros existed, you wouldn't be confused now would you?

Dave Goehrig

( who is really praying for XS support in parrot, 
 cause he's got 11,000 line of it he doesn't want to rewrite )

 

• Irrational fear of macros by David J. Goehrig
• Re: Irrational fear of macros by Melvin Smith
• Re: Irrational fear of macros by Michael G Schwern
• Re: Irrational fear of macros by Larry Wall
• Re: Irrational fear of macros by Melvin Smith