OvermindDL1
Make use of ocaml's type system
Your current implementation lacks type signatures. I will try to fix this. I think we need functors to get rid of the type variables 'msg, 'model and so on. This is a first try. At least, we should think about better names for functors and module types.
The API you propose here breaks with the Elm API hard and thus cannot be used for the base TEA api as it should match Elm as close as possible. However a TeaEx is in planning that uses a similar API as that proposed here (with other changes that break with the Elm API further but add a fairly significant amount of performance as well).
After reading the comments in your code, I got the impression that you might want a functor based interface and could need some help.
Adding mli files are acceptable for files where some parts should be hidden (though I'm kind of not wanting that for now as internal parts are often quite useful), but are otherwise useless when the entire file's types should be exposed.
I sense a misconception of the ocaml module system here and recommend reading Chapter 4 of the book Real World Ocaml. Apart of allowing clean abstraction of complex implementation concepts, mli's also allow to reduce bugs by enforcing specified function signatures. I can generally recommend to start building a module by reasoning about the intended api with specifying it's mli file and do actual implementation afterwards. This way, the compiler knows your intentions and leads you through the implementation with useful error messages.
I sense a misconception of the ocaml module system here and recommend reading Chapter 4 of the book Real World Ocaml. Apart of allowing clean abstraction of complex implementation concepts, mli's also allow to reduce bugs by enforcing specified function signatures. I can generally recommend to start building a module by reasoning about the intended api with specifying it's mli file and do actual implementation afterwards. This way, the compiler knows your intentions and leads you through the implementation with useful error messages.
This is entirely true, but Elm's API is a little... wobbly on a few things. I do plan to have full mli for each of TeaEx's modules. :-)
After reading the comments in your code, I got the impression that you might want a functor based interface and could need some help.
I very much do for TeaEx, just for the Elm-like API I cannot at this time. :-)
For TeaEx I plan to follow the HTML5 webcomponent spec a lot more closely than Elm does, this will allow TeaEx apps and components from other javascript systems to be intercombined near trivially (compared to Elm now where that is an utter pain). :-)
