Re: patch applied (haskell-prime-status): add Make $ left associative, like application
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 ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: patch applied (haskell-prime-status): add Make $ left associative, like application
Manuel M T Chakravarty wrote: Lennart Augustsson: 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. So I suggest we reject the proposal, and move any further discussion to haskell-cafe. Ok? Cheers, Simon ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: patch applied (haskell-prime-status): add Make $ left associative, like application
On Mon, Apr 28, 2008 at 6:56 PM, Simon Marlow [EMAIL PROTECTED] wrote: So I suggest we reject the proposal, and move any further discussion to haskell-cafe. Ok? Sounds good to me. ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: patch applied (haskell-prime-status): add Make $ left associative, like application
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. ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: patch applied (haskell-prime-status): add Make $ left associative, like application
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 [EMAIL PROTECTED] 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
Re: patch applied (haskell-prime-status): add Make $ left associative, like application
Simon Marlow [EMAIL PROTECTED] writes: * add Make $ left associative, like application I'm an end user of Haskell rather than an FP researcher, and I'm very strongly against this change because I don't think of $ as being function application; I think of it as the brackets from here to the end of the expression operator. I've always assumed that it was defined with the associativity it currently has in order to support that use. As it stands, it's one of my favourite features of Haskell. I find it particularly useful when constructing nested data structures; at the moment, it's very easy to write something like: Seq m $ Spec m var $ Only $ ProcCall m name args In that case, $ clearly has the same meaning each time. If I put something like that on a slide, I can explain the meaning of $ in a few seconds, even to an audience who aren't familiar with functional programming or Haskell. Forcing me to change the first two to . would make the code harder to write, harder to understand, and harder to explain. If people want a left-associative application operator, then it ought to be a new operator; please don't change the existing one. -- Adam Sampson [EMAIL PROTECTED] http://offog.org/ ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
RE: patch applied (haskell-prime-status): add Make $ left associative, like application
Manuel Chakravarty wrote: 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. Agreed. I was just motivating why we would want to upgrade code, not arguing that we should be able to do that with no pain at all. 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. 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. 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? Ganesh == Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html == ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: patch applied (haskell-prime-status): add Make $ left associative, like application
On Wed, Apr 23, 2008 at 8:13 PM, Manuel M T Chakravarty [EMAIL PROTECTED] 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. 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 KR C to ANSI C.) For ($), automatic translation could be as simple as changing a couple module imports: import Prelude hiding (($)) import Haskell98 (($)) -- Steven Hazel [EMAIL PROTECTED] ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: patch applied (haskell-prime-status): add Make $ left associative, like application
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 ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: patch applied (haskell-prime-status): add Make $ left associative, like application
Am Mittwoch, 23. April 2008 09:58 schrieb Bulat Ziganshin: […] my main point is that considering space-less operators as having larger priority is our natural habit. Really??? I‘ve never heard of people using spaceless operators for stating precedence before. And it contradicts nice typesetting. In my opinion, an operator needs space around it, otherwise it looks ugly. And I don’t want to have lhs2TeX-typeset source code where infix operators sometimes have the nice TeX spacing and sometimes are not surrounded by spaces at all. […] Best wishes, Wolfgang ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: patch applied (haskell-prime-status): add Make $ left associative, like application
Am Mittwoch, 23. April 2008 10:06 schrieb Cale Gibbard: […] I believe that migrating code will be quite a task regardless of the outcome here, 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. Why not writing a tool which replaces all occurences of a $ b $ c $ d by a . b . c $ d? - Cale Best wishes, Wolfgang ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: patch applied (haskell-prime-status): add Make $ left associative, like application
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. […] Best wishes, Wolfgang ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: patch applied (haskell-prime-status): add Make $ left associative, like application
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? […] Best wishes, Wolfgang ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: patch applied (haskell-prime-status): add Make $ left associative, like application
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⑈ ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: patch applied (haskell-prime-status): add Make $ left associative, like application
On Thu, Apr 24, 2008 at 3:41 PM, Wolfgang Jeltsch [EMAIL PROTECTED] 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. ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: patch applied (haskell-prime-status): add Make $ left associative, like application
Haskell 2 (whatever it is), does not have the goals that were stated for Haskell', so I can accept disruptive changes. Haskell' has (had?) some very clear goals, and breaking every existing program was not one of them. On Thu, Apr 24, 2008 at 8:41 PM, Wolfgang Jeltsch [EMAIL PROTECTED] 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? […] Best wishes, Wolfgang ___ 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: patch applied (haskell-prime-status): add Make $ left associative, like application
On Wed, Apr 23, 2008 at 6:21 PM, Niklas Broberg [EMAIL PROTECTED] 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, but I reckon here is as good as anywhere. I would like to propose that the Haskell' Prelude includes the function f $$ x = f x with the same fixity level as $ (presumably 0) but being left associative instead. And that $ is left as is. It's a pity that @ isn't available for use as an operator. I've seen it used to represent application in a few places, and its resemblance to an a is a handy mnemonic. Is still free? -- Dave Menendez [EMAIL PROTECTED] http://www.eyrie.org/~zednenem/ ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re[2]: patch applied (haskell-prime-status): add Make $ left associative, like application
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, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Re[2]: patch applied (haskell-prime-status): add Make $ left associative, like application
2008/4/23 Bulat Ziganshin [EMAIL PROTECTED]: 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) I'm not sure that I'm convinced about that one -- consider the simple function: f x = x^2 and the two programs: f x+y = (x+y)^2 f x + y = x^2 + y 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. 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. - Cale ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
RE: patch applied (haskell-prime-status): add Make $ left associative, like application
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 == ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re[4]: patch applied (haskell-prime-status): add Make $ left associative, like application
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, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: patch applied (haskell-prime-status): add Make $ left associative, like application
2008/4/23 Sittampalam, Ganesh [EMAIL PROTECTED]: 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. Well, try the alternative for a while. It was a little strange at first for me as well, but once you're used to it, it's extremely natural. I'd argue it even helps your thinking in other places, because you're constantly seeing composition chains (even if you still feel more comfortable thinking of them as application chains for a while), and this exceptionally simple change gets you into the spirit of thinking about functions as values to be combined, not just applied. I would argue that this mindset is an important one for functional programming, and anything which helps usher people toward it is a good thing. 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. I agree that support for this is very important. It would be nice to simply be able to switch between base packages (and perhaps language options, like 98/H') with a single simple flag. I believe that migrating code will be quite a task regardless of the outcome here, 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. - Cale ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: patch applied (haskell-prime-status): add Make $ left associative, like application
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 ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
RE: patch applied (haskell-prime-status): add Make $ left associative, like application
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 == ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: patch applied (haskell-prime-status): add Make $ left associative, like application
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 ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: patch applied (haskell-prime-status): add Make $ left associative, like application
Dan Doel wrote: 3) Left associative ($) is consistent with left associative ($!). (f $! x) y z ((f $! x) $! y) $! z Left associative, these are: f $! x $ y $ z f $! x $! y $! z Nice! Subconsciously, the fact that ($!) is currently not left associative has always bitten me. In the light of Cale's plan to make (.) equivalent to fmap , there is also the option to redefine ($) to mean fmap . This would eliminate the need for a special $ for applicative functors. 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. Regards, apfelmus ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: patch applied (haskell-prime-status): add Make $ left associative, like application
2008/4/23 apfelmus [EMAIL PROTECTED]: 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 ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: patch applied (haskell-prime-status): add Make $ left associative, like application
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 ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: patch applied (haskell-prime-status): add Make $ left associative, like application
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 ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re[2]: patch applied (haskell-prime-status): add Make $ left associative, like application
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, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: patch applied (haskell-prime-status): add Make $ left associative, like application
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
Re: patch applied (haskell-prime-status): add Make $ left associative, like application
On 2008-04-23, Sittampalam, Ganesh [EMAIL PROTECTED] 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? -- Aaron Denney -- ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re[2]: patch applied (haskell-prime-status): add Make $ left associative, like application
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, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Re[2]: patch applied (haskell-prime-status): add Make $ left associative, like application
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 ... and neither of those examples would be broken by changing the associativity of $. If that kind of code had been broken, I would have complained too. So what was your point again? ;-) Cheers, /Niklas ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: patch applied (haskell-prime-status): add Make $ left associative, like application
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 ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: patch applied (haskell-prime-status): add Make $ left associative, like application
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. Thanks Neil * I appreciate that a lot of non-English users might find it a bit difficult to hit this key! ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: patch applied (haskell-prime-status): add Make $ left associative, like application
2008/4/23 Neil Mitchell [EMAIL PROTECTED]: 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 ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: patch applied (haskell-prime-status): add Make $ left associative, like application
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 ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: patch applied (haskell-prime-status): add Make $ left associative, like application
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, but I reckon here is as good as anywhere. I would like to propose that the Haskell' Prelude includes the function f $$ x = f x with the same fixity level as $ (presumably 0) but being left associative instead. And that $ is left as is. Cheers, /Niklas ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: patch applied (haskell-prime-status): add Make $ left associative, like application
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
Re: patch applied (haskell-prime-status): add Make $ left associative, like application
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 ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: patch applied (haskell-prime-status): add Make $ left associative, like application
Niklas Broberg wrote: ... 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 If $ is left-associative, then f (g (h x)) (k y) = (f . g . h $ x) (k y) = (f . g . h $ x) $ k y = f . g . h $ x $ k y But perhaps composing a curried function this way is unintuitive. -- Jason McCarty [EMAIL PROTECTED] ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: patch applied (haskell-prime-status): add Make $ left associative, like application
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⑈ ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: patch applied (haskell-prime-status): add Make $ left associative, like application
John Meacham wrote: 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. Do prefix operators bind more or less tightly than infix operators? Either way, one of the two expressions (~2^3) or (~y$z) will parse somewhat unintuitively. I would expect these to mean ~(2^3) and (~y) $ z respectively. Dan ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
RE: patch applied (haskell-prime-status): add Make $ left associative, like application
Aaron Denney wrote: On 2008-04-23, Sittampalam, Ganesh [EMAIL PROTECTED] 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 == ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: patch applied (haskell-prime-status): add Make $ left associative, like application
On Thu, 24 Apr 2008 01:43:36 +0100, Sittampalam, Ganesh wrote: Is there not a general expectation when a new language standard comes out that people will migrate to it (perhaps over time)? I would hope so. There's no chance that Haskell 98 would continue to be maintained with bug fixes and the like indefinitely into the future. It's a but futile, then, to suppose people can avoid Haskell' entirely for old code. -- Chris ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: patch applied (haskell-prime-status): add Make $ left associative, like application
Lennart Augustsson: I my opinion, anyone who suggest changing the associativity of $ is insane. Or just hating every Haskell user. Changing $ would make virtually every Haskell program uncompilable. Just pick some other (Unicode?) operator, but leave $ alone. I agree that the power/weight ratio for changing the associativity of $ is not convincing at all.[1] Like the choice of (.) for function composition, it is something that Haskell will have to live with, forever. Nevertheless, I think unicode for standard operators is also a no-go for Haskell'. We discussed this on the committee list, and really, tool support for unicode is still very poor. Even cut-copy-paste of unicode text between different apps on MacOS -which seems to support unicode comparatively well- often doesn't work. Some applications, such as X11 for MacOS, don't seem to support unicode at all. The situation on Linux is even worse. Moreover, it is often difficult and definitely not uniform across platforms how to enter unicode characters. Manuel [1] Don't get me wrong, I also stumbled over the associativity of $ before and I agree that it should be different. I just don't think the gain is worth the hassle. ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: patch applied (haskell-prime-status): add Make $ left associative, like application
Sittampalam, Ganesh: Aaron Denney wrote: On 2008-04-23, Sittampalam, Ganesh [EMAIL PROTECTED] 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 KR C to ANSI C.) Manuel ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
patch applied (haskell-prime-status): add Make $ left associative, like application
Tue Apr 22 15:53:31 PDT 2008 Simon Marlow [EMAIL PROTECTED] * add Make $ left associative, like application M ./status.hs +5 View patch online: http://darcs.haskell.org/haskell-prime-status/_darcs/patches/2008045331-8214f-8c2b7ec4a7666bfaa70b2514290172981bdebb50.gz ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: patch applied (haskell-prime-status): add Make $ left associative, like application
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 [EMAIL PROTECTED] * 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 ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: patch applied (haskell-prime-status): add Make $ left associative, like application
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 [EMAIL PROTECTED] * 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. 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. Cheers, Simon ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: patch applied (haskell-prime-status): add Make $ left associative, like application
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
Re: patch applied (haskell-prime-status): add Make $ left associative, like application
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? -- Aaron Denney -- ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re[2]: patch applied (haskell-prime-status): add Make $ left associative, like application
Hello John, Wednesday, April 23, 2008, 9:41:22 AM, you wrote: 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. aside compilers, there are people, too. are we really want to put comments on each haskell snippet published - in which version of language it's written, for a such small benefit? -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
