At 3:34 PM +0900 3/5/02, Matt Armstrong wrote:
>Dan Sugalski <dan / sidhe.org> writes:
>
>>  At 6:37 PM +0900 3/4/02, Paul E.C. Melis wrote:
>>
>>>Of course, it will take some time for Parrot to mature, but I wonder
>>>what the future plans are for Ruby with respect to Parrot... Matz?
>>
>>  We've already covered this, and I expect by the time this makes it
>>  out you'll have at least a dozen references to Matz's decision on
>>  this. Parrot won't be the reference engine for the next version of
>>  Ruby. (A decision I agree with, honestly) Neither will it be the
>>  core engine for the next version of Python.
>>
>>  Parrot *will* run both Ruby and Python code in addition to Perl (and
>>  Scheme) code. My goal is to run them all faster than their reference
>>  implementations (well, except for perl 6, as we'll be the reference
>>  implementation). If we manage that we all win, as there'll be a fast
>>  interpreter for them all. If we don't, well, everyone still wins,
>>  since that'll mean the other interpreters will be even faster. I
>>  like fast. Fast is good. :)
>
>I notice Parrot has string operations, and I have this impression that
>Parrot understands Unicode only.  True?

False. :)

>I.e. most of the world punts and goes to Unicode only for the internal
>representation of strings, while Ruby will be able to deal with
>strings in their native charset. \

Parrot's going to handle strings in their native character sets. 
We're going to punt and use Unicode as a pivot when we need to 
convert between two charsets we don't have a direct conversion for, 
and it'll be the lowest common denominator for truly mixed-set 
character usage, but unless you go doing cross-set things you'll stay 
in a native set.
-- 
                                         Dan

--------------------------------------"it's like this"-------------------
Dan Sugalski                          even samurai
dan / sidhe.org                         have teddy bears and even
                                       teddy bears get drunk