Re: Suitable new name for Dimensional library

Björn Buckwalter wrote:
On 9/28/07, Isaac Dupree
wrote: Björn Buckwalter wrote:
There are two primary reasons I have been wanting to change the name.
Firstly I wanted to move the library from the arbitrary 'Buckwalter.Dimensional' namespace into the standard hierarchy. At Don's suggestion (patch) the library has been moved to the 'Numeric.Dimensional' namespace and if no-one objects it will remain under 'Numeric'. seems fine to me
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. They are somewhat related. But indeed your library only deals with specific named 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
(While the library isn't limited to SI units or even the SI dimensions they are the main focus and default export.)
Personally I like 'Numeric.Units' (it emphasizes that units are the key to interacting with the library) but I'd love to get a second, third and fourth opinion! perhaps: Numeric.Units.SI exports the SI units... but then it's not obvious what to do with the other exports (Dimensionless etc.) - Numeric.Units I guess?
Normal usage would be:
import qualified Prelude import Numeric.Units.Prelude import Numeric.Units.NonSI (poundMass)
The Prelude replacement includes all SI units.
I don't remember, is it possible for modules that import yours, to define arbitrary new units of their own?
Yes, e.g. "nauticalMile = prefix 1.852 (kilo meter)".
I mean a new dimension, like "prettyness" measured in "Emilys", for example.
Is the module's API good enough (or unlikely enough to be duplicated or significantly changed) to use a clean name -- or are we not supposed to be worrying about that because of namespace separation by package? I'm a little confused here, but I think it doesn't matter if our infrastructure is good enough?
I don't foresee any changes to the API. I'm rather happy with it though I haven't gotten much feedback from others. The library isn't haskell98 though, indeed it is GHC6.6+ only. Not sure whether that should be a concern.
I'd also like to think all this doesn't matter if our infrastructure is good enough, but are we there yet?
I don't know.
Thanks, Bjorn
participants (1)
-
Isaac Dupree