Question: Suppose I have the following code:

```
type A =
  abstract member hi: string

type B() =
  interface A with
    member self.hi: string = "Hello"

type C() =
  interface A with
    member self.hi: string = "Yo"

```

I can make F#'s type checker happy with a list of objects of type `A` and `B` as long as I explicitly specify the interface type, ala:

```
let l: A list = [ B(); C() ]

```

But I'm kind of stumped when generic parameters enter the picture. E.g.,

```
type A<'T> =
  abstract member thing: 'T

type B() =
  interface A<int> with
    member self.thing: int = 1

type C() =
  interface A<string> with
    member self.thing: string = "Yo"

```

and I try to use something like

```
let l: A<_> list = [B(); C()]

```

F# seems to want to stubbornly fill in the generic type parameter:

```
error FS0001: The type 'C' is not compatible with the type 'A<int>'

```

Note that I have used this pattern in Java with standard interfaces and in Scala with traits, so I am surprised that I am unable to do this in F#. What am I missing here?

Answer: 
In an ECS structure, your movement system doesn't care about your physics. The physics would have a system of it's own.

The `Movement` system updates a `Position` component based on some other component, say, `Velocity`.  

The `Physics` system updates the `Velocity` component based on forces.  

And the `Collision` system updates both the `Position` and `Velocity` components based on collisions (intersects with other objects).

Pseudocode:

```
MovementSystem {
    void Process(Entity e){
        e.GetComponent(PositionComponent).position += e.GetComponent(VelocityComponent).velocity;
    }
}

PhysicsSystem {
    void Process(Entity e){
        e.GetComponent(VelocityComponent).velocity += World.gravity;
        //And other physical forces being applied to the entity.
        //I guess you could have a 'Forces' component.
    }
}

CollisionSystem {
    void Process(Entity e){
        var collisions = SomeFunctionThatChecksCollisionsWithTheEntityInTheScene(e);

        foreach(collision in collisions) {
            e.GetComponent(VelocityComponent).velocity +=
                SomeFunctionToApplyForceBasedOnCollision(collision);
            e.GetComponent(PositionComponent).position +=
                SomeFunctionToOffsetAwayFromTheCollisionIntersection(collision);
        }
    }
}

```
Not every entity that moves is influenced by physics in a simulation...

I would split the `MovementSystem` into two types

1. Movement for entities which are physics influenced.
2. Movement for entities which are *not* physics influenced.

In the case of the latter, you can go ahead and take the direction on the `MovementComponent` in combination with the speed on the `VelocityComponent` and calculate the movement and position of the entity.

In the case of the former, you will need to allow physics to run its simulation, determine collisions and handle those. In either case, you'd need to then update the position for all entities influenced by physics.

So from a loop perspective, I'd expect to see

1. Input system captures key/mouse input.
2. Player controller system analyzes input and generates intent as appropriate.
3. Run the movement for non-physics influenced entities.
4. Execute the RigidBodyMovementSystem
5. Resolve collisions
6. Update position for all physics influenced entities.

Remember that even based on how you describe your systems, they can be decomposed into smaller system components that specifically handle one smaller task and the output from that step is the input to another system.