Fwd: Suitable new name for Dimensional library

Björn Buckwalter bjorn.buckwalter at gmail.com
Tue Oct 9 13:46:14 EDT 2007


Henning, all,

I decided to go with 'Numeric.Units.Dimensional'. I feel that
'Dimensional' provides sufficient differentiation as unit libraries go
and the preceding 'Numeric.Units' takes care of my concern of
'Dimensional' being too vague.

Thanks all for your inputs!

I've released dimensional-0.7 with the new module name space and a few
small additions w.r.t. version 0.6. It can be downloaded from the
project homepage[1] or hackage.

Regards,
Bjorn Buckwalter

[1] http://dimensional.googlecode.com/


On 10/1/07, Henning Thielemann <lemming at henning-thielemann.de> wrote:
>
> On Fri, 28 Sep 2007, Björn Buckwalter wrote:
>
> > Taken further though, if someone develops another "static" unit
> > library where should they put it? An arbitrarily complex tree of
> > namespaces could be built trying to distinguish libraries to
> > anticipate future clashes.
> >
> > This leads me to wonder -- is it better for a library to have a more
> > or less arbitrary differentiating name rather than a descriptive name?
> > Examples are 'Text.ParserCombinators.Parsec', 'Text.Parsers.Frisby'.
> >> From their names it's not obvious what distinguishes them from other
> > parsers in the same namespace but at least the tree is fairly flat and
> > hopefully narrowed down enough to permit investigating each
> > alternative. In the units case I imagine
> > 'Numeric.Units.SomethingArbitrary' would be appropriate.
>
> Indeed, someone might implement static unit checking by a different
> approach. We cannot predict this. So actually it seems to be better to use
> an arbitrary differentiating name, say
>
> Numeric.Units.Bucky
> Numeric.Units.Lemming
>
> Using module names which describe only the module function might work if
> there is consensus on its relevance and its API. That is, only for very
> basic modules of a 'standard library'.


More information about the Libraries mailing list