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

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