Thank you, David and Antoine. I was planning to have files containing different types of objects, but where all of the types are instances of a particular class. Since the class definition ensures that whatever the types are, they implement the methods that I need, I hoped to be able to manipulate the files using those methods, without having to find out the class programmatically. Clearly I need to rethink this. I'm looking into existentially quantified data constructors now, maybe that will help.

I think this is the exact use case that the new ConstraintKinds extension was meant to address (http://hackage.haskell.org/trac/ghc/wiki/Status/Oct11). But we have to wait for 7.4. -deech On Thu, Nov 3, 2011 at 1:08 PM, Amy de Buitléir wrote:

Thank you, David and Antoine.

I was planning to have files containing different types of objects, but where all of the types are instances of a particular class. Since the class definition ensures that whatever the types are, they implement the methods that I need, I hoped to be able to manipulate the files using those methods, without having to find out the class programmatically.

Clearly I need to rethink this. I'm looking into existentially quantified data constructors now, maybe that will help.

_______________________________________________ Beginners mailing list Beginners@haskell.org http://www.haskell.org/mailman/listinfo/beginners

I could put a header in the file that tells me what the type of the object is. Then I would know at run-time (but not compile-time). Would that help?

Antoine Latter writes:

A really simple and common way to do this would be using a sum-type:

Here's what I'm trying to accomplish. I want to write a daemon that will cycle through the files, load each one in turn, and invoke the doSomething method. I would like to be able to allow people to use my daemon with any assortment of new types that they create, as long as that type implements the doSomething, readThing, and writeThing methods. I could make the sum-type approach work, but then users would have to modify the type. And there might be dozens of different types in use, some provided by me, and some provided by the user, so it would get messy. But I might have to go with that approach.

Perhaps this is what you're looking for: {-# LANGUAGE ExistentialQuantification #-} import Data.Binary import Data.ByteString.Lazy as B ( readFile, writeFile ) import Codec.Compression.GZip ( compress, decompress ) data Thing = forall a. (Binary a, Show a, Eq a) => Thing a instance Binary Thing where get = get put (Thing a) = put a instance Show Thing where show (Thing a) = show a readThing :: FilePath -> IO Thing readThing f = return . decode . decompress =<< B.readFile f writeThing :: FilePath -> Thing -> IO () writeThing f = B.writeFile f . compress . encode doSomething :: Thing -> m Thing doSomething = undefined main = do a <- readThing "file1.txt" a' <- doSomething a writeThing "file2.txt" a' It compiles on my machine (GHC 7.2.1) but I haven't tested it. It uses the existential quantification extension to constrain a datatype to the typeclasses you mention. The caveat is that the only functions you can run on "a" or "a'" are those defined by the Eq, Show and Binary typeclasses. -deech On Fri, Nov 4, 2011 at 8:26 AM, Antoine Latter wrote:

On Fri, Nov 4, 2011 at 7:51 AM, Amy de Buitléir wrote:

...

Antoine Latter writes:

...

A really simple and common way to do this would be using a sum-type:

Here's what I'm trying to accomplish. I want to write a daemon that will cycle through the files, load each one in turn, and invoke the doSomething method. I would like to be able to allow people to use my daemon with any assortment of new types that they create, as long as that type implements the doSomething, readThing, and writeThing methods.

I could make the sum-type approach work, but then users would have to modify the type. And there might be dozens of different types in use, some provided by me, and some provided by the user, so it would get messy. But I might have to go with that approach.

An executable, once compiled, cannot really learn about new types without dynamically loading new object code. Which is possible but often tricky.

You'd have this problem in other languages, too, except Java and .Net have spent a lot of time working on the dynamic loading of new object code into a running process (but you would still need to get the .class file or .dll into a folder where the executable can read it).

Maybe I'm mis-understanding your requirements, though.

Antoine

_______________________________________________ Beginners mailing list Beginners@haskell.org http://www.haskell.org/mailman/listinfo/beginners

On Fri, Nov 04, 2011 at 08:52:36AM -0500, aditya siram wrote:

Perhaps this is what you're looking for: {-# LANGUAGE ExistentialQuantification #-} import Data.Binary import Data.ByteString.Lazy as B ( readFile, writeFile ) import Codec.Compression.GZip ( compress, decompress )

data Thing = forall a. (Binary a, Show a, Eq a) => Thing a

instance Binary Thing where get = get put (Thing a) = put a

instance Show Thing where show (Thing a) = show a

readThing :: FilePath -> IO Thing readThing f = return . decode . decompress =<< B.readFile f

writeThing :: FilePath -> Thing -> IO () writeThing f = B.writeFile f . compress . encode

doSomething :: Thing -> m Thing doSomething = undefined

main = do a <- readThing "file1.txt" a' <- doSomething a writeThing "file2.txt" a'

It compiles on my machine (GHC 7.2.1) but I haven't tested it. It uses the

This will not work. The problem is that once you have a Thing you cannot do anything with it, because you have no information about what type is inside. In other words you cannot implement 'doSomething' to do anything interesting at all. I am actually surprised that 'readThing' type checks -- I am not sure what type it thinks the read thing has, or how it can guarantee that it satisfies the given constraints. I tried adding a Typeable constraint to Thing and using 'cast' to recover the type, but that doesn't really work either. You would really have to do something like changing the Binary instance for Thing so that it also serializes/deserializes a TypeRep along with the value, and then does some sort of unsafe cast after reading. You may want to take a look at how xmonad handles this problem -- it allows arbitrary user-extensible state and layouts, which it needs to serialize and deserialize when restarting itself. -Brent

Antoine Latter writes:

An executable, once compiled, cannot really learn about new types without dynamically loading new object code. Which is possible but often tricky.

I don't mind if the user has to re-compile the code to add in their new types. In addition to the daemon, I'm providing a library of functions that they can use when implementing new types, so they'd have to re-compile anyway.