Trying to create my perfect Racket for AP CS Principles - will someone take pity?

Questions & Answers
, ,
1

So, to review, I'm teaching AP CSP. About 40% of the course is supposed to cover programming and algorithms, and they publish their own pseudocode language, since the language the course is taught in is left to the instructor. As you might expect, the pseudocode is very imperative, mutative, and sort of like dumbed-down Java or C.

I've actually written (following Beautiful Racket) a #lang that handles this language, although the indentation and error messages could be much better. GitHub - toddobryan/apcsp-pseudocode: An implementation of APCSP pseudocode as a DSL in DrRacket

Here's the reference sheet on the language: https://apcentral.collegeboard.org/media/pdf/ap-computer-science-principles-exam-reference-sheet.pdf (which you may be able to see once CloudFlare is fixed).

I would really like to create my own customized version of teaching languages. Like most of us, I'm very opinionated about what I think works best with my students and how I need to teach content given the requirements of the AP course.

Here's the thing. I've spent about 10 hours over the last couple of days looking at both the htdp and deinprogramm repositories as models, and I'm just lost. So much of how things work is based on convention and while the docs are excellent, they seem to assume you have a general understanding of how everything works and just need to remind yourself about particular concepts. For example, I only discovered last night that signature means two things--one in relation to units and another in the teaching languages.

Would someone be willing to take me by the hand and walk me through this endeavor? My problems are myriad--I can only work on this for an hour or two at a time, except on weekends; I'm by no means a proficient Racketeer; and, I occasionally have to abandon what I'm doing for several days to deal with things like creating tests and grading assignments.

We could either do this on here as a series of messages or as email chain that I'd be happy to post a summary of back here.

What I'd eventually like to have is a progression of languages that I could do

#lang apcsp/pseudocode
#lang apcsp/bsl
#lang apcsp/isl

but in the spirit of iterative development, I'd just like to focus on #lang apcsp which would be my customized version of BSL.

2

HtDP and DeinProgram grew, uh, organically.

Let me recommend the following.

  1. Design your teaching language levels. My guess is that this is probably an exercise in syntax not systematic design (a la HtDP and DeinProgram). If I am correct, write down purpose statements (why this language level, what does it achieve), the grammar, sample programs, sample outcomes, sample error messages. (Oh yes these are the first three steps of the design recipe.)

  2. Next, outline the modifications to the parser you have. (Call it a template if you want.)

  3. Implement the parser, target the existing backend.

  4. Make sure to equip the implementation with an integration test suite based on the sample programs. (OK, this is step 6.)

Now, once you have done this for two languages, apply the abstraction design recipe from part III of HtDP/2e:

— what is common
— what is different
— how can you abstract functionality over the differences
— where do you need to abstract syntactically over the differences.

That’s actually behind the arrangements of the existing teaching languages, but the evolution path was somewhat less direct. You might end up with a better implementation than ours.

;; - - -

The connection to the IDE (DrRacket) is a totally different story. While many people think of this relationship as part of the PL, I’d say it’s on the periphery and you might be better off embedding your languages into VSCode, by modifying an editing package for Python and combining it with the Racket package so that students can run it “natively” in this IDE. (You might even be able to connect it to AI later and teach students its responsible use.)

— Matthias

3

Oh, I'm totally into s-exp for the grammar. I just want to make some tweaks.

  • earlier introduction of local to encourage students to embrace DRY (don't repeat yourself) in functions.
  • including readline and display, since they play such a big part in the pseudocode
  • adding some checks as a post-parsing step (make sure every function has a signature and test cases--I have some stubborn 14-year-olds)
  • changing '() back to empty and #t and #f back to true and false (I'll never get to quotes or symbols, so the foreshadowing is lost on my students, and true and false are the values in both the APCSP Pseudocode and the Java that the students have to take next year.)
  • I really like the way that Dein Programm doesn't build in cons, but has students define it. That would be very cool. I want to include more of the signature work from Dein Programm, but obviously don't want the error messages in German. :slight_smile:

And then I'm going to need to add some utilities so that they can write their "Create Performance Task". The requirements are that the program include input while the program is running, a list that supports algorithmic abstraction (in other words, a list that couldn't be replaced by a small fixed number of variables), and a student-written function that includes sequencing, selection, and iteration (or recursion).

universe works for most of these, but I'm thinking it would be cool to add basic GUI things like inputs and buttons so that students can write programs that are more text-based but still make it clear to the graders that they're getting input from the user while the program is running. (Many of these points on the exam are based on a video that the student uploads showing the program running.)

(I've also thought of some esoteric functions that could display the signatures of functions and the types of values in the REPL, if that's even possible.)

Basically, I need to understand how this all fits together so that I can tweak it.

4

If S-expressions are okay, consider the syntax-spec package. It enables someone like you to specify the grammar and binding structure of a language easily, write a "compiler" that's essentially a standard macro, and doing this for several "levels" is also easier than doing it all by hand.

HtDP enables I/O programming in a systematic way via 2htdp/batch-io. It also comes with an "abstraction" package that includes (restricted versions of) Racket's for loops.

Mike has a teach pack for hierarchical GUIs that also matches the basic design principles of HtDP, but I suspect the docs are in German.

Otherwise your requirements are a bit nebulous.