flix
flix copied to clipboard
flix
Process API
I've got an interface to java.lang.Process and java.lang.ProcessBuilder but it is (currently) part of a bigger project and implemented in two layers.
The first layer is just a shim over the Java functions - Process is wrapped as a Flix enum (with a region, a la StringBuilder) and functions from java.lang.Process have a one-to-one Flix wrapper which only minor modifications to make them more Flix-like: Java functions that throw exceptions are wrapped with Result; functions that take or return Java collections should be wrapped to use Flix collections. Namespaces should correspond to the JDK namespaces.
I've done work on the effects signatures of the functions though they are probably out-of-date at the moment (no use of IO and likely inconsistent):
https://github.com/stephentetley/interop-base/blob/master/src/Interop/Lang/Process.flix https://github.com/stephentetley/interop-base/blob/master/src/Interop/Lang/ProcessBuilder.flix
The second layer makes them more palatable for Flix use: Java builders are wrapped with a monad so they can track errors, use sequence notation *> and possibly recover from errors; enums are wrapped as Flix enums so they support pattern matching; namespaces can be changed as some of the Java namespace names seem a bit of a legacy choice.
https://github.com/stephentetley/basis-base/blob/master/src/Basis/System/Process.flix https://github.com/stephentetley/basis-base/blob/master/src/Basis/System/ProcessBuilder.flix
[Note, at the time of writing Process has a design "error" that needs correcting and I wouldn't do now now as it "double wraps" the Java object due to Interop already wrapping it,]
I started work on this two-layer design as I was finding that I had to scrap a lot of code if I refactored libraries that were based on existing Java libraries. Now the "Interop" layer is basically a mechanical wrapper over the Java library and it doesn't get scrapped if I change my mind about the higher level code.
As a developer I like this flexibility but it doesn't really lead to small, discrete packages.
Thanks Stephen. This looks like a useful starting point.
I am not sure exactly what the right API is, but I would like something fairly simple (similar to the file API). I am not sure about the double layered approach nor the monadic builder, but I do like both process and processWithExitCode!
(I am trying to replace a Python script with Flix and its pretty nice, but lacking a way to run processes).
One thing; I think a process can use both stdout and stderr regardless of whether it returns success or failure.
I tried doing this by making the stdout etc channels, which seemed to be a nice interface.
