Re: functional programming is great, but why lists?

[Benderjg2@aol.com]

In a message dated 10/11/2001 8:33:33 PM Central Daylight Time, richter@math.nwu.edu writes:


> But I have a few nephews & nieces of approx high school age, and I'm
> always tempted to try to pull them into PLT Scheme.  But I wonder how
> I'd answer that question, 



Bill,

I think you have this backwards. Your nieces and nephews will first have to learn how to deal with _concrete_ datatypes like lists and numbers before they could even begin to understand a more _abstract_ representation of these types using ONLY lambda expressions. Working first with the primitive car, cdr, and cons as a concrete list datatype helps a student to later understand the SICP presentation of these in terms of "lambda" only.

Maybe I just don't understand math ;) but this is certainly the case for me. I have been wrestling with an "algebra" for turtle graphics based on monads--written in Scheme. An "API" really. (The aim was to do a purely functional turtle graphics package that renders into "Scalable Vector Graphics", an XML language.) Despite my "lofty" goal, the only way I could make any progress was to work in much more concrete terms: what function calls do I want a user of my turtle graphics API to make for drawing a particular shape, what information needs to be passed from one "turtle command" to the next, what should the result of a whole sequence of turtle commands be. At the end of this, I have something that both works and at least looks monadic. But I would never have gotten there by trying to directly write monads for things like "state" and monads transformers, etc. for writing and combining turtle commands. (In fact, I tried really hard at doing exactly that!) Another advantage of working _first_ with more concrete ideas, users of the APIs don't have to see "monads". If I had trouble _designing_ with monads, I wouldn't want to impose them on the unsuspecting high school graphics programmer or geometry student.

Now that I have working (probably monadic) code, I know that more abstraction is possible: I could probably more modular monads, with more better monad transformers. But I will only get there after a few more examples of "composing monads".

(As an aside, having only just gotten this API working, I haven't yet had time to verify that the API implementation follows proper monad laws. But for myself, I don't really care about doing so for math-reasons. What proving that the API obeys monad laws would buy me is the ability to implement an optimization that would give an improvement in memory allocation and probably performance.)

Jim Bender