`Bytes` and `mkBytes` needs to be reconsidered
Ryan alerted me to the dubious nature of Bytes and BytesPrimL in TemplateHaskell.
Bytes contains a ForeignPtr. If someone makes this ForeignPtr in another package then when the user tries to run the splice in their program, surely they will dereference this pointer and it will point to nothing?
The intention behind the API is that the ForeignPtr is created in the same splice (on the host) as the Bytes value but this is not enforced in anyway.
To do this, probably a new effect should be added to Q rather than this stuff with directly manipulating a ForeignPtr.
It also has to be considered how to make Bytes work with Lift. The current instance is wrong for the same reason.
Edited by Matthew Pickering