Internals WG, through August 15th

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