On 9/28/07, Henning Thielemann
On Thu, 27 Sep 2007, Björn Buckwalter wrote:
Secondly, I feel that "Dimensional" is to vague and ambiguous, in particular it could just as well refer to dimensions in the linear algebra sense as physical dimensions. I'd like a more specific and perhaps less pretentious name for the library. This is where I would appreciate some feedback as to what would be appropriate. Some suggestions are:
- Numeric.Units - Numeric.PhysicalUnits - Numeric.PhysicalDimensions - Numeric.SI - Numeric.SIUnits - Numeric.Units.Static
It's certainly a good idea to distinguish between static and dynamic implementations. Incidentally, my implementation of numbers with units uses dynamic unit checking. It is also implemented in a generic way for any unit system, but has a specialisation for SI units. Currently it does not adhere to standard top-level module names (which are these and why?) but this could be changed.
From the wiki[1] it appears there is no standard, only three proposals (which all have 'Numeric' at the top-level).
[1] http://www.haskell.org/haskellwiki/Applications_and_libraries#Guidelines_for...
I use:
Number/Physical.hs Number/Physical/Read.hs Number/Physical/Show.hs Number/Physical/Unit.hs Number/Physical/UnitDatabase.hs Number/SI.hs Number/SI/Unit.hs
To be compatible with your library, the module names should contain some hint to their dynamic nature.
From their names it's not obvious what distinguishes them from other
And conversely by this argument my module names should contain some hint to their static nature, under the assumption that you (or somewhen else) will eventually move a "dynamic" unit library to the 'Numeric' namespace. A suitable namespace would be 'Numeric.Units.Static'. 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'. 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. As counterexamples I also notice there are cases where a library has a unique name but still a very generic namespace, e.g. Takusen which uses 'Database', Haifa with among other 'Text.XML.Serializer'. Then there is HAppS which at a cursory glance appears to use 'HAppS' as its top-level namespace, which has the obvious advantage of not having to worry about other libraries in the same namespace while also keeping the rather broad HAppS code collected in one place. Comments on what is appropriate (for my case, not necessarily for all cases)? I'm still leaning towards 'Numeric.Units' or something thereunder. Thanks, Bjorn
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.
From their names it's not obvious what distinguishes them from other
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'. 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'.
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
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.
From their names it's not obvious what distinguishes them from other
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'. 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'.
participants (2)
-
Björn Buckwalter -
Henning Thielemann