The Perl 6 Summary for the week ending 2004-03-28
... and we're back! Another interesting week in Perl 6. Your Summarizer
even wrote some [parrot] code and it's been simply ages since he did
that. In accordance with ancient custom, we'll start the summary with
perl6-internals.
Building with miniparrot
Back in the early days Dan proposed, and it was generally agreed that
the Parrot build process wouldn't be Perl dependent, but instead there
would be a few OS specific 'bootstrap' scripts, enough to get miniparrot
up and running. Miniparrot would have just enough smarts to be able to
complete the configuration and build the final full parrot.
After last week's discussion about reinventing metaconfig, I wondered if
the miniparrot plan was still in place. It seems I'd missed the
discussion of "stat" that ended up talking about how miniparrot would be
able to do its job. I find myself wondering what else is needed to get
miniparrot to the point where it can start doing configuration work.
http://tinyurl.com/2djx8
Continuations continued (and fun with stacks)
Warning: The following discussion of the Continuation discussions is
irrevocably biased; I find it very hard to be objective about
discussions I participate in, and I was rather loud mouthed in this one.
The previous discussions of the uses and semantics of continuations
carried over into this week. Piers Cawley argued that the current stack
architecture seemed to be optimized for the wrong thing, with the
special case RetContinuations being symptoms. He argued that current
architecture (where a single stack frame can accommodate multiple
pushes, with copy on write semantics being used to handle full
continuations) should be replaced with a 'na�ve' architecture using
linked lists of immutable, simple stack frames, one frame per push.
Switching to this approach, he argued, would do away with a great deal
of code complexity, and issues of high object creation overhead could be
offset by using free lists and preallocation to reuse stack frames. Oh
yes, and there'd be no difference between a RetContinuation and a full
Continuation with this scheme.
Leo T�tsch wasn't convinced. Dan was though, and made the decision to
switch to single item per frame, immutable, non COW stacks. Leo
implemented it. His first cut was rather slow; later refinements added
freelists and other handy stuff to start pulling the performance back
up. I'm sure there's more refinement to come though.
http://tinyurl.com/2k9ke
http://tinyurl.com/yqsxa
http://tinyurl.com/34kas
http://tinyurl.com/2fo5j
http://tinyurl.com/3buyk
Variadic functions
Ilya Martynov had some questions about how to handle variadic functions.
Leo clarified some things and pointed Ilya at the "foldup" op. Jens
Rieks suggested aliasing the registers "I[1-4]" to "argc[ISPN]", which
Leo liked. I'm not sure he's implemented it yet though.
http://tinyurl.com/yugc6
GCC compiling to Parrot
In previous weeks Gerard Butler had posted wondering about getting GCC
to target Parrot. The initial response was rather negative, pointing out
that GCC and Parrot saw memory *very* differently, to the extent that
there would probably be a need have special PMCs for GCC managed memory,
which would make communication between GCC implemented languages and
Parrot implemented ones rather tricky.
Undeterred, Gerald mapped out a way forward and asked for opinions. Dan
thought the scheme looked reasonable, but fenced that with the caveat
that he knows nothing about GCC's internals.
http://tinyurl.com/2qm87
Safe execution core and ops classification
Leo checked in some patches from Jens Rieks to allow classification of
ops. He thought that this meant we were a good way along the road to
providing a 'Safe' run-core option, though there was still a lot to do.
He outlined a road map and asked for comments (and implementations).
Comments were forthcoming, and Dan eventually bundled his comments up
into a single post with some design in it. For some reason this induced
some industrial hand waving about Proof Carrying Code from Steve Fink
(he accused himself of hand waving, not me).
Jarkko Hietaniemi (Emacs' dynamic completion suggested 'Jarkko Himself'
for that one. Well, it made *me* smile) offered the pathological
eval 'while([EMAIL PROTECTED],0){}'
as an example of the kind of bad things that can happen if you allow
"eval EXPR" in your 'safe' code, even with strict rules on what it's
allowed to compile (Dan pointed out that quotas would help in this
particular case...)
If there's one lesson to take from the discussion it's this: Code Safety
is Hard. Whether it's AI Hard or not is left as an exercise for the
interested reader.
http://tinyurl.com/2c2qn
http://tinyurl.com/24q2v
http://tinyurl.com/2jchf -- Dan's big(gish) post
UNO (Universal Network Objects) interface for Parrot?
Tim Bunce pointed everyone at OpenOffice's Universal Network Objects and
wondered if anyone had had a look to see what is needed to plug Parrot
into them. And was promptly Warnocked.
http://tinyurl.com/3fzdg
http://udk.openoffice.org/ -- More on UNO
Load paths
In Perl, it's possible to write "require Some::Module", and Perl will go
off and hunt for the appropriate file in the various directories in its
@INC. You can do something similar in most languages.
Right now, you can't do it in Parrot though; Parrot's "load_bytecode"
and other such ops take filesystem paths so, if things aren't set up
exactly as the programmer expects, Bad Things can happen.
As Dan (and others on IRC and elsewhere I'm sure) points out, this is
sub optimal. He posted an overview of the issue and a few possible ways
forward and asked for comments. There were several. Mostly along the
lines of 'core support for full over the net URIs for bytecode loading
would be unutterably Bad'.
http://tinyurl.com/ysm68
Tcl, looking for a few good people
Will Coleda's Tcl implementation has apparently reached the point where
he'd appreciate assistance. He said as much on the list. If you're
interested in helping getting a full Tcl implementation that targets
Parrot up and running then drop him a line.
http://tinyurl.com/2a8kp
Ulterior Reference Counting for DoD
Andre Pang pointed the list at a paper on yet another Garbage Collection
strategy called 'Ulterior Reference Counting' that looks potentially
interesting. However, it turns out that it doesn't quite work that well
with Parrot since Parrot guarantees that objects don't move around.
http://tinyurl.com/22vux
Multi Method Dispatch vtable functions in bytecode
Dan announced that he'd started adding opcode support for multimethod
dispatch. Leo had a bunch of questions with no answers so far.
http://tinyurl.com/3do7z
So that's where J�rgen's been
After a long absence, J�rgen B�mmels appeared on the list and explained
that he'd got a new job, moved to a new town and had had no connection
to the Internet. He's currently working through a huge backlog of mail
and trying to get familiar with the current state of Parrot. It sounds
like it might be a while before he starts contributing patches to
ParrotIO again. Still, welcome back J�rgen.
http://tinyurl.com/ywaz4
ParrotUnit
Piers Cawley posted his initial version of ParrotUnit, a port of the
xUnit OO testing framework. Warnock applies.
http://tinyurl.com/2dtwl
Behaviour of PMCs on assignment
Dan noted that, right now, binary vtable functions take three arguments,
the destination, the left hand side and the right hand side, which
allows them to either take the type of the destination into account, or
simply to replace it with a new value. The advantage of this approach is
that vtable functions have the potential to be more efficient when, say,
the left hand side is the same as the destination. The disadvantage is
that you have to make a PMC to receive the results of the operation
before you can actually do the operation, which can be a pain (and
suboptimal). Dan offered 3 different options and asked for opinions.
TOGoS argued that the 3 argument form was actually the Wrong Thing in
general and that vtable methods should simply create a new PMC and
replace the destination with it. He argued that this behaviour is what
most HLLs expect, and having it would make the compiler's life a great
deal easier.
http://tinyurl.com/26k8t
Meanwhile, in perl6-language
They talked about Unicode a good deal, but (per my announcement a few
weeks back) I won't be covering those bits.
Outer product considered useful
Luke Palmer proposed an "outer([EMAIL PROTECTED])" function to allow for what he
called 'dynamically nested loops'. He even provided an implementation
for it which used a coroutine. As Simon Cozens pointed out, the fact
that something as powerful as Luke's proposal can be implemented in
(initially buggy) pure Perl 6 with no need for any additions to the
language itself is very nice, but really more of a side issue for the
time being.
http://tinyurl.com/32q4u
Announcements, Acknowledgements, Apologies
No announcements (apart from "Look! ParrotUnit! It's jolly good! You
should use it and send me patches!") this week. And if you think I'm
apologizing...
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 me feedback at
mailto:[EMAIL PROTECTED], or drop by my website, maybe I'll
*really* add some content to it this week.
http://donate.perl-foundation.org/ -- The Perl Foundation
http://dev.perl.org/perl6/ -- Perl 6 Development site
http://www.bofh.org.uk/ -- My website, "Just a Summary"
