On Jan 6, 2015 9:39 PM, "Erik Hesselink" <hesselink@gmail.com> wrote:

Does cabal rely on this behavior?

Erik

On Tue, Jan 6, 2015 at 9:37 PM, Johan Tibell <johan.tibell@gmail.com> wrote:
> Who volunteers to fix the breakages in Cabal and add all the needed CPP?
>
> On Tue, Jan 6, 2015 at 2:45 PM, David Feuer <david.feuer@gmail.com> wrote:
>>
>> This seems reasonable, but if we have a deprecation cycle, the old name
>> should (temporarily) be a synonym for the new one, and the deprecation
>> warning should indicate that code intended to work with older versions needs
>> to be audited.
>>
>> On Jan 6, 2015 2:40 PM, "Gabriel Gonzalez" <gabriel439@gmail.com> wrote:
>>>
>>> I think it's safer to remove the old function altogether (perhaps after
>>> one deprecation cycle) and provide a new one under a different name, rather
>>> than modify it in place.
>>>
>>> Modifying it in place risks the behavior that others mentioned where your
>>> program is unsafe to compile against older library versions.  Yes, the user
>>> could explicitly enforce that by putting a lower bound on the library, but
>>> most users won't even realize that they need to do that.
>>>
>>>
>>> On 1/6/15, 11:37 AM, Edward Kmett wrote:
>>>
>>> I'm +1 for fixing this, in place, on the current function.
>>>
>>> The specification we have here is doing a very very bad thing and needs
>>> to be fixed, not slavishly copied forward because someone sometime once made
>>> a mistake.
>>>
>>> The current behavior grievously violates the expectations of anyone who
>>> would be in a situation to go and reach for it and has any prior experience
>>> with any other such tool.
>>>
>>> -Edward
>>>
>>>
>>>
>>> On Tue, Jan 6, 2015 at 11:14 AM, Malcolm Wallace <malcolm.wallace@me.com>
>>> wrote:
>>>>
>>>>
>>>> On 6 Jan 2015, at 14:59, Bardur Arantsson wrote:
>>>>
>>>> > On 2015-01-06 14:57, Mike Meyer wrote:
>>>> >> On Tue, Jan 6, 2015 at 7:48 AM, Johan Tibell <johan.tibell@gmail.com>
>>>> >> wrote:
>>>> >>
>>>> >>> This is not a bugfix. A bug is failing to follow the functions
>>>> >>> specification, which *does* include following symlinks.
>>>> >>>
>>>> >>
>>>> >> It's a bug in the design, not the code.
>>>>
>>>> > Because *nobody* wants to follow symlinks when doing "rm -rf". Even if
>>>> > they think they do, they *really* don't.
>>>>
>>>> I agree 100%.  Even time I use this function, I worry briefly about
>>>> whether it follows symlinks, then think to myself "no, no-one would be so
>>>> stupid to implement that deliberately in a publically available API".  So it
>>>> was a real shock to discover in this thread that I was wrong, and
>>>> furthermore that the function is documented as doing the wrong thing.  We
>>>> should fix both spec and implementation, as soon as possible.
>>>>
>>>> Regards,
>>>>     Malcolm
>>>> _______________________________________________
>>>> Libraries mailing list
>>>> Libraries@haskell.org
>>>> http://www.haskell.org/mailman/listinfo/libraries
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Libraries mailing list
>>> Libraries@haskell.org
>>> http://www.haskell.org/mailman/listinfo/libraries
>>>
>>>
>>>
>>> _______________________________________________
>>> Libraries mailing list
>>> Libraries@haskell.org
>>> http://www.haskell.org/mailman/listinfo/libraries
>>>
>>
>> _______________________________________________
>> Libraries mailing list
>> Libraries@haskell.org
>> http://www.haskell.org/mailman/listinfo/libraries
>>
>
>
> _______________________________________________
> Libraries mailing list
> Libraries@haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>