You can subscribe to an email version of this summary by sending an empty message to firstname.lastname@example.org.
There were 203 messages across 51 threads, with 46 authors contributing.
Parrot 0.03 should now be available. From the release notes:
What have we unleashed? As promised, the latest release of Parrot, 0.0.3, contains support for complex, language-specific data types to be created. PMCs, or Parrot Magic Cookies, are abstract object data types, with class libraries written in C specifying their behaviour.
To start you off, we have implemented nice, happy, polymorphic Perl undef, Perl Integer, Perl String and Perl Number classes. There's also a default class you can inherit from if you're rolling your own data types. See docs/vtables.pod for all the juicy details.
That's not all, however... We've more documentation, examples, a minature Scheme implementation, support for pushing and popping onto register and global user stacks, subroutine support for Jako, better platform support, and a whole lot more. See the NEWS and ChangeLog files for the rest.
Download it and give it a try.
Adam Turoff has coalesced many of the common questions on Parrot and Perl 6 into the Parrot FAQ.
(17 posts) Terrence Brannon asked why Parrot wasn't simply compiling to GCC's RTL, instead of having to invent a brand new pseudo-architecture.
- Because there are platforms where GCC doesn't run.
- Because GCC's licensing is onerously restrictive for our purposes.
- Because it makes embedding an interpreter a pain.
- Because we dynamically recompile and redefine ourselves, which makes this difficult.
- Because GCC's codegen is pretty bad.
(14 posts) Nguon Hao Ching wondered how external arguments - via the command line, although the environment was quickly added to the discussion - were going to work in Parrot.
Weighing particularly heavy on Dan's mind - embedded interpreters and multi-threaded applications:
Who has control over the environment? The primary thread? All the threads? Should some have access and others not? Is there read-only access, or access to some but not all of the variables? Can an interpreter create or delete entries, and if so which ones? How much control does an embedder have, anyway? Should we call a separate function when getting/setting/querying/deleting? Do we even know which variables exist, or do we have to ask? Is it even thread-safe?
It's kinda messy, and since we can put it off for a bit, I'd as soon do that. We may have a half-kludge solution, but since that's all we have at the moment I'd rather wait and maybe a stroke of genius will occur. Or maybe not, in which case we're not really worse off than we are now.
(11 posts) Alex Gough submitted, then withdrew, a patch to move string-to-number conversions to the encoding layer. (Alex discovered, as Tom Hughes pointed out, that the encoding layer is character agnostic, and that digit determination needs to occur at the character set layer.)
(11 posts) Dan Sugalski posted his thoughts on aggregate keys. Jeff Goff is currently working on implementation.
Currently, Parrot is being developed without a license. Inside sources indicate that Larry is coming to a final decision on this, and Parrot should have one soon.
Parrot now has an IRC channel on
irc.rhizomatic.net for some of the more mundane day-to-day development coordination. Join
#parrot and hang out some time.
It looks like The Parrot Conference will be in San Diego, July 22-26, 2002. More info will be forthcoming, but get your vacation notices in now. (Yes, I believe that some other Open Source stuff will be going on, too. :-)
Bryan C. Warnock