ANNOUNCE: GHC version 6.8.2
gale at sefer.org
Sat Dec 15 20:21:14 EST 2007
Removing support for %HOME% has suddenly broken many
programs. If people don't like it, we can consider
deprecating it in some future version of GHC, but for now
it should put back. I would say it is quite ironic that some
people are arguing against this by saying that it will lead
to more bug reports.
It is *not* "trivial to wrap the function in question", and
it is not "more correct".
The current behavior is not more WIndows native - it is
arguably much worse. The %HOMEPATH% variable
should definitely not be used. The folder that it points
to is not a "home directory" and should not be used
that way. But if there is no other way to provide a value
for getHomeDirectory, I guess that is still better than
throwing a run-time exception, but at least obtain
the path in a somewhat Windows-friendly way by
using the API properly.
It is just not true that using %HOME% creates
problems. This is a widespread convention, in
active use. Admittedly ad-hoc, but it works.
Does anyone know of even a single
incident in which this created a problem?
Better native Windows integration is definitely an
important goal. The whole idea of a ".ghci"
file is very Unixy, for example. There is a
lot of work to be done in this direction. Pulling
the rug out from under %HOME% without
providing a reasonable alternative is not the
way to begin.
By "reasonable alternative", I mean a way that
users can configure GHC's notion of
"home directory" at run-time on Windows.
Truthfully, I don't think this should be the first
priority for better Windows integration. Wouldn't
our time be better spent on Visual Studio integration
and WinAPI support? Not to mention .NET...
More information about the Glasgow-haskell-users