Ben Greenman

Hmm, `check-out` seems like a bad way to fix because it's new & very special purpose syntax. What about, instead, `define-check/contract`? (Also since `check->` is nothing like `->` I think...

Good point about the boundaries. Well I think the best fix would be changing `contract-out` to handle macros. I'm not sure how to do that, so +1 to `check-out`.

Is the idea here that testing code can opt-in to saying "this test was skipped and I want you to know"? If so then yes I want this. Example: ```...

Why not just one `check-fail` function? `(check-fail check-predicate thunk)` - if `check-predicate` is a regular expression, match against the `fail-check` message - if `check-predicate` is a procedure, call it with...

I'd still prefer just having `(check-fail pred thunk)` because (1) I like that API, and wouldn't mind `(check-fail values thunk)` (2) I like the symmetry with `check-exn` (3) I think...

What about `(check-fail (or/c regexp? check-info? predicate?) thunk?)`, and then remove the `check-fail/info` case? (For this to work, `(check-info? (string-info ""))` should return `#true`. I'm not sure if there are...

> I don't think I understand what you mean about (check-info? (string-info "")). Wouldn't someone put the (string-info "") value in a check-info struct first by using make-check-info? I'm the...

Is the general rule that the degree can't be smaller than the number of points?

Hmm, ok. What about catching exceptions from `math` and re-raising them with a brief message like "unable to solve, may be too few distinct points in the dataset" ?

Oh, by re-raise I meant to keep the original exception message. In other words, throw the actual exception and add a commentary on top.