Pugs bugs

[Mark J. Reed]

Is there a repository of current known bugs with pugs, like there is
with Parrot? I'm just starting and don't want to point out things
that are already known.

I just built Pugs fresh from SVN on four different platforms (Win32,
Solaris, OS X Panther, and OS X Tiger) and noticed these things
consistently across platforms:

1. In interactive mode, the REP loop nukes $_ between prompts:

Loading Prelude... done.
pugs> $_="foo"
"foo"
pugs> say $_
foo
Bool::True
pugs> say $_
1
Bool::True
pugs>

2. say and print don't output $_ by default, whatever it's set to;

3. String#trans is behaving quite oddly:

"foo".trans(o=>0) # 1. yields "foo", unmodified
"foo".trans(o=>"0"); # 2. ditto

"foo".trans("o"=>0); # 3. *** Not a keyed reference: VInt 0
# at Prelude.pm line 429, column 22-6

"foo".trans("o"=>"0"); # 4. this finally puts out the desired "f00"
"foo".trans((o=>"0")); # 5. interestingly, so does this

As far as I can tell from the spec, 2, 4, and 5 should all be
equivalent, but they yield three different behaviors. Likewise 1 and
3.

[Larry Wall]

On Thu, Aug 24, 2006 at 02:29:04PM -0400, Mark J. Reed wrote:
: Is there a repository of current known bugs with pugs, like there is

: with Parrot? I'm just starting and don't want to point out things
: that are already known.

The pugs idea of reality is that a bug doesn't exist unless there's a
test failing for it. And the correct way to report a bug is to write
a test for it and check it in. :)

: I just built Pugs fresh from SVN on four different platforms (Win32,

: Solaris, OS X Panther, and OS X Tiger) and noticed these things
: consistently across platforms:
:
: 1. In interactive mode, the REP loop nukes $_ between prompts:
:
: Loading Prelude... done.
: pugs> $_="foo"
: "foo"
: pugs> say $_
: foo
: Bool::True
: pugs> say $_
: 1
: Bool::True
: pugs>

It's purposefully setting $_ to the result of the last evaluation.
Not saying that's the best way to work it, but my understanding is
that it is the intended behavior at the moment. I doubt anyone's
ego is riding on it though... :)

: 2. say and print don't output $_ by default, whatever it's set to;

The current Perl 6 design discourages defaulting to $_ for functions
that could easily be written .say and .print to default explicitly, as
it were. We're all still trying to get used to it, and may yet make
an exception in some cases for old times' sake.

: 3. String#trans is behaving quite oddly:

:
: "foo".trans(o=>0) # 1. yields "foo", unmodified
: "foo".trans(o=>"0"); # 2. ditto
:
: "foo".trans("o"=>0); # 3. *** Not a keyed reference: VInt 0
: # at Prelude.pm line 429, column 22-6
:
: "foo".trans("o"=>"0"); # 4. this finally puts out the desired "f00"
: "foo".trans((o=>"0")); # 5. interestingly, so does this
:
: As far as I can tell from the spec, 2, 4, and 5 should all be
: equivalent, but they yield three different behaviors. Likewise 1 and
: 3.

We recently changed it so that o=> will consistently be taken as a
named parameter while "o"=> will be taken as a pair. (o=>"0") also
works because parens were the old way of hiding pairs from being
named parameters, but we're thinking about whether to break that.

All very good questions. With questions 2 and 3, we're just trying to
figure out how much consistency we can introduce into Perl 6 without
driving people completely nuts.

Larry

[Mark J. Reed]

On 8/24/06, Larry Wall <la...@wall.org> wrote:
> The pugs idea of reality is that a bug doesn't exist unless there's a
> test failing for it. And the correct way to report a bug is to write
> a test for it and check it in. :)

Fair enough. I'll work on decoding the test env.

> It's purposefully setting $_ to the result of the last evaluation.

Ah, that wasn't clear because I didn't realize that Bool::True
stringifies to "1".

> The current Perl 6 design discourages defaulting to $_ for functions
> that could easily be written .say and .print to default explicitly, as
> it were.

Right. Because .say -> $_.say falls back to say($_) since there's no
say method. Nifty!

> We recently changed it so that o=> will consistently be taken as a
> named parameter while "o"=> will be taken as a pair.
> (o=>"0") also works because parens were the old way of hiding pairs from being
> named parameters

OK, I see those in S06 now. And may I say . . . urk! But I'll say no
more, as that is a design topic, and as such fodder for an entirely
different mailing list.

--
Mark J. Reed <mark...@mail.com>