| Note: these documents may be out of date. Do not use as reference! |
To see what is currently happening visit http://www.perl6.org/
Welcome to the second Perl 6 summary of the Copious Free Time era and already I've broken the 'mailed out by Monday evening' promise. There were reasons however, mostly to do with going down to London to do the paperwork for my redundancy stuff. So, I'm emending the promise to 'mailed out by logical Monday evening'.
Starting with perl6-internals (which was pretty quiet this week, only 76 messages compared to perl6-language which tipped the scales with 162)
Piers Cawley worried about class private attributes and asked it it was still going to be possible to write an object serializing tool that wouldn't require tons of Perl class overloads. Dan said that it should still be possible.
Leo Tötsch spent the week working on the packfile format and Parrot's tools for manipulating it. Various internals folks provided feedback, pointers to standards and other handy feedback.
Thomas Whateley has been thinking about how to allow Parrot to run untrusted code in a sandbox, and proposed a system where code would provide a list of required rights and Parrot would guarantee that only those privileges were provided. Matthew Byng-Maddick pointed everyone at the RFC he'd written along these lines and raised the issue of what happens when you call out to a module that's written natively, which he described a 'brick wall'. Others were less sure that this was a showstopper.
Somewhat annoyingly my mailer seems to have had a bad moment and lost some messages, including one from Dan in which he outlined his vision for 'safe mode' and gave some pointers to the VMS docs in this area.
groups.google.com[192.168.2.1] -- Dan's outline
Leon Brocard announced the Parrot Developer World Map, which plots the locations of all the Parrot developers who sent him their location details on a map of the world. A cursory glance at the map would seem to imply that a good place for a Parrot Developers' face to face meeting would be a Caribbean island. Gregor neatly one upped Leon with his interactive SVG version.
Jonathan Sillito found some problems with the coroutine code, so he wrote a test exposing the errors, patched things to fix the errors and added a documentation patch to be on the safe side. Go Jonathan. Steve Fink applied the patches. Jonathan also had a question about naming, and wondered if anyone would be interested in a howto for compiler writers. Nobody commented on this, but the howto sounds like a great idea to me.
Leo Tötsch noted some problems with interpreter->code and
multiple code segments, suggested a way forward and asked for
comments. Nicholas Clark commented, wondering about the potential for
memory leaks but Leo seemed to think that that was covered.
Leo has also been thinking about Parrot run loops and reckons we're doing it wrong. So he proposed a different way of doing things, working through its impact on the various kinds of Parrot core. Steve Fink liked Leo's idea, but Jason Gloudon was less sure.
Michael Lazzaro is working on documenting Perl Arrays and asked for
confirmations and clarifications on various areas of Array behaviour.
One subthread morphed into a discussion of when to use is
properties and when to use but properties. It turns out that the
'is is compile time, but is runtime' rule of thumb is only a
rule of thumb. Damian says that a better distinction is 'but is a
property on a value, is is a property on a referent'. Variables,
arrays, opaque objects, hashes etc are referents and therefore get
is properties. Values are thing things that are held in variables,
arrays, opaque objects etc, and they get but properties.
Martin wondered if it would be possible to use [] to do both hash
and array lookups. Short answer "No". Which isn't to say the thread
didn't take off like a runaway train. After far too many messages we
reached the same 'No' conclusion that Damian had stated way back a the
start of the thread. The reasoning goes like this: Given $container[$spec] you can't use the type of $container to decide
whether to do a hash or an array lookup because there are Perl object
types which have both hash and array semantics. And you can't use
$spec's type either because Perl happily autoconverts between
numbers and strings. So, you need some way to specify what sort of
lookup you need, and you do that by using {} or [] as
appropriate. But, frankly, that's beside the point. The reason we're
not using [] to do both array and hash style lookups is Because
Larry Says So.
groups.google.com[63.120.19.221]
Argh! I've really been screwed by problems with my mail here. For some reason a batch of mail appears to have got dropped on the floor this week and my record of this thread is the one that's suffered the most.
The gist of the thread is that adding a default value to an array opens a whole scary can of worms to do with the distinction between 'undef' and 'exists' (made trickier still by the fact that 'exists' is a pretty vague concept when you're dealing with an array.) Damian's view is that an array with a default value should do the equivalent of
$content = @foo[$index] // @foo.default;
ie, all undefs in the array should be 'replaced' with the array's
default value. And that includes any 'deliberate' undefs (where the
programmer does @foo[$index] = undef). As I understand it, doing
anything else leads to implementation pain. And it leads to even more
fun when your default is computed and the function doing the
computation gets passed the index as an argument. What happens when
someone does a shift?
For some reason this led into a discussion of whether hashes are ordered (they're not, but if you leave a particular hash alone any iterators (keys/values/each) will step through the hash in the same order, repeatably, but that order is not predictable).
groups.google.com -- Current 'default' rules
Damian announced that, owing to time pressures, the need to find paying work, the need to help Larry get the next Apocalypse out the door and to get the associated Exegesis written he's unsubscribed from the language list for the time being, though he expects that he'll probably resubscribe once A6 and E6 are released. Folks wished him well.
After asking for suggestions of a language to implement using parrot, K Stol announced that he would be implementing a Lua->parrot compiler as his final year project.
Gopal V [gopalv82 at symonds dot net]
I'm more interested in Parrot rather than in Perl 6 , since it is the only really free bytecode format out there. I am planning to build a C# to Parrot compiler. I did a bunch of opcodes in this direction , but mostly what I do is lurk around in the mailing list & IRC.
I'm from the DotGNU project and have been playing around in that code for some time. I've still got my foot placed firmly there and am peering over the hedge into parrot. I'm still in college, so I still have to find time to study.
On a Saturday morning after announcing Tuesday afternoon in the release plan.
It's great to be involved with a community project , it's a very entertaining, stimulating and educating experience. In short, I'm in this for the warm fuzzy feeling !.
compulsive hacker, caffeine addict, RSI_sufferer.
I promise, I'll try hard to get the C# compiler working with parrot. (starts singing "Some day, Some way..." off key)
This week's summary was once again prepared in a comfortable chair with plenty of Earl Grey tea and distractions from two delightfully ginger kittens and my embarrassing ability to screw up my Gnus installation (now unscrewed).
Thanks to Gopal V for his answers to the questionnaire this week. If you've been involved in the Perl 6 development process, please consider answering the same set of questions and sending them to [email protected]'>5[email protected] and you'll earn my undying gratitude.
Proofreading was handled by the ever lovely Aspell.
If you appreciated this summary, please consider one or more of the following options:
This week's summary was sponsored by Darren Duncan. Thanks Darren. If you'd like to become a summary sponsor, drop me a line at [email protected]'>p[email protected].