Code from last night's meeting

[Chris Lowis]

Hi!

Joel, James, James and I got together last night to carry on work with
our implementation of a scheme interpreter that can run the examples
from the Little Schemer.

We started to make progress on implementing "lambda". The code we
wrote last night is here:

https://github.com/chrislo/little_scheme/compare/310314-meeting

Cheers,

Chris

[Tom Stuart]

On 1 Apr 2014, at 03:52, Chris Lowis <chris...@gmail.com> wrote:
> Joel, James, James and I got together last night to carry on work with
> our implementation of a scheme interpreter that can run the examples
> from the Little Schemer.
>
> We started to make progress on implementing "lambda".

This is great! Nice work everyone. I've merged these commits into my copy of the repo.

For future reference (i.e. next time): what's the next step? Do we already know why some of the chapter two tests are still failing, or does it require investigation?

Cheers,
-Tom

[James Mead]

Although we did implement "lambda", some of the specs for "lat?" weren't passing. We started to dig into why they weren't passing, but ran out of time. So the next step is to work out why these specs aren't passing. If I remember correctly, we thought it was related to how values of true and false are represented.

Cheers, James.

[Joel Chippindale]

I must admit I took a little look this evening and we had already identified the issue but I think our tiredness caught us out and so I've made a pull request to fix a bug we introduced in some refactoring and also to evaluate `#t` and `#f` correctly to get the lat? specs passing [3].

A few more notes on the meeting:

We worked on lambdas and function definitions, and made the assumption that all functions have a single argument to keep things simple. This is all that is required for Chapter 2 of the Little Schemer (and if it's good enough for Haskell then it's good enough for us).

Treating the Little Schemer specs for a language left us wishing the examples had come in more bite sized pieces. Tom had already added some specs which don't appear in the book to help provide stepping stones for the first example in Chapter 2. These included ones for `cond` which we got passing in the previous meeting, and for a lambda which is evaluated immediately which we added support for in List#evaluate.

We introduced a Lambda class to enable us to store lambdas in the environment and also added a much simpler spec for lambda to help us work on storing lambdas in the environment and probably would have felt more comfortable if we had added more of these smaller step specs.

We noted the difference between parameters (which appear in the function definition) and arguments (which you pass when calling a function) as part of refactoring some of the names of our parameters. This was a distinction that I can't help but feel I should probably have learned many years ago.

We also noted that the List#evaluate method is starting to look like it could do with simplification and lamented Ruby's inability to allow us make Atom::FALSE falsey which would make us a bit more comfortable with returning it from query methods like Atom#eq?

J.

 

--
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.