Adding fixed precision integer types to Morphir

[AttilaMihaly]

On our last community meeting @DamianReeves brought up the topic of fixed-precision integer support in Morphir. Currently we do not specify a precision for our integers and we logically treat them as arbitrary precision. The main reason we do this is to avoid the complexity of dealing with what happens when the result of a computation doesn't fit into the specified precision. This is especially difficult in a language that doesn't allow runtime exceptions because we cannot statically decide if an operation will overflow at runtime or not. We have a few options to deal with this:

1. Explicitly declare that every arithmetic operation can fail by returning a Result.
2. Always return a valid value from every arithmetic operation even if the actual result wouldn't fit in the fixed precision. This means that we lose correctness outside the fixed precision.
3. Do not allow any arithmetic operations on fixed precision integers. This would mean that they should be only used at the edges and immediately converted to arbitrary precision for any calculation.

The first option yields APIs that are almost unusable due to the amount of boilerplate you would have to write. The second option is the one chosen by most mainstream programming languages but it trades correctness for efficiency. This makes sense for general purpose languages but for Morphir correctness is a priority.

To me, option 3 seems like the solution that would align most with Morphir's philosophy. This would mean that you could declare fixed precision integer types at the edges of the system but you would have to explicitly convert them to arbitrary precision for any calculations.

What does everyone think?

[stephengoldbaum]

It would be great to see what Option 3 would be like in practice for business logic authors.

[AttilaMihaly]

Option 3 make the assumption that the modeler is fine with always using arbitrary precision arithmetic inside the business logic and does not want to control the precision of intermediary values (of course if they need rounding logic they can still do that explicitly by using decimal arithmetic but that's outside the scope of this discussion). With that assumption we can represent the calculation with arbitrary-precision integers:

calc : Int -> Int

Then the modeler would have to do the following if they wanted to control the precision in the input or output of the calculation:

Fixed-precision input

They would first have to declare the input as a fixed-length integer:

type alias Input = 
    { foo : Int64
    }

Since it's always safe to turn a fixed-length integer into an arbitrary-precision we would provide a simple mapping function in the SDK:

toInt : Int64 -> Int

And to invoke the calc they would have to:

calc (toInt input.foo)

Fixed-precision output

Similarly with the output they would first have to declare it as a fixed-length integer:

type alias Output = 
    { bar : Int64
    }

Transforming an arbitrary-precision value to a fixed-length one may fail so the SDK function for this will return a Result:

fromInt : Int -> Result String Int64

And the handling would be a bit more complex accordingly:

calc (toInt input.foo)
    |> fromInt
    |> Result.map Output

The return type of this is a Result String Output as well so the error either needs to be propagated up to the integration layer or a default value should be assigned in the model itself:

calc (toInt input.foo)
    |> fromInt
    |> Result.withDefault 0
    |> Output

[DamianReeves]

I do think option 3 is compelling, and works for representation and storage, but does get problematic for interpretation and storage. That being said it becomes a runtime and implementation concern.

[DamianReeves]

We do have a need to support the following operations though, thoughts on that?

total: Int -> Int64 -> Int64
total quantity amount = Debug.todo("implement")

[DamianReeves]

Thinking out - loud here, I wonder if maybe above could be represented by type refinements/phantom types.

type alias Quantity min max = Int

Of course we don't have singleton types (that I know of) so that might be out.

The problem with the above is no way to express the following:

type alias SmallQuantity = Quantity -100 100

[DamianReeves]

My above shower thought aside, how would we specify a function is meant to be at "the edge"?

[stephengoldbaum]

how would we specify a function is meant to be at "the edge"?

By not having any operations on the Int64 type. So in order to use it, you'd have to convert it to Int. That solution is good for anti-corruption layer to keep logic pure. It doesn't help you optimize the backend performance. For that, is it acceptable to have a --performance flag that tells the backend to use long instead of arbitrary size int?

[DamianReeves]

I believe so (and it sounds like we are pretty much on the same page here). I'm curious though, why a performance flag? Perhaps I'm failing to understand how we'll flow such a flag down.

BTW, I can imagine how we could flow such a flag if the IR supported multiple attributes in its on disk representation as mentioned here: in #132 , but I feel we add un-needed ceremony to Morphir backends/runtimes requiring it to go through decorations.