Feature parity with spec

[Raynos]

There is a spec for todomvc ( https://github.com/tastejs/todomvc/blob/gh-pages/app-spec.md ).

It would be nice to either implement the spec or document what functionality is missing from Elm to make it possible to implement in a non hackish way.

Basically a working example or a list of open problems would be nice to see.

[evancz]

Known issue, it's a time/priority thing :P When that happens, I'm thinking it may be valuable to keep this one around as a simpler learning resource (i.e. "how do I use Elm?", not "what does it look like when someone else uses Elm?")

[Raynos]

@evancz if you can't write todomvc in an hour then something is wrong.

[evancz]

The interesting thing is that the "hard" part is that I don't get the html and css for free. It's also that the Graphics.Input library is still somewhat experimental. In other words, there are still design choices to be made elsewhere and this is an early experiment.

Your comment seems to be needlessly rude more than anything else, so please be constructive and specific if you'd like to discuss this further. I am working hard to get all of this straightened out. Getting these APIs right takes time, and the APIs are far more important for me to spend an hour on than copying the TodoMVC style in minute detail.

[Raynos]

I didn't mean to be rude. I can't express tone / humor. By all means take your time and don't rush things.

Now that you mention it, it would be far more interesting to see what decisions todomvc spec has made that are non trivial to port over to an FRP style implementation. I'm sure there are many subtle mismatches between what is straight forward for an imperative implementation vs an FRP implementation.

[evancz]

Okay, no worries :) I think there are still some graphical things that'll be tricky given that the current inputs in Elm are very general. There are common patterns and repeated structures that need to be recognized and added to libraries. This example already found some!