soenkehahn / string-conversions

Simplifies dealing with different types for strings

string-conversions

This is a tiny library to convert between multiple string types in Haskell.

Alternatives

These are alternatives to string-conversions with slightly different designs:

• string-conv
• text-conversions

string-conversions's Issues

Monomorphic helpers for standard type conversions

Sometimes you need to write the always ambiguous cs . cs or use cs in a context where either side is polymorphic. For these cases it'd be nice to provide toStrictText, fromLazyByteString, etc to avoid the ambiguity/need to write type signatures.

I'd be happy to send a PR for this, do you think it's a good idea?

Provide strict conversion from ByteString to Text

Currently all ByteString -> Text conversions use Data.Text.Encoding.Error.lenientDecode. However, some users might prefer the UnicodeException be thrown instead.

So, I propose an alternative module Data.Conversions.String.Strict, which is a drop-in replacement for Data.Conversions.String, but uses Data.Text.Encoding.Error.strictDecode in the ByteString -> Text instances.

Failed to install

string-conversions-0.3.0.3 failed during the final install step. The exception
was:
/tmp/pkgConf-string-conversions-0.3.010971.3: hGetContents: invalid argument
(invalid byte sequence)

Ubuntu GNOME: 14.10
cabal: 1.20.0.2
ghc: 7.6.3

adding functions for explicit conversions

Does it make sense to add functions that have explicit types, with no typeclass?

stringToByteString :: String -> B.ByteString
stringToByteString = cs

stringToLazyByteString :: String -> BL.ByteString
stringToLazyByteString = cs

stringToText :: String -> T.Text
stringToText = cs

stringToLazyText :: String -> TL.Text
stringToLazyText = cs

textToString :: T.Text -> String
textToString = cs

...

Set up CI

We used to have CI based on travis, but that is now defunct. We should have CI. Ideally we would test:

• multiple ghc versions,
• multiple versions of the dependencies.

It seems that neither stack nor haskell/actions support ghc before 7.10. Should we drop support for those old ghc versions?

How does this compare to `string-conv`?

Feature request: add ByteString Builder

Please consider the idea of adding Builder from the bytestring package as one of the convertible strings.
Builder is part of the bytestring package from at least 2012 and has an IsString instance that parses the literal as UTF-8.
If you think this makes sense, I'll prepare a pull request.

Add travis builds

JSString support

@soenkehahn, hello :)

What do you think about adding JSString support?

-- from JSString

#ifdef __GHCJS__
import Data.JSString 
import Data.JSString.Text
#endif

....

#ifdef __GHCJS__
instance ConvertibleStrings JSString JSString where
    convertString = id

instance ConvertibleStrings JSString String where
    convertString = unpack'

instance ConvertibleStrings JSString StrictByteString where
    convertString = Data.Text.Encoding.encodeUtf8 . textFromJSString

instance ConvertibleStrings JSString LazyByteString where
    convertString = Data.Text.Lazy.Encoding.encodeUtf8 . lazyTextFromJSString

instance ConvertibleStrings JSString StrictText where
    convertString = textFromJSString

instance ConvertibleStrings JSString LazyText where
    convertString = lazyTextFromJSString
#endif

Move controversial instances to `Data.String.Conversions.Unsafe`?

translating bytestrings to text is not always well-defined, and there is no single best answer to what it means if a byte sequence is not defined as a character in UTF8. the choices this library makes are great in general, but i would like to be able to opt out of them.

this would require -Wno-orphans in the unsafe module, but i'm ok with that.

would you accept a PR for this?

(also, hi :-)

Put monomorphic functions into single parameter classes

An issue with the monomorphic functions in Data.String.Conversions.Monomorphic is they can't benefit from type defaulting when using the ExtendedDefaultRules extension, because ConvertibleStrings is a multiparameter class.

For example, the following will not compile without adding a type annotation on the string literal:

{-# LANGUAGE ExtendedDefaultRules #-}
{-# LANGUAGE OverloadedStrings    #-}
module Example where
import           Data.String.Conversions.Monomorphic
import           Data.Text (Text)

default(Text)

test :: IO ()
test = genericPutStrLn "test"

genericPutStrLn :: ConvertibleStrings a String => a -> IO ()
genericPutStrLn = putStrLn . toString

One way you could solve this is by putting each of these functions into single parameter classes, like this:

class (ConvertibleStrings a String) => ToString a where
    toString :: a -> String
    toString = cs

I'd be happy to send you a PR if you're happy with this kind of change.