"Strong typing vs. strong testing"
bc at freeuk.com
Tue Sep 28 12:18:41 CEST 2010
"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)
>> 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
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
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
More information about the Python-list