TR Solutions Pte Ltd

Welcome to Jekyll!

2018-12-24T00:00:00+08:00

Welcome to Jekyll!

This is the first pass at revising the TR Solutions website to be mobile-friendly with Jekyll, Bootstrap and JQuery. The website theme is a public-domain theme from Colorlib called Bobsled.

In this first pass (December 2018), I haven’t updated any of the text, and the ‘Read More’ buttons all point back to the main page. In future passes, I will update the text to reflect what TR Solutions is doing these days.

If you have any queries or comments, feel free to contact us at info.trsolutions.biz.

Thomas O’Dell
December 2018.

Treetop Introductory Tutorial Part 10 of 10 – Summary and Advanced Debugging

2010-03-20T00:00:00+08:00

Let's summarize what we've learned as well as look at more in-depth debugging techniques to help you write more complex grammars. ## Summary of Treetop Features _Comments_ start with `#`, just like Ruby. They capture everything up to the end of the line, just like Ruby. _Grammars_ are identified by the keyword `grammer`, have a CamelCase name, and end with the word `end`, like Ruby classes and modules. Note: you can also have modules in Treetop grammars, just like Ruby. Modules can be used to encapsulate complicated subgrammars. You can use the `include` keyword to include other grammars. Grammars consists of _Rules_. Each rule starts with the keyword `rule`, has a lower-case name, and ends with the word `end`, like Ruby methods. Each rule generates an instance of the class `SyntaxNode`, extended with the methods you defined between the curly brackets. Methods to access the named elements (_child nodes_) are also included. Some useful methods available to a syntax node: {% include 2010-03-20-table-01.html %} A simple program to load a Treetop grammar grammar_name and to parse something with it is: ```ruby #!/usr/bin/env ruby require 'rubygems' require 'treetop' Treetop.load grammar_name # or include grammar_name if Polyglot gem installed parser=GrammarNameParser.new result=parser.parse(input) ``` The `parse` method returns `nil` if the input cannot be parsed by the grammar. In that case `parser.failure_reason` can be used to determine where and for what reason the parser failed. (Unless the reason is because the parser could not consume all the input. In that case, you can use `parser.index` to determine how far it got.) The parse method calls the first rule defined in the grammar. You can override this by setting `parser.root`. A rule consists of: - _Terminals_ (text in quotes) - _Non-Terminals_ (names of other rules) - _Regular Expressions_ (usually inside square brackets) - _Iterations_ (`*` matches 0 or more; `+` matches 1 or more, `?` matches 0 or 1) - _Choices_ (separated by `/`) - _Lookaheads_ (identified by `!` or `&`) - _Method Definitions_ (enclosed in curly brackets) - and, of course brackets to override the standard order. Here are some sample rules to illustrate the types of components: ```ruby grammar SampleGrammar rule root_rule 'terminal' non_terminal [regular expression] end rule sample_iterations optional_non_terminal? 'terminal repeated 0 or more times'* [expression repeated one or more times]+ end rule choice_sample a / b tried_if_cant_match_a_and_does_match_b end rule bracket_override (a / b) tried if matches_a_or_matches_b end rule lookaheads matches_me !as_long_as_not_followed_by_me / matches_me &only_if_followed_by_me end rule with_methods non_terminal { def sample_method can_refer_to_by_name(non_terminal) end } end end ``` ## Advanced Debugging Capabilities The `tt` command provided with Treetop allows you to compile your Treetop grammar into Ruby code. The compiler takes your `file_name.treetop` file and creates a `file_name.rb` file. If you have problems loading your Treetop grammar, use the command-line and `tt` to get more details on why your grammar does not compile. If your grammar does not parse what you think it should parse, you can use the generated Ruby file to figure out what is going on. A sample rule will generate code like this (at least in Treetop 1.4.4 — this aspect of Treetop is the one most likely to change): ```ruby def _nt_double_quote # (some code about cached info) if has_terminal?('"', false, index) r0 = instantiate_node(SyntaxNode,input, index...(index + 1)) @index += 1 else terminal_parse_failure('"') r0 = nil end node_cache[:double_quote][start_index] = r0 r0 end ``` You can insert debug statements into this code and use `require` in place of `Treetop.load` to help you understand how the compiled parser is parsing your text. Finally, you can start up the interactive interpreter `irb` and execute your test code from there. In `irb`, you can call `Treetop.load; parser = GrammarNameParser.new` to reload your grammar each time you change it. In `irb`, you can test out the value of the various syntax nodes and of the parser to determine which grammar will work for you. If your grammar fails to parse, you can still get a sense of how far it got by examining `parser.instance_variable_get :@node_cache`. But by now you're getting into pretty heavy debugging... So that's it! You should have enough knowledge by now to set you on your way. Happy parsing! [Previous](/2010/03/19/treetop-introductory-tutorial-part-09-of-10.html)

