HP 2012.4.0.0 -- Call for Proposals

[Simon Peyton-Jones]

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 at projects.haskell.org [mailto:haskell-platform-bounces at projects.haskell.org] On Behalf Of Mark Lentczner
Sent: 22 August 2012 15:33
To: haskell-platform at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20120828/f8b443c9/attachment-0001.htm>