Leopold Toetsch wrote: > Well, if you have some mixed environment, you'd probably build parrot on > all machines with the PMC's needed. Something like: > > perl Configure.pl --with-tcl --with-python > > to get these PMCs built on it.
I'm thinking of situations like web hosting, where the provider will in future offer parrot alongside php etc. But you probably won't be able to convince the average web hosting provider to reconfigure their parrot installation to include PMCs that support your preferred niche language. Dan wrote: > I was hoping we'd see hybrid PMCs -- that is, language specific > PMCs that were fully implemented both in pure bytecode and in C. > You'd use the C version if you could, otherwise you'd use the > bytecode version ... There probably ought to be facilities in > parrot itself, or in its library loading and management code, > to handle this. That would be excellent. Matt Diephouse wrote: > Should as much functionality as possible be put into the core PMCs? I'd like to see parrot include a set of core PMCs that implement fairly pure abstractions, without any language-specific stuff (such as automatic conversions, preconceived notions of which string values are true/false etc). It would be easier for a language implementor to add functionality to these, than to modify PMCs that include some perl-isms or python-isms. > > I'd like the ability to distribute bytecode without PMCs; I think it's > > something worth working for. I agree. I'm currently using the existing parrot core PMCs for the amber language. But I can see that I could get much better performance and the precise semantics that I want by writing my own PMCs instead - and I may yet have to do this. Leo: > I still like to unify ParrotObjects and PMCs more. I second that. I liked the directions in which that was moving. Regards, Roger Browne
