Re: Haskell 2010 libraries

[Brandon S. Allbery KF8NH]

On May 4, 2010, at 05:09 , Duncan Coutts wrote:

On Fri, 2010-04-30 at 10:42 +0100, Simon Marlow wrote:

Bear in mind these goals: we want to

  a. support writing code that is Haskell 2010 only: it only uses
 Haskell 2010 language features and modules.

  b. not break existing code as far as possible


I'm going to dissent here:  current code assumes extensions, not a  
standard.  I think it's not outside the pale to have code that wishes  
to conform to Haskell2010 be modified to do so, and otherwise the code  
continues to be "extended nonstandard Haskell" if it is not already  
Haskell98-conformant.  After all, Haskell2010 doesn't quite include  
*all* of the extensions that are in common use.


So, I'm going to go out on a limb here and suggest that Haskell 2010  
code should specify


> {-# LANGUAGE Haskell2010 #-}

to distinguish from Haskell '98 code (no LANGUAGE pragmas) and  
extension code (other LANGUAGE pragmas).  Users who wish to combine  
the above with nonstandard extensions can expect to do extra work.   
Existing code continues to work because it doesn't explicitly limit  
itself to Haskell2010.


A side benefit of this is that it requires the code (not a cabal file  
or etc.) to specify that it is Haskell2010 as opposed to Haskell98 or  
etc.  Unless cabal-install is a mandatory part of Haskell2010, relying  
on it to specify the language support level strikes me as not the best  
of ideas.



If people think the order in the .cabal file is not sufficiently
explicit then I'm sure we can concoct some more explicit syntax. We
already need to add some syntax to allow a package to depend on  
multiple

versions of a single dependency.


We already have most of that, don't we?  There's the extension to  
allow you to specify the exact package to use for a given module; with  
"as" syntax one might presumably say something like


> import "haskell-2010" Data.List
> import "containers-ext" Data.List as L;

I understand this may require some work, but it seems a reasonable  
extension of existing syntax.  It also puts the onus of making things  
work together on the user, and (as mentioned above) I think that's  
eminently sensible for existing code that assumes that it uses  
extensions, not a standard.


The advantage of the client doing it is it's quite general. The  
downside

is it's quite general: people can do it anywhere and can easily get
incompatible collections of types. For example base:Prelude.Int would
only be the same as haskell2010:Prelude.Int because it is explicitly  
set

up to be that way. Arbitrary shadowing would not be so co-operative.


ghc already lets you do this by rebinding syntax.  What happens if you  
rebind (>>=) in a way that isn't quite compatible with the monad  
laws?  Granted, right now you have to do fairly esoteric stuff to get  
yourself into that kind of trouble, whereas we're talking now about  
something likely to be more common.


I'm not quite sure how it would be implemented but from the user's  
point

of view they just list the package dependencies as usual and get the
sensible overlapping order. Presumably packages not designed to be  
used

in an overlapping way should still give an error message.


The problem here is, how do you know?  I recall suggesting some time  
back that dependencies without an upper bound were going to be a  
problem, and lo and behold, when base-4 came out they broke.  If a  
package declares itself to be capable of overlapping, does it apply  
only to Haskell2010 or is it assumed to also apply to Haskell2011  
unless specified otherwise?  Or do we try to figure it out  
automatically?  (Which I suspect would cause all sorts of problems.)


--
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allb...@kf8nh.com
system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu
electrical and computer engineering, carnegie mellon universityKF8NH




PGP.sig
Description: This is a digitally signed message part
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

Re: Haskell 2010 libraries

[Duncan Coutts]

On Fri, 2010-04-30 at 10:42 +0100, Simon Marlow wrote:
> Hi Folks,
> 
> I'm editing the Haskell 2010 report right now, and trying to decide what 
> to do about the libraries.  During the Haskell 2010 process the 
> committee agreed that the libraries in the report should be updated, 
> using the current hierarchical names, adding new functionality from the 
> current base package, and dropping some of the H'98 library modules that 
> now have better alternatives.
> 
> In Haskell 2010 we're also adding the FFI modules.  The FFI addendum 
> used non-hierarchical names (CForeign, MarshalAlloc etc.) but these are 
> usually known by their hierarchical names nowadays: e.g. Foreign.C, 
> Foreign.Marshal.Alloc.  It would seem strange to add the 
> non-hierarchical names to the Haskell language report.
> 
> So this is all fine from the point of view of the Haskell report - I can 
> certainly update the report to use the hierarchical module names, but 
> that presents us with one or two problems in the implementation.
> 
> However, what happens when someone wants to write some code that uses
> Haskell 2010 libraries, but also uses something else from base, say 
> Control.Concurrent?  The modules from haskell2010 overlap with those 
> from base, so all the imports of Haskell 2010 modules will be ambiguous.

>   The Prelude is a bit of a thorny issue too: currently it is in base, 
> but we would have to move it to haskell2010.

This problem with the Prelude also already exists. It is currently not
possible to write a H98-only program that depends only on the haskell98
package and not on the base package, because the Prelude is exported
from base and not from haskell98.

> Bear in mind these goals: we want to
> 
>a. support writing code that is Haskell 2010 only: it only uses
>   Haskell 2010 language features and modules.
> 
>b. not break existing code as far as possible
> 
>c. whatever we do should extend smoothly when H'2011 makes
>   further changes, and so on.
> 
> Here are some non-options:
> 
>1. Not have a haskell2010 package.  We lose (a) above, and we
>   lose the ability to add or change the API for these modules,
>   in base, since they have to conform to the H'2010 spec.  If
>   H'2011 makes any changes to these modules, we're really stuck.
> 
>2. As described above: you can either use haskell2010, or base,
>   but not both.  It would be painful to use haskell2010 in
>   GHCi, none of the base modules would be available.
> 
> Here are some options:
> 
>3. allow packages to shadow each other, so haskell2010 shadows
>   base.  This is a tantalising possibility, but I don't have
>   any idea what it would look like, e.g. should the client or
>   the package provider specify shadowing?

So one option is simply to have the client specify shadowing by the
order in which packages are listed on the command line / in the .cabal
file (or some other compiler-dependent mechanism).

If people think the order in the .cabal file is not sufficiently
explicit then I'm sure we can concoct some more explicit syntax. We
already need to add some syntax to allow a package to depend on multiple
versions of a single dependency.

The advantage of the client doing it is it's quite general. The downside
is it's quite general: people can do it anywhere and can easily get
incompatible collections of types. For example base:Prelude.Int would
only be the same as haskell2010:Prelude.Int because it is explicitly set
up to be that way. Arbitrary shadowing would not be so co-operative.


The provider doing it seems fairly attractive. Cases of co-operative
overlapping have to be explicitly constructed by the providing packages
anyway (see e.g. base3 and base4).

I'm not quite sure how it would be implemented but from the user's point
of view they just list the package dependencies as usual and get the
sensible overlapping order. Presumably packages not designed to be used
in an overlapping way should still give an error message.

The provider doing it rather than the client should avoid the user
having to think too much or there being too many opportunities to do
foolish and confusing things. Only the sensible combinations should
work.

> Thoughts?  Better ideas?

So I think I quite like option 3. I doesn't sound to me as complicated
or as subtle as Malcolm seems to fear.

If I write:

build-depends: base, haskell2010

then since haskell2010 has been explicitly set up for this overlapping
to be allowed, then we get haskell2010 shadowing base (irrespective of
the order in which the client lists the packages).

Duncan

___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

Re: Haskell 2010 libraries

[Duncan Coutts]

On Fri, 2010-04-30 at 10:42 +0100, Simon Marlow wrote:

> Here are some options:
> 
>3. allow packages to shadow each other, so haskell2010 shadows
>   base.  This is a tantalising possibility, but I don't have
>   any idea what it would look like, e.g. should the client or
>   the package provider specify shadowing?

Note that we already have some notion of shadowing. Modules found in
local .hs files shadow modules from packages.

Duncan

___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

Re: Haskell 2010 libraries

[Simon Marlow]

On 01/05/10 20:17, Ian Lynagh wrote:

On Sat, May 01, 2010 at 08:05:58PM +0100, Simon Marlow wrote:

On 01/05/10 17:16, Ian Lynagh wrote:


So it seems this is closer to option (2) in my message, because
portablebase and haskell2010 overlap, and are therefore mutually
exclusive, whereas in (4) haskell2010 and base2010 are non-overlapping -
that's the crucial difference.


If they are non-overlapping, how would a new Data.List function be
added? Or an existing Data.List function be altered?


In this scenario there would be base as it is now, and base2010 (or
whatever you want to call it) that is base minus the modules in
haskell2010.  So you can add things to base:Data.List, but
haskell2010:Data.List must export exactly the API as specified in the
report.


So someone using haskell2010+base2010 wouldn't be able to use this new
function?


Correct.  If you opt to use the Haskell 2010 API, you don't get to see 
new additions made to those modules, but that's entirely reasonable.


Cheers,
Simon
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

Re: Haskell 2010 libraries

[Brandon S. Allbery KF8NH]

On May 1, 2010, at 15:05 , Simon Marlow wrote:

On 01/05/10 17:16, Ian Lynagh wrote:
Oh, I thought the plan was for library standardisation in the  
report to
be reduced, with perhaps the Haskell Platform becoming the new  
library

standardisation effort.


I thought the *eventual* plan was to properly standardise lots of  
libraries, with the Haskell Platform being an intermediate step on  
the way to standardisation. Though I don't think we ever actually  
decided anything, really.



I was also under the impression that the Haskell Platform was the  
library standardization effort (and in fact my first reaction to your  
original message was "so defer it to the Libraries Report which  
describes the HP", but I wasn't sure I understood all the issues).


--
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allb...@kf8nh.com
system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu
electrical and computer engineering, carnegie mellon universityKF8NH




PGP.sig
Description: This is a digitally signed message part
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

Re: Haskell 2010 libraries

[Ian Lynagh]

On Sat, May 01, 2010 at 08:05:58PM +0100, Simon Marlow wrote:
> On 01/05/10 17:16, Ian Lynagh wrote:
>
>>> So it seems this is closer to option (2) in my message, because
>>> portablebase and haskell2010 overlap, and are therefore mutually
>>> exclusive, whereas in (4) haskell2010 and base2010 are non-overlapping -
>>> that's the crucial difference.
>>
>> If they are non-overlapping, how would a new Data.List function be
>> added? Or an existing Data.List function be altered?
>
> In this scenario there would be base as it is now, and base2010 (or  
> whatever you want to call it) that is base minus the modules in  
> haskell2010.  So you can add things to base:Data.List, but  
> haskell2010:Data.List must export exactly the API as specified in the  
> report.

So someone using haskell2010+base2010 wouldn't be able to use this new
function?

>>> I described this as a non-option because I thought trying to use the
>>> packages together might be a common problem that leads to obscure error
>>> messages about ambiguous modules, but perhaps it's not that bad, or at
>>> least not worse than the other solutions.
>>
>> Direct imports of base* and haskell* could be (dis)allowed by the
>> implementation depending on whether it is in "Haskell 2010 mode" or not.
>
> Not sure what you mean here - modules are imported, not packages.  Type  
> error!

Heh, true. I meant that e.g.
ghc --language haskell2010 -package base ...
would give an error.


Thanks
Ian

___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

Re: Haskell 2010 libraries

[Simon Marlow]

On 30/04/10 23:52, Felipe Lessa wrote:

On Fri, Apr 30, 2010 at 09:37:39PM +0100, Simon Marlow wrote:

I like the picture where we have a small base, lots of independent
packages, and one or more haskell20xx packages that re-exports all
the standardised stuff from the other packages.  This arrangement
extends smoothly, the only problem is that haskell20xx overlaps with
the other packages.


I wonder how much pain will there be when Haskell 2011 comes out.
Some packages will depend on haskell2010, and others on
haskell2011.  Will they integrate and compile fine?

If haskell2010 is a metapackage that says

   Depends: base == X.Y.*

and haskell2011 is another metapackage that says

   Depends: base == Z.W.*

then I think we're going to have big problems.  Sorry if this is
a resolved issue. :)


That won't be a problem, for the same reasons that we can happily mix 
packages that depend on base-3 with packages that depend on base-4 right 
now.


That is, unless Haskell 2011 decides to make some incompatible changes 
to datatypes or classes, as Ian pointed out.


Cheers,
Simon

___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

Re: Haskell 2010 libraries

[Simon Marlow]

On 01/05/10 17:16, Ian Lynagh wrote:


So it seems this is closer to option (2) in my message, because
portablebase and haskell2010 overlap, and are therefore mutually
exclusive, whereas in (4) haskell2010 and base2010 are non-overlapping -
that's the crucial difference.


If they are non-overlapping, how would a new Data.List function be
added? Or an existing Data.List function be altered?


In this scenario there would be base as it is now, and base2010 (or 
whatever you want to call it) that is base minus the modules in 
haskell2010.  So you can add things to base:Data.List, but 
haskell2010:Data.List must export exactly the API as specified in the 
report.



No matter what solution is chosen, changes to datatypes or classes seem
likely to be troublesome.


Yes, that's true. Adding methods to classes is possible, but adding 
constructors to datatypes, or new instances, is not.



I think the library change plans are underdeveloped, the libraries
should be unchanged in H2010, and we should resolve this issue before
changing them in a future language revision. That would keep other
options open, such as the report standardising Haskell2011.Data.List
rather than Data.List, etc.


FWIW, I omitted mentioning that option because I think it's the worst of 
the bunch :-)  I think that putting version numbers into module names is 
a very dangerous thing to start doing.  When you want to upgrade your 
code to Haskell 2011, you have to change not just the .cabal file but 
all the imports too.  Keeping version dependencies collected together in 
one place and not scattered through source code is one of the better 
design decisions we made, I believe.


