I was talking to a colleague (who wishes to remain anonymous), and s/
he had a list of questions about the state of parrot that I think
should end up in the FAQ or elsewhere in the repo. I wanted to post
them here to get some discussion - I don't have answers to many of
these questions myself.
---
1. Why Parrot?
http://www.parrotcode.org/docs/intro.html:
"Parrot is designed with the needs of dynamically typed languages
(such as Perl and Python) in mind, and should be able to run programs
written in these languages more efficiently than VMs developed with
static languages in mind (JVM, .NET). Parrot is also designed to
provide interoperability between languages that compile to it. In
theory, you will be able to write a class in Perl, subclass it in
Python and then instantiate and use that subclass in a Tcl program."
a. What, precisely, about Parrot makes possible more efficient
execution of a dynamically typed language than would be the case with
the JVM or the CLR?
b. Whatever that is, how will it adversely impact the execution of
statically typed languages, including type-inferred languages?
c. How will this impact the execution of statically typed code in
Perl, Python and other targeted languages?
2. General Features
a. How will Parrot support reflection and attributes?
b. How will Parrot support generics types?
c. How will Parrot support interface types?
d. What kind of security models will Parrot support?
e. How will Parrot support small-footprint systems?
f. How will Parrot support direct access to "unmanaged" resources?
g. How will Parrot facilitate distributed processing?
3. Parrot PMC Issues
The Parrot PMC vtable provides a large number of optional functions,
which PMCs can either implement or not. If not implemented, they will
throw an exception at runtime.
a. What support will Parrot provide a compiler to interrogate a PMC at
compile time to know what it actually implements?
All of these functions appear to be predefined because there is no
mechanism for extending this functionality at runtime. It appears that
compilers will be limited to implementing functionality that is
defined in the vtable. The vtable contains the common operations
required by certain languages.
b. How will Parrot handle languages with operations that are not
provided?
http://www.parrotcode.org/docs/vtables.html:
"To be perfectly honest, this is a slightly flawed example, since it's
unlikely that there will be a distinct "Python scalar" PMC class. The
Python compiler could well type-inference variables such that a would
be a PythonString and b would be a PythonNumber. But the point remains
- incrementing a PythonString is very different from incrementing a
PerlScalar."
c. How will Parrot address cross-language semantics?
d. Will each language have to provide its own support for interacting
with PMCs for other languages?
e. How will a PerlScalar interact with a PythonString?
f. What will happen when a PythonString is incremented in Perl code?
Comparing the vtable for a PMC to the JVM and CLR base Object classes,
the PMC is essentially an "abstract" class with dozens of
"unimplemented" methods, while Java's Object provides (and implements)
the following public methods:
equals getClass hashCode notify notifyAll toString wait
Discounting the methods related to Java's peculiar threading
implementation, that's:
equals getClass hashCode toString
Similarly, the CLR's CTS Object provides:
Equals ReferenceEquals GetType GetHashCode ToString
g. Why is it a good thing that PMCs essentially non-contractual
abstract base classes that define a lot of functionality without
implementing it?
h. Why is there no first-tier depth in Parrot's type system, such as:
PMCString, PMCIntger, PMCNumber, ...
4. Parrot VM Issues
Parrot provides what it calls "registers" with no guarantee that these
map to hardware registers.
a. Will any registers ever map, in a Parrot-controlled way, to hardware
registers?
b. How can a compiler efficiently allocate registers if it does not
know which ones will map to hardware registers?
5. Parrot Design Issues
Parrot has many operators and number of Core PMC types for them to
operate on. Parrot has so many operators that it appears to be using
them instead of having a standard library. This is markedly different
than the CLR and JVM systems.
a. Why was this done this way?
b. What is the basis for deciding what will be an operator?
c. How can substantial quantities of additional functionality be added
to this design cleanly?
--
Will "Coke" Coleda
[EMAIL PROTECTED]
