Make use of ocaml's type system

[pkel]

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.

[OvermindDL1]

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).

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.

And I'm not sure what is with the adding of empty tuples on a couple of calls either? They have no optional arguments so adding them seems entirely pointless? Or am I missing something? o.O

But at the very least the module overall cannot be done to the Tea namespace at all, and something similar (though not like what is here for efficiency reasons) is planned for the TeaEx namespace when I get started on new projects. :-)

[OvermindDL1]

I tried to get modules to fit Elm's style but it does not match it's API and makes porting more difficult. I already have a module style planned for the Elm-API-breaking style though, but the base TEA must follow Elm's style.

[OvermindDL1]

Why are there random empty tuples being added to some calls? o.O?
They do not have optional arguments or anything...

[pkel]

This one is definitely my fault. It should be you did it and my type signature in the mli should be changed to t -> unit.

[pkel]

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.

[pkel]

We have n##remove : unit -> unit from type t. If remove is meant to be an impure function which removes a node from the DOM, it's type should be val remove: t -> unit. A correct implemention would be let remove n = n##remove ().

[OvermindDL1]

Ahh that was entirely a copy-paste munge! Good catch! ^.^

Hmm, I'm not even using this function it looks like, maybe it should not even exist...

[OvermindDL1]

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). :-)