>>>>> "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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4