Write CLI scripts in Elm (IO Monad)

[miniBill]

Files API

@albertdahlin

• 90% of the use cases for this package would be satisfied with just reading / writing whole files at once.

Yupp

@albertdahlin

• Writing to closed file descriptors are just one of all the problems you can have and need to watch out for. I am afraid that solving this without something like linear types would make API feel very complex. But of course I am open to suggestions and I will try to think in the lines the ideas you are describing.

I mean, most errors are not avoidable at the API level: write errors, permission errors, full filesystem, etc etc etc, can and need to be managed via Result/IO err, as you already do.

Writing to a closed fd feels like one of those problems that are be fixable with a Strict Enough API but:

1. not sure it actually exists in the Elm typesystem
2. not sure, if it exists, if it is nice enough to be worth using over a trivial withFile : (FD -> IO e a) -> IO e a
3. not sure, if it exists, if it’s flexible enough for all usecases

Something something records keeping tracks of open files via type level shenanigans, elm-css-ish style.

@albertdahlin

Call JS

I had that in the beginning but then I wanted to do async stuff, like

sleep: function(delay) {
    setTimeout(this.send, delay);
}

so I went with the more flexible approach of using callbacks. My thinking was that increased flexibility outweighs the increased risk. I’m open to other opinions or suggestions here though, maybe it is better to revert to returning values.
Is it maybe a better idea to have the functions return either a value or a Promise to allow both styles?

I think allowing either a value or a Promise should be flexible enough yet clean and avoid the issue.