Doing "nothing" as you suggest is an option, but it would mean using the 
non-hierarchical names for the FFI libraries.  There's nothing 
technically wrong with it, but I find it a bit odd to be standardising 
modules with names that in practice almost no code has ever used.  I 
suppose those are the names in the FFI addendum though.



I described this as a non-option because I thought trying to use the
packages together might be a common problem that leads to obscure error
messages about ambiguous modules, but perhaps it's not that bad, or at
least not worse than the other solutions.


Direct imports of base* and haskell* could be (dis)allowed by the
implementation depending on whether it is in "Haskell 2010 mode" or not.


Not sure what you mean here - modules are imported, not packages.  Type 
error!


It's the modules that overlap between the two packages that are the 
problem.  If someone imports Data.List, do they mean the haskell2010 or 
the base one?  If you're suggesting that we choose based on whether the 
flag -fhaskell2010 is set, then that really amounts to the haskell2010 
package shadowing base when -fhaskell2010 is on.  It might be the right 
thing, but it's a slightly ugly special case.



We hope in the future that the set of libraries standardised in the
report grows beyond what we have in base currently


Oh, I thought the plan was for library standardisation in the report to
be reduced, with perhaps the Haskell Platform becoming the new library
standardisation effort.


I thought the *eventual* plan was to properly standardise lots of 
libraries, with the Haskell Platform being an intermediate step on the 
way to standardisation. Though I don't think we ever actually decided 
anything, really.


