[racket] Looping with look-behind and look-forward

Matthias Felleisen wrote at 05/28/2012 11:17 AM:
> But as I keep emphasizing when I teach this material, map&  fold&  filter and friends *are* loops and we teach you how to write your own loops first so that you understand what they are and can write your own when everything else fails. BUT one thing I know is that you can't legislate out bad habits :-)

Oh, I wasn't speaking of undergrad education; you guys have an immensely 
better understanding of what works for that.

I'm concerned here with people coming to Racket as an experienced 
programmer or otherwise outside of your undergrad curriculum, many of 
whom simply aren't going to work their way through HtDP before diving in.

Here's what I think is becoming a typical scenario:

1. Our protagonist, an experienced programmer, comes to Racket, reads 
through the Guide, and skims the Reference on the train.

2. Protagonist sees the fancy "for"* constructs, and figures that it the 
way to do things.

(I suspect that some contributors to #2 are: (a) in other languages 
protagonist knows, newer generalized iteration/enumeration/etc. 
constructs are generally preferred to their  lower-level precedents in 
the same; (b) from reading the documentation, the fancy constructs look 
powerful, and the assumption is that this is the powerful Racket way to 
do this thing protagonist has already conceptualized; and (c) when 
protagonist posts or lurks on the email list, they see beginners asking 
questions about how to do something and being offered answers that 
combine these fancy constructs.)

3. Protagonist proceeds to program in 'idiomatic' Racket, using these 
fancy constructs.  Protagonist might never get the introduction to some 
of the basics that s/he would've, had protagonist come to Scheme 
descendants 10 years earlier.

4. Protagonist encounters problem for which these conveniences, and the 
'idiomatic' way they've been using the conveniences, is not a good fit: 
(a) it has limits they don't know how to work around; or (b) how they're 
combining constructs is not as fast as they expect.

5. Protagonist asks about this problem they're having, and someone says, 
"Oh, you have to not use those features that everyone has been telling 
you to use since you started, and instead do it this other way that 
might hurt your brain a little if you weren't taught it from the 
start"... it might sound like the person is telling them "Don't use the 
actual language; instead use this inline assembler" (implying that the 
language isn't fast enough or flexible enough).  When I think the truth 
is more that we're showing them the core language and model -- which is 
a very nice high-level language and model -- rather than the 
conveniences spread thinly atop that.

One funny thing is, if/when I finish my book -- which is supposed to be 
"professional" perspective stuff that's complementary to the existing 
Racket manuals -- there will probably be at least one chapter that goes 
back to ancient stuff like how to use list-processing primitives with 
recursion, which I believe used to be the *only* thing many students 
were taught about Lisps in "academic" classes in school. :)

Neil V.