[Haskell-cafe] Language extensions

Claus Reinke claus.reinke at talk21.com
Mon May 28 07:32:13 EDT 2007


> I meant to imply more that "it's very difficult to understand why it's 
> useful". If an extension were truely *useless*, I doubt those guys at GHC 
> would have bothered spending years implementing them.
>
> Most of the documents that describe these things begin with "suppose we have 
> this extremely complicated and difficult to understand situation... now, we 
> want to do X, but the type system won't let us." Which makes it seem like 
> these extensions are only useful in extremely complicated and rare 
> situations.

keep in mind that paper space is a precious and limited resource. the
need for extensions tends to arise in practice first, but those real examples
are far too big and complex to fit into those limitations. it is very 
difficult to
come up with examples that are small enough to fit, yet complex enough to
exhibit the problem. which means that the examples usually look artificial,
but small and complete, or realistic, but so large that their presentation
has to be shallow enough to border on vague.

> The fact that my own programs hardly ever result in situations where I want 
> to do X but the type system won't let me only reinforces this idea. Maybe 
> it's just the kind of code I write...

i find it interesting that you seem to be worried about having too many
options and features available to you, as if you were focussing on

  programming in *Haskell*

trying to make use of as many language features as possible.  in
contrast, for quite some time now, i find myself doing something quite
different, namely

  *programming* in Haskell

which works because Haskell often liberates me from having to think
about the host language i'm doing that programming in, and lets me focus
on the programs i'm interested in writing.

there are, however, occasions when the limitations of that host language
start to get in the way to such an extent that the programming i want to
do becomes painful or even impossible (for practical purposes), causing
me to divert my attention from the programming to the boundaries placed
on me

  programming *in Haskell*

in my experience, most of the extensions in Haskell have come into
Haskell because someone felt confined by those boundaries and figured
out a way to make at least some of those boundaries become obsolete,
so that they could go back to focussing on their programs again.

most of the complications in Haskell (of which there are quite a few)
stem not from features, but either from arbitrary limitations of those
features or from underspecified interactions between features. all of
which are signs that the areas in question haven't settled down yet.

think of Haskell as a large town with a reasonably solid and
well-defined center, where most of the living takes place, extending
into less solid and less well-defined corner areas, where everything is
permanently under construction. there is absolutely nothing wrong with
doing all your work in those parts of this little world that are fairly
undisputed, stable and simple ('simple' as in: a lot of work has gone
into smoothing away any rough edges, complicated limitations, or
surprising feature interactions).

in fact, it is a very sensible thing to do: if one were to move into a
new town, one'd try to live and work in a part of it that is no longer
under construction, but has all the infrastructure one needs. it is only
when one needs more than is currently provided that one needs to start
looking into those construction areas. and even then one does not look
for "whatever they have that we haven't", but rather for "i have this
specific problem; will any of the construction sites help me with it?".

don't expect construction work in the outer districts to stop just
because many people live and work happily in the town center. and, of
course, keep your hard hat on when visiting construction sites!-)

claus




More information about the Haskell-Cafe mailing list