Perl 6 Summary for the week ending 20030810
Another week, another summary. How predictable is that?
In keeping with the predictability, we'll start with the internals list.
Set vs. Assign
"T.O.G of Spookware" has an issue with the way IMCC treats "=";
sometimes an "=" means "set" and sometimes it means "assign", which
TOGoS finds confusing. What he(?) finds even more confusing is that
sometimes "set" has "assign" semantics.
Dan agreed that this was somewhat confusing, and pointed out that there
was a third possible semantic, "clone".
Luke Palmer agreed with TOGoS and suggested that it would be useful if
the "assign" like behaviours of of "set" were moved over to becoming
"assign" like behaviours of "assign".
Benjamin Goldberg wasn't even sure that "set" and "assign" were good
names for those behaviours in the first place. He proposed three
behaviour classes; "mutate", "alias" and "create". The general feeling
seemed to be that Ben's approach was a good way forward, but I don't
think anything has actually been implemented along these lines yet.
http://xrl.us/oz5
Generic code generator?
Not content with his efforts in porting Python to Parrot, Michal Wallace
floated the idea of a generic code generator for parrot that everyone
could use. Stephen Thorne liked the concept, but worried that it
wouldn't necessarily play well with languages that allowed "eval
$aString". He proposed that, whatever the code generator got written in
should be a language that would be self-hosting.
Joseph Ryan argued that, instead of coming up with a new meta-language
for the GCG (Generic Code Generator), we should use something like XML
or YAML as a way of dumping the AST (Abstract Syntax Tree) with
standardized node names. Dan (who has a 'deep personal loathing for
XML') was all for just building a standard datastructure and passing
that into the code generator. (ASTnode.pmc anyone?). He also suggested
that having some way of doing AST transforms would be handy, as many
languages would want to get hold of the AST and munge it in some way
before it went any further (Lisp macros are the canonical example of
this sort of thing).
Following the discussion, Michal and Klaas-Jan Stol apparently spiked
out a prototype that used s-expressions.
Your summarizer wonders if there's any overlap between this and treecc.
Maybe I've just misunderstood what treecc was all about.
http://xrl.us/oz6
Calling convention questions
Vladimir Lipskiy had a couple of questions about how the calling
conventions worked. Dan and Leo supplied the answers, Vladimir pointed
to the section of pdd03_calling_conventions.pod that had caused the
confusion, and Dan went and fixed the docs.
http://xrl.us/oz7
Infant Mortality
Every so often, perl6-internals ends up talking about the Infant
Mortality Problem -- the possibility of an object being marked as dead
by the GC system before it's even been fully initialized. Benjamin
Goldberg addressed himself to the problem this week by proposing a
generational Garbage Collector. I'm not sure anyone was convinced that
his proposed use of a generational collector to avoid having to walk the
C stack was the Right Thing, but nor do I think anyone's averse to
trying a generational collection scheme to see how performance stacks
up.
http://xrl.us/oz8
Packfile stuff
Dan outlined some things we need to add to the packfile format and the
sub header in order to get things ready for more language work. He, Leo
and the usual suspects thrashed out the implications (assemble.pl and
disassemble.pl will finally get removed from the distribution for
example), but I don't think a final bytecode and sub header format have
been decided upon yet.
http://xrl.us/oz9
Parrot on Win32?
Valery A.Khamenya wondered if there was any news on getting a ready to
run win32 Parrot distribution. Jonathan Worthington has volunteered to
start work on producing regular build snapshots. Yay Jonathan!
http://xrl.us/o2a
Bitwise string ops
Leo Tötsch checked in the beginnings of bitwise operators for strings
and dropped a huge hint that it'd be good if someone could finish things
up. Vladimir Lipskiy took the hint, but felt a good deal of pain trying
to produce appropriately formatted diffs until he worked out how to do
the equivalent of "cvs diff -c" in WinCVS (hopefully the same trick can
be used to do "cvs diff -u", which is the preferred diff format of
perl6-internals).
http://xrl.us/o2b
Dynamic PMC classes
Discussion of the appropriate interfaces for the dynamic loading of PMCs
continued apace. Leo committed his current implementation, stressing
that it wasn't final, but it is at least something to work on.
http://xrl.us/o2c
extproc_parrot
Sometimes I worry about Parrot hackers... Jeff Horwitz announced that
he's successfully built a library that lets you embed parrot in Oracle.
The theory is that, if you want to eventually have an extproc_perl6 in
oracle you'd need to embed parrot anyway. Jeff commented that "what
makes this even cooler" is that, right now, you can theoretically write
oracle extensions in, um, Parrot BASIC.
Personally, I think Oracle and Brainfuck is a match made in heaven.
http://xrl.us/o2d
Pirate guide
Michal Wallace has now got Py-Pirate (The new name for Python on Parrot;
Pirate has been promoted to being the name of the new Generic Code
Generator) up and running using the Parrot calling conventions. He's
also written a guide which explains how the code is laid out for those
who don't know Python.
http://xrl.us/o2e
http://xrl.us/o2f
TWEAKS
Leo Tötsch is a man of many admirable qualities: Official Patchmonster
to the Parrot process; far, far easier to mention every week than Leon
Brocard; and damn fine company when sat in a Parisian café. He does,
however, have a Dark Side and he showed it this week when he came up
with the acronym TWEAKS (Takers Wanted -- Effort And Knowledge Sought).
TWEAKS is Leo's list of things that need doing for which he's soliciting
volunteers. If you want to help with the Parrot effort without
necessarily having to dive into some of the deeper, scary areas, you
could do lots worse than take on one or another of the requirements on
this list. If nothing else you'd earn the gratitude of our friendly
neighbourhood patchmonster.
http://xrl.us/o2g
Parrot gets a vital op
Jos Visser sent in a vitally important patch to Parrot which added a new
"fortytwo" op to Parrot. Nicholas Clark asked if it shouldn't really be
the "what_do_you_get_if_you_multiply_six_by_nine" op. The thread went
downhill from there.
Parrot hackers are definitely worrying.
http://xrl.us/o2h
QUERIES
Leo's Dark Side was on display again as he expanded QUERIES to
"Questions about Unanswered Elderly/Recent Issues Eventually Solvable"
and popped up a list of more or less Warnocked design issues. Dan came
through with answers.
http://xrl.us/o2i
Resumable ops and exceptions
Jos Visser asked if it would be possible to control what happened when
certain operators failed; whether they threw exceptions or just returned
undef for instance. Leo thought this could be done by installing
suitable exception handlers. Leo noted that internal exceptions should
only really be thrown from within opcode implementations rather than
from the functions they call.
http://xrl.us/o2j
"assign" opcodes
Following the earlier discussion of "set" and "assign" Leo has been
working on making the "assign" op do the right thing. This sparked a
little more discussion along the lines of 'what do "set" and "assign"
imply in English anyway?'
http://xrl.us/o2k
Exec
Daniel Grunblatt checked in the latest version of Exec, his tool for
using the JIT at compile time to generate native executables, which now
passes all the tests. As Nicholas Clark said, "Woohoo!". This means that
Daniel has delivered all the deliverables for his Perl Foundation grant.
http://xrl.us/o2l
Calling conventions for variable-length parameter lists
TOGoS asked for some clarification on dealing with variable length
parameter lists, especially when calling functions in an unprototyped
fashion. Frankly, I'm not quite sure what the issue is, but Leo and Luke
Palmer seemed to get it.
It's my gut feeling that Perl 6 function implementations are going to
end up with two different entry points, one for prototyped invocation
and one for an unprototyped invocation which will take a single array
argument, extract parameters from it as appropriate to the function's
prototype, do any runtime argument checking and then make a tail call to
the prototyped entry point.
http://xrl.us/o2m
Why "new_pad *INT*"?
Michal Wallace asked for some clarification about "new_pad", the opcode
that creates a new lexical scratchpad. He thought that, 9 times out of
10 you would want to create a new pad at the next lower depth from the
current pad, but there's no way to automagically do that. Sean O'Rourke
explained that, generally the compiler should keep track of the lexical
depth of the current thing being compiled, so it shouldn't be a problem
to use the right depth anyway.
Those of us writing pure interpreters would still like to be able to do
"new_pad -1", but I think we'll have to implement it ourselves.
http://xrl.us/o2n
struct Parrot_Lexicals; ArrayHash
Leo commented that the current implementation of find_lex(by_name) does
a linear scan over the list of lexical names. He thought that a better
way would be to provide a list of lexicals plus a name hash where the
hash values are indices into the list. He thought that such
functionality might be handy as a general PMC, and proposed implementing
a new PMC called ArrayHash, or SortedHash. Matt Fowles wondered what was
wrong with simply using a hash, and Leo pointed out that some HLL
compilers might well keep their own map of names->indices where known at
compile time and use the numeric index directly.
http://xrl.us/o2o
Meanwhile in perl6-language
Things were surprisingly quiet. Maybe everyone's taking time to digest
the Exegesis. Or maybe the Exegesis was such a model of clarity that
everyone understood it perfectly.
Macros and is parsed
Brent Dax showed off an implementation of the "??::" operator (which
actually turns out to be the "macro infix:?? (...) is parsed(...)"
operator). Larry pointed out that it wasn't *quite* as simple as Brent
had thought because of issues of precedence and making sure that any
lexicals got declared in the appropriate scope.
http://xrl.us/o2p
Implicit parameter aliases
Dave Whipp asked whether parameter names were taken into account during
multiple dispatch, and whether the parameter names in a forward
declaration had to agree with the names used when the sub was fully
declared. Dan answered that parameter names aren't looked at during
multidispatch, but there's been no answer on whether names have to agree
between forward declarations and the implementation (but I'm guessing
that they do).
http://xrl.us/o2q
"printf"-like formatting in interpolated strings
Larry resurrected this old thread (from mid-June when he was indisposed)
and then laid it to rest again with his usual style and grace. It's
worth reading the whole thing I think, because it's a very succinct
description of the kind of expressiveness and power that's inherent in
what we already know about Perl 6.
http://xrl.us/o2r
I want a Ponie!
I promise that, as development of Ponie (the port of Perl 5 to Parrot)
accelerates you'll see a summary of Ponie activity in this summary as
well. However, almost all the traffic on the [EMAIL PROTECTED] mailing
list has been about fighting Subversion. However, Arthur did post a mini
status update at the end of July
http://xrl.us/o2s -- Status report
Acknowledgements, Announcements and Apologies
So, the countdown to moving to the North East is under way. We've just
had an offer accepted in principle on a house in Gateshead so we have
got to get this one on the market (and sold) sharpish. What giddy fun!
Meanwhile, is it just me, or do we know enough about Perl 6 now that we
could actually start implementing stuff? Admittedly, it'll be lots
easier when Damian finishes Perl6::Rules, but Parrot's looking mature
enough to host most of the behaviour we've seen described. I'd start
hacking myself but... well, see above.
Check out http://xrl.us/mt4 for more of my writing.
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, requests for consultancy, photographic
and writing commissions, or offers on a four bedroomed, 400 year old
house in Newark on Trent to [EMAIL PROTECTED]
