Haskell has now reached the point where backwards compatibility is something that must be taken very seriously.<br>The motivation behind Haskell' was to bring the most common extensions into the standard, it was all going to be done in a year.<br>
Haskell' is not a new language, but growing Haskell98 with common extension.<br>If there's something in Haskell' that will require a change every 1000 lines, then I think it's acceptable.<br>If there's something in Haskell' that will require changing every other line, then it's not acceptable. The existing Haskell codes bases are simply too big.<br>
<br>So I still think changing $ is insane. Why change? If you want a new operator, make a new one. Don't make a gratuitous change that will waste countless man hours. For me it's a simple decision, if $ changes I cannot use Haskell'. :(<br>
<br> -- Lennart<br><br><div class="gmail_quote">On Wed, Apr 23, 2008 at 9:42 PM, Niklas Broberg <<a href="mailto:niklas.broberg@gmail.com">niklas.broberg@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
When I first saw this thread, my gut response was "Aw gawds no, don't<br>
touch my $ !!" I love $, I use it all the time, it really helps making<br>
code more readable and more nicely structured. I would really hate for<br>
someone to take that away from me.<br>
<br>
So when I came across this:<br>
<div class="Ih2E3d"><br>
> > This wouldn't work, you'd have to rewrite it as:<br>
><br>
> > withSomeResource foo .<br>
> > withSomeOtherThing bar .<br>
> > yetAnotherBlockStructured thing $ ...<br>
><br>
><br>
> it is very inconvenient - we should use either . or $ depending on<br>
> that it's last block or not. imagine all the changes when editing the<br>
> code<br>
<br>
</div>... my initial response to it was yeah, Bulat is right, that's rather<br>
inconsistent, and it would mean a lot of changes when editing (and<br>
it's ugly too!).<br>
<br>
But then I started questioning my own motives. What changes would that<br>
be? Changing a . to a $ if I decided to remove the previous last piece<br>
of the "pipeline"? Doesn't seem too hairy, and I have to do far worse<br>
than that already when refactoring. Inconsistent? Doesn't it actually<br>
make perfect sense that the actual application of the "pipeline" of<br>
functions to some value is handled differently? Like Cale said,<br>
wouldn't it actually be a Good Thing that we treated these things as<br>
composition chains instead of application chains? And I could no<br>
longer defend my own position, and so I started thinking for real.<br>
<br>
Refactoring doesn't become harder with this suggestion - it becomes<br>
easier in general, just as Dan points out in #1. And I know I've been<br>
bitten by his #2 a bunch of times, even if I haven't realized the<br>
source of the problem until I read this thread. It's messy having to<br>
use a lot of parenthesis just because some argument to a function<br>
isn't the last one, and I've found myself wishing for a way to get rid<br>
of them. I know I have at times refactored my function definitions,<br>
switching their arguments around just to get the one that would need<br>
the parenthesis to be the last one.<br>
<br>
So I dug through some of my code, picking large modules at random. As<br>
I said I use $ *a lot*, anywhere that I can get away with it. In the<br>
first 10 modules I looked at, I found one (1) place where I would need<br>
to change a $ to a . to make it work. So I went to look at a bigger<br>
module, and in what is possibly my largest self-contained module (1800<br>
loc including comments) I had 211 uses of $, and I would have had to<br>
change 23 of them into . instead to make it work with a<br>
left-associative version. All the ones where the left operand is just<br>
a function (like return) will still work. All the ones that are<br>
followed by a '\x -> ...' will still work. All the ones followed by a<br>
'do ...' will still work. On the other hand, I found 10 places where I<br>
could immediately have gotten rid of some extra parentheses, and that<br>
just by searching for uses of fmap in the code!<br>
<br>
It should be said though that changing the associativity of $ doesn't<br>
make all code nice and clean. Consider for instance<br>
<br>
f (g (h x)) (k y)<br>
<br>
We could change that into one of<br>
<br>
f $ g (h x) $ k y<br>
f (g $ h x) $ k y<br>
<br>
but not get rid of the parenthesis altogether, i.e. uses of $ for<br>
different applications won't mix. But with right-associative $, the<br>
second one would be our only option, so at least we're no worse off<br>
than before, and perhaps it could be argued we are better off (in this<br>
kind of situation).<br>
<br>
<br>
I think it is reasonable to look closely at the motivations for<br>
wanting to retain the $ as is. Looking through this thread, I can find<br>
only a single complaint raised (albeit an important one), namely<br>
backwards compatibility. Yes, such a change would likely break quite a<br>
few my modules. But like Cale, I would never have expected H' to be<br>
fully backwards compatible with H98, and thus there would have to be<br>
some way to migrate anyway. This one seems pretty simple, just let the<br>
old Prelude be Haskell98.Prelude and import that in old code. Of<br>
course changes that break backwards compatibility should not be made<br>
frivolously, but I find it hard to buy having only that as an argument<br>
for a change that otherwise seems highly reasonable.<br>
<br>
We live in a beautiful statically typed world. If the proposed change<br>
was such that existing code would still compile, but with a different<br>
behavior, it would be really dangerous. That's clearly not the case<br>
here, there's no way that code that uses $-chaining would still<br>
compile if the associativity was changed, and any other use of $ would<br>
still compile and work as before. The type checker is there to help<br>
us, and it's literally a moment's work to clean up existing code to<br>
meet these standards. (And it's even faster to import<br>
Haskell98.Prelude if you're lazy).<br>
<br>
So come on, give me an argument for why $ should be right-associative<br>
instead of complaining about broken code (that I argue won't break<br>
even half as bad as some of you would have it). Is there really no<br>
reason at all why right-associative is to be preferred over<br>
left-associative? And if there is, why don't we hear it? Are you truly<br>
arguing this because you think there's a problem with left-associative<br>
$, or are you simply arguing because you want to stay with what you're<br>
used to?<br>
<br>
"The ability to think differently today from yesterday distinguishes<br>
the wise man from the stubborn." - John Steinbeck<br>
<br>
Cheers,<br>
<font color="#888888"><br>
/Niklas<br>
</font><br>
<br>
ps. Though to be honest I really don't see why we don't simply add<br>
another operator instead of changing an existing one... :-)<br>
<div><div></div><div class="Wj3C7c">_______________________________________________<br>
Haskell-prime mailing list<br>
<a href="mailto:Haskell-prime@haskell.org">Haskell-prime@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/haskell-prime" target="_blank">http://www.haskell.org/mailman/listinfo/haskell-prime</a><br>
</div></div></blockquote></div><br>