Making record type arguments easier to maintain

[AttilaMihaly]

Consider the following use-case:

type alias MyInput =
    { foo : String
    , bar : Int
    -- ... 25 more fields ...
    } 

logic : MyInput -> Int
logic myInput =
    myInput.bar * 5

While the function logic declares its input as MyInput it really only uses one of the 27 fields the type has so it's requiring much more data to be available then what it really needs. This is a common modeling problem which leads to difficulties around testing because you need to pass in many dummy values. It also makes evolving types more difficult because if we just look at the type signature it seems that changing any fields will impact this function while in reality it wouldn't for most fields.

Elm (and Morphir) provides extensible records to get around this. You can change the type signature to:

logic : { e | bar : Int } -> Int
logic myInput =
    myInput.bar * 5

This tells the compiler that the input needs to have a bar field but it doesn't limit the rest of the record structure. This is great and very accurate but also very tedious. It's also redundant since the compiler could infer this anyway. On the other hand we usually do want to derive this from the definition of MyInput but the language doesn't help us with that.

What we would ideally want is the combination of the two:

• When writing the business logic we would like to be warned by the compiler if we are using the wrong field names so in this case we would like to treat myInput as a value of type MyInput.
• Once the logic is implemented though we would like anyone who invokes this function to only have to specify the fields that are used by it. So in this case we would want myInput to be of type { e | bar : Int }.

This would provide the best of both worlds and seems to be possible to implement in the Morphir tooling.

[DamianReeves]

Am I missing the proposal here? Also I actually don't find the extensible record to be that tedious, especially if you are allowed to assign it to a type alias and then use the type alias.

[AttilaMihaly]

I didn't want to get into the exact mechanism to achieve this before I get some feedback on the desired behavior first. It is not tedious with a single function but in our domain we often have hundreds of functions applied to the same business record. Using an alias wouldn't help much because each of those functions will usually use a different combination of fields.

type alias Record =
    { field1 : Int
    , field2 : Int
    -- ...
    , field42 : Int
    }

fun1 : { e | field1: Int, field3 : Int } -> Int

fun2 : { e | field8: Int, field14 : Int, field32 : Int } -> Int

-- ...

fun235 : { e | field34 : Int } -> Int

[stephengoldbaum]

How would this transpile to more restrictive languages? Would it result in an explosion of traits (one for each function)?

Another approach is to define the function arguments independently, which both makes it apparent exactly what's needed and makes the logic most universally accessible.

[AttilaMihaly]

Fortunately we have full control over what's getting generated. We can use a list of arguments instead of the extensible record in the target language. Maybe it's worth looking at an example of what the multi-arg approach means in practice:

Say you had this originally:

type alias Record =
    { field1 : Int
    , field2 : Int
    -- ...
    , field42 : Int
    }

logic : Record -> Int

usage =
    logic myRecord

You would have to manually turn it into this:

logic : Int -> Int -> Int -> Int-> Int -> Int
logic field1 field3 field8 field14 field32 =
    -- ...

usage =
    logic myRecord.field1 myRecord.field3 myRecord.field8 myRecord.field14 myRecord.field32

I think this is very tedious. To the point where modelers will be reluctant to do it so they fall back to the original. That's what I'm trying to avoid by essentially automating the process of declaring only the data points that are needed.

Basically our Elm frontend will look at the original where the input is defined as Record, do type checking to confirm that the logic is correct and then using the type information gathered during that process (the inferred input type of the body will be an extensible records with the fields being used anyway) and say: I know you declared that you expect a Record here, but I happen to know that you actually require less than that, let me make that definition more accurate for you.