[Python-Dev] Parrot -- should life imitate satire?

[Jeremy Hylton]

>>>>> "ESR" == Eric S Raymond <esr@thyrsus.com> writes:

  ESR> Let's suppose, for the sake of the design discussion, that we
  ESR> can make the type ontologies of the Perl and Python bytecode
  ESR> match up.

What is a type ontology?  The definition of ontology I'm familiar with
is too broad to be useful in understanding what you're getting at.
I've never heard the technical term "type ontology".

  ESR> (Note: making the type ontologies of the two bytecodes match is
  ESR> not the same problem as making the type ontologies of the
  ESR> *languages* match up.  It should be rather simpler because a
  ESR> lot of the differences between, e.g., class semantics can
  ESR> probably be compiled away.  Not a trivial problem, but humor
  ESR> me.)

If I guess at what you mean-- a fuzzy notion that the underlying type
system can support both languages-- then I submit that most of the
hard problems are indeed here.

  ESR> Let's further suppose that we have a callout mechanism from the
  ESR> Parrot interpreter core to the Perl or Python runtime's C level
  ESR> that can pass out Python/Perl types and return them.

Not quite sure what you mean ehre.

  ESR> Given these two premises, what other problems are there?

  ESR> I can see one: garbage collection.  What others are there?

I think you mean memory management in general, not just GC.  Others:
thread model, interpreter management (such as creating embedded
interpreter objects).

Jeremy