headers
Simon Marlow | 30 Apr 2010 22:37
Picon

Re: Haskell 2010 libraries

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
(Continue reading)

Permalink | Reply |
headers
Felipe Lessa | 1 May 2010 00:52
Picon
Gravatar

Re: Haskell 2010 libraries

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

Thanks,

--
Felipe.
Permalink | Reply |
headers
Simon Marlow | 1 May 2010 21:08
Picon

Re: Haskell 2010 libraries

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.
(Continue reading)

Permalink | Reply |
headers
Ian Lynagh | 1 May 2010 18:16
Picon
Gravatar

Re: Haskell 2010 libraries

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
(Continue reading)

Permalink | Reply |
headers
Simon Marlow | 1 May 2010 21:05
Picon

Re: Haskell 2010 libraries

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
(Continue reading)

Permalink | Reply |
headers
Ian Lynagh | 1 May 2010 21:17
Picon
Gravatar

Re: Haskell 2010 libraries

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!
(Continue reading)

Permalink | Reply |
headers
Simon Marlow | 2 May 2010 10:05
Picon

Re: Haskell 2010 libraries

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
Permalink | Reply |
headers
Brandon S. Allbery KF8NH | 1 May 2010 23:59
Picon
Favicon

Re: Haskell 2010 libraries

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] allbery <at> kf8nh.com
system administrator [openafs,heimdal,too many hats] allbery <at> ece.cmu.edu
electrical and computer engineering, carnegie mellon university    KF8NH


_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries
(Continue reading)

Permalink | Reply |

Gmane