> -----Original Message-----
> From: Manuel M. T. Chakravarty [SMTP:[EMAIL PROTECTED]]
> Sent: Monday, May 14, 2001 10:46 PM
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: RE: Functional programming in Python
>
> [EMAIL PROTECTED] wrote,
>
> > > From: Manuel M. T. Chakravarty [SMTP:[EMAIL PROTECTED]]
> > 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
_______________________________________________
Haskell-Cafe mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell-cafe
