On Tue, Aug 21, 2012 at 8:32 AM, Simon Marlow wrote:

I'm not sure how to interpret that result - at the least, it suggests a certain lack of enthusiasm.

I would like to see the async package go in. I have hand-rolled something like it a couple of times.

On Tue, Aug 21, 2012 at 8:54 AM, Bryan O'Sullivan wrote:

On Tue, Aug 21, 2012 at 8:32 AM, Simon Marlow wrote:

...

I'm not sure how to interpret that result - at the least, it suggests a certain lack of enthusiasm.

I would like to see the async package go in. I have hand-rolled something like it a couple of times.

Having just read through the API, which is very well-written, I'd like to see this go in as well. -- Johan

On Tue, Aug 21, 2012 at 10:24 AM, Brandon Allbery wrote:

On Tue, Aug 21, 2012 at 11:32 AM, Simon Marlow wrote:

...

I'm still keen to see the package go in, mainly because when you start doing concurrent programming you quite quickly run into the need for

I think most of us are of the opinion that it would be nice to see it get some independent use and shake the bugs and infelicities out of it first; being in the platform implies (correctly or not) a certain level of interface stability and trust in functionality.

Is the time until the actual release enough? If not we can accept the package now but not include it until the next release, at which point any obvious bugs should be gone. Simon, has the package seen any use (e.g. in one of your classes) yet?

On 21/08/2012 19:05, Johan Tibell wrote:

On Tue, Aug 21, 2012 at 10:24 AM, Brandon Allbery wrote:

...

On Tue, Aug 21, 2012 at 11:32 AM, Simon Marlow wrote:

...

I'm still keen to see the package go in, mainly because when you start doing concurrent programming you quite quickly run into the need for

I think most of us are of the opinion that it would be nice to see it get some independent use and shake the bugs and infelicities out of it first; being in the platform implies (correctly or not) a certain level of interface stability and trust in functionality.

Is the time until the actual release enough? If not we can accept the package now but not include it until the next release, at which point any obvious bugs should be gone.

Simon, has the package seen any use (e.g. in one of your classes) yet?

The API is actually developed in my tutorial (which will become the book) from first principles, starting from MVars and then moving to STM, as a way to motivate and explain the underlying primitives. Basic versions of the API are used in several of the examples, although I'm not using the async package itself yet - the examples came first. I don't see any reverse deps on async in Hackage yet. Perhaps I need to write a blog post about it... Cheers, Simon

Mark, and HP folk, Geoff, Simon M, and I have just realised that · vector (which we would like to be included in HP) depends on primitive · And primitive is a Terrible Name for a package. Really unacceptably bad. If you look at what’s in primitive it has a bunch of fairly simple wrappers round basic types: · Data.Primitive.Array defined (another) Array type, wrapping Array#. But it’s not the same as the Array type in Data.Array · There’s an Addr type, which is like the Foreign.Ptr type, but un-parameterised. · There’s a ByteArray type, wrapping Array# · There’s a Prim class, with operations like sizeOf#, alignment#, and so on. Roman is the maintainer. Roman, are you happy to be in that position? What should we do about this? There has been NO discussion of this API. Possibilities · Adopt the package with a new name, like vector-prim or vector-internal, implying that it’s for people doing vector-stuff, rather than for end users. (And say that in the docs.) · Absorb it into the vector package, which is currently its only client (we think). · Absorb it into the base package. But we are generally trying to reduce base not increase it. We don’t have a strong opinion, except that baking a package into HP called simply ‘primitive’ seems Wrong. Very sorry for not bringing this up before... only just realised Simon From: haskell-platform-bounces@projects.haskell.org [mailto:haskell-platform-bounces@projects.haskell.org] On Behalf Of Mark Lentczner Sent: 22 August 2012 15:33 To: haskell-platform@projects.haskell.org; Haskell Libraries Subject: Re: HP 2012.4.0.0 -- Call for Proposals Thank you, Yitz, for the wiki maintenance! vector and time-extras - these should be updated by the proposers as they have been "reproposed" async, vector, and time-extras - I think these all need to be updated to reflect the current discussion period. While required by the process, I'd urge proposers to link to the specific version of the package under consideration. While the proposal is for inclusion of the package going forward (hence evolving versions over time), it really helps API discussions to pin them to a particular version. If discussion causes you to update a package, then the proposal discussion can "re-vector" to the new version. Please split discussion of particular proposals off from this thread. Lastly, just to be clear, the dates I set out are the dates by which I need proposals handled and decided in order to get the release out on schedule. The proposal process is not tied to releases, and can continue aysnc from release if any proposal needs time-extra. - Mark

On 28 August 2012 19:26, Simon Peyton-Jones wrote:

Mark, and HP folk,

Geoff, Simon M, and I have just realised that

· vector (which we would like to be included in HP) depends on primitive

