Hi,We had the tenth meeting of the Little Schemer book club earlier this week. 6 of us made the whole meeting and James M. joined us for the first section where we decided what we were up to.
The first 15 minutes of the meeting were focussed on deciding what we wanted from the Little Schemer book club and what we would do next. Various options were discussed from stopping, to switching our focus solely to our scheme interpreter (and abandoning the book), to continuing as we were (with specs for each chapter), to moving our focus away from the interpreter and taking on the form of a more traditional book club where we read and discuss chapters.
We agreed on taking the focus away from the interpreter (for now) and reading/discussing chapters 7-10 as a more traditional book club. The main reasons we went for this were:
- [SPOILER ALERT] Chapter 10 is about building a scheme interpreter in scheme and so may offer us useful insights into building scheme interpreters.
- Our interpreter can probably already handle all the (interesting) things it needs to provide a run time for the examples in the rest of the book and so the book is no longer useful for driving our scheme interpreter.
- Tom S., back in January wrote the specs for chapters 1-7, but there is little appetite for writing full specs for chapters 8-10.
- Some of us are completionists, for our sins (you know who you are)
Having made a clear decision about the future of the club we moved on to Chapter 7, "Friends and relations"
We noted that the structure of the examples in this chapter reflect the book's 6th commandment,"Simplify only after the function is correct". Many of the functions start with 'dumb' formulaic implementations and are then subsequently simplified (red-green-refactor anyone?).
We worked through a number of examples together including parsing the `xxx` function to determine it was the difference (of sets) function.
We noted the definition of `third` was a red herring typical of the Little Schemer book, in that it bore no useful relation to the rest of the chapter.
We discussed the mathematical meaning of 'function' and in particular how a finite function could be represented as a finite list of pairs of inputs and outputs, with certain restrictions on these pairs i.e. the inputs need all be different. We saw how a `fun` was representation of this idea in the book.
We noted how the book used parameter names to indicate the type of value a function expects. For example
<snip>
(define makeset
(lambda(lat)
...
</snip>
Where `lat` is assumed to be list of atoms.
This seemed interesting in the context of the definition of `full_fun?` which surprised us by not checking whether the input is a function because the parameter name 'fun'
We then found the draw of chapter 7 specs (the last that Tom had written) irresistible and made the minor tweaks to the specs in order to get them to work with our implementation. Tom highlighted a conversation he had had with James A. about how, in retrospect, he could have parameterised his specs to make them independent of the particular interface any given interpreter might make available. Chris L. was driving this section and so I imagine will issue a pull request in the near future for these spec changes.
Satisfied that we had made good progress we retired to the pub where there was much interesting discussion of what we might do after the Little Schemer book club finishes. I won't reveal the ideas here because our first decision was that we should start by setting up a new mailing list since we have drifted a long way from the original purpose of this list which was to talk about Tom's "Understanding Computation" book. Watch this space.
Cheers,
J.
P.s. without the aid of a list of commits to remind me of what we discussed in the meeting I may have missed something so do feel free to add your own recollections or correct mine.