Am Mittwoch, 23. April 2008 01:20 schrieb Duncan Coutts:

[…]

Surely there was a justification to having $ be the opposite associativity from application and not just a different precedence. Does anyone know what it was?

Probably the fact that you can write

f $ g $ h $ u $ v $ w $ x

instead of

f (g (h (u (v (w x)))))

and thereby avoid building forests of parantheses.

Duncan

Best wishes, Wolfgang

Hi Chris,

...

* add ""Make $ left associative, like application"

Is there a justification for this somewhere? 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.

From the patch:

+ ,Issue "Make $ left associative, like application" [] + Undecided + Prelude i.e. its Undecided - not accepted. Like you, I would be mildly enraged if someone broke 100's of projects of mine simultaneously. Thanks Neil

marlowsd:

Chris Smith wrote:

...

On Tue, 22 Apr 2008 15:53:39 -0700, Simon Marlow wrote:

...

Tue Apr 22 15:53:31 PDT 2008 Simon Marlow * add ""Make $ left associative, like application"

Is there a justification for this somewhere?

I'm hoping someone will supply some. There seemed to be strong opinion on #haskell that this change should be made, but it might just have been a very vocal minority.

It's just Cale. -- Don

On Tuesday 22 April 2008, Simon Marlow wrote:

I'm hoping someone will supply some. There seemed to be strong opinion on #haskell that this change should be made, but it might just have been a very vocal minority.

These are the arguments off the top of my head: 1) Anything of the form: f $ g $ h $ x with right associative ($) can instead be written: f . g . h $ x where the associativity of ($) doesn't matter. It's not uncommon to want to peel off the end of such a pipeline to eliminate a point. For the second form, such a translation is: \x -> f . g . h $ x ==> f . g . h However: \x -> f $ g $ h $ x ==> f $ g $ h Is invalid, so one might argue that writing such pipelines with composition is a better habit to get into, as it allows easier cleanup of code in this way (if you like somewhat point-free code, that is). 2) Left associative ($) allows you to eliminate more parentheses. Per #1, any parentheses eliminated by right associative ($) can be eliminated by (.) and a single ($). However, left associative ($) allows, for instance: f (g x) (h y) ==> f $ g x $ h y 3) Left associative ($) is consistent with left associative ($!). The right associative version of the latter is inconvenient, because it only allows things to be (easily) strictly applied to the last argument of a function. Needing to strictly apply to other arguments gives rise to things like: (f $! x) y z ((f $! x) $! y) $! z Left associative, these are: f $! x $ y $ z f $! x $! y $! z There may be more arguments, but those are the ones I've heard that I can think of at the moment. #3 strikes me as the most likely to bite people (the other two are more stylistic issues), but I suppose I don't know the relative frequency of strict pipelines (f $! g $! x) versus strict applications at non-final arguments. And I suppose one has to weigh these arguments against breaking lots of code. Cheers, -- Dan

Duncan Coutts wrote:

On Tue, 2008-04-22 at 21:02 -0400, Dan Doel wrote:

...

3) Left associative ($) is consistent with left associative ($!). The right associative version of the latter is inconvenient, because it only allows things to be (easily) strictly applied to the last argument of a function.

What about having ! as a left associative strict apply operator?

f !x !y !z

Isn't there already a proposal along these lines? There is certainly a proposal to stop using ! for array indexing.

The problem with this is that f !x y would associate differently in an expression than it does on the left hand side of an equation, where ! is the prefix bang-pattern operator. To make this consistent we'd have to make ! a prefix operator in expressions, or give it the same precedence as function application; both mean a new extension. Cheers, Simon

On Wed, Apr 23, 2008 at 09:52:11AM -0700, Simon Marlow wrote:

The problem with this is that

f !x y

would associate differently in an expression than it does on the left hand side of an equation, where ! is the prefix bang-pattern operator. To make this consistent we'd have to make ! a prefix operator in expressions, or give it the same precedence as function application; both mean a new extension.

Hmm.. that is another possible solution to the ~ ! - thing, have ~ and ! be prefix operators in general. with ~ meaning 'negate' in expressions. then parsing is the same everywhere. John -- John Meacham - ⑆repetae.net⑆john⑈

