Re[2]: Haskell 2010: libraries
Hello Ganesh, Tuesday, July 14, 2009, 10:48:36 AM, you wrote: I don't have any strong opinion about whether there should be a library standard or not, but if there is a standard, how about putting the entire thing (perhaps including the Prelude) under the prefix Haskell2010. or similar? Most of it could be implemented by just re-exporting things from the real libraries. we already have PvP mechanism for these things -- Best regards, Bulatmailto:bulat.zigans...@gmail.com ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re[2]: Haskell 2010: libraries
Hello Ian, Tuesday, July 14, 2009, 3:20:42 AM, you wrote: We've been fortunate recently that, because the hierarchical modules haven't been in the standard, we've been able to extend and improve them without breaking compatibility with the language definition. but breaking compatibility with existing programs. i hate situation when we need to reupload entire hackage every year -- Best regards, Bulatmailto:bulat.zigans...@gmail.com ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Proposal: change to qualified operator syntax
left section right section prefix unqualified (+ 1) (1 +) (+) Haskell 98 (M.+ 1) (1 M.+) (M.+) proposed (`M.(+)` 1) (1 `M.(+)`) M.(+) or(*) (M.(+) 1) (flip M.(+) 1) The last line is not correct. (M.(+) 1) captures the first argument of the function, not the second like all the other entries in that column. Likewise the flip variant captures the second arg, where all the others capture the first. Regards, Malcolm ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re[4]: Haskell 2010: libraries
Hello Ganesh, Tuesday, July 14, 2009, 11:59:00 AM, you wrote: I don't have any strong opinion about whether there should be a library standard or not, but if there is a standard, how about putting the entire thing (perhaps including the Prelude) under the prefix Haskell2010. or similar? Most of it could be implemented by just re-exporting things from the real libraries. we already have PvP mechanism for these things The PvP isn't (proposed as) part of the standard, and without package qualified imports as implemented by GHC, it wouldn't help anyway. but package versioning implemented by ghc, hugs and probably other compilers. with your idea we will have two things that address the same problem, and these will be miltiplied - i.e. we will carry several versions of base package, each having Haskell2010.*, Haskell2011.* and so on modules -- Best regards, Bulatmailto:bulat.zigans...@gmail.com ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Haskell 2010: libraries
A natural language consists of a vocabulary of words, as well as a grammar for stringing them together. If we omit the common basic libraries from the language definition, then are we implicitly reducing the common vocabulary, and encouraging dialects to appear? If I see the function scanr in a module, should I expect that it has the semantics of Data.List.scanr? Or is it OK for someone to define their own Data.List with different semantics? Keep the commonly used and uncontroversial (mostly pure) modules and rename them to use the new hierarchical module names. I would largely concur with this policy, with the caveat that additions to the API might appear in future. Also, the hierarchical versions of the FFI libraries are essential. 3. Numeric keep as Numeric (?) I think we could take the opportunity to rename it to Text.Numeric. Why Text? Because it only defines ReadS and ShowS things (with the exception of fromRat, and floatToDigits, sigh, which should be moved elsewhere). It'd be nice to have a clear dividing line of keeping the pure stuff and dropping the bits for interacting with the system ... The bits for interacting with the system are of course exactly the bits that are most prone to change and are most in need of improvement. In some ways, it is _more_ important to standardise the difficult bits, i.e. interacting with the system, because otherwise it is desparately difficult to write portable programs. But I agree that the choices made in H'98 and earlier to abstract over the underlying OS were probably rather poor and inflexible, and it is probably unrealistic to be able to propose a new stable API for a couple of years yet. I do think we should set it as a goal for the future however. Regards, Malcolm ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
RE: Re[4]: Haskell 2010: libraries
Bulat Ziganshin wrote: Hello Ganesh, Tuesday, July 14, 2009, 11:59:00 AM, you wrote: I don't have any strong opinion about whether there should be a library standard or not, but if there is a standard, how about putting the entire thing (perhaps including the Prelude) under the prefix Haskell2010. or similar? Most of it could be implemented by just re-exporting things from the real libraries. we already have PvP mechanism for these things The PvP isn't (proposed as) part of the standard, and without package qualified imports as implemented by GHC, it wouldn't help anyway. but package versioning implemented by ghc, hugs and probably other compilers. Do you mean the syntax that allows modules to be imported from a specified package? If so I didn't realise this was implemented by anything more than GHC. with your idea we will have two things that address the same problem, Arguably it is the ability to import from a specified package that duplicates the disambiguation mechanism provided by module names. and these will be miltiplied - i.e. we will carry several versions of base package, each having Haskell2010.*, Haskell2011.* and so on modules I'd expect the Haskell2010.* etc to be implemented in a haskell2010 package which depends on the relevant version of base. Obviously it would need to be updated when base was changed incompatibly. Having a library standard implies that implementations must support it for some period of time. I don't see why namespacing the libraries of that standard makes that any harder. Cheers, Ganesh === Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html === ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Haskell 2010: libraries
On Tue, 2009-07-14 at 00:20 +0100, Ian Lynagh wrote: On Mon, Jul 13, 2009 at 09:56:50PM +0100, Duncan Coutts wrote: I'd advocate 4. That is, drop the ones that are obviously superseded. Keep the commonly used and uncontroversial (mostly pure) modules and rename them to use the new hierarchical module names. Specifically, I suggest: 1. Ratio keep as Data.Ratio 2. Complex keep as Data.Complex 3. Numeric keep as Numeric (?) 4. Ix keep as Data.Ix 5. Array keep as Data.Array 6. Listkeep as Data.List 7. Maybe keep as Data.Maybe 8. Charkeep as Data.Char 9. Monad keep as Control.Monad 10. IO keep as System.IO 11. Directory drop 12. System drop (superseded by System.Process) 13. Timedrop 14. Locale drop 15. CPUTime drop 16. Random drop We've been fortunate recently that, because the hierarchical modules haven't been in the standard, we've been able to extend and improve them without breaking compatibility with the language definition. In some cases, such as the changes to how exceptions work, we haven't had this freedom as the relevant functions are exposed by the Prelude, and that has been causing us grief for years. To take one example, since List was immortalised in the H98 report with 104 exports, Data.List has gained an additional 7 exports: foldl' foldl1' intercalate isInfixOf permutations stripPrefix subsequences The last change (making the behaviour of the generic* functions consistent with their non-generic counterparts) was less than a year ago, and the last additions were less than 2. Though also note that we have not changed any of the existing ones. Is there a problem with specifying in the libraries section of the report that the exports are a minimum and not a maximum? But to me, the most compelling argument for dropping them from the report is that I can see no benefit to standardising them as part of the language, rather than in a separate base libraries standard. Some functions, especially the pure ones are really part of the character of the language (and some are specified as part of the syntax). We have not had major problems with the pure parts of the standard libraries, our problems have almost all been with the system facing parts (handles, files, programs, exceptions). I don't see any particular problem with having some essential (in the sense of being part of the essence of the language) libraries in the main report and some separate libraries report in a year or two's time standardising some of the trickier aspects of libraries for portable programs to interact with the OS (addressing Malcolm's point about the need for this so as to be able to write portable programs). Duncan ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Haskell 2010: libraries
On Tue, Jul 14, 2009 at 12:23:51PM +0100, Duncan Coutts wrote: On Tue, 2009-07-14 at 00:20 +0100, Ian Lynagh wrote: On Mon, Jul 13, 2009 at 09:56:50PM +0100, Duncan Coutts wrote: To take one example, since List was immortalised in the H98 report with 104 exports, Data.List has gained an additional 7 exports: The last change (making the behaviour of the generic* functions consistent with their non-generic counterparts) was less than a year ago, and the last additions were less than 2. Though also note that we have not changed any of the existing ones. Yes we have, less than a year ago: GHCi, version 6.8.2: http://www.haskell.org/ghc/ :? for help Loading package base ... linking ... done. Prelude Data.List.genericTake (-1) abc *** Exception: List.genericTake: negative argument GHCi, version 6.10.3: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer ... linking ... done. Loading package base ... linking ... done. Prelude Data.List.genericTake (-1) abc Is there a problem with specifying in the libraries section of the report that the exports are a minimum and not a maximum? We wouldn't be able to fix the generic* functions, or the way exceptions work. But to me, the most compelling argument for dropping them from the report is that I can see no benefit to standardising them as part of the language, rather than in a separate base libraries standard. Some functions, especially the pure ones are really part of the character of the language The Haskell language could be thought of as being composed of Haskell Language 2010 report and Haskell Libraries 1.0 report. (and some are specified as part of the syntax) Yes, some types functions may need to be specified by the report as being somewhere for desugaring etc. Although maybe we could even eliminate most of these if rebindable syntax became part of the language? Thanks Ian ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Haskell 2010: libraries
On Tue, Jul 14, 2009 at 11:57:11AM +0400, Bulat Ziganshin wrote: Tuesday, July 14, 2009, 3:20:42 AM, you wrote: We've been fortunate recently that, because the hierarchical modules haven't been in the standard, we've been able to extend and improve them without breaking compatibility with the language definition. but breaking compatibility with existing programs. i hate situation when we need to reupload entire hackage every year Standardising the number of modules we're talking about isn't going to affect whether or not this happens. Also, just because the libraries are standardised separately doesn't mean that we /need/ to change them every year, it just makes it /possible/ to change them. Thanks Ian ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Proposal: change to qualified operator syntax
On 14/07/2009 08:58, Malcolm Wallace wrote: left section right section prefix unqualified (+ 1) (1 +) (+) Haskell 98 (M.+ 1) (1 M.+) (M.+) proposed (`M.(+)` 1) (1 `M.(+)`) M.(+) or(*) (M.(+) 1) (flip M.(+) 1) The last line is not correct. (M.(+) 1) captures the first argument of the function, not the second like all the other entries in that column. Likewise the flip variant captures the second arg, where all the others capture the first. oops, I got those the wrong way around. Well spotted. Fixed on the wiki page: http://hackage.haskell.org/trac/haskell-prime/wiki/QualifiedOperators Cheers, Simon ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Haskell 2010: libraries
On Tue, Jul 14, 2009 at 07:48:36AM +0100, Sittampalam, Ganesh wrote: I don't have any strong opinion about whether there should be a library standard or not, but if there is a standard, how about putting the entire thing (perhaps including the Prelude) under the prefix Haskell2010. or similar? Most of it could be implemented by just re-exporting things from the real libraries. That would be OK with me, although I still think it would be easier for us to disentangle the library standardisation effort from the language standardisation effort. I'd suggest Haskell.V2010.Data.List (just re-exports from V2011 where possible) Haskell.V2010.Prelude (just re-exports from V2011 where possible) Haskell.V2011.Data.List Haskell.V2011.Prelude with the implicit Prelude import being changed to Haskell.Vversion.Prelude where version is that latest the compiler supports, unless you say e.g. -XHaskell2010. Thanks Ian ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