Cheers,
Simon
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

Re: Haskell 2010 libraries

[Ian Lynagh]

On Fri, Apr 30, 2010 at 09:37:39PM +0100, Simon Marlow wrote:
> On 30/04/10 13:19, Malcolm Wallace wrote:
>>> 4. Provide a haskell2010 package and a base2010 package that
>>> re-exports all of base except the modules that overlap with
>>> haskell2010. You can either use haskell2010,
>>> haskell2010+base2010, or base. This is a bit like (1), but
>>> avoids the need for shadowing by using package re-exports,
>>> on the other hand confusion could well arise due to the
>>> strange base2010 package, and some people would surely try
>>> to use haskell2010 + base and run into difficulties.
>>
>> In many ways this corresponds to my preferred solution, although I would
>> rephrase it thus:
>>
>> * Deprecate use of the "base" package, (I do not mean to remove "base",
>> just to freeze it, and discourage its general use.)
>> * Create a new "haskell2010" package (for ghc this will be built on topcommon
>> of "base", but other compilers might make a different choice).
>> * Create a new "portablebase" package which contains (or re-exports)
>> all of the remaining useful and portable parts of the current "base"
>> _and_ "haskell2010".
>> * Create a new "ghcextras" package which re-exports (or defines afresh)
>> all of the useful but non-portable parts of the current "base".
>
> So it seems this is closer to option (2) in my message, because  
> portablebase and haskell2010 overlap, and are therefore mutually  
> exclusive, whereas in (4) haskell2010 and base2010 are non-overlapping -  
> that's the crucial difference.

