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: 
A straightforward approach could be to add to the movement component a desired destination along with the actual one. Then update only the former within the movement system.  

On the other side, the collision system will try to apply the new position by switching it with the desired one and check for collisions one entity at a time.

Another approach could be to update only velocities within the movement system. Then add a more general physics system that updates position for an entity at a time and check for collisions, adjusting velocity and position if needed.

You can even define a single system that does exactly what you did previously: iterate over all the entities, update position for an entity at a time and check for collisions, then proceed with the next entity.  

You don't have necessarily to separate movement system and collision system, do what sounds good for you and your game.
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.