Bulat Ziganshin wrote:

Simon Marlow wrote:

...

3. Update the libraries to match what we have at the moment. e.g. rename List to Data.List, and add the handful of functions that have since been added to Data.List. One problem with this is that these modules are then tied to the language definition, and can't be changed through the usual library proposal process.

not necessarily. we already apply versioning to these libs, it may be made official in Report too. i.e. Report defines libraries standard for year 2010 (like it defines language standard for only one year), while we continue to improve libraries that will eventually become version standard for year 2011 (or higher)

If I understand that correctly, this would mean to simply include the particular version of a library that happens to be the current one at the report deadline. In other words, the report specifies that say version 4.1.0.0 of the base library is the standard one for 2010. Since old library versions are archived on hackage, this looks like a cheap and easy solution to me. It's more an embellishment of alternative 1. than a genuine 3. Regards, apfelmus -- http://apfelmus.nfshost.com

Heinrich Apfelmus wrote:

If I understand that correctly, this would mean to simply include the particular version of a library that happens to be the current one at the report deadline. In other words, the report specifies that say version 4.1.0.0 of the base library is the standard one for 2010.

Since old library versions are archived on hackage, this looks like a cheap and easy solution to me. It's more an embellishment of alternative 1. than a genuine 3.

It could be a mere informative reference: "the most-community-accepted libraries at the time of publication are:". Keep in mind also that some of the libraries change irrevocably (like base has; with changes like Unicode I/O, or adding the Category class above Arrow. When it is tied to a particular compiler version it's less trivial to support multiple libraries... or even when it's not, version skew can get annoying -Isaac

On 08/07/2009 19:41, Heinrich Apfelmus wrote:

Bulat Ziganshin wrote:

...

Simon Marlow wrote:

...

3. Update the libraries to match what we have at the moment. e.g. rename List to Data.List, and add the handful of functions that have since been added to Data.List. One problem with this is that these modules are then tied to the language definition, and can't be changed through the usual library proposal process. not necessarily. we already apply versioning to these libs, it may be made official in Report too. i.e. Report defines libraries standard for year 2010 (like it defines language standard for only one year), while we continue to improve libraries that will eventually become version standard for year 2011 (or higher)

If I understand that correctly, this would mean to simply include the particular version of a library that happens to be the current one at the report deadline. In other words, the report specifies that say version 4.1.0.0 of the base library is the standard one for 2010.

Since old library versions are archived on hackage, this looks like a cheap and easy solution to me. It's more an embellishment of alternative 1. than a genuine 3.

So, just to be clear, you're suggesting that we - remove the whole of the Library Report, - declare a list of packages and versions that we consider to be the standard libraries for Haskell 2010. This would be a bold step, in that we would be effectively standardising a lot more libraries than the current language standard. The base package is a fairly random bag of library modules, for instance. It contains a lot of modules that are only implemented by GHC. It contains backwards compatibility stuff (Control.OldException), and stuff that doesn't really belong (Data.HashTable). Perhaps we could explicitly list the modules that the standard requires. On the other hand, this would be a useful step, in that it gives users a wide base of libraries to rely on. And it's cheap to implement in the report. Any other thoughts? Cheers, Simon

On 09/07/2009 13:26, Bulat Ziganshin wrote:

Hello Simon,

Thursday, July 9, 2009, 3:46:31 PM, you wrote:

...

This would be a bold step, in that we would be effectively standardising a lot more libraries than the current language standard. The base package is a fairly random bag of library modules, for instance. It

The base library is under the question, but remaining libs of ghc/HP are in rather good shape

of course, without base we can't do even i/o, so questions still remains. in particular, you plan to do something with base in 6.12 although it was not yet decided what exactly

so these two discussions (what to do with libs in 6.12 and what to do with libs in Report) may go together

ideally, we would split base into smaller and versionable packages. at least in form of interfaces, while implementations will just import everything from base

I feel this discussion is widening a bit too far. The question at hand is how to make the Haskell 2010 Report self-consistent, avoid confusing users, and avoid perpetuating obsolete libraries. The Haskell Report doesn't have to specify libraries, it is not supposed to be a complete specification of the Haskell universe, it is a specification of the language. Remember that we're talking here about a *standard*. The Haskell Platform libraries, while being a hugely useful resource, are not specified to the level of precision we would expect for a Haskell standard. Neither have they undergone the level of scrutiny that we would ideally subject libraries to. So we can't just throw all this stuff in the standard and say "done!". Cheers, Simon

On Jul 8, 2009, at 17:55 , Bulat Ziganshin wrote:

...

On Wed, Jul 08, 2009 at 03:09:29PM +0100, Simon Marlow wrote:

...

1. Just drop the whole libraries section from the report. The Report will still define the Prelude, however.

I'm tending towards (1), mainly because it provides a clean break and is likely to be the least confusing for users: they have one place to go looking for library documentation.

instead, ghc bundled libs say it, replaced now by Haskell Platform libs. but these are de-facto standards, and i think that Report should support it by defining the same set as standard de-jure

Perhaps the real answer is that the Report should bless the Haskell Platform - not any specific version of it. It occurs to me that the dependency might actually go the other way: a Haskell Platform release specifies which versions of the Haskell standard it complies with. (Including H98.) -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH

On 08/07/2009 22:45, Ian Lynagh wrote:

On Wed, Jul 08, 2009 at 03:09:29PM +0100, Simon Marlow wrote:

...

1. Just drop the whole libraries section from the report. The Report will still define the Prelude, however.

I'm tending towards (1), mainly because it provides a clean break and is likely to be the least confusing for users: they have one place to go looking for library documentation.

Sounds good to me.

See also http://hackage.haskell.org/trac/haskell-prime/ticket/118

Ian, would you like to take ownership for this proposal, and start fleshing out the details in a wiki page? There seems to be support for removing all the libraries in the report. Whether the report also blesses either the Haskell Platform or a set of packages is a separate matter; either way, we still have to extract the existing libraries from the report, and there will be a set of changes to the report necessary to make that happen. The Report should explicitly list all the library entities that it refers to. Cheers, Simon

On Fri, Jul 10, 2009 at 10:05:52AM +0100, Simon Marlow wrote:

On 08/07/2009 22:45, Ian Lynagh wrote:

...

On Wed, Jul 08, 2009 at 03:09:29PM +0100, Simon Marlow wrote:

...

1. Just drop the whole libraries section from the report. The Report will still define the Prelude, however.

I'm tending towards (1), mainly because it provides a clean break and is likely to be the least confusing for users: they have one place to go looking for library documentation.

Sounds good to me.

See also http://hackage.haskell.org/trac/haskell-prime/ticket/118

Ian, would you like to take ownership for this proposal, and start fleshing out the details in a wiki page?

OK, will do. Thanks Ian

Ross Paterson:

On Wed, Jul 08, 2009 at 03:09:29PM +0100, Simon Marlow wrote:

...

1. Just drop the whole libraries section from the report. The Report will still define the Prelude, however.

There will be some loose ends where the rest of the report refers to entities from these libraries, e.g. the Prelude refers to Rational from the Ratio library. We just have to fix up these references, moving the appropriate definitions into the Report as necessary.

Some of the loose ends:

The defaulting rules (section 4.3.4) apply to any class "defined in the Prelude or a standard library". The non-Prelude classes involved are Ix and Random.

The FFI spec refers to types Int8, Int16, Int32, Int64, Word8, Word16, Word32, Word64, Ptr a, FunPtr a and StablePtr a. Perhaps they should move to the Prelude when the non-library part of the FFI spec is incorporated into the Report?

If we have these types in the Prelude, the associated functions should be in the Prelude, too, and I'd be reluctant to include operations that are not memory-safe in the Prelude. So, I think, we need at least a standard library for the FFI. (In the FFI spec, we after all went to a lot of trouble to realise as much as possible of the needed functionality as libraries, to change the core language as little as possible.) I understand the desire to cut down on the number of library functions defined in the report, but ultimately, the language needs to provide a basic set of functionality that is the basis for implementing all the other libraries. Otherwise, the usefulness of the standard gets undermined. Apart from the Prelude, I think we should ask the following question to decide whether we can omit some library functionality from the language definition: If we omit the functionality under consideration, can we implement it in a portable manner with what remains in the definition? If that is not the case, we ought to include it. Manuel PS: As a historical anecdote, it was a major shortcoming of Modula-2 over C that Modula-2 didn't define it's basic libraries properly with the language (whereas C did).

On 11/07/2009 11:54, Manuel M T Chakravarty wrote:

Ross Paterson:

...

On Wed, Jul 08, 2009 at 03:09:29PM +0100, Simon Marlow wrote:

...

1. Just drop the whole libraries section from the report. The Report will still define the Prelude, however.

There will be some loose ends where the rest of the report refers to entities from these libraries, e.g. the Prelude refers to Rational from the Ratio library. We just have to fix up these references, moving the appropriate definitions into the Report as necessary.

Some of the loose ends:

The defaulting rules (section 4.3.4) apply to any class "defined in the Prelude or a standard library". The non-Prelude classes involved are Ix and Random.

The FFI spec refers to types Int8, Int16, Int32, Int64, Word8, Word16, Word32, Word64, Ptr a, FunPtr a and StablePtr a. Perhaps they should move to the Prelude when the non-library part of the FFI spec is incorporated into the Report?

If we have these types in the Prelude, the associated functions should be in the Prelude, too, and I'd be reluctant to include operations that are not memory-safe in the Prelude. So, I think, we need at least a standard library for the FFI. (In the FFI spec, we after all went to a lot of trouble to realise as much as possible of the needed functionality as libraries, to change the core language as little as possible.)

The functions don't necessarily have to be in the Prelude too - the point of putting the types there is so that we can specify what a valid foreign import/export declaration is.

I understand the desire to cut down on the number of library functions defined in the report, but ultimately, the language needs to provide a basic set of functionality that is the basis for implementing all the other libraries. Otherwise, the usefulness of the standard gets undermined.

The usefulness of the standard is already undermined by specifying a set of libraries that we don't recommend people use, and that differ in confusing ways from the libraries that we do recommend people use (e.g. they have different names, such as CForeign vs. Foreign.C). I'm all for having standard libraries, but we have to think about what we can practically accomplish for Haskell 2010.

Apart from the Prelude, I think we should ask the following question to decide whether we can omit some library functionality from the language definition:

If we omit the functionality under consideration, can we implement it in a portable manner with what remains in the definition?

If that is not the case, we ought to include it.

I don't like to think of this in terms of "omitting functionality from the language definition". It's more a case of deferring the standardisation of libraries in the Report, until such time as we can produce a polished library standard. The functionality is still there, in the implementations, well documented, and in the FFI spec. It is also explicitly versioned in the Haskell Platform, so language implementers can all agree on what to provide. To use the above test would mean we could avoid specifying some libraries but not others, based on some criteria that is not important to users. I don't think this is the right way to approach the problem. Some libraries inevitably have non-portable implementations: e.g. Data.Typeable, Control.Exception, Data.IORef. We would be able to leave out Data.List, but not Foreign.StablePtr. Which is more useful? Another option (option (3) in my original mail) is to rename all the FFI libraries to use the hierarchical names and include them in the Report. But what other libraries should we include? I favour this approach slightly less than just leaving out all the libraries, mainly because the result would be an fairly arbitrary collection of library modules, which is of limited use to both users and language implementers. It may serve as a start for a larger collection of standard libraries; however, it would also be quite a lot of work to get this done for Haskell 2010.

PS: As a historical anecdote, it was a major shortcoming of Modula-2 over C that Modula-2 didn't define it's basic libraries properly with the language (whereas C did).

I completely agree there should be standard libraries. But I don't think that should prevent us from producing a language revision in the short term. Cheers, Simon

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. List keep as Data.List 7. Maybe keep as Data.Maybe 8. Char keep 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. Time drop 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. It seems unlikely to me that all these libraries are finally perfect. If we freeze them too solidly then I'm sure that we will regret it. It is true that, with yearly language revisions, we have an annual opportunity to fix any problems. However, we also want the implementations to support several releases at once, and maintaining those old base libraries would be a lot of work and confusion for the minimal amount of benefit they would provide. 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. We would be able to act as if they were one standard if that were most convenient, but we would have the flexibility to take advantage of them being separate if necessary. Thanks Ian

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, Bulat mailto:Bulat.Ziganshin@gmail.com

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, Bulat mailto:Bulat.Ziganshin@gmail.com

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.V<version>.Prelude where <version> is that latest the compiler supports, unless you say e.g. -XHaskell2010. Thanks Ian

Simon Marlow wrote:

On 14/07/2009 15:04, Ian Lynagh wrote:

...

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.V<version>.Prelude where<version> is that latest the compiler supports, unless you say e.g. -XHaskell2010.

I find this rather jarring, because it moves versioning from where it should be (in the package metadata) to where it shouldn't be (in the module names).

I'd say that versioning of standards is rather different from versioning of packages, which makes it less jarring, but yes, it doesn't feel very nice and it would make porting code forwards annoying.

But there's a solution: we could remove the "standard" modules from base, and have them only provided by haskell-std (since base will just be a re-exporting layer on top of base-internals, this will be easy to do). Most packages will then have dependencies that look like

But this precludes the kind of changes to those modules that Ian described as having happened in the last few years. Ganesh =============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ===============================================================================

Simon Marlow wrote:

On 15/07/2009 15:47, Sittampalam, Ganesh wrote:

...

...

But there's a solution: we could remove the "standard" modules from base, and have them only provided by haskell-std (since base will just be a re-exporting layer on top of base-internals, this will be easy to do). Most packages will then have dependencies that look like

But this precludes the kind of changes to those modules that Ian described as having happened in the last few years.

I don't follow. If we have versioned haskell-std packages, surely they can export different APIs?

I guess if all such changes were treated as candidates for the next version of the library standard, then that would work. Cheers, Ganesh =============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ===============================================================================

On 15/07/2009 15:54, Ian Lynagh wrote:

On Wed, Jul 15, 2009 at 03:39:55PM +0100, Simon Marlow wrote:

...

But there's a solution: we could remove the "standard" modules from base, and have them only provided by haskell-std (since base will just be a re-exporting layer on top of base-internals, this will be easy to do). Most packages will then have dependencies that look like

build-depends: base-4.*, haskell-std-2010

We'll probably end up with situations where one dependency of a package needs haskell-std-2010, and another needs haskell-std-2011. I don't know which impls support that at the moment.

That's the case with base-3/base-4 at the moment. Is it a problem? Cheers, Simon

On 15/07/2009 18:10, David Menendez wrote:

On Wed, Jul 15, 2009 at 11:33 AM, Simon Marlow wrote:

...

On 15/07/2009 15:54, Ian Lynagh wrote:

...

On Wed, Jul 15, 2009 at 03:39:55PM +0100, Simon Marlow wrote:

...

But there's a solution: we could remove the "standard" modules from base, and have them only provided by haskell-std (since base will just be a re-exporting layer on top of base-internals, this will be easy to do). Most packages will then have dependencies that look like

build-depends: base-4.*, haskell-std-2010 We'll probably end up with situations where one dependency of a package needs haskell-std-2010, and another needs haskell-std-2011. I don't know which impls support that at the moment. That's the case with base-3/base-4 at the moment. Is it a problem?

Could I use two packages of arrow code which depend on base 3.0.2 and base 3.0.3, respectively, in the same project?

No. (though I'm not sure the significance of "arrow code" here). Is there a package that depends on base-3.0.2, and doesn't work with base-3.0.3? Cheers, Simon

Simon Marlow wrote:

Ian Lynagh wrote:

...

Simon Marlow wrote:

...

But there's a solution: we could remove the "standard" modules from base, and have them only provided by haskell-std (since base will just be a re-exporting layer on top of base-internals, this will be easy to do). Most packages will then have dependencies that look like

build-depends: base-4.*, haskell-std-2010

We'll probably end up with situations where one dependency of a package needs haskell-std-2010, and another needs haskell-std-2011. I don't know which impls support that at the moment.

That's the case with base-3/base-4 at the moment. Is it a problem?

I think the issue raised is the diamond import problem, for instance that say the list type from haskell-std-2010 is spuriously different from the one in haskell-std-2011 . This would affect new programs based on the 2011 standard that want to use older libraries based on the 2010 standard; the point being that the latter are "intentionally" not updated to the newer standard. Of course, that's just the base-3 / base-4 issue which can be solved; it's just that it's not automatic but needs explicit work by implementors every time there is a new library standard. Regards, apfelmus -- http://apfelmus.nfshost.com

On 15/07/2009 17:03, Mathias Stearn wrote:

Would it be possible for the language to require that implementations support linking multiple versions of packages (at least base and haskell-std) into a single running instance? That would solve the issue of using two libs that depend on different versions.

The language definition says nothing about packages. As far as the Haskell standard is concerned, a Haskell program is just a collection of modules, including the Prelude. I'm fairly keen to keep things simple like this. The packaging system can be explained, without modifying the language standard, as a transformation on module names (e.g. prefixing each module name with an identifier representing the package instance it comes from). Cheers, Simon

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

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

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:

...

Specifically, I suggest:

4. Ix keep as Data.Ix 5. Array keep as Data.Array

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?

Here's another example I've just been looking at: Prelude> Array.listArray (1,4) [1..4] Array.! 5 *** Exception: Ix{Integer}.index: Index (5) out of range ((1,4)) Prelude> Array.listArray ((0,0), (3,3)) (repeat 0) Array.! (0,5) *** Exception: Error in array index Because the "Ix Integer" instance is for a type that we have a "Show" instance for, it can give a nice out-of-bounds error message. But the "Ix (a, b)" instance doesn't know if "(Show a, Show b)" instances exist, so it has to fall back to an unhelpful error message. So one could certainly argue that we should make Show a superclass of Ix, leaving us with a class that is incompatible with the older class definition. Thanks Ian