If they are non-overlapping, how would a new Data.List function be
added? Or an existing Data.List function be altered?

No matter what solution is chosen, changes to datatypes or classes seem
likely to be troublesome.

I think the library change plans are underdeveloped, the libraries
should be unchanged in H2010, and we should resolve this issue before
changing them in a future language revision. That would keep other
options open, such as the report standardising Haskell2011.Data.List
rather than Data.List, etc.

> I described this as a non-option because I thought trying to use the  
> packages together might be a common problem that leads to obscure error  
> messages about ambiguous modules, but perhaps it's not that bad, or at  
> least not worse than the other solutions.

Direct imports of base* and haskell* could be (dis)allowed by the
implementation depending on whether it is in "Haskell 2010 mode" or not.

> We hope in the future that the set of libraries standardised in the  
> report grows beyond what we have in base currently

Oh, I thought the plan was for library standardisation in the report to
be reduced, with perhaps the Haskell Platform becoming the new library
standardisation effort.


Thanks
Ian

___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

Re: Haskell 2010 libraries

[Simon Marlow]

On 30/04/10 13:19, Malcolm Wallace wrote:

4. Provide a haskell2010 package and a base2010 package that
re-exports all of base except the modules that overlap with
haskell2010. You can either use haskell2010,
haskell2010+base2010, or base. This is a bit like (1), but
avoids the need for shadowing by using package re-exports,
on the other hand confusion could well arise due to the
strange base2010 package, and some people would surely try
to use haskell2010 + base and run into difficulties.


In many ways this corresponds to my preferred solution, although I would
rephrase it thus:

* Deprecate use of the "base" package, (I do not mean to remove "base",
just to freeze it, and discourage its general use.)
* Create a new "haskell2010" package (for ghc this will be built on topcommon
of "base", but other compilers might make a different choice).
* Create a new "portablebase" package which contains (or re-exports)
all of the remaining useful and portable parts of the current "base"
_and_ "haskell2010".
* Create a new "ghcextras" package which re-exports (or defines afresh)
all of the useful but non-portable parts of the current "base".


So it seems this is closer to option (2) in my message, because 
portablebase and haskell2010 overlap, and are therefore mutually 
exclusive, whereas in (4) haskell2010 and base2010 are non-overlapping - 
that's the crucial difference.


