u.stenzel at web.de
Fri Nov 24 20:34:21 EST 2006
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)
> 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.
Lebensmittelskandal: Gene im Mais entdeckt!
(angeblich eine Schlagzeile aus der BILD)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: Digital signature
Url : http://www.haskell.org/pipermail/libraries/attachments/20061125/67a706c5/attachment.bin
More information about the Libraries