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