I described this as a non-option because I thought trying to use the 
packages together might be a common problem that leads to obscure error 
messages about ambiguous modules, but perhaps it's not that bad, or at 
least not worse than the other solutions.


I think we can leave the question of whether to abstract the existing 
base into separate "portablebase" and "ghcextras" packages as a separate 
issue - there are merits to doing something like this for sure, but I'd 
like to focus specifically on Haskell 2010, and I think 
portablebase/ghcextras are orthogonal.



Because I suggest that "portablebase" re-export the "haskell2010" API in
its entirety, it would be impossible to use both packages explicitly at
the same time from a single module - users would need to choose one or
the other. Also, packages which currently depend on "base" should be
encouraged to upgrade to a dependency on "haskell2010" rather than on
"portablebase", if possible, because it provides greater stability of
interface.


We hope in the future that the set of libraries standardised in the 
report grows beyond what we have in base currently, so I'm not sure how 
much sense it makes for portablebase to re-export the haskell20xx 
modules.  Generally speaking we've been tyring to make base smaller 
rather than larger.  Indeed right now there are some modules in the 
report that aren't in base, although those are the ones we're 
considering removing in this iteration.


I like the picture where we have a small base, lots of independent 
packages, and one or more haskell20xx packages that re-exports all the 
standardised stuff from the other packages.  This arrangement extends 
smoothly, the only problem is that haskell20xx overlaps with the other 
packages.



5. Not have a haskell2010 package, but have the report say that
implementations are allowed to add things to the standard
libraries.


This seems superficially attractive, but I think it would be impossible
in practice to guarantee anything. For instance, the semantics of "take"
and "drop" changed between Haskell 1.4 and Haskell'98 iirc, with no
corresponding change in the API. With separate packages it is possible
to retain and choose between both sets of semantics.


Yes, I agree - that's a non starter.

Cheers,
Simon
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

Re: Haskell 2010 libraries

[Christian Maeder]

Malcolm Wallace schrieb:
> In many ways this corresponds to my preferred solution, although I would
> rephrase it thus:
> 
>   * Deprecate use of the "base" package,  (I do not mean to remove "base",
> just to freeze it, and discourage its general use.)
>   * Create a new "haskell2010" package (for ghc this will be built on top
> of "base", but other compilers might make a different choice).
>   * Create a new "portablebase" package which contains (or re-exports)
> all of the remaining useful and portable parts of the current "base"
> _and_ "haskell2010".
>   * Create a new "ghcextras" package which re-exports (or defines afresh)
> all of the useful but non-portable parts of the current "base".
> 
> So "haskell2010" would be stable and unchanging.  "portablebase" would
> be a superset of "haskell2010", and continue to evolve with community
> input, and parts of it would eventually migrate into "haskell2011",
> "haskell2012", etc.  Meanwhile "ghcextras" would clearly delineate those
> language/library features that are not portable, and it could continue
> to grow, or indeed shrink, with some parts migrating into "portablebase"
> as the language definition adopts extensions, or as other compilers
> adopt implementation strategies.
> 
> To illustrate the forward compatibility story, I envisage that when
> "haskell2011" is created, a new version of "portablebase" would depend
> on (and re-export) it instead of "haskell2010".  This would be OK
> because the "portablebase" API would be non-decreasing, and new Reports
> should not make library changes that have not already been trialled in
> the community.  On the other hand, the "ghcextras" package would be free
> to shrink as functionality is gradually transferred to "portablebase".
> 
> Because I suggest that "portablebase" re-export the "haskell2010" API in
> its entirety, it would be impossible to use both packages explicitly at
> the same time from a single module - users would need to choose one or
> the other.  Also, packages which currently depend on "base" should be
> encouraged to upgrade to a dependency on "haskell2010" rather than on
> "portablebase", if possible, because it provides greater stability of
> interface.
> 
> The overall dependency graph would look something like this:
> 
>   /--- stablestuff   /-- less-stable-stuff
>  /  /
>  base ---  haskell2010 --- portablebase ---\
>   \--  ghcextras   -\=== experimental-stuff

Why do you want portablebase to be a superset of haskell2010 by
re-export? Is it not better to have a package "baseextras" that depends
on haskell2010 but only exports additional modules.

Other packages can decide to depend on "haskell2010" only or on
"haskell2010" and "baseextras" (instead of "portablebase" alone).

Or do you want modules from "haskell2010" also to be "portablebase" but
with additional functions (rather than putting new functions into new
modules)?

Cheers Christian

___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

Re: Haskell 2010 libraries

[David Menendez]

On Fri, Apr 30, 2010 at 8:19 AM, Malcolm Wallace
 wrote:
> Because I suggest that "portablebase" re-export the "haskell2010" API in its
> entirety, it would be impossible to use both packages explicitly at the same
> time from a single module - users would need to choose one or the other.

