2008/4/22 Aaron Denney <[EMAIL PROTECTED]>: > On 2008-04-22, Simon Marlow <[EMAIL PROTECTED]> wrote: > > > Chris Smith wrote: > >> I know it would break > >> nearly every single piece of Haskell code I've ever written. As such, > >> I'm biased toward thinking it's an extremely bad idea. > > > > Absolutely. Given that, we'd need a *very* good reason to make the change. > > Surely we don't expect the majority of Haskell code to work unchanged as > Haskell' code? >
And if we're not going to break things in Haskell', then when *are* we going to break them? Making all the little fiddly changes at once seems like a better plan than standardising on one thing and then changing things away from that in the implementations shortly afterwards. It also seems like a better plan than forking the language over what are essentially library issues. (This is a sort of minor one, but there other things, like 'fail', which I certainly would hope we don't just live with forever.) If the only goal of Haskell' is to standardise current practices, then I agree this change makes no sense, but it also seems not to make much sense to standardise a Prelude which people strongly want to change. Also, the Haskell 98 Prelude has already been reported on, and probably should continue to be supported in some way or another. By the way, as Don suggests, I do strongly advocate this change, and Dan Doel has already given a very nice summary of why. With regard to reason #1 in his list, I'd just like to add that due to the fact that (.) is an associative operator, a composition chain written in terms of (.) effectively has more subexpressions than one written in terms of ($), and is thus at least marginally easier to refactor and reason about. I've found that favouring (.) and being comfortable with expressing things in terms of function composition very much puts one in the right mindset for functional programming. - Cale _______________________________________________ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
