Re: Guidelines for internals proposals and documentation

Using the IBM article that Jarkko found as an example, core implementations of different languages may have more in common with each other 
than implemetations of the same language,

I think PPC is actually significant enough so that it should not be painted into a perl-only corner.

Seeing that the majority of the debate or confusion in PCC is at the germination level, I am proposing a more nebulous level... BS ( for brain 
storming ) which would precede development.  It would be open enough to allow any developer (perl or no) to contirubute while hopefully spinning  
off the perl component into their own lang's direction.  

An example for this would be what I learned at the NYPC/LinuxSociety demo last night.  In the 2.4 compile, you now use "make xconfigure" 
rather than "make configure".  Its a TK app that makes the process more fun than work and it should be ported to every configure esp perl.

On our side, there is notion in of eliminating "make" (a good idea IMHO) by updating the cons modules.  

It would then be a piece of cake for anyone on these lists to bring these two together, where the PPC would guide the feature set... (I'm just 
wondering how to do this in HTML/CPANTS ;)

Anyone who wants can start a BS list w/ GNU/Mailman on http://puny.vm.com just email me an I will make a link;)

John