Guido van Rossum <guido@zope.com> writes:
> > Guido> The PVM doesn't have a lot of knowledge about types built into
> > Guido> its instruction set.... The opcodes are mostly very abstract:
> > Guido> BINARY_ADD etc.
> >
> > Yeah, but the runtime behind the virtual machine knows a hell of a lot about
> > the types. A stream of opcodes doesn't mean anything without the semantics
> > of the functions the interpreter loop calls to do its work. I thought the
> > aim of Eric's Parrot idea was that Perl and Python might be able to share a
> > virtual machine. If both can generate something like today's BINARY_ADD
> > opcode, the underlying types of both Python and Perl better have the same
> > semantics.
>
> Yeah, but the runtime could offer a choice of data types -- for Python
> code the constants table would contain Python ints and strings etc., for
> Perl code it would contain Perl string-number objects. Maybe.
And the point of this would be? I don't see much more benefit than
just arranging for the numbers in Include/opcode.h to match perl's
equivalents (i.e. none), but I may be missing something...
Cheers,
M.
--
I've even been known to get Marmite *near* my mouth -- but never
actually in it yet. Vegamite is right out.
UnicodeError: ASCII unpalatable error: vegamite found, ham expected
-- Tim Peters, comp.lang.python
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