First I would like to remind everyone of Wadler's law of language design: http://www.haskell.org/haskellwiki/Wadlers_Law Having said that I'm now going to argue for yet another color for the bike shed. I was a little surprised by the list of motivations for changing the fixity of $ because it didn't contain the one argument I was in fact expecting to hear. 0) $ was introduced as a combinator for function application. Therefore we might expect that whenever we have a function application we can stick a $ in there. But this is not the case. Consider the following expression: f x y There are two applications here and if $ behaved like function application we would be able to write: f $ x $ y But as it is now this expression means something completely different. I expected this discrepancy between function application and $ to be the major reason for changing the fixity. That being said, this change would break a lot of my code as well and I'm not a big fan of it. Cheers, Josef On Wed, Apr 23, 2008 at 3:02 AM, Dan Doel wrote:

On Tuesday 22 April 2008, Simon Marlow wrote:

...

I'm hoping someone will supply some. There seemed to be strong opinion on #haskell that this change should be made, but it might just have been a very vocal minority.

These are the arguments off the top of my head:

1) Anything of the form:

f $ g $ h $ x

with right associative ($) can instead be written:

f . g . h $ x

where the associativity of ($) doesn't matter. It's not uncommon to want to peel off the end of such a pipeline to eliminate a point. For the second form, such a translation is:

\x -> f . g . h $ x ==> f . g . h

However:

\x -> f $ g $ h $ x ==> f $ g $ h

Is invalid, so one might argue that writing such pipelines with composition is a better habit to get into, as it allows easier cleanup of code in this way (if you like somewhat point-free code, that is).

2) Left associative ($) allows you to eliminate more parentheses. Per #1, any parentheses eliminated by right associative ($) can be eliminated by (.) and a single ($). However, left associative ($) allows, for instance:

f (g x) (h y) ==> f $ g x $ h y

3) Left associative ($) is consistent with left associative ($!). The right associative version of the latter is inconvenient, because it only allows things to be (easily) strictly applied to the last argument of a function. Needing to strictly apply to other arguments gives rise to things like:

(f $! x) y z ((f $! x) $! y) $! z

Left associative, these are:

f $! x $ y $ z f $! x $! y $! z

There may be more arguments, but those are the ones I've heard that I can think of at the moment. #3 strikes me as the most likely to bite people (the other two are more stylistic issues), but I suppose I don't know the relative frequency of strict pipelines (f $! g $! x) versus strict applications at non-final arguments.

And I suppose one has to weigh these arguments against breaking lots of code.

Cheers, -- Dan

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

2008/4/23 apfelmus :

Dan Doel wrote:

Note that setting (.) or ($) = fmap subsumes function application, because we have

fmap :: (a -> b) -> a -> b

for the /identity functor/. In other words, the current ($) and (.) are just special cases of the general fmap . Unfortunately, the identity functor currently can't be overloaded, although I think it would be unambiguous.

Unfortunately, it would be quite ambiguous -- the identity functor overlaps with basically any other. Consider the case: reverse . [[1,2,3],[4,5]] which if (.) is fmap would normally mean [[3,2,1],[5,4]], but if the identity functor is used instead would mean [[4,5],[1,2,3]]. - Cale

Dan Doel wrote:

On Tuesday 22 April 2008, Simon Marlow wrote:

...

I'm hoping someone will supply some. There seemed to be strong opinion on #haskell that this change should be made, but it might just have been a very vocal minority.

These are the arguments off the top of my head:

Thanks, I've put these points, and Josef's point, on the wiki: http://hackage.haskell.org/trac/haskell-prime/wiki/ChangeDollarAssociativity (I should point out that I'm personally *not* in favour of this change, just making sure the arguments are documented) Cheers, Simon

Hello Lennart, Wednesday, April 23, 2008, 11:38:50 PM, you wrote:

Just pick some other (Unicode?) operator, but leave $ alone.

good said. i have my own version of &&/|| which i love more but they are called &&&/||| -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

On 2008-04-22, Simon Marlow 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? -- Aaron Denney -><-

Hello Cale, Wednesday, April 23, 2008, 10:54:06 AM, you wrote:

By the way, as Don suggests, I do strongly advocate this change, and

i agree that the change by itself is reasonable, but fixing all the old issues and providing new beautiful language version should be project of its own. for example, i will propose raising precedences when there are no spaces around operator. this will significantly reduce amount of parentheses/$s: f a+b c*d f g(x) h(y) for now, wee need to standardize current haskell practice just for compilers interoperability and teaching purposes (noone wants to write book about ghc 6.8 or teach students to it) -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

