[Haskell-cafe] Haskell SQL backends: How is data handed over?

Olaf Klinke olf at aatal-apotheke.de
Thu Aug 11 19:36:50 UTC 2022

> My observation about the "scientific" package is also relevant here:
> most DBMSes have a different notion of "number" than most programming
> languages, so unless there is specifically a binary number field type
> it is probably necessary to send it as a string of some variety. The
> "scientific" package abstracts over this for Haskell.

You mean that formatting a Scientific number as String is more
efficient than formatting an Integer/Double in its usual
representation? How about parsing? In most parsing libraries I've seen
[1,2,3] the following code transforms a string of digits to an integer.

import Data.Char (ord)
import Data.Foldable (foldl')

-- The parser ensures only digit Chars
-- are passed to this function. 
fromDigit :: Num a => Char -> a
fromDigit = let 
    z = ord '0' 
    in \digit -> fromIntegral (ord digit - z)

appendDigit :: Num a => a -> Char -> a
appendDigit x d = 10 * x + fromDigit d

digitsToNum :: Num a => [Char] -> a
digitsToNum = foldl' appendDigit 0

If in addition to 'show' the function prependDigit (and its foldr
cousin for digits behind the floating point) were particularly
efficient for Scientific [*], that would indeed make a strong case for
using Scientific in parsing and (SQL-)database applications. 


[1] https://hackage.haskell.org/package/parsec-
[2] https://hackage.haskell.org/package/megaparsec-9.2.1/docs/src/Text.Megaparsec.Char.Lexer.html#decimal_
[3] https://hackage.haskell.org/package/attoparsec-0.14.4/docs/src/Data.Attoparsec.Text.html#decimal
[*] This seems not to be the case currently: The Num instance is implemented as 

 Scientific c1 e1 * Scientific c2 e2 =
        Scientific (c1 * c2) (e1 + e2)

Would it be a bad idea to add special cases for numbers of the form 
Scientific 1 e? It penalizes all multiplications with a pattern match. 

More information about the Haskell-Cafe mailing list