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

Parse rules as data

 [1/7] from: brett:codeconscious at: 27-Jun-2001 18:16


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. As in: Data-B: TRANSFORM data-A parse-rules-A parse-rules-B Probably would need transform-hints-from-A-to-B as well I suppose, in some form. Even a constrained (in terms of rules) solution might be handy. I suppose this steps into the same space as XSLT and tree-rewriting. Just whip me up one please.. Thanks.. :) Brett.

 [2/7] 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
<<quoted lines omitted: 4>>
> 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

 [3/7] from: brett::codeconscious::com at: 28-Jun-2001 1:05


Hi Joel, Thanks for your reply. The idea you think I had appears not to be the one I think I had. But you're most welcome to pursue the former, though my interest is actually in the latter. The latter being as follows in example form: author-index: context [ author-entry: [author author-rebsite] author: [string!] author-rebsite: [url!] model*: [ any author-entry ] content*: [ "Brett Handley" http://www.codeconscious.com/index.r "Joel Neely" http://www.textimage.com/REBOL/index.r "Allen Kamp" http://www.rebolforces.com/index.r ] ] So I can do:
>> parse author-index/content* author-index/model*
== true Then I'd like to provide a new model and have content "calculated" for me doing something like: rebsite: transform author-index rebsites-spec hints-spec where rebsites-spec is rebsite-spec: context [ reblink: ['folder linkurl 'info author] author: [string!] linkurl: [url!] model*: [ any reblink ] ] and hint-spec contains the magical transformation dialect that makes it all possible :) author-entry -> reblink author -> author author-rebsite -> linkurl So for example I might end up with something like this: rebsites: context [ reblink: ['folder linkurl 'info author] author: [string!] linkurl: [url!] model*: [ any reblink ] content*: [ folder http://www.codeconscious.com/index.r info "Brett Handley" folder http://www.textimage.com/REBOL/index.r info "Joel Neely" folder http://www.rebolforces.com/index.r info "Allen Kamp" ] ] and again I can do:
>> parse rebsites/content* rebsites/model*
== true So I guess I'm wondering if some function 'transform and some fantastic transformation dialect will be more economical than just writing the transformation directly in straight Rebol code. Should I go back to dreaming? Maybe the data generator will be more useful :) Brett.

 [4/7] from: joel:neely:fedex at: 27-Jun-2001 10:24


Hi, Brett, Brett Handley wrote:
> The idea you think I had appears not to be the one I think > I had. But you're most welcome to pursue the former, though > my interest is actually in the latter. >
You're welcome to credit for both! ;-) I was just observing another application of the root notion of "reverse interpreting" the parse dialect.
> Then I'd like to provide a new model and have content > "calculated" for me doing something like:
<<quoted lines omitted: 8>>
> and hint-spec contains the magical transformation dialect > that makes it all possible :)
...
> So I guess I'm wondering if some function 'transform and some > fantastic transformation dialect will be more economical than > just writing the transformation directly in straight Rebol code. >
I'd guess it depends on how often one does transformations that are sufficiently similar. There are probably situations where the (possibly high) investment in effort to implement the transformer would have a payback over repeatedly hand-crafting the individual translations, but I'd need LOTS of experience doing the specific cases before I'd feel comfortable doing the general case.
> Should I go back to dreaming? >
Dreams are good! For some dream-inspiration, take a look at the specs for XSL and XSLT at http://www.w3.org/Style/XSL/ They're addressing the corresponsing problem for XML -- given one structure expressed in XML, how can one write rules that specifiy how to map it to a different structure in XML/HTML/XHTML? It might give you some more ideas. -- It's turtles all the way down! joel'dot'neely'at'fedex'dot'com

 [5/7] from: jseq:mediaone at: 27-Jun-2001 9:18


Brett, Isn't it quite possible that the two sets of rules are completely orthogonal? For example, Carl's parse samples include driving directions and a cooking recipe. How would you automatically transform between the two? I think that once you'd added the rules or hints needed to effect the transform, you'd have a nice little rebol script and very little logic left for the common engine to implement. JS EIS Architect http://www.pobox.com/~johnseq 6/27/01 4:16:03 AM, "Brett Handley" <[brett--codeconscious--com]> wrote:

 [6/7] from: brett:codeconscious at: 28-Jun-2001 19:50


Hi John,
> Isn't it quite possible that the two sets of rules are completely
orthogonal?
> For example, Carl's parse samples include driving directions and a
cooking recipe. How would you automatically transform between the two? No doubt that there could be orthogonal sets of rules, and in such cases it may be a nonsense to try to transform between them. Though given the activity around e-commerce languages and XSLT type transformations there is probably a family of transforms that would be useful to do. I suppose it would have to be up to the user to decide whether to initate the tranform or not.
> I think that once you'd added the rules or hints needed to effect the
transform, you'd have a nice little rebol script and very little logic left for the common
> engine to implement.
That was bothering me also, but I thought I'd send up the kite to see if it would fly. I thought there should be something smart that one could do with meta-data + meta-data. I suppose it is equivalent to having a relational database with schema-a and asking it to export and then load into schema-b. Tricky :) Brett.

 [7/7] from: jseq:mediaone at: 28-Jun-2001 11:38


Brett, As you mentioned below - the metadata is key (which goes beyond simple parse rules). The RDF crowd is trying to do exactly the schema-a to schema-b tranform you describe. Apple created something well regarded in this area with their Meta Content Framework and Hot Sauce project. I believe the effort is either dead or rolled into current W3C RDF projects. http://www.w3.org/TR/NOTE-MCF-XML/ http://home.netscape.com/columns/techvision/innovators_rg.html Carl has suggested REBOL playing a role similar to XML/RDF and metadata. I'm looking forward to the rebol approach to these thorny interoperability issues. JS http://www.pobox.com/~johnseq 6/28/01 5:50:15 AM, "Brett Handley" <[brett--codeconscious--com]> wrote:

Notes
  • Quoted lines have been omitted from some messages.
    View the message alone to see the lines that have been omitted