Re: Meta-point: backward compatibility
On 2008-04-30, Ross Paterson [EMAIL PROTECTED] wrote: On Thu, Apr 24, 2008 at 08:18:10PM +, 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. Class aliases (or the ability to add superclasses) would certainly help in letting many of these things be more easily tested. I suppose we don't need vector spaces. Nor do we need rationals, complex numbers, or even arbitrarily large integers. Nevertheless, there is a huge benefit to having the interfaces for them there. -- Aaron Denney -- ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Meta-point: backward compatibility
I agree with Neil. Translators are very difficult to do right, except for the most trivial transformations. Changing tabs to spaces is about as far as I would trust an automatic translator. -- Lennart On Thu, Apr 24, 2008 at 9:21 AM, Neil Mitchell [EMAIL PROTECTED] wrote: 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 ___ 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
Re: Meta-point: backward compatibility
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 ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Meta-point: backward compatibility
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 [EMAIL PROTECTED] 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. ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Meta-point: backward compatibility
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 ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Meta-point: backward compatibility
Chris Smith wrote: 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. The $ problem is an interesting one, for it has the following properties: 1) Someone who learns Haskell for the first time will not complain about either associativity. Whether it's left or right associative is rather unimportant, it is how it is and either way is fine. 2) But once the decision has been made, it's nigh impossible to change it, simply because everybody has relied on one particular associativity of $ all the time. 3) Assuming that this associativity is a matter of taste, it only sounds fair to experiment and try different tastes. So, Cale has a Prelude with left associative $ and Lennart has a different personal Prelude as well and I'm going too taste a sip of either one and brew my own functional coffee. But in that situation, the defining property of a standard, namely that everybody uses the same $ , is gone, everybody would have to check which one is used in which module. It's like being forced to eat chicken only because chicken lay eggs. Some may like it, some may not, but the eggs will hatch new chicken who lay new eggs for all eternity :) Regards, apfelmus ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Meta-point: backward compatibility
2008/4/24 Chris Smith [EMAIL PROTECTED]: 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 ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Meta-point: backward compatibility
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. -- Johan On Wed, Apr 23, 2008 at 2:16 PM, Chris Smith [EMAIL PROTECTED] 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
Re: Meta-point: backward compatibility
On Wed, 23 Apr 2008, 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. Current practice often involves removing certain warts anyway - the MR being a great example. -- [EMAIL PROTECTED] Ivanova is always right. I will listen to Ivanova. I will not ignore Ivanova's recomendations. Ivanova is God. And, if this ever happens again, Ivanova will personally rip your lungs out! ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Meta-point: backward compatibility
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 ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Meta-point: backward compatibility
On Wed, Apr 23, 2008 at 4:52 PM, Niklas Broberg [EMAIL PROTECTED] wrote: 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? You're of course right. Haskell' could be both. It probably should be as the next Haskell standard (after Haskell') will probably be several years in the future. It would be a shame to wake up the day after GHC fully implements Haskell' and notice that nothing has changed and my old annoyances are still there. -- Johan ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Meta-point: backward compatibility
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 ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Meta-point: backward compatibility
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 [EMAIL PROTECTED] 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 ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Meta-point: backward compatibility
On Wednesday 23 April 2008, Chris Smith wrote: 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.) The thing is, fail isn't evil because it's intrinsically evil; it's evil because it's in the wrong place. Many monads don't have a proper notion of failure, so error just gets called, which is undesirable. (Even if they do have a proper notion of failure, it's also easy to forget to define fail appropriately, if you're defining your own monad.) Discouraging people from ever using fail, or even monadic pattern matching is also undesirable, because there are plenty of places where it is appropriate. As an example, I saw a blog post that included code like so (I don't remember the exact code, but this is comparable): f c l = length [ () | (c':'h':_) - tails l, c == c' ] In the comments of that blog, someone had written that the code was evil, because it was an abuse of fail. But that isn't an abuse of fail (it doesn't even use fail at all, technically, since list comprehensions have their own desugaring in the report), it's appropriate use of fail. So clearly, people are already getting the wrong idea from the don't use fail push, and may be avoiding appropriate use of it, when it would make for clearer code. So, if you ask me, the solution isn't discourage all use of fail. There's nothing wrong with failing in an arbitrary monad-with-failure. And we already have a class for that, called MonadPlus (or MonadZero if you split them up as in 1.4). If you move fail there, then you can encourage use of fail when appropriate. Currently, it seems difficult to do that (witness the readM thread on the libraries list, where it was proposed that fail be used (because there are multiple ways to fail), but with type restricted to MonadPlus; most people still seemed to dislike that because 'fail is evil'). -- Dan ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Meta-point: backward compatibility
Simon Marlow: 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. [..] 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. 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. After all, this is only needed for active projects that want to make use of H'. For old code, I expect that compilers will still provide a -XHaskell98 flag or similar for the foreseeable future. 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. Manuel ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
