On Thu, 18 Sep 2003 [EMAIL PROTECTED] 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 _______________________________________________ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
