Changes
Updated implementation section
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 would clearly be counterproductive. We decided to use the JS/CC parser generator, since it provides a simple online interface, supports grammars similar to those used in CS164, and outputs a stand-alone JavaScript parser file that can be included in our distribution as a library. This parser process the input to the program and outputs JavaScript objects for the interpreter.
* 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 As described above, the input will take to the form of language is a hierarchical list of menu items with associated attributes, and the attribute lists. The program will translate translates the input into the corresponding CSS , HTML, and JavaScript code along with all the plumbing needed to create and 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 is fairly straightforward; the interpreter will go goes 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 Our distribution is packaged with an HTML page with a text box. You can type an input program into the text box, and the output navigation bar will be is displayed abovebelow. If there is an error, the error message will be is displayed instead of the navigation bar.
