first shot for a combinator library for d

Ellery Newcomer ellery-newcomer at utulsa.edu
Fri Dec 10 11:34:51 PST 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


More information about the Digitalmars-d-learn mailing list