At 10:24 2002-10-17 +0000, Smylers wrote: >[...]I reckon it'd be saner to have one of these situations: >* When an extra feature is added to Pod::Simple, it also gets added to the >spec (even if only in an appendix of "things you can get away with but >probably shouldn't") so that anybody else trying to write a parser becomes >aware of them.[...]
True, that approach can be good as a sort of ideal, but it ends up assuming that a spec can, in practice, usefully stipulate all behavior. But in programming and writing, I've observed that as one makes a spec more and more detailed, not only is there a point of diminishing returns, but an actual zone of negative returns. For an example of the zone of negative returns in spec-writing, I encourage the true masochists among you to glance at /The SGML Handbook/. Warning: Every minute spent with /The SGML Handbook/ takes an hour off your life, and kills about 2% of your neocortex. Also, the book costs about $100. I have actually seen one or two technical specs that are worse, but they were /purely/ worse -- there was not one scrap of hope in any bit of them, as they described never-implemented (meta-)systems in totally pointless jargon, and every page of them fractally exhibited the obvious uselessness of the whole work and every one of its constituent parts. But /The SGML Handbook/ actually tempts you by making you think it's JUST about to enlighten you on some point that you really do need to know about, and then it parries and jabs. When you need basic concepts laid out, the book showers you with unintelligible implementional asides. When you need implementational details, the book is a mute network of cross-references and pseudo-BNFs. This is the game that moves as you play. That situation of reductio ad nauseam leads us to the other alternative you mention: > * It becomes decreed that Pod::Simple defines canonical Pod (and > anybody else wanting to write another parser has to mimic its > behaviour). The perlpodspec doc is kept as it is now, such that > anybody who follows it will produce valid Pod. (That is, it's a > one-way relationship: following perlpodspec yields valid Pod, but > it's not the case that all the redundant and/or arcane bits of valid > Pod are in that doc. The doc is good enough for people wanting to > write Pod, but not for somebody wanting to write another parser.) I hope I'm not stating the obvious when I point out that alternative situation basically describes the relationship between Perl (the idea), perl (the single but ever-changing implementation), and the Perl documentation. -- Sean M. Burke http://search.cpan.org/author/sburke/
