I am trying to implement a long-lived "accumulator" Alex

-----Original Message----- From: haskell-cafe-admin@haskell.org [mailto:haskell-cafe-admin@haskell.org]On Behalf Of mike castleman Sent: Sunday, August 11, 2002 6:50 PM To: haskell-cafe@haskell.org Subject: Re: Newbie question on "statefullness"

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On Sun, Aug 11, 2002 at 05:36:21PM -0700, Alex Peake wrote:

...

n += i

So how does one doe this in Haskell?

Usually, one doesn't. What are you actually trying to accomplish?

mike

- -- mike castleman / mlc67@columbia.edu / http://mlcastle.net current location: sharon, ma, us columbia univ. grad student employees united: ¡sí se puede! http://www.gseu.net/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE9VxRarbXc6n5AevkRAm/OAJ99Ly1o2i2mncZPo2khdPfYrLR6WQCgnzbv QpTyrQlZTt7H5hHVgObvmB0= =cRVI -----END PGP SIGNATURE----- _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

G'day all. On Sun, Aug 11, 2002 at 05:36:21PM -0700, Alex Peake wrote:

I am new to Haskell. I want to do something very simple (I thought) but got lost in the world of Monads.

I want to implement something like the C idea of: n += i

So how does one doe this in Haskell?

I think this needs to be an FAQ. The short answer is that if you find yourself needing to do this, especially if you're new to Haskell, you're probably thinking about the problem in the wrong way. Haskell does not support the "n += i" idiom in the same way that C does not support, say, higher-order functions. The flip side is that Haskell _does_ support the "n += i" idiom in the same way that C _does_ support higher-order functions, in that with some effort (sometimes a little, sometimes a lot) you can simulate the same functionality if you find you really need it (using monads, continuations or whatever). However, most of the time where you would use this idiom in C, you would not use it in the equivalent Haskell program, simply because there's usually a more appropriate way of phrasing your intentions. Cheers, Andrew Bromage

This has been coming up a lot, probably because of Paul Graham's challenge: http://www.paulgraham.com/accgen.html So the answer is probably: it has to be done this way because that's what the challenge specifies. Paul's language of choice is Lisp, and he combines a higher-order function with a side-effect to give a very short and simple solution. In a side-effect free language the answer will tend to be more cumbersome, because you have to jump through some hoops to manage the state. This is certainly not a great introductory problem for someone trying to learn a _pure_ functional language. OTOH, if you want to do anything useful with any language you have to learn to do IO (and simple IO is tackled early in most languages), and therefore you must deal with Monads. I often wish that Haskell books and tutorials would introduce IO earlier; it is often near the end, in the "advanced" topics (after you've been dazzled/saturated by the magic you can do with list functions and comprehensions, and how easy it is to create abstract datatypes, and write parsers, etc...). Alistair ---- Original Message: From: Andrew J Bromage Sent: Monday 12 Aug 2002 02:27 Subject: Re: Newbie question on "statefullness" G'day all. On Sun, Aug 11, 2002 at 05:36:21PM -0700, Alex Peake wrote:

I am new to Haskell. I want to do something very simple (I thought) but got lost in the world of Monads.

I want to implement something like the C idea of: n += i

So how does one doe this in Haskell?

I think this needs to be an FAQ. The short answer is that if you find yourself needing to do this, especially if you're new to Haskell, you're probably thinking about the problem in the wrong way. Haskell does not support the "n += i" idiom in the same way that C does not support, say, higher-order functions. The flip side is that Haskell _does_ support the "n += i" idiom in the same way that C _does_ support higher-order functions, in that with some effort (sometimes a little, sometimes a lot) you can simulate the same functionality if you find you really need it (using monads, continuations or whatever). However, most of the time where you would use this idiom in C, you would not use it in the equivalent Haskell program, simply because there's usually a more appropriate way of phrasing your intentions. Cheers, Andrew Bromage

OTOH, if you want to do anything useful with any language you have to learn to do IO (and simple IO is tackled early in most languages), and therefore you must deal with Monads. I often wish that Haskell books and tutorials would introduce IO earlier; it is often near the end, in the "advanced" topics (after you've been dazzled/saturated by the magic you can do with list functions and comprehensions, and how easy it is to create abstract datatypes, and write parsers, etc...).

I think the fact that IO and efficient array updates, etc., are all best (to our current knowledge) handled in a pure function language by monads shows the actual underlying complexity that is hidden in many imperative languages. I drew an analogy between a state machine and an object that contained several variables once in a conversation. Vehement denial about an object being at all like a state machine came from the other parties. After much discussion, they conceded that yes an object really was a state machine but they'd never thought about it that way. The human mind is amazing in the level of complexity that it can deal with and the computations it can perform. Hidden complexity in programming languages however has led to numerous software problems that are common throughout the industry. I just completed a project (with several others) that takes C code and crudely converts it into it's functional equivalent. The next step is to convert the output in a pseudo-language into true functional code. The number of side effects to deal with from some of the simplest expressions has been staggering. Most of the effort in the project was spent on the increment/decrement operators and switch and loop statements. Don't worry, there won't be a c2h (C -> Haskell) anytime soon for those who remember dealing with f2c (Fortran -> C) code, that's not the purpose of this project. On a side note, Stroustroup recently wrote in an article about how the "hello, world" example was starting new C++ programmers down the wrong path from the beginning. He, of course, advocated using the iostreams and then went on to show several examples of wonderful things that could be done with iostreams. Iostreams seem to be closer to a functional concept than then clib printf variations. I think the book, _Structure_and_Interpretation_of_Computer_Programs_, by Abelson and Sussman is a much better freshman text because of it's functional approach. Real solid examples about the dangers of imperative constructs. After years of warping my brain on C++ code, I'm enjoying learning the IO monad. It's starting to make sense at a much deeper level to me. Shawn Garbett

G'day all. On Mon, Aug 12, 2002 at 04:19:38AM -0700, John Meacham wrote:

grr. this used to be in a FAQ at the Wiki. whatever happened to that?

Unfortunately, the ReportingProblems page is one of the ones which died. It's also not in the google cache. Does anyone know who's responsible for the wiki? Cheers, Andrew Bromage