Functional programming in Python

[brk@jenkon.com]

> -----Original Message-----
> From:	Manuel M. T. Chakravarty [SMTP:chak@cse.unsw.edu.au]
> Sent:	Monday, May 14, 2001 10:46 PM
> To:	brk@jenkon.com
> Cc:	haskell-cafe@haskell.org
> Subject:	RE: Functional programming in Python
> 
> brk@jenkon.com wrote,
> 
> > > From:	Manuel M. T. Chakravarty [SMTP:chak@cse.unsw.edu.au]
> > 	Evidently this is wrong, but my intuition is that <- simply binds a
> > name to a value, and that:
> 
> No, that is not the case.  It does more, it executes an I/O action.
> 
	[Bryn Keller]  [snip]

> The short answer is that Version 2 (the arrow) executes any
> side effects encoded in `somefunc', whereas Version 1 (the
> let binding) doesn't do that.  Expressions given as an
> argument to a function behave as if they were let bound, ie,
> they don't execute any side effects.  This explains why the
> identity that you stated above does not hold.
> 
> So, at the core is that Haskell insists on distinguishing
> expressions that can have side effects from those that
> cannot.  This distinction makes the language a little bit
> more complicated (eg, by enforcing us to distinguish between
> `=' and `<-'), but it also has the benefit that both a
> programmer and the compiler can immediately tell which
> expressions do have side effects and which don't.  For
> example, this often makes it a lot easier to alter code
> written by somebody else.  It also makes it easier to
> formally reason about code and it gives the compiler scope
> for rather radical optimisations.
> 
	[Bryn Keller]  
	Exactly the clarification I needed, thank you! 

	[Bryn Keller]  [snip]


> > 	p.s. What data have your students' reactions given you about what is
> > and is not difficult for beginners to grasp?
> 
> They found it to be a difficult topic, but they found
> "Unix/Shell scripts" even harder (and we did only simple
> shell scripts).  I actually made another interesting
> observation (and keep in mind that for many that was their
> first contact with programming).  I had prepared for the
> distinction between side effecting and non-side-effecting
> expressions to be a hurdle in understanding I/O.  What I
> hand't taken into account was that the fact that they had
> only worked in an interactive interpreter environment (as
> opposed to, possibly compiled, standalone code) would pose
> them a problem.  The interactive interpreter had allowed
> them to type in input and get results printed all way long,
> so they didn't see why it should be necessary to complicate
> a program with print statements.
	[Bryn Keller]  
	Interesting!

	Thanks for your help, and for sharing your students' observations. I
always knew shell scripting was harder than it ought to be. ;-)

	Bryn