How about this?

The AST declarations are the classes of the objects that the source code is converted into.

For example, when the rule 'num' is parsed successfully, an object of type 'num_t' is created.

Yes, it would be easy. Just write the grammar, then the objects you wish the input to be converted to, and you're good to go.

I can assist you in it, if you tell me which commands would you like to support.

EDIT:

For example, if your input consists of simple commands, your grammar can be like this:

rule whitespace = *expr(' ');
rule run_command = "run";
rule pause_command = "pause";
rule command = run_command | pause_command;
rule grammar = *command;

Your AST would look like this:

class command : public ast_node {
};

class run : public command {
};

class pause : public command {
};

class commands : public ast_container {
public:
    ast_list<command> commands;
};

And the connections between the grammar and the AST would look like this:

ast<commands> ast_commands(grammar);
ast<run> ast_run_command(run_command);
ast<pause> ast_pause_command(pause_command);

You could then parse the input with the following code:

error_list errors;
commands *cmds;
parse(input, grammar, whitespace, errors, cmds);

When the above returns, the pointer 'cmds' would contain a pointer to a commands object, with all the commands the user typed.

Do you mean it or was it sarcasm?

In case it was sarcasm, could you please indicate to me in which areas should the parser library be improved?

If you're not having fun, why do it? If it's only for money, I feel sorry for you.

So simplifying it is at least satisfying, if not fun? OK then.

I absolutely sincerely meant it. Writing parsers is fun.

Except if you use (f)lex/bison/yacc; those are atrociously hard to use, full of obscure edge cases, and the output has the aesthetic appeal of elephant droppings.

I've written quite a bunch of parsers myself lately: a few iterations of a template engine in PHP (started out as a four-line function that went something like preg_match_all -> array_map -> str_replace, but by now, it's a fully-fledged template language with loops and includes and whatnot). A fast C parser for a custom network protocol. A few parsers (query strings, POST message bodies, HTTP requests, etc.) for an experimental web server framework. Another template engine, this time in Haskell (allowing for arbitrary Haskell expressions to be interpolated into the template while still providing HTML-encoding where needed). A parser for my custom sheet music language, also in Haskell.

So yes, writing parsers is fun.

I like the parser-combinator approach - build a generic parser interface, a bunch of atomic parsers, a bunch of combinator parsers, and then build your final parser from these blocks, following along a BNF representation of the grammar. Haskell's Parsec library takes this to the extreme, providing a native Haskell syntax that closely resembles BNF itself:

literal = stringLiteral
        <|> charLiteral
        <|> numberLiteral

But even in a language with less flexible syntax, a similar parser can be built. E.g., in (functional-style) C++, the above could look like this:

AST_Expression* parseLiteral(ParserState& p) {
    AST_Expression* e;
    if (e = parseStringLiteral(p)) return e;
    if (e = parseCharLiteral(p)) return e;
    if (e = parseNumberLiteral(p)) return e;
    return 0; // fail, no parse.
}

Or you could do it OOP-style, which would yield something like:

I guess at this point it may be obvious why I like Haskell.

Hey, I'm not attacking anyone here. Just saying that at least for me, Haskell is the perfect fit for these things. There's about a dozen reasons, but the obvious one is how ridiculously expressive the language is, and how little boilerplate there is in typical Haskell code. C++ isn't bad at all, but you can't deny it is pretty verbose.

Just like I'd do it in any other language, only I do it in Haskell. In fact, the Haskell community has produced some very fine building blocks for MVC-style web development (assuming that's what you're talking about). Really, MVC can be done in Haskell just like in any other language - it's an architectural pattern, not a language-specific one.

Also, I don't see how this has anything to do with the fact that I prefer Haskell over C++ for building parsers.

Uh... what? No. MVC, again, is an architectural pattern; whether or not your programming language provides mutable data structures or not is completely irrelevant.

Just because Haskell values are immutable doesn't mean you can't have mutable state; you just have to implement it on top of immutable objects (this is what the State, Reader and Writer monads and monad transformers are for). You don't modify objects in-place; instead, you write your logic in terms of functions that map old state to new state, and wrap them in a State monad to provide the syntactic sugar to make them behave as if they were mutable.

I'd have to look into how Haskell's GTK bindings do things, but my guess would be that Java's event listener model doesn't translate easily to Haskell; you'll have to do it the Haskell way.

I'd design it so that the controller polls the view for input, then dispatches it to the model and receives a response that tells it what has been changed; this in turn would be used to update the view accordingly. The controller would probably run some kind of main loop, something like:

And then you could define a bunch of commands and command results, and implement runCommand and processCommandResult to dispatch them.

Note, however, that I haven't written any desktop GUI applications in a while, and there are probably more elegant ways of solving this. For starters, you could wrap the main loop in a state monad of type AppState, but I'll leave it as explicit as this.

MVC does not mandate registrations and unregistrations of observers. The whole event listener / observer pattern thing is a Javaism (or rather, a class-based-OOP-ism), and it doesn't translate to other paradigms as-is. It is completely orthogonal to MVC design. MVC simply means: Model = representation of domain logic; View = present data to the user; Controller = get user input and dispatch to model and view.

The observer pattern is one way of doing this, but it's not the only one, and not necessarily the best.

Here's the relevant wikipedia entry to remind you: https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller.

Heh, yeah. Walked right into at least two consecutive strawmen. At least we have established that Haskell is unsuitable for building parsers because I don't know how to implement Swing event listeners with it.