Location of inlinePerformIO
Hi I was looking for the function inlinePerformIO, and was quite shocked when I found it in the module "Data.ByteString.Base". This is clearly entirely the wrong place for it to go, so could we get it moved before it has to remain in this totally non-logical place forever? Thanks Neil
On Mon, 2007-04-23 at 03:57 +0100, Neil Mitchell wrote:
I was looking for the function inlinePerformIO, and was quite shocked when I found it in the module "Data.ByteString.Base".
Or we could stop exporting the internal bytestring APIs at all.
This is clearly entirely the wrong place for it to go, so could we get it moved before it has to remain in this totally non-logical place forever?
If you want to propose that it become a standard function rather than an internal artifact of the bytestring lib then please do so. You might want to see if people agree on the name. At the same time there's the issue of locked vs. unlocked unsafePerformIO. Probably the best place for all three is the same module where unsafePerformIO currently lives, System.IO.Unsafe. Duncan
Duncan Coutts wrote:
Or we could stop exporting the internal bytestring APIs at all.
The ability to monkey around in the internals of bytestrings is very
handy, so it would be a shame to do that. I've grown quite fond of the
flexibility of the Pythonic approach to abstraction, which is by
consent, not decree.
On Sun, 2007-04-22 at 23:18 -0700, Bryan O'Sullivan wrote:
Duncan Coutts wrote:
Or we could stop exporting the internal bytestring APIs at all.
The ability to monkey around in the internals of bytestrings is very handy, so it would be a shame to do that.
Yes, I wasn't really being serious. We do deliberately export it all so people can build extensions, and there are already several such extensions. Of course we don't make the same api stability promises about the stuff in the .Base module. Duncan
Hi
Or we could stop exporting the internal bytestring APIs at all.
The ability to monkey around in the internals of bytestrings is very handy, so it would be a shame to do that.
Yes, I wasn't really being serious. We do deliberately export it all so people can build extensions, and there are already several such extensions. Of course we don't make the same api stability promises about the stuff in the .Base module.
Base is a bit too friendly a name, I would have expected Internal somewhere in the name if this library really is internal and has no guarantees. Plus there is no way for a library user to know that this Base thing is less stable than the rest of the base library, without going as far as the documentation - which I certainly didn't do. Thanks Neil
On Mon, 2007-04-23 at 10:48 +0100, Neil Mitchell wrote:
Of course we don't make the same api stability promises about the stuff in the .Base module.
Base is a bit too friendly a name, I would have expected Internal somewhere in the name if this library really is internal and has no guarantees.
True. I think I originally called it .Internal but it ended up as .Base in the end. I don't recall why. Possibly because that's how it's done for the Data.Array.* modules. Perhaps we should rename it, then everyone would know it's not stable ;-) even the name isn't stable!
Plus there is no way for a library user to know that this Base thing is less stable than the rest of the base library, without going as far as the documentation - which I certainly didn't do.
True, this can only be done by convention. I think .Internal naming is quite a good and obvious convention. The other strategy (as followed by Data.Array.Base) is to hide the module from haddock and thus also from hoogle, casual users would never stumble across it. Duncan
participants (4)
-
Bryan O'Sullivan -
Duncan Coutts -
Marc Weber -
Neil Mitchell