Re: [Haskell-cafe] Why is $ right associative instead ofleftassociative?
On 06/02/06, John Hughes [EMAIL PROTECTED] wrote: Cale Gibbard wrote: That said, I'd *really* like to see monad comprehensions come back, since they align better with the view that monads are container types, dual to the view that monads are computations, which is supported by the do-syntax. This view is actually much easier to teach (in my experience). Giving lists a little extra syntax is nice, but giving things unnecessarily restrictive types seems to be the point at which I'd consider it going too far. The trouble with monad comprehensions was that it became far too easy to write ambiguous programs, even when you thought you were just working with lists. Haskell overloading works really nicely *as long as there's a judicious mixture of overloaded and non-overloaded functions*, so that the overloading actually gets resolved somewhere. Overload too many things, and you end up having to insert type annotations in the middle of expressions instead, which really isn't nice. Lists are special, not least because they come very early in a Haskell course--or, in my case, in the first ever programming course my students have ever taken. Getting error messages about ambiguous overloading when they are still trying to understand what comprehension notation means (without even the concept of a for-loop to relate it to) is very destructive. And this is in the case where the code is otherwise type-correct--the kind of error message you would get by trying to append a number to a monad comprehension doesn't bear thinking about! The class system is already something of an obstacle in teaching, because you have to mention it in the context of arithmetic (even if you tell students always to write monomorphic type signatures, they still see classes mentioned in error messages). After all, that is surely why Helium doesn't have it. I find classes manageable for arithmetic, even if students do take some time to learn to distinguish between a class and a type (or a type and a value, for that matter!). But it's a relief that list programs, at least, have simple non-overloaded types. List functions provide an opportunity to introduce polymorphism in a simple context--it's much easier to understand why (++) should have the type [a] - [a] - [a], than to start talking about MonadPlus m = m a - m a - m a. There is a lot to learn in Haskell, especially in the type and class system. It's an advantage if you don't have to learn it all at once--if you can master lists and list comprehensions without exposure to monads (which are a much harder concept). We should never forget that beginners have somewhat different needs from expert programmers--and those needs are also important. If we want Haskell to be used for first programming courses (and it's a big advantage to catch 'em early), then there needs to be a learning path into the language that goes quite gently. Monomorphic lists help with that. We did consider more aggressive defaulting to address the ambiguity problems with monad comprehensions--defaulting Monad to lists, for example, or user-declared defaulting rules--but this introduces yet more complexity without really addressing the problem of keeping types simple for beginners, so the idea was abandoned. John How about a compiler switch for beginners (maybe with an included script that adds it to the command line) that turns off a bunch of the more complex issues involved, and uses a beginner's version of the Prelude? Helium exists as well, which is a simplified version of Haskell for beginners, without even typeclasses. It has very careful and detailed error messages. Having monad comprehensions actually helps with another newbie problem, albeit one which is a little farther along the garden path -- learning about monads. Defaulting monad comprehensions is probably a good idea. List comprehensions are probably the most common case anyway, just because lists are the most common container type. :) This also further helps in introducing monads as generalisations of lists. If extensions to the language get standardised, I'd be fine with having monad comprehensions among them. Adding an extension declaration or compiler switch to any module using them wouldn't be so bad either, though I'd really like them in the actual language. I'd also want to include the usual changes to the prelude. The situation with map I find especially grating. Having two versions of common functions is one thing, but 3 is getting out there! :) Is explaining Functor really that hard? It's just container types with a way to apply a function to all of their elements. :) I don't think it should be necessary to completely rule out useful features because they might be difficult to newcomers. There should always be ways to turn things off, and construct a simpler language for new users. Dr. Scheme seems to take this approach, and has a pretty fine gradation of languages for leading users from
Re[2]: [Haskell-cafe] Why is $ right associative instead ofleftassociative?
Hello John, Monday, February 06, 2006, 10:39:59 AM, you wrote: That said, I'd *really* like to see monad comprehensions come back, JH We did consider more aggressive defaulting to address the ambiguity JH problems with monad comprehensions--defaulting Monad to lists, for JH example, or user-declared defaulting rules--but this introduces yet more JH complexity without really addressing the problem of keeping types simple JH for beginners, so the idea was abandoned. why not allow some sort of module-wide pragma to enable use of this and any other features for expert programmers? just recalling last import extension proposal, we can add: import extension i-am-expert-programmer-enable-monad-comprehension-please! :) -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why is $ right associative instead ofleftassociative?
On 2/6/06, John Hughes [EMAIL PROTECTED] wrote: The trouble with monad comprehensions was that it became far too easy to write ambiguous programs, even when you thought you were just working with lists. Would the Haskell98-style solution be to add defaulting for Monads? -- Taral [EMAIL PROTECTED] Computer science is no more about computers than astronomy is about telescopes. -- Edsger Dijkstra ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why is $ right associative instead ofleftassociative?
Quoting Paul Hudak [EMAIL PROTECTED]: Actually, one of the main reasons that we chose (:) is that that's what Miranda used. So, at the time at least, it was not entirely clear what the de facto universal inter-language standard was. Phil Wadler argued for the ML convention at the time, and wrote a document containing a fair amount of sample code to illustrate what it would look like. We noticed something surprising: instead of (x:xs) and the like, Phil had consistently written (x :: xs) -- note the extra spaces. Somehow, using the longer operator name led him to feel spaces were needed around it. That in turn made his lines longer, encouraged him to split definitions across lines, and so on. When I read the thing, I realised after a while that I was skipping all the code fragments -- because they just looked too big and complicated to take in during a quick reading. It was at least partly that experience that convinced us that using :: for cons would impose a small cost, but a real one, on readability. It may seem trivial, but the sum of many such decisions is significant. The story does illustrate the importance of actually trying out syntactic ideas and seeing how they play--one can be surprised by the result. I don't think Haskell Prime should be about changing the look and feel of the language. It's about consolidating the most important extensions into the standard, isn't it? Changes that break existing code should be very, very well motivated--if porting code to Haskell Prime is too difficult, people just won't do it. John ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why is $ right associative instead ofleftassociative?
John Hughes wrote: Quoting Paul Hudak [EMAIL PROTECTED]: Actually, one of the main reasons that we chose (:) is that that's what Miranda used. So, at the time at least, it was not entirely clear what the de facto universal inter-language standard was. Phil Wadler argued for the ML convention at the time, and wrote a document containing a fair amount of sample code to illustrate what it would look like. We noticed something surprising: instead of (x:xs) and the like, Phil had consistently written (x :: xs) -- note the extra spaces. Somehow, using the longer operator name led him to feel spaces were needed around it. That in turn made his lines longer, encouraged him to split definitions across lines, and so on. When I read the thing, I realised after a while that I was skipping all the code fragments -- because they just looked too big and complicated to take in during a quick reading. It was at least partly that experience that convinced us that using :: for cons would impose a small cost, but a real one, on readability. It may seem trivial, but the sum of many such decisions is significant. The story does illustrate the importance of actually trying out syntactic ideas and seeing how they play--one can be surprised by the result. And at the time I agreed with you. But now I'm older and wiser(?). I now think :: for type signatures was a bad mistake. I don't use lists very much. They are not the right data structure for many things. So : is not as common as :: in my code. I checked a small sample of code, about 2 lines of Haskell. It has about 1000 uses of ':' and 2000 of '::'. In my opinion all the special syntactic sugar for lists should go away. I don't think lists are special enough to motivate it. But this is not what Haskell' is about. It's supposed to be some modest extensions to Haskell. Not designing a new perfect language. -- Lennart ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why is $ right associative instead ofleftassociative?
Lennart Augustsson wrote: I now think :: for type signatures was a bad mistake. I don't use lists very much. They are not the right data structure for many things. So : is not as common as :: in my code. I checked a small sample of code, about 2 lines of Haskell. It has about 1000 uses of ':' and 2000 of '::'. Just for interest, I analysed some of my code. Obviously my style is quite different to yours--my type specialiser of 3,500 lines has 240 conses, and only 22 occurrences of '::'. I seem to be using '::' a bit more lately, though, which I suspect is due to using classes much more. I also checked the Agda source code, about 14,000 lines, with about 500 occurrences of cons and 640 of '::'. I think the only conclusion one can draw is that style varies. In my opinion all the special syntactic sugar for lists should go away. I don't think lists are special enough to motivate it. What, no list comprehensions?? I'd disagree--sequencing is special, and lists represent it directly. Don't forget, also, that lists are also much more prevalent in beginners' code--and nice notation for beginners helps get people started on Haskell. But this is not what Haskell' is about. It's supposed to be some modest extensions to Haskell. Not designing a new perfect language. Right! John ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why is $ right associative instead ofleftassociative?
John Hughes wrote: What, no list comprehensions?? No. I think the do notation is good enough. I'd disagree--sequencing is special, and lists represent it directly. Don't forget, also, that lists are also much more prevalent in beginners' code--and nice notation for beginners helps get people started on Haskell. I don't really see what's so much better about writing [x1,x2,x3,x4,x5] than x1:x2:x3:x4:x5:[]. When I've explained lists to beginners I've just found it annoying and hard to explain why there are two ways of writing lists. And why only lists have this special syntax. -- Lennart ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why is $ right associative instead ofleftassociative?
On Sun, Feb 05, 2006 at 10:45:50AM -0500, Lennart Augustsson wrote: I don't really see what's so much better about writing [x1,x2,x3,x4,x5] than x1:x2:x3:x4:x5:[]. When I've explained lists to beginners I've just found it annoying and hard to explain why there are two ways of writing lists. And why only lists have this special syntax. -- Lennart But if you remove the [...] syntax, there will be more :'s in people's code. You are working against yourself here ;-) Best regards Tomasz -- I am searching for programmers who are good at least in (Haskell || ML) (Linux || FreeBSD || math) for work in Warsaw, Poland ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why is $ right associative instead ofleftassociative?
Bulat Ziganshin wrote: LA In my opinion all the special syntactic sugar for lists should go LA away. I don't think lists are special enough to motivate it. i have proposal (not for Haskell', of course) of using : and [] syntax for general notion of traversable collections: Minor point, perhaps, but I should mention that : is not special syntax -- it is a perfectly valid infix constructor. [] and all its variants, however, are special syntax. -Paul ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why is $ right associative instead ofleftassociative?
On 05/02/06, Lennart Augustsson [EMAIL PROTECTED] wrote: John Hughes wrote: What, no list comprehensions?? No. I think the do notation is good enough. I'd disagree--sequencing is special, and lists represent it directly. Don't forget, also, that lists are also much more prevalent in beginners' code--and nice notation for beginners helps get people started on Haskell. I don't really see what's so much better about writing [x1,x2,x3,x4,x5] than x1:x2:x3:x4:x5:[]. When I've explained lists to beginners I've just found it annoying and hard to explain why there are two ways of writing lists. And why only lists have this special syntax. -- Lennart Lists have special syntax because they're the lazy-functional counterpart to loops. They're quite a fundamental structure, regardless of what other data types we may have at our disposal, and I think that lots of special support is reasonable. Loops in imperative languages often get all kinds of special syntax support, and I don't think it's too far off-base to give lists special syntax accordingly. That said, I'd *really* like to see monad comprehensions come back, since they align better with the view that monads are container types, dual to the view that monads are computations, which is supported by the do-syntax. This view is actually much easier to teach (in my experience). Giving lists a little extra syntax is nice, but giving things unnecessarily restrictive types seems to be the point at which I'd consider it going too far. I haven't thought this out too carefully, but perhaps in order to give the brackets and commas syntax some more weight, the syntax x1:x2:x3:[] (or x1:x2:x3:Nil ?) could be used solely as a list, but [x1,x2,x3] would be the corresponding element in any MonadPlus -- this would be quite handy in a lot of the cases which I care about (nondeterministic computation). It would also mesh perfectly with monad comprehensions. I'd also like to mention that although my background is in pure mathematics, I had no trouble whatsoever adjusting to :: meaning has type. A colon is commonly inserted in mathematics between the name of a function and a depiction of the domain and codomain with an arrow between them, but I wouldn't think of that as formal syntax per-se. Also, it's not centuries-old as mentioned, but only about 50 years old -- I believe it started with the use of arrows in category theory. Before then, people mostly stated the types of functions in words, or it was left completely implicit, and they still often do both of those. Also, it is only used for functions and doesn't apply to values in any set or concrete categorical object. The notation x : S to mean x is an element of S is not in widespread common use. The use and context in mathematics is sufficiently different that I don't see it as a concern that Haskell be the same in this regard. The aesthetic reason that I like :: for has type and : for cons is that it's far more common that type signatures occur on a line by themselves, whereas conses when needed are often needed in bunches on the same line. Not that I'm suggesting that we change things, but as an example, I actually wouldn't mind typing out has type for type declarations (though the symbolic form is awfully nice when things must be annotated in-line, because it looks more like a separator rather than some random words -- syntax colouring could make up for that though), whereas I would likely mind a larger symbol for list cons. The amount of typing isn't the concern, it's how it actually looks on the page, and where it occurs in use. The wishy-washy informal reasoning is that cons is like a small bit of punctuation between the elements of a list -- semantically a comma, whereas a type annotation is actually saying something. When reading code aloud, you might not even say 'cons', and if you do say something, it'll probably be something fairly short and punctuation-like whereas for a type annotation, you're almost certainly going to say 'has type' or 'is of type', which seems structurally 'larger' to me, and perhaps deserves a bigger, more noticeable representation on the page. - Cale ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why is $ right associative instead ofleftassociative?
Cale Gibbard wrote: That said, I'd *really* like to see monad comprehensions come back, since they align better with the view that monads are container types, dual to the view that monads are computations, which is supported by the do-syntax. This view is actually much easier to teach (in my experience). Giving lists a little extra syntax is nice, but giving things unnecessarily restrictive types seems to be the point at which I'd consider it going too far. The trouble with monad comprehensions was that it became far too easy to write ambiguous programs, even when you thought you were just working with lists. Haskell overloading works really nicely *as long as there's a judicious mixture of overloaded and non-overloaded functions*, so that the overloading actually gets resolved somewhere. Overload too many things, and you end up having to insert type annotations in the middle of expressions instead, which really isn't nice. Lists are special, not least because they come very early in a Haskell course--or, in my case, in the first ever programming course my students have ever taken. Getting error messages about ambiguous overloading when they are still trying to understand what comprehension notation means (without even the concept of a for-loop to relate it to) is very destructive. And this is in the case where the code is otherwise type-correct--the kind of error message you would get by trying to append a number to a monad comprehension doesn't bear thinking about! The class system is already something of an obstacle in teaching, because you have to mention it in the context of arithmetic (even if you tell students always to write monomorphic type signatures, they still see classes mentioned in error messages). After all, that is surely why Helium doesn't have it. I find classes manageable for arithmetic, even if students do take some time to learn to distinguish between a class and a type (or a type and a value, for that matter!). But it's a relief that list programs, at least, have simple non-overloaded types. List functions provide an opportunity to introduce polymorphism in a simple context--it's much easier to understand why (++) should have the type [a] - [a] - [a], than to start talking about MonadPlus m = m a - m a - m a. There is a lot to learn in Haskell, especially in the type and class system. It's an advantage if you don't have to learn it all at once--if you can master lists and list comprehensions without exposure to monads (which are a much harder concept). We should never forget that beginners have somewhat different needs from expert programmers--and those needs are also important. If we want Haskell to be used for first programming courses (and it's a big advantage to catch 'em early), then there needs to be a learning path into the language that goes quite gently. Monomorphic lists help with that. We did consider more aggressive defaulting to address the ambiguity problems with monad comprehensions--defaulting Monad to lists, for example, or user-declared defaulting rules--but this introduces yet more complexity without really addressing the problem of keeping types simple for beginners, so the idea was abandoned. John ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
