Regarding simple type systems, experiments, and language features for library authors -- finding the right abstraction is hard. In 0.18, there's an HTTP abstraction, so you can run requests in parallel (but not arbitrary effects: racing a file read and a file delete is a bad idea!). Then there's an abstraction for arbitrary effects, Task, which can be chained with andThen. Finally there's Cmd which is more restricted and represents the final unit of work to be done by the runtime. The most sophisticated thing you can do is map over its return value (not the work itself), usually to wrap it so you can identify what happened. But importantly, the preferred way to run an HTTP request is to turn it directly into a Cmd. You can turn it into a Task, and a Task into a Cmd, but that's an escape hatch for experts.
Back to the larger goals: I think it's fair to say that we want to be able to write webapps/SPAs in Elm. That is, we want it to replace Angular, Ember, React+Flux, etc. Evan has said that he wants to wrap the "web platform", and as a result of that, we have access to most web primitives but not nice framework abstractions. We have virtual DOM but resuable UI components. We have HTTP but no models (like Ember Data or Rails, not the Elm model that holds all your state). That is, Elm is really good at computation and the ability extract functions is incredibly useful. But things stop working when you look at the inputs and outputs of a webapp, and they are primarily HTML and HTTP (also the current time, randomness, and a few others). So I think what we need is the ability to abstract over HTTP with models, and to abstract over HTML with reusable components. The former seems really hard. The former seems hard only if you need to hold state in your component; maybe we'd have some luck trying to make "components" that are actually just functions? -- You received this message because you are subscribed to the Google Groups "Elm Discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to elm-discuss+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
