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.
