Bulat Ziganshin wrote:
what i mean here: now we have, for example
splitToBaseExt :: FilePath -> (FilePath,FilePath)
the same function, in polymorphic way:
splitToBaseExt :: FilePathClass fp => fp -> (fp,fp) and instance FilePathClass FilePath instance FilePathClass UTF8ByteString instance FilePathClass UTF16ByteString
Let me try to put this in a diplomatic way: No.
this change in interface would be indistinguishable for 99% of us.
Err, no. 99% of us _don't_ write flawless programs. With every overloaded symbol you get worse error messages. Have you ever used C++? Ever got a screenful of completely incomprehensible gobbledygook because you forgot a namespace qualification somewhere? Go ahead with all these FooLike and BarAble classes and you get the same from Haskell (and then some, including exponential runtime of the type checker). Pathnames are short strings. No need to optimize for performance, instead optimize for clarity. An algebraic datatype reflecting the algebra of filenames would likely be even more clear, but defining a type class just to support different encodings is definitely overengineering and very likely a bad idea. Remember, this ends with std::basic_ios< char, std::char_traits<char> > or worse. -Udo -- Lebensmittelskandal: Gene im Mais entdeckt! (angeblich eine Schlagzeile aus der BILD)