I'm using a windows GUI (made with Irrlicht, but it doesn't matter) with textbox and I want some library written with C++ and made for parsing symbols, etc. Basically I create the mnemonic and some run time machinery sorts the mnenomics out to do some operation. Is there such a thing? Is yacc/bison or lex capable of this or thats made for making a compiler?

How about this?

In your calculator.cpp example you have AST declarations, what are those for? It starts on line 61 and goes to 155?

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.

Would it be easy to modify the code to include mnemonics as operators such as run,pause,repeat, etc?

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.

Whee, parsing is fun!

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?

What would I need to compile your calculator example using codeblocks. Anything tricky or special.

I can see now from your edits on how to do it. It seems in my case I have a gui which would grab the text input and invoke the rule for example "run" when the gui button is pressed. Then I would use that to set a boolean in some other class to true. So far I think I could manage that.

This is the real world, who the fuck plays games around here anyways?

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

Its for making a simple interface for a 3d engine. Basically my theory is that using a text box input would allow me to design a gui with only one text box and one button and use commands to do things. Right now I have 20 text boxes and 4 buttons and the gui is getting really complicatedly ugly and difficult to read.

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

Sometimes I get this angry feeling whenever I type code with c++, its not the same with Python though. Its the wordiness of it all.

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.

Nothing tricky or special. A Codeblocks project file is already provided for the specific example.

Maybe it is, but it is a solved problem for me. This parser library allows me to convert any grammar to an AST, even if the grammar has left recursion.

But my c++ parser has EBNF-like syntax too. Unless I overlook something, I do not see Haskell having a particular advantage over c++ in this.

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.

Can you please show me how to do the Model-View-Controller pattern in Haskell?

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.

The MVC pattern requires mutable objects, which Haskell does not have.

I have tried to do the MVC pattern in Haskell, but it eludes me, perhaps because I am too accustomed to imperative programming.

So, since you seem to have more experience in Haskell than me, could you please post some code on how to do the MVC pattern? more specifically, how to do the Model part?

I'll give you what I wanted to achieve: I was trying to make a pacman level editor. My model, in Java, looked like this:

The model obviously had other classes as well (Level, LevelObserver, etc).

The model allowed the view (Swing classes) to be linked to the model so as that when the model changed, the view was automatically refreshed.

I would be extremely pleased if you could do just the above class in Haskell for me. Personally, I tried to do it but I always end up with type errors.

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.

That's not MVC. There are no registrations and unregistrations of observers anywhere in your code.

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.

Tobias got owned by an axilmar setup.

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.

The wikipedia article says that "the view observes the model", and therefore the solution you provided is not an implementation of the MVC pattern.

Get your quotes right.

Also, I believe your original argument went something like this: If I fail to provide an implementation of Java-style event listeners in Haskell, then it logically follows that Haskell is less suitable for implementing parsers than C++.

Yeah, makes perfect sense.

Oh, and for the record: In your example, the view doesn't really observe the model either. It merely passes a bunch of callbacks into the model, and then the model updates the view. Technically speaking.

First of all, the wikipedia article says:

So, my quotes are correct.

Secondly, you are wrong, my request for the MVC pattern in Haskell has nothing to do with parsers. I am really curious on how to do the MVC pattern in Haskell, that's just all there is.

Thirdly, in my example, it is the View class that installs the callbacks in the Model, so, the View really observes the Model.

With all this in mind, can you show me how to do the MVC pattern with observers in Haskell or not?

No, because you said the view observes the model. The article actually says that the view observes the state of the application, and the model is just a representation of the state, not the state itself.

The Wikipedia article says that the Model represents the application's state, and the View observes the application's state. So, Model = State and the View observes the Model, which is actually how MVC is implemented in every language.

It seems we're getting down to semantics. Who would've thought?

I tried downloading Antlr 2.7 and I found the calc example a little confusing. There's a file named calc.g shown below, how do this get compiled with the MAIN.cpp file? I'm using codeblocks btw...

g++ 4.6.3 on Ubuntu has problems with the latest source due to not and and. Using the previous commit works.

Also had to change line 98 of the calculator:

diff --git a/examples/calculator/calculator.cpp b/examples/calculator/calculator
index 7c8fa18..ea0e6c6 100644
--- a/examples/calculator/calculator.cpp
+++ b/examples/calculator/calculator.cpp
@@ -95,7 +95,7 @@ class binary_expr_t : public expr_t {
 public:
     ast_ptr<expr_t> left, right;
 
-    virtual void print(int depth, int tab) const = 0 {
+    virtual void print(int depth, int tab) const {
         left->print(depth);
         right->print(depth);

Jesus H. Christ, I thought I knew all of c++!!! TIL that the words 'not' and 'and' are reserved keywords, as alternatives to operators!

It's part of the C++03 standard, section 2.5.

I fixed the code, thanks Matthew.