I have a question, and sorry if it is redundant. (I can't seem to find a search function on http://archive.develooper.com like I thought used to be there.)
P.S. Please CC any replies to [EMAIL PROTECTED] as I'm not subscribed to this mailing list. For background, I am currently building a comprehensive database abstraction framework in pure Perl 5 (search on CPAN for 'Rosetta') which I believe is granular or low-level enough that I should also be doing a compiled C version of it before too long. While I like to think I write efficient (or at least easy to maintain) Perl, I suspect that a compiled version would be necessary to get really good performance for the amount of data I would be processing. Probably another good reason is to remove a lot of extra layers between my code and the actual compiled database-specific drivers; for one thing, if the drivers normally take SQL and would be parsing it into objects prior to making requests from the db server (rather than the db server doing the parsing), then the use of SQL can be skipped entirely, as I don't have to generate it just for it to be parsed again. Reasoning is similar as to why the likes of LIBXML or DBI are mostly compiled. I decided that I shouldn't waste my time with the Perl 5 XS system and go straight to using the corresponding Parrot extension mechanism instead. Partly this is because the latter should be more mature by the time I am ready to write the C, and also because it should be a lot better designed and a joy to work with than XS. So, some questions: 1. Are PMCs being designed such that compiled Parrot extensions should be using them for all their internal operations where possible, or is it more likely that an extension writer should be using their own structs for most internal operations, and save PMCs mainly for the parts of their code that interface with the Parrot core? Basically, I like that using PMCs internally should save me a lot of work and make writing C more like writing Perl (high-level data structures like sparse arrays and hashes), but I'm concerned whether or not they would use a lot more overhead in resources than would be 'good'. 2. On a related note, if I wanted to implement Rosetta as a standalone C library (like LIBXML) which has Parrot/Perl bindings rather than being designed exclusively as a Parrot extension (should I, *sacrilege*, want it possible to use the library with non-Parrot, eg compiled, applications), is it reasonable to use PMCs as a set of pre-declared data types that are good for use on their own, apart from the Parrot runtime? Of course, I still plan for this library to work on any platform that Parrot does. (Heck, if it hasn't already been done, this setting PMCs free thing could be its own thread.) 3. If it's reasonable to ask, how soon (or how long ago) do you think that Parrot and its official extension interface would stabilize enough that one could start using it in a major way without constant compatability rewrites? (Not that I would be ready for months anyway.) On the other hand, would it actually be helpful for me to write to the current version anyway, as it might help expose deficiencies that would otherwise not show up 'til later? 4. I'm also interested on documentation for writing Parrot extensions, as well as making bindings to the various languages that compile to Parrot bytecode. However, I won't make that an official request as I should RTFM first, so I will do some online searches in the mean time. Thanks in advance for any answers. -- Darren Duncan P.S. Please CC any replies to [EMAIL PROTECTED] as I'm not subscribed to this mailing list.
