ANNOUNCE: GHC version 6.8.2
claus.reinke at talk21.com
Thu Dec 13 12:03:38 EST 2007
> 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
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
> 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?
More information about the Glasgow-haskell-users