[plt-scheme] A data point on 'match' in intro programming

Agreed, showing them pattern matching late but still in the first  
year is the right thing.

BSL, with list abbrv:

> (require scheme/match)
>
> ;; [Listof Number] -> Number
>
> (check-expect (sum '(1 2 3)) 6)
>
> (define (sum x)
>   (match x
>     [`() 0]
>     [(cons fst rst) (+ fst (sum rst))]))

Enjoy -- Matthias




On Jul 8, 2009, at 10:18 AM, Prabhakar Ragde wrote:

> Matthias wrote:
>
>> I would love to use match in introductory courses to get away from  
>> a  lot of details. (I introduced match into Scheme 84 in 1984.)  
>> Doing so  would be a great disfavor to our students. Very few of  
>> them will end  up working with a language that supports match,  
>> once they are on  their first co-op etc. If I prepare them with  
>> structures/predicates/ selectors etc, they have at least a chance  
>> to adapt some of what they  learned in "210" to their work. If we  
>> had showed them match and even  'deep' matches, it would just be  
>> one more large conflict between this  silly, design-recipe FP  
>> stuff and their real world. -- Matthias
>
> I think the pedagogy of lists in HtDP is dead on -- introduce cons  
> alone and work with it, then provide list, first, second, etc. once  
> students are ready for it. I typically get howls of outrage when we  
> move up to abbreviations. "Why didn't you tell us about this  
> before?" I explain. They don't always believe me, but that's too  
> bad. It's the right thing to do.
>
> In the same sense, I think a late introduction to match would work  
> well. I don't begrudge John his experiment with very-early match,  
> though I wouldn't make a habit of it. What I would do is introduce  
> it when it becomes useful, which in my mind is somewhere late in or  
> past the tree material. As a concrete example, I have taught Braun  
> trees in our first course, because they provide a useful example of  
> a simple logarithmic-depth data structure where only structural  
> recursion is used. One can implement priority queues using Braun  
> trees, but the code using accessors is longer and more tedious than  
> it needs to be. The code using match is short and clean enough that  
> I actually used this as an exam question. But since I'm still in  
> Beginning Student with List Abbreviations when we do Braun trees, I  
> can't ask such questions until we leave the teaching languages  
> entirely.
>
> Now, this is not what most people would do in a first course, so I  
> am not advocating making this an integral part of the teaching  
> languages. But quasiquote is in them, even though I would make the  
> same argument for that. At any rate, what I am asking for is how I  
> can put match, or something like it, into a teachpack.
>
> I also think you are selling pattern-matching a bit short. It is a  
> very good bridge to ML, Haskell, and Erlang, and I believe it will  
> show up in multi-paradigm languages (if it hasn't already), because  
> it's just so convenient for expressivity. We owe our students the  
> chance to see things that they will later do their damndest to  
> sneak into their workplace. --PR
> _________________________________________________
>  For list-related administrative tasks:
>  http://list.cs.brown.edu/mailman/listinfo/plt-scheme