Help with package/module naming

--===============8021433093420394259==
Content-Type: multipart/alternative; boundary="000000000000bbbb2d05fb3bfe4c"

--000000000000bbbb2d05fb3bfe4c
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I'm currently putting the finishing touches on the first version of a new
priority queue package. It implements amortized-optimal priority queues and
is intended to compete with the heaps package with a simpler, more compact,
and hopefully faster implementation=E2=80=A0. The main types are key-only a=
nd
key-value priority queues, which I'm naming based on the conventions of the
pqueue package:

data MinQueue k
data MinPQueue k a
data MaxQueue k
data MaxPQueue k a

Additionally, the implementation uses underlying types with constant time
insertion, logarithmic-time union, logarithmic time peekMin, and
logarithmic time deleteMin:

-- Key-value priority queues that are strict in both the key and the
-- value.
data MinPQueue k a

-- Similar to the above, but associating
-- two values with each key. The @a@
-- value is stored strictly and the @b@ value
-- is stored lazily.
data MinPQueue2 k a b

So I have a few questions:

1. What should I name this package?
2. What should I name the modules containing the bootstrapped queues?
3. What should I name the modules containing the underlying oddly-strict
queues? I don't know how many people will want to use them, but I figure
they're probably just what's needed from time to time and it's better to
let them loose than keep them under wraps.

Finally, there is the question of how to expose internals. In addition to
the queues above, with are all reasonable things for public consumption,
there are modules implementing those, as well as a couple modules
implementing helper types and such. I'm really no good at figuring out how
to "lay out" modules in a package, so any advice would be greatly
appreciated.

=E2=80=A0 The heaps package uses bootstrapped skew binomial heaps (Brodal a=
nd
Okasaki), achieving worst case constant-time union and peekMin and worst
case logarithmic time deleteMin. The package I'm working on uses the same
bootstrapping technique, but with a space-saving modification of Louis
Wasserman's realization of Okasaki lazy binomial heap as the base priority
queue. It achieves the same bounds, but union is only constant time in the
(persistently) amortized sense; it degrades to logarithmic time in the
worst case. In practice, this theoretical degradation likely doesn't
matter, both because it's small and because GHC's garbage collection
imposes occasional delays regardless.

--000000000000bbbb2d05fb3bfe4c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto">I&#39;m currently putting the finishing touches on the fi=
rst version of a new priority queue package. It implements amortized-optima=
l priority queues and is intended to compete with the heaps package with a =
simpler, more compact, and hopefully faster implementation=E2=80=A0. The ma=
in types are key-only and key-value priority queues, which I&#39;m naming b=
ased on the conventions of the pqueue package:<div dir=3D"auto"><br></div><=
div dir=3D"auto">data MinQueue k</div><div dir=3D"auto">data MinPQueue k a<=
br><div dir=3D"auto"><div dir=3D"auto">data MaxQueue k</div><div dir=3D"aut=
o">data MaxPQueue k a</div><div dir=3D"auto"><br></div><div dir=3D"auto">Ad=
ditionally, the implementation uses underlying types with constant time ins=
ertion, logarithmic-time union, logarithmic time peekMin, and logarithmic t=
ime deleteMin:</div><div dir=3D"auto"><br></div><div dir=3D"auto">-- Key-va=
lue priority queues that are strict in both the key and the</div><div dir=
=3D"auto">-- value.</div><div dir=3D"auto">data MinPQueue k a</div><div dir=
=3D"auto"><br></div><div dir=3D"auto">-- Similar to the above, but associat=
ing</div><div dir=3D"auto">-- two values with each key. The @a@</div><div d=
ir=3D"auto">-- value is stored strictly and the @b@ value</div><div dir=3D"=
auto">-- is stored lazily.</div><div dir=3D"auto">data MinPQueue2 k a b</di=
v><div dir=3D"auto"><br></div><div dir=3D"auto">So I have a few questions:<=
/div><div dir=3D"auto"><br></div><div dir=3D"auto">1. What should I name th=
is package?</div><div dir=3D"auto">2. What should I name the modules contai=
ning the bootstrapped queues?</div><div dir=3D"auto">3. What should I name =
the modules containing the underlying oddly-strict queues? I don&#39;t know=
 how many people will want to use them, but I figure they&#39;re probably j=
ust what&#39;s needed from time to time and it&#39;s better to let them loo=
se than keep them under wraps.</div><div dir=3D"auto"><br></div><div dir=3D=
"auto">Finally, there is the question of how to expose internals. In additi=
on to the queues above, with are all reasonable things for public consumpti=
on, there are modules implementing those, as well as a couple modules imple=
menting helper types and such. I&#39;m really no good at figuring out how t=
o &quot;lay out&quot; modules in a package, so any advice would be greatly =
appreciated.</div></div><div dir=3D"auto"><br></div><div dir=3D"auto">=E2=
=80=A0 The heaps package uses bootstrapped skew binomial heaps (Brodal and =
Okasaki), achieving worst case constant-time union and peekMin and worst ca=
se logarithmic time deleteMin. The package I&#39;m working on uses the same=
 bootstrapping technique, but with a space-saving modification of Louis Was=
serman&#39;s realization of Okasaki lazy binomial heap as the base priority=
 queue. It achieves the same bounds, but union is only constant time in the=
 (persistently) amortized sense; it degrades to logarithmic time in the wor=
st case. In practice, this theoretical degradation likely doesn&#39;t matte=
r, both because it&#39;s small and because GHC&#39;s garbage collection imp=
oses occasional delays regardless.</div></div></div>

--000000000000bbbb2d05fb3bfe4c--

--===============8021433093420394259==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Disposition: inline

X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KSGFza2VsbC1D
YWZlIG1haWxpbmcgbGlzdApUbyAodW4pc3Vic2NyaWJlLCBtb2RpZnkgb3B0aW9ucyBvciB2aWV3
IGFyY2hpdmVzIGdvIHRvOgpodHRwOi8vbWFpbC5oYXNrZWxsLm9yZy9jZ2ktYmluL21haWxtYW4v
bGlzdGluZm8vaGFza2VsbC1jYWZlCk9ubHkgbWVtYmVycyBzdWJzY3JpYmVkIHZpYSB0aGUgbWFp
bG1hbiBsaXN0IGFyZSBhbGxvd2VkIHRvIHBvc3Qu

--===============8021433093420394259==--