Hello Cale, Wednesday, April 23, 2008, 11:26:49 AM, you wrote:

f x+y = (x+y)^2

f x + y = x^2 + y

imho, it's easy to see what there are no spaces around + on first line, but there are spaces at the second. imho, it's just our habits - ignore spaces and split expression by operators actually, shift from usual style of f(x+y,z*t) to f (x+y) (z*t) was no less dramatic. i propose to go one step further and use spaces instead of brackets as one more way to control precedence. this idea born from my haskell programming practice - these additional parentheses are rather common and avoiding them will make program reading easier. but it needs to shift habits

That's a pretty hard to see bug, and it sneaks right past the typechecker. I'm all for a certain amount of whitespace sensitivity, but that might be going too far.

my main point is that considering space-less operators as having larger priority is our natural habit. consider this: f a*b x+c imho, my interpretation of this expression sounds more natural than haskell's current one

...

for now, wee need to standardize current haskell practice just for compilers interoperability and teaching purposes (noone wants to write book about ghc 6.8 or teach students to it)

Well, my point is that if we can see these changes that we want to make to the libraries, it makes little sense to let people write those books and then change all the libraries out from under them a few months down the road. Maybe it's what we'll end up doing anyway, but it's worth considering.

unfortunately, it will be not a few months. there are many important things we may change in haskell. sometime ago it was said that haskell' will just standartize existing haskell (ghc/hugs) state and haskell 2 will be new, probably incompatible language. fixing just one oddity in haskell' will give us worst of both worlds - broken compatibility and lots of oddities still remaining -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

but it also seems not to make much sense to standardise a Prelude which people strongly want to change.

I'm strongly against this change, both on its own merits - in most cases when there is a real argument being passed, I find chains of $s easier to think about than your alternative - but most importantly because it would be enormously disruptive. It's the kind of completely unnecessary thing that simply lends ammunition to the people that claim Haskell is an academic language unsuited to the real world.

Also, the Haskell 98 Prelude has already been reported on, and probably should continue to be supported in some way or another.

How would you propose supporting multiple preludes at once? I have a feeling most of the pieces are in place and it's just a question of documenting the "best practice" properly, but it needs to be done and we need to get experience with doing it and with a gradual migration strategy before we even consider this kind of change. Ganesh ============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ==============================================================================

I believe that migrating code will be quite a task regardless of the outcome here,

NonDecreasing indentation and the removal of n+k patterns are the only accepted proposals I can see that might affect existing code. The former is already standard practice and the latter is unlikely to be that disruptive, as their use has been discouraged for some time.

but at least for the packages that are in Hackage, the system helpfully reports build failures, so we'll know where the breakages are, and roughly what's left to be done.

There's plenty of code out there that doesn't have the benefit of a vigilant user community ready to spring into action. For example, Credit Suisse has several tens of thousands of lines of code written by internal users who are not Haskell experts, and it would be rather hard to explain to them that they needed to go through it all and fix it. Ganesh ============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ==============================================================================

Aaron Denney wrote:

On 2008-04-23, Sittampalam, Ganesh wrote:

...

There's plenty of code out there that doesn't have the benefit of a vigilant user community ready to spring into action. For example, Credit Suisse has several tens of thousands of lines of code written

...

by internal users who are not Haskell experts, and it would be rather hard to explain to them that they needed to go through it all and fix it.

What makes them need to update to Haskell' instead of sticking with Haskell '98?

(a) the fact that the code already uses several GHC extensions that will be in Haskell' and we would like to be closer to standard code (b) the expectation that at some point implementations will stop supporting H98 Is there not a general expectation when a new language standard comes out that people will migrate to it (perhaps over time)? Ganesh ============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ==============================================================================

Sittampalam, Ganesh:

Aaron Denney wrote:

...

On 2008-04-23, Sittampalam, Ganesh wrote:

...

There's plenty of code out there that doesn't have the benefit of a vigilant user community ready to spring into action. For example, Credit Suisse has several tens of thousands of lines of code written

...

...

by internal users who are not Haskell experts, and it would be rather hard to explain to them that they needed to go through it all and fix it.

...

What makes them need to update to Haskell' instead of sticking with Haskell '98?

(a) the fact that the code already uses several GHC extensions that will be in Haskell' and we would like to be closer to standard code (b) the expectation that at some point implementations will stop supporting H98

