in reply to Repository of Parse::RecDescent grammars?

My experience is that industry-standard formats aren't. I mean, yes, they do exist, but more often than not, they're a de facto standard because everybody in that industry uses the same software for the same task. Further, I find that Parse::RecDescent is more often useful to parse either a) Extremely complex grammars like the SQL example above, or b) Proprietary formats of things like part numbers, internal file formats, etc.

If BAI::Format were truly useful, it would certainly be much more useful to write it as a full-blown module (spit out the code that Parse::RecDescent creates before eval'ing as a starting point), than as a grammar file that needs to be parsed before even starting to process the BAI file(s).

So, overall, while it'd be nice to have, say, SQL available as a grammar, I don't think most people's Parse::RecDescent creations would be either a) useful to anybody else, or b) be able to be released to the public without having your ass sued off.

  • Comment on Re: Repository of Parse::RecDescent grammars?

Replies are listed 'Best First'.
Re: Re: Repository of Parse::RecDescent grammars?
by Maestro_007 (Hermit) on Aug 07, 2002 at 16:40 UTC
    You're probably right about the majority of people's everyday grammars. But I'll bet dollars to donuts there are at least a dozen standards out there that could apply. Medical records? Air-traffic data? Building specifications? If there are a dozen, mightn't that warrant some sort of more general wrapper? This would be in cases where the software people already use is a black-box, and they can't do anything with the data basides what is shoved into a database w/ a limited interface. That's exactly the situation the company was in, so they asked me for help.

    Of course, the maintenance of those standards is an issue. If I didn't know that this standard was fairly well accepted and rarely changed I wouldn't propose it as one of them. Clearly there won't be too many that apply. The idea would be to have grammars for the ones that apply, and to make them flexible.

    Sure, I could create BAI::Format, in fact I already have (though a different name, still need to work on what its CPAN name would be). The problem is that it presumes to know what format you want your data returned in. It doesn't want to know the names of the bank account owners, it wants to know dates and amounts. I'll bet I'll never need the data structures again when I re-use this parser for another project, but I'll still need the parser. If I change it so that all the data is extrapolated into a large hash of hashes, I'll have a huge data structure, only about 15% of which I'll actually need.

    The idea is that I supply the rules for how the file should look, and everyone who downloads the parser will only have to do the easy part, i.e. figuring out what to do with the data. Sure, it'll take some work on their part, but I'll just about guarantee that my solution wouldn't work for them. If someone had done this for my project, leaving all the references to $item[x] out of it, it probably would have taken about 3 hours (less|fewer).

    This still may be a bad idea, especially with the good points you bring up. I guess the real answer will rest on whether or not there are enough of these file formats (that aren't proprietary) to justify it.

    Good comments, thanks.

    MM

[reply]
[d/l]
      I was in the same boat, and just posted my fragments to Snippets to save the next person the effort.

      (If Abigail-II or TheDamian want's to include that in the regex collection mentioned earlier, that's fine)

      —John

[reply]

In Section Meditations