Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search

[REBOL] Re: Parse rules as data

From: joel:neely:fedex at: 27-Jun-2001 3:13

Hi, Brett, Handy idea for creating test data... Brett Handley wrote:
> Just musing.. > > If a set of parse rules validate some data, then they > certainly describe it too. > > I was wondering that if given data-A that is parsed by > parse-rules-A and parse-rules-B a smart program could > produce data-B that can be parsed by parse-rules-B... > > Probably would need transform-hints-from-A-to-B as well > I suppose, in some form. >
Many years ago in a galaxy far, far away, I wrote a data generator that took "specs" that were essentially a simple form of regular expressions and created output that matched those specs. There are a couple of policy questions: 1) How much data does one want? 2) How specific should one be about "holes" in the data? With regard to (1), given digit: charset [#"0" - #"9"] lcalpha: charset [#"a" - #"z"] twochar: [digit lcalpha] there are 260 possible distinct strings that match TWOCHAR (assuming case sensitivity). Should the generator create all of them, or be told how many to create at random, and with/without duplicates allowed? Given label: [lcalpha some [digit | lcalpha]] the length of a *single* LABEL becomes an open issue. With regard to (2), given attrval: [label {="} copy val to {"} skip] there's a severe lack of hints about what characters might appear between the quotes. There could be multiple such holes in a set of parse rules. What would be a good way to supply those hints? 1) Making the parse rules more specific? 2) Refinements on the DEPARSE function? 3) Special comments within the parse rules? 4) ...any other thoughts? -jn- ------------------------------------------------------------ Programming languages: compact, powerful, simple ... Pick any two! joel'dot'neely'at'fedex'dot'com