[Haskell-cafe] Re: Research language vs. professional language
wren ng thornton
wren at freegeek.org
Wed Sep 3 23:03:39 EDT 2008
Jonathan Cast wrote:
> > But Haskell's community is also growing
> This is good!
> > and becoming more
> > results-oriented.
> This is not; see my other post. I think it's great that Haskellers are
> starting to accomplish useful things, but if in the process I think
> elders like Lennart Augustsson and Paul Hudak are starting to be
> ignored. Hair-shirt wearers need to have someplace to live. Up until
> recently, that's been Haskell. I can't help seeing putting things like
> ad-hoc overloading or ACIO into Haskell as theft of that territory from
> them, and I think it's incumbent upon those who would do such a thing to
> propose where the hair-shirt wearers are going to receive asylum now
> that they're being expelled from Haskell.
I can't express how strongly I agree with this. For me, the most
fundamental and radical idea of Haskell is the idea of purity. For a
long time functional languages have claimed the moral high ground, but
they've all made concessions against purity. In a world dominated by
impure procedural languages, it is imperative to have a language which
is unwilling to make concessions for the sake of expediency. Moreover,
it is imperative to have a language which is just as vehement about
finding the correct answer as it is unwilling to concede. I'm eternally
grateful that Haskell has had that vehemence, because it means I can use
it in day-to-day programming and at work. But sacrificing that purity
for daily expediency defeats the whole exercise. If it can't be done
purely then we're doing it wrong. I chose to don the hair shirt.
> > So, my question for you is: if Haskell is a research language, what
> > direction should it be taking? What changes should be happening at
> > the language (not the library) level that are in the interests of
> > improving the state-of-the-art in functional programming?
* Extensible records, seconding Jonathan Cast.
* Extensible unions. Something combining Datatypes a la Carte with the
work on Bit-C to allow construction of ad-hoc unions as well as
specifying how the unions are tagged, all while ensuring safety. DTalC
is nice but it would be nicer if we could use, say, a Huffman encoding
of the coproduct tag rather than just a linear encoding.
* Inference with type-classes (and fundeps). How exactly we determine
the correct instance to choose has some irksome limitations at present.
It would be nice to explore how much of logic programming we could lift
into this decision without ruining performance. Many of the proposals
for haskell' to deal with MPTC are in a similar vein.
* Refinement types. Doing this purely would help capture a wide genre of
OO-like ad-hoc polymorphism, and it would let us totalize partial
functions like `head` and `div`.
* Top-level mutable variables, dynamic linking. This is also seconding
Cast, but I mention it more in the vein of capability systems and
component-based programming. Having a coherent story for how programs
are constructed from components/modules including all the gritty bits
about duplicating components and wiring them together efficiently; that
is, can we take the compositional and applicative features of functional
programming and apply them to the module layer?
* Distributed processes. This is more in the vein of Erlang, but an
exploration of the problem space seems to be in order. This feels very
similar to the previous point, though one of the key focuses here would
be on the memory model and GC.
* Effect systems, in particular the composition of effects. Monads are
nice and fun, but they do sort of paint one into a corner
language-design-wise: once you use them to encapsulate effects, that
forces your hand when it comes to combining effects etc. Also, this
essentially gives us two orders of evaluation: by-need for pure values,
and sequentially for effectful values. What about other orders for
effectful values? What about breaking up the sin bin of IO? Studying
this in depth would most likely fork the language, but there is still
research to be done.
> > My goal is
> > to make it not be a joke when I go to work and suggest that we use
> > Haskell for part of our next project. What is yours?
> My goal is to ensure there's an even better language to propose using 10
> years from now.
Again, ditto Cast. In ten years I want a language that's as far ahead of
Haskell as Haskell is ahead of the other languages out there today.
More information about the Haskell-Cafe