On Tue, 18 Jun 2002, Melvin Smith wrote:
: 2) In fact, there are MANY funny named macros in Perl5.
That is precisely *why* they had to have funny names. Perl 5's
macro naming schemes were a vast improvement over Perl 4's. In
Perl 4 it was impossible to tell at a glance what kind of macro
you were looking at.
: Don't you agree that code should document itself as much as possible?
Sure, but there's more than one kind of self-documentation.
The self-documenting nature of Perl 5's macros is intended for people
who can see patterns, not for people who have to have it all spelled
out to them every time. After all, when Perl 5's code was originally
written, it only had to be readable by one person, which was me. :-)
It was only after 5.000 came out that I figured out I needed to
delegate internals work.
: 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()! :)
Doesn't matter how often it's used--it fit into the system. I don't see this
as a good place for Huffman coding. In particular, macros defined in
the same file they're used are not much of a problem here. If you can't
remember what they mean, you just search for them. It's the macros that
are defined in header files that have to be very carefully named.
: >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.
As I say, those aren't a very good example, being local macros rather
than global. It was much more important to systematize the macros in,
say, pp.h. After all these years, I still know exactly what a
dPOPTOPnnrl does, and it's not because I remember the name.
: >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. ;)
With apologies to Henry Spencer, those who do not understand Perl 5
macros are doomed to re-invent them, poorly.
Larry
