ndmitchell:
Hi
I think it is reasonable to look closely at the motivations for wanting to retain the $ as is. Looking through this thread, I can find only a single complaint raised (albeit an important one), namely backwards compatibility. Yes, such a change would likely break quite a few my modules. But like Cale, I would never have expected H' to be fully backwards compatible with H98, and thus there would have to be some way to migrate anyway. This one seems pretty simple, just let the old Prelude be Haskell98.Prelude and import that in old code. Of course changes that break backwards compatibility should not be made frivolously, but I find it hard to buy having only that as an argument for a change that otherwise seems highly reasonable.
I don't want to have to do a brain mode-change between "in a Haskell98.Prelude" module and "in a Prelude" module. I don't want to copy code between modules and have it do different things.
We also should remember that a large number of academic papers are written in Haskell, and unlike libraries, don't get "update releases" made. This is not a minor tweak - it will break a massive number of programs.
ps. Though to be honest I really don't see why we don't simply add another operator instead of changing an existing one... :-)
(£) anyone?* This seems a massively more sensible idea.
I'm very suspicious about the power/weight ratio of this change. Normally, for simple value-level stuff like this, provide both options: mapM / forM. =<< >>= So how about, rather than break things, just provide an alternative to ($). -- Don