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 you can start at
http://xrl.us/c2pv -- 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...
http://xrl.us/c2pw
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 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.
http://xrl.us/c2px
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.
http://xrl.us/c2py
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.
http://xrl.us/c2pz
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.
http://xrl.us/c2p2
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.
http://xrl.us/c2p3
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.
http://xrl.us/c2p4
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.
http://xrl.us/c2p5
Patrick R. Michaud Speaks!
Mark Patrick's words: There will be a Perl 6.
Now all that remains is to find out when.
http://xrl.us/c2p6
mod_parrot progress
Jeff Horwitz updated everyone on his progress with updating (rewriting)
a mod_parrot plugin for Apache 2.
http://xrl.us/c2p7
Continuations and GC. Continued
They're baack! Just when you thought return continuations had been
sorted, they're back and causing memory leaks.
http://xrl.us/c2p8
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.
http://xrl.us/c2p9
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.
http://xrl.us/c2qa
http://xrl.us/c2qb - Part two.
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.
http://xrl.us/c2qc
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.
http://xrl.us/c2qd
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.
http://xrl.us/c2qe
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.
http://xrl.us/c2qf
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.
http://xrl.us/c2qg
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:{...}
http://xrl.us/c2qh
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 to mailto:[EMAIL PROTECTED]
http://donate.perl-foundation.org/ -- The Perl Foundation
http://dev.perl.org/perl6/ -- Perl 6 Development site
Or, you can check out my website.
http://www.bofh.org.uk/
