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: Meta-point: backward compatibility
Hi I think Henrik's criteria are pretty close to perfect. As I have argued before on the committee list, I also think we should *not* worry about backwards incompatible changes too much in cases where a simple automatic translation from H98 to H' code is possible. Even for a large project, it is IMHO no big hardship to run a H98-H' translator over all Haskell sources. Some questions: 1) Will I (the programmer) have to mode switch in painful ways between H98 and H'? Do I have to learn a pile of exceptions, or is there some common rule that works? (i.e. removing n+k is fine since I just don't learn it, changing the fixity of $ is not since I need to know both) 2) Will tool T (the translator) work on academic papers that have previously been published. 3) Will tool T handle all of GHC's extensions. 4) Will tool T deal with things like CPP, hsc, trhsx, happy, alex etc... - all these file formats which include embedded Haskell. 5) Will tool T ever exist. I think the answer to 2-5 is nearly certainly going to be No. I don't think the relevance of a conversion tool should even be considered until some person steps forward and says without doubt that _they_ will write the converter. Even if they did there very best, it still won't be trivial to use in all cases. As John Launchbury has said, given Haskell's current rise in popularity, anything that we do not fix with H' will be much harder, if not impossible, to fix in the future. That is a very good point. Perhaps we're already a little too late. Thanks Neil ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Meta-point: backward compatibility
Hi all, Manuel wrote: As I have argued before on the committee list, I also think we should *not* worry about backwards incompatible changes too much in cases where a simple automatic translation from H98 to H' code is possible. Yes, tools can and should help with migration, and we should keep that in mind. In particular, complicated language design to incorporate new features while maintaining backwards compatibility should be avoided where old code and new code easily can be made to work together through a compiler compatibility flag. (The discussion on records/labelled fields spring to mind.) However, I still think it is important to be conservative when it comes to breaking changes and either only consider them when the impact really would be very small, or when it is agreed it is a really important change. Even if there are tools to help with code, effort is still involved to fix the breaks, and thus it ought to be completely clear that the effort is worth it. And there is not only code: there are papers and books too! And finally, unless we're fairly strict, we'll be bogged down in a flood of discussion on gratuitous and ultimately rather superficial changes. The associativity of $ is a case in point. So, the criteria I proposed still seem quite reasonable to me. But I'm biased, of course! :-) /Henrik -- Henrik Nilsson School of Computer Science The University of Nottingham [EMAIL PROTECTED] This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ 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
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[2]: Meta-point: backward compatibility
Hello Neil, Thursday, April 24, 2008, 12:21:41 PM, you wrote: Some questions: don't forget about most complex part: does this tool will convert human minds? :D -- 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
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: Meta-point: backward compatibility
Manuel wrote: As John Launchbury has said, given Haskell's current rise in popularity, anything that we do not fix with H' will be much harder, if not impossible, to fix in the future. On Thu, 24 Apr 2008 09:21:41 +0100, Neil Mitchell wrote: That is a very good point. Perhaps we're already a little too late. In general, I truly hope that this is not the case. Part of what makes Haskell such a great environment is the sense that the language values doing things right, trying out new ideas and adopting them when they work, and that the Haskell community takes pride in what we have as a language. I'm certainly willing to give up some effort fixing my old code in order to use such a language. Now, I realize that me fixing my old Haskell code means something like ten thousand lines at most, while for others it may mean a couple orders of magnitude more work; maybe it's best just to ignore me. But it would be a shame if, in the course of trying to do the right thing for Haskell's large popularity, we ended up diluting the things about the language that make it popular. So I'd argue that, in Haskell' and later on as well, it should be just a fact of life that code will occasionally break as the language evolves. If there's a consensus that something is broken, it should be fixed. If people want their code from 10 years ago to work on today's latest compiler, then there will be lots of intangible costs to achieving that goal, and I'm not sure the current spirit of Haskell will survive those costs. Unfortunately, that cost, which might be expressed as Haskell won't be as nifty a language any more, is hard to take seriously; but I'm nevertheless convinced that it has to be taken seriously. That said, three caveats: 1. If the goal of Haskell' in particular is to codify existing practice, that's quite the admirable goal given how far behind (10 years!) things currently are in having a language standard. So this is more about how we should think about life after Haskell', rather than the current Haskell' effort. 2. Nothing I said is an argument for intentionally making people's lives painful. For example, there's no need to take approaches that break people's code between consecutive versions of Haskell with no easy way of making the code work with both. Neil said this better elsewhere, so I won't repeat it. 3. Don't get me wrong; I'm definitely not arguing for this ($) associativity change, for example, and my objection is the backward compatibility. But ultimately, it's more like a combination of incompatibility and the lack of a really compelling story on why it should be one way or the other. I have a hard time calling this a fix; it's more like a change of personal taste. If I saw this as really broken, then I'd say we need to talk about how to fix it. -- Chris ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
RE: The monomorphism restriction and monomorphic pattern bindings
| Iavor: | the change is valid. I do believe that you can probably work around | the problem in many situations but the question in my mind is why | should we have to work around stuff when we have a system that already | works? In other words, what problem do MBPs solve? ... | Neil: | Haskell has always had the attitude of doing what suits users, and | making implementations work hard to handle the language features. In | addition, this is a breaking change. I have not made my case well! 1. [Minor point] In general I agree with what Iavor and Neil say above, but it should not be an Iron Law. If a small and easily-describable restriction in programming yields a significant simplification in implementation, that's a benefit that may be worth having. 2. More importantly, I am using System F *not* because it tells us about GHC's implementation, but because I have found that it's an excellent litmus test that tells when something smelly is going on. The fact that one has to go through contortions to translate pattern bindings is a Bad Sign, I believe. 3. I'm more concerned about the programmer than the implementation. Consider (f,g) = (negate, show) What type do you expect 'f' to have? A straightforward answer might be f :: (Num a, Show b) = a - a If you don't want that, you need to explain a more complicated typing rule for pattern bindings.I'll ask the same about (f,g) = (reverse, length) A simple and consistent story is that all the pattern bound variables are generalised over all the class constraints and all the type variables of the RHS. But I bet that is not what you want. 4. Would it make a difference if you gave a type signature for f? Can f,g have different sets of class constraints? (H98 says 'no' for class constraints, but 'yes' for type variables, which is an obvious wart). 5. I'm also concerned about the interaction with strictness. let (f,g) = e in f (...f...g...) Here 'f' is clearly used strictly, so the pair will certainly be evaluated. Does this mean the same? case e of (f,g) - f (...f..g...) 6. If we allow bang patterns, what does !(f,g) = e actually mean? The implementation is not the driving force. It's just the way I know that something is afoot. What is the problem MPB tries to solve? The problem of specifying the type system for pattern bindings. Try writing down the full typing rules for pattern bindings, including type signatures! Higher-rank types too. Simon ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Meta-point: backward compatibility
Chris Smith wrote: I'm definitely not arguing for this ($) associativity change, for example, and my objection is the backward compatibility. But ultimately, it's more like a combination of incompatibility and the lack of a really compelling story on why it should be one way or the other. I have a hard time calling this a fix; it's more like a change of personal taste. The $ problem is an interesting one, for it has the following properties: 1) Someone who learns Haskell for the first time will not complain about either associativity. Whether it's left or right associative is rather unimportant, it is how it is and either way is fine. 2) But once the decision has been made, it's nigh impossible to change it, simply because everybody has relied on one particular associativity of $ all the time. 3) Assuming that this associativity is a matter of taste, it only sounds fair to experiment and try different tastes. So, Cale has a Prelude with left associative $ and Lennart has a different personal Prelude as well and I'm going too taste a sip of either one and brew my own functional coffee. But in that situation, the defining property of a standard, namely that everybody uses the same $ , is gone, everybody would have to check which one is used in which module. It's like being forced to eat chicken only because chicken lay eggs. Some may like it, some may not, but the eggs will hatch new chicken who lay new eggs for all eternity :) 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
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: The monomorphism restriction and monomorphic pattern bindings
Iavor Diatchki wrote: I should also point out that if we were to adopt the MBP rule, we would have to adjust the definition of what pattern bindings mean. For example, I think that this is how things are desugared at the moment: (x,y) = e becomes new_var = e x = case new_var of (v,_) - v y = case new_var of (_,v) - v The report doesn't actually mention this translation although it is widely used to implement pattern bindings, and in some compilers (not GHC) the translation is done before type checking. What's interesting to me is that perhaps this gives us a way to understand what the static semantics of pattern bindings should be, absent MPB. e.g. (x,y) = (negate,show) (Simon's example) translates to z = (negate,show) x = fst z y = snd z and we can see why both x and y end up generalised over both constraints, because z :: (Num a, Show b) = (a - a, b - String) and this also explains why the pattern-bound variables don't have to be generalised over all the type variables. e.g. in z = (id,id) x = fst z y = snd z we'd get z :: forall a b . (a-a, b-b) x :: forall a . a - a not x :: forall a b . a - a because the generalisation step for x only generalises over the type variables in the type arising from its right-hand side. Cheers, Simon It seems that under MBP the second program is not equivalent to the first because it is more polymorphic. -Iavor On Wed, Apr 23, 2008 at 10:32 AM, Simon Marlow [EMAIL PROTECTED] wrote: Folks, The current proposal on the table for what to do about the monomorphism restriction (henceforth MR) is * remove the MR entirely * adopt Monomorphic Pattern Bindings (MPB) Right now, the committee is almost uniformly in favour of dropping the MR, and most of us are coming round to the idea of MPB. Since this area has historically been difficult to achieve a concensus on, I'm excited that we appear to be close to making a decision, and a good one at that! The arguments for removing the MR are pretty well summarised on the wiki: http://hackage.haskell.org/trac/haskell-prime/wiki/MonomorphismRestriction You can read about MPB here: http://hackage.haskell.org/trac/haskell-prime/wiki/MonomorphicPatternBindings GHC has implemented MPB by default (i.e. we deviate slightly from Haskell 98) since 6.8.1. The nice thing about the combination of removing MR and adopting MPB is that we retain a way to explicitly declare monomorphic bindings. These are monomorphic bindings: ~x = e [EMAIL PROTECTED] = e or if you don't mind a strict binding: !x = e. The wiki points out that (x) = e would also be monomorphic, but arguably this is in poor taste since we expect (x) to mean the same as x everywhere. Cheers, Simon ___ 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): BangPatterns: probably accept == undecided
Am Freitag, 18. April 2008 11:54 schrieb Sittampalam, Ganesh: Simon Peyton Jones wrote: Not allowing infix functions on the LHS would be a notable simplification. This would significantly weaken a useful property of Haskell, that definitions and uses often share the same concrete syntax. It's very natural to be able to define things that way and it would be a real shame to lose it (and I think it would break a lot of existing code). +1 (f . g) x = f (g x) is really nice. In any case, I've always thought this was weird: Just x == Just y = x == y It takes a little getting used to, but I don't find it that weird. +1 […] Best wishes, Wolfgang ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Haskell' - class aliases
Am Mittwoch, 23. April 2008 06:18 schrieb John Meacham: On Tue, Apr 22, 2008 at 08:33:53AM +0100, Simon Peyton-Jones wrote: Is this the most up-to-date description of the proposal? http://repetae.net/recent/out/classalias.html There were a few changes proposed in the discussion that followed my announcement that I wanted to make. The one I can remember now is getting rid of the 'alias' keyword since the equals sign unabiguously identifies it as an alias. I will dig through the archive to find the others.. I've just had another look, which threw up quite a few questions in my mind. I wonder what would be a good list to discuss it. Maybe this one is not bad, because it has people interested in Haskell innovation, regardless of whether it's a live Haskell' candidate? Sounds good to me. John By the way, what are your current thoughts about your supertyping proposal. At least, on http://repetae.net/recent/out/supertyping.html you say: This functionality becomes even more necessary when faced with binary-only libraries and standard language features which cannot be easily rewritten or overridden without great effort. This seems to be an advantage compared to the class alias library. On the other hand, it looks a bit weird to me that you can express a class relation in two different ways: A t = B t and B t = A t. 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 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: Suggestion regarding (.) and map
Am Mittwoch, 23. April 2008 23:55 schrieb Cale Gibbard: […] Rename fmap to map This would be really great! There is no point in having a map just for lists and a general map for functors since the list map is the same as the list instance’s functor map. And identifiers with a single lowercase letter in front or after a lowercase word (fmap, foldr, etc.) are not nice, in my opinion. (like it was in Haskell 1.4), It really was this way in Haskell 1.4? Why was it changed? and define (.) as a synonym for it. I don’t think that this is reasonable. (.) corresponds to the little circle in math which is a composition. So (.) = () would be far better. Additionally, add the instance: instance Functor ((-) e) where map f g x = f (g x) (and hopefully the corresponding Monad instance as well) And hopefully the corresponding Applicative instance as well! Applicative functors are a very nice thing. (So a big “thank you” to Conor and Ross.) […] Best wishes, Wolfgang ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Suggestion regarding (.) and map
2008/4/24 Wolfgang Jeltsch [EMAIL PROTECTED]: Am Mittwoch, 23. April 2008 23:55 schrieb Cale Gibbard: […] Rename fmap to map This would be really great! There is no point in having a map just for lists and a general map for functors since the list map is the same as the list instance's functor map. And identifiers with a single lowercase letter in front or after a lowercase word (fmap, foldr, etc.) are not nice, in my opinion. (like it was in Haskell 1.4), It really was this way in Haskell 1.4? Why was it changed? and define (.) as a synonym for it. I don't think that this is reasonable. (.) corresponds to the little circle in math which is a composition. So (.) = () would be far better. But the realisation here is that composition *is* functor application, for a certain rather important functor. :) - Cale ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Meta-point: backward compatibility
2008/4/24 Chris Smith [EMAIL PROTECTED]: 3. Don't get me wrong; I'm definitely not arguing for this ($) associativity change, for example, and my objection is the backward compatibility. But ultimately, it's more like a combination of incompatibility and the lack of a really compelling story on why it should be one way or the other. I have a hard time calling this a fix; it's more like a change of personal taste. If I saw this as really broken, then I'd say we need to talk about how to fix it. How about the argument that the right associative ($), in conjuction with (.) is less expressive than that left associative one in conjunction with (.)? That is, more parentheses can be avoided. Everything you can do with chained right associative ($), you can do with (.) and a single ($), whereas there are things you can express with chained left-associative ($) which you need parentheses to express without it. - Cale ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Suggestion regarding (.) and map
On Thursday 24 April 2008, Wolfgang Jeltsch wrote:
I don’t think that this is reasonable. (.) corresponds to the little
circle in math which is a composition. So (.) = () would be far better.
Were I building a library, this might be the direction I'd take things.
They're two incompatible generalizations, and you have to decide which is
more important to you.
For instance, you can generalize from arrows into categories (with objects in
*):
class Category (~) where
id :: a ~ a
(.) :: (b ~ c) - (a ~ b) - (a ~ c)
And, of course, from this, you get the usual meanings for (-):
instance Category (-) where
id x = x
(f . g) x = f (g x)
An example of a Category that isn't an Arrow (I think) is:
newtype Op (~) a b = Op { unOp :: b ~ a }
instance Category (~) = Category (Op (~)) where
id = Op id
-- (.) :: (b ~ c) - (a ~ b) - (a ~ c)
(Op f) . (Op g) = Op (g . f)
type HaskOp = Op (-)
(Why is this even potentially useful? Well, if you define functors with
reference to what two categories they relate, you get (pardon the illegal
syntax):
map :: (a ~1 b) - (f a ~2 f b)
Which gives you current covariant endofunctors if (~1) = (~2) = (-), but it
also gives you contravariant endofunctors if (~1) = (-) and (~2) = Op
(-). Is this a useful way of structuring things in practice? I don't know.)
Now, going the (.) = map route, one should note the following Functor
instance:
instance (Arrow (~)) = Functor ((~) e) where
-- fmap :: (a - b) - (e ~ a) - (e ~ b)
fmap f g = arr f g
So, in this case (.) is composition of a pure function with an arrow, but it
does not recover full arrow composition. It certainly doesn't recover
composition in the general Category class above, because there's no operation
for lifting functions into an arbitrary Category (think Op: given a function
(a - b), I can't get a (b - a) in general).
(At a glance, if you have the generalized Functors that reference their
associated Categories, you have:
map (a ~1 b) - (e ~3 a) ~2 (e ~3 b)
so for (~1) = (~3), and (~2) = (-), you've recovered (.) for arbitrary
categories:
instance (Category (~) = Functor ((~) e) (~) (-) where
map f g = f . g
so, perhaps with a generalized Functor, you can have (.) = map *and* have (.)
be a generalized composition.)
Now, the above Category stuff isn't even in any library that I know of, would
break tons of stuff (with the generalized Functor, which is also kind of
messy), and I haven't even seriously explored it, so it'd be ridiculous to
request going in that direction for H'. But, restricted to the current
libraries, if you do want to generalize (.), you have to decide whether you
want to generalize it as composition of arrows, or as functor application.
The former isn't a special case of the latter (with the current Functor, at
least).
Generalizing (.) to Arrow composition seems more natural to me, but
generalizing to map may well have more uses.
-- 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
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: Suggestion regarding (.) and map
2008/4/24 Dan Doel [EMAIL PROTECTED]:
On Thursday 24 April 2008, Wolfgang Jeltsch wrote:
I don't think that this is reasonable. (.) corresponds to the little
circle in math which is a composition. So (.) = () would be far better.
Were I building a library, this might be the direction I'd take things.
They're two incompatible generalizations, and you have to decide which is
more important to you.
For instance, you can generalize from arrows into categories (with objects in
*):
class Category (~) where
id :: a ~ a
(.) :: (b ~ c) - (a ~ b) - (a ~ c)
And, of course, from this, you get the usual meanings for (-):
instance Category (-) where
id x = x
(f . g) x = f (g x)
An example of a Category that isn't an Arrow (I think) is:
newtype Op (~) a b = Op { unOp :: b ~ a }
instance Category (~) = Category (Op (~)) where
id = Op id
-- (.) :: (b ~ c) - (a ~ b) - (a ~ c)
(Op f) . (Op g) = Op (g . f)
type HaskOp = Op (-)
(Why is this even potentially useful? Well, if you define functors with
reference to what two categories they relate, you get (pardon the illegal
syntax):
map :: (a ~1 b) - (f a ~2 f b)
Which gives you current covariant endofunctors if (~1) = (~2) = (-), but
it
also gives you contravariant endofunctors if (~1) = (-) and (~2) = Op
(-). Is this a useful way of structuring things in practice? I don't know.)
Now, going the (.) = map route, one should note the following Functor
instance:
instance (Arrow (~)) = Functor ((~) e) where
-- fmap :: (a - b) - (e ~ a) - (e ~ b)
fmap f g = arr f g
So, in this case (.) is composition of a pure function with an arrow, but it
does not recover full arrow composition. It certainly doesn't recover
composition in the general Category class above, because there's no operation
for lifting functions into an arbitrary Category (think Op: given a function
(a - b), I can't get a (b - a) in general).
(At a glance, if you have the generalized Functors that reference their
associated Categories, you have:
map (a ~1 b) - (e ~3 a) ~2 (e ~3 b)
so for (~1) = (~3), and (~2) = (-), you've recovered (.) for arbitrary
categories:
instance (Category (~) = Functor ((~) e) (~) (-) where
map f g = f . g
so, perhaps with a generalized Functor, you can have (.) = map *and* have (.)
be a generalized composition.)
Now, the above Category stuff isn't even in any library that I know of, would
break tons of stuff (with the generalized Functor, which is also kind of
messy), and I haven't even seriously explored it, so it'd be ridiculous to
request going in that direction for H'. But, restricted to the current
libraries, if you do want to generalize (.), you have to decide whether you
want to generalize it as composition of arrows, or as functor application.
The former isn't a special case of the latter (with the current Functor, at
least).
Generalizing (.) to Arrow composition seems more natural to me, but
generalizing to map may well have more uses.
-- Dan
Right, my own preference in this regard is to generalise in the
direction that () would be a method of Category, which is a
generalisation of Arrow.
We currently at least have way more Functor instances than Category
instances, so it seems sensible to pick the shorter notation for the
more common case, but I do strongly think we should start pushing
things in this direction. These are all really nice, extremely general
ideas which can make libraries nicely uniform.
- Cale
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Suggestion regarding (.) and map
Cale Gibbard wrote: Hello, In keeping with my small but seemingly extremely controversial suggestions for changes to the Prelude, here's a suggestion which I think is elegant and worth considering for the Haskell' Prelude: Rename fmap to map (like it was in Haskell 1.4), and define (.) as a synonym for it. One thing I fear (though that fear may be irrational) is that you get code that looks like (.) . ((.) . (.) .). To me, and I expect to many people, map and composition are different things, and used in different ways. If both are written as a dot it will take extra mental effort to decipher the meaning of a program. The potential for writing code that resembles the worst outputs of the @pl lambdabot plugin also becomes larger. Cale: do you have some real world examples of code you wrote using (.) = fmap? Secondly, I am really fond of the Applicative notation $, which goes great together with *. A lighter notation would be nice, but I see no good way to do that. (Perhaps we need to add syntactic sugar for idiom brackets?) Twan ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Suggestion regarding (.) and map
2008/4/24 Twan van Laarhoven [EMAIL PROTECTED]: Cale Gibbard wrote: Hello, In keeping with my small but seemingly extremely controversial suggestions for changes to the Prelude, here's a suggestion which I think is elegant and worth considering for the Haskell' Prelude: Rename fmap to map (like it was in Haskell 1.4), and define (.) as a synonym for it. One thing I fear (though that fear may be irrational) is that you get code that looks like (.) . ((.) . (.) .). To me, and I expect to many people, map and composition are different things, and used in different ways. If both are written as a dot it will take extra mental effort to decipher the meaning of a program. The potential for writing code that resembles the worst outputs of the @pl lambdabot plugin also becomes larger. This is why I recommend having (.) only be a synonym for map (which would be the method of Functor). Cale: do you have some real world examples of code you wrote using (.) = fmap? I haven't used the convention in anything too large, but I've found it rather convenient and natural in the case of, for instance, IO, to be able to write things like map read . lines . getContents. I've played around with it in a lot of small cases and not found ambiguity to be much of a problem. It turns out that the functor is basically always determined by the last thing in the chain of (.) applications, so it remains sensible. Secondly, I am really fond of the Applicative notation $, which goes great together with *. A lighter notation would be nice, but I see no good way to do that. (Perhaps we need to add syntactic sugar for idiom brackets?) Yeah, that's something to think about. I agree that the appearance of $ mixes well with the other Applicative operators, and should likely remain a part of that library. Adding special syntactic support for Applicative could be very nice though. - Cale ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Suggestion regarding (.) and map
On Thu, Apr 24, 2008 at 6:06 PM, Twan van Laarhoven [EMAIL PROTECTED] wrote: Cale Gibbard wrote: Hello, In keeping with my small but seemingly extremely controversial suggestions for changes to the Prelude, here's a suggestion which I think is elegant and worth considering for the Haskell' Prelude: Rename fmap to map (like it was in Haskell 1.4), and define (.) as a synonym for it. One thing I fear (though that fear may be irrational) is that you get code that looks like (.) . ((.) . (.) .). To me, and I expect to many people, map and composition are different things, and used in different ways. If both are written as a dot it will take extra mental effort to decipher the meaning of a program. The potential for writing code that resembles the worst outputs of the @pl lambdabot plugin also becomes larger. I'd much rather keep composition and functor map separate. I'm still not entirely sure that generalizing (.) to other morphisms in the Category class is a good idea. Function composition gets used a *lot*, and I imagine we'd loose a lot of inlining if it became a class method. Secondly, I am really fond of the Applicative notation $, which goes great together with *. A lighter notation would be nice, but I see no good way to do that. (Perhaps we need to add syntactic sugar for idiom brackets?) As much as I like Applicative, I dislike the name *. To me, it makes more sense to use $ for *, since it's application of wrapped functions. I've used $^ as a synonym for fmap (because it's lifted application). It would be nice to have sugar for idiom brackets. You can simulate them with a class, but the result typically doesn't stand out enough visually as being special syntax. -- 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: 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: Suggestion regarding (.) and map
2008/4/24 David Menendez [EMAIL PROTECTED]: On Thu, Apr 24, 2008 at 6:06 PM, Twan van Laarhoven [EMAIL PROTECTED] wrote: Cale Gibbard wrote: Hello, In keeping with my small but seemingly extremely controversial suggestions for changes to the Prelude, here's a suggestion which I think is elegant and worth considering for the Haskell' Prelude: Rename fmap to map (like it was in Haskell 1.4), and define (.) as a synonym for it. One thing I fear (though that fear may be irrational) is that you get code that looks like (.) . ((.) . (.) .). To me, and I expect to many people, map and composition are different things, and used in different ways. If both are written as a dot it will take extra mental effort to decipher the meaning of a program. The potential for writing code that resembles the worst outputs of the @pl lambdabot plugin also becomes larger. I'd much rather keep composition and functor map separate. I'm still not entirely sure that generalizing (.) to other morphisms in the Category class is a good idea. Function composition gets used a *lot*, and I imagine we'd loose a lot of inlining if it became a class method. It should specialise quite nicely. The only places I'd expect you'd lose optimisation would be those which were truly polymorphic applications, which you otherwise couldn't have written as (.) anyway. Someone who knows more about how GHC works might want to comment further, but a simple SPECIALISE pragma for it should do the trick. - Cale ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
