Mark Lentczner | 21 Aug 15:43 2012
Picon

HP 2012.4.0.0 -- Call for Proposals

While proposals for changes to Haskell Platform can be made at any time, this call is for proposals that would like to land in the 2012.4.0.0 release.


The 2012.4.0.0 is scheduled for November 12th, 2012. In order for a proposal to made it in that release, it needs to meet the following timeline:
  • August 20th, 2012 - Call for proposals for additions and changes
  • September 17th, 2012 - Call for proposals ends (no more proposals considered)
  • October 1st, 2012 - Proposals decided, Initial version list
If you are a maintainer of a library that you'd like to be in the platform: Now is the time to get a clean version on Hackage, and then put together a proposal for the haskell-platform list. Please see the process for Adding Packages.

Outstanding work:
  • There is a proposal to include vector-0.9.1 in the platform
  • There is a ticket to consider including OpenGLRaw — Ticket #167
  • There are tickets to consider removing OpenGL and GLUT — Ticket #57, Ticket #58
  • There is a ticket about binary being in the platform without being part of it — Ticket #191
  • There is a ticket about needing hscolour to build the platform, but it isn't part of it — Ticket #160
Please not that none of the tickets is a proposal before the list yet. If the maintainer of those libraries, or someone else, want to propose a change based on those tickets, now is the time to do so. In any event, I will close those tickets on September 17th.

If you are part of the reviewing process: Traditionally, proposals have been accompanied by lengthly discussions, often resulting in deep API design confabs. As we are approaching a release, I'd like to ask all to consider making this round more succinct if at all possible. In particular, it would be great if proposals were keyed to specific revisions of a library to be considered. If consensus is that something needs to be changed before inclusion - it would be best if maintainers took that input into account, turned another library version and placed that up for consideration. Please note the schedule: I'm going to hold October 1st firm.

— Mark "proposed in a restaurant in front of friends" Lentczner
_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries
Simon Marlow | 21 Aug 17:32 2012
Picon

Re: HP 2012.4.0.0 -- Call for Proposals

There's also a proposal (by me) to include the async package:

http://trac.haskell.org/haskell-platform/wiki/Proposals/async

The deadlines have now expired.  During the discussion several people 
were positive about the package, however I don't think anyone expressed 
an opinion specifically on whether the package should be in the 
platform.  I'm not sure how to interpret that result - at the least, it 
suggests a certain lack of enthusiasm.

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 
some way to return results from threads, and then you need error 
handling.  Then you start to need a way to wait for results from 
multiple threads with error handling... people build these things 
themselves, but in fact it's quite tricky with the basic 
Control.Concurrent API to do it right.  The async package provides a 
well though-out API for that essential functionality, in a way that 
composes nicely.  It's a very small package, but it should be a part of 
our standard vocabulary in my opinion.

We should have it if only for the cool one-liners you can write with

mapConcurrently :: Traversable t => (a -> IO b) -> t a -> IO (t b)

:-)

On the other hand, given that nobody else argued for it to be in the 
platform, a reasonable decision would be "wait and see"; I'd be fine 
with that too.

Cheers,
	Simon

On 21/08/2012 14:43, Mark Lentczner wrote:
> While proposals for changes to Haskell Platform can be made at any time,
> this call is for proposals that would like to land in the 2012.4.0.0
> release.
>
> The 2012.4.0.0 is scheduled for November 12th, 2012. In order for a
> proposal to made it in that release, it needs to meet the following
> timeline:
>
>   * *August 20th, 2012* - Call for proposals for additions and changes
>   * *September 17th, 2012* - Call for proposals ends (no more proposals
>     considered)
>   * *October 1st, 2012* - Proposals decided, Initial version list
>
> *If you are a maintainer of a library that you'd like to be in the
> platform:* Now is the time to get a clean version on Hackage, and then
> put together a proposal for the haskell-platform list. Please see the
> process for Adding Packages
> <http://trac.haskell.org/haskell-platform/wiki/AddingPackages>.
>
> *Outstanding work:*
>
>   * There is a proposal to include vector-0.9.1 in the platform
>   * There is a ticket to consider including OpenGLRaw — Ticket #167
>     <http://trac.haskell.org/haskell-platform/ticket/167>
>   * There are tickets to consider removing OpenGL and GLUT — Ticket #57
>     <http://trac.haskell.org/haskell-platform/ticket/57>, Ticket #58
>     <http://trac.haskell.org/haskell-platform/ticket/58>
>   * There is a ticket about binary being in the platform without being
>     part of it — Ticket #191
>     <http://trac.haskell.org/haskell-platform/ticket/191>
>   * There is a ticket about needing hscolour to build the platform, but
>     it isn't part of it — Ticket #160
>     <http://trac.haskell.org/haskell-platform/ticket/160>
>
> Please not that none of the tickets is a proposal before the list yet.
> If the maintainer of those libraries, or someone else, want to propose a
> change based on those tickets, now is the time to do so. In any event, I
> will close those tickets on September 17th.
>
> *If you are part of the reviewing process:* Traditionally, proposals
> have been accompanied by lengthly discussions, often resulting in deep
> API design confabs. As we are approaching a release, I'd like to ask all
> to consider making this round more succinct if at all possible. In
> particular, it would be great if proposals were keyed to specific
> revisions of a library to be considered. If consensus is that something
> needs to be changed before inclusion - it would be best if maintainers
> took that input into account, turned another library version and placed
> that up for consideration. Please note the schedule: I'm going to hold
> October 1st firm.
>
> — Mark "proposed in a restaurant in front of friends" Lentczner
>
>
> _______________________________________________
> Haskell-platform mailing list
> Haskell-platform@...
> http://projects.haskell.org/cgi-bin/mailman/listinfo/haskell-platform
>
Bryan O'Sullivan | 21 Aug 17:54 2012

