Hi Seth.
Sorry, my asterisks were not at all meant to be a flame.
Please accept my sincere apologies if it appeared that way.
I wrote:
>> It is *not* "trivial to wrap the function in question", and
>> it is not "more correct".
Seth Kurtzberg wrote:
> Why is it *not* trivial to wrap the function?
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
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 repo
On Sat, 15 Dec 2007 21:31:25 +0300
Bulat Ziganshin <[EMAIL PROTECTED]> wrote:
> Hello Juanma,
>
> Saturday, December 15, 2007, 4:24:43 AM, you wrote:
>
> > Because what Yitzchak Gale proposed and I seconded does not mean that
> > getHomeDirectory will not "follow the Windows API", unless very
>
Hello Juanma,
Saturday, December 15, 2007, 4:24:43 AM, you wrote:
> Because what Yitzchak Gale proposed and I seconded does not mean that
> getHomeDirectory will not "follow the Windows API", unless very
> specifically requested by setting HOME.
i'm against this idea. one can setup HOME for some
Hi,
I also agree with Duncan---basic library functions should provide a
mechanism and not try to enforce a policy. Applications that are
interested in supporting the %HOME% convention can easily do so by
defining a function that first checks for that environment variable,
and only if it is not s
