Open pesco opened 11 years ago
White space is used pretty much whenever you're parsing text files, so I'd be in favor of having it as part of the API. I'd implement it how you defined it though, unless there's a really compelling performance reason.
E.g. h_whitespace(p) could obviously be defined as h_sequence(h_many(wschar), p) wrapped in an appropriate action, saving a lot of code. I suspect there are other examples.
Is there a particular reason for eschewing such layering or should there be a refactoring pass across the API at some point?
— Reply to this email directly or view it on GitHubhttps://github.com/UpstandingHackers/hammer/issues/32 .
I missed a crucial phrase - "wrapped in an appropriate action". Sorry.
Sent on the go On May 15, 2013 9:20 PM, "Steven P" peasteven@gmail.com wrote:
White space is used pretty much whenever you're parsing text files, so I'd be in favor of having it as part of the API. I'd implement it how you defined it though, unless there's a really compelling performance reason.
- Steven On May 15, 2013 4:57 AM, "pesco" notifications@github.com wrote:
E.g. h_whitespace(p) could obviously be defined as h_sequence(h_many(wschar), p) wrapped in an appropriate action, saving a lot of code. I suspect there are other examples.
Is there a particular reason for eschewing such layering or should there be a refactoring pass across the API at some point?
— Reply to this email directly or view it on GitHubhttps://github.com/UpstandingHackers/hammer/issues/32 .
This seems like a reasonable goal; however, it's worth comparing performance between primitive parsers and compound parsers.
Let's take a look at this again after 1.0.
E.g.
h_whitespace(p)
could obviously be defined ash_sequence(h_many(wschar), p)
wrapped in an appropriate action, saving a lot of code. I suspect there are other examples.Is there a particular reason for eschewing such layering or should there be a refactoring pass across the API at some point?