Treetop Introductory Tutorial Part 9 of 10 – Looking ahead

2010-03-19T00:00:00+08:00

There is one way that our Treetop grammar is different than the harried UN translator. Treetop grammars have a lookahead function, which allows them to peer a short way into the future, rather like Nicholas Cage in [Next](https://www.imdb.com/title/tt0435705/). We need that feature in order to handle the last case of our email list. If we match a name in quotes, we know when to stop: when we reach the second quote. But when we are parsing the name outside the quotes, we actually want to stop when we reach the (optional) space before the open-angle-bracket. What we would like to do, in effect, is to push that (optional) space and open-angle-bracket back into the future, so the main parser routine (full_email_address) will pick it up properly. So the rule we want is something like this:

If we don't find the quote to start an email name,
gather up all the non-blank-characters into a word.
If the word is going to be followed by optional spaces and an open-angle-bracket,
then stop.
Otherwise, parse the rest of the unquoted email name.

We can represent this in Treetop as follows: ```ruby rule optional_email_name ('"' email_name '"' / unquoted_email_name &([ ]* '<') / '' ){ def email_name_text_value if self.terminal? '' else email_name.text_value end end } end rule unquoted_email_name unquoted_email_name_word (&([ ]* '<') / ([ ]+ unquoted_email_name)) end rule unquoted_email_name_word (!(' '/'<') .)+ # (equivalent to: [^ <]+) end ``` The grammar is getting a little bit more complicated here. Now you know why we left it until last. We can see there are two types of lookaheads in Treetop: Positive Lookaheads and Negative Lookaheads. Postive Lookaheads are indicated by an ampersand (&) and succeed if that pattern is in the immediate future. Negative Lookaheads are indicated by an exclamation mark (!) and succeed if that pattern is not in the immediate future. So `&([ ]*<)` will match optional spaces followed by an ampersand, but will not consume them, so they can be available to the calling routine, namely `full_email_address`. On the other hand, `(!(' '/'<) .)+` says "match any character as long as it is not space or open-angle-bracket". So it will stop when a space or an open-angle-bracket is about to happen. Now we have to figure out how to extract this. The principle is that the calling object (in this case `full_email_address`) should not have to change, to limit the damage. Now we actually get to see a feature of Treetop that makes things simpler! We can add routines in the middle of our patterns, not just at the end. This means we can take the if out of our email_name_text_value method. Modify the grammar as follows: {% include 2010-03-19-code-snippet-01.html %} What we are saying is that, if the `email_name` matches, `email_name_text_value` returns the text value from `email_name`; otherwise, if the `unquoted_email_name matches`, `email_name_text_value` returns the text value from `unquoted_email_name`; otherwise it returns an empty string. Guess what! Nothing needs to change in our Ruby program! That's the benefit of limiting the effect of changes. Give it a try with our test string: ``` "Jena L. Dovie" , ; Charmain Lashunda ; "Traci Shauna" ``` You should get something like: ``` I say yes! I understand! You said the following email addresses: jdovie_qs@agora.bungi.com, Jena L. Dovie marleen_df@acg-aos.com c.lashunda_mc@promero.com, Charmain Lashunda traci_shaunaxp@cs.com, Traci Shauna ``` We have now completed the task we set out to do. We have written a simple Treetop grammar to parse our email list, and along the way we have learned about regular expressions, tail recursion, lookaheads and so much more. After this, sad to say, you're on your own. You will find Treetop quite counter-intuitive, unless you are naturally used to this type of grammar. The next tutorial will summarize what we've learned as well as provide more in-depth debugging techniques to help you write more complex grammars. [Previous](/2010/03/18/treetop-introductory-tutorial-part-08-of-10.html) \| [Next](/2010/03/20/treetop-introductory-tutorial-part-10-of-10.html)

Treetop Introductory Tutorial Part 8 of 10 – Chasing our tail

2010-03-18T00:00:00+08:00

Our goal has always been to understand a list of email addresses. We would like to apply the `full_email_address` rule over and over until our whole list is consumed. Can we? Yes, we can! Remember, our parser is like the poor UN translator — it can only take things in the order it receives them. So how about if we think of our email list using the following rule:

A full email address
followed by (maybe) some spaces
followed by either a comma or a semicolon
followed by (maybe) some more spaces
followed by another email list.

Basically, an email list is an email item followed by an email list (which is an email item followed by an email list, which is...). That's the principle of Tail Recursion. Tail Recursion is an important part of grammars as it allows us to process a list when we don't know at the start how many items there will be in it. We can represent this in Treetop as follows: {% include 2010-03-18-code-snippet-01.html %} Notice that we put our new rule at the head of the list. The first rule of our grammar is called the *root*. It represents what, all together, we are looking for. Since we are looking for an email list, it's appropriate that our root rule is `email_list`. You may be asking why we used `(','/';')` instead of the simpler `[,;]`. The reasons are rather difficult to explain, having to do with backtracking capability (the ability to pretend we never translated something). From your point of view, items you put in Regular Expressions will not generate error messages when they're missing, whereas items in quotes will. This is all very well and fine if we are processing an infinite email list. But email lists, like all good things, have to end some time. So we need to build in an way to end our email list. We already know how to use options, because we did that in the previous tutorial. Modify your grammar as follows to make the remainder of the list optional: ```ruby rule email_list full_email_address [ ]* optional_email_list end rule optional_email_list (','/';') [ ]* email_list / '' end ``` Now we need a way to access the list of email names. What do you think is the easiest way? Of course, you're right! We add a Ruby routine to extract the email name and address, and then we append the return value from our recursive call to that list. Your code will look something like this: ```ruby rule email_list full_email_address [ ]* optional_email_list { # return an array of email pairs, # each pair consisting of an (optionally empty) email name # followed by an email address. def list_of_email_pairs # start out with the email name and address for the first email email_list = [ [full_email_address.optional_email_name.email_name_text_value, full_email_address.email_address.text_value] ] # unless we are the last pair, unless optional_email_list.terminal? # add in the pairs from the rest of the list email_list += optional_email_list.email_list.list_of_email_pairs end email_list end } end ``` The modifications to the email list program should be easy. Just use the each method to display the pairs according to our original intent: ```ruby puts "You said the following email addresses:" result.list_of_email_pairs.each do |email_pair| print " #{email_pair[1]}" print ", #{email_pair[0]}" unless email_pair[0].empty? print "\n" end ``` Give it a spin with our first two full addresses together: ``` "Jena L. Dovie" , ``` Works? Good! Okay, at this point, you have learned quite a bit about Treetop, and you could go on to write more of your own grammars with a little help from the (sparse) documentation. However, there's one email address we haven't figured out how to parse: `Charmain Lashunda ` To parse that address we have to look at some of the advanced features of Treetop grammars. Read on, if you dare! [Previous](/2010/03/17/treetop-introductory-tutorial-part-07-of-10.html) \| [Next](/2010/03/19/treetop-introductory-tutorial-part-09-of-10.html)

Treetop Introductory Tutorial Part 7 of 10 – Has/has not

2010-03-17T00:00:00+08:00

Let's look at the next contact in our email list: ``` ``` This one just has an email address. So the email name portion is optional. In other words, a valid full email address has an optional encapsulated email name followed by spaces followed by an encapsulated email address. We can represent this in Treetop as follows: {% include 2010-03-17-code-snippet-01.html %} In a Treetop grammar, `/` separates two options. The grammar first tries to match the first option. If that fails, then it goes on to the second option. Our second option in the rule `optional email name` is just two single quotes, meaning the empty string. (You can have more than two options if you want.) The key thing to remember, when you are writing grammars with options, is that there needs to be some text or pattern that clearly identifies which option is the correct one. Just like the real-time translator at the UN, the parser needs grab some word or character that identifies the correct option for this text. In our case, the double-quote clearly identifies the first option. Then we know that, if there is no double-quote, we should be using the second option. Notice that the Syntax Node structure has changed. That means the understanding our email list program has of the text has also changed. How would you change the line ```ruby puts "You said the email name #{result.email_name.text_value} and the email address #{result.email_address.text_value}." ``` If you guessed `result.optional_email_name.email_name.text_value`, good choice! However, we have a problem. Will there be a Syntax Node called `email_name` when there is no double-quoted email name? In fact there won't. You can try it out and see. Things now get messy, so the Ruby way is to bury the messiness back in the class. It would be nice if we could modify the `optional_email_name` class so that it returned an empty string when there is no email. Guess what! Treetop allows this! We can add Ruby code right into the grammar that will be included in our resulting tree of Syntax Node instances. Modify the grammar as follows (noting the round brackets, which make sure the rule is properly applied): ```ruby rule optional_email_name ('"' email_name '"' / '' ) { def email_name_text_value if self.terminal? '' else email_name.text_value end end } end ``` And modify the email list program as follows: ```ruby puts "You said the email name #{result.optional_email_name.email_name_text_value} and the email address #{result.email_address.text_value}." ``` Give it a spin with our first two full addresses: ``` "Jena L. Dovie"

``` Works? Good! What about the two addresses together on one line? Let's do that in our next tutorial... [Previous](/2010/03/16/treetop-introductory-tutorial-part-06-of-10.html) \| [Next](/2010/03/18/treetop-introductory-tutorial-part-08-of-10.html)

Treetop Introductory Tutorial Part 6 of 10 – Testing Your Understanding

2010-03-16T00:00:00+08:00

Yes! Our program understands! But how can we be sure? In pedagogy (the science of learning), the difference between "knowing" and "understanding" (or between "understanding" and "knowing", depending on which book you read) is the ability to apply, or to transform, what you have learned, rather than simply parroting it back. So can a Treetop parser transform what it claims to have understood? Make the following modification to your parse_email_list.rb Ruby program: ```ruby if result=parser.parse(what_you_said) puts "I say yes! I understand!" puts "You said the email name #{result.email_name}" else ``` Now run it and supply the same input that it understood last time (`"Jena L. Dovie"`). Now you get a result something like this: ``` You said the email name # ``` Which, if you know about Ruby, means that you got an instance of the Ruby object `Treetop::Runtime::SyntaxNode`. In fact, your result is simply a tree of Syntax Node objects, one for each rule or rule component. You can see this by changing the puts line to read : ```ruby puts "You said the email address #{result.inspect}" ``` Here are some useful methods available to a Syntax Node:

Method	Description
`terminal?`	True if the node doesn't have children.
`non_terminal?`	True if the node does have children.
`text_value`	The text the node has matched.
`elements`	An array of all the children.

So, clearly, text_value is the method we want. Modify your puts line as follows: ```ruby if result=parser.parse(what_you_said) puts "I say yes! I understand!" puts "You said the email name #{result.email_name.text_value}." else ``` Try it again, with the same input—it works! It should be simple then, to add another rule to parse our email address. We know an encapsulated email address is an open-angle-bracket (`<`) followed by the actual email address (which is any character but the close-angle-bracket and the pattern must match at least one character) followed by the close-angle-bracket(`>`). Do this on your own, so you can gain confidence and so you can also gain practice in deciphering Treetop error messages. When you are finished, your program should be able to understand ``` "Jena L. Dovie" ``` And be able to print out: ``` I say yes! I understand! You said the email name Jena L. Dovie and the email address jdovie_qs@agora.bungi.com. ``` Got it? Happy? Good. But what about email addresses that don't have any email names? How can we parse those? On to the next tutorial... [Previous](/2010/03/15/treetop-introductory-tutorial-part-05-of-10.html) \| [Next](/2010/03/17/treetop-introductory-tutorial-part-07-of-10.html)

Treetop Introductory Tutorial Part 5 of 10 – A Match made in Patterns

2010-03-15T00:00:00+08:00

Let's take another look at the email list sample that we want our program to understand: ``` "Jena L. Dovie" , ; Charmain Lashunda ; "Traci Shauna" ``` We might as well start at the beginning, now that we've matched the quote. Let's look at the first email name: ``` "Jena L. Dovie" ``` If I asked you, “where is the actual email name?”, you would probably say something like “It’s whatever’s between the double quotes”. And you'd be right. So let's call the email name with the quotes the “enclosed email name” because it's enclosed by the double quotes. Our enclosed email name could be matched by a rule that looks like this:

The email name enclosed in double quotes

But now we need to understand something fundamental about computer syntax checkers. Computer syntax checkers are like those poor people who offer instantaneous translation at the UN. They have to start translating, even before they know what the speaker is really going to say. Computer parsers like the one created by Treetop start at the beginning of your text, and they make decisions as they go along without knowing what comes next. So here is a clearer definition, that's closer to the way Treetop parsers try to understand your text:

A double-quote (")
followed by the email name
followed by another double-quote (")

Save your `double_quote.treetop` program as `email_list.treetop` and edit it to match the following: ```ruby # a Treetop Grammar to parse email lists # grammar EmailList rule full_email_address '"' email_name '"' end end ``` (Yes, there is something wrong with this program. I'm sure you're smart enough to see it right off. However, let's use this opportunity to see how Treetop tells us about errors.) Save your program `talk_to_me.rb` as `parse_email_list.rb` and change the lines to load the treetop grammar so it loads our new email_list grammar. ```ruby Treetop.load 'email_list' puts 'Loaded email list grammar with no problems...' parser = EmailListParser.new ``` Save and run your `parse_email_list.rb` program. Notice that it loads correctly. (If you followed my instructions exactly. If not, you know what to fix...) Enter the following text into your test program: ``` "Jena L. Dovie" ``` You get an error message something like this: ``` (eval):43:in `_nt_full_email_address': undefined local variable or method `_nt_email_name' for # (NameError) from /Library/Ruby/Gems/1.8/gems/treetop-1.4.4/lib/treetop/runtime/compiled_parser.rb:18:in `send' from /Library/Ruby/Gems/1.8/gems/treetop-1.4.4/lib/treetop/runtime/compiled_parser.rb:18:in `parse' from parse_email_list.rb:17 ``` As usual, not very helpful. But, if we focus on some key information in the error message (with the help of a purple marker):


(eval):43:in `_nt_full_email_address': undefined local variable or method `_nt_email_name' for #<EmailListParser:0x1005b0580> (NameError)

So, what Treetop is trying to tell us, in its arcane way, is that the rule (`_nt_`) `full_email_address` refers to the rule `email_name` — but we never defined any such rule! That's easy to fix: ```ruby # a Treetop Grammar to parse email lists # grammar EmailList rule full_email_address '"' email_name '"' end rule email_name [^"]* end end ``` Oops. Completely new concept here. What we have entered for email name is called a _Regular Expression_. Regular expressions match patterns of text, so it's like Treetop but much more condensed. The email name pattern `[^"]*` can be expressed as the following rule.

Match any character except the double-quote
And keep matching as long as possible

Some other useful regular expressions you might need in Treetop grammars:

Expression	Meaning
`[a-zA-Z]`	match any letter in the range a to z or A to Z (e.g. match 'a', 'e', 'W', 'Z', but don't match '%', '3' or '*').
`.*`	match any character, any number of them (even none at all!).
`[.]*`	match any number of periods, e.g. '', '.', '..', '...'.
`c+`	match at least 1 c, e.g. 'c', 'cc', 'ccc'.

If this is your first encounter with Regular Expressions, accept that it's going to take you a while to digest them. You can read about Regular Expressions at [Regular-Expressions.info](https://www.regular-expressions.info/index.html). There is even a tutorial there you can try. Before we go on, let's fire up our test program and see if our grammar that has the regular expression for email_name works. Save the modified grammar and run your test program. Enter the following text when prompted: ``` "Jena L. Dovie" ``` Yes! It understands! But understands what? That's for our next tutorial. [Previous](/2010/03/14/treetop-introductory-tutorial-part-04-of-10.html) \| [Next](/2010/03/16/treetop-introductory-tutorial-part-06-of-10.html)

Treetop Introductory Tutorial Part 4 of 10 – What Went Wrong?

2010-03-14T00:00:00+08:00

Well, not that much more complicated. It's a truism about computer languages, that the most important tool is the console. What I mean is that, unless your program has a way to communicate information back to the programmer, it's almost impossible to create working programs. If you gave your little "Talk To Me!" program to a friend, how long would it take before he or she could guess that it only understood a double quote? Programming is like that. Without a console, you fire possiblities away at a dumb block never knowing how close any of your possiblities are. So now we are going to modify the program to give some help to the poor friend who is trying to figure out what your program does understand. Modify your program to add the line listed with `# new`: ```ruby #!/usr/bin/env ruby # Talk To Me -- tell me something and I'll tell you if I understand it require 'rubygems' require 'treetop' puts 'Loaded Treetop with no problems...' Treetop.load 'double_quote' puts 'Loaded double quote grammar with no problems...' parser = DoubleQuoteParser.new print "You say: "; what_you_said = gets what_you_said.strip! # remove the newline at the end if parser.parse(what_you_said) puts "I say yes! I understand!" else puts "I say no, I don't understand." puts parser.failure_reason # new end ``` Unfortunately, this code won't work for every situation. Run your program and enter `"You wanted a quote? I'll give you a quote!"` (include the double-quotes, obviously; that's the whole point!). What happens? You get a failure but no failure reason! The problem is our parser understood the double-quotes all right, but it knew you didn't stop talking, and there's stuff it doesn't understand at the end. So it is an error? No, not really. I mean, it did understand the double quote. It did everything you asked it to. It's just not sure if you asked it to do something else, so got that blank look in its face again... In the current (1.4.4) version of Treetop, you have to do some fancy footwork to diagnose the problem. Hopefully, in future versions, this kind of code will be moved inside the class. Modify your program as shown by the `# new`: ```ruby #!/usr/bin/env ruby # Talk To Me -- tell me something and I'll tell you if I understand it require 'rubygems' require 'treetop' puts 'Loaded Treetop with no problems...' Treetop.load 'double_quote' puts 'Loaded double quote grammar with no problems...' parser = DoubleQuoteParser.new print "You say: "; what_you_said = gets what_you_said.strip! # remove the newline at the end if parser.parse(what_you_said) puts "I say yes! I understand!" else puts "I say no, I don't understand." unless parser.terminal_failures.empty? # new puts parser.failure_reason else # new puts "I had a problem with line #{parser.failure_line} column #{parser.index+1}" # new puts "To be honest, I was not expecting you to say anything more." # new end end ``` Ugly, isn't it! Of course if you didn't *care* that the user babbled on and one, you can always add this line before you parse your input: ``` parser.consume_all_input = false ``` Okay. At this point, even though we have been taking baby steps all the way, we have come quite far. We were able to write a simple Treetop grammer, connect it into Ruby, parse something with it, and we have a good sequence of code we can use in all cases to debug our grammar. We can now start in earnest on our email list parsing program! [Previous](/2010/03/13/treetop-introductory-tutorial-part-03-of-10.html) \| [Next](/2010/03/15/treetop-introductory-tutorial-part-05-of-10.html)

Treetop Introductory Tutorial Part 3 of 10 – What Number am I Thinking Of?

2010-03-13T00:00:00+08:00

Now we are going to use our grammar in a Ruby program. Our program is a kind of "What Number am I Thinking Of" game. The user will type some input, and our program will let the user know whether or not it matches our grammar or not. Of course, it only matches our grammar if it is a double-quote! First we need to save our grammar so Treetop can compile it. (I told you this was not my ideal compiler-compiler...) Save your program as `double_quote.treetop`. Now create a new Ruby program and enter the following code: ```ruby #!/usr/bin/env ruby # Talk To Me -- tell me something and I'll tell you if I understand it require 'rubygems' require 'treetop' puts 'Loaded Treetop with no problems...' ``` Save this code as `talk_to_me.rb` and run it. If you get error messages, then you haven't installed properly. Hopefully the error messages will be instructive enough. You can always try `gem list --local` to see if all the required gems are installed. Now add the following code to the end of your program (yes, these *are* baby steps! Don't worry, we'll pick up speed soon enough): ```ruby #!/usr/bin/env ruby # Talk To Me -- tell me something and I'll tell you if I understand it require 'rubygems' require 'treetop' puts 'Loaded Treetop with no problems...' # new Treetop.load 'double_quote' # new puts 'Loaded double quote grammar with no problems...' # new ``` This is the code that actually compiles your grammar. If you get error messages now, then your problem is most likely you didn't enter the code from the previous tutorial properly. Or that your version of Treetop (`gem list --local | grep "treetop"` in unix-like systems) is too different from mine. I've tested this code with Treetop 1.4.4. Once you have things working, you can fill in the rest of our Ruby program: ```ruby #!/usr/bin/env ruby # Talk To Me -- tell me something and I'll tell you if I understand it require 'rubygems' require 'treetop' puts 'Loaded Treetop with no problems...' Treetop.load 'double_quote' puts 'Loaded double quote grammar with no problems...' # new parser = DoubleQuoteParser.new # new # new print "You say: "; what_you_said = gets # new what_you_said.strip! # remove the newline at the end # new # new if parser.parse(what_you_said) # new puts "I say yes! I understand!" # new else # new puts "I say no, I don't understand." # new end # new ``` Notice that the Treetop loader has created a Ruby class `DoubleQuoteParser` out of our grammar! This class has a method `parse` which takes input and returns `false` if it doesn't understand it. (What it returns if it *does* understand it, we'll find out later.) What we have done is get a line of text from the keyboard, strip it of the newline (carriage return) that comes with it, and then pass it to the parser using the `parse` method. Now run the program. At the prompt, enter some data like `Do you understand what I'm saying to you?`. The program will respond `I say no, I don't understand.` because, that's true, the only thing it understands is a double-quote. You now have a complete working integrated Treetop and Ruby program! How do you feel? Ready to try out something a little more complicated?... [Previous](/2010/03/12/treetop-introductory-tutorial-part-02-of-10.html) \| [Next](/2010/03/14/treetop-introductory-tutorial-part-04-of-10.html)

Treetop Introductory Tutorial Part 2 of 10 – As Long as You Speak Double-Quote

2010-03-12T00:00:00+08:00

Our development style is what I call the Baby-Step style: start with something simple, make sure it works, and keep adding to it. And, of course, retest every step. The advantage of that style is that you can be pretty sure that, if something goes wrong, the error is in the last thing you added. So we are going to start with something simple. We want to recognize just the very first character of our email list: the double-quotes. Ensure you have Ruby and Treetop installed properly, as per the installation instructions. Then fire up your editor and write your first Treetop grammar definition: ```ruby # my first Treetop Grammar # As long as you speak double-quote, I know what you mean. # grammar DoubleQuote rule double_quote '"' end end ``` Before we go too much further, let's take a look at some of the characteristics of our Treetop grammar language. ```ruby # my first Treetop Grammar ``` Comments start with `#`, just like Ruby. ```ruby grammar DoubleQuote ... end ``` Our grammar is identified by the keyword `grammar`, has a CamelCase name, and ends with the word `end`, like Ruby classes and modules. ```ruby rule double_quote ... end ``` Our grammar consists of rules. Each rule starts with the keyword `rule`, has a lower-case name, and ends with the word `end`, like Ruby methods. ```ruby rule double_quote '"' end ``` Our rule `double_quote` will match the single character `"`. That means, if it is given the character `"`, it is content. Anything else, and it gets this blank look on its face... [Previous](/2010/03/10/treetop-introductory-tutorial-part-01-of-10.html) \| [Next](/2010/03/13/treetop-introductory-tutorial-part-03-of-10.html)