GHC 7.8 release?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
142 messages Options
1 ... 45678
Reply | Threaded
Open this post in threaded view
|

Re: base package -- goals

Roman Cheplyaka-2
* Stephen Paul Weber <[hidden email]> [2013-02-25 11:29:42-0500]
> Why shouldn't Prelude (and other really stable, standard modules)
> just live in the `haskell2010` package?

Because then we can't make changes to it without producing a new
language standard.

Roman

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: base package -- goals

Stephen Paul Weber
Somebody claiming to be Roman Cheplyaka wrote:
>* Stephen Paul Weber <[hidden email]> [2013-02-25 11:29:42-0500]
>> Why shouldn't Prelude (and other really stable, standard modules)
>> just live in the `haskell2010` package?
>
>Because then we can't make changes to it without producing a new
>language standard.

That sounds like a good thing.  Very in line with the goal of making stable
modules more stable.

--
Stephen Paul Weber, @singpolyma
See <http://singpolyma.net> for how I prefer to be contacted
edition right joseph

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

signature.asc (853 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: base package -- goals

Ian Lynagh-2
In reply to this post by Stephen Paul Weber
On Mon, Feb 25, 2013 at 11:29:42AM -0500, Stephen Paul Weber wrote:

> Somebody claiming to be Ian Lynagh wrote:
> >On Mon, Feb 25, 2013 at 02:31:56PM +0100, Joachim Breitner wrote:
> >>In any case there is still the problem: What and where is the Prelude...
> >>but maybe let’s postpone this.
> >
> >I'd put it in its own package for now, and then look at whether/what it
> >should be merged with later.
>
> Why shouldn't Prelude (and other really stable, standard modules)
> just live in the `haskell2010` package?

If we did that then every package would depend on haskell2010, which is
fine until haskell2013 comes along and they all need to be changed (or
miss out on any improvements that were made).

Even the really stable modules change, incidentally. For example, since
Haskell 2010, the Show superclass of Prelude.Num was removed, Prelude no
longer exports catch, and Data.List gained a function dropWhileEnd.


Thanks
Ian


_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: base package -- goals

Herbert Valerio Riedel
Ian Lynagh <[hidden email]> writes:

[...]

> If we did that then every package would depend on haskell2010, which
> is fine until haskell2013 comes along and they all need to be changed
> (or miss out on any improvements that were made).

...wouldn't there also be the danger of type(class)-incompatible
(e.g. the superclass breakages for startes) changes between say
haskell2010 and haskell2013, that would cause problems when trying to
mix libraries depending on different haskell20xx library versions?


_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: base package -- goals

Ian Lynagh-2
On Mon, Feb 25, 2013 at 06:38:46PM +0100, Herbert Valerio Riedel wrote:

> Ian Lynagh <[hidden email]> writes:
>
> [...]
>
> > If we did that then every package would depend on haskell2010, which
> > is fine until haskell2013 comes along and they all need to be changed
> > (or miss out on any improvements that were made).
>
> ...wouldn't there also be the danger of type(class)-incompatible
> (e.g. the superclass breakages for startes) changes between say
> haskell2010 and haskell2013, that would cause problems when trying to
> mix libraries depending on different haskell20xx library versions?

I think that actually, for the Num/Show change, the hasell98/haskell2010
packages just incorrectly re-export the new class.

Personally, I don't think the language report should be specifying the
content of libraries at all, and I doubt anyone really uses the haskell*
packages. A separate library specification, perhaps based on the Haskell
Platform, would make more sense IMO. But that's another debate  :-)


Thanks
Ian


_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: base package -- goals

Johan Tibell-2
In reply to this post by Joachim Breitner-2
Hi all,

Let me add the goals I had in mind last time I considered trying to split base.

 1. I'd like to have text Handles use the Text type and binary Handles use the ByteString type. Right now we have this somewhat awkward setup where the I/O APIs are spread out and bundled with pure types. Splitting base would let us fix this and write a better I/O layer.

 2. The I/O manager currently has a copy of IntMap inside its implementation because base cannot use containers. Splitting base would let us get rid of this code duplication. 

I'm less interested in having super fine-grained dependencies in my libraries. More packages usually means more busy-work managing dependencies. Taken to its extreme you could imagine having base-maybe, base-bool, and whatnot. I don't think this is an improvement. Splitting base into perhaps 3-5 packages (e.g. GHC.*, IO, pure types) should let us get a bunch of benefits without too many downsides.

-- Johan


_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: base package -- goals

Joachim Breitner-2
Hi,

Am Montag, den 25.02.2013, 11:25 -0800 schrieb Johan Tibell:
>  1. I'd like to have text Handles use the Text type and binary Handles
> use the ByteString type. Right now we have this somewhat awkward setup
> where the I/O APIs are spread out and bundled with pure types.
> Splitting base would let us fix this and write a better I/O layer.
>
>
>  2. The I/O manager currently has a copy of IntMap inside its
> implementation because base cannot use containers. Splitting base
> would let us get rid of this code duplication.

added to http://hackage.haskell.org/trac/ghc/wiki/SplitBase

It would be interesting to see if Text and Bytestring (without the file
IO parts) can be compiled using the base-foreign package extracted here
https://github.com/nomeata/packages-base/tree/base-split/base-foreign.
Looking at the imports, it seems possible. Then a base-io-system package
can indeed depend on text and bytestring, and provide the appropriately
typed file IO functions there.

The containers package looks like a good example for a package that sits
on base-pure: No IO, no FFI. So with the split suggested in my branch,
having the ghc-io-system depend on containers seems possible.

> I'm less interested in having super fine-grained dependencies in my
> libraries. More packages usually means more busy-work managing
> dependencies. Taken to its extreme you could imagine having
> base-maybe, base-bool, and whatnot. I don't think this is an
> improvement. Splitting base into perhaps 3-5 packages (e.g. GHC.*, IO,
> pure types) should let us get a bunch of benefits without too many
> downsides.

This is basically the goal added by SPJ: Split base into as FEW packages
as possible, consistent with meeting the other goals.

Greetings,
Joachim

--
Joachim "nomeata" Breitner
Debian Developer
  [hidden email] | ICQ# 74513189 | GPG-Keyid: 4743206C
  JID: [hidden email] | http://people.debian.org/~nomeata


_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

RE: base package -- goals

Simon Peyton Jones
In reply to this post by Johan Tibell-2

I think it would be vv helpful to have all these goals articulated on the wiki page.

          http://hackage.haskell.org/trac/ghc/wiki/SplitBase

 

For the “avoiding version bump” goal, I still don’t see why having a simple “shim” package on top whose API is stable, and whose version number changes seldom, would not do the job. 

 

Simon

 

From: Johan Tibell [mailto:[hidden email]]
Sent: 25 February 2013 19:25
To: Joachim Breitner
Cc: [hidden email]; Simon Peyton-Jones
Subject: Re: base package -- goals

 

Hi all,

 

Let me add the goals I had in mind last time I considered trying to split base.

 

 1. I'd like to have text Handles use the Text type and binary Handles use the ByteString type. Right now we have this somewhat awkward setup where the I/O APIs are spread out and bundled with pure types. Splitting base would let us fix this and write a better I/O layer.

 

 2. The I/O manager currently has a copy of IntMap inside its implementation because base cannot use containers. Splitting base would let us get rid of this code duplication. 

 

I'm less interested in having super fine-grained dependencies in my libraries. More packages usually means more busy-work managing dependencies. Taken to its extreme you could imagine having base-maybe, base-bool, and whatnot. I don't think this is an improvement. Splitting base into perhaps 3-5 packages (e.g. GHC.*, IO, pure types) should let us get a bunch of benefits without too many downsides.

 

-- Johan

 


_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: base package -- goals

Simon Marlow-7
In reply to this post by Ian Lynagh-2
On 25/02/13 18:05, Ian Lynagh wrote:

> On Mon, Feb 25, 2013 at 06:38:46PM +0100, Herbert Valerio Riedel wrote:
>> Ian Lynagh <[hidden email]> writes:
>>
>> [...]
>>
>>> If we did that then every package would depend on haskell2010, which
>>> is fine until haskell2013 comes along and they all need to be changed
>>> (or miss out on any improvements that were made).
>>
>> ...wouldn't there also be the danger of type(class)-incompatible
>> (e.g. the superclass breakages for startes) changes between say
>> haskell2010 and haskell2013, that would cause problems when trying to
>> mix libraries depending on different haskell20xx library versions?
>
> I think that actually, for the Num/Show change, the hasell98/haskell2010
> packages just incorrectly re-export the new class.
>
> Personally, I don't think the language report should be specifying the
> content of libraries at all,

It's not that straightforward, because the language report refers to
various library functions, types and classes.  For example, integer
literals give rise to a constraint on Num, so we have to say what Num
is.  Guards depend on Bool, the translation of list comprehensions
refers to "map", and so on.

It could be whittled down certainly (we actually removed a few libraries
in Haskell 2010), but there's still a core that is tied to the language
definition.

Cheers,
        Simon


_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: base package -- goals

Simon Marlow-7
In reply to this post by Johan Tibell-2
On 25/02/13 19:25, Johan Tibell wrote:

> Hi all,
>
> Let me add the goals I had in mind last time I considered trying to
> split base.
>
>   1. I'd like to have text Handles use the Text type and binary Handles
> use the ByteString type. Right now we have this somewhat awkward setup
> where the I/O APIs are spread out and bundled with pure types. Splitting
> base would let us fix this and write a better I/O layer.
>
>   2. The I/O manager currently has a copy of IntMap inside its
> implementation because base cannot use containers. Splitting base would
> let us get rid of this code duplication.
>
> I'm less interested in having super fine-grained dependencies in my
> libraries. More packages usually means more busy-work managing
> dependencies. Taken to its extreme you could imagine having base-maybe,
> base-bool, and whatnot. I don't think this is an improvement. Splitting
> base into perhaps 3-5 packages (e.g. GHC.*, IO, pure types) should let
> us get a bunch of benefits without too many downsides.

+1 to all that.

I'd like to add one other thing that we've been wanting to clean up: the
unix/Win32 packages should sit low down in the dependency hierarchy, so
that the IO library can depend on them.  Right now we have bits and
pieces of unix/Win32 in the base package, some of which have to be
re-exported via internal modules in base to unix/Win32 proper
(System.Posix.Internals).

I seem to recall the situation with signal handlers being a bit of a
mess: the code to handle signals is in base, but the API is in unix.
Glancing at the code in GHC.Conc.Signals it looks like I even had to use
Dynamic to get around the dependency problems (shhh!).

Cleaning up things like this is a win.  But I'm with Johan in that
having fine-grained packages imposes a cost on the clients (where the
clients in this case includes everyone), so there should be significant
tangible benefits (e.g. more stability).

Cheers,
        Simon


_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: base package -- goals

Ian Lynagh-2
In reply to this post by Simon Marlow-7
On Wed, Feb 27, 2013 at 04:54:35PM +0000, Simon Marlow wrote:

> On 25/02/13 18:05, Ian Lynagh wrote:
> >
> >Personally, I don't think the language report should be specifying the
> >content of libraries at all,
>
> It's not that straightforward, because the language report refers to
> various library functions, types and classes.  For example, integer
> literals give rise to a constraint on Num, so we have to say what
> Num is.  Guards depend on Bool, the translation of list
> comprehensions refers to "map", and so on.
>
> It could be whittled down certainly (we actually removed a few
> libraries in Haskell 2010), but there's still a core that is tied to
> the language definition.

Yes, OK, my language was a bit strong: s/at all/any more than necessary/


Thanks
Ian


_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: base package -- goals

Joachim Breitner-2
In reply to this post by Simon Peyton Jones
Hi,

Am Dienstag, den 26.02.2013, 10:08 +0000 schrieb Simon Peyton-Jones:
> I think it would be vv helpful to have all these goals articulated on
> the wiki page.
>
>          http://hackage.haskell.org/trac/ghc/wiki/SplitBase
>

well, all the goals are there (or are they not sufficiently well
explained)?

I also tried to compare the two approaches – the re-exporting
API-specifying packages and the actual split of base – by listing their
advantages (I skipped the disadvantages, these would just be the
negation of the other advantages list...) at
http://hackage.haskell.org/trac/ghc/wiki/SplitBase#Approaches

I don’t feel in the position to actually make a call here, or even to
cast a vote with confidence, but I’m happy to continue summarizing the
discussion until a consensus is found. If there is more discussion, that
is.

Greetings,
Joachim

--
Joachim "nomeata" Breitner
Debian Developer
  [hidden email] | ICQ# 74513189 | GPG-Keyid: 4743206C
  JID: [hidden email] | http://people.debian.org/~nomeata


_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

RE: base package -- goals

Simon Peyton Jones
|  I don’t feel in the position to actually make a call here, or even to cast a vote with
|  confidence, but I’m happy to continue summarizing the discussion until a
|  consensus is found. If there is more discussion, that is.

I've updated the page http://hackage.haskell.org/trac/ghc/wiki/SplitBase a bit.

It seems to me that there are two kinds of goals

A Better for external clients (stable APRs, few version bumps)
B Better for internal implementation (eg using containers or bytestring in base)

On the Wiki page, (G1) and (G2) are to do with group (A).  And this seems best handled by defining client-facing shim packages that export just what you want.

However (G4) and later seem to be concerned with (B), and they clearly do require re-structuring the code.

It seems entirely possible to me that BOTH will be needed.  That is, the structure to achieve (B) will not be precisely what is wanted for (A).  So it seems to be me that both approaches are valid and we might want to do both.  We can do them in either order, or simultaneously.  (Mind you, doing (A) first would make (B) less disruptive for our users.)

In short, less of an either/or, more of a both/and.

Simon

|  -----Original Message-----
|  From: [hidden email] [mailto:glasgow-haskell-users-
|  [hidden email]] On Behalf Of Joachim Breitner
|  Sent: 07 March 2013 20:22
|  To: [hidden email]
|  Subject: Re: base package -- goals
|  
|  Hi,
|  
|  Am Dienstag, den 26.02.2013, 10:08 +0000 schrieb Simon Peyton-Jones:
|  > I think it would be vv helpful to have all these goals articulated on
|  > the wiki page.
|  >
|  >          http://hackage.haskell.org/trac/ghc/wiki/SplitBase
|  >
|  
|  well, all the goals are there (or are they not sufficiently well explained)?
|  
|  I also tried to compare the two approaches – the re-exporting API-specifying
|  packages and the actual split of base – by listing their advantages (I skipped the
|  disadvantages, these would just be the negation of the other advantages list...) at
|  http://hackage.haskell.org/trac/ghc/wiki/SplitBase#Approaches
|  
|  I don’t feel in the position to actually make a call here, or even to cast a vote with
|  confidence, but I’m happy to continue summarizing the discussion until a
|  consensus is found. If there is more discussion, that is.|  
|  Greetings,
|  Joachim
|  
|  --
|  Joachim "nomeata" Breitner
|  Debian Developer
|    [hidden email] | ICQ# 74513189 | GPG-Keyid: 4743206C
|    JID: [hidden email] | http://people.debian.org/~nomeata

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: base package -- goals

Johan Tibell-2
On Mon, Mar 11, 2013 at 4:45 PM, Simon Peyton-Jones <[hidden email]> wrote:
B Better for internal implementation (eg using containers or bytestring in base)

Note that this also means better code for external clients, as we can offer e.g. a better System.IO that lets people use Handles to read Text and ByteStrings in a more natural way (i.e. the I/O functions will be in one place, not spread out throughout N data structure libraries). 

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: base package -- goals

Joachim Breitner-2
In reply to this post by Simon Peyton Jones
Hi,

Am Montag, den 11.03.2013, 23:45 +0000 schrieb Simon Peyton-Jones:
> |  I don’t feel in the position to actually make a call here, or even to cast a vote with
> |  confidence, but I’m happy to continue summarizing the discussion until a
> |  consensus is found. If there is more discussion, that is.
>
> I've updated the page http://hackage.haskell.org/trac/ghc/wiki/SplitBase a bit.

thanks.

> It seems to me that there are two kinds of goals
>
> A Better for external clients (stable APRs, few version bumps)
> B Better for internal implementation (eg using containers or
> bytestring in base)
>
> On the Wiki page, (G1) and (G2) are to do with group (A).  And this
> seems best handled by defining client-facing shim packages that export
> just what you want.
>
> However (G4) and later seem to be concerned with (B), and they clearly
> do require re-structuring the code.
>
> It seems entirely possible to me that BOTH will be needed.  That is,
> the structure to achieve (B) will not be precisely what is wanted for
> (A).  So it seems to be me that both approaches are valid and we might
> want to do both.  We can do them in either order, or simultaneously.
> (Mind you, doing (A) first would make (B) less disruptive for our
> users.)
>
> In short, less of an either/or, more of a both/and.
from reading between the lines I get the impression that you’d prefer
(A) to happen first, in order to do (B) more easily. If (A) was
successful, we even have to worry less about bad decisions while doing
(B), as it would be relatively easy to fix these.

So if we do (A), we still have the problem that Ian pointed out: Why
should anyone use these shim packages, when they can continue to use
base?

This is especially true when the shim packages are less simple to use,
due to the handling of Prelude. I see some options (assuming, just for
demonstration, we have to shim packages base-pure and base-io):

     1. Prelude stays in base, packages wanting to use the shim packages
        exclusively have to use {-# LANGUAGE NoImplicitPrelude #-}
        everywhere and import stuff explicitly. base-pure would probably
        provide its subset of the Prelude in Prelude.Pure, to be
        imported explicitly.
     2. Prelude goes to a separate shim package, base-prelude. Extra
        dependency required, packages that want to only depend on
        base-pure have no Prelude to use, same problem as in 1.
     3. Every shim package has a Prelude module. Good for those who
        depend on base-pure, but those who require both base-pure and
        base-io have no an ambiguous import.
     4. Separate packages base-io-prelude and base-pure-prelude
        providing Prelude’s containing stuff of base-* (+ dependencies).
        Packages can pull in precisely the Prelude they want, but yet
        more packages.

None of these look particularly appealing. Here some ideas to make it
more convenient for the programmer that require changes to GHC and how
it treats packages:

     I. It automatically imports _all_ visible Prelude modules. So
        base-pure provides the pure Prelude and base-io adds the IO
        functions.
    II. Same, but a bit more explicit: We extend the package
        configuration by a "prelude-modules" field. Every module listed
        in that field of every visible package is treated as a Prelude
        and automatically imported (unless {-# LANGUAGE
        NoImplicitPreldue #-} is active.)
   III. Ambiguous module imports do not cause an error if, among the
        modules, there is one that is a superset of all others, i.e.
        reexports all other modules.

I personally find I. quite elegant and appealing, as it is clearly the
behavior expected by library authors if they have their code
build-depend on their selection of shim packages, and requires no extra
prelude packages. One might see it as a disadvantages that now arbitrary
packages can add to the “virtual prelude”, although I don’t think it
would be abused without good reason, and who knows what clever things
people will do with that feature.

Greetings,
Joachim


--
Joachim "nomeata" Breitner
Debian Developer
  [hidden email] | ICQ# 74513189 | GPG-Keyid: 4743206C
  JID: [hidden email] | http://people.debian.org/~nomeata


_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: base package -- goals

Ian Lynagh-2
On Tue, Mar 12, 2013 at 09:47:21AM +0100, Joachim Breitner wrote:
>
> This is especially true when the shim packages are less simple to use,
> due to the handling of Prelude.

Just to make sure I am following you, I think you are saying:

Everything would work fine if there was a Prelude in base (used by
packages that still use base, and not the shims) and a Prelude in one of
the shim packages (used by packages that exclusively use the shims, and
not base).

The problem is that Prelude doesn't fit in any of the sensible shim
packages (as it contains, for example, both pure and file IO functions),
but having a shim package purely for the Prelude seems excessive.


This is a problem regardless of whether we do A or B or both.


I think we should avoid getting bogged down in one small detail at this
stage. If we make the bulk of the changes now then we still have a few
months to polish the result before it gets effectively frozen by being
released.

If you don't like the idea of putting it in its own package, then I
think either the file-io package (as that's the "worst" thing it
contains) or the pure package (as that's the package most likely to be
depended on anyway) would make most sense.


Thanks
Ian


_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: base package -- goals

Joachim Breitner-2
Hi,

Am Dienstag, den 12.03.2013, 14:35 +0000 schrieb Ian Lynagh:
> I think we should avoid getting bogged down in one small detail at this
> stage. If we make the bulk of the changes now then we still have a few
> months to polish the result before it gets effectively frozen by being
> released.

I’m not sure it is just a small detail: The handling of Prelude will
influence how practical it is to use the shim package, and how practical
it is to use just some of the shim packages.

> If you don't like the idea of putting it in its own package, then I
> think either the file-io package (as that's the "worst" thing it
> contains) or the pure package (as that's the package most likely to be
> depended on anyway) would make most sense.

Both have issues: Putting it in file-io will cause everyone to depend on
file-io, subverting „To allow packages to be explict about what they
need (G2)“. Putting it in pure will make pure not pure any more, as the
Prelude would still have to contain writeFile etc.

But you are right that this discussing this should not prevent us from
deciding between A, B and both, and then actually doing it.

Greetings,
Joachim

--
Joachim "nomeata" Breitner
Debian Developer
  [hidden email] | ICQ# 74513189 | GPG-Keyid: 4743206C
  JID: [hidden email] | http://people.debian.org/~nomeata


_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: base package -- goals

Ian Lynagh-2
On Tue, Mar 12, 2013 at 03:58:28PM +0100, Joachim Breitner wrote:
>
> Both have issues: Putting it in file-io will cause everyone to depend on
> file-io

If it ended up there, then we'd presumably encourage people to use
NoImplicitPrelude and import e.g. list functions from Data.List rather
than Prelude.


Thanks
Ian


_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: base package -- goals

Mario Blažević
In reply to this post by Joachim Breitner-2
On 13-03-12 04:47 AM, Joachim Breitner wrote:
> ...
> None of these look particularly appealing. Here some ideas to make it
> more convenient for the programmer that require changes to GHC and how
> it treats packages:
>
>       I. It automatically imports _all_ visible Prelude modules. So
>          base-pure provides the pure Prelude and base-io adds the IO
>          functions.


        I like this proposal, but it goes further than necessary for your goal,
and it could lead to some messy conflicts. All you need is


>      2. Prelude goes to a separate shim package, base-prelude. Extra
>         dependency required, packages that want to only depend on
>         base-pure have no Prelude to use, same problem as in 1.


plus the ability to specify, per *user* package, from which package it
wants to import Prelude. The default would be base-prelude, but a
single-line change could switch that to base-pure-prelude or
awesome-alternative-prelude. Presumably ghc-pkg would need a new
command-line option to specify the Prelude package as well.



_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

RE: base package -- goals

Simon Peyton Jones
In reply to this post by Joachim Breitner-2
| > In short, less of an either/or, more of a both/and.
|
| from reading between the lines I get the impression that you’d prefer
| (A) to happen first, in order to do (B) more easily. If (A) was
| successful, we even have to worry less about bad decisions while doing
| (B), as it would be relatively easy to fix these.

Yes, that's right. (A) sounds like a low-cost way of meeting some goals.  (B) is a higher-cost way of meeting some further goals.


Your follow-on remarks (appended below) about which implicit Prelude you get if you (say) import only `base-pure` are well-taken, but they apply equally to (B).  Worth adding a section to the Wiki page to discuss this?

My gut feel: for the minority who do not want to depend on enough base-X packages to get the Haskell-98 Prelude, use NoImplicitPrelude (since indeed you don't depend on enough to get the H98 Prelude) and import what you want explicitly.

Most people won't care and will continue to depend on enough to get Prelude.

Simon



| So if we do (A), we still have the problem that Ian pointed out: Why
| should anyone use these shim packages, when they can continue to use
| base?
|
| This is especially true when the shim packages are less simple to use,
| due to the handling of Prelude. I see some options (assuming, just for
| demonstration, we have to shim packages base-pure and base-io):
|
|      1. Prelude stays in base, packages wanting to use the shim packages
|         exclusively have to use {-# LANGUAGE NoImplicitPrelude #-}
|         everywhere and import stuff explicitly. base-pure would probably
|         provide its subset of the Prelude in Prelude.Pure, to be
|         imported explicitly.
|      2. Prelude goes to a separate shim package, base-prelude. Extra
|         dependency required, packages that want to only depend on
|         base-pure have no Prelude to use, same problem as in 1.
|      3. Every shim package has a Prelude module. Good for those who
|         depend on base-pure, but those who require both base-pure and
|         base-io have no an ambiguous import.
|      4. Separate packages base-io-prelude and base-pure-prelude
|         providing Prelude’s containing stuff of base-* (+ dependencies).
|         Packages can pull in precisely the Prelude they want, but yet
|         more packages.
|
| None of these look particularly appealing. Here some ideas to make it
| more convenient for the programmer that require changes to GHC and how
| it treats packages:
|
|      I. It automatically imports _all_ visible Prelude modules. So
|         base-pure provides the pure Prelude and base-io adds the IO
|         functions.
|     II. Same, but a bit more explicit: We extend the package
|         configuration by a "prelude-modules" field. Every module listed
|         in that field of every visible package is treated as a Prelude
|         and automatically imported (unless {-# LANGUAGE
|         NoImplicitPreldue #-} is active.)
|    III. Ambiguous module imports do not cause an error if, among the
|         modules, there is one that is a superset of all others, i.e.
|         reexports all other modules.
|
| I personally find I. quite elegant and appealing, as it is clearly the
| behavior expected by library authors if they have their code build-
| depend on their selection of shim packages, and requires no extra
| prelude packages. One might see it as a disadvantages that now arbitrary
| packages can add to the “virtual prelude”, although I don’t think it
| would be abused without good reason, and who knows what clever things
| people will do with that feature.
|
| Greetings,
| Joachim
|
|
| --
| Joachim "nomeata" Breitner
| Debian Developer
|   [hidden email] | ICQ# 74513189 | GPG-Keyid: 4743206C
|   JID: [hidden email] | http://people.debian.org/~nomeata

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
1 ... 45678