Max Goldstein
2017-05-01 02:45:49 UTC
I'm salvaging this idea from the "moving on" thread. Basically, some
features like audio playback, binary data, task ports, and so on have been
commonly requested. I'd like to propose that the advocates of these
features do some of the pre-code legwork. This is more of a literature
review than a design document. It would serve several purposes: to give
those clamoring for features something to do (funnel the creative energy),
to to let them examine the feature in more depth to determine if it really
solves their problem, and to give some guidance during implementing that
we're talking about the same thing. It would also provide a common place to
link when someone asks "what are task ports?".
This project would take the form of a collection of markdown documents,
each researching a particular proposed addition and say why it would be
useful. Each document should, for its proposed feature X:
- Define X
- Explain of why X is useful
- Describe the best way(s) to do X in Elm today
- Describe how other ML-family and JS-ecosystem languages do X, with
links
- Give type signatures or syntax of a *proposed* API for X
This is work that Evan would have to do anyway. (And he might still have to
do it anyway, since I haven't talked to him about this and he might ignore
or nix it.)
features like audio playback, binary data, task ports, and so on have been
commonly requested. I'd like to propose that the advocates of these
features do some of the pre-code legwork. This is more of a literature
review than a design document. It would serve several purposes: to give
those clamoring for features something to do (funnel the creative energy),
to to let them examine the feature in more depth to determine if it really
solves their problem, and to give some guidance during implementing that
we're talking about the same thing. It would also provide a common place to
link when someone asks "what are task ports?".
This project would take the form of a collection of markdown documents,
each researching a particular proposed addition and say why it would be
useful. Each document should, for its proposed feature X:
- Define X
- Explain of why X is useful
- Describe the best way(s) to do X in Elm today
- Describe how other ML-family and JS-ecosystem languages do X, with
links
- Give type signatures or syntax of a *proposed* API for X
This is work that Evan would have to do anyway. (And he might still have to
do it anyway, since I haven't talked to him about this and he might ignore
or nix it.)
--
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+***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
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+***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.