A postscript. The goal is to provide these updaters in BSL
and ISL so that teachers can have students write their own
updaters. (We should dig into zippers, too.) But I suspect
HtDP/2e will drop these things in only _after_ students have
some experience with writing updaters on their own. Our pedagogic
goal is not to make writing world programs easy but to teach
systematic design. This demands on occasion that students
define simple abstractions first and are then told that
general versions exist.
-- Matthias
On Sep 26, 2009, at 3:07 PM, Shriram Krishnamurthi wrote:
> Hi Yaron,
>> We have an internal version that defines updaters automatically.
> Thus, if you
>> (define-struct world (pos vel))
>> you will automatically get
>> update-world-pos: world x pos -> world
> update-world-vel: world x vel -> world
>> We did not do this initially because, as you point out, the student
> could write these updaters themselves. However, it's conceivably also
> a barrier for some to have to create the abstraction every time.
> Personally, I'm leaning towards giving them the updaters, then showing
> them that they could have built them for themselves. (In that sense,
> the updaters would be unlike everything else that DEFINE-STRUCT
> provides, in that the other pieces they *couldn't* build themselves.)
>> Recreating the entire struct from scratch is good to do initially
> because it helps confirm that the students know what they're really
> doing, rather than hiding the details under some magical construct
> that they only use, not understand. It's similar to using CONS to
> make lists initially, before showing them LIST and QUOTE.
>> Shriram
> _________________________________________________
> For list-related administrative tasks:
>http://list.cs.brown.edu/mailman/listinfo/plt-scheme