Closed AshleyYakeley closed 2 years ago
Hmm, given that we have WholeRef Text <: TextRef
and not TextRef <: WholeRef Text
, is it reasonable to have an implied ByteStringRef <: WholeRef Literal
?
The round-trip TextRef -> WholeRef Text -> TextRef
loses information, while WholeRef Text -> TextRef -> WholeRef Text
does not.
Likewise, the round-trip ByteStringRef -> WholeRef ByteString -> ByteStringRef
loses information, while WholeRef ByteString -> ByteStringRef -> WholeRef ByteString
does not.
Consider a ByteStringRef
to a really big file. Converting it to a WholeRef ByteString
is fine, but reading or writing that would be a problem.
In the existing case, if you have a WholeRef that was explicitly constructed from a TextRef, then that is also a TextRef, but a different one.
In the alternate case, if you have a TextRef that was explicitly constructed from a WholeRef, then that is also a WholeRef, and the same one (that is, functions equivalently).
Currently TextRef
s cannot be created directly, only WholeRef
s on memory. And these will reflect whole changes, not by text section.
Done.
Maybe
FileRef <: WholeRef Literal
Going to assume "This call does no blocking I/O." means a GIO call can be done under
unsafePerformIO
.