Re: pugs bugs (or features?)

2007-09-07 Thread Larry Wall
On Fri, Sep 07, 2007 at 03:00:36PM +0100, Wim Vanderbauwhede wrote:
: On 07/09/2007, Chas Owens <[EMAIL PROTECTED]> wrote:
: >
: > On 9/7/07, Wim Vanderbauwhede <[EMAIL PROTECTED]> wrote:
: > > The following program works fine in pugs r17041 (which is the rev of
: > > /usr/bin/pugs on feather):
: > >
: > > my $r=\{say $x+1};
: > > my $x=2;
: > > $r();
: > >
: > > With r17041, this gives 3;
: > > However, on the latest pugs (r17615 or later), it gives an error:
: > > ***
: > > Unexpected "$r"
: > > expecting "=", "::", context, ":" or "("
: > > Variable "$x" requires predeclaration or explicit package name
: > > at pugs_var_bug.p6 line 1, column 4
: > > It would think that the r17041 result is correct.
: >
: > You can't use variables before declaring them, think use strict.
: 
: I agree with that, but I am not _using_ the variable, I am just creating a
: Code object for later execution.
: On execution of the Code object, the variables it accesses should of course
: be declared -- which they are.
: But on creation of a Code object, that is not necessarily the case.

Um, you can't even mention the variable without declaring it, or the
compiler will have no idea what you *mean* by the variable.  Older
pugs was buggy in that it didn't check for non-declaration till
run time, and that has since been fixed.  You seem to be suggesting
that declarations should come from the dynamic scope rather than
the lexical scope.  That would make it difficult to write closures,
and impossible to catch typos at compile time.

Larry


Re: pugs bugs (or features?)

2007-09-07 Thread Trey Harris

In a message dated Fri, 7 Sep 2007, Wim Vanderbauwhede writes:


On 07/09/2007, Chas Owens <[EMAIL PROTECTED]> wrote:
Even

if strict weren't in effect this code should not work since the $x in
the closure is not the one created after the closure:

perl -le 'my$r=sub{print $x+1};my $x = 2;$r->()'

That Perl 5 code prints 1 because undef plus one is one.



I am sorry, but if you put it in a script that Perl 5 code prints 3:
[wv]$ cat test_softref.pl
my $r=sub {print $x+1,"\n" };
my $v='x';
$$v=2;
&$r();
[wv]$ perl test_softref.pl
3
[wv]$


Putting it into a script isn't all you changed.  As your filename implies, 
you're using a symbolic reference (sometimes called a "soft" reference) in 
this Perl 5 code.  Your Perl 6 doesn't have any symbolic references. 
Your Perl 6 closure refers to a variable, $x, that has not yet been 
declared, which is illegal; the fact that there is a $x by runtime is 
irrelevant.  Perl (5 or 6) is not Tcl; it is compile time that matters for 
variable binding, not runtime (unless you specifically delay the binding 
somehow to runtime).


Trey


Re: pugs bugs (or features?)

2007-09-07 Thread Carl Mäsak
Wim (>):
> I think it could be a GHC bug: I rebuilt r17041 with ghc-6.6.1 (just a few
> changes to use the new filepath package in Pugs.hs and Pugs/Run.hs) and it
> shows the bug. I assume the pugs on feather really is r17041, to be really
> sure I should build r17041 with ghc-6.6. I should manage that next week.

Cool. Wim++

// Carl


Re: pugs bugs (or features?)

2007-09-07 Thread Wim Vanderbauwhede
I think it could be a GHC bug: I rebuilt r17041 with ghc-6.6.1 (just a few
changes to use the new filepath package in Pugs.hs and Pugs/Run.hs) and it
shows the bug. I assume the pugs on feather really is r17041, to be really
sure I should build r17041 with ghc-6.6. I should manage that next week.

Wim

On 07/09/2007, Carl Mäsak <[EMAIL PROTECTED]> wrote:
>
> Wim (>):
> > The following program works fine in pugs r17041 (which is the rev of
> > /usr/bin/pugs on feather):
> >
> > my $r=\{say $x+1};
> > my $x=2;
> > $r();
> >
> > With r17041, this gives 3;
> > However, on the latest pugs (r17615 or later), it gives an error:
> > ***
> > Unexpected "$r"
> > expecting "=", "::", context, ":" or "("
> > Variable "$x" requires predeclaration or explicit package name
> > at pugs_var_bug.p6 line 1, column 4
> >
> > It would think that the r17041 result is correct.
> > ---
> > There is also a scoping issue in r17615:
> >
> > my $v=1;
> > if ($v) {
> > map ->$v {$v},(2);
> > } else {
> > $v;
> > }
> >
> > With r17041, this gives 2; With r17615 it gives an error:
> > ***
> > Unexpected end of input
> > expecting "::"
> > Variable "$v" requires predeclaration or explicit package name
> > at pugs_scoping_bug.p6 line 6, column 15
> >
> > Now, if I change $v to $x in the pointy sub, it works fine.
> > -
> >
> > Both  seems like bugs to me, but can someone confirm that?
>
> They're most likely bugs. Since May, Pugs has been halfway towards
> getting a new MO core.
>
> <
> http://moritz.faui2k3.org/irclog/out.pl?channel=perl6;date=2007-05-17#i_18608
> >
>
> Not everything has been working since then, and likely won't until the
> other half is committed. #perl6 people might be able to fix minor
> flaws, but there's general hesitation towards fixing things that might
> be superceded by the new MO machinery.
>
> // Carl
>



-- 
If it's pointless, what's the point?
If there is a point to it, what's the point?
(Tibor Fischer, "The Thought Gang")


