On Sun, 16 Dec 2007 03:21:14 +0200
"Yitzchak Gale" <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Reply via email to