CPSC 110: Weeks 3 and 4.

Introduction

Spring break has just begun, and I’ve decided to devote some more significant time to CPSC 110. It helps that I’m sort of floating between projects and want a bit of bland coursework to churn through at the moment, so I’ve been spending my leisure time listening to Kiczales go on about data and recursion. I’ve been ramping up my progress with CPSC 110 for the last couple weeks, and I’ve managed to do a couple ‘weeks’, or modules, since I last published a set of notes. Regarding my old end date goal, I’ve decided to shift my goal more towards a September challenge (of the exam), to give myself time over the summer to cram and practise with old papers. (Ironically, I’d also decided at the beginning of the year that I’d take this summer to rest and relax before university, but I suppose that’s gone out the window in lieu of some hopefully more engaging plans. And hey, if I choose to relax that way, I guess it’s a perfectly fine thing to do.)

After getting back in the swing of Racket and relearning the templates and design recipes, these couple modules haven’t been too challenging. Adding systematically onto the recipes makes the logical jumps between concepts less sharp, and makes the course much less intimidating. Having a repository and tracking my progress with the course has definitely motivated me to work on it more. So, here’s a couple modules’ worth of notes - but as always, if you’re not following along with CPSC 110 or have no interest in learning about compound and arbitrarily long data, you might want to go off and read a different post.

Notes - Week 3

Week 3 goes over how to define compound data (essentially adding structs to the data definition recipe), and integrates that data in building ‘worlds’, or GUI programs. Having a proper definition for data simplifies things in future weeks, and makes the data definitions seem more solid or ‘real’, in my opinion.

• ticks => update behaviour, but can be changed by interactive input
  • tick rate is defined by the program, can change
  • can use a data definition to interpret the current state
• (big-bang) function used to make these graphical programs => called worlds
  • import (2htdp/image) and (2htdp/universe)
  • use (place-image) and the (empty-scene) frequently to draw and render
  • rendering is done by setting the (to-draw), and tick behaviour by (on-tick)
    • later use (on-key) and (on-mouse) to handle those behaviours
• start by doing a domain analysis => what remains constant and what changes each tick
  • each function is first wish-listed as the overall world is structured
  • apply HtDD to design the program state data => structs in second half of week
  • apply standard HtDF to create functions used in big-bang
  • use constants in the (check-expect)s to maximize adaptability
• use (define-struct name (args)) to define compound data => data that relate to each other
  • when expression run, generates the (name?), (name-args), and (make-name) operators
  • in HtDD example definitions and tests => now have to use (make-name (args))
    • include the data types here and intervals if using Naturals or Numbers
  • need to add interpretation for data types with the ;; Name is ... comment
  • add interpretation for each field in HtDD interpretation comment
  • HtDD (fn-for-name) now includes each of the fields used in the args
  • include number of fields with the compound keyword when listing template rules used
  • when using HtDF => add constraints and notes in the tests => clarity of examples and behaviour
• (on-mouse) and the (on-key) events are handled with an overall cond
  • will take mouse event / key event as argument
  • need to check the state / key with string=? or key=?
• use helper functions where possible to ensure function does one thing

Notes - Week 4

In Week 4, Kiczales discusses arbitrarily sized data, which is basically a convoluted way of working with lists. This week also has to deal a lot with recursion, which is something I’ve sort of avoided as much as possible in the past. However, it’s been pretty interesting to see how to solve problems recursively, which I think will come in handy down the line.

• we use recursive data definitions to model arbitrarily sized data => compound data
  • set a base case (empty, or false), as well as (cons)‘ing it with an element and then the original data definition
    • this element can be atomic non-distinct data, not just another data definition (reference)
  • an example of self-reference, where the data definition involves itself
  • new primitives: (first list) returns the first element, and (rest list) returns everything but the first element
• with HtDF, several things have changed to accomodate new branches
  • refer to the type comment and how it refers to itself => preserve that in the function templates
  • template now needs to apply a (fn-for-element) for the first element
    • this should be another helper function generally, want the function to do one thing at a time
  • template applies the (fn-for-list) for the rest of the list
  • generally use a (cond) to check if the list is empty (base case handling)
  • examples can help clarify the behaviour of the function first, and show where you might need helpers
    • also insert tests for base cases themselves
• positions in list templates matter and have their own functions
  • base => when the function exits and ‘bottoms out’
  • contribution of first => the first element (type checking generally goes here)
  • combination => check other cases or perform operations on the value of the rest of the list
• when the recursive data definition handles another data definition => reference rule
  • produces a natural helper => abstract this to another function

Conclusion

As I write this, I’m actually halfway through week 5, but it’ll take me a good while to write up that double module’s notes properly, and I’d rather not extend this post too much. I’m also almost at the halfway mark of the whole course (yay me!), but I’ve noticed that most of the next modules are broken up into a and b sections, so I expect it’ll probably be more work than the first couple weeks. I’ve heard that the later weeks heavily build on the beginning weeks, so I might come back and update my notes posts every so often. I hope I’ll be able to at least go through another couple weeks before spring break ends, but I also want to take enough time to relax and recharge¹.

I have no big plans with regards to projects at the moment - I’m just trying to keep everything stable before I graduate, and continue to explore opportunities I might like to take after I enter university. It’s rather scary that I’ll be an actual university student in a couple months, and that my quintessential ‘high school experience’ is nearly over. A post about Racket is probably not the best place to digress into all the amazing experiences that’ve filled the last couple years, but I will say it feels a bit strange to consider that I’ll be one of ’them’ (an actual student) in the fall, and that I have no idea what I have time for left in the last three (well, two and a half, if we’re going to be precise) months. Well, we’ll figure it out eventually (and finish CPSC 110 somewhere in the process too).