Expose internals

[typedrat]

Fixes #118.

This exposes what you need to write your own backend, as shown by haskeline-brick. Please squash this if it gets merged!

[bjartur]

Exposing these modules only under System.Console.Haskeline.Internal implies that they have an unstable API that can be expected to break compatibility even between minor versions of Haskeline. Is this API not stable enough to retain compatibility for most or all of this functionality across minor versions, and simply bump a major version if any of these change later?

[typedrat]

I don’t know how stable they are, but this sort of thing is Internal in purpose at least, since it should only be used by people who know what they’re doing.

[romanofski]

I've actually came back here to see this pull request to my surprise. I've tested this pull request and it would totally help outsiders to use the API in order to write a widget like the Brick <-> Haskeline widget. Would it be possible to merge this and if not give a hint what would need to happen to expose some of the internals like in this pull request?

[frasertweedale]

@judah ping. What do you think about this PR? It would be very helpful for purebred and other brick-based terminal programs.

[frasertweedale]

Ping @judah, @bgamari. When able, please review and consider merging this PR.

[4eUeP]

Any updates? Ping @judah @bgamari

[4eUeP]

Also maybe we can add a warning notice like the ByteString package's Data.ByteString.Internal:

-- A module containing semi-public 'ByteString' internals. This exposes the
-- 'ByteString' representation and low level construction functions. As such
-- all the functions in this module are unsafe. The API is also not stable.