Re: pugs bugs (or features?)

2007-09-07 Thread Carl Mäsak
Wim (>):
> The following program works fine in pugs r17041 (which is the rev of
> /usr/bin/pugs on feather):
>
> my $r=\{say $x+1};
> my $x=2;
> $r();
>
> With r17041, this gives 3;
> However, on the latest pugs (r17615 or later), it gives an error:
> ***
> Unexpected "$r"
> expecting "=", "::", context, ":" or "("
> Variable "$x" requires predeclaration or explicit package name
> at pugs_var_bug.p6 line 1, column 4
>
> It would think that the r17041 result is correct.
> ---
> There is also a scoping issue in r17615:
>
> my $v=1;
> if ($v) {
> map ->$v {$v},(2);
> } else {
> $v;
> }
>
> With r17041, this gives 2; With r17615 it gives an error:
> ***
> Unexpected end of input
> expecting "::"
> Variable "$v" requires predeclaration or explicit package name
> at pugs_scoping_bug.p6 line 6, column 15
>
> Now, if I change $v to $x in the pointy sub, it works fine.
> -
>
> Both  seems like bugs to me, but can someone confirm that?

They're most likely bugs. Since May, Pugs has been halfway towards
getting a new MO core.

 

Not everything has been working since then, and likely won't until the
other half is committed. #perl6 people might be able to fix minor
flaws, but there's general hesitation towards fixing things that might
be superceded by the new MO machinery.

// Carl


Re: pugs bugs (or features?)

2007-09-07 Thread Wim Vanderbauwhede
On 07/09/2007, Chas Owens <[EMAIL PROTECTED]> wrote:
>
> On 9/7/07, Wim Vanderbauwhede <[EMAIL PROTECTED]> wrote:
> > The following program works fine in pugs r17041 (which is the rev of
> > /usr/bin/pugs on feather):
> >
> > my $r=\{say $x+1};
> > my $x=2;
> > $r();
> >
> > With r17041, this gives 3;
> > However, on the latest pugs (r17615 or later), it gives an error:
> > ***
> > Unexpected "$r"
> > expecting "=", "::", context, ":" or "("
> > Variable "$x" requires predeclaration or explicit package name
> > at pugs_var_bug.p6 line 1, column 4
> > It would think that the r17041 result is correct.
>
> You can't use variables before declaring them, think use strict.

I agree with that, but I am not _using_ the variable, I am just creating a
Code object for later execution.
On execution of the Code object, the variables it accesses should of course
be declared -- which they are.
But on creation of a Code object, that is not necessarily the case.

Even
> if strict weren't in effect this code should not work since the $x in
> the closure is not the one created after the closure:
>
> perl -le 'my$r=sub{print $x+1};my $x = 2;$r->()'
>
> That Perl 5 code prints 1 because undef plus one is one.


I am sorry, but if you put it in a script that Perl 5 code prints 3:
[wv]$ cat test_softref.pl
my $r=sub {print $x+1,"\n" };
my $v='x';
$$v=2;
&$r();
[wv]$ perl test_softref.pl
3
[wv]$


> ---
> > There is also a scoping issue in r17615:
> >
> > my $v=1;
> > if ($v) {
> > map ->$v {$v},(2);
> > } else {
> > $v;
> > }
> >
> > With r17041, this gives 2; With r17615 it gives an error:
> > ***
> > Unexpected end of input
> > expecting "::"
> > Variable "$v" requires predeclaration or explicit package name
> > at pugs_scoping_bug.p6 line 6, column 15
> >
> > Now, if I change $v to $x in the pointy sub, it works fine.
>
> This definitely seems like a bug.  It looks like $v is being destroyed
> after it is used in the map.  It is my understanding that the $v in
> the map should be treated like a temp variable (its old value should
> return after the map).


Well, ->$x {} is a pointy sub, so the variable should only ever be in scope
inside the sub.

Thanks!

Wim






-- 
If it's pointless, what's the point?
If there is a point to it, what's the point?
(Tibor Fischer, "The Thought Gang")


Re: pugs bugs (or features?)

2007-09-07 Thread Chas Owens
On 9/7/07, Wim Vanderbauwhede <[EMAIL PROTECTED]> wrote:
> The following program works fine in pugs r17041 (which is the rev of
> /usr/bin/pugs on feather):
>
> my $r=\{say $x+1};
> my $x=2;
> $r();
>
> With r17041, this gives 3;
> However, on the latest pugs (r17615 or later), it gives an error:
> ***
> Unexpected "$r"
> expecting "=", "::", context, ":" or "("
> Variable "$x" requires predeclaration or explicit package name
> at pugs_var_bug.p6 line 1, column 4
> It would think that the r17041 result is correct.

You can't use variables before declaring them, think use strict.  Even
if strict weren't in effect this code should not work since the $x in
the closure is not the one created after the closure:

perl -le 'my$r=sub{print $x+1};my $x = 2;$r->()'

That Perl 5 code prints 1 because undef plus one is one.

> ---
> There is also a scoping issue in r17615:
>
> my $v=1;
> if ($v) {
> map ->$v {$v},(2);
> } else {
> $v;
> }
>
> With r17041, this gives 2; With r17615 it gives an error:
> ***
> Unexpected end of input
> expecting "::"
> Variable "$v" requires predeclaration or explicit package name
> at pugs_scoping_bug.p6 line 6, column 15
>
> Now, if I change $v to $x in the pointy sub, it works fine.

This definitely seems like a bug.  It looks like $v is being destroyed
after it is used in the map.  It is my understanding that the $v in
the map should be treated like a temp variable (its old value should
return after the map).