Re: HP 2012.4.0.0 -- Call for Proposals

On Tue, Aug 21, 2012 at 8:32 AM, Simon Marlow <marlowsd-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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.
_______________________________________________
Haskell-platform mailing list
Haskell-platform@...
http://projects.haskell.org/cgi-bin/mailman/listinfo/haskell-platform
Felipe Almeida Lessa | 21 Aug 17:56 2012
Picon

Re: HP 2012.4.0.0 -- Call for Proposals

Is it time for votes yet?  +1 for async =).

--

-- 
Felipe.
Johan Tibell | 21 Aug 18:26 2012
Picon

Re: HP 2012.4.0.0 -- Call for Proposals

On Tue, Aug 21, 2012 at 8:54 AM, Bryan O'Sullivan <bos@...> wrote:
> On Tue, Aug 21, 2012 at 8:32 AM, Simon Marlow <marlowsd@...> 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
Brandon Allbery | 21 Aug 19:24 2012
Picon

Re: HP 2012.4.0.0 -- Call for Proposals

On Tue, Aug 21, 2012 at 11:32 AM, Simon Marlow <marlowsd <at> gmail.com> 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.

--
brandon s allbery                                      allbery.b <at> gmail.com
wandering unix systems administrator (available)     (412) 475-9364 vm/sms

_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries
Johan Tibell | 21 Aug 20:05 2012
Picon

Re: HP 2012.4.0.0 -- Call for Proposals

On Tue, Aug 21, 2012 at 10:24 AM, Brandon Allbery
<allbery.b@...> wrote:
> On Tue, Aug 21, 2012 at 11:32 AM, Simon Marlow <marlowsd@...> 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?
Dan Burton | 21 Aug 20:34 2012
Picon

Re: HP 2012.4.0.0 -- Call for Proposals

Both split and async fit well with the "batteries included" nature of the platform. Regardless of how much use it has seen, async is definitely an API that should be bundled with the "standard" libraries. Compare with, say, Java or Python standard libs; programmers expect modern languages to expose easy-to-use concurrency operations. Most of the async definitions are thin convenience wrappers around Control.Concurrent, so as long as we are comfortable with Control.Concurrent, I see no reason to worry about async.

In my unprofessional opinion, it's high time we add async to the platform.

-- Dan Burton
_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries
Simon Marlow | 22 Aug 13:09 2012
Picon

Re: HP 2012.4.0.0 -- Call for Proposals

On 21/08/2012 19:05, Johan Tibell wrote:
> On Tue, Aug 21, 2012 at 10:24 AM, Brandon Allbery
<allbery.b@...> wrote:
>> On Tue, Aug 21, 2012 at 11:32 AM, Simon Marlow <marlowsd@...> 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 Lentczner | 22 Aug 16:32 2012
Picon

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
_______________________________________________
Haskell-platform mailing list
Haskell-platform@...
http://projects.haskell.org/cgi-bin/mailman/listinfo/haskell-platform
Simon Peyton-Jones | 28 Aug 11:26 2012
Picon

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

_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries
Henning Thielemann | 28 Aug 11:31 2012
Picon

RE: HP 2012.4.0.0 -- Call for Proposals


On Tue, 28 Aug 2012, Simon Peyton-Jones wrote:

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

+1

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

-1 because I think it could be useful for alternative packages (like 
storablevector, but it does not use 'primitive' currently)

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

-1

_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries
Ivan Lazar Miljenovic | 28 Aug 12:07 2012
Picon

Re: HP 2012.4.0.0 -- Call for Proposals

