Add basic parallelism/batching support

ianmackenzie / elm-script

Experimental command-line scripting for Elm

34 stars 4 forks source link

Add basic parallelism/batching support #6

Open ianmackenzie opened 6 years ago

ianmackenzie commented 6 years ago

[ ] NetworkConnection.sendAll : List (Request a) -> Script Error (List a)
[ ] File.readAll : List (File (Read p)) -> Script Error (List String)
[ ] File.writeAll : List ( File (Write p), String ) -> Script Error ()
[ ] Shell.executeAll : List String -> Shell -> Script Error (List String)

CharlonTank commented 4 years ago

That project is awesome! Really looking forward to see how far elm scripting can go!

ianmackenzie commented 4 years ago

Glad you like it! I wouldn't get too excited about too much parallelism support, though...the way things are implemented internally is pretty fundamentally serial. So it might be possible to implement a few very specific parallel things like described here, but probably not much beyond that. Was there anything in particular you were thinking of doing?

CharlonTank commented 4 years ago

Yeah I know, I’m just excited haha. I’m mostly scripting in ruby, but I was searching but a more rigorous way of scripting. I’m creating a elm+rails+graphql generator using dillonkearns/elm-graphql and Poilon/rails-graphql-api. I know that after a while, this kind of generator can be outdated pretty fast and needs updates pretty consistently. Thank’s to its design, elm could help to be able to be sure to handle every possibilities and would be easier to create updates. About the parallelism, I need to run a server and at the same run the elm-graphql script in another directory and then kill the server.

ianmackenzie commented 4 years ago

Hmm, that would be tricky - I haven't even thought about things like explicitly killing processes, let alone doing that when you have multiple processes in parallel. I was brainstorming a little while ago trying to think if there was a way to incorporate something like TEA into elm-script where you could temporarily switch into a message-model-update mode instead of basically just task composition, but I haven't explored it that much - I'm frankly not even sure if it's possible.