[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