[plt-scheme] Was HTDP 21.1.2 - Why I "don't" use the design recipe

>From: Felix Klock's PLT scheme proxy <pltscheme at pnkfx.org>
>To: "wooks ." <wookiz at hotmail.com>
>CC: plt-scheme at list.cs.brown.edu
>Subject: Re: [plt-scheme] Was HTDP 21.1.2 - Why I "don't" use the design 
>recipe
>Date: Thu, 13 Jul 2006 13:50:33 -0400
>
>Wooks-
>
>On Jul 13, 2006, at 5:31 AM, wooks . wrote:
>
>>I am extremely appreciative of all the help I have gotten here but  I wish 
>>to say something that  I think applies generally to people  of my 
>>background.
>>[[snip]]
>
>I feel the design recipe is targeted at teaching new programmers how  to 
>write maintainable code, not to teach them how to maintain code  that has 
>been developed in the wild.
>

Yes I understand all that. I was talking primarily about the difficulties 
faced by people who come to HTDP having been out in the wild for any 
appreciable time and the difficulties that will  await HTDPed programmers 
that subsequently venture out into the wild. The former explained why it 
might look like I'm not following the design recipe when in fact I'm  trying 
to.


>I agree that being able to maintain undomesticated code is a very  useful 
>skill.  However, I have encountered very few ways to actually  teach such 
>skills, because undomesticated code is often by its nature  unmaintainable 
>by any pre-established method.
>
>
>>>But since I want to actually put content in this post, and since  you  
>>>could find this information from Figure 57, I'll fill in the  blank,  
>>>using the argument order you gave in your post.
>>>
>>>;; fold : X (X Y -> Y) [Listof X] -> Y
>>>
>>>Now, if you look at these two contracts, they certainly look very   
>>>different.  map takes two arguments, fold takes three; plus, map   
>>>returns a [Listof Y], while fold returns a Y.  So how could we  hope  to 
>>>implement map in terms of fold, as you say?
>>>
>>
>>Maybe I should ask the question that struck me immediately I saw  this 
>>problem. Why would I want to do this anyway. Map and fold are  clearly 
>>intuitive one is a translation the other is a  summarisation. I cannot 
>>intuitively see why I would want to  implement a translation in terms of a 
>>summarisation.
>
>Its an exercise.  But its also something that comes up in practice,  this 
>act of building a simple function like map on top of a general  function 
>like fold.
>
>My feeling about this particular exercise is that its meant to test  your 
>ability to use tools like fold to their full power.  Once you  see how to 
>implement map (and how incredibly simple it actually  *is*), hopefully 
>you'll see this "summarizing" power of fold is much  more general than you 
>might have realized.
>
>>>...
>>>
>>>Likewise,
>>>
>>>;; fold : forall X, Y . Y (X Y -> Y) [Listof X] -> Y
>>>
>>
>>Well I had a more conservative
>>;; fold : X (X X -> X) (listof X)  ->  X
>
>This is *too* conservative.  If this were the contract for fold, you  would 
>not be able to implement map using it.
>
>Not only that, but you would not be able to implement append either,  if 
>this were the most general contract for fold.
>
>This makes me very curious to see how you chose to implement append,  and 
>how you decided to instantiate the parameter X to accomplish that  goal.
>

Here's my fold with parameters reordered as suggested by Richard Cobbe

(define (fold op baseCase alon)
  (cond
    [(empty? alon) baseCase]
    [else (op (first alon)
	     (fold op baseCase (rest alon)))]))

and here is append

(define (myAppend a-list b-list)
  (fold cons b-list a-list))

<snip>



>>
>>;fold : list (S list of S -> list of S)
>
>I can't read this.  Either you have the parentheses mixed up in your  
>contract, or you're telling me in some manner that fold is not a  function, 
>but instead a list of functions, which doesn't make sense  for fold.
>

Sorry I meant

;fold : list (S list of S) -> list of S

Right now my head hurts so  I will take a break and come back and reread all 
the input I've had to this problem as well as rereading chaps 19 & 20.