On Thu, 18 Sep 2003 b.i.mills@massey.ac.nz wrote:
Although a number of comments in this discussion make some sense, I personally am getting worried about the direction that it is taking. I have been a (fairly quiet) Haskell user for some time. I like it because of the strong connection to standard mathematical constructs, and the dedication to equational reasoning. I was dubious when Monads were introduced, but grew to be comfortable with that as an approach to embedding temporal characteristics, I try not to use do, I like the fact that I don't have to. But, recent developments on this list suggest that this is all going to be a thing of the past. There is a real danger that Haskell will just turn into yet another procedural language.
What worries you? I don't see what configuration has to do with procedural languages. The elegant solution everyone is looking for would make it easier for the language to evolve, but I don't see why it would become more procedural. If anything most of the current extensions move Haskell even farther from normal procedural languages. I'm curious what procedural tendencies you see. I agree monads are becoming very popular, but I don't equate monads and imperative languages. Maybe IO and ST are imperative.
Firstly I want to bring into the open something that you would all be aware of. It is possible to change any typical procedural imperative language into a functional language by a change of point of view. All you do is just state that each command in the imperative is a function that operates on the state of the machine. The entire program becomes a composition of these functions. Control statements such as for-do-while-until-repeat-if, simply become higher order functions. That's why the monad stuff works, all it does is demand that you explicitly admit to the passing of the state.
If you keep going the way you are going you will simply turn Haskell into a procedural language with some snazzy data-types. It would survive, perhaps, but in name only.
The importance of Haskell is not that it is Functional, this is in reality just a technicality of point of view, the importance of Haskell is the WAY in which it is functional, the emphasis it puts on the manner in which the total function is decomposed. It is important not simply that Haskell admits equational reasoning, but that it is equational reasoning that a human can do, not something that requires a heavy duty code transformer to work out.
At least this is how I see it, perhaps this is simply the point at which Haskell and I part company?
I also don't see the point of the language configuration pragmas either. Uniformity is important. Instead of agreeing to disagree, and coming up with a rag-bag language, the points need to be nutted out until they make consistent sense. The pragmas do not represent any uniformity, they actually represent a schism, you can't agree so you are splitting the language into incompatible variants. It solve the political problem of in-fighting, but only by letting the in-fighting destroy the language. It's the same sort of thing that splits C++ into multiple camps, the same thing that gives the multiple levels of comments in comments for postscript, and so on.
I agree with Henrik here. I see two main purposes to configuration, backwards compatibility for continuting support of the standard and of legacy code, and the freedom to experiment with the language without committing to extensions. I see multiparameter type classes and explicit quantification as part of the current langauge, and expect others feel the same way. I expect implicit parameters to remain experimental until we really understand them, for example.
Remember Flon's law. The fact that you CAN do something does not mean that it is a good idea.
I'll get off my soap box now.
If it gives you a useful perspective, and gets your insights back to the rest of us, stay up there for a while. We can always use good ideas. Brandon