Lambda the Ultimate

Dimension types are extremely useful for preventing errors in programs that manipulate physical quantities. There are several Haskell libraries for them, F# has a built-in version, etc. (I've read about a nice Python package that addresses the same issues dynamically, which may be a good source of inspiration, though my personal interest is in static approaches.)

Of course there is the thorny issue of selecting a basis with which to express dimensions. The dimensions of the SI base units are a common choice. The dimensions of the cgs units are another appealing choice in some respects, though you do need to deal with fractional powers (e.g. 1 esu = 1 g^1/2 cm^3/2 s^-1, so the dimension of a charge is Mass^1/2 Distance^3/2 Time^-1, whereas in the SI system it is Current^1 Time^1). There is also some appeal to allowing the creation of additional user-defined basic dimensions in addition, to allow dimensions like Vehicle^1 Time^-1 for the rate at which traffic is flowing.

Since my target users are engineers, I am inclined to choose the dimensions of the SI base units. For simplicity I will set aside the question of additional user-defined basic dimensions, because it is only slightly related to my primary question.

There is broad agreement (for decent reasons) that angles are dimensionless, and there is a long history of mostly treating them that way in the mathematics, physics, and engineering literature. Yet pragmatically, serious errors can arise when revolutions are mistaken for radians or angular velocities are confused with frequencies. Factors of 2 pi are liberally sprinkled all over the place, and it is pretty easy to forget or misplace one.

This form of confusion and traditional resort to name-based disciplines seems very much like the type of confusion and lack of formality that dimension types are intended to address. I find that I much prefer my toy system where angles are treated as dimensions to the version in which they are not, because it requires me to annotate all the places where numbers turn into angles (and vice versa) with the "units" that I am intending to use. This naturally leads to extremely good documentation of interfaces, serialization formats, and interoperation with external code.

There is a related problem where torques and energies share the same SI dimension (Mass^1 Distance^2 Time^-2), which can be helped by pretending that angles have a dimension and treating the dimension of torques is Mass^1 Distance^2 Time^-2 Angle^-1. This does lead to some problems, though. For example, torque is no longer equal to the cross product of displacement and force. (Or is it? Both this use of the cross product and the use in defining curl seem to involve angles in the same way, so for a minute I considered changing the type of my cross product operator to introduce a factor of Angle^-1. I don't think it is helpful to do this, though, because I can't figure out how to stand on my head and imagine the use in the Lorentz force equation to involve implicit introduction and elimination of an angle, so it appears that this angular nature is not an inherent property of the cross product operator.) Another approach (not entirely an exclusive choice) is to distinguish through the vector nature of torque and the scalar nature of energy; now taking the norm is where your turns/degrees/radians ambiguity arises, and also it is not clear to me how this approach would work in fewer dimensions.

Should angles be modeled as a dimension for software engineering purposes? Should they be modeled in some other way? Should they be left implicit?

(To throw another wrench in the works, similar remarks apply to solid angles, although they may arise considerably less often for my target users. It also feels arbitrary to stop after 3 dimensions, and I assume--although I am not familiar with one--that there is some sort of generalization of solid angles to n-dimensional space.)