1,277
edits
Changes
m
→Part 4: Decide on the implementation: minor formatting
# Give an outline of the programming model of your language. What are the "objects" in your language? What operations on these objects will you allow? How will you combine small programs into bigger ones, hiding the implementation details of the smaller ones (what abstraction mechanism will you support, if any?).
==Part 4: Decide on the implementation==
Choose two alternative implementations, and compare them along these aspects. For each aspect, write a paragraph. Your two approaches may be identical in some aspects.
* frontend: How will you translate the input (source) program into the program's internal presentation (often, this is an AST)? You know that this can be done with a parser or with an embedded DSL, as in rake or protovis. Some languages may not need an internal representation.
:The decision to go with a parsed input rather than an embedded DSL was not one we made lightly. The primary advantage of the embedded DSL is simplicity; it doesn't require us to go through the trouble of writing a grammar for the input. However, that simplicity comes at the price of flexibility; the parsed input can be specified in any format we choose, whereas the input of an embedded DSL must fit into the syntax of the parent language. Considering that the main goal of this language is to provide a clean and simple syntax, restricting ourselves to the syntax of the parent language is clearly counterproductive.
* the core language: Are some features built as sugar on top of a simpler-to-implement language? If yes, what is that core language, and how will you desugar those features?
:The purpose of this language is to provide a convenient and concise way for users to create CSS navigation bars. As such, it must be implemented entirely as sugar on top of CSS and HTML. The input will take the form of a list with associated attributes, and the program will translate the input into the corresponding CSS code along with all the plumbing needed to arrange the bar properly.
* internal representation. What are the alternative ways of representing the program for the interpreter or compiler?
:We considered using both an AST and objects for the interpreter's internal representation of the input. In the end, we decided that objects are better suited to the data. Our input is not going to come in the form of a deeply-nested hierarchy, so the tree structure is unnecessary; the input is a collection of data points, each of which has a set of associated attributes. This lends itself very well to object representation.
* interpreter/compiler: how will you interpret or compile the language? Is there a prepossessing step, eg translation from AST to bytecode? If you want to generate code, what is the target language? Why did you choose that language?
:The interpretation will be fairly straightforward; the interpreter will go through the object representation of the input, generating the appropriate CSS and HTML as it goes.
* debugging: How will you debug the implementation of the language?
:We will provide an HTML page with a text box. You can type an input program into the text box, and the output navigation bar will be displayed above. If there is an error, the error message will be displayed instead of the navigation bar.
