Syntax Extensions (and future Haskell)

[Brandon Michael Moore]

On Thu, 18 Sep 2003 b.i.mills at 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