I will not be asking for specific test cases, like curried map, etc.
Instead, the test cases are based on the forms of the languages, as
always. The language has 18 forms, so you should always be testing
each one. Generally, you'll want to have a variety of tests for each
form though---one for every way it can be wrong (i.e. with + there can
be a not-number on the left and on the right) and then how it can be
right. Finally, with type systems there are a few special
circumstances, like showing that you allow runtime errors and support
polymorphism,
This email does not say anything that the assignment page and section
4.3 of the syllabus doesn't say.
On Mon, Dec 2, 2013 at 11:21 PM, Stephen Rollins
<
enzed....@gmail.com> wrote:
> Jay,
>
> I feel very comfortable with the performance of my type inferrer. I've
> written test cases for everything from numbers to recursive functions,
> including a Fibonacci function and the curried map we were specifically
> advised to include in the writeup. My test case racket file is over 300
> lines long. I feel like I've been thorough. However, after having been in
> your class for nearly a semester, I've learned to be paranoid about the
> thoroughness of my test cases. Are there any exceptional cases that would be
> worth addressing, such as the curried map? Even just some hints would be
> very helpful.
>
> Thanks!
> ~Stephen
--
Jay McCarthy <
j...@cs.byu.edu>
Assistant Professor / Brigham Young University
http://faculty.cs.byu.edu/~jay
"The glory of God is Intelligence" - D&C 93