Problem Set 02—Notes and link to solution

Your final autograder grade will be available in Gradescope at the end of the lab grading process, and we will post the combined autograder and TA grade on Canvas. In the meantime your email autograde gives you a very good indication of your final autograde. The autograde score only changes if we fix a problem in the autograder.

Here is the sample solution for problem set 2! You should also carefully consider the following comments on the problem set. These will help you do well on the next problem set and the midterm.

Please read over the style rules! They are very important, there are not a lot of them, and they are not hard to follow once you are aware of them.

Debugging Problems

Debugging problems are all about working slowly and systematically. Start by reading carefully and comparing each part of the design to every other part looking for inconsistencies.

When we give you a debugging problem your goal should be to fix any problems you identify with minimal editing. This is a best practice for two reasons:

One is that the more you change the more likely you are to accidentally introduce a new bug.
A second reason is that in most team projects at least one person will end up having to look at any code you change to approve your change back into the system. The smaller the change you make, the easier it is for that person to approve. For one thing there is just to understand, and for another the less you change the more likely it is that your changes won't conflict with changes someone else may have made.

HtDF and HtDD

It is very important to use templates properly in function design. In particular, if you take a template from a user defined type (a type for which you did an HtDD), and if the template includes a cond, then, as you finish the function, you must ensure that:

The cond appears in the final function, and
you do not add or remove cond question/answer (QA) pairs, and
you do not change the order of the QA pairs, and
you do not in any way edit any of the cond questions.

Remember that the template rules are based on type theory, and they produce templates that guarantee certain properties - these include type safety, and starting in module 4 the idea that we can "trust the natural recursion". Having guarantees about those properties is so important that it more than outweighs any fun we might have by editing cond templates.

Do note that these rules only apply to cond expressions that are formed by one-of types. In cond expressions that you introduce to the code after templating are you are free to edit questions, add or remove QA pairs etc.

Also Remember that intervals should not be in the type comment anymore but should be in the CONSTRAINT instead.

Order is important with templates and the whole design should be consistent. In problem 5 your dd-template-rules and cond QA pairs should have been in the same order as the type comment.

A function purpose must be max 1 line (80 characters long). Accounting for the ;; and the space at the beginning this means you get 77 characters. One good way to save space is to avoid restating information already contained in the signature, don't waste precious real estate!

Remember to run your tests with your stub before commenting the stub out and make sure that each element of your design is consistent. The stub's return type should match that of the signature for example. Every test should match the signature as well.

The solution for this problem set is:

pset-02-solution.rkt