Difference between revisions of "Computer Science/164/HW3"

From lensowiki
Jump to: navigation, search
(Part 1: Choose the problem that your language will solve: intro)
(Filled out part 4)
Line 23: Line 23:
 
==Part 4: Decide on the implementation==
 
==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.
 
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.  
+
* 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 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?
 
* internal representation. What are the alternative ways of representing the program for the interpreter or compiler?
* 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?  
+
 
 +
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?
 
* 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.

Revision as of 07:25, 21 November 2009

Part 1: Choose the problem that your language will solve

  1. What problem are you addressing? First, describe the context and the general nature of the problem. Then describe a instance of the problem: depending on your problem, you may want to
    1. show a fragment of ugly code that you want to improve with your language, or
    2. describe a code development scenario that your language will make less tedious and more automatic.
    3. missing features that you want to add to a language; say what these features would allow that is not possible (or too hard to do) today.
  2. Argue why this problem is hard. For example, the code example you show may be obviously ugly, but do programmers indeed find it difficult to write this code, or to debug it?
  3. Argue why this problem is worth solving. Aren't there simpler solutions than designing a language? For exaple, it may be possible to work around the problem, sidestepping it by switching to a different, existing language. Of course, switching languages is not always possible, which motivates embedded languages and tools for dealding with existing languages.

Navigation bars are a standard feature of many web pages. In recent years, a somewhat standard paradigm has developed of using unordered lists, which are then styled with CSS to give them a more traditional appearance.

Accomplishing this in a good-looking and cross-browser-compatible manner is not trivial and requires a fair amount of CSS fiddling. Furthermore, the HTML code which must be written to set up the navigational elements contains a fair amount of extraneous markup which detracts from getting a clear picture of the navigational elements and their actions.

Furthermore, navigational menus can often contain submenus for a structured hierarchy. This requires additional javascript coding to work properly and further detracts the web page designer from concentrating on accomplishing his task; namely, working on the actual design of the menu

Part 2: Study a language that solves a similar problem and describe it in this homework

  1. One simple code example. Your comments must sufficiently explain the meaning of the code.
  2. Describe the implementation. (Two paragraphs and pseudocode of the implementation.)

Part 3: What features specifically will your language support

  1. The domain. Give a list of a few small programs that you hope to be able to write in your language. These will guide your language design.
  2. 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.