Perl 6 Summary for the week ending 20030703
"Ooh look, it's another Perl 6 summary. Doesn't that man ever take a
holiday?"
"I think he took one last month."
"Is it in Esperanto this week?"
"I don't think so."
"Does Leon Brocard get a mention?"
"It certainly looks that way."
"Does it start with the internals list again?"
"I think it does, in fact, here it comes now."
Approaching Python
Discussions (and coding) of the Parrot implementation of Python
continued this week. Michal Wallace is working on taking a preexisting
(but incomplete, it's a proof of concept only) python parse tree ->
parrot code generator and rejigging it to generate code for IMCC.
Assuming the initial rejig is doable, Michal surmises that getting a
complete python compiler will be 'just' a matter of fleshing out the
rest of the visitor methods, 'and then dealing with the C-stuff.'
Actually, the main strand of this discussion dealt with ways of
extending IMCC to help optimize the translation of stack based code to
code that uses registers more efficiently (register unspilling as
Benjamin Goldberg called it), which should help with any bytecode
translator based efforts.
http://xrl.us/crudf
http://xrl.us/crukq
Semantics of clone for PIO-objects
J�rgen B�mmels' work on the Parrot IO system continues to find edge
cases in Parrot's memory management subsystem. As initially written, a
clone call adds a reference to a ParrotIO object, but that object is
neither garbage collected nor refcounted, and it gets destroyed when its
first reference is destroyed. The problem can be solved by allocating a
new ParrotIO in the clone call, but J�rgen had some questions about how
to handle various things like what to do with buffering or position
pointers.
Jos Visser offered a suggestion involving indirection and reference
counting which met with (at least) Melvin Smith's approval.
http://xrl.us/crusx
Making 'make' less verbose
Leo T�tsch checked in a patch to make make's output rather less verbose.
After the patch, the make process only echos the name of the file being
compiled, and doesn't spam your terminal with the entire compiler
commandline (the compiler warnings do that). Some people liked this.
Others didn't.
http://xrl.us/cruz5
Don't trace system areas in sweep ops
One of the things we discussed at the Parrot BOF was how to solve the
'bogus objects' problem when doing timely destruction sweeps (The 'bogus
objects' problem is when the stack walk code detects chimerical objects
through holes in the C stack (hmm... if anyone has a good drawing of
this?)). After much discussion we came to the conclusion that the trick
was to only walk the system stack during DOD (Dead Object Detection)
runs that got triggered via resource starvation.
This works because "There is nothing unanchored and alive beyond the
runloop's stack". Brent Dax was impressed, but then, he wasn't at the
BOF so he doesn't know how long it took us to get to the answer.
http://xrl.us/cru73
User defined events
Klaas-Jan Stol wondered if there would be some way of generating and
posting user defined events. Uri Guttman thought that there probably
would be.
http://xrl.us/crviz
PHP/Parrot
The language implementation insanity continues!
Stephen Thorne announced that he's working on implementing a PHP parser
and is seriously considering targetting Parrot. He asked for pointers to
good docs on how to go about doing so. He worried a little about
bootstrapping as well.
Luke Palmer and Simon Glover were forthcoming with lots of useful
answers and pointers.
http://xrl.us/crvsa
Why Parrot uses Continuation Passing Style
In a delayed response to a question from Klaas-Jan Stol, Dan has posted
a long message on the reasons for choosing Continuation Passing Style as
Parrot's calling convention. It's definitely worth the read if you're at
all interested in the reasoning behind Parrot (and the reason that my
copy of *Perl 6 Essentials* has a signed correction from Dan).
http://xrl.us/crv24
IMCC supports the Parrot Calling Conventions
Leo announced that IMCC's brand of assembler, PIR (I can't remember what
it stands for, Parrot Intermediate Representation perhaps). Of course,
there are things it doesn't quite do yet (tail call detection, only
preserving 'necessary' registers...) and it's somewhat lacking on the
test front, but it's a start. Yay Leo!
http://xrl.us/crv75
Another task for the interested: Coverage
Dan threw out another 'task for the interested' this week. At present we
don't have a complete set of coverage tests for the parrot opcodes, nor
do we even know why opcodes do have coverage. Volunteers to fix this
state of affairs (start with a coverage report being generated as part
of the "make test" run) would be very welcome.
It turns out that Leo already has an "unportable, ugly, slightly tested"
script generating a coverage report of sorts which he posted. Josh
Wilmes also has a coverage testing tool generating reports on the web,
but he'd turned it off following some problems under testing.
http://xrl.us/crwdy
http://xrl.us/crwob -- Josh's reports
Pirate (py...rrot)
Will the terrible jokes never stop?
Michal Wallace reported to the list on his attempts to retool amk's
parrot-gen.py to generate code for IMCC. It sounds like he's making good
progress, but his choice of codename -- Pirate, from py...rrot -- had at
least one summarizer groaning.
Later Michal asked the list about the best way of generating subroutines
and asked for some pointers about how best to arrange the generated
code. He also let slip that Pirate could handle Lists, strings, and
ints; assignments; control structures; maths; boolean logic; and
comparisons...
Leo came up with a suggestion about code layout for Michal and spoke for
everyone (I think) when he added:
"Wow."
Luke Palmer offered a few performance tuning tips (the parrot of Python
translation is currently running 3 times slower than python on euclid,
but I'm sure we'll get that fixed soon enough.
http://xrl.us/crwwo
http://xrl.us/crw4n
JVM->PIR translator
Just as we were all giving Michal some good Wow, Joseph Ryan announced
that he had a partially complete JVM->PIR translator done, though it
still had a few issues.
http://xrl.us/crxbc
http://xrl.us/crxhi
Dynamic PMC Classes
Leo announced that he's started working on dynamic PMC classes. The idea
is that PMCs could be loaded on demand, in a similar fashion (though
hopefully with a nicer interface) to Perl 5's DynaLoader tricks. He
already has something working, and asked for comments.
Dan responded by outlining his thoughts on the interfaces and
requirements for dynamic PMC loading, which weren't quite the same as
what Leo had implemented, but they don't call it software for nothing.
Christian Renz wondered if there were any plans to allow PMCs to be
implemented in Parrot assembly. Dan confirmed that there were.
http://xrl.us/crxmk
Question about "interpreter == NULL"
J�rgen B�mmels wondered which functions allowed the caller to pass in a
NULL pointer in place of the interpreter. Some functions allow this,
others fall in big segfaulty heaps. He and Leo thrashed out the details
of what is and isn't allowed, hopefully this will make it into
documentation at some point.
http://xrl.us/crxrp
Adding "yield" semantics to IMCC
Kenneth A Graves has been experimenting with the ".pcc_*" directives for
implementing function calls, and wants to add coroutine support by
implementing ".pcc_begin_yield" and ".pcc_end_yield" which would be
analogous to the current ".pcc_*_return" directives. He supplied a patch
implementing what he was after. Leo liked the patch and applied it.
http://xrl.us/crxxi
IMCC objects speed, ".include", file-scoped vars et cetera
Now that Parrot nearly has objects, Jerome Quelin has started work on a
new version of Befunge in IMCC. This meant he had a pile of questions
about speed, file scoping of variables, problems with line numbering
within included files, and fragility in the absence of newline
termination.
Melvin Smith opined that the time had come to start putting together a
nice web based set of docs for IMCC, and volunteered to start work on it
himself as soon as he'd caught up with the current state of the IMCC
art.
Leo T�tsch meanwhile answered most of Jerome's questions.
http://xrl.us/crx5m
IMCC's "call" vs first class functions
If you were still not sure of the virtues of Continuation Passing Style
in Parrot, then Michal Wallace's problems with making first class
function objects in Pirate might help convince you of their virtue. As
far as I can see, just switching to a CPS style should mean that
anonymous functions in Pirate become almost automatic. (I could be wrong
of course)
http://xrl.us/crycc
David Adler Scares Himself
For reasons best known only to himself Dave Adler has implemented an
hq9+ interpreter in pasm. Quite what an hq9+ interpreter is was left as
an exercise for the interested reader. Having just now done the Google
search for the language, I think it's best if I leave it to you to do
the search yourself, but quite frankly, I wouldn't bother.
http://xrl.us/cryj5
Upcoming backwards incompatible changes to IMCC
Leo T�tsch announced some changes to IMCC which will mean it is no
longer backwards compatible. What's changing is that from now, all code
outside of compilation units will be ignored, which means that nested
subroutines will no longer be supported. He will also be adding a new
".globalconst" directive for declaring file scoped constants.
http://xrl.us/cry3r
Embedding Parrot
Jeff Horwitz is interested in embedding parrot in other programs, and
wanted to know if there was any prior art, or even a road map. So far
there's been no response.
http://xrl.us/crzbf
Meanwhile, in perl6-language
Things are starting to warm up a little in perl6-language following the
publication of Exegesis 6 (take a look, you'll find it at
http://xrl.us/crznl, there's much good stuff in there; Perl 6 is
starting to look like a real language I tell you). The volume's not got
up to post-Apocalypse 6 levels yet, but it's early days yet.
Perl 6's "for()" signature
John Siracusa referred back to an earlier summary where I had wondered
if either of two "for" implementations had got the signature quite
right. Luke Palmer (perpetrator of one of the for implementations)
thought that it wasn't quite possible to come up with an accurate
signature for "for" (or at least, not one that could tell the compiler
enough to detect errors at compile time.) because you essentially needed
a slurpy list followed by a block, but slurpy lists have to be the last
parameter in the signature.
John countered by quoting from Exegesis 6 "An important goal of Perl 6
is to make the language powerful enough to implement all its own
built-ins", which doesn't exactly contradict what Luke said, as there's
always the possibility of implementing something "for"-like using a
macro, but that doesn't feel too comfortable.
Rod Adams proposed "non-greedy slurpy arrays" which would be analogous
to non-greedy regex matches and proposed "*?@" as the sigil combination
for such a parameter. (Perl? Line noise? Never!)
Damian Conway tweaked Simon Cozens' "Soylen^WPerl 6 is Ruby!" detector
when he mentioned that Larry was considering adding a special case for
allowing a single &block parameter after a slurpy parameter, but that
both Larry and Damian weren't entirely happy with the idea.
Larry offered words of wisdom. As usual.
http://xrl.us/crzyb
http://xrl.us/crz9j -- the earlier summary
http://xrl.us/cr2hc -- Larry dispenses wisdom
Exegesis 6: Assume nothing
Referring to Exegesis 6, Trey Harris wondered how one could curry a
subroutine to always use the default value for the 'assumed' parameter.
He wanted to be able to created a curried function in such a way that,
if the original function's default value changed, the curried function
would reflect that.
I don't think this thread has been resolved to anyone's satisfaction
yet, and I can't quite tell where it's headed. My gut feeling is that
this is a sufficiently rare requirement that Damian's solution of not
using ".assuming" at all and just writing a simple wrapper function by
hand may be the way forward.
http://xrl.us/cr2pv
Mandating name-only parameters
Mark J. Reed wondered if the new parameter declaration syntax meant it
was possible to declare a mandatory name-only parameter. Damian thinks
it will probably be doable, but only by using traits rather than the
single character prefixes.
http://xrl.us/cr2yl
Small Junctions
Exegesis 6 describes a junction as "a single scalar value that can act
like two or more values at once". Dave Whipp wondered how junctions with
0 or 1 members would behave. As Dave said, the case of a single member
junction is relatively easily to understand, but he's unsure as to the
semantics for a 0 member junction.
Luke Palmer gave a good answer, and pointed at Damian's message about
"Perl 6 and Set Theory" for more detail.
http://xrl.us/cr28j
http://xrl.us/cr3ep
Macros and "is parsed"
Abhijit A Mahabal asked for some clarification about the workings of
macros, in particular how/when macro arguments were parsed. The answer
from Larry appears to be that macros get a default "parsed" trait, which
can be overridden by "is parsed" when the macro is declared, so macro
arguments are parsed by the macro's "parsed" trait.
http://xrl.us/cr3lx
Macro arguments themselves
Luke Palmer wondered what macros do about being passed variables, with a
supplementary question about recursive macros. Larry answered that
macros dealt with their arguments in the way that Luke hoped (it'd be a
disaster if the didn't, frankly), but that to get a recursive macro you
would probably have to write a helper function.
http://xrl.us/cr3q2
Another macro question
Abhijit A. Mahabal wondered what
macro foo() { return { my $x = 7 } }
foo;
print $x;
would be equivalent to. According to Larry, the answer is probably:
do { my $x = 7 }
print $x;
Which would throw an error under use strict. It seems to me that the way
to get expanded code that looks like:
my $x = 7;
print $x;
would be to declare "foo" as:
macro foo() { return 'my $x = 7' }
http://xrl.us/cr3xe
"grep EXPR, LIST"
John Williams wondered if the Perl 5ish "grep EXPR, LIST" would still
work in Perl 6. Larry thinks not. I think it should be possible to
declare an appropriate macro version of grep, but the margins of this
summary are too narrow to contain my solution.
http://xrl.us/cr35m
Acknowledgements, Announcements and Apologies
Thanks to Damian for Exegesis 6, Perl 6 may be slow in coming, but I
like it more with each revelation.
Ooh look, another plug for http://xrl.us/mt4.
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 suggestions for something else to ask
for in this bit to [EMAIL PROTECTED]
