For the last few days, my mail-box has been full of mail about the M-R, lazy pattern matching, n+k patterns, comment syntax--it's just like the good old days! And that worries me. Each of these topics is a snake pit--a tricky area of language design, with many alternative possibilities and no clear winner. As such, they make great discussion topics--if you want to start a heated argument, just propose a change to one of these (mea culpa)! We've also been discussing most of them for sixteen years. Of course, it's worth raising them from time to time, in case new insight means we can find a solution that is clearly much better than we found before. But the risk is that we go over the same old arguments, perhaps the consensus is slightly different this time, we make a change to the language, and who knows, next time the language is revised, maybe it'll change back again! That's destructive. We shouldn't change these things unless we can very, very clearly make an improvement. The fact is, we've lived with the present design for over a decade in each case, and we can live with it for another decade if we have to. The problem with Haskell 98 is not its warts--it offers a very pleasant programming experience despite them. The problem with Haskell 98 is that it *lacks* features which have become absolutely essential to Haskell programmers today. Those features are what really *need* discussion and energy spent on them. What are the top priorities for inclusion in a new standard? How can we identify them? I have some personal favourites, of course: ST state threads--absolutely essential. - but how to distinguish strict and lazy state? The present solution--importing a different module--sucks. Monad transformers - dramatically simplify constructing new monads - not a language feature in themselves, but demand extensions to work well. Multi-parameter classes with functional dependencies - used everywhere... for example in monad transformers... so *must* be included this time - omitted from Haskell 98 because "the right design" wasn't clear - it's still unclear! Functional dependencies *in some form* are essential, but associated types and datatypes look nicer in many ways! - is it too late, in practice, to replace fundeps by something else? How will we know? If we are to standardize on associated types instead, we need a major effort to *make sure* all important applications of fundeps can be represented. How will we organize that? Type system extensions--at least existential and rank-2 types. - should we go further? How will we know? My favourites may not be your favourites. How will we know what the most important features to discuss are? Here's a thought: Wouldn't it be nice if the most important Haskell tools and libraries, were actually written in standard-compliant Haskell'? One such tool is wxHaskell--named by 19% of Haskell users in my survey, it's the de facto standard GUI toolkit. wxHaskell makes essential use of existential types in its interface, a strong reason for including them in Haskell'. It also uses multi-parameter classes and functional dependencies, although much less heavily. What other tools "must" be supported by Haskell'? What other extensions must be present to support them? What issues remain before those extensions are standardized, and thus frozen in stone for many years to come? I'd like to see clearer priorities and a more focussed discussion--maybe the Wiki can be used to help? John
John Hughes wrote:
The problem with Haskell 98 is that it *lacks* features which have become absolutely essential to Haskell programmers today. Those features are what really *need* discussion and energy spent on them.
Very well, but this looks like a discussion for implementors and languages lawyers. It's not that interesting for me as a language/compiler user. For me, GHC is the de-facto standard because it works. That's why I found it more interesting to discuss improvements and changes. But I agree this is a different concern, and standardizing current practice certainly is needed to have a formally sound basis for further extensions. Perhaps you want to restrict traffic on haskell-prime to the original goal (standardization) and move everything else (incompatible and untested and unwanted modifications) to sth. like haskell-wishlist (I guess I'd unsubscribe from both, then, and get back to work :-) -- -- Johannes Waldmann -- Tel/Fax (0341) 3076 6479/80 -- ---- http://www.imn.htwk-leipzig.de/~waldmann/ -------
On Thu, 2006-02-02 at 11:38 +0100, John Hughes wrote:
One such tool is wxHaskell--named by 19% of Haskell users in my survey, it's the de facto standard GUI toolkit. wxHaskell makes essential use of existential types in its interface, a strong reason for including them in Haskell'. It also uses multi-parameter classes and functional dependencies, although much less heavily.
My priorities for Gtk2Hs (the second most popular GUI toolkit in John Hughes's survey) are very similar. We have adopted wxHaskell's style of attributes which is what uses existential types. I should not that in both cases the use of existential types is not essential. It was done that way only because the symbol that people wnated to use ':=' happens to be a constructor operator. If '=:' were used instead then existential construcotr types would not be necessary. We might make use of MPC +FunDeps if they were standard but it is not at all crucial. Our main concern is namespace issues. As I've said before, Gtk2Hs is a very large library but with the current module system it must export a flat name space. wxHaskell solves this with somewhat of a hack. It defines many multi-parameter type classes to allow the same name to be used by different widgets (with hopefully the same general meaning). I think this would be better solved by using qualified names. We have been trying hard to avoid non-H98isms so that we can hope to work with compilers other than ghc. So having these features standardised would allow us to present a better api and allow us to remain portable.
What other tools "must" be supported by Haskell'? What other extensions must be present to support them? What issues remain before those extensions are standardized, and thus frozen in stone for many years to come?
Another gripe is in the FFI, in the handling of include files. The method preferred by GHC and the method preferred by the FFI spec are rather at odds. GHC prefers the file to be specified on the command line while the FFI spec prefers it to be specified in each and every FFI import declaration. If one does the latter then GHC refuses to inline foreign calls across modules. Other mundane but useful things include the ability to specify different FFI import decls for different platforms without using #ifdef's. This would allow a program using a Gtk2Hs GUI to be compiled to bytecode with YHC and run on different platforms, rather than having to be built differently on each platform. (The issue is that even for portable C libs, the calling convention and symbol names can differ across platforms. This is true to a minor degree with the Gtk+ library.) Duncan
Multi-parameter classes with functional dependencies
When I first learned functional dependencies I remember I was really confused by their syntax. First, it is hard to find it defined: The GHC docs have barely three lines http://www.haskell.org/ghc/docs/latest/html/users_guide/type-extensions.html... and they refer to Mark Jones' paper which has a different notation than GHC's In Mark Jones' paper, the syntax is "tuple" notation, GHC uses | a b c -> d e where concatenation stands for grouping. where one would expect 'a b c' to mean application in Haskell (at the values level and at the type level). So when I first saw this, I thought this must be a kind error (if a has kind *) Otherwise in Haskell, we use parentheses and commas for grouping (export lists, type constraints, deriving) which is somehow wrong because the group in this case is a set, not a tuple. (With that respect, braces in records and let and where are OK, since order is irrelevant, but in do { .. } they are not, but that's how we show our sympathy to C and Java, right.) -- -- Johannes Waldmann -- Tel/Fax (0341) 3076 6479/80 -- ---- http://www.imn.htwk-leipzig.de/~waldmann/ -------
Hello Johannes, Thursday, February 02, 2006, 2:17:42 PM, you wrote: JW> When I first learned functional dependencies JW> I remember I was really confused by their syntax. JW> First, it is hard to find it defined: i should wrote this earlier, but nevertheless: Hugs documentation contains excellent introduction into the fundeps. i learned on it and never read any other papers. moreover, i recommended it to other ghc users, who was unhappy with current ghc docs Simon, may be it's the time to just steal this document section? i will don't say to anyone :) -- Best regards, Bulat mailto:bulatz@HotPOP.com
Hello Bulat, Thursday, February 02, 2006, 3:48:45 PM, you wrote: JW>> When I first learned functional dependencies JW>> I remember I was really confused by their syntax. JW>> First, it is hard to find it defined: BZ> Hugs documentation contains excellent introduction into the fundeps. namely chapter 7.1.1 in the http://cvs.haskell.org/Hugs/pages/hugsman/exts.html -- Best regards, Bulat mailto:bulatz@HotPOP.com
Johannes Waldmann wrote:
(With that respect, braces in records and let and where are OK, since order is irrelevant, but in do { .. } they are not, but that's how we show our sympathy to C and Java, right.)
You forget "let { f [] _ = 1 ; f _ [] = 2 } in f [] []". -- Ben
On Thu, Feb 02, 2006 at 07:06:07PM +0000, Ben Rudiak-Gould wrote:
Johannes Waldmann wrote:
(With that respect, braces in records and let and where are OK, since order is irrelevant, but in do { .. } they are not, but that's how we show our sympathy to C and Java, right.)
You forget "let { f [] _ = 1 ; f _ [] = 2 } in f [] []".
Also, order is relevant in many situations with records, e.g. data Foo = Foo { x :: Char, y :: Bool } defines Foo :: Char -> Bool -> Foo as well as the corresponding pattern constructor, and with foo (Foo { x = 'a', y = False }) = 'c' foo _ = 'd' bar (Foo { y = False, x = 'a' }) = 'c' bar _ = 'd' we have foo (Foo { x = 'z', y = undefined }) == 'd' bar (Foo { x = 'z', y = undefined }) == undefined (Err, where "we" == hugs. If "we" == ghci then they're both 'd', but I think this is wrong given my reading of both 3.17.2 and 3.17.3 in the H98 report) Thanks Ian
Ian Lynagh wrote:
Also, order is relevant in many situations with records, e.g.
data Foo = Foo { x :: Char, y :: Bool }
defines Foo :: Char -> Bool -> Foo as well as the corresponding pattern constructor
True. Of course the reason is, allowing both positional and named notation for records is a design error :-) But this is distracting from my main point: using spaces for grouping in fundeps is ugly because it looks like application. The separator should be a comma. -- -- Johannes Waldmann -- Tel/Fax (0341) 3076 6479/80 -- ---- http://www.imn.htwk-leipzig.de/~waldmann/ -------
On Thu, Feb 02, 2006 at 11:38:07AM +0100, John Hughes wrote:
The problem with Haskell 98 is that it *lacks* features which have become absolutely essential to Haskell programmers today. Those features are what really *need* discussion and energy spent on them.
[...]
Multi-parameter classes with functional dependencies - used everywhere... for example in monad transformers... so *must* be included this time - omitted from Haskell 98 because "the right design" wasn't clear - it's still unclear! Functional dependencies *in some form* are essential, but associated types and datatypes look nicer in many ways! - is it too late, in practice, to replace fundeps by something else? How will we know? If we are to standardize on associated types instead, we need a major effort to *make sure* all important applications of fundeps can be represented. How will we organize that?
I agree that MPTCs are much less useful (though not completely useless) without something like FDs or associated types. But the specification of FDs is far from clear: the system described in Mark's paper is quite a bit weaker than what is implemented by GHC and (more shakily) by Hugs. It seems that associated types aren't ready yet, but I don't think FDs are either, accustomed as people are to them. I have another worry about MPTCs. They require require relaxations on the form of instances (FlexibleInstances on the wiki), which in turn require relaxations on contexts and thus deferred context reduction (see FlexibleContexts). The result is that missing instances get reported later than they do now. MPTCs are very useful and probably necessary, but there is a cost.
On Thu, Feb 02, 2006 at 11:38:07AM +0100, John Hughes wrote:
The problem with Haskell 98 is that it *lacks* features which have become absolutely essential to Haskell programmers today. Those features are what really *need* discussion and energy spent on them. [...] I'd like to see clearer priorities and a more focussed discussion--maybe the Wiki can be used to help?
As a small part of that, the tickets page has a tentative list of "probably yes" changes. Personally, I'm not sure about caseless underscore, concurrency, natural numbers and parallel list comprehensions.
On Thu, Feb 02, 2006 at 01:05:57PM +0000, Ross Paterson wrote:
Personally, I'm not sure about caseless underscore, concurrency, natural numbers and parallel list comprehensions.
There is one more reason to leave concurrency out of the standard. Some experts (like Hans Boehm) argue, that concurrency can't be added to the language as a library. http://www.hpl.hp.com/techreports/2004/HPL-2004-209.pdf This is true for many imperative programming languages. Haskell seems to be an exception: http://www.haskell.org//pipermail/glasgow-haskell-users/2005-December/009417... We don't have any problems with ensuring good cooperation between mutable variables and concurrency synchronisation primitives, because the language doesn't have mutable variables, they are delivered in the concurrency library - the variables _are_ the synchronisation primitives. If we add concurrency to the standard, we'll be in a strange situation. In future discussions about language design and concurrency, all we will be able to say to highlight Haskell's strengths will be something like this: The design of Haskell was so great, that we could add concurrency as a library without introducing any problems... but we have concurrency in the standard anyway... ;-) Best regards Tomasz -- I am searching for programmers who are good at least in (Haskell || ML) && (Linux || FreeBSD || math) for work in Warsaw, Poland
Hello Tomasz, Friday, February 03, 2006, 10:52:22 AM, you wrote:
Personally, I'm not sure about caseless underscore, concurrency, natural numbers and parallel list comprehensions.
TZ> The design of Haskell was so great, that we could add concurrency as TZ> a library without introducing any problems... but we have TZ> concurrency in the standard anyway... concurrency should go into the Standard Library specification. there is just nothing to say about this in the _language_ standard -- Best regards, Bulat mailto:bulatz@HotPOP.com
On Fri, Feb 03, 2006 at 12:43:24PM +0300, Bulat Ziganshin wrote:
Friday, February 03, 2006, 10:52:22 AM, you wrote:
Personally, I'm not sure about caseless underscore, concurrency, natural numbers and parallel list comprehensions.
TZ> The design of Haskell was so great, that we could add concurrency as TZ> a library without introducing any problems... but we have TZ> concurrency in the standard anyway...
concurrency should go into the Standard Library specification. there is just nothing to say about this in the _language_ standard
Agreed! Best regards Tomasz -- I am searching for programmers who are good at least in (Haskell || ML) && (Linux || FreeBSD || math) for work in Warsaw, Poland
Hello Tomasz, Friday, February 03, 2006, 2:00:23 PM, you wrote:
Personally, I'm not sure about caseless underscore, concurrency, natural numbers and parallel list comprehensions.
TZ> The design of Haskell was so great, that we could add concurrency as TZ> a library without introducing any problems... but we have TZ> concurrency in the standard anyway...
concurrency should go into the Standard Library specification. there is just nothing to say about this in the _language_ standard
TZ> Agreed! well, there is just one exception - _foreign_ functions should carry "blockable" specification. that will only emphasize imperfection of non-Haskell world :))) -- Best regards, Bulat mailto:bulatz@HotPOP.com
On Fri, Feb 03, 2006 at 12:00:23PM +0100, Tomasz Zielonka wrote:
TZ> The design of Haskell was so great, that we could add concurrency as TZ> a library without introducing any problems... but we have TZ> concurrency in the standard anyway...
concurrency should go into the Standard Library specification. there is just nothing to say about this in the _language_ standard
Agreed!
We should be careful to not take too narrow a view of the meaning of the word "language", or at least not in the public output of this group. Many people would, for instance, consider the standard set of libraries in Java to be part of the language. The same could be said for Perl and Python. -- John
On Friday 03 February 2006 08:52, Tomasz Zielonka wrote:
On Thu, Feb 02, 2006 at 01:05:57PM +0000, Ross Paterson wrote:
Personally, I'm not sure about caseless underscore, concurrency, natural numbers and parallel list comprehensions.
There is one more reason to leave concurrency out of the standard.
Some experts (like Hans Boehm) argue, that concurrency can't be added to the language as a library. http://www.hpl.hp.com/techreports/2004/HPL-2004-209.pdf
This is true for many imperative programming languages. Haskell seems to be an exception:
http://www.haskell.org//pipermail/glasgow-haskell-users/2005-December /009417.html
We don't have any problems with ensuring good cooperation between mutable variables and concurrency synchronisation primitives, because the language doesn't have mutable variables, they are delivered in the concurrency library - the variables _are_ the synchronisation primitives.
What about IORefs? Ben
On Sun, Feb 05, 2006 at 01:21:08AM +0100, Benjamin Franksen wrote:
We don't have any problems with ensuring good cooperation between mutable variables and concurrency synchronisation primitives, because the language doesn't have mutable variables, they are delivered in the concurrency library - the variables _are_ the synchronisation primitives.
What about IORefs?
They are not part of Haskell 98 ;-) The question is if they will be added to Haskell'? I guess they will, so you have a point 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
Hello Tomasz, Sunday, February 05, 2006, 2:45:44 PM, you wrote:
We don't have any problems with ensuring good cooperation between mutable variables and concurrency synchronisation primitives, because the language doesn't have mutable variables, they are delivered in the concurrency library - the variables _are_ the synchronisation primitives.
What about IORefs?
TZ> They are not part of Haskell 98 ;-) TZ> The question is if they will be added to Haskell'? I guess they will, so TZ> you have a point here. the _language_ anyway don't have mutables, it's a part of library -- Best regards, Bulat mailto:bulatz@HotPOP.com
On 05/02/06, Bulat Ziganshin
Hello Tomasz,
Sunday, February 05, 2006, 2:45:44 PM, you wrote:
We don't have any problems with ensuring good cooperation between mutable variables and concurrency synchronisation primitives, because the language doesn't have mutable variables, they are delivered in the concurrency library - the variables _are_ the synchronisation primitives.
What about IORefs?
TZ> They are not part of Haskell 98 ;-)
TZ> The question is if they will be added to Haskell'? I guess they will, so TZ> you have a point here.
the _language_ anyway don't have mutables, it's a part of library
Well, sort of. I suppose it's the same issue as with concurrency itself. It's a library with runtime support. - Cale
On Thu, 2006-02-02 at 11:38 +0100, John Hughes wrote:
For the last few days, my mail-box has been full of mail about the M-R, lazy pattern matching, n+k patterns, comment syntax--it's just like the good old days! And that worries me.
Each of these topics is a snake pit--a tricky area of language design, with many alternative possibilities and no clear winner. As such, they make great discussion topics--if you want to start a heated argument, just propose a change to one of these (mea culpa)! We've also been discussing most of them for sixteen years. (snip)
I hope that we can avoid rehashing discussion where possible. That means going out and looking for objective information and putting it on the wiki for everyone to see. That means making ourselves aware (if we aren't already) of past discussions. I hope that those who were around "in the good old days" will consistently interrupt threads with "we had this discussion on march 10th 1994 and here's what we came up with. I put the summary up on the wiki along with links to two papers". That's everyone's job, but especially the committee :) peace, isaac
participants (12)
-
Ben Rudiak-Gould -
Benjamin Franksen -
Bulat Ziganshin -
Cale Gibbard -
Duncan Coutts -
Ian Lynagh -
isaac jones -
Johannes Waldmann -
John Goerzen -
John Hughes -
Ross Paterson -
Tomasz Zielonka