This Week on Perl 6, Week Ending 2004-09-10
This week on perl6-compiler
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, start at perl6-compiler on Perl.org — there’s all of 35 messages there as I type this…
Bundles
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…
Current state?
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 Slashdot).
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.
Meanwhile, in perl6-internals
Fix ops
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.
Perl free configuration
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.
Oh My. Minesweeper!
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.
Dynamic PMC libraries
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.
Semantics for regexes
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 your summarizer.
Namespaces
(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.
Patrick R. Michaud Speaks!
Mark Patrick’s words: There will be a Perl 6.
Now all that remains is to find out when.
mod_parrot progress
Jeff Horwitz updated everyone on his progress with updating (rewriting) a mod_parrot plugin for Apache 2.
Continuations and GC. Continued
They’re baack! Just when you thought return continuations had been sorted, they’re back and causing memory leaks.
No Autoconf, dammit!
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.
Constant strings
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.
Multiple languages clarification
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.
NCI and the running process image
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.
Meanwhile, in perl6-language
Synopsis 9, the discussion continues
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.
Oops.
Sub signatures without parens
Juerd wondered if the parentheses around the signatures of function/method were still strictly necessary. Larry explained that they were and why.
The reach of macros
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.
Iterators and for
David Wheeler wondered if the (Smalltalk by way of) Rubyish style of eschewing 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:
@foo.each({...})
we’ll be able to write
@foo.each:{...}
Announcements, Apologies, Acknowledgements
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.
Or, you can check out my website.
Tags
Feedback
Something wrong with this article? Help us out by opening an issue or pull request on GitHub
