I have spent the weekend playing catchup and have implemented my own Little Scheme which passes everything in the examples for the first three chapters. Exciting times!
I’ve tried not to look too much at what’s already in the lib directory but I suspect that we’ve probably come up with a few similar ideas. Somewhat notably, I’ve used Parslet rather than Treetop to build the parser and evaluator. This has meant doing a bit of work to match the API expected by the specs (there’s no #to_ast method built in, for example, and you don’t get an evaluator quite for free, like you do with Treetop).
One other thing I’ve noticed is that my version seems to be considerably slower than the existing one. Running the examples for chapter three takes about 0.3 seconds on my machine again the mainline scheme implementation, but my version takes 1.4, almost 5 times slower! It would be interesting to figure out why, although I don’t want to look too closely at the existing version, mainly out of a perverse desire not to influence my approach (i.e. steal your good ideas).
Anyway, just thought I’d report in from afar. Hope you’re all doing well :)
> * We made Atom#number? return Atom::TRUE/Atom::FALSE instead of Ruby `true`/`false` (https://github.com/tomstuart/little_scheme/commit/c134610
)) in anticipation of implementing `number?`...
> * ...and then we implemented `number?` (https://github.com/tomstuart/little_scheme/commit/9e94612
> * We finished by implementing `and` (https://github.com/tomstuart/little_scheme/commit/6ad17bb
), which made the rest of the chapter 4 tests pass
> As a final exercise, we removed the definition of `rempick?` (https://github.com/tomstuart/little_scheme/blob/master/spec/04_numbers_games_spec.rb#L186
) from the chapter 4 examples and successfully rewrote it from scratch.
> While we were doing all this work, we noted two problems that we'd like to address before moving on:
> 1. It's becoming increasingly difficult to keep track of which methods on Atom and List return Ruby booleans and which ones return Atom::TRUE and Atom::FALSE. The consensus seemed to be that it would make sense for all of these methods to just return Ruby booleans (https://github.com/tomstuart/little_scheme/issues/10
) so that we don't have to think about it any more
> 2. It's difficult for us to write nontrivial function definitions in the examples because our parser is intolerant of extra whitespace. It would improve the clarity of the specs if we could include arbitrary whitespace (i.e. newlines and indentation) in our example programs (https://github.com/tomstuart/little_scheme/issues/11
> A few people threatened to attack one or both of these issues as "homework" before the next meeting.
> So now we've finished chapter 4, and next time we'll be able to dive into chapter 5 if we want to, or we could take a breather and look for some more refactoring opportunities before we continue through the book. As Joel already announced, the next meeting's on the 23rd of June (http://lanyrd.com/2014/the-little-schemer-book-club-meeting-9/
) -- hope to see you there!
> You received this message because you are subscribed to the Google Groups "Understanding Computation discussion" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to computationbo...@googlegroups.com
> For more options, visit https://groups.google.com/d/optout