Now that you've had a chance to push internal DSLs to the limit, let's try external DSLs!

Implement an external version of Piconot. You can choose to implement any version of Piconot you want (e.g., your original version from the previous assignment, another team's version, a new version, etc.). Just make sure it's a sufficiently large language that you can get good practice with parser combinators and with the language architecture and implementation process we discussed in class.

• Sign up for teams. Team 1 will have three people; all other teams will have two people
• Describe your design in design.txt
• Formally specify the syntax you plan to implement in grammar-ideal.txt.
• Implement the syntax
  • Add files, as needed, to implement your syntax. Use the language architecture we discussed in class (more details below), and use parser combinators to implement your parser.
  • Include at least two example programs
    • Empty.bot
    • RightHand.bot
  • Provide instructions for how to run piconot on a file in build.txt
  • Describe your implementation process in evaluation.txt
  • Formally specify your final syntax in grammar-final.txt
• Critique another team's design and implementation

Describe the design of the language you'll implement, in the file design.txt (see that file for instructions on what to write). If you're implementing the exact same language you designed for the previous assignment, you can reuse the contents of your file from that assignment (although it's probably a good idea to revisit what you wrote to see if there's anything you would change).

Formally specify the syntax for your design, using EBNF. Place your definition in the file grammar-ideal.txt.

Implement the language. Use parser combinators and case classes to implement the parser. Here's a good article for learning a bit more about parser combinators; there are many other ones on the web. Chapter 19 of Scala for the Impatient also covers parser combinators. For more advanced languages, the Language Implementation Patterns book may also be useful.

A note about building the given code: use sbt! If you don't, you'll have to jump through many difficult hoops to get your code to compile against the parser combinator library.

When implementing your language, use the architecture from class:

main 
 |-- scala
      |-- package name
           |-- parser
           |-- ir
           |-- semantics

test 
 |-- scala
      |-- package name
           |-- parser
           |-- ir
           |-- semantics

Your implementation should handle errors gracefully. Errors might include syntax errors, programs that reference undefined rules, etc. The team of three should pay extra attention to error handling: the implementation should be extremely robust, and the error messages should be clear and actionable.

Giving good error messages for parsers is notoriously difficult. The failure, positioned, phrase, and log combinators (defined in the scala.util.parsing.combinators.Parsers trait) may be helpful.

As you work, comment on your experience in the file evaluation.txt. In particular, if you change your ideal syntax, you should describe what changed and why you made the change (e.g., your original idea was too hard to implement or it didn't match well with the library calls) You should also answer the following questions: On a scale of 1–10 (where 10 is "a lot"), how much did you have to change your syntax?

After you've finished implementing, formally specify the syntax of your internal DSL in grammar-actual.txt

In the build.txt file provide instructions for how to build your software and how to run it on piconot file. A somewhat easy way to do is the following:

1. build a .jar file by running sbt package
2. run the software on a file by executing the command path-to-jar-file name- of-class-with-main-function bot-file

Note that for your users to run your language this way, you'll have to design your solution so that the main function takes and processes an argument that contains the filename of the picobot file to run.

Comment on another team's design and implementation. You should look through their grammars, pay special attention to their evaluation.txt file, their parser, and their intermediate representation. You might consider the following questions:

• What good insights about implementation did the team in design.txt? Did you have any experiences that were similar to the team?
• How nice is their implementation? Is it understandable? Clean? Modular? Extensible? What do you like about their code? Are there any particularly elegant ways they overcame implementation challenges?
• Download their code and run their example programs. How easy was it to run? Did the instructions work?
• Modify the example programs to introduce errors. How robust is their implementation? What do you like about their error-handling? What can be improved?
• Are there any implementation tricks that you can suggest to the team? Anything you see that might make the implementation easier or more like the original design?