ANNOUNCE: GHC version 6.8.2

[Seth Kurtzberg]

On Sun, 16 Dec 2007 03:21:14 +0200
"Yitzchak Gale" <gale at sefer.org> wrote:

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

Why is it *not* trivial to wrap the function?  Regardless of whether you like the resulting solution, it is undeniably trivial to change the name of a function, create a new function with the (original) name, and have that new function call the original function, or call the original function based on some criteria, or implement different behavior entirely?  I did so here, and in roughly 10 minutes I verified that the behavior was exactly as one would expect.

Now, you may not approve of the resulting behavior, but that's an entirely separate question of whether something is, or isn't, trivial to implement.  I wrote a few lines of code; certainly seemed trivial to me.

I have a bit more sympathy for your assertion that changing the default behavior is not something to be done lightly, but if a small modification allows you to implement either the old or new behavior, the question becomes what should the default behavior be?  (Or perhaps the *default* behavior?  I've always found that the use of punctuation as a substitute for rational discussion is an attempt to be insulting rather than to enter into a discussion on the merits.

If you believe something is not trivial, then state your reasons.  If you don't have a reason, hold the bluster and the asterisks.

Seth

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


-- 
Seth Kurtzberg <seth at cql.com>