futurize / future-io Goto Github PK

Stuff that needs to happen before we can go public with this. Feel free to add additional points.

• #3 Add features missing for MVL.
• #4 Decide on node versions to support (>=4.x).
• Dump Ramda (it's hardly used at the moment).
• #5 Finalise README.
• Setup CI.
• tag and npm publish.

I think I managed to find a way to remove the world object and still allow the IO monad to be easily tested. It simplifies the API quite a bit.

Basically, the inpure functions are contained in the Monad itself rather than a separate world object (like you suggested before). However, they are not called automatically upon unsafePerform. Instead, you have to pass in an executor function that can either call those impure functions (default scenario), or do something else entirely (like passing the arguments to a test and piping some mock response back into execution). We can offer easy to use wrapper functions for both execution scenario's.

The whole thing is a bit inspired by the Free monad, but I don't believe it can be expressed as one directly.

Apart from passing in your unpure function, you pass in a 'name' which can be used during the non-standard run to, for instance, log what the thing is doing.

It's on the try-2 branch. I have to tackle the nice generator based API, add the node-lib related methods from the other branch and then I think I can wrap this up pretty quickly.

Consider what should be in there. Theoretically, the entire chain of operations could be printed, because each has a name:

IO(process.argv -> process.stdout.write)

Not sure if that's a good idea though.

There will probably be more functions to come. So lets move process/fs and so on to future-io/node/*.
I'm thinking about adding f.e. future-io/browser/(document, location, ...)

Is the current README clear? Do we need any additional sections, links or logos before going public?

add reply Io.parallel

This library so far has the features we need for another project, but are those enough features to make it a viable library and, if not, what absolutely needs to be added?

Possible new features that can be added:

• Reading from stdin.
• fs operations.
• Making HTTP requests.

One remark here is that the IO operations in this library should, in my opinion, stay pretty close to the node implementation. Fancier more opinionated solutions can be built on top of that in separate libraries.

Features we decide not to be build for v1 can be moved into separate issues.

For instance, when the function passed to chain does not return an instance of IO.

See https://github.com/futurize/future-io/blob/strange-test-behavior/test/node-fs.js#L9
Tests run forever...

At the moment, the library is written in node v4. Is this ok or should we support lower?

If we support lower, do we write the source in ES5 or use a compilation step?

Personally, I dislike writing functional JS without having at least arrows to work with, so I'd be against supporting node 0.x with ES5 source code.

no nulls