[Discussion] RFC 1091 - Extending the Types which Support Units of Measure

[abelbraaksma]

This thread discusses the proposal in #495.

There's already some discussion in that issue. To summarize the open issues:

• Should measures be equally applicable to all build-in aliases of the primitive types? Answer: under discussion
• Should measures be applicable to user-defined aliases of primitive types? Answer: no
• Should nativeint or unativeint be allowed as UoM? Answer: under discussion
• Should measures be allowed on the actual types (i.e., Int32<kg> vs int<kg>)? Answer: under discussion
• If the type checker presently doesn't allow two alias types to be equal when a measure is applied, should this be made valid (i.e., can int<kg> be used interchangeably with int32<kg>? Answer: under discussion

[abelbraaksma]

In reply to #495 (comment):

But it will be more work than I originally thought. It seems some additional logic needs to be injected somewhere (probably the constraint solver), so that measured abbreviations are considered in terms of their base types (without sacrificing the measure information).

Did you actually see this fail? Because alias-resolution already exists, perhaps once you've allowed int<kg> and int32<kg> to work, you can try a test like the one I proposed in #495 (comment).

let f (x: int<kg>) y: int32<kg> = x + y   // should be valid, inferred type for y is int<kg>
let g (x: int<kg>) y: int32<kg^2> = x *  y  // should be valid, inferred type for y is int<kg>
let h (x: int<kg>) y = x *  y  // inferred return type is int<kg^2>, inferred type for y is int<kg>
let h (x: int32<kg>) y = x *  y  // inferred return type is int32<kg^2>, inferred type for y is int32<kg>

@pblasucci If this leads to a lot of extra work, I've (still) no problem in postponing this, and allow the constraint solver and/or type inference to choke on this, i.e., where the user just has to stick to one chosen alias.

[pblasucci]

@abelbraaksma, thanks for opening up the issue.

Did you actually see this fail?

