Re: HP 2012.4.0.0 -- Call for Proposals
Roman Leshchinskiy <rl <at> cse.unsw.edu.au>
2012-08-28 19:58:15 GMT
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.