Functional programming in Python

[brk@jenkon.com]

> -----Original Message-----
> From:	Manuel M. T. Chakravarty [SMTP:chak@cse.unsw.edu.au]
> Sent:	Wednesday, May 09, 2001 12:57 AM
> To:	brk@jenkon.com
> Cc:	haskell-cafe@haskell.org
> Subject:	RE: Functional programming in Python
> 
	[Bryn Keller]  [snip]
>  
> > 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]
> 
	[Bryn Keller]  
	Absolutely! C's type system is not nearly so powerful or unobtrusive
as Haskell's. 

> > 	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.
	[Bryn Keller]  
	I would agree with this.

> 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.
	[Bryn Keller]  
	This, too. :-)

	[Bryn Keller]  [snip]

>  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.
	[Bryn Keller]  
	Since my first mesage and your and Simon Peyton-Jones' response,
I've taken a little more time to work with Haskell, re-read Tackling the
Awkward squad, and browsed the source for Simon Marlow's web server, and
it's starting to feel more comfortable now. In the paper and in the server
souce, there is certainly a fair amount of IO work happening, and it all
looks fairly natural and intuitive. 

	Mostly I find when I try to write code following those examples (or
so I think!), it turns out to be not so easy, and the real difficulty is
that I can't even put my finger on why it's troublesome. I try many
variations on a theme - some work, some fail, and often I can't see why. I
should have kept all the versions of my program that failed for reasons I
didn't understand, but unfortunately I didn't... The only concrete example
of something that confuses me I can recall is the fact that this compiles:

	main = do allLines <- readLines; putStr $ unlines allLines
	    where readLines = do
	            eof <- isEOF
	            if eof then return [] else
	                do
	                    line <- getLine
			    allLines <- readLines
	                    return (line : allLines)

	but this doesn't:

	main = do putStr $ unlines readLines
	    where readLines = do
	            eof <- isEOF
	            if eof then return [] else
	                do
	                    line <- getLine
			    allLines <- readLines
	                    return (line : allLines)

	Evidently this is wrong, but my intuition is that <- simply binds a
name to a value, and that:

	foo <- somefunc
	bar foo

	should be identical to:
	
	bar somefunc

	That was one difficulty. Another was trying to figure out what the $
sign was for. Finally I realized it was an alternative to parentheses,
necessary due to the extremely high precedence of function application in
Haskell. That high precedence is also disorienting, by the way. What's the
rationale behind it?

	Struggling along, but starting to enjoy the aesthetics of Haskell,
	Bryn

	p.s. What data have your students' reactions given you about what is
and is not difficult for beginners to grasp?