Status of Haskell'?

Fri Nov 30 21:36:36 CET 2012

On Fri, Nov 30, 2012 at 5:36 PM, Simon Peyton-Jones
<simonpj at microsoft.com> wrote:
> I'd argue that it's not. Haskell hasn't had a release in years, and I think
> it's time to put a little pressure on the community.
>
>
>
> The question is: who is “the community”?
>
>
>
> It’s fairly clear that the Haskell Prime process itself is languishing. The
> last message about the development process that I can find is this one from
> Malcolm Wallace, in January 2011.
>
>
>
> But please don’t blame Malcolm or the committee.  Developing new,
> well-specified changes to Haskell will only happen if there is a vigorous
> eco-system of folk who are prepared to devote the love and time to do it.
> There are plenty of people (myself among them) who would be delighted if
> there was a series of well-specified updates to the Haskell standard; but it
> is harder to assemble a group that is willing to move that process forward.
>
>
>
> Why not?  I don’t think it’s laziness or selfishness; just look at how
> helpful people are on the mailing list.  Rather, I am guessing that it’s a
> subconscious assessment of cost/benefit.  The cost is certainly significant,
> and (unlike a quick email response on Haskell Cafe) takes place over months.
>
>
>
> The benefit, for an individual, is harder to articulate.   GHC defines a
> de-facto standard, simply by existing, and for many practical purposes that
> is good enough.  However, GHC is (quite consciously) exploring stuff that
> may or may not ultimately turn out to be a good idea: it’s a laboratory, not
> an every-detail-thought-out product.  [Though of course we try hard to be
> good enough for production use.]  So there is real merit in having a group,
> not too closely coupled to GHC, that picks off the best ideas and embodies
> them in a language standard.   But if for any one individual, GHC is “good
> enough”, then the benefits of a language standard may seem distant and
> diffuse.
>
>
>
> I don’t have a solution to this particular conundrum.  As many of you will
> remember, the Haskell Prime process was itself developed in response to a
> sense that making a “big iteration” of the language was so large a task that
> no one felt able to even begin it.  Hence the deliberately more incremental
> nature of Haskell Prime; but even this lighter-weight process is rather
> stuck.
>
>
>
> I’m sure that any solution will involve (as it did in earlier stages)
> motivated individuals who are willing to take up leadership roles in
> developing Haskell’s language definition.  I’m copying this to the main
> Haskell list, in the hope of attracting volunteers!
>
>
>
> Simon

To take a somewhat contrarian position, but with many of the same points:

I don't think it's so terrible that the process is languishing. Of
course, a new standard would be nice - so would a pony.* But a
language standard is a solution to a problem that right now, we don't
have.

The situation when you really want a common standard is when you have
multiple, competing, incompatible implementations. Programs that work
with one implementation don't work with another, and there's no clear
idea of what they "should" do, only what they do. It's really
annoying, and impedes productivity. The solution is to create a
standard that specifies the expected behaviour, and to make all of the
implementations obey it. It's a lot of work, but the payoff is worth
it. If your code works with one implementation, it's likely to work
with another.

But in Haskell right now, for practical purposes, we don't have
competing implementations. We have GHC. If your code works with GHC,
it's likely to work with GHC. (Heck, the main source of
incompatibilities is /older and newer versions of GHC/.) People get
their work done, their code works, there's no big problem. So while
creating a standard is a lot of work, there's no clear payoff. People
are making the calculation that they have more beneficial uses for
their time than to work on Haskell' - and maybe they're right!

If someone wants to "put pressure on the community" to work on a new
standard, the thing to do would be to work on another implementation
of Haskell(-with-extensions), and to get it to the point where a
significant chunk of the community has reasons to prefer it over GHC.
Even that feels a bit like putting the cart before the horse, though:
the value would be more in the new, competing implementations and the
different perspectives they afford, than in the new work on Haskell'
that they might inspire. But besides increasing demand for one, I do
think that this would have a positive effect on any hypothetical new
standard and on the process of arriving at it. When making decisions
about the expected behaviour, we would have a rich body of experience
to draw on from the different implementations. Right now, it looks
like "we know what GHC does" and then bikeshedding about "but maybe
another way would be better?", without experience to inform it.
Decisions are harder to make that way, and we can be less certain that
they're right.

Executive summary: We don't need a new standard right now. If people
don't think it's worth their while to work on it, they're probably
right. New, competing implementations might be valuable. If we have
them, there will be demand for a standard, making decisions about it
will be easier, and it will probably be better.

That's my two forints.

- Gábor

* I don't actually like ponies, but I suppose everyone else does.

>
>
>
> From: haskell-prime-bounces at haskell.org
> [mailto:haskell-prime-bounces at haskell.org] On Behalf Of Nate Soares
> Sent: 27 November 2012 22:44
> To: Ben Millwood
> Cc: haskell-prime at haskell.org Prime
> Subject: Re: Status of Haskell'?
>
>
>
>> it might be wise to see what GHC decides to do on that front, first,
>
>
>
> I'd argue that it's not. Haskell hasn't had a release in years, and I think
> it's time to put a little pressure on the community.
>
>
>
> On Tue, Nov 27, 2012 at 2:15 PM, Ben Millwood <haskell at benmachine.co.uk>
> wrote:
>
> On Tue, Nov 27, 2012 at 5:35 PM, Ian Lynagh <igloo at earth.li> wrote:
>> [...] adding DeriveDataTypeable
>> hopefully wouldn't be too controversial [...]
>
> This is a little tricky since the Data class itself makes (essential,
> I think) use of Rank2Types. Typeable ought to be fine, but it might be
> wise to see what GHC decides to do on that front, first, e.g. whether
> it's going to autoderive all instances or forbid user instances or
> anything else similarly bold.
>
>
> _______________________________________________
> Haskell-prime mailing list
> Haskell-prime at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-prime
>
>
>
>
> _______________________________________________
> Haskell-prime mailing list
> Haskell-prime at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-prime
>

-- 
Your ship was destroyed in a monadic eruption.