[perl #53902] my @var1, @var2 not working

# New Ticket Created by  Moritz Lenz
# Please include the string:  [perl #53902]
# in the subject line of all future correspondence about this issue.
# <URL: http://rt.perl.org/rt3/Ticket/Display.html?id=53902 >


Rakudo as of r27393 can't handle multiple declarations in a single "my":

> my (@a, @b); say @a
Scope  not found for PAST::Var '@a'
> my @a, @b; say @a
Scope  not found for PAST::Var '@b'

Implementing that shouldn't be too hard, and would fix quite some of the
spec test failures.

Cheers,
Moritz

--
Moritz Lenz
http://moritz.faui2k3.org/ |  http://perl-6.de/

On Thu, May 08, 2008 at 11:28:36AM -0700, Moritz Lenz wrote:
> Rakudo as of r27393 can't handle multiple declarations in a single "my":
> 
> Scope  not found for PAST::Var '@a'

We'll work on this one.
 
> Scope  not found for PAST::Var '@b'

Rakudo has this one correct -- according to S03, scoping
multiple variables with 'my' requires the parens:

:    my $a;                  # okay
:    my ($b, $c);            # okay
:    my ($b = 1, $c = 2);    # okay - "my" intializers assign at runtime
:    my $b, $c;              # wrong: "Use of undeclared variable: $c"

Pm

On Fri, May 09, 2008 at 06:47:12PM -0500, Patrick R. Michaud wrote:
> On Thu, May 08, 2008 at 11:28:36AM -0700, Moritz Lenz wrote: 
>
> We'll work on this one.
> 
>
> Rakudo has this one correct -- according to S03, scoping
> multiple variables with 'my' requires the parens:
>
> :    my $a;                  # okay
> :    my ($b, $c);            # okay
> :    my ($b = 1, $c = 2);    # okay - "my" intializers assign at runtime
> :    my $b, $c;              # wrong: "Use of undeclared variable: $c"

But is that really the error message you want to be giving for that syntax
error? The double spaces suggest that something internal isn't even
interpolating as expected, due to a the string form of a name being missing.

Nicholas Clark

On Sat, May 10, 2008 at 09:43:38AM +0100, Nicholas Clark wrote:
> On Fri, May 09, 2008 at 06:47:12PM -0500, Patrick R. Michaud wrote: 
>
> But is that really the error message you want to be giving for that syntax
> error? The double spaces suggest that something internal isn't even
> interpolating as expected, due to a the string form of a name being missing.[/colo
r]

You're correct, the error message itself needs updating.  At the moment
the error is being caught during code generation (in PCT), whereas
ideally we'd like to catch it during the parse (in the action
method).  At that point we can give a better error message.

Pm