Well, here's something I think I need to delegate. :)
The perl6-internals list hasn't seen nearly the traffic that perl6-language
has, has yet to spawn off any sub-lists, and has produced only a few RFCs.
This is, in general, a good thing, as it's somewhat premature to be getting
too deep into the internals of perl 6 before the language capabilities are
worked out.
There has been a general set of discussions, though. No outcomes yet, but
the gist of them are:
* Perl 6 should be fast
* It's likely we'll use a vtable implementation for variable functions,
possibly a multi-level one. This will give us more flexibility to add and
change variable types and their behaviour. There's some question as to
performance, though, which can't be resolved until we have some code to
work with.
* Perl 6 should be really fast
* We'll likely have perl partitioned, at least conceptually and at an API
level, into four parts. Those would be the parser, the bytecode compiler,
the optimizer, and the back-end execution engine. All of them should be
replaceable.
* Perl 6 should be really, really fast
* The reference back-end may be a TIL, or it may not be. TILs tend to be
fast, but have the drawback of being platform (and sometimes compiler)
specific. We may develop a TIL engine in parallel with the reference
interpreter, if we decide that a TIL engine's not the best way to go.
* Have I mentioned that perl 6 should be fast?
* There was some discussion about garbage collection, but it's not really
gone anywhere, besides to the bookstore. The current reference-count GC
scheme will probably go, though.
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
