portability of Data.ByteString.Lazy

Data.ByteString.Lazy defines ByteString as a type synonym, and then uses that in instances, which isn't permitted by Haskell 98. How about defining a newtype ByteString in Data.ByteString.Lazy.Base instead?

Ross Paterson
Data.ByteString.Lazy defines ByteString as a type synonym, and then uses that in instances, which isn't permitted by Haskell 98. How about defining a newtype ByteString in Data.ByteString.Lazy.Base instead?
Here is another portability problem in Data.ByteString.Lazy: Constructor :*: used at 590:22-590:24 is not defined. Regards, Malcolm

Malcolm.Wallace:
Ross Paterson
wrote: Data.ByteString.Lazy defines ByteString as a type synonym, and then uses that in instances, which isn't permitted by Haskell 98. How about defining a newtype ByteString in Data.ByteString.Lazy.Base instead?
Here is another portability problem in Data.ByteString.Lazy:
Constructor :*: used at 590:22-590:24 is not defined.
Hmm, strange. It's defined in Data.ByteString.Fusion: infixl 2 :*: -- |Strict pair data PairS a b = !a :*: !b deriving (Eq,Ord,Show) and imported via: import Data.ByteString.Fusion (PairS(..),loopL) -- Don

dons@cse.unsw.edu.au (Donald Bruce Stewart) wrote:
Here is another portability problem in Data.ByteString.Lazy:
Constructor :*: used at 590:22-590:24 is not defined.
It's defined in Data.ByteString.Fusion: infixl 2 :*: -- |Strict pair data PairS a b = !a :*: !b deriving (Eq,Ord,Show)
I did not find it with a quick grep, but yes, there it is. So this indicates a bug in nhc98/yhc's import resolution, not in your library... Regards, Malcolm

Malcolm.Wallace:
dons@cse.unsw.edu.au (Donald Bruce Stewart) wrote:
Here is another portability problem in Data.ByteString.Lazy:
Constructor :*: used at 590:22-590:24 is not defined.
It's defined in Data.ByteString.Fusion: infixl 2 :*: -- |Strict pair data PairS a b = !a :*: !b deriving (Eq,Ord,Show)
I did not find it with a quick grep, but yes, there it is. So this indicates a bug in nhc98/yhc's import resolution, not in your library...
It's everyone's library now! :) -- Don

On Thu, 2006-11-02 at 10:37 +0000, Ross Paterson wrote:
Data.ByteString.Lazy defines ByteString as a type synonym, and then uses that in instances, which isn't permitted by Haskell 98. How about defining a newtype ByteString in Data.ByteString.Lazy.Base instead?
It is defined as a newtype in Data.ByteString.Lazy.Base. But that module also defines the strict variant, so within the same module they needed different names. So we could just use the original name in the instance declarations. that is, .Base has: data ByteString = ... newtype LazyByteString = LPS [ByteString] and .Lazy has: type ByteString = Base.LazyByteString So in .Lazy we can just use instance Eq Base.LazyByteString where ... Or we could use a separate .Lazy.Base module for exposing the lower level internals of the lazy version and then not use a type alias at all. Duncan

On Thu, Nov 02, 2006 at 11:51:48AM +0000, Duncan Coutts wrote:
On Thu, 2006-11-02 at 10:37 +0000, Ross Paterson wrote:
Data.ByteString.Lazy defines ByteString as a type synonym, and then uses that in instances, which isn't permitted by Haskell 98. How about defining a newtype ByteString in Data.ByteString.Lazy.Base instead?
It is defined as a newtype in Data.ByteString.Lazy.Base. But that module also defines the strict variant, so within the same module they needed different names. [...] Or we could use a separate .Lazy.Base module for exposing the lower level internals of the lazy version and then not use a type alias at all.
So can we do that? What's the process?

Ross Paterson
Data.ByteString.Lazy defines ByteString as a type synonym, and then uses that in instances, which isn't permitted by Haskell 98.
I recently sent some patches to the fps package, to enable it to build with nhc98. They simply change these instance decls to use the original type name rather than the synonym. (The original name was even in scope, so there was no compelling reason to use the synonym in the first place.) Btw, my patches have not yet appeared in the official fps repo. I think dons was going to be responsible for pushing them into base at the next merge point between fps and base. Regards, Malcolm

Malcolm.Wallace:
Ross Paterson
wrote: Data.ByteString.Lazy defines ByteString as a type synonym, and then uses that in instances, which isn't permitted by Haskell 98.
I recently sent some patches to the fps package, to enable it to build with nhc98. They simply change these instance decls to use the original type name rather than the synonym. (The original name was even in scope, so there was no compelling reason to use the synonym in the first place.)
Btw, my patches have not yet appeared in the official fps repo. I think dons was going to be responsible for pushing them into base at the next merge point between fps and base.
The patches never arrived! I was wondering when they were going to appear. When they do, I'll apply, test, push into base. Can you resend, Malcolm? -- Don

On Wed, Nov 22, 2006 at 12:28:33PM +0000, Malcolm Wallace wrote:
Ross Paterson
wrote: Data.ByteString.Lazy defines ByteString as a type synonym, and then uses that in instances, which isn't permitted by Haskell 98.
I recently sent some patches to the fps package, to enable it to build with nhc98. They simply change these instance decls to use the original type name rather than the synonym. (The original name was even in scope, so there was no compelling reason to use the synonym in the first place.)
There is the minor issue of which name appears in the Haddock docs.

Am Mittwoch, 22. November 2006 14:18 schrieb Ross Paterson:
On Wed, Nov 22, 2006 at 12:28:33PM +0000, Malcolm Wallace wrote:
Ross Paterson
wrote: Data.ByteString.Lazy defines ByteString as a type synonym, and then uses that in instances, which isn't permitted by Haskell 98.
I recently sent some patches to the fps package, to enable it to build with nhc98. They simply change these instance decls to use the original type name rather than the synonym. (The original name was even in scope, so there was no compelling reason to use the synonym in the first place.)
There is the minor issue of which name appears in the Haddock docs.
In the OpenGL package this is "solved" via preprocessing: http://darcs.haskell.org/packages/OpenGL/include/HsOpenGLTypes.h I haven't followed the Haskell' discussion in detail, but I hope that this restriction on instances will be dropped. Cheers, S.
participants (5)
-
dons@cse.unsw.edu.au
-
Duncan Coutts
-
Malcolm Wallace
-
Ross Paterson
-
Sven Panne