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 )
