addressalign-toparrow-leftarrow-rightbackbellblockcalendarcameraccwcheckchevron-downchevron-leftchevron-rightchevron-small-downchevron-small-leftchevron-small-rightchevron-small-upchevron-upcircle-with-checkcircle-with-crosscircle-with-pluscrossdots-three-verticaleditemptyheartexporteye-with-lineeyefacebookfolderfullheartglobegmailgooglegroupshelp-with-circleimageimagesinstagramlinklocation-pinm-swarmSearchmailmessagesminusmoremuplabelShape 3 + Rectangle 1ShapeoutlookpersonJoin Group on CardStartprice-ribbonShapeShapeShapeShapeImported LayersImported LayersImported Layersshieldstartickettrashtriangle-downtriangle-uptwitteruserwarningyahoo

Re: [Clojadelphia] Thoughts on SICP 1.3

From: Paul S.
Sent on: Sunday, March 30, 2014 7:52 PM
If anyone might find my writeups for the section 1.3 exercises helpful,
solutions (hopefully correct) for almost all can be found in my github
repo. (Now with actual HTML rendering so you can see the LaTeX!):

  http://htmlprevie...­

PDF available as well, if you prefer:

  https://github.com...­

Of course, it's recommended that you try to solve as many exercises as
possible yourself, as has been observed many times, that's where the value
really lies.

Solutions are still missing for 1.35 and 1.45, as I haven't had a chance to
sit down and work through them yet.  If you're prioritizing which exercises
you work on, plan to spend a good long while poking through the details of
1.45.

Paul


On Mon, 24 Mar 2014, Tim Visher wrote:

> Thanks again for putting this together, Paul! These have been extremely helpful.
> 
> On Thu, Mar 20, 2014 at 11:38 AM, Paul Snyder <[address removed]> wrote:
> > The next section of the book is extremely important, but it may not
> > be as mind-expanding if you're already familiar with higher-order
> > functions (a.k.a. lambdas) from other programming languages.
> >
> > Section 1.1 primarily addressed issues of syntax: what Scheme looks
> > like as a language, and the process of writing a program. Section 1.2
> > (in Steve's excellent summation) is about /consequences/: if you write
> > a program in a particular way, what are results?  Not just in terms of
> > the values that result, but in terms of the steps the computer has to
> > perform reach that result. It's about beginning to build mental models
> > of processes that may result from particular procedures, in the
> > language of the book.
> >
> > Section 1.3 is about the power of abstraction. To make this point, it
> > introduces two primary concepts: =lambda= and =let=. The consequences
> > of these two forms are profound.  In Abelson and Sussman's teaching
> > notes for the book, they suggest that a course may wish to cover this
> > section /before/ 1.2, to get the concept of lambda introduced as
> > quickly as possible.
> >
> > Three key points for lambdas are:
> >
> >   A. A procedure doesn't need a name; names are incidental.
> >
> >   B. Procedures can be created, manipulated, and passed around, just
> >      like any other data.
> >
> >   C. Creating custom procedures on the fly (commonly called
> >      "closures", though the authors disparage the term) is a useful
> >      way for the programmer to specialize an abstraction for a
> >      particular purpose.
> >
> > One of the most interesting things in the discussion of the =let= form
> > is that it is, fundamentally, just syntactic sugar for a lambda. The
> > code examples in the subsection of 1.3.2 on "Using =let= to create
> > local variables" are where you should keep looking until the
> > equivalence clicks. A =let= is just a way to make your program easier
> > to read...but it's an important one, and this form is used extensively
> > in Scheme, Clojure, and other Lisps.
> >
> > Sections 1.3.3 and 1.3.4 try to get the reader to design procedures in
> > a more abstract way. Section 1.2 ran through a lot of different
> > procedures that had the same "shape": if you worked through all of the
> > exercises, you probably found that it was easiest to cut-and-paste the
> > code from previous exercises and substitute in the names of the new
> > procedures. These subsections take the tools introduced in 1.3.1 and
> > 1.3.2, and show why you don't need to do that if you structure your
> > code using suitable abstractions.
> >
> > The examples in the text and the exercises are heavily mathematical in
> > theme. Once again, don't get too hung up on this if you aren't
> > mathematically inclined. One reason they're used is that complex data
> > structures (such as lists) haven't been introduced yet, so most of
> > the procedures just operate on numbers.
> >
> > But (and this is the key), they also operate on other procedures!
> > Exercises[masked] are quite approachable, and mostly give you the
> > tools you need to solve them directly.
> >
> > Exercise 1.34 is another "figure out why this doesn't work" problem,
> > and demonstrates a type of bug you'll frequently run across when
> > writing Lisp.
> >
> > Exercise 1.35 ties back to the Fibonacci examples from the previous
> > section. If you haven't spent enough time with those, this might not
> > be the best place to focus your energy.
> >
> > Exercise 1.36 is about instrumentation: it's another way of
> > approaching the empirical examination of the processes generated by
> > your procedures. The "just stick in a print" strategy is important
> > in just about every programming language.
> >
> > Exercises[masked], have you doing fun stuff with continued
> > fractions. The problems aren't that hard, but make sure you don't try to
> > tackle these when you don't have the time to sit down and think them
> > through.
> >
> > Exercises[masked] form a great series where you generate
> > increasingly general abstractions and even write some functions that
> > are standard higher-order functions that you'll find in most Lisp's
> > libraries. Definitely work through as many of these as you have time
> > for. They build up to a final exercise where you construct an general
> > procedure that captures the significant structure of the exercises
> > from the previos sections.
> >
> >
> >
> > --
> > Please Note: If you hit "REPLY", your message will be sent to everyone on this mailing list ([address removed])
> > http://www.meetup...­
> > This message was sent by Paul Snyder ([address removed]) from Clojadelphia.
> > To learn more about Paul Snyder, visit his/her member profile: http://www.meetup...­
> > Set my mailing list to email me
> >
> > As they are sent
> > http://www.meetup...­
> >
> > In one daily email
> > http://www.meetup...­
> >
> > Don't send me mailing list messages
> > http://www.meetup...­
> > Meetup, POB 4668 #37895 NY NY USA 10163 | [address removed]
> >
> 
> 
> 
> --
> Please Note: If you hit "REPLY", your message will be sent to everyone on this mailing list ([address removed])
> http://www.meetup...­
> This message was sent by Tim Visher ([address removed]) from Clojadelphia.
> To learn more about Tim Visher, visit his/her member profile: http://www.meetup...­
> Set my mailing list to email me
> 
> As they are sent
> http://www.meetup...­
> 
> In one daily email
> http://www.meetup...­
> 
> Don't send me mailing list messages
> http://www.meetup...­
> Meetup, POB 4668 #37895 NY NY USA 10163 | [address removed]
> 

Our Sponsors

People in this
Meetup are also in:

Sign up

Meetup members, Log in

By clicking "Sign up" or "Sign up using Facebook", you confirm that you accept our Terms of Service & Privacy Policy