Compiler causes name collisions that do not exist within native elm, and does not catch them as errors

[edwardpeters]

Describe the bug

This relates to #1101

To recap that error, the morphir-elm compiler does not notice or complain if a multiple values or fields have the same name.

This is compounded by the fact that morphir's naming conventions cause collisions which do not exist in elm, so elm tooling may not catch these redundant fields either.

To Reproduce
The following code compiles and runs in elm:

type alias MyRecord = {
    exampleField : String,
    example_field: Bool
    }

bar : MyRecord -> Bool
bar record = record.example_field

myValue : String
myValue = "myValue"

my_value : Bool
my_value = True

foo : MyRecord -> String
foo record = record.exampleField

sample : MyRecord 
sample = {exampleField = "Red", example_field = True}
     
test : ((String, Bool), (String, Bool))
test = ((foo sample, bar sample), (myValue, my_value))

However, morphir-elm make throws an error, because it treats both exampleField and example_field as ["example", "field"] (and the same for the values).

The issue is that if you do not specifically refer to these, the redundant definitions on their own are legal:

type alias MyRecord = {
    exampleField : String,
    example_field: Bool
    }

bar : MyRecord -> Bool
bar record = record.example_field

myValue : String
myValue = "myValue"

my_value : Bool
my_value = True

compiles just fine. (The last field definition seems to be what's found.) Elm tooling also will not complain about this, because according to elm, those are two different fields.

Expected behavior
Either these names should be treated as distinct, or the morphir compiler should report them as errors.

Desktop (please complete the following information):

• OS: OSX
• Version: 2.86.0

[stephengoldbaum]

In this case, we are more restrictive than Elm and do want this limitation. So we should make the feedback/documentation clearer. The reasoning is that Morphir focuses on business terms and we define strategies to achieve those across the languages. Your camel case and snake case examples are two ways of achieving the same business name in Elm.

[edwardpeters]

@stephengoldbaum Oh, yeah, if it was unclear, I'm not saying the collisions themselves are a bug - just the fact that the morphir-elm compiler doesn't show an error if you attempt them. There's a number of things it doesn't catch, but I think most of the others would at least be reported by elm tooling - since these cases aren't an elm bug, they can make life difficult for developers.