-----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