Quoth Stephen Bloch:
> That happens when you follow the HtDP design recipe directly and there are
> conditionals for two unrelated reasons, e.g.
> (cond [(empty? L) ...]
> [(cons? L)
> (cond [(snark? (first L)) ...]
> [(boojum? (first L)) ...]
> [(beeblebrox? (first L)) ...]
> )])
> Yes, this COULD be collapsed into
> (cond [(empty? L) ...]
> [(snark? (first L)) ...]
> [(boojum? (first L)) ...]
> [(beeblebrox? (first L)) ...]
> )
> but that doesn't match the data structure as transparently.
As an alternative, when I was teaching from HtDP last year I used the
pattern
(define (list-blah lst)
(cond [(empty? lst) ...]
[(cons? lst) (cons-blah lst)]))
(define (cons-blah lst)
(combiner (blah (first lst))
(list-blah (rest lst))))
or whatever else was appropriate for cons-blah, including a cond. Part
of me worried "ooh, mutual recursion, will that be a problem?" but this
was a total non-issue for the students, and it really *really*
highlighted the fact that lists were fundamentally an either-or type
with one branch that was a struct type. It isolated the parts and
definitely helped the students focus on the recipe.
It also had the benefit that the code didn't get too nested or complex,
which was nice.
--
-=-Don Blaheta-=-blahet...@blahedo.org-=-<http://cs.longwood.edu/~dblaheta/>-=-
"Computer science is a grab bag of tenuously related areas thrown
together by an accident of history, like Yugoslavia." --Paul Graham
____________________
Racket Users list:
http://lists.racket-lang.org/users
