I've been writing a lot of compiler recently, and figuring as how Perl
6 is aiming to replace yacc, I think I'll share some of my positive and
negative experiences.   Perhaps Perl 6 can adjust itself to help me out
a bit.  :-)

=over

=item * RegCounter

I have a class called RegCounter which is of immense use, but could be
possibly more elegant.  It's a tied hash that, upon access, generates a
new name and stores it in a table for later retrieval under the same
name.  

It has a method called C<next> that returns a new RegCounter that shares
the same counter, and puts whatever was in that one's "ret" slot into
whatever argument was given to C<next>, by default "next".

The first <[^a-z]> characters in the name are passed along to the
generated register name, defaulting to a target-specific string (for
instance, I use $P for Parrot programs).

So I can do, for instance:

    method if_statement::code($rc) { # $rc is the regcounter
          self.item[0].code($rc.next('condition'))
        ~ "unless $rc{condition}, $rc{Lfalse}\n"
        ~ self.item[1].code($rc.next)
        ~ "$rc{Lfalse}:\n"
    }

=item * Concatenations

The code example you just saw gets much, much uglier if there is added
complexity.  One of my compilers returns lists of lines, the other
concatenates strings, and they're both pretty hard to read -- especially
when there are heredocs all over the place (which happens frequently).

I think $() will help somewhat, as will interpolating method calls, but
for a compiler, I'd really like PHP-like parse switching.  That is, I
could do something like (I'll use $< and $> for <? and ?>):

    method logical_or_expression::code($rc) {
        <<EOC;
            null $rc{ret}
            $< for @($self.item[0]) -> $item { $>
                  $item.code($rc.next)
                  if $rc{next}, $rc{Ldone}
            $< } $>
            $rc{Ldone}:
        EOC
    }

For this case, I think it would also be a good idea to have a string
implementation somewhere that stores things as "ropes", a list of
strings, so that immense copying isn't necessary.

=item * Comments

We've already gone over this, but it'd be good to have the ability for
parsers to (somehow) "feed" into one another, so that you can do
comments without putting a <comment> in between every grammar rule (or
mangling things to do that somehow), or search and replace, which has
the disadvantage of being unable to disable comments during parts of the
parse.  $Parse::RecDescent::skip works well, but I don't think it's
general enough.

=item * Line Counting

It is I<essential> that the regex engine is capable (perhaps off by
default) of keeping track of your line number.

=back

Luke