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
se
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 p
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 we
At 11:49 AM 6/18/2002 -0700, Larry Wall wrote:
>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 imp
On Tue, Jun 18, 2002 at 01:25:49PM -0400, Melvin Smith wrote:
> 1) Macros and debuggers don't play as well together.
I second that. One of my biggest barriers to useful debugging of perl5 is
having, for example, an HV and having to unroll something like the
SvRMAGICAL() macro to figure out if it
