ANNOUNCE: GHC version 6.8.2

[Claus Reinke]

> Sorry, it's not me who invented it. There are many tools (from Unix
> origin) that use HOME in Windows if defined. In fact, let me think...
> oh, yeah, I remember, GHCi itself used it until this very same
> morning... :)

yes, but ghc/ghci switched from unix-emulated to windows-native 
long ago - since then, they've tried to behave more like other 
windows programs, with no built-in knowledge of unixisms.

now, imagine the surprise when, in your %HOME%/.ghci, you

    do home <- System.Directory.getHomeDirectory
         System.Directory.getDirectoryContents home

and the script ghci claims to be executing isn't even there!-)

or imagine switching between console (no HOME) and bash 
(inherited HOME) ghci: now you see .ghci, now you don't..

> No. I don't "take care" of the Windows-provided home dir, because it
> is mostly used *automatically* by programs that write their setting
> files to it. It is rare indeed the Windows program that requires the
> user to go to %HOMEDRIVE%%HOMEPATH% and edit a file there.

it would be useful if ghci could read/write its current settings
(perhaps split into a .cabal file with settings and a .ghci file
with scripts/definitions). but you wouldn't want it to ovewrite 
your old .ghci, and some of us would still like to know where 
it ends up so that we can check and edit it manually, or copy 
it elsewhere;-)
 
> Thanks, I'll use that. However, I still think that breaking
> back-compatibility is Not a Good Idea.

in general, i would agree.

perhaps my fault for filing that ticket in absolutes, which led
to a fix replacing, rather than augmenting, the old, erroneous
behaviour. but a HOME-overrides-HOMEPATH approach,
while backwards-compatible, suffers from the same inconsistency
issues as the old please-define-HOME-yourself approach
(even worse: you might get different versions of .ghci).

so, one would have to implement the overriding approach
consistently (including getHomeDirectory), and issue warnings 
and documentation to make users aware of any such overriding 
taking place (and should it be optional, to avoid deviating from
the platform standard?).. as a short-term deprecation workaround 
for ghc-6.8.x, that makes some sense, but in the long-term?

claus