At 12:47 AM 6/18/2002 -0400, David J. Goehrig wrote:
>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
I have no fear of macros; I contributed quite a few to Parrot myself. :)
>Perl 5's problem with macros is not that they are macros, or that their
>names are funny,
I have to disagree to both.
1) Macros and debuggers don't play as well together.
2) In fact, there are MANY funny named macros in Perl5.
>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
Under-utilized, true. Defined once, used twice. See below.
Don't you agree that code should document itself as much as possible?
Now, take an example from Perl5.
#define BOop(f) return ao((yylval.ival=f, REPORT("bitorop",f) PL_expect =
XTERM,PL_bufptr = s,(int)BITOROP))
#define BAop(f) return ao((yylval.ival=f, REPORT("bitandop",f) PL_expect =
XTERM,PL_bufptr = s,(int)BITANDOP))
Reading these, I know what they mean. When dealing with Lex/Yacc interface
it is useful to hide yylval usage and state checks/changes inside an interface,
however if I mean BitwiseOrOp() why do I write BOop() when, in fact, the macro
is only used _twice_? When I see BOop, I'm looking for BEtty()! :)
>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
I agree mostly, but this goes back to what I said above, in fact macros are
often named badly. Just open up toke.c in Perl5 and hop to line 152.
Now try to read toke.c remembering what each of those macros does;
even if you have a dictionary, you can only retain so many terms.
4 character macros obfuscate as much as they help productivity.
>If you knew why the macros existed, you wouldn't be confused now would you?
>( who is really praying for XS support in parrot,
> cause he's got 11,000 line of it he doesn't want to rewrite )
Wait, I thought you said we don't want to repeat history. ;)
I agree with you mostly, macros are powerfully useful, they should
follow the rules, and one of the most important rules is, "code in a
self-documenting manner."
-Melvin
