A New Haskell and those anxious to change

Haskell' (pronounced "Haskell prime") is being formulated while we sleep. While the committee wants to incorporate into the new standard only "tried-and-true language features", a quick glance at the mailing list shows quite a few unimplemented ideas being tossed around.

The same thing happens with the C++ standardization process. Is it a good idea to keep language standardization conservative? Herb Sutter would perhaps argue so, since the export feature in C++98 was so rarely implemented.

So, is conservatism right for C++0x? Is it right for Haskell'?

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Committees should listen to programmers.

There was a discussion recently in artima.com about features that C++ must have. Stroustrup kindly responded to some messages, but the overall tone was "that is it". But the fact is that C++ has some "big" problems, and bold decisions are needed.

Cutting Hedge

If we don't want the cutting edge we know where to find it. To my mind conservative design is not appropriate for Haskell or any other interesting programming language.

Codifying the current extensions

Right now, there are several extensions to Haskell 98 in common usage (higher-ranked polymorphism, multi-parameter type classes, etc.). As I see it, the goal of Haskell' is to reflect the current state of the language-as-written, providing a stable base for portable code and for future extensions.

conservatism where sensible

while i think that conservatism is necessarily part of the nature of standardization processes, i believe that the reasoning to block language features should be done in a very sensible way.

the current incarnation of c++ suffers from major issues. the largest, namely the lack of many necessary standard library components, is actively targeted with the upcoming version. here the standard comitee has clearly seen the need to drop conservatism in favor of competitiveness. it is good to see that even previously discarded features like multithreading are accepted regardless of the obvious portability issues to some target platforms.

unfortunately the same issues do not resolve so well at language level. features seen in other comparable languages are slowly, if at all seeing their way into c++. there are missing features which draw projects from c++ to other languages where standard proposals drag their way for years now. think about reflection or lambda for example.

imho templates are a good example that a sound language feature can be very successful even if it is far from perfect. historically templates have been dragged into the language in a pragmatic decision to allow the development of generic types, where back then unsolved issues did not hinder the integration.

maybe standardizations sometimes strives for a little bit too much of perfection. ;)

in favor of conservatism

It seems silly to standardize anything without an implementation. A working implementation focuses discussion and makes the abstract concrete (by bringing up implementation issues, usability issues, etc.)

That's not to say committees should ignore users; but the users really need to be talking to the compiler makers, not the standards committees.

I agree

How does a new feature interact with all of the current features of a langauge? Can it be implemented in a reasonable way, and reasonably efficient? These are questions that obviously get addressed in any example implementation, but can easily be overlooked in a paper-only implementation.

Historical Note

It should be noted that Haskell, while explicitly meant to consolidate and codify existing practice, i.e. be a fairly conservative "common" lazy FPL, itself introduced type classes, a very significant feature, unimplemented, at least when Haskell was forming.

Also, I'd say that some things about Haskell 98 were over-conservative.

However, in practice (for Haskell), de facto standards trump de "jure" standards and the community will choose the standard anyways no matter what is written. Which is not to say a written and "accepted" standard is not useful.

If they'd only just get good record support!

Seriously, it's not like SPJ hasn't shown them the way. :)

C++ export

Herb's proposal was discussed and voted down. This comp.std.c++ thread discusses the issue in detail.

Development by standards committee?

Standards committees make very bad development groups. (Yes, that is an understatement.) If you want historical examples, look at C, C++, the ISO, or the IETF. For every success, like Haskell's type classes, there are a goodly number of failures, like trigraphs and the OSI thing.

Haskell may be a bit of a special case, since what is conservative for Haskell is beyond the cutting edge everywhere else, but how hard would it be for anyone suggesting an unimplemented idea to actually implement it and then get some experience with it in real code before proposing it as a standard? That ought to be the minimal amount of preparation required for a committe's consideration.

Consider the risks: features added to the standard language that are difficult to implement, unused, or that preclude future improvement, or are simply ugly. Not to mention language fragmentation.


I think Larry Wall had a good idea when soliciting ideas for Perl 6: to propose the inclusion of a new language feature, you also had to propose the removal of an existing one.

Admittedly Perl is a target-rich environment for language features, but the notion carries the intent of removing cruft while keeping the language up-to-date.