Closed jonascarpay closed 3 years ago
Unfortunately this implementation would make text interpolation much slower.
I pushed a version that leaves the original internal representation intact. Looking at the text
source, fromString . unpack
should fuse, so the actual overhead should be basically zero. I'm not sure how to best benchmark and verify that, though.
That would result in the splices still requiring to be Text
regardless of the type you wish to produce.
My plan for this library is to have specialised quoters, which would splice the same types as they produce. I.e., a ByteString
-producing quoter will expect its parameters to be ByteString
as well. I also plan to make it more efficient by utilising specialised builders and possibly exposing builders for them as well.
Unfortunately accepting this PR would make the package go in a direction, which I didn't intend. I also can't find a compelling reason to do so.
Alright, that makes sense
This is one way to address #17, it simply generalizes the resulting value to
IsString a => a
. This is mostly an experiment to see if it was possible, and it seems to work out nicely, but maybe you have a good reason for not wanting to useIsString
. Either way, please let me know.If you do think this is a good idea, there's probably some cleanup to do before merging, like removing dependencies and/or not using
String
as the intermediate representation.