HW3

CS164 HW3 - Final Project Proposal

Part I

1. We want to embed a baby version of jQuery into the 164 language. With its control structures and iterators, the 164 language is well-suited for DOM layout; however, we have no clean way of modifying the DOM. One solutions for this would be to have programmers manually traverse the DOM with JavaScript-like functions. These functions would be able to traverse the DOM, select DOM nodes, or add events. While this sounds like a feasible solution, because modifying the DOM is a task that will be done frequently, we want to design a cleaner abstraction for this functionality. As an example, what if we wanted to change the color of all the links on a page that contain a certain word? Without this baby version of jQuery, we would have to write a function that first grabs all correct links in the DOM. Then we would write a for loop that iterates over all of these links and adds event listeners to all of these links such that their color changes appropriately. It would be much cleaner to abstract away the iteration and adding of event listeners. What jQuery does for JavaScript is facilitate the ease with which the DOM is modified, and we hope to add this same feature to the 164-language. This way, we would have a universal method of changing DOM elements which is readily understandable. We do not rely on a programmer-designed family of functions; we rely on the programming-language's implementation.

2. With the example described previously, although it is not difficult to write code that grabs links, iterates over these links, and adds the appropriate event listeners, it leaves significant room for error. As a result of breaking up the task into many different sub-parts, each step is now prone to error. Furthermore, the increase in code size of the original method also contributes to the difficulty of writing clean code for these kind of DOM-manipulation tasks. It seems that without the correct plumbing, debugging code would be difficult because programmers would have to do deal with all the details and would not be able to focus on the main idea of the program. By creating a jQuery-like library for the 164-language, we abstract away complexity and give programmers the tools to write readable and more error-free code.

3. This problem is worth solving because it makes it easier for us to modify the DOM and helps with adding scripting features to BAH webpages. We would no longer have to create functions for grabbing all a certain kind of node, iterators for nodes, etc. since we are making it part of the language itself. Because of the confined nature of this problem, we are left with few other options than extending the functionality of the 164-language. In extending project 3, we hope to allow the 164-language to do more than just layout the BAH.

Part II

$("exit").click(lambda (event) {
alert("Thanks for visiting!")
}

This code will grab all the tags whose id is 'exit', and then add an event handler to those links such that when the link is clicked, the webpage will show a pop-up window with the specified text passed into alert().

Implementation-wise, we can have $ be a reserved keyword which stands for a function that operates on the DOM. Inside this function, it will do a traversal of the DOM and return an iterator over the dictionary of tags whose id is "exit". Each of these references to an "exit" tag will call a click method which will bind an click event handler to that tag using the lambda argument that was passed in and modify the DOM accordingly.

def $(string) {
tags = traverse DOM and return tags who have string as id
def i = 0
lambda () {
def cur = i
i = i+1
return tags[cur]
}
}

def click(func) {
get a pointer to 'self'
change the DOM by making a new event handler
}

Part III

1. The domain: a few small programs that we hope to be able to write:
1. Events: Launch code when website is ready by a "ready event", checks the document and waits until it's ready to run the script
2. Special Effects: cause a link to fade in or fade out when it is clicked.
3. Selectors: select an object in order to bind event handlers to it, such as selecting a link to attach a mouse-over event listener to it.
2. Outline of programming model:
1. Objects: Selectors, Traversing, Events, Effects
2. Operations:
1. Selectors
1. id - matches a single element with given id attribute
2. element - matches all elements with given tag name
3. selector1, selector2, selectorN - matches combined results of all specified selectors
   
4. first - matches first selected element
5. last -matches last selected element
6. eq(index) - matches a single element by its index
   
7. contains(text) - matches elements which contain the given text
8. empty - matches all elements that have no children
2. Traversing
1. filter(fn) - keeps only elements from the set of matched elements where the specified function returns a non-false value
2. slice(start,end) - selects a subset of the matched elements.
3. Events
1. ready - binds a function to be executed when DOM is ready
   
2. bind - binds a handler to one event (like click)
3. one - binds a handler to one or more events to be executed once for each matched element
4. trigger - trigger an event on every matched element
5. triggerHandler - triggers all bound event handlers on an element (for a specific event type) WITHOUT executing the browser's default actions
6. unbind - opposite of bind, it removes bound events from each of matched elements
   
7. hover - simulates hovering (moving mouse on and off)
   
8. click - triggers the click event of each matched element
9. click(fn) - binds a function to the click event of each matched element
10. dblclick - triggers the dblclick event of each matched element
11. dblclick(fn) - binds a function to the dblclick event of each matched element
12. ...etc mouse and keyboard-related binders
4. Effects
1. show - displays matched elements if they are hidden
2. hide - hides elements if they are shown
   
3. fadeIn - fade an object in with variable speed
4. fadeOut - fade an object out with variable speed
3. Abstraction mechanism - our 164Query will be built on top of our 164 language meaning all the abstraction mechanisms afforded to us in 164 is at our disposal for 164Query.

Part IV

Alternative implementation 1:

frontend: Translate the input scripts into 164 code with a library. This requires the user to include the 164Query library everytime the user wishes to write 164Query code. This is probably the more preferable option when compared with modifying the 164 code interpreter as there is no installation required. Also, it allows for quick future updates by changing the 164Query library.

core language: 164 code is the core language. The desugaring stage depends on the frontend implementation. In this case, the desugaring happens in the 164Query library.

internal representation: Program can be represented as 164 bytecode.

debugging: Debugging will be done through testcases with the small programs described in part 3. Unfortunately, because most of the test are user interface related, many tests will have to be run manually.

Alternative implementation 2:

frontend: modify the 164 interpreter to also handle 164Query code. This allows the user to bypass importing libraries, but all users will have to update their 164 interpreters. In a real browser, this is equivalent to updating all users' browser installations which may be a larger hassle than including libraries.

core language: 164 code is the core language. The desugaring stage depends on the frontend implementation. In this case, the desugaring happens in the 164 interpreter.

internal representation: Program can be represented as 164 bytecode.

debugging: Debugging will be done through testcases with the small programs described in part 3. Unfortunately, because most of the test are user interface related, many tests will have to be run manually. We will have to make sample webpages and interact with them to see if they indeed have the desired functionality.