Dan Sugalski wrote:
Could one of the folks working on the perl 6 parser give us a status
update as to where it stands? Which bits of the apocalypses don't
work, and what parts of the regex definiton's not done yet? Things
have stalled a bit, and I'd like to get it going again, and the perl 6
tests into the standard parrot test suite.
I think that before development kicks back up again, perhaps we use
the long absense to look objectively at P6C and look for potential
places to refactor.
For instance, one thing that I'd like to do is abstract operator
symbols from their node definition. After the monster operator
thread on p6-lang awhile back, at least 50% (guess) of the operators
are no longer the same as they used to be.
However, these symbols are still hardcoded into the Binop node type,
meaning that nearly every single module in P6C needs to be updated.
However, if the symbols were mapped to an operator name/number in the
tree deciphering phase in Tree.pm, then updating the operators would
be simple if future changes occur.
So, a node like this:
bless {
op => '_', # yes, it is '~' now, but there are still dozens of
# usages of '_' throughout P6C
l => bless {type=>'PerlUndef', name=>'$x'}, 'P6C::variable'
r => bless {type=>'PerlUndef', name=>'$y'}, 'P6C::variable'
}, 'P6C::Binop';
Might become:
bless {
op => 'concat',
l => bless {type=>'PerlUndef', name=>'$x'}, 'P6C::variable'
r => bless {type=>'PerlUndef', name=>'$y'}, 'P6C::variable'
}, 'P6C::Binop';
or
bless {
op => 1, # or whichever operator number concat is
l => bless {type=>'PerlUndef', name=>'$x'}, 'P6C::variable'
r => bless {type=>'PerlUndef', name=>'$y'}, 'P6C::variable'
}, 'P6C::Binop';
The operator name/number could then be resolved during IMCC code
generation phase using a dispatch table similar to the one already
in place.
Joseph F. Ryan
[EMAIL PROTECTED]
