Units of measurement in programming languages (was Re: Complexity Shock Horror II: the Sequel)

[Chris Pressey]

On Mon, 31 Mar 2003 23:20:54 +0200
Twan van der Schoot <twanvds@REDACTED> wrote:

> Hi Chris,

Hi.

> On Monday, March 31, 2003 9:35 PM, Chris Pressey  wrote:
> >
> > Yet, I don't see *any* scalar values in the world around me.  They
> > *all* have units of measurement.
> 
> I'm sorry, but quite a number of constants in physical are
> dimensionless. 
>  And these have  a "scalar" nature.

OK, I was a bit hasty in making that statement.

However, aside from e and phi, I can't think of any popular constants
that are purely scalar in nature.  Many scalar constants are more like
pi, that is, a ratio between two measurements with the same unit
(circumference (distance) / diameter (distance).)

In any case, because scalar constants are in the minority, and because
it's easier to express a scalar as a measurement without units than it
is to express a measurement given only scalars, I do think scalars
should be the exception to the rule, rather than the default case.

> But in a typical programming context, what about an ordinal number
> like an index in an array? And just counting of elements in a list? 

For both of these, the unit of measurement is 'elements'.

> Do you want to count the number of elements, like 23_element, or
> 23_list, in case that list is comprised of lists?

It depends what you're counting.

If you have a function that counts the number of elements of a list, it
should return a value with a unit of 'elements.'

If you have a function that counts the number of lists in a list, it
could return a value with a unit of either 'elements' or 'lists.'

All this implies to me is that 'lists' are a subunit of 'elements', and
consequently, that the structure of the unit system reflects that of the
type system.

> Besides, one introduces the requirement for a kind of type-system
> (i.c. dimension/unit checking and derivation).

Yes.  This is a *good* thing, IMO, because it catches errors.

> For the usual
> arithmatical expressions this may be not a problem.  But what unit has
> a list of, say, metres?

Same deal.  If you have a function that counts the number of lists of
meters in a list, it could return a value with a unit of any of
'elements' or 'lists' or 'lists of meters.'

Just like if you had a function which counts the number of cars in a
dealership's showroom, it would return a measurement with 'cars' as the
unit; if it counted red cars, it could return either 'X cars' or 'X red
cars'; etc.

Again, just showing that the unit system mirrors the type system.

But because Erlang's type system doesn't distinguish between lists of
one thing or another, I don't think it necessarily needs this level of
detail.  For simplicity, all subunits of 'elements' could be omitted.

> And the second question then pops up
> immediately.  Does one want to base such a measurement system on the
> structure of the dimension or should it be a level more concrete and
> should one use a concrete unit standard (like SI or BSI or ANSI).

Both, converting between the two as necessary.

Internally, I imagine measurements would be stored like:
  {20.7, [{kg,1},{m,2},{sec,-2}]}

Whereas in the programming language and its I/O, one could say
'20.7 joules' as a shorthand for this.

> Eventhough it would make doc-hunting less necessary, it is much too
> concrete to be "sufficently" generic for a universal programming
> langauge.

I think that remains to be seen.

> BTW: Are you acquainted with the HP48?  That nifty calculator allows
> you to enter number extended with units and all arthimatic behaves
> nice.

Yes.  That a calculator can do it, goes to show that it's not
technically difficult.  Yet we're stuck with spreadsheets and
programming languages still in the dark ages of being able to confuse
meters and feet, because they're all treated as scalars, because that's
how we've always done it, because it's been deemed good enough (not
unlike those two-digit years that got us into that y2k kerfuffle.)

> So, I guess that leaving scalars in favour of "unit objects" is not a 
> concept for a universal programming language.  But I do think it would
> be great to have facilities in a programming language which make it
> attractive to have a standard library available which lowers the
> threshold to implement /applications/ utilising unit objects as the
> main representation of a measurement.  What these facilities precisely
> should be without unduly interference with the basic clarity of the
> programming language, I don't know.
> 
> br
>
> Twan van der Schoot.

While that would help for building a spreadsheet (or similar
application) that is unit-aware - why stop there?

I still think the greatest benefit will only be seen if there is a tight
coupling between measurements and the type system and syntax of the
programming language itself.

-Chris