Discussion: API Changes for Hopac 1.0

I’d like to push toward a stable 1.0 API for Hopac. Much of the API looks good and is relatively stable, but there may be some changes that we can make before a 1.0 release that can improve the usability of the API. Below are a couple of my ideas.

• Rollback use of constructors for Promises and IVar and some others, preferring create/createFull/createFailed functions.

• The idea of removing Scheduler from the design has been previously discussed. I am not sure quite where to start to do this, but it may be better to reserve for a possible 2.0.

• Move away from functional jargon names or add functions that have more names that are more “friendly” to new users. Taking a page from Elm, possibly introduce andThen as a synonym for bind.

• It is too easy to use Alt.prepare incorrectly, often doing synchronous work (or worse, waiting on jobs synchronously) before returning the Alt. Instead users that need to do asynchronouse work before an Alt is ready should be creating a Promise (through memo, for example) so that the Alt can finish instantiation and then continue to instantiate other Alts in a choose block. Possibly add documentation to the various Alt functions and/or add other functions into Alt that provide the intended functionality (even if simple synonyms to existing functions).

• Harmonize the names of Job/Alt/Promise functions that return unit, a constant, an exception, and that never return.

Each of these and more may spawn additional tickets, but I wanted to get some feedback before I go running off with this.

[haf]

-1 for the renames @21c-HK suggests. I also disagree with the justification; there’s no good auto-complete for huge F# projects in Ionide, so I type the Hopac functions and types all the time.

I think this project shouldn’t focus on making it easier to understand, but making it easier to get started and find documentation and experimenting. Perhaps we can compile to wasm?

[voronoipotato]

I think bind is fine. If you want to improve ease of use focus on exposing computation expressions in documentation. Most F# programmers are at least experienced in consuming CE’s.