[Haskell-cafe] Design Question - Functions taking 'subtype' like arguments but has to be restricted to one type

[Geraldus]

Please excuse me an off-topic question, *MarLinn* can you say what
apostrophe means in `Item 'Changeable`?

ср, 3 авг. 2016 г. в 20:00, MarLinn via Haskell-Cafe <
haskell-cafe at haskell.org>:

> I'll try to address the questions in the reverse order.
>
>
> 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.
>
> The main power lies in the minimalism. You don't need special handling of
> an *Either* or manual tracking because the types do everything you need.
>
>
> In your approach or in the approach suggested by others, ultimately, I end
> up handling the 'Frozen' type during run-time.
>
> Actually, not really. That's the beauty of phantom types: It's almost
> exclusively a development-time tool that vanishes once the program is
> compiled. You can't handle the Frozen type during run-time because it will
> have been dropped - unless you use tricks to keep it, of course. It might
> feel like you're dealing with the type, but it's all in your head.
>
>
> There is no way from stopping somene write code that calls update's on
> Frozen. (For example while mapping..).  Is that understanding correct?
>
> Here's my *Item* type again for reference:
>
>     data Item (c :: Changeability) = Item { plainItem :: PlainItem }
>
> If you don't export the *Item* constructor, you have full control over
> who gets to do what with your items. If your only exported update function
> is
>
>     changeItem :: (PlainItem -> PlainItem) -> Item 'Changeable -> Item 'Changeable
>
> then only non-frozen items can be changed, as the type signature says. Of
> course you have to be careful, e.g. you wouldn't want to export a function
> like
>
>     asChangableItem :: PlainItem -> Item 'Changeable
>
> because then somebody could "unfreeze" items. But as long as you watch
> your types and exports, you should be fine. (apart from unsafe casting and
> the like, naturally)
>
> 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.
>
> That depends. How does a cart behave, depending on the changeability of
> its contents?
>
>    -
>
>    *If a cart with any frozen value behaves differently from a cart with
>    only changeable baskets* then add a phantom type to the cart as well.
>    Control the channels into it and have the cart type change depending on
>    what you insert.
>    -
>
>    *If all carts behave the same and contents don't matter* just store
>    *PlainBasket*s, i.e. a *Basket* without the annotation.
>    -
>
>    *If you want to be able to map over baskets in a cart while handling
>    frozen ones** differently*, then you need both run-time information
>    about basket changeability and a way to share functions between the two
>    different types. The canonical way to share a function between types is a
>    class:
>
>        class IsBasket b
>        instance IsBasket (Basket c)
>        type Cart = (IsBasket b) => [b] -- not a good definition, but you get the point
>
>    Now *Basket*s can share functions but behave differently. Of course
>    once you need such a class anyway you could ask why you would not want to
>    use it exclusively instead of the phantom types. It's a matter of taste, I
>    guess.
>
> _______________________________________________
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20160804/8c23ccd7/attachment.html>