Monomorphic helpers for standard type conversions about string-conversions

[bergmark]

Whoops hit submit to early, but updated it now.

[soenkehahn]

That's an idea.

So the from...-versions would be monomorphic only in their input and the to... versions in their output?

We also have type synonyms (LT, SBS, etc.) defined in the package. Would we also provide toLT, fromSBS, etc.?

I wonder if cluttering the namespace is something we should be worried about. What do you think about putting it in a separate module? E.g. Data.String.Conversions.Monomorphic? Then the new functions would be opt-in, but also less discoverable. On the other hand I don't expect many name clashes, since the functions with Strict or Lazy in their names is a string-conversions convention that I haven't seen much elsewhere.

When do we have to write cs . cs? Isn't ConvertibleStrings transitive? (I mean manually implemented to be transitive.)

[bergmark]

So the from...-versions would be monomorphic only in their input and the to... versions in their output?

Correct

We also have type synonyms (LT, SBS, etc.) defined in the package. Would we also provide toLT, fromSBS, etc.?

I personally prefer the expanded names and always use them, but it makes sense to include these aliases since the short names exist elsewhere.

I wonder if cluttering the namespace is something we should be worried about.

Like you say, I don't expect clashes either. But these functions will also be used far less frequently assuming you use cs as much as possible. I don't have a preference here.

When do we have to write cs . cs?

If you have two unrelated stringy types you may not have defined the conversions between them because there is no natural place for it. I sometimes have e.g. ConvertibleStrings A StrictText and ConvertibleStrings StrictText B and then I need to use cs . (id :: B -> StrictText) . cs which would then be cs . toStrictText or fromStrictText . cs instead.

[soenkehahn]

Regarding the last question: Ah, I didn't consider writing your own instances of ConvertibleStrings. I guess if we aim at making this class extensible we could come up with a better design overall. But that's a different story.

I would propose to put the new functions into a different module for now. We can move them to the main module later if we realize that would be better. (My suggestion was Data.String.Conversions.Monomorphic but feel free to come up with something better.)

If you come up with a PR that would be great.

The PVP would allow to get away with a minor version bump (i.e. 0.3.1) but I think I would prefer 0.4 if you don't mind.

And to finally answer your initial question: Yes, I think it's a good idea. :) It's a fairly seldom use-case but I think I'd end up using these functions.

[soenkehahn]

Merged and released to hackage: http://hackage.haskell.org/package/string-conversions-0.4

Thanks very much.

[bergmark]

Cheers!