· And primitive is a Terrible Name for a package. Really unacceptably bad.

If you look at what’s in primitive it has a bunch of fairly simple wrappers round basic types:

· Data.Primitive.Array defined (another) Array type, wrapping Array#. But it’s not the same as the Array type in Data.Array

· There’s an Addr type, which is like the Foreign.Ptr type, but un-parameterised.

· There’s a ByteArray type, wrapping Array#

· There’s a Prim class, with operations like sizeOf#, alignment#, and so on.

Roman is the maintainer. Roman, are you happy to be in that position?

What should we do about this? There has been NO discussion of this API. Possibilities

· Adopt the package with a new name, like vector-prim or vector-internal, implying that it’s for people doing vector-stuff, rather than for end users. (And say that in the docs.)

There are quite a few packages that seem to use primitive: http://packdeps.haskellers.com/reverse/primitive Admittedly, my quick sample of those packages makes it seem like they only use primitive _for_ dealing with vector (as in all the packages I looked at also had vector as a dep).

· Absorb it into the vector package, which is currently its only client (we think).

· Absorb it into the base package. But we are generally trying to reduce base not increase it.

We don’t have a strong opinion, except that baking a package into HP called simply ‘primitive’ seems Wrong.

Very sorry for not bringing this up before... only just realised

Simon

From: haskell-platform-bounces@projects.haskell.org [mailto:haskell-platform-bounces@projects.haskell.org] On Behalf Of Mark Lentczner Sent: 22 August 2012 15:33 To: haskell-platform@projects.haskell.org; Haskell Libraries Subject: Re: HP 2012.4.0.0 -- Call for Proposals

Thank you, Yitz, for the wiki maintenance!

vector and time-extras - these should be updated by the proposers as they have been "reproposed"

async, vector, and time-extras - I think these all need to be updated to reflect the current discussion period.

While required by the process, I'd urge proposers to link to the specific version of the package under consideration. While the proposal is for inclusion of the package going forward (hence evolving versions over time), it really helps API discussions to pin them to a particular version. If discussion causes you to update a package, then the proposal discussion can "re-vector" to the new version.

Please split discussion of particular proposals off from this thread.

Lastly, just to be clear, the dates I set out are the dates by which I need proposals handled and decided in order to get the release out on schedule. The proposal process is not tied to releases, and can continue aysnc from release if any proposal needs time-extra.

- Mark

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

-- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com http://IvanMiljenovic.wordpress.com

PS: One other point · If we adopt primitive (perhaps with a new name), can we get rid of any stuff in base? From: haskell-platform-bounces@projects.haskell.org [mailto:haskell-platform-bounces@projects.haskell.org] On Behalf Of Simon Peyton-Jones Sent: 28 August 2012 10:26 To: Mark Lentczner; haskell-platform@projects.haskell.org; Haskell Libraries Cc: Geoffrey Mainland; Manuel Chakravarty; Roman Leshchinskiy; Ben Lippmeier (benl@ouroborus.net) Subject: RE: HP 2012.4.0.0 -- Call for Proposals Mark, and HP folk, Geoff, Simon M, and I have just realised that · vector (which we would like to be included in HP) depends on primitive · And primitive is a Terrible Name for a package. Really unacceptably bad. If you look at what’s in primitive it has a bunch of fairly simple wrappers round basic types: · Data.Primitive.Array defined (another) Array type, wrapping Array#. But it’s not the same as the Array type in Data.Array · There’s an Addr type, which is like the Foreign.Ptr type, but un-parameterised. · There’s a ByteArray type, wrapping Array# · There’s a Prim class, with operations like sizeOf#, alignment#, and so on. Roman is the maintainer. Roman, are you happy to be in that position? What should we do about this? There has been NO discussion of this API. Possibilities · Adopt the package with a new name, like vector-prim or vector-internal, implying that it’s for people doing vector-stuff, rather than for end users. (And say that in the docs.) · Absorb it into the vector package, which is currently its only client (we think). · Absorb it into the base package. But we are generally trying to reduce base not increase it. We don’t have a strong opinion, except that baking a package into HP called simply ‘primitive’ seems Wrong. Very sorry for not bringing this up before... only just realised Simon From: haskell-platform-bounces@projects.haskell.orgmailto:haskell-platform-bounces@projects.haskell.org [mailto:haskell-platform-bounces@projects.haskell.org]mailto:[mailto:haskell-platform-bounces@projects.haskell.org] On Behalf Of Mark Lentczner Sent: 22 August 2012 15:33 To: haskell-platform@projects.haskell.orgmailto:haskell-platform@projects.haskell.org; Haskell Libraries Subject: Re: HP 2012.4.0.0 -- Call for Proposals Thank you, Yitz, for the wiki maintenance! vector and time-extras - these should be updated by the proposers as they have been "reproposed" async, vector, and time-extras - I think these all need to be updated to reflect the current discussion period. While required by the process, I'd urge proposers to link to the specific version of the package under consideration. While the proposal is for inclusion of the package going forward (hence evolving versions over time), it really helps API discussions to pin them to a particular version. If discussion causes you to update a package, then the proposal discussion can "re-vector" to the new version. Please split discussion of particular proposals off from this thread. Lastly, just to be clear, the dates I set out are the dates by which I need proposals handled and decided in order to get the release out on schedule. The proposal process is not tied to releases, and can continue aysnc from release if any proposal needs time-extra. - Mark

