|Note: these documents may be out of date. Do not use as reference!|
To see what is currently happening visit http://www.perl6.org/
Yes you read that right; development of the Perl 6 compiler now has its own mailing list. Hopefully, in the coming weeks, the current perl6-internals list will get renamed parrot-internals to reflect that split.
As I write this, groups.google.com hasn't picked up the new list, but I'm sure it will do eventually, so I'm going to continue to use Google URLs here on the theory that they'll work eventually. If you're desperate to read the whole threads before then you can start at www.nntp.perl.org -- there's all of 35 messages there as I type this...
In a thread that migrated over from perl6-language Gregory Keeney continued discussion of whether Perl 6 will/should have an officially blessed bundling system, or whether it should simply have good enough hooks that someone could write one. There was some discussion about whether perl6-compiler is actually the correct list for the discussion...
Herbert Snorrason wondered what state the Perl 6 compiler was in. (I think we all did to be honest, but Herbert got to ask the question.)
Patrick said that he and Luke (I think) are at the beginning stages of building a basic perl 6 grammar engine that compiles to parrot and handles some basic optimizations. In tandem with that, Patrick was also working on writing a Perl 6 grammar. The plan is (and no plan survives contact with the enemy) to get a working basic grammar engine up in the next month or so then use that to build the Perl 6 parser.
As soon as there's code, announcements will be made in all the right places (and who knows? maybe even on Slash dot).
If you want to help with the process of writing the grammar engine, your best bet (at least until there's some running code) is to snag the appropriate apocalypse and use that to write tests and post 'em to the list.
Last week Leo had discussed unhooked ops without definite opcode numbers and asked for comments on what to do with them. Apparently Dan finds many of the boolean functions useful, so they're going to be kept, probably hidden behind a namespace, once we know how namespaces work.
Right now, Parrot's configuration system palms off a lot of the work to the local Perl installation by querying the perl config. Which isn't ideal in the long run. So Dan suggested that now's the time to make a list of what info configure.pl grabs from the perl installation and instead to write(appropriate) probing code ourselves so we can do perl-free configuration. The usual "autoconf!" "No! Metaconfig!" "No! Something else entirely!" discussion occurred. (For the record, Dan seems to favour the 'something else entirely' option).
The bike shed remains unpainted.
Jens Rieks pointed everyone at the shiny new examples/sdl/minesweeper/mines.imc. Speaking as a compulsive Minesweeper in recovery, this is a bad, bad thing.
Steve Fink posted a patch to Parrot's build system to make the process of building libraries of dynamic PMCs rather less platform specific. After a sanity check from Leo it got committed.
The discussion of required semantics to implement a regular expression
engine continued. Chip Salzenberg chipped in with some experience from
the Topaz project (a brave project to reimplement Perl 5 in C++ that,
sadly failed whilst teaching Chip a great deal). I confess that the
thought of an
open_up_and_say_aaah method on Perl Scalars delighted
(Am I the only person who wants to repeat Namespaces! with the same intonation used for 'Monorail!' in the Simpsons?)
As Dan pointed out, Parrot needs namespaces, more than that, it needs them to be designed. So, like the excellent designer he is, he laid out his plan for namespaces and invited comments. And comments there were. We can probably expect a PDD soon. Ish.
Mark Patrick's words: There will be a Perl 6.
Now all that remains is to find out when.
Jeff Horwitz updated everyone on his progress with updating (rewriting) a mod_parrot plugin for Apache 2.
They're baack! Just when you thought return continuations had been sorted, they're back and causing memory leaks.
Dan restated his position on using Autoconf in the parrot build system. It's really rather simple:
We're not using autoconf. Period.
In the discussion, Herbert Snorrason suggested we institute a "Rule One" for Dan. In other words, Dan is always right. Unless he changes his mind ("Rule Two"). Or is overridden by Larry ("The One True Rule One").
It works for me.
Dan posted a discussion of const_string, a Parrot function for making use of string constants from C. It's very useful, but it doesn't seem to be as useful as Dan would like it to be, so he's extended the API.
Personally, I'd like Symbols as first class data structures in Parrot, but not enough that I'm likely to implement the darned things.
groups.google.com[10.0.1.2] - Part two.
Self-described newbie, Richard Jolly asked for clarification on what mixing languages will look like. Dan pointed out that it hadn't actually been specified yet. Besides, the internals list didn't do syntax.
He then outlined what he thought the syntax would look like. He doubts that people will end up mixing languages in single source files though. Further discussion pretty much agreed with Dan, generally arguing that most uses of multiple languages would come from using other languages' libraries.
Jeff "mod_parrot" Horwitz revived a thread from a year ago. He wanted
to be able to use the running process image (say httpd) and grab its
various API functions using
dlfunc. Sadly, although this works for
functions that Apache uses from shared libraries, it doesn't work for
those functions that are statically linked into the binary. He wondered
if this was a bug, or if he was going to have to stick to using the
workaround he'd come up with.
It turns out that it isn't a bug, but it can be done by passing a NULL as the filename from which you're dynamically loading a function. Thanks Leo.
Synopsis 9 covers Perl's data types. And, from such a small acorn grows one might oak of a thread. Some of the discussion was even about Perl's data types. There was also a snide remark about summaries and the correct pronunciation of 'Z' -- in revenge for which I plan to make sure that David Green is never mentioned in a Perl 6 Summary.
Juerd wondered if the parentheses around the signatures of function/method were still strictly necessary. Larry explained that they were and why.
Last week, Larry pointed out that even existing keywords could be overridden with macros. Piers Cawley pointed out that they'd be no fun if they didn't. Larry added the caveat that macros couldn't work with precompiled library code (which is a shame, but understandable). This thread developed into the (occasionally intemperate) discussion of Bundles that later migrated to perl6-compiler.
David Wheeler wondered if the (Smalltalk by way of) Rubyish style of
for in favour appropriate iterators and code blocks would
eventually become good Perl 6 style. (I expect it will in my
code). Larry didn't think it would, but pointed out that the syntax had
been modified recently to make it relatively easy to work that way if
you wanted to. Instead of writing, say:
we'll be able to write
If you find these summaries useful or enjoyable, please consider contributing to the Perl Foundation to help support the development of Perl. You might also like to send feedback or contributions to a 'getting Piers to OSCON 2005' fund to mailto:[email protected]
donate.perl-foundation.org -- The Perl Foundation
dev.perl.org -- Perl 6 Development site
Or, you can check out my website.