@Marlin Thank you for the example. Looks very interesting. Initially, when I was modelling this problem, I did consider Phanton types. But, you do provide a nice extension using type classes. Here are the obstacles/discomfort I faced while I took the Phantom Polymorphism approach: 1. With the definition of Basket c, how do I create a type such as Cart = [Basket]. The only way to create such a cart is Cart c = [Basket c]. But, that ties the Cart to one definition of Basket. Is there a way around this? I might be missing something simple. 2. In your approach or in the approach suggested by others, ultimately, I end up handling the 'Frozen' type during run-time. There is no way from stopping somene write code that calls update's on Frozen. (For example while mapping..). Is that understanding correct? Does this approach give me any more power than the previous approaches? The one power is that we stop the user from being able to construct the Frozen type, and we leave it to the compiler to return that type based on the inference. Correct? Is there any other power. Thank you for the help. Just with this thread, I have learnt more than 3 different ways of modelling approaches for this kind of a problem! On Sun, Jul 31, 2016 at 11:41 AM, MarLinn via Haskell-Cafe < haskell-cafe@haskell.org> wrote:
This sounds like a perfect opportunity to use phantom types. I'll be using it's DataKind-enhanced variant for added beauty.
-- An Item that can be of two types, one whose value can be changed, one whose value are frozen once created data Item = FreeToChange {freeToChangeCount:: Int} | CannotChange {frozenCount:: Int}
I assume all items are equal apart from their changeability. Not that it's necessary, but it makes the demonstration simpler. If changeable and unchangeable items have differing structure you may need additional tools like smart constructors. Accordingly, my items have the type
data PlainItem = PlainItem { count :: Int }
Changeability will be added on top:
data Changeability = Changeable | Unchangeable
data Item (c :: Changeability) = Item { plainItem :: PlainItem }
Why separate *Item* and *PlainItem*? One second, please.
-- The item is part of a basket data Basket = Basket { name:: String, item::Item }
data Basket c = Basket { name :: String, item :: Item c } -- No kind signature necessary. Thanks, solver.
Therefore, valid operation are:
1. I can create an Basket with either FreeToChange item or CannotChange item.
The new *Basket* constructor can do that by default.
2. I can update the count for FreeToChange item in the Basket
changeItem :: (PlainItem -> PlainItem) -> Item 'Changeable -> Item 'Changeable
changeItem f (Item i) = Item (f i)
changeBasket :: (PlainItem -> PlainItem) -> Basket 'Changeable -> Basket 'Changeable
changeBasket f basket@Basket{..} = basket { item = changeItem f item }
And that's why *PlainItem* was separated, so we can have a simple type signature here. You might worry that it was exposed, but it will not give anyone access to a frozen basket. And of course you are free to further restrict access to it. And as we're speaking about freezing, that's extremely simple as well.
freezeItem :: Item c -> Item 'Unchangeable
freezeItem (Item i) = Item i
freezeBasket :: Basket c -> Basket 'Unchangeable
freezeBasket basket@Basket{..} = basket { item = freezeItem item }
You later mention that you might want to map updates only over some of the baskets in a cart. That's not hard either. As an example, here's a way to implement a function that updates changeable baskets while ignoring unchangeable ones:
class MaybeUpdateBasket c where updateBasket :: (PlainItem -> PlainItem) -> Basket c -> Basket c instance MaybeUpdateBasket 'Changeable where updateBasket = changeBasket instance MaybeUpdateBasket 'Unchangeable where updateBasket _ = id
Just *map* it over your cart as always.
If you want more complicated things (eg. you want a cart to freeze once any bucket freezes) you just have to expand the ideas here. You may need MultiParamTypeClasses and FunctionalDependencies, but the basic ideas are the same.
Cheers.
_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.