On Tue, Aug 28, 2012 at 08:58:15PM +0100, Roman Leshchinskiy wrote:

On 28/08/2012, at 10:26, Simon Peyton-Jones wrote:

...

Geoff, Simon M, and I have just realised that · vector (which we would like to be included in HP) depends on primitive · And primitive is a Terrible Name for a package. Really unacceptably bad.

Hmm, I'm not sure I agree :-)

Could you please explain why it's so terrible?

I can't speak for Simon, but I've always thought it overly-generic. Given the description starts "This package provides wrappers for primitive array operations from GHC.Prim." and that it was (AIUI) created as a base upon which to build 'vector', I would suggest that one of array-primitive primitive-array vector-primitive primitive-vector would be a better name. I don't know enough about it to know whether 'array' or 'primitive' would be better, and I don't know if there is precedent for whether 'primitive' should come first or last.

I'm not really sure why it is worse than, say, binary. Or vector, for that matter.

Hopefully, binary and vector are the obvious, natural APIs for their tasks. If vector only supported vectors or Ints, for example, then I think that it ought to be renamed int-vector. But seeing as it has a "Vector a" type, and offers the expected functions such as map :: (a -> b) -> Vector a -> Vector b the name appears appropriate to me (at least, based on a very cursory look).

In any case, if a lot of people really want to rename it I'd be ok with that provided I like the new name but frankly, I don't really see the point. The package is 3 years old and this is the first time anybody has complained about the name.

No-one asked me before :-) Actually, I did suggest having admins approve new package names when Hackage was first created, but the people doing the work didn't think it would be a problem. And to be fair, the handful of times I know of a naming issue being raised, I think the maintainer has been happy (or at least willing) to rename.

If it is to be renamed, though, then I would really find it useful to have agreed upon guidelines on what constitutes a Terrible Name so that I can try to avoid picking one in the future.

It would very much have to be a guideline as opposed to a rule, but I'd suggest something like: A package should not use a descriptive name that another package might be equally- or more-deserving-of. Thanks Ian

| > * And primitive is a Terrible Name for a package. Really | unacceptably bad. | | Hmm, I'm not sure I agree :-) | | Could you please explain why it's so terrible? | I would really find it useful to have agreed upon guidelines on what | constitutes a Terrible Name so that I can try to avoid picking one in | the future. Firstly, this is a matter for the libraries list and the Haskell Platform team. Just because I think it's a bad name doesn't mean that it *is*. GHC is happy to go with whatever the HP team decide; we'd just like it to be a conscious decision. Making it conscious was the point of our message. Why do I think it's a poor name? Because "primitive" conveys no information to me about its actual content except that it's, well, somehow primitive. "ghc-prim" isn't much better, but at least it declares that it's a GHC internal thing and no one else need bother with it. Likewise we have "integer-simple" and "integer-gmp", which say something about their content. So the guideline is: convey as much information as possible in the package name. Names like "basic-array" or "basic-vector" would convey a lot more information. Still, if HP team are happy with "primitive" (and changing it does have costs), then so be it. | It is actually for end users rather than for people doing vector stuff | which is why it's a separate package. So I wouldn't want to do this. Aha! Clearly I had misunderstood -- the name didn't sound end-user like to me! | > * Absorb it into the vector package, which is currently its | only client (we think). | | Definitely not this. I had what I consider good reasons for making it a | separate package when I implemented it. Great. Perhaps it would help to articulate those reasons? Even in the cabal file? Being explicitly told the cohesive unity in the mind of the package author, is really really useful. I'm not disputing that it's a useful package, or a well designed one. I just want the HP team to explicitly consider, bless it, and suggest changes if they think they are necessary. Simon

Johan Tibell wrote:

There is also one for vector: http://trac.haskell.org/haskell-platform/wiki/Proposals/vector

Ah, sorry. I didn't notice it at first because it wasn't on the list of active proposals: http://trac.haskell.org/haskell-platform/wiki/Proposals I added it. Now I see that Brent has created a proposal page for the split package; I added that as well. There is one more active proposal that Mark did not mention: the time-extras package, proposed by its author, Ashley Yakeley. I added a link to that, too. Thanks, Yitz