The goal of the Bug Explaier is to provide a web service for novice programmers encountering bugs in their code when learning a new language. Novices don't know what's going wrong, and they often describe their problems in vague or invalid terms, e.g., "member doesn't work!" Hence their attempts to find answers via Google or FAQ searches often fail to find relevant answers.

To get around the ambiguity problem,

Tasks

Bug Report Interface

The input interface is where the end user specifies a problem. The interface needs to be easy to use and not require any expert knowledge from the user.

Using Webactions, create a simple readable form that lets a user specify the following information:

SummaryA short text summary of bug. Not useful for the computer.
InputSample code that produces the bug
Expectedthe result(s) the user expected to see
Actualthe result(s) the user actually saw
Operating Systemthe operating system the user is on
Languagethe language, including implementation version the user has

Here are two example bug reports. I'm leaving out the summaries and platform information, since they're not important here:

Example Bug Report #1
Input(LET ((L '(A B C))) (DELETE 'A L) L)
Expected(B C)
Actual(A B C)
Example Bug Report #2
Input(DELETE '(B) '((A) (B) (C))
Expected((A) (C))
Actual((A) (B) (C))

Submitting the form should cause the server to

In good RESTful form, the URL for the new page should be bookmarkable. This bug page would also contain any automated explanations, but for now of course none will be found.

Implement and test with at least the two examples above.

Submit: the Webactions functions you defined to implement to create and store the bug reports. Do not submit the CLP pages, but do submit functions called by CLP tags to display the bug reports, if any were defined.

Bug Analyzer

The analyzer needs to look at the bug report and find possible explanations for the bug. The clues to common bugs can be subtle. For example, novices often report that deleting doesn't work, and their example involves deleting the first element of a list.

The standard way to look for such clues is pattern matching. The matcher used in the Lisp Critic is a good fit, since it's been tested on matching many Lisp code constructs. One pattern that recognizes the "deleting first element" situation is:

Input(?CONTAINS (DELETE ?*))
Expected((?* X))
Actual((? Y) (?* X))
Explanation Although DELETE can return a list without the first element, the structure of Lisp lists make it impossible to destructively remove the first element of a list. For more, see http://www.cs.cmu.edu/Groups/AI/html/faqs/lang/lisp/part3/faq-doc-4.html

Note the use of variables across several fields.

Bug Report #1 is an example of a report that this pattern should match.

Bug Report #2 is an example of a report of a bug due to a different misunderstanding of DELETE. What's the explanation, and what's a pattern to recognize relevant reports?

If you're not comfortable with packages yet, do all of the code in CS325-USER. Otherwise, define a BUG-FINDER package for the code and a BUG-FINDER-TESTS package for the test cases.

DEFBUG is similar to DEFINE-LISP-PATTERN used in defining Lisp Critic rules in lisp-rules.lisp. You need some format that identifies which fields are being matched against, i.e., input versus expected versus actual.

GET-EXPLANATIONS should returns rules, not just the text strings. There's no additional work to do this, and it leaves your options open for extensions, such as editing rules in the next task.

Submit: the Webactions functions you defined to implement to create and store the bug reports. Do not submit the CLP pages, but do submit functions called by CLP tags to display the bug reports, if any were defined.

Bug Rule Editor

Modify your your bug explanation page to allow people to edit an existing explanation rule, or to add a new one. The exact interface is up to you, but either option should open the same rule editing form, to let people change the pattern and explanation text, but not the name.

Submit: the Webactions functions you defined to implement to back-end editing and updating. Do not submit the CLP pages, but do submit functions called by CLP tags to display the bug reports, if any were defined.

Faculty: Chris Riesbeck
Time: Monday, Wednesday, Friday: 1pm - 2pm
Location:Annenberg G15

Contents

Important Links