Care for legacy code is important, but H' will have to break backwards compatibility in some places. And especially where you already rely on GHC extensions, you can't really expect that H' will adopt features that have been available as GHC extensions in exactly the form that they were implemented in GHC. We should be careful about where we break existing code, and we should try to support automatic translation of H98 to H' code, but any changes that we do not make now will become even more difficult in the future when there is even more Haskell code. Look at what is happening now already, industrial users applying pressure on the committee to not change the language too much for the sake of legacy code. A clear indication that anything we don't change now, we will have to live with forever. Hence, anything that is *important* to change, we should change now. We should mitigate the pain by having a H98 to H' translator and Haskell compilers will surely support a Haskell98 compatibility mode as long as there are enough users interested in such a feature. (This is not unlike the transition from K&R C to ANSI C.) Manuel

Sittampalam, Ganesh:

Manuel Chakravarty wrote:

...

We should be careful about where we break existing code, and we should try to support automatic translation of H98 to H' code, but any changes that we do not make now will become even more difficult in the future when there is even more Haskell code. Look at what is happening now already, industrial users applying pressure on the committee to not change the language too much for the sake of legacy code. A clear indication that anything we don't change now, we will have to live with forever.

I wasn't arguing for special treatment as an "industrial" user, just listing one datapoint that I have to counter any impression that the only or main cost to the community as a whole is fixing what's on hackage.

