Add `string` besides `text`?

nikita-volkov / neat-interpolation

A quasiquoter for neat and simple multiline text interpolation

http://hackage.haskell.org/package/neat-interpolation

MIT License

55 stars 16 forks source link

Add `string` besides `text`? #17

Open martijnbastiaan opened 6 years ago

martijnbastiaan commented 6 years ago

I'm often faced with situations where I want to format a bunch of Strings into a new multiline String. This results in a lot of Text.unpack and Text.pack when using neat-interpolation. Could we re-add string like in the first versions of neat-interprolation? Of course, without throwing away text.

I'm willing to make a PR.

CMCDragonkai commented 6 years ago

I would really like this as well. Strings are just useful for debugging sometimes.

nikita-volkov commented 6 years ago

I'm willing to accept a PR. Sorry somehow missed the issue before

sjakobi commented 4 years ago

Now that there are trimming and untrimming, and text is just an alias for trimming, what should be added and how should the additions be named?

How about adding trimmingString, untrimmingString and string?

nikita-volkov commented 4 years ago

How about a separate public module for String with functions named the same?

sjakobi commented 4 years ago

Sounds good to me! :)

sjakobi commented 4 years ago

How about a separate public module for String with functions named the same?

Maybe NeatInterpolation.String should export a string quasiquoter though instead of text.

nikita-volkov commented 4 years ago

I'm thinking of the following changes:

Add NeatInterpolation.String module with trimming and untrimming.
Add NeatInterpolation.Text module with trimming and untrimming.
Add string to the NeatInterpolation module.
Mark trimming and untrimming in the NeatInterpolation module as deprecated.

Thus we'll be able to establish clear purposes for modules. The root one will be about exporting default quoters determined by the type they produce. The nested modules will be about providing different flavours of quoters dedicated to the type in title. We'll also be able to achieve all that without backward compatibility conflicts.

I'm just expressing the ideas for the discussion. What do you think?

martijnbastiaan commented 4 years ago

I totally missed your comment after I opened this issue, until now. Your proposal sounds good to me! :)

sjakobi commented 4 years ago

@nikita-volkov Yeah that sounds good to me.

Indeed, backward compatibility is important to me, but that seems to be well addressed in your proposal. :)