On 28 August 2012 19:26, Simon Peyton-Jones <simonpj <at> microsoft.com> 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 <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
>
>
> _______________________________________________
> Libraries mailing list
> Libraries <at> haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>

--

-- 
Ivan Lazar Miljenovic
Ivan.Miljenovic <at> gmail.com
http://IvanMiljenovic.wordpress.com

_______________________________________________
Haskell-platform mailing list
Haskell-platform <at> projects.haskell.org
http://projects.haskell.org/cgi-bin/mailman/listinfo/haskell-platform
Gregory Collins | 28 Aug 14:06 2012
Picon

Re: HP 2012.4.0.0 -- Call for Proposals

On Tue, Aug 28, 2012 at 12:07 PM, Ivan Lazar Miljenovic <ivan.miljenovic <at> gmail.com> wrote:

On 28 August 2012 19:26, Simon Peyton-Jones <simonpj <at> microsoft.com> wrote: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).

I use primitive for its MutableArray directly inside the hashtables package if the bounds checking is turned off (the default): https://github.com/gregorycollins/hashtables/blob/master/src/Data/HashTable/Internal/Array.hs, and also for MutableByteArray: https://github.com/gregorycollins/hashtables/blob/master/src/Data/HashTable/Internal/IntArray.hs

The types from primitive have less overhead than vector, which is important for some of my use cases.

G
--
Gregory Collins <greg <at> gregorycollins.net>
_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries
Simon Peyton-Jones | 28 Aug 12:41 2012
Picon

RE: HP 2012.4.0.0 -- Call for Proposals

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 <at> projects.haskell.org [mailto:haskell-platform-bounces <at> projects.haskell.org] On Behalf Of Simon Peyton-Jones
Sent: 28 August 2012 10:26
To: Mark Lentczner; haskell-platform <at> projects.haskell.org; Haskell Libraries
Cc: Geoffrey Mainland; Manuel Chakravarty; Roman Leshchinskiy; Ben Lippmeier (benl <at> 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 <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

_______________________________________________
Haskell-platform mailing list
Haskell-platform@...
http://projects.haskell.org/cgi-bin/mailman/listinfo/haskell-platform
Roman Leshchinskiy | 28 Aug 21:58 2012
Picon
Picon

Re: HP 2012.4.0.0 -- Call for Proposals

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? It provides wrappers around (mostly) GHC primitives which
aren't exposed elsewhere in an easily usable manner. I find it quite useful and really, primitive seemed
like the most logical name for this, especially since it started out as a wrapper around ghc-prim (which, I
assume, is an abbreviation for "GHC's primitive package"). I'm not really sure why it is worse than, say,
binary. Or vector, for that matter.

> 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

No, because Data.Array is much more heavy weight among other things.

> ·         There’s an Addr type, which is like the Foreign.Ptr type, but un-parameterised.
> ·         There’s a ByteArray type, wrapping Array#

Nitpick: ByteArray#, not Array#.

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

Actually, the main operations on Prim are readByteArray, writeByteArray, indexByteArray and similar
operations on Addr. The methods typically won't be called directly and are only exported so that new
instances can be defined. The reason for having sizeOf# rather than sizeOf as a method is to avoid boxing in
generic code but sizeOf is what end-user code should use typically.

There are also wrappers for MutVar#, a generic interface to ST and IO, the MachDeps module and a few other
things. It will grow in the future.

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

Yes, of course.

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

As an aside, there has been no real discussion of vector, either, which makes me rather sad. I don't use the
platform but I thought that if vector is proposed/included, I would get a review of the API and, hopefully,
suggestions how to improve it which would be more than worth the additional work. 

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

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.

> ·         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. Also, vector is not the only client AFAIK.

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

Nor this, really.

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

Roman
Ian Lynagh | 28 Aug 23:08 2012
Picon

Re: HP 2012.4.0.0 -- Call for Proposals

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
Roman Leshchinskiy | 29 Aug 09:56 2012
Picon
Picon

Re: HP 2012.4.0.0 -- Call for Proposals

Ian Lynagh wrote:
> 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."

Yes, this description is quite outdated. Thanks for bringing it to my
attention!

> and that it was (AIUI)
> created as a base upon which to build 'vector',

I'm really not sure where this impression comes from. Vector isn't even
mentioned in either the docs or the name :-)

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

None of these describe what the package does since it contains a lot more
than just array primitives.

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

Well, binary's name is quite general and only vaguely related to its task.
Don't get me wrong, I think it's a perfectly fine name, I just don't see
how primitive is any worse.

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

To me, this reads as "packages should not use descriptive names" since
there is almost always another package that does roughly the same thing.
In the specific case of primitive, though, I'm actually having trouble
finding another package on Hackage which would want to use the name.

