Re: Anachronistic Acronyms in Parrot?

[Pedroni Samuele]

From: "Guido van Rossum" <[EMAIL PROTECTED]>
To: "Dan Sugalski" <[EMAIL PROTECTED]>
Cc: "Donal K. Fellows" <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>
Sent: Friday, September 21, 2001 5:53 PM
Subject: Re: Anachronistic Acronyms in Parrot?


> Should we really be discussing encodings this early in the game?
> Shouldn't that be a detail that is none of the engine's business (but
> belongs to the individual data type implementations)?  That's the
> abstraction we strive for in Python's implementation
> (only partially successfully, for various mostly historic reasons).

I don't know if you are aware of that, but the Parrot VM
both has instructions that deal with static typed data
integers (IV?) , floats (NV?) and strings (STRING)
so you can't delay the problem of a string library
to the dynamic typed stuff (PMCs) like in Python

But clearly the PMCs and how to implement
python runtime and semantics through them
and how easy is "our" problem.

A "Parrot Python String" will not be a STRING
but given there are STRINGs it should be
decided how they work...

regards, Samuele Pedroni.