Is the idea that portablebase re-exports modules at the same name? If
so, does Haskell2010 allow for package-qualified imports or would
portablebase require extensions?

-- 
Dave Menendez 

___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

Re: Haskell 2010 libraries

[Bas van Dijk]

When you talk about the package "haskell2010" do you mean a package
named "haskell" with major version "2010" as in "haskell-2010" or a
package actually named "haskell2010"?

Regards,

Bas
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

Re: Haskell 2010 libraries

[Malcolm Wallace]

During the Haskell 2010 process the
committee agreed that the libraries in the report should be updated,


i think: if committee assignment turned out to be ambiguous, it should
be returned to committee. we can discuss it here but then committee
should make a clear decision


The committee's decision is clear enough.  The question is to do with  
implementation issues that are not specified by the Report.


Regards,
Malcolm

___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

Re: Haskell 2010 libraries

[Malcolm Wallace]

 3. allow packages to shadow each other, so haskell2010 shadows
base.  This is a tantalising possibility, but I don't have
any idea what it would look like, e.g. should the client or
the package provider specify shadowing?


This sounds like a potentially complicated new mechanism, introducing  
lots of new subtleties.  Probably not a good idea for that reason alone.



 4. Provide a haskell2010 package and a base2010 package that
re-exports all of base except the modules that overlap with
haskell2010.  You can either use haskell2010,
haskell2010+base2010, or base.  This is a bit like (1), but
avoids the need for shadowing by using package re-exports,
on the other hand confusion could well arise due to the
strange base2010 package, and some people would surely try
to use haskell2010 + base and run into difficulties.


In many ways this corresponds to my preferred solution, although I  
would rephrase it thus:


  * Deprecate use of the "base" package,  (I do not mean to remove  
"base",

just to freeze it, and discourage its general use.)
  * Create a new "haskell2010" package (for ghc this will be built on  
top

of "base", but other compilers might make a different choice).
  * Create a new "portablebase" package which contains (or re-exports)
all of the remaining useful and portable parts of the current  
"base"

_and_ "haskell2010".
  * Create a new "ghcextras" package which re-exports (or defines  
afresh)

all of the useful but non-portable parts of the current "base".

So "haskell2010" would be stable and unchanging.  "portablebase" would  
be a superset of "haskell2010", and continue to evolve with community  
input, and parts of it would eventually migrate into "haskell2011",  
"haskell2012", etc.  Meanwhile "ghcextras" would clearly delineate  
those language/library features that are not portable, and it could  
continue to grow, or indeed shrink, with some parts migrating into  
"portablebase" as the language definition adopts extensions, or as  
other compilers adopt implementation strategies.


To illustrate the forward compatibility story, I envisage that when  
"haskell2011" is created, a new version of "portablebase" would depend  
on (and re-export) it instead of "haskell2010".  This would be OK  
because the "portablebase" API would be non-decreasing, and new  
Reports should not make library changes that have not already been  
trialled in the community.  On the other hand, the "ghcextras" package  
would be free to shrink as functionality is gradually transferred to  
"portablebase".


Because I suggest that "portablebase" re-export the "haskell2010" API  
in its entirety, it would be impossible to use both packages  
explicitly at the same time from a single module - users would need to  
choose one or the other.  Also, packages which currently depend on  
"base" should be encouraged to upgrade to a dependency on  
"haskell2010" rather than on "portablebase", if possible, because it  
provides greater stability of interface.


The overall dependency graph would look something like this:

  /--- stablestuff   /-- less-stable-stuff
 /  /
 base ---  haskell2010 --- portablebase ---\
  \--  ghcextras   -\=== experimental-stuff


5. Not have a haskell2010 package, but have the report say that
implementations are allowed to add things to the standard
libraries.


This seems superficially attractive, but I think it would be  
impossible in practice to guarantee anything.  For instance, the  
semantics of "take" and "drop" changed between Haskell 1.4 and  
Haskell'98 iirc, with no corresponding change in the API.  With  
separate packages it is possible to retain and choose between both  
sets of semantics.


Regards,
Malcolm

___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

Re: Haskell 2010 libraries

[Bulat Ziganshin]

Hello Simon,

Friday, April 30, 2010, 1:42:33 PM, you wrote:

> During the Haskell 2010 process the
> committee agreed that the libraries in the report should be updated,

i think: if committee assignment turned out to be ambiguous, it should
be returned to committee. we can discuss it here but then committee
should make a clear decision


-- 
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

[Ian Lynagh]

On Tue, Jul 14, 2009 at 01:57:34PM +0100, Ian Lynagh wrote:
> 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:

Also, we've just had a proposal to change some others:
Generalize the type of Data.List.{deleteBy, deleteFirstsBy}
http://hackage.haskell.org/trac/ghc/ticket/3399

Both functions are spec in List in haskell98:
http://haskell.org/onlinereport/list.html