Roman
Simon Peyton-Jones | 29 Aug 09:59 2012
Picon

RE: HP 2012.4.0.0 -- Call for Proposals

| > *         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 | 28 Aug 22:43 2012
Picon

Re: HP 2012.4.0.0 -- Call for Proposals

On Tue, Aug 28, 2012 at 2:26 AM, Simon Peyton-Jones
<simonpj <at> microsoft.com> wrote:
> ·         Absorb it into the vector package, which is currently its only
> client (we think).

We definitely need a library like primitive to share code among other
libraries. I think that package might as well be primitive. To my
knowledge there are at least three, nearly-identical wrappers of the
GHC array primops: one primitive (used by vector), one in text, and
one in unordered-containers.

The reason that these libraries cannot use the array or bytestring
libraries as wrappers over Array# and ByteArray# is that design
trade-offs made in these two libraries are not always what you want:

 * Arrays are too big and use a (relatively) inefficient indexing scheme.
 * ByteStrings are too big and also have a somewhat inefficient
indexing schemes. They're also pinned.

-- Johan
Bryan O'Sullivan | 21 Aug 17:55 2012

Re: HP 2012.4.0.0 -- Call for Proposals

On Tue, Aug 21, 2012 at 6:43 AM, Mark Lentczner <mark.lentczner <at> gmail.com> wrote:

Outstanding work:

I believe there was also a proposal to include the split package: http://trac.haskell.org/haskell-platform/wiki/Proposals/split 
_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries
Brent Yorgey | 21 Aug 19:12 2012

Re: HP 2012.4.0.0 -- Call for Proposals

On Tue, Aug 21, 2012 at 08:55:40AM -0700, Bryan O'Sullivan wrote:
> On Tue, Aug 21, 2012 at 6:43 AM, Mark Lentczner <mark.lentczner <at> gmail.com>wrote:
> 
> > *Outstanding work:*
> >
> 
> I believe there was also a proposal to include the split package:
> http://trac.haskell.org/haskell-platform/wiki/Proposals/split

Indeed.  I plan to release a new version (incorporating feedback) and
bump the process soon.

-Brent
Yitzchak Gale | 22 Aug 07:29 2012

Re: HP 2012.4.0.0 -- Call for Proposals

On Tue, Aug 21, 2012, Mark Lentczner wrote:
> Please see the process for
> [Adding Packages](http://trac.haskell.org/haskell-platform/wiki/AddingPackages).
>
> Outstanding work...

Just to clarify:

Since Mark referenced the policy page, I assume that
means we need to adhere to it at least to some degree
before a package can be added to the platform.

If so, there must be a proposal page on the Trac Wiki
before we can consider a package. Therefore, there
is only ONE package so far that is a candidate: async.

A proposal page can be created by anyone,
not just the package maintainer. So if you are in favor
of a package other than async, you might better
spend your time working on a wiki page instead of
"voting" for a non-proposal.

All that said, it seems to me that we might not need
quite so much formal process for each package
addition. If there is serious discussion on these lists,
I personally would be willing to entrust the final
decision to a benevolent dictator. We could save
the formal process for periodic selection of the
dictator. A number of open source projects work
in this way.

Thanks,
Yitz
Johan Tibell | 22 Aug 07:50 2012
Picon

Re: HP 2012.4.0.0 -- Call for Proposals

On Tuesday, August 21, 2012, Yitzchak Gale wrote:

On Tue, Aug 21, 2012, Mark Lentczner wrote:
> Please see the process for
> [Adding Packages](http://trac.haskell.org/haskell-platform/wiki/AddingPackages).
>
> Outstanding work...

Just to clarify:

Since Mark referenced the policy page, I assume that
means we need to adhere to it at least to some degree
before a package can be added to the platform.

If so, there must be a proposal page on the Trac Wiki
before we can consider a package. Therefore, there
is only ONE package so far that is a candidate: async.

 
_______________________________________________
Haskell-platform mailing list
Haskell-platform@...
http://projects.haskell.org/cgi-bin/mailman/listinfo/haskell-platform
Yitzchak Gale | 22 Aug 10:27 2012

Re: HP 2012.4.0.0 -- Call for Proposals

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
Ashley Yakeley | 22 Aug 10:48 2012

Re: HP 2012.4.0.0 -- Call for Proposals

On 22/08/12 01:27, Yitzchak Gale wrote:

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

The time-extras package provided Data instance for various time 
structures. This functionality is now provided by the time package. So 
time-extras no longer has any purpose and there is no package-version 
that matches the latest time package. I recommend rejecting it.

-- Ashley Yakeley

Gmane