Unfortunately, yes. I tried the exact code you posted (after enabling int32<'u>). The constraint solver rejects the attempt to use, e.g., ( + ) with operands of type int<mm> and int32<mm>.

Because alias-resolution already exists

Indeed. With unmeasured values, the types (e.g. int, int32) are treated interchangeably. It's only the handling of the measurable variants that's at issue. It looks like maybe the abbreviations are expanded after the work to identify a type or value as measurable. Thus, two different paths though the compiler logic.

---

(Aside: there's also a possibly related issue with respect to how constants are resolved to entities in the type checker; but I want to study that portion of code a bit further before discussing it.)

---

If this leads to a lot of extra work, I've (still) no problem in postponing this, and allow the constraint solver and/or type inference to choke on this, i.e., where the user just has to stick to one chosen alias.

☝️ Just to clarify: you mean we'd release the update so that unsigned and native ints are supported -- but only a single abbreviation for each primitive can be measurable (i.e int or uint but not int32 or uint32)?

Because I'm comfortable with either that or delaying the whole thing. But I reallllly don't want to have multiple abbreviations for the same type be not-interchangeable.

[abelbraaksma]

That's a good point (your last one), I agree with that.

[pblasucci]

I figure now's a good time to update the discussion...

State of the PR:

1. Unsigned integers are now included in the set of types which are measurable (i.e. can be decorated with units of measure)
2. Native integers are now included in the set of types which are measurable (though at least one test for this is being difficult)
3. Any numeric types which have multiple abbreviations (e.g. sbyte & int8) now support units of measure for all abbreviations.
   1. The rules for above work the same as any other type abbreviation; namely: they are interchangeable, and inference will default to the canonical abbreviation (e.g. int<m> rather than int32<m>).

Errata:

• User-defined measurable types work as they always have.
• I was unable to appropriately extend the machinery to include CLR types (i.e. you can't do System.Int32<m>).

Remaining work is:

• A bit more testing
• Hiding things behind language version flags
• Any reviewer feedback (greatly appreciated)

[abelbraaksma]

Wow, that's an impressive set of features! Good work! I'll have a go with your branch 👍.

[pblasucci]

Spoke too soon... there's an error specifically with unativeint<_>. ☹️

Looks like a parser issue. It's actually present in production F#... but I guess it wasn't considered a big deal, since you can't add units to it anyway (in 4.x).

[pblasucci]

OK. Gonna add this here for posterity's sake (and in case anyone is curious)...

I finished the analysis of the issue I was having with unsigned native integers. Basically, it was a bug in the parser. More specifically, the lexer filter was not including unativeint in the list of candidates for type application. Basically, the opening angle bracket (<) was never getting promoted from LESS to HIGH_PRECEDENCE_TYAPP. This, in turn, caused things to follow the wrong path the YACC file, which resulted in the wrong error message being displayed. Further, this would block extending unativeint to be a measurable type. Fortunately, it turned out to be a very simple fix (see 399bf88 for details... n.b. this bug has been in the parser code for quite a while; so, even if the decision is made to not extend native integers, I'd still strongly suggest pulling in this one commit).

Anyway, at this point, I just need to straighten out a bit of testing ('cuz preview features), and apply any reviewer feedback. 🙂

[abelbraaksma]

That's a great find! Must've been tricky and a deep dive into the compiler, nice work!

[pblasucci]

So, there are the following "maybe"s in the RFC:

1. single
2. double
3. int8
4. int32
5. uint8
6. uint32
7. nativeint
8. unativeint

It'd be nice to take a decision on them (n.b. they are currently all implemented in the PR -- but it's easy enough to drop out individual ones if they're unwanted for one reason or another). If we can arrive at a definitive answer here, I'll go update the code and/or RFC as needed.

[abelbraaksma]

For originality, it would be very good to have these all in. The alternative, not supporting type aliases would no doubt raise questions why uint (only available since a short while) and not uint32? Or why sbyte and not int8?

@cartermp, would you agree that we should support these? They've already been implemented.

As I understand it, the nominal types are not supported by this RFC, and neither are user defined type aliases of primitives (unless the type alias is itself an alias of a measured type).

But all FSharp.Core defined aliases are supported.

[pblasucci]

As I understand it, the nominal types are not supported by this RFC, and neither are user defined type aliases of primitives (unless the type alias is itself an alias of a measured type).

But all FSharp.Core defined aliases are supported.

@abelbraaksma Your understanding is correct.

[pblasucci]

Just found out about this:

https://devblogs.microsoft.com/dotnet/introducing-the-half-type/

Do we need a plan for also supporting this? Or is it too far "down the road" to be considered in the current work?

[abelbraaksma]

Yeah, I actually wanted to add a language suggestion to that effect, it probably shouldn't be part of this one, as it is a whole new type, specifically meant for high performance simd programming.

[abelbraaksma]

Done: #498

[pblasucci]

I know everyone is very busy, but are there any further thoughts on: #496 (comment)?

(I don't mean to bug anyone. Just want to keep this RFC "on radar" and, hopefully, progressing 🙂 )

[cartermp]

I think at this point I'll leave it to @dsyme to consider the scope

[dsyme]

So, there are the following "maybe"s in the RFC:

We should just do all of these unless there's a technical problem with this.

It's wrong for people who decide on single and double to have to resort to float and float32 to get UoM

[pblasucci]

Thanks everyone! I've updated the RFC to reflect this decision.

[pblasucci]

So, I just noticed the checkbox for

Design Review Meeting(s) with @dsyme and others invitees

is still not checked for this RFC. Is this something that needs tending to, and if so, is it possible to sneak this in before the .NET 6 release is November? I'm really keen to see this feature get "over the goal line". 🙂 Thanks!

[dsyme]

It's fine, not needed for this

We'll be moving features from preview to default for F# 6.0 in the next while

[pblasucci]

Awesome! Thanks!