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
> 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])
> 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
> In one daily email
> Don't send me mailing list messages
> Meetup, POB 4668 #37895 NY NY USA 10163 | [address removed]