Perl 6 Summary for the week ending 20030706
Welcome to this week's Perl 6 Summary, coming to you live from a
gatecrashed Speakers' lounge at OSCON/TPC, surrounded by all the cool
people like Dan Sugalski, Lisa Wolfisch, Graham Barr and Geoff Young,
who aren't distracting me from writing this summary at all.
10 minutes later, after the arrival of James Duncan and Adam Turoff, I'm
still not being distracted. Oh no... Leon Brocard's just arrived, which
helps with the running joke, but not with the 'getting the summary
written'.
So, we'll start as usual with the goings on in perl6-internals.
More on Parrot's multiple stack implementations
Dan pointed out that, although Control, User and Pads share the same
stack engine, Pads should be implemented using a simple linked list. He
also confessed that all the register backing stacks should share an
implementation, but that he'd been too lazy to macro things up properly.
http://xrl.us/ldt
Building IMCC as parrot
Leo Tötsch posted an initial patch to make IMCC build as the parrot
executable. And there was much Makefile debugging.
http://xrl.us/ldu
Parrot IO work
Work on Parrot's IO system was ongoing this week.
http://xrl.us/ldv
Parrot Exceptions
Discussion of possibly resumable exceptions continued, and morphed into
a discussion of the workings of warnings when Benjamin Goldberg wondered
if warnings were being implemented as exceptions.
The aren't. I think Benjamin was being confused by Perl 6's "fail"
function which can either issue a warning and return undef to its
caller's caller, or throw an exception, depending on a pragma whose name
I can't for the life of me remember.
http://xrl.us/ldw
Parrot's build system.
Last week Dan asked for help writing a configuration and build system
that would allow per-C-file compiler flag overrides and various other
complexities. This week Alan Burlison worried that this approach looked
'*very* suspect'. This sparked a discussion of the proper way to do
interrupt safe queueing, reentrant code and other scary things.
I may be misreading what's being said in the thread, but it seems that
the scariest thing about the whole issue is that there's no portable way
of doing the Right Thing, which leads to all sorts of painful platform
dependencies and hoopage (From 'to jump through hoops', anything which
requires you to jump through a lot of hoops has a high degree of
hoopage. For the life of me I can't remember if it was me or Leon
Brocard who coined the term).
Swamps were mentioned. Monty Python skits were quoted. Uri Guttman was
overtaken by (MUAHAHAHAHAHA!) megalomania.
http://xrl.us/ldx
Klaas-Jan Stol Explains Everything (part 1)
Last week I mentioned that I didn't know what Klaas-Jan Stol was driving
at when he proposed a general, language-independent "argument" PMC class
and hoped that he would provide an explanation, with code fragments.
This week, Klaas-Jan came through, and I think I understand what he
wants. Go read his explanation and see if you understand it too. It's to
do with when a parameter should be passed by reference or by value.
Parrot currently assumes that Strings and PMCs are passed by reference,
and that integers and floats are passed by value.
There was some discussion of whether support for optionally passing PMCs
by value should be added at the parrot level or whether individual
language compilers should be responsible for calling the appropriate PMC
methods.
http://xrl.us/ldy
Moving ParrotIO to PMCs
Jürgen Bömmels is working hard on moving Parrot's IO-system to a fully
garbage collected PMC based system. He posted an initial patch
transforming ParrotIO structures into PMCs using a simple wrapping
approach.
The patch had problems because the new ParrotIO PMCs were marked as
needing active destruction, which could lead to problems with files
being closed twice and memory structures getting cleaned up twice. Which
is tends to make memory leak detecting tools a little unhappy. This bug
proved to be easy to fix. But then another one reared it's head and has
so far proved rather harder to fix.
http://xrl.us/ldz
Jako gets modules (sort of)
Gregor N Purdy announced that he's added rudimentary module support to
his Jako little(?) language. A little late he announced that he'd added
rather less rudimentary module support.
http://xrl.us/ld2
Stupid Parrot Tricks
Clinton Pierce, shooting for his 'mad genius' badge announced that he'd
implemented a simple CGI script in Parrot BASIC. Everyone gasped. Robert
Spier decided that the time may have come to start playing with
"mod_parrot" (embedding Parrot in Apache) again.
http://xrl.us/ld3
http://xrl.us/ld4 -- that BASIC CGI URL
Lazy Arrays
Luke Palmer is thinking about implementing LazyArray and LazySequence
PMCs and outlined his design approach for the list. Benjamin Goldberg
and Leo Tötsch both contributed answers to some of the questions Luke
raised.
http://xrl.us/ld5
wxWindows Support
David Cuny asked if there was any interest in supporting wxWindows (an
open source, cross platform, native UI framework for a pile of operating
systems).
Leo thought that one could use wxWindows from Parrot via the NCI (Native
Call Interface), but that it wouldn't be at all easy. He thought that
the best way would be a custom dynamically loaded PMC, tied to good
object support in Parrot. Neither of which we have (yet).
Leo also thought that using Parrot as a GCC backend would be a
reasonably sensible idea, but that it 'would need some extensions at
both sides.' He wondered if there were any GCC people listening.
http://xrl.us/ld6
Hash Iterators
Leo checked in his 'buggy initial try' at implementing a hash iterator
for Parrot, but he wasn't entirely happy with his implementation. Sean
O'Rourke suggested a Better Way, which Leo immediately took advantage
of.
http://xrl.us/ld7
Meanwhile, in perl6-language
Almost nothing happened.
"printf" like formatting in interpolated strings
Jonadab the Unsightly One made another proposal in this longrunning
thread.
http://xrl.us/ld8
Perl 6 Daydreams
The directed daydreaming continued. Jonadab is looking forward to Perl
6's new improved object model (him and many, many others I believe).
This morphed into a discussion of porting Inform to run on Parrot. Which
spawned thoughts of when Parrot achieves its final goal of being able to
load and run z-code based interactive fiction. (The theory is that
getting z-code working on Parrot will be the final goal because once
that happens the dev team will stop working on Parrot and spend all
their time playing Zork).
http://xrl.us/ld9
Aliasing an array slice
Dan Brook wondered if it would be either possible or sane to bind a
variable to an array slice:
my @array_slice := @array[1,3,5]
Luke Palmer thought it would have to be, because if it weren't
my [EMAIL PROTECTED] := (1, 1, map { $^a + $^b} zip(@fibs, @fibs[1...]));
wouldn't work (and that would be a bad thing because?)
Damian pointed out that it sort of worked already in Perl 5. This
started people discussing what the Right Thing would finally be in Perl
6.
http://xrl.us/lea
Acknowledgements, Announcements and Apologies
Look, I'm sorry the Summary's late, okay? OSCON is an incredibly
distracting thing to be present at; every time I settled down to write I
got drawn into another fascinating conversation and before I knew it it
was time to go back to my hotel. Which is, of course, where I managed to
knuckle down and write this.
Thanks to Curtis Poe for putting us up for the first couple of nights in
Portland, and to Tom Phoenix for being a top notch Native Guide. No
thanks to Powell's City of Books http://www.powells.com for having far
too much good stuff in stock. Thankfully, they ship.
As ever, if you've appreciated this summary, please consider one or more
of the following options:
* Send money to the Perl Foundation at
http://donate.perl-foundation.org/ and help support the ongoing
development of Perl.
* Get involved in the Perl 6 process. The mailing lists are open to
all. http://dev.perl.org/perl6/ and http://www.parrotcode.org/
are good starting points with links to the appropriate mailing
lists.
* Send feedback, flames, money, photographic and writing commissions,
or a cute little iSight to [EMAIL PROTECTED]
--
Piers
