Am Donnerstag, 6. Dezember 2007 10:03 schrieb Simon Peyton Jones:

[redirecting to Haskell Cafe]

| > It is clear that this situation must not stay this way. Bit by bit, | > disciples of Perl and Python discover Haskell and demand that Haskell | > will be plastered with syntactic sugar until the simplicity of the | > functional approach isn’t visible anymore. Sadly, they seem to be | > successful with this as syntax extensions like parallel list | > comprehensions show.

I think it is helpful to distinguish "superficial" complexity from "deep" complexity. All of Haskell's syntactic sugar is just that: it can be translated into a small purely-functional language using straightforward translation schemes. Even something relatively complicated like the "order by/group by" extension that Phil and I proposed at this year's Haskell workshop, has an easy translation that takes a dozen or two lines to give in full detail.

In contrast, something like higher order functions, or mutable state, is deep complexity. Both have a pervasive effect on the language semantics and on its implementation. (The effect of mutable state is much, much worse, but they are both deep.)

The point is that higher order functions, type classes, etc. enable you to “extend the language yourself” to a large degree by just creating libraries. Such powerful concepts give you the ability to create domain specific languages by just writing Haskell code. So they serve the approach of having few concepts in the language which allow you to do many things. On the other hand, syntactic sugar often deals with very special cases. Guards are sugar for case distinction on just a single type (Bool), list comprehensions deal with specific operations (map, filter, etc.) of a specific type ([]). Parallel list comprehensions even sugar a function which is somehow broken in a language without dependent types (zip; because of the ad-hoc solution for zipping lists of different length). In my opinion, syntactic sugar is good if it is about more general things. do and proc expressions are really useful but they don’t deal with specific types but with whole classes of types which are rather large. The ability to define infix operators is really helpful, especially for creating DSLs. (Johannes Waldmann has a different opinion here.)

Concerning Haskell, I'm quite relaxed about superficial complexity, as you'll have seen from what happens in GHC.

Yes, I have seen what happens in GHC and it makes me very sad. I think, since you are a GHC developer, you have a different perspective. You can modify the compiler to provide language extensions. People like me cannot do this. And I think that the solution is not to make the language larger and larger everytime someone wants a feature but to give people the tools to provide features without language changes.

Section 3.6 of the History of Haskell paper addresses this point specifically […].

I want to cite the first paragraph:

A major source of tension both within and between members of the committee was the competition between beauty and utility. On the one hand we passionately wanted to design a simple, elegant language […] On the other hand, we also really wanted Haskell to be a useful language, for both teaching and real applications.

This reasoning is really flawed, in my opinion. The claim is that a language without all kinds of syntactic sugar wouldn’t be useful, especially not for real applications. I claim that I’m writing really useful code in Haskell and I find myself not using many kinds of syntactic sugar. Not because I just have an opinion that syntactic sugar is bad but because I feel that my style of coding is sensible. I never consciously decided against syntactic sugar. My low-sugar style just emerged automatically over the years. As I already said, I definitely want do expressions, proc expressions and definable infix operators. However, I seldomly use where clauses. List comprehensions are more or less absent from my code and I’m even not interested in getting to know how pattern guards and parallel list comprehensions work in detail. And I don’t want to write SQL-like code in Haskell using the order-by/group-by extension.

You may disagree with the choice made by the Haskell committee at the time, and with subsequent developments, but it was quite a conscious choice, and one not without its advantages.

The choice of the Haskell committee might be okay, the subsequent developments in GHC are problematic, in my opinion.

Simon

Side note: I hope you can cope with my direct style of writing. After all, I’m just an unfriendly German. ;-) Best wishes, Wolfgang