digitalmars.D.learn - first shot for a combinator library for d
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
Dec 10 2010
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
Dec 10 2010
=?ISO-8859-1?Q?Christian_K=F6stlin?= <christian.koestlin gmail.com> thanks for your feedback!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.
first with arrays of objects (templated) because then you could put a lexer in front of the parsers).I looked at your code a bit, but I'm lazy. Why is ParseSuccess.fResults a Variant[] ?
return different types from the parsers. e.g. an integer parser should return an array of ints (or in my case a variantarray containing ints). the use of the variants was the second thing which came to my mind and allowed for mixed returns from the parsers ... e.g. the result of parsing "private int i = 5" could be (by classes) [Modifier, Type, string, int].Lastly, I can't help you with naming :)
libraries organized. because it seems that dsss is not any more for d2? regards christian
Dec 13 2010