lex and yacc Continued

Follow the link for an excellent tutorial ref1 on lex and yacc with some sample code. I will refer to this as ref1 in comments below.

Another lex and yacc tutorial with sample code . This post is based substantially on this second tutorial and the examples in the sample code.

A number of examples are provided. For each example, a script, say example1.compile, is present after you gunzip and tar x-tract.
chmod 755 the *.compile files to make them executable.
cat or edit each example, example4.l is the lex file and example4.y is the yacc file.

I have never been a fan of exercise, either in the gym or on paper. Give me a real problem or a real event to contest any day. But exercise is sometimes a necessary preparation for building strength and agility. Recalling Harvey Wagner and the “Mind Expanding Exercises” in his textbook Principles of Operations Research let us call these:

Stretching Exercises

Note: Do all of the examples. Stretching exercises extend but do not replace the tutorial.

0. Download the sample code. Gunzip and expand it. Mark the executable *.compile scripts and execute the example1.compile script. Resolve any knowledge gaps.

1. Build example2 and test it. Now enhance it so that it prints “MIXED” if the input is alpha-numeric, “NUMIXED” if the input is alpha-numeric with leading digit, “NUMBER” if all digits, “TEXT” if all letters and if the input is EXIT, Return 0.
Did you get a message like ex2.l:9: warning, rule cannot be matched on the lex execution? Why might it occur? How can you fix it if it does?

2. Build example4 and test it. What usability problems would you fix? Suggest 3 usability or reliability improvements. Create a version that implements the improvements.

3. Now create a version of the example4.compile script that includes the yacc “-rall” switch. Execute it and examine the y.output file. Do you think that the “-rall” switch aids understanding? Debugging? Checking? Testing? Designing?

4. Review the tutorial at ref1. Repeat exercise 3.

5. Create a word counting program using lex (flex). Nobody expects the Inquistion. Compile and test it.

6. Run example4.compile. Examine y.tab.h.
rm y.output, lex.yy.c, y.tab.h and y.tab.c. Run example1.compile again. Which files are created? Make note of the size(s).
mv or cp lex.yy.c to preserve it.
Run example4.compile again. Which files are different?
diff the preserved version of lex.yy.c and the just created one. Are they more or less different than you expected?

7. Run example4. Use the following inputs (from the tutorial)
heat on
heat off
target temperature 22

What were the responses?

Try “heat foo” – what is the result?
Try “target temp 99” – what is the result?

Rate the generated program on a robustness scale of 0-3.
Rate the generated program on a user friendliness scale of 0-3.
Explain how this experience will influence your future program designs.
Explain how this experience will influence your future program testing.

8. Between earlier examples and example4, can you explain what changed that allowed the removal of -ll (libfl if flex how can that be?) from the link specification?
What did yacc provide that allowed this to happen?
In your intermediate files, can you find the line number?

9. diff example4.l and example5.l
diff examle4.y and example5.y
Demonstrate your understanding of yytext and yylval by explaining the origin of their content and when it is created.
Further explain yytext and yylval as “c” variables in the generated program.

10. diff example4.y and example6.y
Explain your understanding of the origin of variable $2
Explain your understanding of the origin of variable $3
Explain why the specifics of $1 $2 $3 etc. are not that important.
Explain why the shared usage of $1 $2 $3 is important to the shared, generated code.

10. Explain the lexyacc efficency trade-off on the choices made for HEAT ON and HEAT OFF.

11. Run example5.compile and provide inputs from 7 above.
Describe your user experience:
a. Program correct?
b. Program robustness, security, reliability, resistance to failure.
c. Program presentation/beauty/ease-of-use/understandability
d. Program efficiency.

12. As a user, rank the factors a-d above. Check with your associates. Ask visitors to your home to evaluate. Ask strangers to evalute the list.

13. Create a version of example5 that is more user friendly. Consider recovery from errors, ease of use, lack of training, carelessness.

Now that you are warmed up, Wikipedia [Bison] and ref1 present calculator programmes. Build each, test and evaluate, share a blog post that compares and contrasts the available examples.

Leave a Reply