typeclasses/ascii

The ASCII character set and encoding

To build and test with all supported compiler versions:

nix build .#testConfigurations.all --no-link

ascii's Issues

Documentation on monomorphic conversion functions

For all the monomorphic conversion functions that are just specializations of a polymorphic function, the haddock comment should include a link to the polymorphic version.

Remove data-ascii

@frasertweedale (snoyberg/ascii#6 (comment))

I note you re-export Data.ASCII presumably for backwards compat, having moved the old ascii package to data-ascii. But data-ascii is still marked as deprecated, so what is the intention going forward with these modules?

GHC 9.0 support

I've gone ahead and released versions that support base 4.15 (GHC 9.0), but CI is currently failing because dependencies hashable 1.3 and bytestring-0.11 do not yet support it. When they do, we should re-run CI to make sure it actually builds, and unmark GHC 9.0.1 as a continue-on-error build.

Support GHC 9.4

Consider using Data.ByteString.Encodings.isAscii for checking ByteString asciiness

https://hackage.haskell.org/package/bytestring-encodings-0.2.0.2/docs/Data-ByteString-Encodings.html#v:isAscii

This function is about 8x faster than a call to Data.ByteString.all (< 128), because instead of checking one Word8 at a time, it can check eight Word8s at a time, using a cool bit twiddling optimisation. There is a test suite and benchmark suite to confirm that it both works and is that fast.

Support case-insensitive comparisons

Previously brought up by @frasertweedale here, where the request was to add a FoldCase instance (I presume from the case-insensitive package).

I'm inclined to discourage use of the CI type; it bothers me a lot that CI has a field that == doesn't consider in its equality test, I think it's an abuse of Eq. As the docs say:

(==) is customarily expected to implement an equivalence relationship where two values comparing equal are indistinguishable by "public" functions

And I think that going against this expectation can lead us to unhappy places.

I was considering adding another package called ascii-subset, whose purpose would be to provide types like "case-insensitive character". (I can think of a handful of ways to write this: to define a new type for each ASCII subset we care to consider, to define a 128-constructor GADT with some phantom type parameters that allow you to narrow the type, or to define various smaller types like ControlCharacter, Digit, CapitalLetter, SmallLetter etc. and then build up various ASCII subsets out of those. But, setting aside these details for the moment...) What do you think, would having "case-insensitive char" and "case-insensitive string" types be helpful, or is there a particular need for the CI approach that preserves the original case?

Documentation on all Lift instances

https://hackage.haskell.org/package/ascii/docs/ASCII.html#t:Lift

Some Lift instances have a comment, it would be nice if they all did.

hedgehog-1.2 is out of bounds

commercialhaskell/stackage#6698