Thanks
Ian

___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

Re: Haskell 2010: libraries

[Ian Lynagh]

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. Ixkeep 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

___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

Re: Haskell 2010: libraries

[David Menendez]

On Thu, Jul 16, 2009 at 4:36 AM, Simon Marlow wrote:
> 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?

Any package that defines an Arrow instance can't work with both 3.0.2
and 3.0.3, because they provide incompatible class definitions.
(That's where Category was introduced.)

It broke at least one package at the time, although I think it's been
fixed by now.

In 
,
you argued:

> We simply *can't* provide the same API as base-3.0.2 without defining
> a new Arrow class, and that would kill compatibility with base-4.  On the
> other hand, we did know this could happen (changes to datatypes also
> cause the same problem), it's the tradeoff with trying to provide base-3
> as a compatibility layer over base-4.

Which is probably the right call for obscure classes like Arrow, but
not more common ones like Num or Monad.

-- 
Dave Menendez 




-- 
Dave Menendez 

___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

Re: Haskell 2010: libraries

[Heinrich Apfelmus]

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

___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

Re: Haskell 2010: libraries

[Simon Marlow]

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

___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

Re: Haskell 2010: libraries

[Simon Marlow]

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
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

Re: Haskell 2010: libraries

[David Menendez]

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?

-- 
Dave Menendez 

___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

Re: Haskell 2010: libraries

[Mathias Stearn]

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.


On Wed, Jul 15, 2009 at 10:54 AM, 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.
>
>
> Thanks
> Ian
>
> ___
> 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: Haskell 2010: libraries

[Sittampalam, Ganesh]

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 
 
=== 
 
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

Re: Haskell 2010: libraries

[Simon Marlow]

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
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

Re: Haskell 2010: libraries

[Simon Marlow]

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?


Cheers,
Simon
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

Re: Haskell 2010: libraries

[Ian Lynagh]

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.


Thanks
Ian

___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

RE: Haskell 2010: libraries

[Sittampalam, Ganesh]

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.Prelude
>> where  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 
 
=== 
 
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

Re: Haskell 2010: libraries

[Simon Marlow]

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

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.Prelude
where  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).


So why can't we use package versioning to do this?  Suppose we have a 
'haskell-std' package, with versions starting at 2010, providing modules 
like Data.List.  The problem is that haskell-std:Data.List overlaps with 
base:Data.List.


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

(or does it have to be haskell-std-2010.0?)

In some ways this is nice, because we will be able to keep old versions 
of haskell-std much longer than we can keep old versions of base.  And 
in due course, we can move more modules into haskell-std.  That makes an 
incremental approach to library standardisation possible, in the same 
way as we have modularised the language standardisation process.


So, if we have standard Haskell library modules, then I believe they 
should be separate at the package level (as they are now).


Cheers,
Simon
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

Re: Haskell 2010: libraries

[Ian Lynagh]

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.Prelude
where  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

Re: Haskell 2010: libraries

[Ian Lynagh]

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: Haskell 2010: libraries

[Ian Lynagh]

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

[Duncan Coutts]

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

[Malcolm Wallace]

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: Haskell 2010: libraries

[Sittampalam, Ganesh]

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.
>> 
> 
> 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. 

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.

Clearly there is the downside that this will be rather verbose, but it
should minimise the constraints placed on the faster moving libraries
that most people use while still providing a properly standardised and
stable set of code.

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

[Ian Lynagh]

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. Ixkeep 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. IOkeep as System.IO
> 11. Directory drop
> 12. Systemdrop (superseded by System.Process)
> 13. Time  drop
> 14. Localedrop
> 15. CPUTime   drop
> 16. Randomdrop

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

___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

Re: Haskell 2010: libraries

[Duncan Coutts]

On Mon, 2009-07-13 at 21:57 +0100, Duncan Coutts wrote:
> On Wed, 2009-07-08 at 15:09 +0100, Simon Marlow wrote:
> 
> > I'm mainly concerned with projecting a consistent picture in the Report, 
> > so as not to mislead or confuse people.  Here are the options I can see:
> 
> >   2. Just drop the obvious candidates (Time, Random, CPUTime,
> >  Locale, Complex?), leaving the others.
> > 
> >   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.  Also it would seem
> >  slightly strange to have a seemingly random set
> >  of library modules in the report.

Another thing we can do here is specify that the contents of these
modules is a minimum and not a maximum, allowing additions through the
usual library proposal process.

> >   4. Combine 2 and 3: drop some, rename the rest.
> 
> 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.

Oh and additionally include the FFI modules under their new names.

Duncan

___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

Re: Haskell 2010: libraries

[Duncan Coutts]

On Wed, 2009-07-08 at 15:09 +0100, Simon Marlow wrote:

> I'm mainly concerned with projecting a consistent picture in the Report, 
> so as not to mislead or confuse people.  Here are the options I can see:

>   2. Just drop the obvious candidates (Time, Random, CPUTime,
>  Locale, Complex?), leaving the others.
> 
>   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.  Also it would seem
>  slightly strange to have a seemingly random set
>  of library modules in the report.
> 
>   4. Combine 2 and 3: drop some, rename the rest.

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

The slightly odd thing here is keeping System.IO but dropping the other
IO libs Directory and System. We obviously have to drop System, because
it's more or less a deprecated API and it's superseded by System.Process
(which we almost certainly do not want to standardise at this stage).

It'd be nice to have a clear dividing line of keeping the pure stuff and
dropping the bits for interacting with the system however we have to
keep System.IO since bits of it are re-exported through the Prelude
(unless we also trim the Prelude). 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.

Another quirk is that we never changed the name of the Numeric module.

Duncan

___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

Re: Haskell 2010: libraries

[Simon Marlow]

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
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

Re: Haskell 2010: libraries

[Ian Lynagh]

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

___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

Re: Haskell 2010: libraries

[Ashley Yakeley]

Ross Paterson wrote:


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?

The Prelude specification imports Char, Numeric and Ratio.  It also uses
(but does not import) IO(BufferMode(..), hSetBuffering, stdio, stdout).
The Numeric specification imports Array, but only uses it for an
optimization of 2^n.


The Prelude seems to do double duty:

* stuff needed to support the language definition, etc.

* useful stuff you'll probably want to import

Is it worth separating these?

--
Ashley Yakeley

___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

Re: Haskell 2010: libraries

[Ross Paterson]

On Sat, Jul 11, 2009 at 08:54:14PM +1000, Manuel M T Chakravarty wrote:
> Ross Paterson:
>> 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 difference is that the types are used by the core language definition
(section 3.2 of the FFI Addendum), and the functions aren't.
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

Re: Haskell 2010: libraries

[Manuel M T Chakravarty]

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).

___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

Re: Haskell 2010: libraries

[Manuel M T Chakravarty]

Simon Marlow:

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.


I don't mind defining libraries separately, but not defining them at  
all is problematic unless a core set of libraries isn't rigorously  
defined somewhere else.


Manuel

___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

Re: Haskell 2010: libraries

[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?

The Prelude specification imports Char, Numeric and Ratio.  It also uses
(but does not import) IO(BufferMode(..), hSetBuffering, stdio, stdout).
The Numeric specification imports Array, but only uses it for an
optimization of 2^n.
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

Re: Haskell 2010: libraries

[Heinrich Apfelmus]

Simon Marlow wrote:
> 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.
> 
> 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.

Yes.

> 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.

Oh, that sounds more bold than I expected it to be. Yes, I agree that we
should exclude modules that don't really belong; this should be cheap to
implement.

> 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?

The way I imagine it is that the libraries thus standardized will *not*
be the libraries that most people are going to use; the latest versions
of the  base  library or the Haskell Platform will define a current set
of "standard" libraries.

Rather, I imagine the libraries standardized in the report to be a
reference for writing code that does not need to be updated when  base
or the HP change. Put differently, if I put the

  {-# LANGUAGE Haskell'2010 #-}

flag into my source code, then I'm assured that it will compile for all
eternity because my favorite compiler is going to use the  base  library
specified in the report instead of the newest  base  library available
on hackage. This requires compiler support.

In other words, this is option 1. embellished with the cheapest way of
blessing a bunch libraries for the purpose of backward compatibility.


This may not be the best solution to the  backward compatibility VS
libraries change  dilemma, but I think it reflects current practice. I
can write strict H98 if I want to, but most of the time I'm just going
to use the latest  base  anyway.



On a side note, if Haskell 2010 gets a library report, then I think this
should be in the form of a simple package on hackage, named something
like "haskell2010-libraries".


Regards,
apfelmus

--
http://apfelmus.nfshost.com

___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

Re: Haskell 2010: libraries

[Simon Marlow]

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
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

Re: Haskell 2010: libraries

[Simon Marlow]

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
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

Re: Haskell 2010: libraries

[Simon Marlow]

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
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

Re: Haskell 2010: libraries

[Ian Lynagh]

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


Thanks
Ian

___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

Re: Haskell 2010: libraries

[Isaac Dupree]

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
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

Re: Haskell 2010: libraries

[Heinrich Apfelmus]

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

___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

Re: Haskell 2010: libraries

[Bulat Ziganshin]

Hello Simon,

Wednesday, July 8, 2009, 6:09:29 PM, you 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)

but we probably aren't yet ready to produce Library Standard. it will be great
to include in Standard only *versioned* libraries while ATM many
features (such as IO) is a part of non-versioned library named "base"

well, it' versioned but not very good

-- 
Best regards,
 Bulatmailto:bulat.zigans...@gmail.com

___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime