[GHC] #12494: Implementation of setenv in base incorrectly claims empty environment variable not supported on Windows

[GHC]

#12494: Implementation of setenv in base incorrectly claims empty environment
variable not supported on Windows
-------------------------------------+-------------------------------------
        Reporter:  ezyang            |                Owner:
            Type:  bug               |               Status:  new
        Priority:  normal            |            Milestone:
       Component:  libraries/base    |              Version:  8.0.1
      Resolution:                    |             Keywords:
Operating System:  Unknown/Multiple  |         Architecture:
                                     |  Unknown/Multiple
 Type of failure:  None/Unknown      |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by hvr):

 It's maybe worth pointing out that `setEnv` has been introduced with
 base-4.7.0.0 (via #7427 &
 https://mail.haskell.org/pipermail/libraries/2012-October/018560.html)

 Replying to [comment:1 bergmark]:
 > I think it's important to make sure that there is some kind of
 > mention/warning to let users know that their code changed because of
 > this.

 On the one hand, we use semantic versioning to signal this very kind of
 semantic API changes; on the other hand, `base` makes inflationary use of
 major version increments due to its large API surface, so that we end up
 with a sub-optimal signal/noise ratio, resulting in API consumers not
 paying attention anymore... :-(



 > I see three ways to accomplish this:

 > * Deprecate `setEnv` and add the new function under a new name

 I think that'd be the safest approach given the circumstances, and it
 would side-step all the BC issues; the only downside is having to figure
 out a good name for the new function... :-)

 > * Add a warning pragma for one release cycle and then make the change

 That's still gonna result in silent failures for users which don't pay
 attention to semantic version signalling nor compile warnings or which
 happen to skip that one release cycle which warned about it.

 > * Change the parameter to only accept non-empty strings

 how?

 > What about staying compatible with several versions of base? Should
 users never use an empty string (effectively banning the use of empty env
 vars), and/or should we refer users to the base-compat package?

 In hindsight, maybe we should have thrown an exception for situations
 where `setEnv` would act like `unsetEnv`, or unify `setEnv` with
 `unsetEnv` by using `:: String -> Maybe String -> IO ()`...

--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12494#comment:2>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler