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
