[Haskell-cafe] Re: [Haskell] Nested guards?

[Wolfgang Jeltsch]

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