On Tue, Jul 26, 2011 at 1:52 PM, Tim Cowlishaw wrote:

On Tue, Jul 26, 2011 at 7:46 PM, Evan Laforge wrote:

...

Could you give a specific example of the problem you're trying to solve?

Sorry, yes, that'd be useful :-)

So, the project I'm working on involves developing a simulation of a securities market. I have a type which models an order book, on which orders can be placed or removed (and later filled):

eg.

placeOrder :: (Order e) -> e -> OrderBook -> OrderBook deleteOrder :: (Order e) -> e -> OrderBook -> OrderBook

Now, i've chosen to model orders as a typeclass, as there are various semantic differences between different types of order that I can model as different types implementing this typeclass (limit orders vs market orders, buy side vs sell side), and these differences can be specified in the type's implementation of the class.

Use Maybe to demarcate nonsense semantics/undefinedness.

However, there are a number of other typeclasses that all orders should also be instances of (and in terms of which their semantics don't differ, eg Eq or Ord.

data OrderType = Market Size | Limit LimitPrice Expiration Size | Stop (Either Percent Price) newtype Sell = Sell OrderType newtype Buy = Buy OrderType newtype Order = Order (Either Buy Sell) class Order o where

price :: o -> Int size :: o -> Int

size :: Order -> Int size (Order (Left (Buy (Market s))) = s size (Order (Left (Buy (Limit _ _ s))) = s etc.

I'd like to be able to specify an Eq instance for all types of class Order in a manner similar to this:

instance (Order o) => Eq o where o1 == o2 = (price o1 == price o2) && (size o1 == size o2)

On Tue, Jul 26, 2011 at 11:58 PM, Tim Cowlishaw wrote:

On Tue, Jul 26, 2011 at 11:14 PM, Alexander Solla wrote:

...

data OrderType = Market Size | Limit LimitPrice Expiration Size | Stop (Either Percent Price) newtype Sell = Sell OrderType newtype Buy = Buy OrderType newtype Order = Order (Either Buy Sell)

...

size :: Order -> Int size (Order (Left (Buy (Market s))) = s size (Order (Left (Buy (Limit _ _ s))) = s etc.

Aah, thank you - this is really neat. So now, I can write (for instance) an Eq instance for OrderType and use deriving (Eq) on the newtypes that wrap it, and my Order can be a concrete type, but still encapsulates all the different types of order.

Thank you!

No problem. This is more-or-less how type classes work internally, with fewer restrictions (but some more implicit passing around of stuff). Notice that my Order type "corresponds" with your Order typeclass. My OrderType type value constructors correspond to all your Order types. In other words, a typeclass is a fancy "open" "union" type. I never use type classes unless I need that openness property. The problem with this approach is that it can become verbose very quickly. It can be mitigated some by defining accessors for the newtypes, and using function composition. So instead of:

newtype Sell = Sell OrderType newtype Buy = Buy OrderType newtype Order = Order (Either Buy Sell)

I would personally use

newtype Sell = Sell { unSell :: OrderType } newtype Buy = Buy { unBuy :: OrderType } newtype Order = Order { unOrder :: Either Buy Sell }

where "un" should be read like "unwrap". These unwrappers can help cut down on the size of pattern matches. I'll give an example shortly. I suggested using Maybe to deal with nonsense semantics/undefinedness. All orders have a size/quantity, but not all have a limit price. So we might write an accessor like: limitPrice' :: OrdeType -> Maybe Price limitPrice' (Limit l _ _) = Just l limitPrice' _ = Nothing We have turned a "partial" function into a "total" function by embedding it in (Order -> Maybe Price). This cuts down on bugs. Now that easy accessor for all orders: limitPrice :: Order -> Maybe Price limitPrice = limitPrice' . either (unBuy) (unSell) . unOrder We might even want to stick limitPrice' in a where clause for limitPrice, depending on whether you expect reuse or not.