Functional programming in Python

[Manuel M. T. Chakravarty]

brk@jenkon.com wrote,

> 	It's interesting to me to note the things that were interesting to
> you. :-)  I'm the author of the Xoltar Toolkit (including functional.py)
> mentioned in those articles

Cool :-)

> and I have to agree with Dr. Mertz - I find
> Haskell much more palatable than Lisp or Scheme. Many (most?) Python
> programmers also have experience in more typeful languages (typically at
> least C, since that's how one writes Python extension modules) so perhaps
> that's not as surprising as it might seem.

Ok, but there are worlds between C's type system and
Haskell's.[1]

> 	Type inference (to my mind at least) fits the Python mindset very
> well. 

So, how about the following conjecture?  Types essentially
only articulate properties about a program that a good
programmer would be aware of anyway and would strive to
reinforce in a well-structured program.  Such a programmer
might not have many problems with a strongly typed language.

Now, to me, Python has this image of a well designed
scripting language attracting the kind of programmer who
strives for elegance and well-structured programs.  Maybe
that is a reason.

> I think most Python programmers would be glad to have strong typing,
> so long as they don't have to press more keys to get it. If you have to
> declare all your types up front, it just means more time spent changing type
> declarations as the design evolves, but if the compiler can just ensure your
> usage is consistent, that's hard to argue with.

Type inference (as opposed to mere type checking) is
certainly a design goal in Haskell.

> 	As for the difficulty with imperative constructs, I agree it's not
> even an issue for many (Dylan, ML, et. al.) languages, but for Haskell it
> still is, in my humble opinion. I found the task of writing a simple program
> that did a few simple imperative things inordinately difficult. I know about
> the 'do' construct, and I understand the difference between >> and >>=. I've
> read a book on Haskell, and implemented functional programming support for
> Python, but trying to use Haskell to write complete programs still ties my
> brain in knots. I see there are people writing complete, non-trivial
> programs in Haskell, but I don't see how.
> 
> 	To be sure, I owe Haskell more of my time and I owe it to myself to
> overcome this difficulty, but I don't think it's only my difficulty. In the
> Haskell book I have, discussion of I/O is delayed until chapter 18, if
> memory serves. One thing that might really help Haskell become more popular
> is more documentation which presents I/O in chapter 2 or 3. Clearly the
> interesting part of a functional language is the beauty of stringing
> together all these functions into a single, elegant expression, but an
> introductory text would do well to focus on more immediate problems first.

Absolutely.  In fact, you have just pointed out one of the
gripes that I have with most Haskell texts and courses.  The
shunning of I/O in textbooks is promoting the image of
Haskell as a purely academic exercise.  Something which is
not necessary at all, I am teaching an introductory course
with Haskell myself and did I/O in Week 5 out of 14 (these
are students without any previous programming experience).
Moreover, IIRC Paul Hudak's book <http://haskell.org/soe/>
also introduces I/O early.

In other words, I believe that this a problem with the
presentation of Haskell and not with Haskell itself.

Cheers,
Manuel

[1] You might wonder why I am pushing this point.  It is
    just because the type system seems to be a hurdle for
    some people who try Haskell.  I am curious to understand
    why it is a problem for some and not for others.