Design of inputs

[jkarni]

As I mentioned in another issue, I was hoping to write a SystemdRunLimits Input, and a couple of questions came up:

• 1. Why is Input a class? All of the inputs are just representing ProcessConfiguration -> ProcessConfiguration functions. So they could just be combined via <> rather than anything fancier. E.g.:

run (cmd "mycmd" <> args ["arg1", "arg2"] <> stdinHandle hdl <> workingDir "some-dir")

Type inference would improve, the codebase would be simpler, and the types much easier to read.

• 2. Why is the command (and, I would think, also the arguments) not a "proper" argument to run (instead of an Input)? The disadvantages are that a clearly wrong use of run typechecks but throws a runtime error, and that other Inputs that may want to modify the command (e.g.: a Sudo Input), now have to be run in a very specific order which is opaque to the user (and, to me at least, it's harder to read or understand what each command is doing).

(Combined with 2 the above example would be:

run "mycmd" ["arg1", "arg2"] (stdinHandle hdl <> workingDir "some-dir")

And run :: (MonadIO m, Output a) => String -> [String] -> (ProcessConfig -> ProcessConfig) -> m a (though having a newtype for ProcessConfig -> ProcessConfig might be nice).

[soenkehahn]

Interesting. Personally I really like that cradle allows very short syntax for very simple invocations, e.g. run "tree" or run "ls" "." or run (words "ls -la ."). So I think for those your proposed interface would be worse. (I.e. run "tree" [] id, run "ls" ["."] id and run "ls" (words "-ls .") id.)

I definitely do somewhat like the ProcessConfig -> ProcessConfig idea. But again, that would make e.g. run ("tree" :: String) impossible.