[Haskell-cafe] Re: [Haskell] Nested guards?
g9ks157k at acme.softbase.org
Thu Dec 6 06:20:46 EST 2007
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.
Side note: I hope you can cope with my direct style of writing. After all,
I’m just an unfriendly German. ;-)
More information about the Haskell-Cafe