[Haskell-cafe] Re: Research language vs. professional language

[wren ng thornton]

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.


-- 
Live well,
~wren