Parrot Updates

BorrisYeltsin writes: "A couple of updates for Parrot are in a recent This Week on Perl 6, most imporantly Parrot 0.03 is out! Get it here , the release notes are here. Also Adam Turoff has got together the Parrot FAQ version 0.2 which addresses some of the more common questions about Parrot and Perl 6."

Comments

Old News

[mshiltonj]

Parrot 0.0.3 was released way back on the 11th of dec, nearly three weeks ago.

If you want *new* news on perl/parrot, the latest parrot in CVS is now "fully-functional" (interpret that however you want.)

Spam

[Matts]

A large number of perl web sites have been spammed with this. I consider the manner in which it's been done quite rude, as it has in no way been personalised, and is very "spam" like in appearance (i.e. it's saying that DeveloperWork's articles are of the highest quality - well they would, wouldn't they?).

I'm not disputing the quality of the articles there, just pointing out that this has gone to several places, and even been posted on a few sites. I didn't post it on the one I admin because it was totally impersonal.

Re:FAQ leaves me concerned.

[Elian]

Since this seems to be serious, please consider the advantages of a mixed register+stack machine. With 3 32 bit stacks and one 64 bit stack (though if you are using FORTH, you can use the FORTH model, and drop the last one at the expense of having a set of double-cell primitives.

This has been part of the design from the very beginning. In addition to a general purpose stack, each of the register types has a stack associated with it so you can push and pop all the registers of a particular type at once.

The reason for hardware registers is that in hardware fast memory is an expensive and scarse resource.

That's not the only reason. Bits and memory bus bandwidth are also scarce resources, and a small set of named scratchpad spots allows for significant speedups over fully qualifying everything with a memory location.

But in a software implementation, the registers run in the same memory space as the rest of the program. So they loose many of their advantages.

Many, but not all. The stack thrash is a big issue as well and, while there are ways to get around it by allowing references back in the stack, they're generally more awkward than a plain register setup.

There's also an awful lot of literature on writing optimizers which is geared towards register machines, as that's what everyone's CPU is these days. I've not found much readable literature on optimizing a pure stack-based system.

They can, however, save a level of indirection. And that can speed things up if it's on something that is being done frequently. So one alternative is to define the largest stack frame that one wishes to allow for, provide a way for a stack frame to be copied to a fixed location, and then have analogous operations based either on the fixed location, or on a stack frame pointer in the stack. So the stack is a set of modifiable stack frames (though only the top stack frame at any time is resizeable).

Congrats, you just described a register-frame system. Which is what we already have. :)

However, if one isn't modeling an existing hardware implementation, then the virtual machine should not end up looking like any of the hardware.

One is always modelling hardware. That's what this stuff ultimately runs on. You can't ignore the underlying system if you want really good performance. And while a good chunk of our userbase is running on register-starved systems (x86) a lot aren't. The design's not got any serious disadvantages relative to a stack system on x86, and some good advantages on machines with plentiful registers (alpha, sparc, PPC, MIPS, IA64) so it's a win.

Re:OT: question about hyper operators.

[LunaticLeo]

Perl6 is not going to be as explict about this as K apparently is. In perl6 we already know the context of variable because of all the $@% stuff. So we don't need to specify left/right variations of the same operator.

Your examples become:

@x = (1, 2, 3);
@y = (10, 20, 30);
$z = 100;

@x ^+ @y is (11, 22, 33)
@x ^+ $z or $z ^+ @x is (101,102,103)
$z ^+ @y or @y ^+ $z is (110,120,130)

# There is probably a more clever Perl6 way
# also correctness is not guranteed
map { ($_ ^+ @y) } @x is (11 21 31; 12 22 32; 13; 23 33)
map { ($_ ^+ @x) } @y is (11 12 13; 21 22 23; 31 32 33)

There is no @a ^^+ @b for the last two examples, but you might be able to defined your own operators and have the hyperoperator work on it.

But Perl6 does not seem to want to go as far as your language K does. However, modifying the syntaxt of Perl6 on the fly is going to be VERY easy. Something like:

use Ksyntax;

@a ^\+ @b; #like x +\: y
@a ^/+ @b; #like x +/: y

no Ksyntax;
#back to normal

-LL.

Perl Documentation

[Anonymous Coward]

Perl has served its purpose. Sad to say, but its day is done. The time has come for Perl to yield the spotlight to newer, better scripting languages. The reasons for Perl's imminent demise should be obvious to anyone with an ounce of common sense. Nevertheless, the main causes of Perl's lack of fitness deserve to be recounted here:

Perl is emphatically not an object-oriented language. Perl's OO features were crudely hacked in after-the-fact. This unfortunate compromise is the equivalent of trying to bolt an internal-combustion engine onto a stagecoach instead of designing an automobile from the ground up.

Too many simple tasks are pointlessly complicated. Take the simple example of creating an array whose elements are arrays. Not only does the developer need to use additional inner brackets for each element, but they must also remember to use the unique @{$a[1]} syntax when referencing. Why all the extra steps? Who knows.

Perl is notoriously impossible read and maintain. Walk into any bar frequented after-hours by veteran developers and you'll hear story after story being swapped about having to decipher brain-crushing lines of text like :" (my @parsed =$URL =~ m@(\w+)://([^/:]+)(:\d*)?([^#]*)@) || return undef;". This unreadability is in part the result of the fact that:

Perl attempts to be all things to all people and ends up being second-rate at everything.Perl is widely known as the "duct tape of the internet", and it performs superbly in this role. However, just as you cannot build a house out of duct tape alone, so attempting to turn a language that was originally developed for scrpiting brief, handy utilities into a do-all, be-all programming language will only result in the buggy, bloated, "write-only" mess that Perl has become.

Subroutine signatures, orthogonals, method access, data inheritance: this list could go on and on. But there is no real need. Its is now clear that Perl is doomed. At this very moment, Perl 6.0 is being cobbled together, with bulletins about the myriad upcoming features of the new version being issued with titles referring to the Biblical Book of the Apocalypse, the favorite text of messianic streetcorner lunatics. There is no better indicator of the deranged states of mind of the developers behind Perl than this unfortunate choice of imagery. Software developers with any interest in future employment/relevance should sieze this opportunity to attain fluency in Ruby or Python and donate their Perl books to the History Department of their local University.