people don't know what the behavior of a given program should be. We often say, "what does Racket say?" and this works 99% of the time, but we're really talking about a subset of Racket and there are subtle issues here.
we assume expressions are "well-formed" but never fully spell out what this means.
students don't seem to internalize they are building a PL in which they can write and run programs.
To improve this, I propose, we ship #lang language for each of the languages plus all of the assignment languages. The implementation will be by expansion to Racket, so you'll get usual IDE tools, plus static checking for conformance to the language. This makes it definitive to say "run Check Syntax" and if it's OK, your compiler better be able to compile it. It also gives students a reference implementation for the interpreter without leaking any details since the implementation via expansion doesn't shed light on how to write the interpreter/compiler. Being able to run programs in DrRacket may help reinforce the ideas that you can write programs in these languages.
A few perennial issues in the class:
To improve this, I propose, we ship
#langlanguage for each of the languages plus all of the assignment languages. The implementation will be by expansion to Racket, so you'll get usual IDE tools, plus static checking for conformance to the language. This makes it definitive to say "run Check Syntax" and if it's OK, your compiler better be able to compile it. It also gives students a reference implementation for the interpreter without leaking any details since the implementation via expansion doesn't shed light on how to write the interpreter/compiler. Being able to run programs in DrRacket may help reinforce the ideas that you can write programs in these languages.