CPSC 110: Week 2.

Introduction

Somehow through the whirlwind couple months it’s been, I’ve neglected to touch CPSC 110 at all. I’ve been mostly focused with fixing Matter up and adding all the quality-of-life features I’d want in order to designate it a main information source. But that’s besides the point: I’ve decided I want to finish as much of CPSC 110 as I can before spring break, or at least during it. At the latest, I’d like to sort everything out by summer, and see if I can finagle myself a spot in the summer session (fingers crossed).

I’ve made myself a proper CPSC 110 repo and even bothered to figure out how to convert GUI DrRacket files into ones Vim can handle, so hopefully I’ll be more motivated to solve the problem sets properly. Before I dove into this week’s material, I had to rewatch most of week 1 to relearn the function recipes again, but I’ve made more notes this time round (and referred to the ones on my blog - I told y’all it would come in handy). Going into the data definitions section wasn’t actually much of a challenge once I went through and watched the videos again.

The design recipes, as Kiczales mentions, are becoming ingrained into my memory now. It’s very intuitive how they all slot together, and though sometimes it feels extremely repetitive to keep making examples and stubs, I can see why it helps when debugging more complex parts on top of the recipe. This week, I’d gotten ahead of myself and briefly tried to do things with structs, but that really wasn’t the point of this week yet (I’m told it’s part of week 3.). It’s rather surprising to see how each recipe and definition builds on the others, though sometimes I’m left wondering if all these conventions are really all that useful.

If you’re uninterested in wrangling with data definition recipes, this might not be very fascinating, but I think keeping this as a record of what I’ve been doing with Racket will be helpful for later revision.

Notes

Week 2 deals with designing data, and how to create data definitions that work with the function definition recipe.

• cond expressions are if statements with multiple branches
  • use square brackets to test the question => [(Q) A]
  • if only else body => the then block is evaluated instead
  • evaluation steps: evaluate the first expression’s Q block
    • if it’s false, it gets removed from evaluation
    • keep evaluating and removing until you meet a true block, then return the answer
• data definitions => information represented in problem domain, and restricts what is allowed
  • type signature comment, what it is
  • interpretation of what the data is supposed to represent
  • examples of the data => ‘one of’ comments
• atomic non-distinct => can’t break into meaningfully smaller pieces
  • now have a data driven template => fn-for-x, then have a body from the table
    • never actually use it, so keep it commented
  • when atomic non-distinct => (... x), if distinct, then just (...)
    • write a comment detailing the data driven template body type
• following the HtDF recipe is easier to understand + already learned metadesign
  • function recipe is independent to data definitions, so don’t need to learn a new one
• interval data definition => numbers within a certain range
  • when giving type comment, use range => use proper interval notation
• enumeration => two or more distinct values
  • for rules used, add ‘one of’, and the number of cases / subclasses
  • use a cond to represent each case in body
  • don’t need to use examples => add comment to explain redundancy
• itemization => two or more categories, but one or more of which isn’t distinct
  • for example, a preflight, postflight, and inflight altitude
  • type guard required for each case if mixed data types
  • last condition will be an else, because we know that by process of elimination it must be that value
    • if all remaining data types are same data type, no guard needed
• amount of tests will differ based on the data
  • with an interval => closed boundaries and midpoints (~3)
• when using HtDF with own data definitions => can reuse template
  • function recipe and prompt gives information about tests, etc
  • design behaviour of function while designing tests

Conclusion

I actually managed to work my way through the lab and problem set while trying to learn the material at the same time (not very fun, do not recommend because you’ll be very confused at the conventions that the example solution assumes), so I developed my own way of doing things the first time. It was interesting to contrast how I took shortcuts the first way round: not putting down enough check-expects or ignoring the stub parts of recipes. Again, sometimes it really does feel like a chore to have to repeat the steps over and over again, but maybe that’s part of how you learn things¹.

Spending a month and a bit away from Racket, then suddenly returning was a bit disorienting at first - I had to familiarize myself with the syntax again, and the various builtins. The way I write Racket has been tinted a lot by the procedural way of doing things that’s been prescribed by the course, so it was an experience to go from writing essentially whatever fit without much proper testing (Matter), to having to make testing an integral part of the programs.

I’d forgotten how much fun listening to 2x lectures was - I suppose it’s just part of the natural recursion². I’ve been trying to make CPSC a priority in my free time (of which I have very little - oh, the woes of senior year), so hopefully I’ll be back next week with either more notes or a proper post. I have ideas for both, but we’ll see.