Hello Philippa, Wednesday, April 23, 2008, 10:53:54 PM, you wrote:

Current practice often involves removing certain warts anyway - the MR being a great example.

it's already in ghc for a years and doesn't affect too much code. we need a solid base of a language to write to, to learn, to popularize. and to develop next, more advanced language versions -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

An interesting question. What is the goal of Haskell'? Is it to, like Python 3000, fix warts in the language in an (somewhat) incompatible way or is it to just standardize current practice? I think we need both, I just don't know which of the two Haskell' is.

I would hope it is both. Some changes simply cannot become current practice since they would not be compatible with existing code, and the only place that such changes *could* be made is in a new language version. Like you say, fail in the Monad class is one such issue that would not be backwards compatible, and couldn't become a current practice without some help. Chicken or egg first? Cheers, /Niklas

On Wed, 23 Apr 2008 22:52:18 +0200, Niklas Broberg wrote:

...

An interesting question. What is the goal of Haskell'? Is it to, like Python 3000, fix warts in the language in an (somewhat) incompatible way or is it to just standardize current practice? I think we need both, I just don't know which of the two Haskell' is.

I would hope it is both. Some changes simply cannot become current practice since they would not be compatible with existing code, and the only place that such changes *could* be made is in a new language version. Like you say, fail in the Monad class is one such issue that would not be backwards compatible, and couldn't become a current practice without some help. Chicken or egg first?

I don't think I agree that fail in the Monad typeclass is a good example here, or necessarily that there is a good example. We should remember that there is a cohesive community of Haskell programmers; not a bunch of unrelated individuals who never talk to each other. It's entirely possible to spend some time recommending against using fail (as many people have been doing), and then eventually remove it. It doesn't need to break very much. This is working in our favor, so we may as well use it. IMO, this argues strongly in favor of making any backward compatible changes incrementally, instead of adopting a "Python 3000" model of postponing them and then breaking everything at once. (This is ignoring technical issues in this particular example; like what happens when a pattern match fails if there is no fail in Monad. It's entirely possible that discouraging use is the right answer in this case, and that removal need not happen. That's beside the point.) -- Chris

Johan Tibell wrote:

An interesting question. What is the goal of Haskell'? Is it to, like Python 3000, fix warts in the language in an (somewhat) incompatible way or is it to just standardize current practice? I think we need both, I just don't know which of the two Haskell' is.

The stated goal is still for Haskell' to be a language that is stable and relevant for large-scale development for several years to come. It is mainly a consolidation effort: that is, we aim to standardise existing practice in the form of language extensions that are currently implemented and widely used. Having said that, the standardisation process gives us the opportunity to critically assess the design of these extensions, and the design of the system as a whole, and as a result we may wish to make changes in order that the resulting language does not have inconsistencies, design flaws, or critical omissions. The language design process is also an opportunity to re-assess existing language features in the light of the wealth of experience gained over recent years. A perfect example is the monomorphism restriction: we now know that this aspect of the language really does surprise people in practice, whereas this wasn't known, or at least wasn't as clear, at the time that Haskell 98 was being designed. As for the particular question of backwards-incompatible changes, here are some criteria that Henrik Nilsson proposed early on, and I think are still relevant (i'm sure he won't mind my reposting these from the committee mailing list): * If a proposed change breaks backwards compatibility, then it is acceptable only if either - very little existing code is likely going to be broken in practice, or - + it is widely agreed that not addressing the issue really would harm the long-term relevance of Haskell', and + it is widely agreed that attempting to maintain backwards compatibility would lead to an unwieldy language design, and + the proposed design and its implications are well understood, i.e. it has been implemented in at least one system and it has been used extensively, or a strong argument can be made on the grounds of, say, an underlying well-understood theory. Libraries are another matter. We have in place mechanisms for versioning libraries and specifying precise dependencies, so changes to libraries are in a sense less fundamental than changes to the language itself. We've already stated that libraries are to be standardised separately, and I think it would also make sense for library standards to be issued more regularly than standards for the language. Cheers, Simon

-- Johan

On Wed, Apr 23, 2008 at 2:16 PM, Chris Smith wrote:

...

There appears to be some question as to the backward compatibility goals of Haskell'. Perhaps it's worth bringing out into the open.

...

From conversations I've had and things I've read, I've always gathered that the main goal of Haskell' is to address the slightly embarrassing fact that practically no one actually writes code in Haskell, if by Haskell we mean the most recent completed language specification. This obviously argues strongly for a high degree of backward compatibility.

On the other hand, I am assuming everyone agrees that we don't want to replicate Java, which (in my view, anyway) is rapidly becoming obsolete because of an eagerness to make the language complex, inconsistent, and generally outright flawed in order to avoid even the most unlikely of broken code.

-- Chris

_______________________________________________ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime

_______________________________________________ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime

Hi I think Henrik's criteria are pretty close to perfect.

As I have argued before on the committee list, I also think we should *not* worry about backwards incompatible changes too much in cases where a simple automatic translation from H98 to H' code is possible. Even for a large project, it is IMHO no big hardship to run a H98->H' translator over all Haskell sources.

