On Wed, 2008-07-23 at 17:09 +0200, François Perrad wrote: > > >From a couple comments you make later, it sounds like you're aiming to > > be perfectly API compatible with the original library implementations > > for Lua and PHP, so that moving to Parrot is a "drop-in" replacement as > > far as the user's source code is concerned; am I correct in this > > assumption? > > > Yes, fully compatible. For me, a Lua-like or PHP-like is just a toy.
Gotcha. Makes sense -- making the implementation switch as smooth and easy as possible will greatly assist bringing them over to the light side. > > I'm not sure what you mean by "only for bootstrap" here. Do you mean > > because of potential performance problems implementing heavy math code > > in PIR as opposed to C? > > > Currently, the whole parrot/perl6 project is in bootstrap stage, ie. > Perl6 is not available. > So, the choice is : > - waiting for Perl6 or other magic tools > - writing PIR today, and doing the job Ah, I think I understand you now. > > Why do you silently ignore extra arguments? Is that part of the > > standard Lua design? > > > It's the standard Lua behavior. So, it's a requirement. Got it. And this is true even for C-implemented libraries? Lua's NCI automatically does extra argument stripping? > > Why were they written in C instead of PHP in the existing PHP > > implementation? Is there any reason we wouldn't be providing a nice > > service to the PHP community by doing the rewrite, totally aside from > > our needs for the Parrot project? > > > I think they use C for performance reason. Do you think they would be fast enough if written in PIR? Or is Pipp so much faster than the original PHP implementation, that a rewrite in pure PHP now makes sense? > >> Finally, improvement in runtime/parrot/library/OpenGL.pir : > >> at this time, just split the function '_export_all_functions' into > >> '_export_GL_functions' & '_export_GLUT_functions'. > > > > Should be easy. However, the OpenGL header parser will try to detect > > and wrap any GL-related API it can find. So we can do this two ways: > > > > 1. Have a single function that takes one or more API names > > (GL, GLU, GLE, AGL, GLX ...) and exports them. This gets > > closer to acting like I believe the Namespace API intended. > > > > 2. Have an export function per API, as you suggested; we'll need > > on the order of a dozen of these to handle the GL APIs seen on > > each of our platforms. It's a fair amount of copied boilerplate, > > but may be mildly more efficient at run time (though I certainly > > hope that symbol export isn't a bottleneck for anyone ...). > > > > In either case, we need to decide what happens when the user tries to > > export an API that hasn't been wrapped. I'm thinking exception .... Would any other Parrot Porters like to weigh in on this? -'f
