"Strong typing vs. strong testing"

[BartC]

"Malcolm McLean" <malcolm.mclean5 at btinternet.com> wrote in message 
news:1d6e115c-cada-46fc-9444-01e80e0afd75 at c10g2000yqh.googlegroups.com...
> On Sep 27, 9:29 pm, p... at informatimago.com (Pascal J. Bourguignon)
> wrote:
>>
>> On the other hand, with the dynamic typing mindset, you might even wrap
>> your values (of whatever numerical type) in a symbolic expression
>> mentionning the unit and perhaps other meta data, so that when the other
>> module receives it, it may notice (dynamically) that two values are not
>> of the same unit, but if compatible, it could (dynamically) convert into
>> the expected unit.  Mission saved!
>>
> I'd like to design a language like this. If you add a quantity in
> inches to a quantity in centimetres you get a quantity in (say)
> metres. If you multiply them together you get an area, if you divide
> them you get a dimeionless scalar. If you divide a quantity in metres
> by a quantity in seconds you get a velocity, if you try to subtract
> them you get an error.

As you suggested in 'Varaibles with units' comp.programming Feb 16 2008? 
[Yes with that spelling...]

I have a feeling that would quickly make programming impossible (if you 
consider how many combinations of dimensions/units, and operators there 
might be).

One approach I've used is to specify a dimension (ie. unit) only for 
constant values, which are then immediately converted (at compile time) to a 
standard unit:

a:=sin(60°)       # becomes sin(1.047... radians)
d:=6 ins          # becomes 152.4 mm

Here the standard units are radians, and mm. Every other calculation uses 
implied units.

-- 
Bartc