My idea for this package is to make it more ergonomic to write simple CLI scripts, for example dev tools and build pipelines. I also want to make it as open as possible to allow others to implement their own I/O in nodejs.
Cool!
Supporting HTTP-servers is however out of scope for now.
Fair
Files API
While the API for reading and writing a whole file at once can work for simple cases, having a streaming API is definitely something one eventually wants. On the other hand the 1.0 API you published has the obvious problem (that I guess you’re aware of) wrt writing to closed files.
Ideas:
One could imagine a withFile : Filename -> (FD x -> IO e a) -> IO e a API that automatically closes the file at the end, BUT the problem is that you would be able to “smuggle out” the file descriptor via return.
What if we don’t expose the file descriptor, but instead withFile : Filename -> ({read : Int -> IO e String, write : String -> IO e ()} -> IO e a) -> IO e a? Again, you can just return the read and andThen it out, so doesn’t work.
We could force a to be () and then one wouldn’t be able to smuggle out anything, but you could only use that for writing, not for reading… not great.
We could have an opaque type FileIO e a = FileIO (IO e a). Then withFile : Filename -> FileIO e a -> IO e a and then read : FileIO Err String, write : String -> FileIO Err () + monad operations for FileIO but then you can’t allow nesting withFile calls because we either get back to the smuggling problem or you have an API where only the inner file can be read/written to inside the nested call. Not flexible enough I think.
Uhm. You could restrict the return to be an IO Value where Value is the Json.Encode one but… meh, it’s unclean.
I’ll think a bit more about this.
CallJs
Javascript
Why not have the functions return the value (instead of calling send)? You avoid both double-send and no-send that way
Elm
Great!
Put it together
Simple, I like it!