The perl 6 parser

[Dan Sugalski]

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.
--
Dan

--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk

[Sean O'Rourke]

On Wed, 8 Jan 2003, Dan Sugalski wrote:
> Could one of the folks working on the perl 6 parser give us a status
> update as to where it stands?

languages/perl6/README mostly reflects the status with respect to the
language definition of about 4-5 months ago. Differences include:

- IIRC hyper-assignment operators are there.
- regex capture groups are partial/flaky, not completely unimplemented.

Joseph Ryan has updated string and numeric literals to correspond to the
latest consensus on the list. Other than that, it's inconsistent with the
current spec in a number of ways. A lot of it's just syntax (e.g.
hyper-ops, for which I'll have to cut-and-paste the non-ASCII bits). The
tests should all still pass (barring inclement GC bugs), but they reflect
the outdated spec.

/s

[Joseph F. Ryan]

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
ryan...@osu.edu

[Leopold Toetsch]

Sean O'Rourke wrote:

>... The

> tests should all still pass (barring inclement GC bugs), but they reflect
> the outdated spec.

Almost:
Failed Test Stat Wstat Total Fail Failed List of Failed
-------------------------------------------------------------------------------
t/compiler/1.test 14 1 7.14% 14
t/compiler/b.test 6 3 50.00% 4-6

1_14 is failing due to the inf/Inf case issue. And:

t/compiler/b.t............4/6[backslashed_expr::string_special

(error) main] Error in interpolation of control-char:

Constant(\N{...}): $^H{charnames} is not defined at (eval 212) line 1, within string

Constant(\N{...}): $^H{charnames} is not defined at (eval 212) line 1, within string
...propagated at P6C/Tree/String.pm line 221.

Some were failing due to GC issues (not walking the stack),

this is fixed in my tree

> /s

leo

[Dan Sugalski]

At 2:31 AM -0500 1/9/03, Joseph F. Ryan wrote:
>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.

This sounds like a good idea, and one that'll make development easier
while this compiler is still in use. Please, by all means implement
the changes.