Round-up of the fourth Little Schemer book club meeting

[Tom Stuart]

Hi,

The Little Schemer book club met for the fourth time last night, on an evening which clashed with Saint Patrick's Day celebrations as well as various book club members' holidays and commitments. It's therefore kind of amazing that anyone showed up, but four of us beat the odds to spend a couple of hours talking about Scheme. Our main goal was to get the rest of the chapter one examples passing and make as much headway as possible on chapter two.

@joelchippindale cloned http://github.com/tomstuart/little_scheme onto his laptop and we got stuck in:

* We implemented `atom?` on atoms and lists (https://github.com/tomstuart/little_scheme/commit/c13a3c4)

* We took a first pass at implementing `eq?` on atoms (https://github.com/tomstuart/little_scheme/commit/2c0527b)

* We refined our `eq?` implementation to fail when either of the compared atoms is a "number", whatever that turns out to mean (https://github.com/tomstuart/little_scheme/commit/6f93346)

That got us to the end of chapter one (hooray!), so we made a start on chapter two:

* We implemented `cond` with a couple of special evaluation rules (https://github.com/tomstuart/little_scheme/commit/80bd7f4)

The implementation of `cond` provoked some debate over whether `else` should be exclusively supported as part of the `cond` code, or whether we should special-case the evaluation of atoms so that `else` evaluated to `#t` in general, which would incidentally allow it to do the right thing when used in a `cond`. We tried both strategies and both worked, but it was the latter which made it into the repository. We later verified that MIT Scheme doesn’t work this way – evaluating `else` on its own produces an unknown variable error, not `#t` — but nobody felt strongly about that. Perhaps future implementation work will clarify whether or not this is an important design choice.

Ultimately we didn't get very much done, because:

1. My RSpec examples expected a different API to the one supported by our collaboratively-built interpreter, so I'd written some adapter classes to wrap instances of our interpreter objects and change their API. This worked okay in the previous meeting, but last night we kept running into problems that were originating from within these adapters rather than from any of our code, which was frustrating and left us unable to understand the actual source of problems. Today I've changed the examples to work directly with our interpreter, which let me remove the adapters entirely (https://github.com/tomstuart/little_scheme/compare/03b6d6e...9521ba4), so this shouldn't happen again.

2. We were unclear about how to approach the implementation of `lambda`, and the adapter-related confusion didn't help. In the end we avoided touching `lambda` at all, and settled instead for making `cond` work. We'll have to come back to `lambda` (and `define`?) next time.

Overall it was a low-key meeting, but I enjoyed myself and it was great to see the chapter one examples finally passing. The next push is going to be difficult because chapter two contains almost all of the remaining implementation challenges for the majority of the book, but hopefully we'll have fewer obstacles at the next meeting and be able to make some more progress.

Cheers,
-Tom