[RFC] This needs a language

[zyrolasting]

For background on why I got here, see #20 and #23. The code checked into this repo is modified directly by the user, and the code being modified includes kudgely checks to catch or work around compile-time errors that can be distracting. The purpose of this issue is to define a language that treats the code the user writes as data so that the code that actually contextualizes/runs the koans can be maintained separately.

Since this would be my first use of Racket's true powers I'm leaning on the community for feedback before I jump into writing breaking changes.

Definitions

• Koan: An initially failing whitebox test used to educate a student about a specific topic. Every Koan needs a Solution.
• Submission: Potentially (and initially) incorrect Racket code that may or may not pass Rule 2.
• Solution: A submission that passes Rule 2.
• Blank: 5 contiguous underscores (_____) marking a place where user is expected to write code inside of a submission.

Rules

1. Koans execute in the order they are encountered¹
2. Every koan checks the following, in order, to pass.
   1. Did the user fill out all blanks?
   2. Does the submission compile?
   3. Is the submission a solution?
3. Blanks may appear inside of a submission, but not a solution.

Proposed language

The language racket/koans will extend rackunit and provide a koan form that accepts a submission, which is treated as a Racket expression with blanks. When the koan is encountered, the submission will be evaluated against Rule 2.

#lang racket/koans

(koan
  (let ([p _____])
    (check-pred racketeer? p)
    (check-pred programmer? p)
    (check-pred struct? p)
    (check-pred procedure? set-programmer-salary!)
    (check-equal? (programmer-confusion-level p) 10)
    (check-equal? (racketeer-desire-for-racket-jobs p) 9001)))

If one writes this koan using #lang racket and rackunit, macro testing facilities like convert-compile-time-error and possibly other LBYL checks are necessary to give the user feedback tailored to their presumably lower level of experience. That kind of defensive code can be distracting to the target user since they do not pertain to the exercise presented to them. Compare the above to this revision.

Do you have any feedback on this proposal? Anything you would change?

---

¹ I acknowledge but will currently defer the problem of printing results in the same order in which koans are encountered even if tests run concurrently or in parallel.