Re: Syntax Extensions (and future Haskell)
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. 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. 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. Regards, Bruce. ------------------------------------------------------------------------- Institute for Information and Mathematical Sciences Massey University at Albany, email: B.I.Mills@massey.ac.nz web: http://www.massey.ac.nz/~bimills -------------------------------------------------------------------------
Bruce I. Mills wrote:
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.
Remember Flon's law. The fact that you CAN do something does not mean that it is a good idea.
You raise a number of important points, and basically I, and I think most Haskeller's, agree with you: we would like to strive for uniformity. But how does one get there, how does one agree on agreeing? A large part of the answer, I think, is thorugh experiments, i.e. experimental language features, trying to find good answers to questions like what works, what doesn't, was it really worth the effort, and how does the various faetures interact? And in order to find *good* answers to such questions, one need to make use of these features in pretty serious projects, which in turn implies that there has to be a reasonable way of enabling and disabling them. And command line arguments just isn't a very good way of doing that in practice. A second answer two your concerns is that even in an ideal world, I'd think we'd end up with two or three versions of the Haskell that needs to be supported, just for legacy reasons, say Haskell 98, Haskell 98 with commonly accepted extensions, and somewhere down the road perhaps Haskell mk II. It would be desirable for the various Haskell implementations to support all of these to the extent possible, and again one would need a way of specifying which, and again command line arguments are arguably not the right way of doing that. So, in my view, the idea of language pragmas is just a way to make what we currently have work better and smoother in order to facilitate doing real work with Haskell. Ultimately, the experience thus gathered will enable better decisions to be taken regarding how Haskell should evolve, hopefully eventually leading to a new, uniform base-line language that everyone can agree upon. And then the process can start over again! ;-) Best regards, /Henrik -- Henrik Nilsson Yale University Department of Computer Science nilsson@cs.yale.edu
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
participants (3)
-
b.i.mills＠massey.ac.nz -
Brandon Michael Moore -
nilsson＠cs.yale.edu