Hi, I am very impressed by your work to date on fan, and see it as a language with real potential. However there are a few design decisions I want to query, and ideas I want to put forward. At least part of this is to judge the bigger question of whether you see this as an open source project, or a dictatorship (benevolent or otherwise).

First up are quantity literals. At present you have literals for timespans (ns, hr, etc.). But these are really only the tip of the iceberg wrt literals of that type.

The real world concept is quantity literals, and examples would include distance (metres, kilometres, milies), mass (grams) and speed (mph, kph).

Limiting quantity durations to just timespans is very restrictive - why just pick time? I would suggest that either timespan literals are dropped, or a more general quantity literal strategy is adopted.

Here is the start of a proposal: class Quantity {

Unit unit
Int amount

}

Literal syntax possibilities:

distance := 6:Miles
distance := 6_Miles

where Miles is a Unit.

Unit would need to be an extensible set of units.

Stephen

Duration literals were added to the language because I wanted to standardize on nanosecond ticks, and working with numbers like 1_000_000_000 for 1sec was unweildy. So it is a bit of a special case since they are used all through out the API.

But there will definitely be a sys::Unit class on the way. The market I personally work in (M2M) makes heavy use of measurement values from sensors. I've been passively involved in JSR 275, and actively involved in developing a unit design for an OASIS specification called oBIX. Section 11.5 of the spec defines how we handled units of measurement, and the spec has an associated XML unit database. There is also an open source implementation in Java. I would like Fan's unit system to be based on oBIX.

As an aside, oBIX is actually a great spec to read as a background for the whole REST, Uri, Namespace design. It has a cool prototype based type system inspired from Self.

So I personally haven't given a lot of thought to it yet, but units will definitely be a part of the core system.

Brian,

Thanks to Stephen, who also started thiss thread I learned, Fantom had Units of Measure support built in at a rather core level. Prior to that I knew CURL and recent versions of F# to provide something similar only. And a few platforms like Smalltalk or Delphi having a few main Unit libraries.

I was one of the JSR-275 Spec Leads, and if you followed some of its development, then you may have seen, a key reason most EC members turned it down was they were afraid of changes to core parts of the JDK similar to what Fantom, CURL or F# provide.

Does the Quantity type exist already? It follows concepts in the Units of Measure API, the official successor to JSR-275 rather closely. As that API (see unitsofmeasure.org) was designed open to several implementations, at least Quantity has no Unit or Decimal part. Implementations like ICU4J's Measure do.

There is at least another OASIS standard dealing with Units, UnitsML, where former JSR-275 EG member Karen Legrand is participating. I'll look into the oBIX Java library what it means compared to UnitsOfMeasure.org? UCUM is certainly an important standard for all kinds of unit data exchange, especially in business or healthcare. They may be interested in oBIX, too.

I'd be happy to get involved here or get Fantom in touch with the UCUM standard.

Werner

I checked out the "units.fog" DB. Quite fascinating, as I wrote a SF project called "sdj" over a decade ago, and the Java properties or other text files holding Units weren't so much different...

Do you see a way to make this pluggable, so that e.g. the whole set of UCUM standard units could be represented in such FOG?

Hi keilw, welcome to Fantom!

I actually participated in JSR-275 for a while too (and the previous 108).

Quantity does not exist today, mainly because it is so tricky to create a simple API that covers all the cases (Int, Float, Decimals, and collections of such).

What I've tried to do with the Unit database is focus on the most fundamental aspect of unit modeling which is just to get a standard database to identify unit names and basic definitions. Obviously lots of cool layers can be built upon this, but to me getting a standard unit database is the foundation.

The oBIX database was defined many years ago, and at the time I had a lot of trouble finding standards group which were focused on this basic naming/definition problem. Although the current database has a lot of units, its definitely incomplete and might have some bugs or misnamed units. It has been organically grown based on usage in fields such as hvac, energy, and industrial control.

If the UCUM tackles this problem in a more complete way, I'd love to merge it into Fantom's standard database (and I can also help get it standardized by OASIS as part of oBIX).

So couple questions:

• does UCUM define a standard database of units?
• if so is the model compatible with units.fog?

I apologize for not understanding all the issues being addressed by this topic, and the various standards mentioned above.

I do like the idea of the "1sec" instead of 1_000_000_000, but my next thought was to how units are used (say) in Physics.

The idea is that expressions like:

distance = rate * time

become:

miles = (miles / hour) * hours

and the units are understood to cancel. However, of course, you may wind up with:

duration := 5days
velocity := 32mph
distance := velocity * duration

It would be very cool if, somehow(1) the units system knew how to automatically convert the "5days" into "120hours" to do the computation correctly.

This would help with situations such as NASA's occasional problems with SI and metric units.

(1) "Anything is possible to the one who does not have to do it." :-)

I spoke to some of the NASA guys at EclipseCon. They're aware of the problem and got a few of their own libraries, some even using Eclipse technology (which especially FWT also does in Fantom ;-)