Some questions: 1) Will I (the programmer) have to mode switch in painful ways between H98 and H'? Do I have to learn a pile of exceptions, or is there some common rule that works? (i.e. removing n+k is fine since I just don't learn it, changing the fixity of $ is not since I need to know both) 2) Will tool T (the translator) work on academic papers that have previously been published. 3) Will tool T handle all of GHC's extensions. 4) Will tool T deal with things like CPP, hsc, trhsx, happy, alex etc... - all these file formats which include embedded Haskell. 5) Will tool T ever exist. I think the answer to 2-5 is nearly certainly going to be "No". I don't think the relevance of a conversion tool should even be considered until some person steps forward and says without doubt that _they_ will write the converter. Even if they did there very best, it still won't be trivial to use in all cases.

As John Launchbury has said, given Haskell's current rise in popularity, anything that we do not fix with H' will be much harder, if not impossible, to fix in the future.

That is a very good point. Perhaps we're already a little too late. Thanks Neil

Manuel wrote:

...

As John Launchbury has said, given Haskell's current rise in popularity, anything that we do not fix with H' will be much harder, if not impossible, to fix in the future.

On Thu, 24 Apr 2008 09:21:41 +0100, Neil Mitchell wrote:

That is a very good point. Perhaps we're already a little too late.

In general, I truly hope that this is not the case. Part of what makes Haskell such a great environment is the sense that the language values doing things right, trying out new ideas and adopting them when they work, and that the Haskell community takes pride in what we have as a language. I'm certainly willing to give up some effort fixing my old code in order to use such a language. Now, I realize that me fixing my old Haskell code means something like ten thousand lines at most, while for others it may mean a couple orders of magnitude more work; maybe it's best just to ignore me. But it would be a shame if, in the course of trying to do the right thing for Haskell's large popularity, we ended up diluting the things about the language that make it popular. So I'd argue that, in Haskell' and later on as well, it should be just a fact of life that code will occasionally break as the language evolves. If there's a consensus that something is broken, it should be fixed. If people want their code from 10 years ago to work on today's latest compiler, then there will be lots of intangible costs to achieving that goal, and I'm not sure the current spirit of Haskell will survive those costs. Unfortunately, that cost, which might be expressed as "Haskell won't be as nifty a language any more", is hard to take seriously; but I'm nevertheless convinced that it has to be taken seriously. That said, three caveats: 1. If the goal of Haskell' in particular is to codify existing practice, that's quite the admirable goal given how far behind (10 years!) things currently are in having a language standard. So this is more about how we should think about life after Haskell', rather than the current Haskell' effort. 2. Nothing I said is an argument for intentionally making people's lives painful. For example, there's no need to take approaches that break people's code between consecutive versions of Haskell with no easy way of making the code work with both. Neil said this better elsewhere, so I won't repeat it. 3. Don't get me wrong; I'm definitely not arguing for this ($) associativity change, for example, and my objection is the backward compatibility. But ultimately, it's more like a combination of incompatibility and the lack of a really compelling story on why it should be one way or the other. I have a hard time calling this a "fix"; it's more like a change of personal taste. If I saw this as really broken, then I'd say we need to talk about how to fix it. -- Chris

2008/4/24 Chris Smith :

3. Don't get me wrong; I'm definitely not arguing for this ($) associativity change, for example, and my objection is the backward compatibility. But ultimately, it's more like a combination of incompatibility and the lack of a really compelling story on why it should be one way or the other. I have a hard time calling this a "fix"; it's more like a change of personal taste. If I saw this as really broken, then I'd say we need to talk about how to fix it.

How about the argument that the right associative ($), in conjuction with (.) is less expressive than that left associative one in conjunction with (.)? That is, more parentheses can be avoided. Everything you can do with chained right associative ($), you can do with (.) and a single ($), whereas there are things you can express with chained left-associative ($) which you need parentheses to express without it. - Cale

Hi all, Manuel wrote:

As I have argued before on the committee list, I also think we should *not* worry about backwards incompatible changes too much in cases where a simple automatic translation from H98 to H' code is possible.

Yes, tools can and should help with migration, and we should keep that in mind. In particular, complicated language design to incorporate new features while maintaining backwards compatibility should be avoided where old code and new code easily can be made to work together through a compiler compatibility flag. (The discussion on records/labelled fields spring to mind.) However, I still think it is important to be conservative when it comes to breaking changes and either only consider them when the impact really would be very small, or when it is agreed it is a really important change. Even if there are tools to help with code, effort is still involved to fix the breaks, and thus it ought to be completely clear that the effort is worth it. And there is not only code: there are papers and books too! And finally, unless we're fairly strict, we'll be bogged down in a flood of discussion on gratuitous and ultimately rather superficial changes. The associativity of "$" is a case in point. So, the criteria I proposed still seem quite reasonable to me. But I'm biased, of course! :-) /Henrik -- Henrik Nilsson School of Computer Science The University of Nottingham nhn@cs.nott.ac.uk This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation.

On Thu, Apr 24, 2008 at 08:18:10PM +0000, Aaron Denney wrote:

And there is a lot that clearly isn't battle tested in a reasonable new form, though the current practice is widely agreed upon to be broken. Examples include all monads having fail, rather than only those in a subclass, monad not being a subclass of functor, and the whole numeric hierarchy issue (which I don't think can be properly designed unless we know whether it's going to be FDs or ATs, though, of course, designing it for either would provide valuable experience for the limitations of both),

I don't think any of these need involve multi-parameter type classes (we don't need vector spaces in the Prelude), but they're often presented as use cases for things like class aliases. Even then, the numeric hierarchy is probably easier to fix that the others: one can define a finer-grain hierarchy with the existing classes as a facade, and leave clients untouched. The change would be felt by the minority defining instances of numeric classes, but they are exactly the people who find the present hierarchy inadequate.