7 of us met two weeks ago today for the 7th book club meeting and we made good progress.
We started by discussing whether we wanted to push on into Chapter 4 and implement numbers for our interpreter or to refactor some of the existing code and in particular List#evaluate which looked like it was becoming increasingly complex. This time we decided that refactoring was overdue and started work on this first and then moved on to Chapter 4.
@tomstuart drove the laptop and projector and together did some refactoring first
This highlighted the fact that our interpreter allows you to redefine these keywords whereas many scheme interpreters appear to have a separate spaces for variables and keywords i.e. in chicken scheme [1]
#;1> (or (quote a) (quote b))
a
#;2> (define or (quote my-or))
#;3> or
my-or
#;4> (or (quote a) (quote b))
a
#;5>
This made some of us feel uncomfortable about this implementation. The Little Schemer book does not suggest one approach or another and we didn't come to agreement on the reason why this might be the case in many scheme interpreters (i.e. is it just an implementation detail or specific language design and if so why).
Note: although we didn't try this out in the meeting, mit-scheme [2] works like our interpreter does in the sense that if you can redefine a keyword [3].
This made our primitives much more explicit.
There was some discussion of how much this refactoring of List#evaluate (both putting keywords and primitives in the environment) had reduced complexity vs. just moving complexity about in the system.
Then on to chapter 4
These meeting notes are a little later than usual and have just made it out in time for our next meeting which is tonight. See you there,
J.