How should one go about deciding to use data or class?

class: class lets specify more than one method. when you define instance yet do not implement all methods, compiler warns. if you try to call class method without an instance for that type, compiler warns. pattern matching: compiler does not warn if methods do not match every constructor of the data type. one way to decide if not sure, is to pick one way which seems easier to refactor. when more code is written, it usually becomes obvious if this approach does not fit. then refactor.

Which is more appropriate here? depends on the rest of the code. if this is it, then there is no real difference.

Well, there is -fwarn-incomplete-patterns, which should be included in -Wall, which does exactly this.

cheers Jonas. will try this. another thing: class lets reuse the same method name for several types. with pattern matching, different types require different function names. it is possible to place methods in different modules and call them qualified, but class solution seems cleaner. basically, classes are very convenient for standardization and extending code. a bit like Java interfaces :-P

it's very hard to pass them around, manipulate them and compute with them without using non-standard and awkward techniques.

well here is one simple use case when class is very convenient: class ConvertByteString a where toByteString::a -> ByteString fromByteString::ByteString -> a no problems defining instances of this class, passing and calling them whatsoever.

you convert String or Text: what encoding would you use?

let's say, this is very specific conversion where newtypes are used a lot. There are many different formats for Int (even the same type of int), String may be ascii, UTF8, ISO-..., you name it. using class does not make a difference re: type definition in this case.

In case of the data approach, `GroceryTask` and `LaundryTask` are the same type: `Task`. Hence you can have some kind of "dynamic" polymorphism (or "dynamic" dispatch) by storing a list of homogeneous types (`Task`) with heterogeneous behaviors. For example, imagine you want to store a todo list and do all task of the todo list. data Task = GroceryTask | LaundryTask doTask GroceryTask = putStrLn "grocery" doTask LaundryTask = putStrLn "laundry" todoList :: [Task] todoList = [GroceryTask, LaundryTask, GroceryTask] doAllTasks :: [Task] -> IO () doAllTasks tasks = mapM_ doTask tasks However, In the case of the class approach data GroceryTask data LaundryTask class Task t where doTask :: t -> IO () instance Task GroceryTask where doTask t = putStrLn "grocery" instance Task LaundryTask where doTask t = putSTrLn "laundry" doAllTask :: [?????] -> IO () In this case, GroceryTask and LaundryTask are NOT the same type, hence the "????", you cannot create a list which stores different Tasks and returns apply However you can still wrap them inside a sum type : data DoableTask = DoableGrocery GroceryTask | DoableLaundry LaundryTask instance Task DoableTask where doTask (DoableGrocery t) = doTask t doTask (DoableLaundry t) = doTask t (Open question: is there a hack / tool / library / Template Haskell solution to generate this kind of stuff ?) There is other solutions, you can partially apply the doTask function, for examples: todoList :: [IO ()] todoList = [doTask GroceryTask, doTask LaundryTask, doTask GroceryTask] (Another open question, is there a simple solution to do a map over an literal heterogeneous list to get an homogeneous one?) Thank to laziness, this works, but can be really boring to implement. There is other solution using existential types or heterogeneous lists. I'm still looking for a good discussion about which one to use when we focus on performance. So, finally, there is no simple solution. If your type is close and really represents a choice between a set of possibilities and that you know you want a kind of dynamic dispatch, definitely go for the data approach. Else, the class approach is easier to extend at the cost of a lot of boilerplate when you want dynamic dispatch... On Mon, Jan 11, 2016 at 12:44 PM, Lian Hung Hon wrote:

Dear all,

Thanks for the opinions. I'll go with type classes for now, because as Miguel said, I want it to be open :)

Regards, Hon

On 8 January 2016 at 19:46, Imants Cekusins wrote:

...

...

you convert String or Text: what encoding would you use?

let's say, this is very specific conversion where newtypes are used a lot. There are many different formats for Int (even the same type of int), String may be ascii, UTF8, ISO-..., you name it.

using class does not make a difference re: type definition in this case. _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe