On 08/12/01 14:35 +0100, Nadim Khemir wrote: > I get the feeling this is getting quite serious. If we are going to > cooperate on this, I propose that we do it seriously to avoid having 3 > people doing the same thing in incompatible ways.
Agreed. > Can some one lead this? What is it we want to do and with what ? > > I can see at least 1 big problem (which is a little in fact), NAMING. > > I have an Inline::Flex and an Inline::Bison in alpha. To me > Inline::SomeToolOrLanguage is a direct mapping to the language or tool with > the added possibility to map the tools output to perl. As an example > Jochen's Inline::Yacc modifies the way one writes yacc grammar as they are > enhanced to allow direct perl (or other language) coding in the grammar. I > think this (the naming of the module) is counter intuitive. Add to this that > writing 20 lines of perl code in a grammar instead of just calling a sub > (that would be in the normal perl part) seems even more counter intuitive. > > I am not complaining about jochen's module, I think the idea is great. Can > someone (Ingy?) take responsibility over all naming. A long time ago, I asked the PAUSE group to let me be in charge of the Inline::* namespace. My basic intent was to make sure that all new Inline authors would bounce their idea off the mailing list and see if there were any conflicts or complaints. Andreas Koenig seemed to agree with me, and this summer he mentioned putting something in place that would help enforce this. I don't know if it happened or not, but it really isn't that important. Everyone seems to be playing fair for the most part, and Andreas has a lot more important issues on his plate than Inline. I just had a quick look at: http://search.cpan.org/search?mode=dist&query=inline 16 Total Inline modules! (and one schwernism) Very impressive! The only module name I have reservations about is Inline::Basic. There are lots of Basics and this one is just using the module Language::Basic. This is also one of two cases where the author did not notify the list prior to release. The other is Inline::Octave. But in the end there is no harm done. I'm quite happy to have both in the namespace. I would be glad to arbitrate the naming issues for the Yaccish modules. Better yet it would be nice for the parties involved to collaborate, and propose what the various names would be. Then I can just use my Inline rubber stamp of Approval. > > What I have in my pocket is: > Inline::Flex direct mapping (exports yylex only) > Inline::Bison > Inline::Byacc > All this modules are direct mapping, nothing fancy. I am ready to rename > them to whatever as long as we all agree. I'm no expert in the parser tools realm. As long as these modules support all of the popular implementations of the languages, I think that they are fine names. If there are popular implementations that you don't wish to support, consider making the module subclassable. Did you know that Inline::CPP is a subclass of Inline::C? Another example of friendly programming is Neil Watkiss' Inline::ASM. He wrote the module to support many assembly languages. One last point. There can be more than one implementation of a particular inline language. I could write Inline::Coffee and still use it like: use Inline Java; Inline doesn't get the usage from the module name, it gets it from the ILSM's register() method. (The most recently installed module wins) I put that in place early on to prevent potential conflicts in the Inline ILSM namespace land grab :) It also makes the following module usage possible: use Inline 'C++'; use Inline 'C#'; > This weekend I will look at jochen's module. Please *do* work with Jochen. Perhaps in the end we'll be able to come up with a fast alternative to the current Perl parsing modules, that are just as easy to use as Parse::RecDescent. That would make the world a happier place. Cheers, Brian
