Recommended class instances for container type
Hello, I'm in the process of implementing a container data type, and wonder what class instances are generally considered necessary. E.g. is it ok to start out with a Show that's adequate for debugging, or is it a 'must' to include instances of everything possible (Eq, Ord if possible, Read, Show, Functor, ...). And what about the more experimental things? Say, DeepSeq, Typeable, Data? I'd like to keep this simple at start, and I've admittedly not followed recent developments in Haskell-land (recent meaning the last 10 years or so. I _do_ know about hierachical modules ;-) ). OTOH, if not having such instances makes it impossible to do things the modern way, I'd probably take the time to implement (and maybe understand) them. Thanks, Chris
I'd hazard that if you went 'containers' and looked at what instances were implemented, that would give you a good idea. :^) (For example, if you look at Data.MAp, it has NFData, Typeable2 and Data instances.) Edward Excerpts from Christoph Breitkopf's message of Thu Dec 08 11:12:06 -0500 2011:
Hello,
I'm in the process of implementing a container data type, and wonder what class instances are generally considered necessary. E.g. is it ok to start out with a Show that's adequate for debugging, or is it a 'must' to include instances of everything possible (Eq, Ord if possible, Read, Show, Functor, ...).
And what about the more experimental things? Say, DeepSeq, Typeable, Data? I'd like to keep this simple at start, and I've admittedly not followed recent developments in Haskell-land (recent meaning the last 10 years or so. I _do_ know about hierachical modules ;-) ).
OTOH, if not having such instances makes it impossible to do things the modern way, I'd probably take the time to implement (and maybe understand) them.
Thanks,
Chris
That's what I did, and the reason for my question. 'Cause I was scared off by looking at Data.Map (CPP, lots of language extensions).
On Thu, Dec 8, 2011 at 8:12 AM, Christoph Breitkopf < chbreitkopf@googlemail.com> wrote:
I'm in the process of implementing a container data type, and wonder what class instances are generally considered necessary. E.g. is it ok to start out with a Show that's adequate for debugging, or is it a 'must' to include instances of everything possible (Eq, Ord if possible, Read, Show, Functor, ...).
If you're only beginning or partway through the implementation, my advice would be to simply not worry about instances at all just yet, until you've got things in reasonable shape. When the time comes, implement the instances you think appropriate in order of importance, relevance, and difficulty. Of course if you're new to the community, it won't be too obvious what's important or relevant (difficulty should be obvious enough). Basically, aim at the standard classes first, based on how often you'd expect to use them yourself. And what about the more experimental things? Say, DeepSeq, Typeable, Data?
None of those are experimental. They're all frequently used in production code. DeepSeq is far more important than the other two, though. For Typeable and Data, you could copy the approach taken by Data.Map and be fine. At some point, if you want your container class to be useful to others, you'll want to implement Foldable and Traversable.
Hello Bryan,
On Thu, Dec 8, 2011 at 6:03 PM, Bryan O'Sullivan
And what about the more experimental things? Say, DeepSeq, Typeable, Data?
None of those are experimental. They're all frequently used in production code. DeepSeq is far more important than the other two, though. For Typeable and Data, you could copy the approach taken by Data.Map and be fine.
Well, including a some file via CPP did look experimental enough to me. I'd like to stay away from GHC-only code, if possible.
At some point, if you want your container class to be useful to others, you'll want to implement Foldable and Traversable.
Being useful to others would be the whole point in releasing it at all :-) Thanks for your explanations - I take this as: "Yes, the Haskell community is really using all this stuff in production code, so better offer it, or your library might not be that usable." I'll try to be complete, then. - Chris
On Thursday 08 December 2011, 18:13:50, Christoph Breitkopf wrote:
Well, including a some file via CPP did look experimental enough to me. I'd like to stay away from GHC-only code, if possible.
CPP is standard (maybe not in the sense that it's included in the language standard, but every implementation I'm aware of supports CPP).
At some point, if you want your container class to be useful to others, you'll want to implement Foldable and Traversable.
Being useful to others would be the whole point in releasing it at all :-)
Thanks for your explanations - I take this as: "Yes, the Haskell community is really using all this stuff in production code, so better offer it, or your library might not be that usable."
To varying extent. Stuff can be quite usable without Data or Typeable instances. You can start with what you consider most important and add the rest when you get feature requests.
I'll try to be complete, then.
- Chris
On Thu, Dec 8, 2011 at 8:12 AM, Christoph Breitkopf < chbreitkopf@googlemail.com> wrote:
Hello,
I'm in the process of implementing a container data type, and wonder what class instances are generally considered necessary. E.g. is it ok to start out with a Show that's adequate for debugging, or is it a 'must' to include instances of everything possible (Eq, Ord if possible, Read, Show, Functor, ...).
Start out with Show and spend your time making sure that you're container type performs well (unless you're doing this as an exercise of course). A featureful API for something that's as slow as linked lists isn't very useful. ;) -- Johan
It's just a variant of Data.Map that takes intervals as keys and offers an
efficient stabbing query. I'm reasonably optimistic on the performance
front. Will probably release a 0.1 soon.
Thanks again for all opinions,
Chris
Am 08.12.2011 20:41 schrieb "Johan Tibell"
On Thu, Dec 8, 2011 at 8:12 AM, Christoph Breitkopf < chbreitkopf@googlemail.com> wrote:
Hello,
I'm in the process of implementing a container data type, and wonder what class instances are generally considered necessary. E.g. is it ok to start out with a Show that's adequate for debugging, or is it a 'must' to include instances of everything possible (Eq, Ord if possible, Read, Show, Functor, ...).
Start out with Show and spend your time making sure that you're container type performs well (unless you're doing this as an exercise of course). A featureful API for something that's as slow as linked lists isn't very useful. ;)
-- Johan
On 12/8/11 11:12 AM, Christoph Breitkopf wrote:
Hello,
I'm in the process of implementing a container data type, and wonder what class instances are generally considered necessary. E.g. is it ok to start out with a Show that's adequate for debugging, or is it a 'must' to include instances of everything possible (Eq, Ord if possible, Read, Show, Functor, ...).
And what about the more experimental things? Say, DeepSeq, Typeable, Data? I'd like to keep this simple at start, and I've admittedly not followed recent developments in Haskell-land (recent meaning the last 10 years or so. I _do_ know about hierachical modules ;-) ).
I don't use Typeable or Data, but there are a lot of folks who do, and they seem pretty well entrenched in GHC-standard Haskell. Not sure about non-GHC compiler support. For a container datatype, I'd consider Foldable and Traversable to be essential (provided that they're actually implementable). These classes are widely used and so they offer a nice standard set of names for common operations. But more than just having a common set of names, implementing these classes ensures a minimum level of completeness for your API--- and that's the essential part. Functor, Applicative, and Monad are also good to offer whenever possible. Functor is required/implied by Foldable and Traversable. Applicative and Monad just give a nice clean interface--- though you should beware of whether there are multiple law-abiding implementations for these two classes. If there are, then you'll have to worry about which one you offer by default (if any) as well as how people can access the other ones. -- Live well, ~wren
participants (6)
-
Bryan O'Sullivan -
Christoph Breitkopf -
Daniel Fischer -
Edward Z. Yang -
Johan Tibell -
wren ng thornton