# Proposal: Make digitToInt and intToDigit work up to base 36

Dan Burton danburton.email at gmail.com
Fri Jun 29 23:44:47 CEST 2012

```Hi List, Twan,

I would argue the opposite: the function name indicates that it will
transform a *digit* into an *int*. Digits in most cases any developer will
deal with are `elem` [0 .. 9], so it would make more sense to produce an
error for anything else, and provide a *separate *function, hexDigitToInt with
the hex reading behavior. (This would be a silently breaking change, so I'd
think carefully before seriously proposing this.) Twan is suggesting what
amounts to englishAlphaOrDigitToInt; is there any particular reason to give
the English alphabet special treatment in this case? I could instead
imagine the usefulness of alphaPos :: Alphabet ->  Char ->  Int which
indicates what position a given character is in its alphabet (alphaPos
English 'a' == 1, for instance), and its inverse alphaFromPos ::  Alphabet
-> Int -> Char.

But if I am trying to read a number from a String, I would almost certainly
want it to fail on encountering any non-hex digit, rather than producing a
strange number.

--
Dan Burton

On Fri, Jun 29, 2012 at 2:59 PM, Twan van Laarhoven <twanvl at gmail.com>wrote:

> Hello List,
>
>
> I propose to change the functions digitToInt and intToDigit in Data.Char to
>
> digitToInt :: Char -> Int
> digitToInt c
>  | isDigit c            =  ord c - ord '0'
>  | c >= 'a' && c <= 'z' =  ord c - ord 'a' + 10
>  | c >= 'A' && c <= 'Z' =  ord c - ord 'A' + 10
>  | otherwise            =  error ("Char.digitToInt: not a digit " ++ show
> c)
>
> intToDigit :: Int -> Char
> intToDigit i
>  | i >= 0  && i <=  9   =  toEnum (fromEnum '0' + i)
>  | i >= 10 && i <= 35   =  toEnum (fromEnum 'a' + i - 10)
>  | otherwise            =  error "Char.intToDigit: not a digit"
>
> (and equivalently for the Ghc specialized version in Data.Show)
>
> Right now the functions only work for c <= 'f' and i <= 15, i.e. only up
> to hexadecimal. But I can think of no reason why that should be the case.
>
> There is the problem of compatibility with the Haskell98/2010 report. But
> since this proposed change only reduces the number of cases that are
> errors, I think that is not a big concern.
>
>
> Discussion period: 2 weeks, deadline July 13.
>
>
> Twan
>
> ______________________________**_________________
> Libraries mailing list