ANNOUNCE: GHC version 6.8.2

[Yitzchak Gale]

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...

Thanks,
Yitz