I agree with that. However, maybe somewhat paradoxically, I think, given the resistance that changes to the language already invoke now, we should actually be fairly aggressive with changes this one time (ie, in Haskell').

...

Hence, anything that is *important* to change, we should change now.

Agreed. It's just in this case the pain of changing will be huge and the benefits marginal at best.

Yes, I was not arguing for that particular change, my comment was of a general nature.

...

We should mitigate the pain by having a H98 to H' translator

Such a translator would have to maintain existing layout etc, and produce reasonably nice looking code in places where it makes changes. Do we have any infrastructure that would make writing one easy?

For H98, simple[1] changes might be possible with haskell-src if it would be modified to be able to preserve comments and layout. Manuel [1] For example, purely syntactic ones.

Am Donnerstag, 24. April 2008 05:13 schrieb Manuel M T Chakravarty:

[…]

Hence, anything that is *important* to change, we should change now.

Although I can follow your arguments, I thought that the large and disruptive changes should be done for Haskell 2. If they should really be done now, we should also fix a lot of other things. For example, the Num hierarchy, the Functor/Applicative/Monad hierarchy, the fact that there exist Alternative and MonadPlus although we have Monoid, the fact that we cannot have contexts like (forall a. Monoid (m a)) which is the source for the last problem, the fact that we don’t have class aliases, ugly names like fmap and mappend, etc.

[…]

Manuel

Best wishes, Wolfgang

Am Montag, 28. April 2008 06:29 schrieben Sie:

Wolfgang Jeltsch:

...

Am Donnerstag, 24. April 2008 05:13 schrieb Manuel M T Chakravarty:

...

[…]

Hence, anything that is *important* to change, we should change now.

Although I can follow your arguments, I thought that the large and disruptive changes should be done for Haskell 2.

Depends what you mean by Haskell 2. If it is an experimental language that shares some superficial similarities with Haskell, sure we may have Haskell 2. If you mean a serious successor of Haskell with the expectation that many/most Haskell users will eventually move to Haskell 2, then no. Haskell has been gaining a lot of momentum recently. That's good and bad, but surely makes it hard to change the trajectory. (This is, of course, just my personal opinion.)

...

If they should really be done now, we should also fix a lot of other things. For example, the Num hierarchy, the Functor/Applicative/Monad hierarchy, the fact that there exist Alternative and MonadPlus although we have Monoid, the fact that we cannot have contexts like (forall a. Monoid (m a)) which is the source for the last problem, the fact that we don’t have class aliases, ugly names like fmap and mappend, etc.

As Lennart and Ganesh have argued, the amount of breaking changes that we we will be able to fit in without causing serious problems is limited.

Manuel

Hello again (after a long time), the things I proposed above are mostly library changes which could mostly be made non-disruptive if we had class aliases. Would this make them acceptable for you? Best wishes, Wolfgang

Hi

How would you propose supporting multiple preludes at once?

Unhappy. The Haskell Prelude is more than just a standard library. Things like $, ., otherwise, >>= etc would be keywords in any other language. As such, you expect their meaning to be consistent. If you let other people define other Preludes you get very confused very quickly. I can just imagine otherwise = False sneaking in somewhere! I don't want to have to edit code and when I look at $ think "did Cale modify this code at any point in the past" :-) Thanks Neil

On Wed, Apr 23, 2008 at 09:32:11AM +0400, Bulat Ziganshin wrote:

...

I'm hoping someone will supply some. There seemed to be strong opinion on #haskell that this change should be made, but it might just have been a very vocal minority.

i think this is some misinterpretation. haskell-prime should be, afaik, simple standardization of current software practices, more or less common subset of ghc/hugs language extensions. in particular, it should keep almost full bwd compatibility with H98 standard. it was haskell-2 to break up old things and build new perfect language from ground

Haskell' will not be fully Haskell 98 compatible. But it won't break things too much hopefully. And no doubt compilers will have strategies for mixing h98 and h' code. John -- John Meacham - ⑆repetae.net⑆john⑈

Hello John, Wednesday, April 23, 2008, 9:41:22 AM, you wrote:

...

i think this is some misinterpretation. haskell-prime should be, afaik, simple standardization of current software practices, more or less common subset of ghc/hugs language extensions.

Haskell' will not be fully Haskell 98 compatible.

in particular, h' should break H98 compatibility no more that existing ghc/hugs versions -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

On Wednesday 23 April 2008, Duncan Coutts wrote:

withSomeResource foo $ withSomeOtherThing bar $ yetAnotherBlockStructured thing $ ...

Does that work?

This wouldn't work, you'd have to rewrite it as: withSomeResource foo . withSomeOtherThing bar . yetAnotherBlockStructured thing $ ... But it seems like your second example is more likely to come up for 'with' type blocks:

Or

withSomeResource foo $ \x -> withSomeOtherThing bar $ \y -> yetAnotherBlockStructured thing $ \z ->

That should work, because '\x ->' extends to the end of the expression. Similarly: iWantMonadicValues $ do foo bar iAlsoWantMonadicStuff $ do ... still works. -- Dan

On Wednesday 23 April 2008, Bulat Ziganshin wrote:

Hello Dan,

Wednesday, April 23, 2008, 1:42:20 PM, you wrote:

...

This wouldn't work, you'd have to rewrite it as:

withSomeResource foo . withSomeOtherThing bar . yetAnotherBlockStructured thing $ ...

it is very inconvenient - we should use either . or $ depending on that it's last block or not. imagine all the changes when editing the code

Well, that may be inconvenient, but I don't know how much such block structured code is actually a composition of such functions. Off the top of my head, I'd expect most to involve lambdas or dos: forM l $ \e -> ... State $ \s -> ... (see also Reader, Cont, ...) runST $ do ... (or 'flip runM arg' for most monads, I suppose) callCC $ \k -> ... (shift) forever $ do ... withResource $ \r -> ... local f $ do ... Which still work with the flipped associativity. The one oddity I noticed looking at random code of mine is reset in Cont(T), which might currently be used like: reset $ forM l $ \e -> ... for inverting loops. It would have to become: reset . forM l $ \e -> ... Which might be a little weird (of course, in CC-delcont, that's reset $ \p -> forM l $ \e -> ... so it's moot there, but I suppose this affects all the functions that rely on 'do' to use repeated ($)s). My code may well be abnormal, though (certainly, my infatuation with continuations probably is :)). When I do have composition pipelines that don't fit on one line (like the initial example), I think I tend to write them like this: pipe = foo . bar . baz . quux $ quuux Which lets you slip new things in pretty naturally, I think. There may be a lot of code out there that that all doesn't work for, though. I don't know. -- Dan

Hello Niklas, Thursday, April 24, 2008, 12:42:02 AM, you wrote:

But then I started questioning my own motives. What changes would that be? Changing a . to a $ if I decided to remove the previous last piece of the "pipeline"? Doesn't seem too hairy, and I have to do far worse than that already when refactoring.