Partly this, but also the UnitsOfMeasure.org site behind the UCUM standard inspired Eclipse UOMo, a project derived by some ideas from our earlier JSRs (108,275) and the unit and measure types in ICU4J. See http://www.eclipse.org/proposals/uomo/

I started experimenting with the simple approach by Andrew Kennedy used by F# which has also influenced similar Measurement libraries for Smalltalk or Scala. I created a small PoC last night:

Unit metre	:= Unit.find("meter")
Unit foot	:= Unit.find("foot")
Unit kg		:= Unit.find("kilogram");
echo("hello metre " + metre.symbol)
echo("in feet " + metre.convertTo(1f, foot))
//echo("in kg " + metre.convertTo(1f, kg))

Measure m := Measure.make(1f, kg)
echo("Measure: " + m)
Measure m2 := -m
echo("Measure2: " + m2)
Measure m3 := Measure.make(1f, metre)
echo("Measure3: " + m3)
Measure m4 := m3+Measure.make(5f, foot)
echo("Measure4: " + m4)

It seems you cannot upload sources here in the forum, but if you let me know a place, I'd be happy to share the source for Measure.fan. It already deals with simple conversions, e.g. adding 1m+5ft, and its conventions stick a lot to Date or similar classes (rendering to "1day" as duration)

Of course multiplication or pow() operations would have to do more "magic" and conversion, but the simple way of calling them in Fan is very appealing.

Regarding UCUM, there is a definition file named ucum-essence.xml. (one of the places should be here: http://aurora.regenstrief.org/~ucum/ucum-essence.xml)

Aside from prefixes for unit operations (mainly the * operator) which aren't supported by the Unit class as of now, there's probalby only an attribute called "code" that exceeds the scope and attributes in units.fog.

I took a brief look at the "buildunits" script, and see no reason why this couldn't be extended to a quantity named "ucum".

Werner

And yes, the Float vs. Decimal issue is something I came across there, too. For now I stick with Float to be compatible with the current Unit implementation, but constructors or converters accepting full precision Decimal types should also work somewhere. Especially if you plan to support Outer Space (see the NASA quote earlier ;-) or even just Financial Services.

I designed a DecimalMeasure, something JSR-275 had for a while. It has the same signature as Measure, but takes Decimal instead of Float. For most cases that should do. In the JSR we had Float/Double beside Int/Long, but many cases required a higher precision Decimal, too.

I haven't heard from the UCUM guys, but one important come to my mind based on the current Unit implementation.

Does Unit have to be final?

ICU4J which I just started building UOMo Financial on top of (with significant help by the Units of Measure API, successor to JSR-275) declares an abstract MeasureUnit. With major types like Currency subclassing it. Fantom has no Currency, but it seems not impossible to have that be a Unit, too.

Key elements like name and symbol are already defined by the Unit class. If Unit had an additional code attribute, then not only UCUM codes could be represented, it would also work for extensions like a Currency type.

Here's just a Hz frequency in both the FOG and UCUM form

FOG:

"frequency",
Unit("hertz; Hz; sec-1"),

UCUM:

<unit Code="Hz" CODE="HZ" isMetric="yes" class="si">
   <name>Hertz</name>
   <printSymbol>Hz</printSymbol>
   <property>frequency</property>
   <value Unit="s-1" UNIT="S-1" value="1">1</value>
 </unit>

As you can see, even the "s-1" vs. "sec-1" information are similar, except for "code" and the "class" which is allows telling SI from other groups they are almost identical.

I'd be happy to contribute here, especially in the area of a Measure or possible Currency type.

Werner

what is the difference b/w "code" and "symbol"?

Just throwing in a reference to an interesting unit-related language - Frink.

The presentation also includes a small recap "Units in existing languages".

@brian: the code would more be a unique attribute that's machine readable, see UCUM for that.

Many cases in UCUM have either name or symbol same as code, but this on's a good example:

<unit Code="Cel" CODE="CEL" isMetric="yes" isSpecial="yes" class="si">
    <name>degree Celsius</name>
    <printSymbol>&#176;C</printSymbol>
</unit>

Symbol printing °C

For a Currency sub-class obviously you'll have name=US Dollar symbol=US$ Code=USD

In fact for some types, the code may be more unique than the name which is currently kind of a hybrid in Fantom's Unit class.

@katox: Thanks a lot for pointing that out. There are other "Scientific" languages, especially Fortress by Sun, but funding for that project seems to have stopped long before Oracle purchased Sun. So beside other examples like F# Fantom remains one of the few Open Source examples for Units of Measure playing a more important role in the language than usual.

For various conversion tables, prefixes, and much more, this site is a good source: http://www.allmeasures.com/

Another one (Brian probably knows some of it as its makers were JSR-108 EG members once, too) http://www.unidata.ucar.edu/software/udunits/udunits-1/udunits.txt