Parrot 0.4.0 Luthor Released!
On behalf of the Parrot team I'm proud to announce another major release of Parrot. More than 530 svn checkins and 1000 added tests by numerous folks bump up the version to 0.4.0. I'd like to thank all involved people as well as our sponsors for supporting us. What is Parrot? Parrot is a virtual machine aimed at running Perl6 and other dynamic languages, see http://www.parrotcode.org/ for more information. Parrot 0.4.0 changes and news - New lexical handling and closure support including better introspection for caller and outer - PGE (Parrot Grammar Engine) provides now compilers for P6Rule, P6Grammar, P5Regexp, and Glob - ca. 1000 new tests including 800 for Perl5 regexp - Improved unicode charset and encoding support - Calling conventions for exception handlers - Punie (Perl 1) uses TGE (Tree Grammar Engine) to convert from PGE match objects to AST via two steps of tree transformation grammars - New languages: amber and lua - The usual code fixes, cleanup, and improvements, including an overhaul of the config and test framework After some pause you can grab it from http://www.cpan.org/authors/id/L/LT/LTOETSCH/parrot-0.4.0.tar.gz. As parrot is still in steady development we recommend that you just get the latest and best from SVN by following the directions at http://www.parrotcode.org/source.html Turn your web browser towards http://www.parrotcode.org/ for more information about Parrot, get involved, and: Have fun! leo
scalar/array contexts in perl5 vs. perl6
what is a good translation of the following C into perl6?
code
#include stdio.h
void print(int y[])
{
int ii;
for (ii = 0; 9 ii; ++ii)
{
printf(%d , y[ii]);
}
printf(\n);
}
int main()
{
int x = 0; int y[] = {1, 2, 3, 4, 5, 6, 7, 8, 9}; y[x++]++; /* line
that matters */
printf(%d\n, x);
print(y);
return 0;
}
/code
in perl5, i would've written something like:
code
my $x = 0; my @y = 1..9; @y[$x++]++; print $x\n; print @y\n
/code
but in perl6, the '@' sigil always means list context, so should i
write the following?
code
my $x = 0; my @y = 1..9; [EMAIL PROTECTED]; print $x\n; print @y\n
/code
-xgl
Re: scalar/array contexts in perl5 vs. perl6
Mike Li skribis 2005-12-04 13:10 (-0500): in perl5, i would've written something like: my $x = 0; my @y = 1..9; @y[$x++]++; print $x\n; print @y\n but in perl6, the '@' sigil always means list context, so should i write the following? my $x = 0; my @y = 1..9; [EMAIL PROTECTED]; print $x\n; print @y\n The @ sigil does not create list context. In general, every $foo[$bar] from Perl 5 can be written as @foo[$bar] in Perl 6. @foo[$bar++]++ is neither weird nor wrong. Ugly, yes, that it is. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: scalar/array contexts in perl5 vs. perl6
On Sun, 2005-12-04 at 13:10 -0500, Mike Li wrote:
what is a good translation of the following C into perl6?
code
[...]
int x = 0; int y[] = {1, 2, 3, 4, 5, 6, 7, 8, 9}; y[x++]++; /* line
that matters */
[...]
/code
in perl5, i would've written something like:
code
my $x = 0; my @y = 1..9; @y[$x++]++; print $x\n; print @y\n
/code
Note that when you run this in perl 5:
$ perl -we 'my $x = 0; my @y = 1..9; @y[$x++]++; print $x\n;
print @y\n'
Scalar value @y[$x++] better written as $y[$x++] at -e line 1.
1
2 2 3 4 5 6 7 8 9
You've already used a Perl6-ism!
but in perl6, the '@' sigil always means list context, so should i
write the following?
code
my $x = 0; my @y = 1..9; [EMAIL PROTECTED]; print $x\n; print @y\n
/code
I'm not sure what you're trying to do with all those derefs, but the
only change you need to make to your original code is to put the @y
interpolation inside a block;
{ my $x = 0; my @y = 1..9; @y[$x++]++; print $x\n; print { @y }\n }
Try downloading and installing pugs; it's great for trying out this sort
of thing!
Sam.
Flunking tests and failing code
There's a bikeshedding question of some visibility: now that we have a Cfail builtin, what do we do with CTest::fail? There's plenty of code out there that uses fail as an exported function from pugs' Test.pm or Perl 5 testing modules. We want to keep Test primitives exported and fun to use, to encourage people to use them a lot; so requiring a fully qualified call would go against the grain. But the builtin has even more of that concern: it should become the more common, too. If one is to be renamed, it looks like is the Test one, despite existing legacy code. Discussion on #perl6 brought up flunk as a candidate name. Its merits, including its, uh, dropout cuteness, are many; it rings well against fail, alludes to tests, can probably be backported to the Perl 5 test modules, etc. What say? [++] dduncan autrijus -- Gaal Yahas [EMAIL PROTECTED] http://gaal.livejournal.com/
the $! too global
I've run into a problem today with my Perl 6 coding, which is due to
a perceived design flaw in the current Perl 6 spec (this was
discussed on #perl6 just now, mainly between myself and autrijus), so
I'm bringing it up here.
And yes, autrijus thinks the behaviour I'm seeing in Pugs is
according to an actual spec, and mentioned in S02 with a
Conjectural: beside it.
The problem is that $! is being treated too much like a global
variable and not enough like a lexical variable. Consider the
following example:
sub foo () {
try {
die MyMessage.new( 'key' = 'dang', 'vars' = {'from'='foo()'} );
};
if ($!) {
display_message( $! );
}
else {
display_message( MyMessage.new(
'key' = 'nuthin_wrong', 'vars' = {'from'='foo()'} ) );
}
}
sub display_message ( MyMessage $m ) {
try {
potential_problem(); # on problem, dies
};
if ($!) {
deal_with_it();
}
say this message has a key {$m.key()}, is from {$m.vars{'from'}};
}
This is a generified example of my Locale::KeyedText module and its examples.
Under the current system, a subroutine argument is an alias for the
container passed to it; in this case, $e is an alias for the $! that
was set in foo()'s try-block.
Unfortunately, the $! that is set or undeffed by
display_exception()'s try-block appears to be the same container as
foo()'s $!, which means that by the time say() is called, $e has been
wiped out.
Now, I can understand that consequence if the code instead looked like this:
my $*myerr = undef;
sub foo () {
try {
$*myerr = MyMessage.new( 'key' = 'dang', 'vars' = {'from'='foo()'} );
};
if ($*myerr) {
display_message ( $*myerr );
}
else {
display_message( MyMessage.new(
'key' = 'nuthin_wrong', 'vars' = {'from'='foo()'} ) );
}
}
sub display_message ( MyMessage $m ) {
try {
potential_problem(); # on problem, first sets $*myerr before death
};
if ($*myerr) {
deal_with_it();
}
say this message has a key {$m.key()}, is from {$m.vars{'from'}};
}
However, much like $_, I expect that exception handling done within a
called subroutine isn't going to mess up that subroutine's parent
scope, and consequently its own arguments.
Under the current system, I can keep $m preserved by either declaring
that argument with 'is copy', or having foo() explicitly copy its $!
to another lexical var which is then passed to display_exception(),
however, either of those is counter-intuitive and ugly.
First of all, declaring a subroutine's argument 'is copy' presumes
that either you are going to modify its value in the subroutine, or
you will be storing it in an object attribute or something and you
don't want to risk changes to it when the subroutine's caller
modifies the container it just passed.
But in the case of my example, the called subroutine is doing neither
of those things; no changes are made, and $m isn't kept beyond the
subroutine's execution.
Note that, while my examples don't use a CATCH block (which isn't yet
implemented in Pugs), you get the exception from $! or an alias
thereof anyway, so whether or not I used CATCH is factored out of the
discussion at hand here.
Now, I'm not sure exactly of the right solution for this, and perhaps
others such as autrijus can chime in with some help here, but the
current situation needs to be changed. Either $! becomes
semi-lexical, so a called sub's try block doesn't wipe out the $!
from a caller, or $! is treated special when used as a subroutine
argument and is automatically passed by copy, without the subroutine
signiture having to specify 'is copy'.
What I want to have happen is that display_message() works correctly
regardless of whether its argument came from $! or some other source,
without having to declare 'is copy' because of the possibility it is
from $!.
The big problem here is that almost any argument for any subroutine
could potentially come from $!, and it would be rediculous for them
all to be 'is copy' just to handle the possibility.
Nor is it reasonable for a caller to have to copy $! to another
variable before passing it to a subroutine just because that sub
*may* have its own try block ... a caller shouldn't have to know
about the implementation of what it called.
I welcome feedback on this issue and a positive, elegant resolution.
-- Darren Duncan
Re: Flunking tests and failing code
On 12/5/05, Gaal Yahas [EMAIL PROTECTED] wrote:
There's a bikeshedding question of some visibility: now that we have a
Cfail builtin, what do we do with CTest::fail?
Is it possible to do nothing with it? That is, can we coerce the Test
module to understand when the main program fails? This may be
problematic, as it is occasionally desirable to call fail from
within a function while you are testing.
There's another problem that I've been thinking about with regard to
Test. We have the prefix:is builtin, used like so:
class Foo {
is Bar;
}
Which can be interpreted as a regular compile-time function (I guess
we call those macros) that acts on some topic container (think io[1]).
So we seem to have stolen that from Test, too.
I wonder if there is a macroey thing that we can do here. That is,
could we make:
ok(1);
is(1, 1);
like(foo, /foo/);
Into:
ok(1);
ok(1 == 1);
ok(foo ~~ /foo/);
And lexically analyze the argument to ok() to find out how to report
the error? Something in the style of Smart::Comments which looks at
subexpressions and tells you about them automatically.
The only downside is that you can't refer to ok as a coderef. I
think that is a small price to pay for such a wonderful DWIMmity.
Luke
[1] http://www.iolanguage.com