it's not refactoring! it's just adding more features - exception handler, progress indicator, memory pool and so on. actually, code blocks used as a sort of RAII for Haskell. are you wanna change all those ';' when you add new variable to your C++ code? bracketCtrlBreak (archiveReadFooter command arcname) (archiveClose.fst) $ \(archive,footer) -> do bad_crcs <- withList $ \bad_crcs -> do doChunks arcsize sector_size $ \bytes -> do uiWithProgressIndicator command arcsize $ do or handleCtrlBreak (ignoreErrors$ fileRemove arcname_fixed) $ do bracketCtrlBreak (archiveCreateRW arcname_fixed) (archiveClose) $ \new_archive -> do withJIT (fileOpen =<< originalURL originalName arcname) fileClose $ \original' -> do is just two examples from my code -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

On Wednesday 23 April 2008, Bulat Ziganshin wrote:

it's not refactoring! it's just adding more features - exception handler, progress indicator, memory pool and so on. actually, code blocks used as a sort of RAII for Haskell. are you wanna change all those ';' when you add new variable to your C++ code?

bracketCtrlBreak (archiveReadFooter command arcname) (archiveClose.fst) $ \(archive,footer) -> do bad_crcs <- withList $ \bad_crcs -> do doChunks arcsize sector_size $ \bytes -> do uiWithProgressIndicator command arcsize $ do or handleCtrlBreak (ignoreErrors$ fileRemove arcname_fixed) $ do bracketCtrlBreak (archiveCreateRW arcname_fixed) (archiveClose) $ \new_archive -> do withJIT (fileOpen =<< originalURL originalName arcname) fileClose $ \original' -> do

is just two examples from my code

