HP 2012.4.0.0 -- Call for Proposals

Roman Leshchinskiy rl at cse.unsw.edu.au
Tue Aug 28 21:58:15 CEST 2012


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





More information about the Libraries mailing list