*) Unclear parts of the existing architecture are up for discussion.
*) Unspecified architecture parts are up for discussion.
*) Changes to the existing programmer-facing architecture aren't up for current discussion. This includes the parts of parrot's virtual architecture (things like register count, which stacks exist, whether PMCs have vtables, whether strings being potentially binary data and text, what ops exist) which are already specified.
*) Changes to the internal implementation for performance reasons aren't up for current discussion or re-implementation. "Performs slowly" isn't enough of a reason to rework parts of the internals now (though it will be later).
*) Bug fixes to the internal implementation are up for discussion and implementation.
*) Reworking parts of the implementation because newly specified features make the current implementation untenable is okay.
Basically, if it exists, leave it until we're functionally complete. When we get there we'll have a re-evaluation phase and rework things. It'll be clear when we get to that point. In the mean time, let's stick to buggy parts of the implementation, or parts that won't work with new architecture.
Discussion of things which aren't up for discussion will get a simple, good-humored reply: "http://<insert the perl.org archive link of this message>".
The design isn't perfect. No design ever is. But we'll have a much better idea of what our real weaknesses are, and how to address them, once we're functionally complete. Getting functionally complete should be our current overriding goal.
(And for those who've noted that this is somewhat different than my normal postings, well... this is what happens when you get someone competent in the use of english language involved :)
--
Dan
--------------------------------------it's like this-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
