Skip to content
This repository has been archived by the owner on Feb 3, 2022. It is now read-only.

Proposals case insensitive

Robert M. Lefkowitz edited this page Jun 23, 2014 · 2 revisions

PageOutline

Table of Contents

Proposal: Add the case-insensitive package to the Haskell Platform

This is a proposal for the 'case-insensitive' package to be included in the next major release of the Haskell platform.

Everyone is invited to review this proposal, following the standard procedure for proposing and reviewing packages.

Review comments should be sent to the libraries mailing list before Feb 10, which is the discussion deadline.

Credits

Proposal author: Gregory Collins

Package maintainer: Bas van Dijk

The following individuals contributed to the review process:

  * Gregory Collins
  * ...

Abstract

The `case-insensitive` package provides a case-insensitive wrapper around string types. (!ByteString, Text, String, etc.)

Documentation and tarball from the hackage page:

  http://hackage.haskell.org/package/case-insensitive

Development repo:

  https://github.com/basvandijk/case-insensitive

Rationale

Used whenever you need a case-insensitive comparison of two strings, usually as the key in an associative container. Does the right thing, i.e. stores a cached copy of the downcased string for comparisons only, while retaining the original string's casing. No current solution in the platform. Both the Snap Framework and Yesod have standardized on this package as the natural way of representing map keys in web programming, which are often case-insensitive (e.g.: http headers). In wide use: at the time of this writing has 48 reverse dependencies on Hackage.

Introduction to the API

The API is structured as follows:

  * `Data.CaseInsensitive`: contains the "CI s" datatype, which has instances for Eq, Ord, Read, Show, IsString, Monoid, etc. Also provides a "FoldCase" typeclass:
  * Functions to convert between strings and CI strings:

Design decisions

There's only one real decision: store the case-folded version or not? I think keeping it is best: it trades space for making the second and subsequent comparisons faster. Searching a `Map` could involve comparing the lookup key several times, so overall I think this is a win.

Open issues

Clone this wiki locally