Nice.
Maybe add support for predicated alternatives?
If you *really* want to make it more convenient, you could make a string
mixin front for it, so that one could do something like
mixin(maek_parser("
start -> s1 s2;
s1 -> (`ab`|`cd`) `ef`;
s2 -> (`1`|`2`|`3`);
"));
I don't recommend you do that, though, given D's current state of
affairs regarding ctfe.
Though a runtime version would be doable.
Instead of adding support for char[], wchar[], string, etc, I would
recommend you just make it support a dchar range interface. This hits
all of the above, and then some.
I looked at your code a bit, but I'm lazy. Why is ParseSuccess.fResults
a Variant[] ?
Lastly, I can't help you with naming :)
On 12/10/2010 10:58 AM, Christian Köstlin wrote:
Hi,
I try to learn D and as a testproject I wanted to implement combinator
parsing for D.
That's what I currently have: https://gist.github.com/736456#file_parser.d
It is a simple combinator library including simple matchers,
alternatives, sequences, optional, transformations of the results and so
on.
included is a unit-test that realizes a very simple expression evaluator
(lexing, parsing and evaluation are all put together into one).
My questions are now:
* Starting from this, how should such a module be named?
* In which package structure should it be put?
* How could the language be made more convinient (e.g. I overloaded ~
and | operations to be able to write something like match("super") |
match("not super"))?
Next steps for me would be to add support for different input that
char[] aka strings.
happy to hear from you
christian
