Long-term improvements to process WAS: process: Confusion about UseHandle handles being closed.

[Michael Snoyman]

In order to avoid confusion with the short-term discussion, I've renamed
the subject.

On Wed Nov 26 2014 at 10:16:09 AM Henning Thielemann <
lemming at henning-thielemann.de> wrote:

>
> On Wed, 26 Nov 2014, Michael Snoyman wrote:
>
> > So I'd argue that:
> >
> > 1. If we want to have a discussion about radically changing the API,
> let's have that discussion, but include
> > a very clear set of plans for migration. Henning: have you given that
> any thought?
>
> As I have written, a first step into the right direction could be setter
> functions for CreateProcess. Another step could be to export
> createProcess_, but give a warning in the documentation, that it is only a
> temporary solution. Alternatively you could add CreateProcess_, an opaque
> equivalent of CreateProcess, according setter functions, and
> createProcess_ which accepts CreateProcess_ as input. Or you generalize
> createProcess using a type class, such that it both accepts CreateProcess
> and CreateProcess_ as input. However this might make CreateProcess_ a long
> term solution. Alternatively, you could add a new module that provides an
> opaque CreateProcess record with setter functions and an according
> createProcess function.
>

These are good proposals. I think I most like the idea of an alternate
module, as it has a number of benefits:

1. We can immediately experiment with it in a separate package that has a
release cycle detached from process itself.
2. There's a clear migration path: at some point we deprecate the current
module in favor of the new module, and eventually replace the current
module with the new one.
3. We can do a fair amount of this in a very backwards-compatible manner.

One thing that I think it unclear is what the *goal* of the new module is.
I've seen three things mentioned:

1. Making the CreateProcess an abstract type/moving to setters.
2. Changing the behavior of createProcess to not automatically close
Handles (controlled by a leaveOpen field/setter).
3. Replace the underscore naming scheme with camel case.

I just want to make sure we're explicit about the goals we have here. Given
that we take things slowly enough to avoid migration headaches, I'm fully
in favor of (1), and if we're already going to be breaking the API with new
setters, I'm also behind (3). I'm tentatively in favor of (2) as I think
the current default is broken, but I'm concerned about introducing silent
breakage for people expecting the current behavior. That said, if we're
changing the API anyway, there likely won't be anything silent occurring.

Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20141126/36a64615/attachment.html>