
On 04/11/2009 11:56, Felipe Lessa wrote:
On Wed, Nov 4, 2009 at 8:00 AM, Simon Marlow
wrote: the property doesn't hold any more because dropFileName "foo" == "./". So I worked around cases like this with an internal version of splitFileName with the old semantics. This isn't a big problem - it just means we get to keep some of these nice simple equality properties, which are arguably wrong anyway, and fewer "./" prefixes will show up to surprise users.
If FilePath was a newtype, could its Eq instance not distinguish between "foo" and "./foo"? Note that we must distinguish "./foo/../" of "./" because this may not be valid ("foo" does not exist) or may be something different ("foo" is a symlink). This Eq instance would just eat all superfluous "./".
Yes, but FilePath is not a newtype, and it would break a lot of code to make it one. That is not part of this proposal. Just in case this isn't clear: like most people, I (still) believe FilePath should be an abstract type, but that's a matter for separate discussion. Right now I'm concerned about fixing a small problem with the current API. Cheers, Simon