Why can't they be part of parrot?

Post #124,740 by ben_tilly 11/8/03 11:39:53 AM Reply	Why can't they be part of parrot? If you have concrete technical reasons why not, the Parrot folks would be interested in hearing about it. Parrot is meant to be readily extensible and highly customizable to specialized purposes. (You can even create new bytecodes dynamically!) If there is a need they can't fill that can be demonstrated by pointing to an existing scripting language, now would be the time to try to fix it. Cheers, Ben "good ideas and bad code build communities, the other three combinations do not" - [link\|http://archives.real-time.com/pipermail/cocoon-devel/2000-October/003023.html\|Stefano Mazzocchi]
Post #124,744 by jake123 11/8/03 12:53:34 PM Reply	Re: Why can't they be part of parrot? Because they are quite specific to the OS/2 platform. EG- access to the SOM class hierarchy and the object hierarchy for the desktop. Putting that into parrot seems like bloat for what parrot is supposed to be. Putting it as an 'enhancement' to parrot that is specific to an OS/2 implementation makes a lot more sense, imho. --\n-------------------------------------------------------------------\n* Jack Troughton jake at consultron.ca \n [link\|http://consultron.ca\|http://consultron.ca] [link\|irc://irc.ecomstation.ca\|irc://irc.ecomstation.ca] \n Kingston Ontario Canada [link\|news://news.consultron.ca\|news://news.consultron.ca] *\n-------------------------------------------------------------------
Post #124,755 by ben_tilly 11/8/03 4:26:31 PM Reply	That doesn't seem like a valid objection to me So you write an interface between Parrot and the native object system. There is no reason that you cannot build that on top of Parrot, and once you have done so, that interface would be available to any code running on that interpreter that wanted access. (Even code running in other scripting languages.) Remember, Perl was the language that invented the concept of [link\|http://inline.perl.org/inline/home.html\|Inline.pm], and Parrot would like to make that easier. (Another reason that non-Perl programmers should like Parrot. It will try to make CPAN no longer a reason to choose Perl over, say, Python.) Cheers, Ben "good ideas and bad code build communities, the other three combinations do not" - [link\|http://archives.real-time.com/pipermail/cocoon-devel/2000-October/003023.html\|Stefano Mazzocchi]
Post #124,767 by jake123 11/8/03 9:22:45 PM Reply	No no no no... I'm basically saying that the stuff for that shouldn't be part of the core of parrot, as it's very platform specific. Or, as you said, "There is no reason that you cannot build that on top of Parrot, and once you have done so, that interface would be available to any code running on that interpreter that wanted access." which is exactly what I'm talking about... I want to extend some of those facilities to any scripting language that is able to address them. There are other APIs that are used to load rexx into compiled programs (rexxstart, rxsubcom, etc) that I'd also like to generalise, esp. because with the introduction of object rexx some of those APIs become broken in certain ways that can be catastrophic to the system. It's not like it's unfixable; it's that IBM won't actually do it without someone throwing a ton of dough at them to do it. With that in mind, I'd like to be able to create function-alike APIs that would add some functionality, and 'hook' the current calls to work on a subset of the new calls, so that daemons using user hooks written in rexx would get un-fscked when the system uses the object rexx interpreter. --\n-------------------------------------------------------------------\n Jack Troughton jake at consultron.ca \n [link\|http://consultron.ca\|http://consultron.ca] [link\|irc://irc.ecomstation.ca\|irc://irc.ecomstation.ca] \n Kingston Ontario Canada [link\|news://news.consultron.ca\|news://news.consultron.ca] *\n-------------------------------------------------------------------
Post #124,911 by ben_tilly 11/10/03 10:33:06 AM Reply	Right, but you DON'T need to fork Parrot to do it Just build an extension on top of Parrot for OS/2. Then you get stuff that goes into the regular Parrot, and you don't have to maintain a port. Cheers, Ben "good ideas and bad code build communities, the other three combinations do not" - [link\|http://archives.real-time.com/pipermail/cocoon-devel/2000-October/003023.html\|Stefano Mazzocchi]
Post #124,924 by folkert 11/10/03 11:15:27 AM Reply	If you fork the parrot.... It'll be pinning for the fjord! Better staple the feet on the perch. -- [link\|mailto:greg@gregfolkert.net\|greg], [link\|http://www.iwethey.org/ed_curry\|REMEMBER ED CURRY!] @ *i_wethey*
Post #124,996 by pwhysall 11/10/03 7:46:44 PM Reply	Re: If you fork the parrot.... I'm phoning PETA and the RSPB. Peter [link\|http://www.debian.org\|Shill For Hire] [link\|http://www.kuro5hin.org\|There is no K5 Cabal] [link\|http://guildenstern.dyndns.org\|Blog]

Welcome to IWETHEY!