7 ms·

For some quick hands-on learning, it might be interesting to read up on Resursive Descent Parsers (http://en.wikipedia.org/wiki/Recursive_descent_parser http://

by chton 12y ago

For some quick hands-on learning, it might be interesting to read up on Resursive Descent Parsers (http://en.wikipedia.org/wiki/Recursive_descent_parser http://en.wikipedia.org/wiki/Recursive_descent_parser). They're easy to understand and easy to code in a language of your choice. Once you have a working one, you can expand it to experiment with your own grammar. Spend some time experimenting that way and you'll be able to get a lot of insight in what the pitfalls of language design are and how you can work with your parser to minimize them.

poseid 12y ago
thanks! do you have some tool that you would recommend to run programs with these grammars. e.g. I have calculator.ycomb and a ycomb grammar. which programs would you recommend to get an output of calculator.ycomb ?
- chton 12y ago
  honestly, I would recommend you write your own parser for it. A grammar is meaningless by itself, and you'll learn a lot more about why yours might work or not work if you do the work yourself. I can't say I know of any good PEG implementations, and even if there were, you'd be limited to what you can express in PEG. A real language can be far broader, encompassing inputs, outputs, complicated functions, etc.
  - poseid 12y ago
    interesting advice to get hands dirty with source code directly. I might think to experiment a bit with C/lexx/yacc then. one thing, I am curious about, what are the kind of "hello_world()" functions, that would print something on a screen... hmm..
    - chton 12y ago
      Getting in on the ground floor tends to be my advice for a lot things. It's hard to make something click if you can't see it work in the flesh. For the typical functions that print output or take input or the likes, I'm always partial to keeping them separate from the grammar itself. You can see the distinction clearly between for example Python: print myVar and Java: System.out.println(myVar); In Python, the print verb is defined in the grammar, and as such needs to be parsed and handled properly. In Java's case, it's regarded as any other method. It's irrelevant to the parser what it does, it just needs to handle it like it would a normal method. This tends to make the whole easier to debug and adapt, since you never need to touch the parser to change behavior of one of these standard methods. This does ofcourse lead to more complex applications, which may not be desirable, depending on the intent of the language. Just my 2 cents :)
poseid 12y ago
maybe this is interesting too: https://github.com/jashkenas/coffeescript/wiki/%5BHowto%5D-Hacking-on-the-CoffeeScript-Compiler https://github.com/jashkenas/coffeescript/wiki/%5BHowto%5D-H...
poseid 12y ago
and http://zaach.github.io/jison/docs/#installation http://zaach.github.io/jison/docs/#installation
- chton 12y ago
  Those are interesting resources, but do remember that a context-free grammar is exactly that: context-free. It might be a fun starting point, but it's much more limited than a grammar you would usually find a real programming language.

by chton 12y ago

poseid 12y ago

thanks! do you have some tool that you would recommend to run programs with these grammars. e.g. I have calculator.ycomb and a ycomb grammar. which programs would you recommend to get an output of calculator.ycomb ?

chton 12y ago
honestly, I would recommend you write your own parser for it. A grammar is meaningless by itself, and you'll learn a lot more about why yours might work or not work if you do the work yourself. I can't say I know of any good PEG implementations, and even if there were, you'd be limited to what you can express in PEG. A real language can be far broader, encompassing inputs, outputs, complicated functions, etc.
- poseid 12y ago
  interesting advice to get hands dirty with source code directly. I might think to experiment a bit with C/lexx/yacc then. one thing, I am curious about, what are the kind of "hello_world()" functions, that would print something on a screen... hmm..
  - chton 12y ago
    Getting in on the ground floor tends to be my advice for a lot things. It's hard to make something click if you can't see it work in the flesh. For the typical functions that print output or take input or the likes, I'm always partial to keeping them separate from the grammar itself. You can see the distinction clearly between for example Python: print myVar and Java: System.out.println(myVar); In Python, the print verb is defined in the grammar, and as such needs to be parsed and handled properly. In Java's case, it's regarded as any other method. It's irrelevant to the parser what it does, it just needs to handle it like it would a normal method. This tends to make the whole easier to debug and adapt, since you never need to touch the parser to change behavior of one of these standard methods. This does ofcourse lead to more complex applications, which may not be desirable, depending on the intent of the language. Just my 2 cents :)

poseid 12y ago

maybe this is interesting too: https://github.com/jashkenas/coffeescript/wiki/%5BHowto%5D-Hacking-on-the-CoffeeScript-Compiler https://github.com/jashkenas/coffeescript/wiki/%5BHowto%5D-H...

poseid 12y ago

and http://zaach.github.io/jison/docs/#installation http://zaach.github.io/jison/docs/#installation

chton 12y ago
Those are interesting resources, but do remember that a context-free grammar is exactly that: context-free. It might be a fun starting point, but it's much more limited than a grammar you would usually find a real programming language.