[Haskell] Status of Haskell'?

Fri Nov 30 21:50:52 CET 2012

On Sat, Dec 1, 2012 at 3:36 AM, Gábor Lehel <illissius at gmail.com> wrote:

> > But in Haskell right now, for practical purposes, we don't
have competing implementations. We have GHC.

Isn't "putting pressure on the community" for a new standard a way to, umm,
implement wished-for features in GHC economically? ;)

-- Kim-Ee

On Sat, Dec 1, 2012 at 3:36 AM, Gábor Lehel <illissius at gmail.com> wrote:

> 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.
>
> _______________________________________________
> Haskell mailing list
> Haskell at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell/attachments/20121201/222df346/attachment-0001.htm>