Suitable new name for Dimensional library
isaacdupree at charter.net
Fri Sep 28 12:34:35 EDT 2007
Björn Buckwalter wrote:
> On 9/28/07, Isaac Dupree <isaacdupree at charter.net> 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.
More information about the Libraries