For what it's worth, both of these examples require no change. However, with left-associative ($), you're free to change them to (sorry for the additional lines, but my mail client breaks at 80 characters. I think they're still valid code): bracketCtrlBreak $ archiveReadFooter command arcname $ archiveClose.fst $ \(archive,footer) -> do bad_crcs <- withList $ \bad_crcs -> do doChunks arcsize sector_size $ \bytes -> do uiWithProgressIndicator command arcsize $ do handleCtrlBreak $ ignoreErrors (fileRemove arcname_fixed) $ do bracketCtrlBreak $ archiveCreateRW arcname_fixed $ archiveClosed $ \new_archive -> do withJIT $ fileOpen =<< originalURL originalName arcname $ fileClose $ \original' -> do Or, for a simpler example I discovered earlier, you can write: catchError $ do return 1 throwError $ strError "foo" $ \e -> return 2 Although I'm not sure how much better that is than the alternative: do return 1 throwError $ strError "foo" `catchError` \e -> return 2 -- Dan

2008/4/23 Neil Mitchell :

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.

How many research papers have you seen which use chained ($) applications? I can't recall a single one. - Cale

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

On Thu, Apr 24, 2008 at 12:21:26AM +0200, Niklas Broberg wrote:

...

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 ($).

Alright, I'm not sure what the proper channel for doing this is,

Please see http://www.haskell.org/haskellwiki/Library_submissions

f $$ x = f x

Note that this clashes with Text.PrettyPrint (which doesn't necessarily mean it shouldn't be used anyway). Thanks Ian

On Thu, Apr 24, 2008 at 09:38:22PM +0200, Wolfgang Jeltsch wrote:

Am Donnerstag, 24. April 2008 00:43 schrieb Ian Lynagh:

...

[…]

...

Please see http://www.haskell.org/haskellwiki/Library_submissions

...

f $$ x = f x

Note that this clashes with Text.PrettyPrint

I also doesn’t correspond to $!. We should introduce $$! then.

I don't think either of these are necessary and eat up valuable operator-space. John -- John Meacham - ⑆repetae.net⑆john⑈

I think there are some very valid concerns about this proposal, but just to add a small datapoint -- the associativity of $ was somewhat painful and counterintuitive to me when I was first learning Haskell, and the associativity of $! doubly so. Code breakage issues aside, this seems very much the "right thing" to do. Haskell will *necessarily evolve* in a backwards-incompatible way at some point, with the move from Functional Dependencies. And meanwhile, changes to things such as the ByteString API have been taking place and causing breakage now for some time (although hopefully we've seen about the last of that). So the bigger issue seems to be -- if not Haskell', then when, precisely should a number of other issues with the core libraries be addressed, or should we let some things stay set in stone, even while other compatibility- breaking changes occur all around them? --S On Apr 23, 2008, at 4:42 PM, Niklas Broberg wrote:

When I first saw this thread, my gut response was "Aw gawds no, don't touch my $ !!" I love $, I use it all the time, it really helps making code more readable and more nicely structured. I would really hate for someone to take that away from me.

So when I came across this:

...

...

This wouldn't work, you'd have to rewrite it as:

...

withSomeResource foo . withSomeOtherThing bar . yetAnotherBlockStructured thing $ ...

it is very inconvenient - we should use either . or $ depending on that it's last block or not. imagine all the changes when editing the code

... my initial response to it was yeah, Bulat is right, that's rather inconsistent, and it would mean a lot of changes when editing (and it's ugly too!).

But then I started questioning my own motives. What changes would that be? Changing a . to a $ if I decided to remove the previous last piece of the "pipeline"? Doesn't seem too hairy, and I have to do far worse than that already when refactoring. Inconsistent? Doesn't it actually make perfect sense that the actual application of the "pipeline" of functions to some value is handled differently? Like Cale said, wouldn't it actually be a Good Thing that we treated these things as composition chains instead of application chains? And I could no longer defend my own position, and so I started thinking for real.

Refactoring doesn't become harder with this suggestion - it becomes easier in general, just as Dan points out in #1. And I know I've been bitten by his #2 a bunch of times, even if I haven't realized the source of the problem until I read this thread. It's messy having to use a lot of parenthesis just because some argument to a function isn't the last one, and I've found myself wishing for a way to get rid of them. I know I have at times refactored my function definitions, switching their arguments around just to get the one that would need the parenthesis to be the last one.

So I dug through some of my code, picking large modules at random. As I said I use $ *a lot*, anywhere that I can get away with it. In the first 10 modules I looked at, I found one (1) place where I would need to change a $ to a . to make it work. So I went to look at a bigger module, and in what is possibly my largest self-contained module (1800 loc including comments) I had 211 uses of $, and I would have had to change 23 of them into . instead to make it work with a left-associative version. All the ones where the left operand is just a function (like return) will still work. All the ones that are followed by a '\x -> ...' will still work. All the ones followed by a 'do ...' will still work. On the other hand, I found 10 places where I could immediately have gotten rid of some extra parentheses, and that just by searching for uses of fmap in the code!

It should be said though that changing the associativity of $ doesn't make all code nice and clean. Consider for instance

f (g (h x)) (k y)

We could change that into one of

f $ g (h x) $ k y f (g $ h x) $ k y

but not get rid of the parenthesis altogether, i.e. uses of $ for different applications won't mix. But with right-associative $, the second one would be our only option, so at least we're no worse off than before, and perhaps it could be argued we are better off (in this kind of situation).

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.

We live in a beautiful statically typed world. If the proposed change was such that existing code would still compile, but with a different behavior, it would be really dangerous. That's clearly not the case here, there's no way that code that uses $-chaining would still compile if the associativity was changed, and any other use of $ would still compile and work as before. The type checker is there to help us, and it's literally a moment's work to clean up existing code to meet these standards. (And it's even faster to import Haskell98.Prelude if you're lazy).

So come on, give me an argument for why $ should be right-associative instead of complaining about broken code (that I argue won't break even half as bad as some of you would have it). Is there really no reason at all why right-associative is to be preferred over left-associative? And if there is, why don't we hear it? Are you truly arguing this because you think there's a problem with left-associative $, or are you simply arguing because you want to stay with what you're used to?

"The ability to think differently today from yesterday distinguishes the wise man from the stubborn." - John Steinbeck

Cheers,

/Niklas

ps. Though to be honest I really don't see why we don't simply add another operator instead of changing an existing one... :-) _______________________________________________ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime

Haskell has now reached the point where backwards compatibility is something that must be taken very seriously. The motivation behind Haskell' was to bring the most common extensions into the standard, it was all going to be done in a year. Haskell' is not a new language, but growing Haskell98 with common extension. If there's something in Haskell' that will require a change every 1000 lines, then I think it's acceptable. 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. 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'. :( -- Lennart On Wed, Apr 23, 2008 at 9:42 PM, Niklas Broberg wrote:

When I first saw this thread, my gut response was "Aw gawds no, don't touch my $ !!" I love $, I use it all the time, it really helps making code more readable and more nicely structured. I would really hate for someone to take that away from me.

So when I came across this:

...

...

This wouldn't work, you'd have to rewrite it as:

...

withSomeResource foo . withSomeOtherThing bar . yetAnotherBlockStructured thing $ ...

it is very inconvenient - we should use either . or $ depending on that it's last block or not. imagine all the changes when editing the code

... my initial response to it was yeah, Bulat is right, that's rather inconsistent, and it would mean a lot of changes when editing (and it's ugly too!).

But then I started questioning my own motives. What changes would that be? Changing a . to a $ if I decided to remove the previous last piece of the "pipeline"? Doesn't seem too hairy, and I have to do far worse than that already when refactoring. Inconsistent? Doesn't it actually make perfect sense that the actual application of the "pipeline" of functions to some value is handled differently? Like Cale said, wouldn't it actually be a Good Thing that we treated these things as composition chains instead of application chains? And I could no longer defend my own position, and so I started thinking for real.

Refactoring doesn't become harder with this suggestion - it becomes easier in general, just as Dan points out in #1. And I know I've been bitten by his #2 a bunch of times, even if I haven't realized the source of the problem until I read this thread. It's messy having to use a lot of parenthesis just because some argument to a function isn't the last one, and I've found myself wishing for a way to get rid of them. I know I have at times refactored my function definitions, switching their arguments around just to get the one that would need the parenthesis to be the last one.

So I dug through some of my code, picking large modules at random. As I said I use $ *a lot*, anywhere that I can get away with it. In the first 10 modules I looked at, I found one (1) place where I would need to change a $ to a . to make it work. So I went to look at a bigger module, and in what is possibly my largest self-contained module (1800 loc including comments) I had 211 uses of $, and I would have had to change 23 of them into . instead to make it work with a left-associative version. All the ones where the left operand is just a function (like return) will still work. All the ones that are followed by a '\x -> ...' will still work. All the ones followed by a 'do ...' will still work. On the other hand, I found 10 places where I could immediately have gotten rid of some extra parentheses, and that just by searching for uses of fmap in the code!

It should be said though that changing the associativity of $ doesn't make all code nice and clean. Consider for instance

f (g (h x)) (k y)

We could change that into one of

f $ g (h x) $ k y f (g $ h x) $ k y

but not get rid of the parenthesis altogether, i.e. uses of $ for different applications won't mix. But with right-associative $, the second one would be our only option, so at least we're no worse off than before, and perhaps it could be argued we are better off (in this kind of situation).

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.

We live in a beautiful statically typed world. If the proposed change was such that existing code would still compile, but with a different behavior, it would be really dangerous. That's clearly not the case here, there's no way that code that uses $-chaining would still compile if the associativity was changed, and any other use of $ would still compile and work as before. The type checker is there to help us, and it's literally a moment's work to clean up existing code to meet these standards. (And it's even faster to import Haskell98.Prelude if you're lazy).

So come on, give me an argument for why $ should be right-associative instead of complaining about broken code (that I argue won't break even half as bad as some of you would have it). Is there really no reason at all why right-associative is to be preferred over left-associative? And if there is, why don't we hear it? Are you truly arguing this because you think there's a problem with left-associative $, or are you simply arguing because you want to stay with what you're used to?

"The ability to think differently today from yesterday distinguishes the wise man from the stubborn." - John Steinbeck

Cheers,

/Niklas

ps. Though to be honest I really don't see why we don't simply add another operator instead of changing an existing one... :-) _______________________________________________ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime

On Thu, Apr 24, 2008 at 3:41 PM, Wolfgang Jeltsch wrote:

Am Donnerstag, 24. April 2008 09:30 schrieb Lennart Augustsson:

...

Haskell has now reached the point where backwards compatibility is something that must be taken very seriously.

Would you be opposed to a Haskell 2 which would break lots of things?

I would! No new language standard should break lots of things! It could break some things and should provide easy rewrite rules for code (or better yet a tool like Python's 2to3) to move from standard A to standard B for most of the things that break.

Lennart Augustsson:

Haskell has now reached the point where backwards compatibility is something that must be taken very seriously. The motivation behind Haskell' was to bring the most common extensions into the standard, it was all going to be done in a year. Haskell' is not a new language, but growing Haskell98 with common extension. If there's something in Haskell' that will require a change every 1000 lines, then I think it's acceptable. 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.

I completely agree.

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'. :(

Given that people can't even agree whether it makes sense to change $ at all, this is IMHO far away from a change that justifies breaking any code. Manuel

On Mon, Apr 28, 2008 at 6:56 PM, Simon Marlow wrote:

So I suggest we reject the proposal, and move any further discussion to haskell-cafe. Ok?

Sounds good to me.