Hi,

Dave Thomas wrote:
> 
> Conrad Schneiker <schneik / austin.ibm.com> writes:
> 
> > Conrad Schneiker wrote:
> >
> > > (1) Is there anything about Perl5 that would have precluded it from
> > > using Ruby's (C-language API) extension scheme (assuming the developers
> > > had known about it at the time, and so on)?
> >
> > Maybe part 2 scared everyone off. Can anyone answer this part (or at
> > least make an educated guess)?
> 
> I guess I was confused by the question. What part of Ruby's extension
> scheme would be useful. 

"(C-language API)"

> Although it
> would be good to see the Ruby API spread (as it's far, far easier to
> code to), that would basically mean writing Perl's internals as if it
> was Ruby.

Do you mean internals insofar as basic datatype representations are
concerned, or something much more extensive--i.e. pretty much
everything? Given that the primary stimulus of Perl6 was to rewrite its
internals (apparently to a much greater extent than was the case in
doing Perl5), probably in a way compatible with modern garbage
collection, I'd expect some flexibility here, since Perl has for a long
time slowly been moving in the direction of Ruby's capability (although
certainly not in the direction of Ruby's elegant usability!). Are you
aware of (off hand) any things about Perl that would make "writing
Perl's internals as if it was Ruby" a technically hopeless prospect?

Is there any good on-line description/documentation of Ruby's C-language
API? Even if I can't find someone qualified to submit this, this is too
interesting an experiment to pass up.

(And by the way, is there a updated version of the Ruby Reference Manual
-- later than c.1998?)

-- 
Conrad Schneiker
(This note is unofficial and subject to improvement without notice.)