basvandijk / case-insensitive Goto Github PK

See http://hackage.haskell.org/package/hashable

This is something we're going to need at some point for Snap.

I just spent quite a while digging, first through the source, finally ending up at http://hackage.haskell.org/package/text-1.2.4.0/docs/Data-Text.html#v:toCaseFold while trying to figure out what the result of toCaseFold is actually like.

It would probably be useful to others to do one or more of the following.

• add a sentence in the general parts of the documentation noting that case folding is mostly but not quite lowercasing (perhaps with a link to a more detailed explanation)
• in the documentation of foldedCase, explicitly state that the result depends on the FoldCase instance (instead of just a "see also")
• document the behaviour of the individual FoldCase instances

import qualified Data.CaseInsensitive as CI
import qualified Data.Char as Char

main :: IO ()
main = do
  print ((Char.toLower <$> ("\5042" :: String)) == "\43906")
  print ((CI.foldCase (CI.mk ("\5042" :: String))) == "\43906")

{-
*Main> :main
True
False
-}

Thanks to QuickCheck! :)

The current version of this library compiles fine with all major GHC versions except 7.2.2: http://hydra.cryp.to/build/105520/log/raw. This is probably trivial to fix, right?

It's debatable whether it's a true law of Eq (opinions varied in #haskell), but I'd say it certainly is an expectation that if a == b then f a == f b. The original function breaks this for the CI type.

This is somewhat ironic (was it intentional??) but if I clone this on a case-insensitive filesystem, the Data and data folders overlap. This is usually not the end of the world, but it breaks hashing when we use this package in nix and similar hash-centric systems. Can the folder structure be rearranged a bit?

/cc @ryantrinkle @jwiegley

Constructing a CI ByteString will ask for pinned memory, but usually the ByteString is short so this behavior not only add overhead but contribute to heap fragment. I think we can do better here, any idea?

@basvandijk, what's your opinion. Could we add it into case-insensitive, or should I put it into my binary-orphans package?

LTS 8.x has HUnit 1.5, but this package requires HUnit >=1.2.2 && <1.4. Would it be possible to extend support for later versions of HUnit?

Because the constructor is not exported it's impossible to define instances out of your library.

If you don't want to derive it, at least, please export the constructors.

The base version dependency in case-insensitive.cabal is too restrictive, and doesn't allow building on GHC 7.2.x.

Could you please relax the version constraint? Thanks!

I'm trying to build an app to deploy to Debian stable on production, and this is the version of GHC it has. Removing the NoImplicitPrelude extension makes the library work again (it complains about no fromInteger and >>)

GHC 8.0.1 was released in May 2016 https://www.haskell.org/ghc/blog/20160521-ghc-8.0.1-released.html , and I'd guess many have moved to later versions since.

By supporting GHC >= 8 only, we could get rid of the semigroups dependency, too.