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?  How will this mesh with
Ruby's (planned) charset agnostic m18n strategy?

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.  Might this make a Ruby running on
Parrot difficult?  Or perhaps limit that Ruby to Unicode strings?

-- 
matt