Re: Status of Haskell'?
Hi Malcolm, On Wed, Dec 12, 2012 at 10:40:53AM +, Malcolm Wallace wrote: Please send nominations to haskell-2011-commit...@haskell.org, summarising your interest and experience. The existing committee will (I hope) make some decision on how to proceed, in early January 2013. Any progress on this? Thanks Ian ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Status of Haskell'?
The committee has received no nominations. I have asked the committee whether they would like to disband.Regards, MalcolmOn 01 Feb, 2013,at 05:17 PM, Ian Lynagh i...@well-typed.com wrote: Hi Malcolm, On Wed, Dec 12, 2012 at 10:40:53AM +, Malcolm Wallace wrote:Please send nominations to haskell-2011-commit...@haskell.org, summarising your interest and experience. The existing committee will (I hope) make some decision on how to proceed, in early January 2013. Any progress on this? Thanks Ian ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Status of Haskell'?
On Fri, Feb 01, 2013 at 05:31:53PM +, Malcolm Wallace wrote: The committee has received no nominations. At least one was sent. Does haskell-2011-commit...@haskell.org accept mails from non-members? Thanks Ian ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Status of Haskell'?
On 28/12/2012, at 1:01, Ramana Kumar ram...@member.fsf.org wrote: On Wed, Dec 12, 2012 at 6:40 PM, Malcolm Wallace malcolm.wall...@me.com wrote: There is a mailing list for the members of the language committee: haskell-2011-commit...@haskell.org. Hi Malcolm, could you (or someone) help me out with a link to the archives (if any) for this list, and the listinfo page? http://www.haskell.org/mailman/listinfo/haskell-2011-committee But of course, those list archives are private. All substantive discussion is supposed to take place on the Haskell-prime list. The private committee list is only for administration, voting, choice of new committee members, etc. Regards, Malcolm ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Status of Haskell'?
On Fri, 28 Dec 2012 02:01:15 +0100, Ramana Kumar ram...@member.fsf.org wrote: Hi Malcolm, could you (or someone) help me out with a link to the archives (if any) for this list, and the listinfo page? http://www.haskell.org/pipermail/haskell-prime/ http://www.haskell.org/mailman/listinfo/haskell-prime Regards, Henk-Jan van Tuyl -- http://Van.Tuyl.eu/ http://members.chello.nl/hjgtuyl/tourdemonad.html Haskell programming -- ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Status of Haskell'?
I confess that I have not had enough free time in the last two years to have been a good chair for the language committee. (Using Haskell in the real world is just too absorbing!) I think the next chair should probably be an academic, who may have more incentive to spend effort on formalisation of the language design process than us industrial types. (At work, if we want a language extension, we just go ahead and implement it - job done.) There is a mailing list for the members of the language committee: haskell-2011-commit...@haskell.org. It has not seen any activity since 3 messages in October 2011, and prior to that, a thread of 13 messages in Nov/December 2010. Both of those threads were largely about the vanishingly small number of proposals to be decided upon, and whether to issue a new Report (the answer being no on both occasions). So, given that there are a few people who have expressed interest in reviving the language formalisation process, perhaps we should hold nominations for a new committee, in the spirit of the method outlined on the wiki page: http://hackage.haskell.org/trac/haskell-prime/wiki/Committee Please send nominations to haskell-2011-commit...@haskell.org, summarising your interest and experience. The existing committee will (I hope) make some decision on how to proceed, in early January 2013. Regards, Malcolm On 12 Dec 2012, at 02:42, Ramana Kumar wrote: Dear Malcolm, What is the current status of Haskell Prime, as far as you know? (Is there a better way to reach the Haskell Prime committee than just emailing the chair?) We have a few volunteers here looking to keep Haskell Prime moving forward, and Simon suggested following the tracks of earlier pioneers and resuming/joining where they left off. Cheers, Ramana ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Status of Haskell'?
Dear Malcolm, What is the current status of Haskell Prime, as far as you know? (Is there a better way to reach the Haskell Prime committee than just emailing the chair?) We have a few volunteers here looking to keep Haskell Prime moving forward, and Simon suggested following the tracks of earlier pioneers and resuming/joining where they left off. Cheers, Ramana On Tue, Dec 4, 2012 at 4:00 AM, Simon Peyton-Jones simo...@microsoft.comwrote: Stefan, John, Ramana all say: | I, for one, would love to help out! Great stuff. I think the first thing to do is to talk to the 2011 Haskell Prime committee http://hackage.haskell.org/trac/haskell-prime/wiki/Committee, and ask what the status is, as far as they know. Malcolm asked for proposals at the start of 2011 but I'm not sure if he actually received any, or what happened after that. There are guidelines for representation on the committee, and a process for forming a new committee on that page. The process part depends a bit on the old committee, and I don't know what they feel now that a gap year has gone by. But I'm sure they will appreciate your taking a lead in re-booting the process. Don't be put off by the talk of a committee. This isn't bureaucracy! To revise a community language standard there needs to be a group that leads the process. It needs to be big enough to have a diversity of view, but small enough to make progress. And that's our committee. Simon | -Original Message- | From: haskell-prime-boun...@haskell.org [mailto:haskell-prime- | boun...@haskell.org] On Behalf Of Stefan Holdermans | Sent: 02 December 2012 10:24 | To: haskell-prime@haskell.org | Subject: Re: Status of Haskell'? | | Simon wrote: | | I'm sure that any solution will involve (as it did in earlier stages) | motivated individuals who are willing to take up leadership roles in | developing Haskell's language definition. I'm copying this to the main | Haskell list, in the hope of attracting volunteers! | | | Cheers, | | Stefan | ___ | 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: Status of Haskell'?
On Sun, Dec 02, 2012 at 07:56:57PM +, Gábor Lehel wrote: Out of curiosity, to what degree does MultiParamTypeClasses have this issue? It seems to me like one of the few extensions which is straightforward, widely implemented, uncontroversial, and very useful. There's some discussion of the linkages at http://hackage.haskell.org/trac/haskell-prime/wiki/MultiParamTypeClasses Without FlexibleInstances, each argument in an instance must be a type constructor applied to type variables, with no repetition of type variables across the head. That would rule out instances like these from the array packages: instance IArray Array e instance MArray (STArray s) e (ST s) instance Storable e = MArray StorableArray e Even without these, when reducing contexts you encounter situations where one argument has a type constructor and another is a type variable. So you have to change the notions of simple context and context reduction errors (section 4.5.3). GHC avoids that by deferring context reduction, but that opens a whole other can of worms. ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Status of Haskell'?
Simon wrote: I’m sure that any solution will involve (as it did in earlier stages) motivated individuals who are willing to take up leadership roles in developing Haskell’s language definition. I’m copying this to the main Haskell list, in the hope of attracting volunteers! I, for one, would love to help out! Cheers, Stefan ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Status of Haskell'?
On Fri, Nov 30, 2012 at 11:05:41PM +, Gábor Lehel wrote: Well, I'm not so sure it's a great idea to just bake what GHC does at this moment (for any particular extension) into the standard without really thinking about it. Even then, you have to figure out, in great detail, what GHC does, and write it all down! That's not negligible effort, either. And that is the core of the problem. The standard isn't just a list of approved features. It needs to describe them in such detail that a programmer can tell, from the Report alone, whether a particular program is legal, and if so what it's supposed to do. We don't have that level of description for these extensions, and creating it will be a lot of hard work. Relying on what GHC does at the moment has obvious risks for programmers, it also puts an unfair responsibility on GHC itself. How can they improve a feature if it's current implementation is the standard? ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Status of Haskell'?
This is a significant problem for even some of the more ubiquitous extensions. For instance, there are multiple compilers that implement RankNTypes, but I would not be surprised at all if programs using that extension were not portable across implementations (they're not really even portable across GHC versions). The problem is that RankNTypes is not just about the fact that you are allowed to use such types; every compiler must decide on an inference algorithm that incorporates such types while defaulting to Hindley-Milner. But, there are several such algorithms, and they have different trade offs as far as where annotations must be placed, or even whether certain conceivably well-typed terms are type checkable (for instance, GHC used to do some level of impredicative instantiation; forall a. a - a could be instantiated to (forall a. a) - (forall a. a); but this no longer works). So, even if we have ubiquitous agreement on the fact that RankNTypes are useful, and implementable, we don't have ubiquitous agreement on the algorithms for implementing them, and which set of trade offs to make. But any standard would have to nail all that down, or else programs won't be portable. And this is not the only extension for which this kind of thing is an issue. -- Dan On Sun, Dec 2, 2012 at 6:42 AM, Ross Paterson r...@soi.city.ac.uk wrote: On Fri, Nov 30, 2012 at 11:05:41PM +, Gábor Lehel wrote: Well, I'm not so sure it's a great idea to just bake what GHC does at this moment (for any particular extension) into the standard without really thinking about it. Even then, you have to figure out, in great detail, what GHC does, and write it all down! That's not negligible effort, either. And that is the core of the problem. The standard isn't just a list of approved features. It needs to describe them in such detail that a programmer can tell, from the Report alone, whether a particular program is legal, and if so what it's supposed to do. We don't have that level of description for these extensions, and creating it will be a lot of hard work. Relying on what GHC does at the moment has obvious risks for programmers, it also puts an unfair responsibility on GHC itself. How can they improve a feature if it's current implementation is the standard? ___ 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: Status of Haskell'?
On Sun, Dec 2, 2012 at 7:06 PM, Dan Doel dan.d...@gmail.com wrote: This is a significant problem for even some of the more ubiquitous extensions. For instance, there are multiple compilers that implement RankNTypes, but I would not be surprised at all if programs using that extension were not portable across implementations (they're not really even portable across GHC versions). The problem is that RankNTypes is not just about the fact that you are allowed to use such types; every compiler must decide on an inference algorithm that incorporates such types while defaulting to Hindley-Milner. But, there are several such algorithms, and they have different trade offs as far as where annotations must be placed, or even whether certain conceivably well-typed terms are type checkable (for instance, GHC used to do some level of impredicative instantiation; forall a. a - a could be instantiated to (forall a. a) - (forall a. a); but this no longer works). So, even if we have ubiquitous agreement on the fact that RankNTypes are useful, and implementable, we don't have ubiquitous agreement on the algorithms for implementing them, and which set of trade offs to make. But any standard would have to nail all that down, or else programs won't be portable. And this is not the only extension for which this kind of thing is an issue. Out of curiosity, to what degree does MultiParamTypeClasses have this issue? It seems to me like one of the few extensions which is straightforward, widely implemented, uncontroversial, and very useful. For some reason it's been held up by the FDs vs TFs debate, but I don't see why it has to be. Vanilla MPTCs on the one hand, and MPTCs together with either FDs or TFs on the other hand, serve different use cases. If you want a plain type-level relation on types, you use MPTCs. If you want some types to be determined by others, then you use either FDs or TFs. If we standardize support for the former, that's useful, even if we continue to procrastinate on the FDs vs TFs question. So if the idea is to do yearly incremental updates to the standard, MPTCs looks like the biggest low-hanging fruit to me. (Assuming they aren't similarly problematic as RankNTypes.) -- Your ship was destroyed in a monadic eruption. ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Status of Haskell'?
As far as I know, MPTCs alone do not have this issue. But functional dependencies do, as there are at least two ways they can behave. One is the way they traditionally behave in GHC, and another is the way they would behave if they were sugar for type families. I can't think of anything about MPTCs alone that would be a problem, though. On Sun, Dec 2, 2012 at 2:56 PM, Gábor Lehel illiss...@gmail.com wrote: On Sun, Dec 2, 2012 at 7:06 PM, Dan Doel dan.d...@gmail.com wrote: This is a significant problem for even some of the more ubiquitous extensions. For instance, there are multiple compilers that implement RankNTypes, but I would not be surprised at all if programs using that extension were not portable across implementations (they're not really even portable across GHC versions). The problem is that RankNTypes is not just about the fact that you are allowed to use such types; every compiler must decide on an inference algorithm that incorporates such types while defaulting to Hindley-Milner. But, there are several such algorithms, and they have different trade offs as far as where annotations must be placed, or even whether certain conceivably well-typed terms are type checkable (for instance, GHC used to do some level of impredicative instantiation; forall a. a - a could be instantiated to (forall a. a) - (forall a. a); but this no longer works). So, even if we have ubiquitous agreement on the fact that RankNTypes are useful, and implementable, we don't have ubiquitous agreement on the algorithms for implementing them, and which set of trade offs to make. But any standard would have to nail all that down, or else programs won't be portable. And this is not the only extension for which this kind of thing is an issue. Out of curiosity, to what degree does MultiParamTypeClasses have this issue? It seems to me like one of the few extensions which is straightforward, widely implemented, uncontroversial, and very useful. For some reason it's been held up by the FDs vs TFs debate, but I don't see why it has to be. Vanilla MPTCs on the one hand, and MPTCs together with either FDs or TFs on the other hand, serve different use cases. If you want a plain type-level relation on types, you use MPTCs. If you want some types to be determined by others, then you use either FDs or TFs. If we standardize support for the former, that's useful, even if we continue to procrastinate on the FDs vs TFs question. So if the idea is to do yearly incremental updates to the standard, MPTCs looks like the biggest low-hanging fruit to me. (Assuming they aren't similarly problematic as RankNTypes.) -- Your ship was destroyed in a monadic eruption. ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: [Haskell] Status of Haskell'?
* Henning Thielemann lemm...@henning-thielemann.de [2012-12-01 00:37:12+0100] We should have multiple implementations before standardization. Alternative implementations already exist for lots of extenstions, see http://hackage.haskell.org/trac/haskell-prime/wiki/HaskellExtensions Roman ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: [Haskell] Status of Haskell'?
* Tijn van der Zant robot...@gmail.com [2012-12-01 10:00:31+0100] Why do I need to know about pragmas if it is already difficult to learn the language? Exactly. In an ideal world, where the language standard corresponds to what people perceive as being standard, beginners shouldn't know or care about pragmas, which by definition enable non-portable and experimental features. And the last thing a beginner should do is to enable ALL of those obscure features. (and they just turn a load of them on without even thinking about it what they do, but hey, the code works now!...) That is an unfortunate situation in which we are now, and which could be improved by releasing a new standard incorporating the most tested and widely-used features. Roman ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Status of Haskell'?
* Simon Peyton-Jones simo...@microsoft.com [2012-11-30 16:36:01+] Why not? I don't think it's laziness or selfishness; just look at how helpful people are on the mailing list. Rather, I am guessing that it's a subconscious assessment of cost/benefit. The cost is certainly significant, and (unlike a quick email response on Haskell Cafe) takes place over months. The benefit, for an individual, is harder to articulate. GHC defines a de-facto standard, simply by existing, and for many practical purposes that is good enough. However, GHC is (quite consciously) exploring stuff that may or may not ultimately turn out to be a good idea: it's a laboratory, not an every-detail-thought-out product. [Though of course we try hard to be good enough for production use.] So there is real merit in having a group, not too closely coupled to GHC, that picks off the best ideas and embodies them in a language standard. But if for any one individual, GHC is good enough, then the benefits of a language standard may seem distant and diffuse. I don't have a solution to this particular conundrum. As many of you will remember, the Haskell Prime processhttp://hackage.haskell.org/trac/haskell-prime/wiki/Process was itself developed in response to a sense that making a big iteration of the language was so large a task that no one felt able to even begin it. Hence the deliberately more incremental nature of Haskell Prime; but even this lighter-weight process is rather stuck. I'm sure that any solution will involve (as it did in earlier stages) motivated individuals who are willing to take up leadership roles in developing Haskell's language definition. I'm copying this to the main Haskell list, in the hope of attracting volunteers! Thanks — I think this is a good analysis of the situation. One thing I'd like to add is that working on the standard not only takes more effort compared to responding on the mailing list, but it also requires a much higher level of competence. Roman ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: [Haskell] Status of Haskell'?
2012/12/1 Tijn van der Zant robot...@gmail.com: I think that there is more to take into account. Haskell is growing as a language that people use to solve scientific and business problems. It is starting to become more of a working language, which is a very good thing of course. But this also means that Haskell should accommodate the people who are only working with it (not developing the language) and might not have a clue about the developers of the language. I'm somewhere in between where I love to read about the developments (this is my first post) and use it to program robots in my lab (besides some other languages). To accommodate the people who just want to use Haskell, we might have a super-pragma (as previously proposed) and for those gaining skill it should be possible to subtract pragmas until you have turned them all off and you can call yourself a Haskell guru. Mind you, I am not one of those, simply because I have to program in 5 languages for my work. For me, all those pragmas are not a matter of ugliness, but more an annoyance. For starters it is even worse. They ask questions such as: What do I turn on? Did I already find a good pragma tutorial? Why do I need to know about pragmas if it is already difficult to learn the language? By subtracting the pragmas (or turning them off) people can learn what they actually do and improve their code and their thinking about the language. Quite often I need the get something done, and due to time pressure I do not always have the luxury to make the code beautiful. And since it is Haskell (if it compiles it probably does what you want) I do not always care. For many users, pragmas are a Haskell concept that they can live without in the first part of their Haskell programming career (and they just turn a load of them on without even thinking about it what they do, but hey, the code works now!...) I think that we should accommodate the 'working programmers' and make their life a little bit easier, so that it becomes easier to start programming in Haskell and the language can be put to use by more people. This does not exclude having a 'pragma prime' that includes proposals for Haskell' of course. But it would help people starting with Haskell a lot imho. Thank you for highlighting the many ways in which pragmas are a problem from a practical point of view. -- Jason Dusek pgp // solidsnack // C1EBC57DC55144F35460C8DF1FD4C6C1FED18A2B ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Status of Haskell'?
2012/11/30 Gábor Lehel illiss...@gmail.com: Well, I'm not so sure it's a great idea to just bake what GHC does at this moment (for any particular extension) into the standard without really thinking about it. Even then, you have to figure out, in great detail, what GHC does, and write it all down! That's not negligible effort, either. And the alternative is to also publicly discuss and hash all of it out down to the little tiny gritty stuff. But wanting to write a new standard (big effort!) just to get rid of some pragmas and make people feel better (small payoff!) feels like a mismatch to me. It is a large payoff, considering the thousands and thousands of people that it creates a small payoff for: people writing Haskell, people learning Haskell, people teaching Haskell. A standard is a lot of effort for a handful of people. -- Jason Dusek pgp // solidsnack // C1EBC57DC55144F35460C8DF1FD4C6C1FED18A2B ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
RE: Status of Haskell'?
I'd argue that it's not. Haskell hasn't had a release in years, and I think it's time to put a little pressure on the community. The question is: who is the community? It's fairly clear that the Haskell Prime process itself is languishing. The last message about the development process that I can find is this one from Malcolm Wallacehttp://www.haskell.org/pipermail/haskell-prime/2011-January/003335.html, in January 2011. But please don't blame Malcolm or the committeehttp://hackage.haskell.org/trac/haskell-prime/wiki/Committee. Developing new, well-specified changes to Haskell will only happen if there is a vigorous eco-system of folk who are prepared to devote the love and time to do it. There are plenty of people (myself among them) who would be delighted if there was a series of well-specified updates to the Haskell standard; but it is harder to assemble a group that is willing to move that process forward. Why not? I don't think it's laziness or selfishness; just look at how helpful people are on the mailing list. Rather, I am guessing that it's a subconscious assessment of cost/benefit. The cost is certainly significant, and (unlike a quick email response on Haskell Cafe) takes place over months. The benefit, for an individual, is harder to articulate. GHC defines a de-facto standard, simply by existing, and for many practical purposes that is good enough. However, GHC is (quite consciously) exploring stuff that may or may not ultimately turn out to be a good idea: it's a laboratory, not an every-detail-thought-out product. [Though of course we try hard to be good enough for production use.] So there is real merit in having a group, not too closely coupled to GHC, that picks off the best ideas and embodies them in a language standard. But if for any one individual, GHC is good enough, then the benefits of a language standard may seem distant and diffuse. I don't have a solution to this particular conundrum. As many of you will remember, the Haskell Prime processhttp://hackage.haskell.org/trac/haskell-prime/wiki/Process was itself developed in response to a sense that making a big iteration of the language was so large a task that no one felt able to even begin it. Hence the deliberately more incremental nature of Haskell Prime; but even this lighter-weight process is rather stuck. I'm sure that any solution will involve (as it did in earlier stages) motivated individuals who are willing to take up leadership roles in developing Haskell's language definition. I'm copying this to the main Haskell list, in the hope of attracting volunteers! Simon From: haskell-prime-boun...@haskell.org [mailto:haskell-prime-boun...@haskell.org] On Behalf Of Nate Soares Sent: 27 November 2012 22:44 To: Ben Millwood Cc: haskell-prime@haskell.org Prime Subject: Re: Status of Haskell'? it might be wise to see what GHC decides to do on that front, first, I'd argue that it's not. Haskell hasn't had a release in years, and I think it's time to put a little pressure on the community. On Tue, Nov 27, 2012 at 2:15 PM, Ben Millwood hask...@benmachine.co.ukmailto:hask...@benmachine.co.uk wrote: On Tue, Nov 27, 2012 at 5:35 PM, Ian Lynagh ig...@earth.limailto:ig...@earth.li wrote: [...] adding DeriveDataTypeable hopefully wouldn't be too controversial [...] This is a little tricky since the Data class itself makes (essential, I think) use of Rank2Types. Typeable ought to be fine, but it might be wise to see what GHC decides to do on that front, first, e.g. whether it's going to autoderive all instances or forbid user instances or anything else similarly bold. ___ Haskell-prime mailing list Haskell-prime@haskell.orgmailto: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: Status of Haskell'?
don't need a new standard right now. If people don't think it's worth their while to work on it, they're probably right. New, competing implementations might be valuable. If we have them, there will be demand for a standard, making decisions about it will be easier, and it will probably be better. That's my two forints. - Gábor * I don't actually like ponies, but I suppose everyone else does. From: haskell-prime-boun...@haskell.org [mailto:haskell-prime-boun...@haskell.org] On Behalf Of Nate Soares Sent: 27 November 2012 22:44 To: Ben Millwood Cc: haskell-prime@haskell.org Prime Subject: Re: Status of Haskell'? it might be wise to see what GHC decides to do on that front, first, I'd argue that it's not. Haskell hasn't had a release in years, and I think it's time to put a little pressure on the community. On Tue, Nov 27, 2012 at 2:15 PM, Ben Millwood hask...@benmachine.co.uk wrote: On Tue, Nov 27, 2012 at 5:35 PM, Ian Lynagh ig...@earth.li wrote: [...] adding DeriveDataTypeable hopefully wouldn't be too controversial [...] This is a little tricky since the Data class itself makes (essential, I think) use of Rank2Types. Typeable ought to be fine, but it might be wise to see what GHC decides to do on that front, first, e.g. whether it's going to autoderive all instances or forbid user instances or anything else similarly bold. ___ 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 -- Your ship was destroyed in a monadic eruption. ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Status of Haskell'?
2012/11/30 Gábor Lehel illiss...@gmail.com: Executive summary: We don't need a new standard right now. If people don't think it's worth their while to work on it, they're probably right. New, competing implementations might be valuable. If we have them, there will be demand for a standard, making decisions about it will be easier, and it will probably be better. It would be nice for there to be a new standard so that many features in GHC -- such as overloaded strings, rank n types, MPTCs, c. -- were enabled by default without any pragmas. This standardization process amounts to endorsement of existing features which seems like not a bad process at all. It makes the standard descriptive rather than predictive. -- Jason Dusek pgp // solidsnack // C1EBC57DC55144F35460C8DF1FD4C6C1FED18A2B ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Status of Haskell'?
This standardization process amounts to endorsement of existing features which seems like not a bad process at all. It makes the standard descriptive rather than predictive. +1. I agree generally with Gabor's points -- GHC is in the drivers seat. But at some point we should take a look at all the things GHC has made that did pay off and that are good and make them official. I'd very much like to see that endorsement happen soon, even if it's not aggressive. ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: [Haskell] Status of Haskell'?
On Fri, Nov 30, 2012 at 1:42 PM, Jason Dusek jason.du...@gmail.com wrote: It would be nice for there to be a new standard so that many features in GHC -- such as overloaded strings, rank n types, MPTCs, c. -- were enabled by default without any pragmas. I think this is one of these nice gains for day-to-day Haskell programming. Less typing and fewer things to explain to beginners (You see, this might seem like an experimental feature I'm asking you to use, but it really isn't.) -- Johan ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Status of Haskell'?
* Brandon Allbery allber...@gmail.com [2012-11-27 11:44:51-0500] On Tue, Nov 27, 2012 at 10:50 AM, Nate Soares n...@so8r.es wrote: I second this question. At what point do we cut Haskell' with what we have, release it, and push the big undecideds back to Haskell? Maybe the question is whether we have anything. We already skipped 2011 because there wasn't anything worth the effort of a new standard. How about MultiParamTypeClasses, RankNTypes, ExistentialQuantification, GADTs? They've been around for quite some time and turned out very useful in practice. Roman ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Status of Haskell'?
On Tue, Nov 27, 2012 at 12:07 PM, Roman Cheplyaka r...@ro-che.info wrote: Maybe the question is whether we have anything. We already skipped 2011 because there wasn't anything worth the effort of a new standard. How about MultiParamTypeClasses, RankNTypes, ExistentialQuantification, Do we have a definitive go/no-go on the FDs vs. TFs question yet? I thought MPTC was not considered usable without one of those, and neither is yet considered standard (with some good reason in the case of FDs). -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix/linux, openafs, kerberos, infrastructure http://sinenomine.net ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Status of Haskell'?
I think it has proven out pretty well in practice that probably want both in the surface language. I know minimalists on the TF side of the debate have tried to make the case that you don't even need FDs in the surface syntax, but there are lots of places where it having a class with multiple directional constraints makes the code much, much more sane. I would be loathe to sacrifice either of them. -Edward On Tue, Nov 27, 2012 at 12:11 PM, Brandon Allbery allber...@gmail.comwrote: uestion yet? I thought MPTC was not considered usable without one of those, and neither is yet considered standard (with some good reason in the case of FDs). ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Status of Haskell'?
* Brandon Allbery allber...@gmail.com [2012-11-27 12:11:43-0500] On Tue, Nov 27, 2012 at 12:07 PM, Roman Cheplyaka r...@ro-che.info wrote: Maybe the question is whether we have anything. We already skipped 2011 because there wasn't anything worth the effort of a new standard. How about MultiParamTypeClasses, RankNTypes, ExistentialQuantification, Do we have a definitive go/no-go on the FDs vs. TFs question yet? I thought MPTC was not considered usable without one of those, and neither is yet considered standard (with some good reason in the case of FDs). I see MPTCs and TFs as independent, in the sense that each one is usable without the other. MPTCs allow the implementation to depend on multiple types, while TFs allow the implementation *and* some other types to depend on one type. Of course, in combination they are even more powerful, allowing to have several basis types and several dependent types. FDs are a bit different because they are not usable without MPTC. Thus, FDs aside, MPTC usefulness should not depend on whether we accept TFs. (FWIW, I agree with Edward that both FDs and TFs are very useful in practice.) Roman ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Status of Haskell'?
On Tue, Nov 27, 2012 at 5:35 PM, Ian Lynagh ig...@earth.li wrote: [...] adding DeriveDataTypeable hopefully wouldn't be too controversial [...] This is a little tricky since the Data class itself makes (essential, I think) use of Rank2Types. Typeable ought to be fine, but it might be wise to see what GHC decides to do on that front, first, e.g. whether it's going to autoderive all instances or forbid user instances or anything else similarly bold. ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Status of Haskell'?
it might be wise to see what GHC decides to do on that front, first, I'd argue that it's not. Haskell hasn't had a release in years, and I think it's time to put a little pressure on the community. On Tue, Nov 27, 2012 at 2:15 PM, Ben Millwood hask...@benmachine.co.ukwrote: On Tue, Nov 27, 2012 at 5:35 PM, Ian Lynagh ig...@earth.li wrote: [...] adding DeriveDataTypeable hopefully wouldn't be too controversial [...] This is a little tricky since the Data class itself makes (essential, I think) use of Rank2Types. Typeable ought to be fine, but it might be wise to see what GHC decides to do on that front, first, e.g. whether it's going to autoderive all instances or forbid user instances or anything else similarly bold. ___ 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: Status of Haskell Prime Language definition
Iavor Diatchki wrote: http://hackage.haskell.org/trac/haskell-prime/wiki/FunctionalDependencies#Lossofconfluence There is nothing about the system being unsound there. Furthermore, I am unclear about the problem described by the link... The two sets of predicates are logically equivalent (have the same set of ground instances), here is a full derivation: (B a b, C [a] c d) using the instance (B a b, C [a] c d, C [a] b Bool) using the FD rule (B a b, C [a] c d, C [a] b Bool, b = c) using b = c (B a b, C [a] c d, C [a] b Bool, b = c, C [a] b d) omitting unnecessary predicates and rearranging: (b = c, B a b, C [a] b d) The derivation in the other direction is much simpler: (b = c, B a b, C [a] b d) using b = c (b = c, B a b, C [a] b d, C [a] c d) omitting unnecessary predicates (B a b, C [a] c d) You're right, I think I'm mixing up soundness with completeness and termination. My thought was that not explicitly mentioning the b=c constraint could lead to the type inference silently dropping this fact and letting an inconsistent set of instance declarations go through without noticing. But that would only be important in a setting where inconsistent instances are not reported early via the consistency condition but late when actually constructing terms. The consistency condition should be enough for soundness (no inconsistent axioms accepted), but I didn't dwell enough into FD to know such things for sure. Regards, apfelmus ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Status of Haskell Prime Language definition
Robert Will wrote: Could someone please summarize the current status and planned time line for Haskell'? John Launchbury wrote: Up to now, the Haskell' effort has been mostly about exploring the possibilities, to find out what could be in Haskell', and to scope out what it might mean. We've now reached the stage where we want to do the opposite, namely trying to pin down what we definitely want to have in the standard, and what it should look like in detail. There's still a major technical obstacle, namely functional dependencies vs associated type synonyms . Some functionality for programming in the type system is needed for Haskell' but fundeps are too tricky to get powerful and sound at the same time. The problem with their promising alternative of associated type synonyms is that they're very young with their first official release being the upcoming GHC 6.8 . So, they have to stand some test of time before Haskell' can pick one of the two (probably the latter). Regards, apfelmus ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Status of Haskell Prime Language definition
Iavor Diatchki wrote: apfelmus wrote: fundeps are too tricky to get powerful and sound at the same time. I am not aware of any soundness problems related to functional dependencies---could you give an example? http://hackage.haskell.org/trac/haskell-prime/wiki/FunctionalDependencies#Lossofconfluence But I should have said sound, complete and decidable instead :) Regards, apfelmus ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Status of Haskell Prime Language definition
On Tue, 16 Oct 2007, apfelmus wrote: Robert Will wrote: Could someone please summarize the current status and planned time line for Haskell'? John Launchbury wrote: Up to now, the Haskell' effort has been mostly about exploring the possibilities, to find out what could be in Haskell', and to scope out what it might mean. We've now reached the stage where we want to do the opposite, namely trying to pin down what we definitely want to have in the standard, and what it should look like in detail. There's still a major technical obstacle, namely functional dependencies vs associated type synonyms . The right thing is probably to admit that it's going to take a few years to resolve adequately, get a standard now and get a new standard or an addendum when those few years are up. This has the problem that it leaves us with crippled interfaces for standard libraries, but we already have that problem! -- [EMAIL PROTECTED] Sometimes you gotta fight fire with fire. Most of the time you just get burnt worse though. ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Status of Haskell Prime Language definition
Hello, On 10/16/07, apfelmus [EMAIL PROTECTED] wrote: Iavor Diatchki wrote: apfelmus wrote: fundeps are too tricky to get powerful and sound at the same time. I am not aware of any soundness problems related to functional dependencies---could you give an example? http://hackage.haskell.org/trac/haskell-prime/wiki/FunctionalDependencies#Lossofconfluence But I should have said sound, complete and decidable instead :) There is nothing about the system being unsound there. Furthermore, I am unclear about the problem described by the link... The two sets of predicates are logically equivalent (have the same set of ground instances), here is a full derivation: (B a b, C [a] c d) using the instance (B a b, C [a] c d, C [a] b Bool) using the FD rule (B a b, C [a] c d, C [a] b Bool, b = c) using b = c (B a b, C [a] c d, C [a] b Bool, b = c, C [a] b d) omitting unnecessary predicates and rearranging: (b = c, B a b, C [a] b d) The derivation in the other direction is much simpler: (b = c, B a b, C [a] b d) using b = c (b = c, B a b, C [a] b d, C [a] c d) omitting unnecessary predicates (B a b, C [a] c d) -- Iavor ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Status of Haskell Prime Language definition
Hi Robert, At the recent Haskell workshop, I stood up and gave the following summary (approximately): Up to now, the Haskell' effort has been mostly about exploring the possibilities, to find out what could be in Haskell', and to scope out what it might mean. We've now reached the stage where we want to do the opposite, namely trying to pin down what we definitely want to have in the standard, and what it should look like in detail. I've set aside a chunk of my own time this fall to help coordinate the activity, write text etc. I'm hoping that things should be pretty clear by early next year. I have spoken with CUP and JFP about publishing the standard as a special issue of JFP and as a book, and they are interested. The strawman timeline for that is early next summer. Hope this helps, John On Oct 11, 2007, at 9:34 PM, Robert Will wrote: Hi all, When I first discovered Haskell' I was really excited to hear that many of the individual extensions that are already used by many people are going to be put together to one coherent next release. I have read the archive of the Haskell Prime Mailing list for all of 2007 as well as a lot of pages on Haskell.org and in the Haskell Prime Wiki, yet the most recent status report that I found is the one in the wiki from September 2006. (http://hackage.haskell.org/trac/haskell-prime/wiki/Status') Could someone please summarize the current status and planned time line for Haskell'? thanks a lot, Robert -- Skype: robert.will ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime John Launchbury | galois | (503)626-6616 x104 ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
