As already stated, this site is not a good place to have this discussion since it is OT for here, and the key people you should ask (like Simon Cozens) aren't around.

Again, as already stated, if you phrased some of these questions as questions rather than as statements and arguments, people would probably be more kindly disposed to you.

In any case your statements betray a fundamental lack of knowledge. Perl and Python already work in terms of bytecode machines. Both of them already fit the "virtual super CISC machine" description. Perhaps if you understood that, then you would be in a better position to understand Parrot.

Now the description "super-CISC" should be a tip-off to something important. The idea is that the byte-code allows concise descriptions of the kinds of operations that people do inside of scripting languages. What that means is that a single operation in this byte-code, such as a hash lookup or a regular expression match, may be very complicated indeed in terms of any realistic "Assembly language". These are very high level instructions, which are very complicated. The virtual interpreter will see these and proceed to do something involved and complex. Since the vast majority of the execution time is therefore spent executing the instructions rather than interpreting them. This means that the overhead of interpreting instructions is small, and therefore efficiency of execution has little to do with how directly the bytecode maps to the native architecture, be it CISC or RISC.

In short if you tried to understand what Parrot was doing rather than proceeding to flame upon your initial misunderstandings, you would understand that they actually have a high-level architecture. High-level or low-level, it can be described as an assembly language of a kind. But since it is high-level, it has super complicated instructions, hence their description.

Now to answer the other two questions. There are many excellent reasons to not use Scheme for what they are doing. Here is a sample:

• The concepts that they are looking to "chunk" on are not directly implemented in Scheme, and they have implementations already in C to work from.
• They want to have an implementation in which it is very easy to link to external libraries, and such libraries are most portably linkable in C. Building their stuff in C makes that goal easier to accomplish than it would be if they had to link through the indirection of an implementation built in Lisp.
• Far most importantly, they are an open source effort. That means that they have to go where the contributers they want are, and not vice versa. It is critical for what Parrot is doing that it attract people who hack on perl and python. They know that the key people with that experience are competent at C. They would be far less likely to contribute to a project written in Scheme. If a bunch of Lisp hackers wanted to write their own virtual machine, they might indeed work from Scheme. The techniques to build a language on top of a Lisp are widely known and have been used many times. (eg That is how Smalltalk was developed.) But if they did that, they would be virtually guaranteed to not get core Perl developers interested.

And lastly, whether Parrot is stack based. If Parrot is going to support continuations, then it won't be globally stack based because a stack cannot model the kinds of program flows a continuation requires. Instead each continuation gets its own stack, and so you still need an operation to push and pop to the current register stack. But there will also be operations to switch which stack is the current register stack.