[Haskell-cafe] Polyvariadic functions operating with a monoid
Luke Palmer
lrpalmer at gmail.com
Sun Oct 3 15:30:39 EDT 2010
On Sun, Oct 3, 2010 at 1:26 PM, Luke Palmer <lrpalmer at gmail.com> wrote:
> On Sun, Oct 3, 2010 at 1:24 AM, Kevin Jardine <kevinjardine at gmail.com> wrote:
>> I had a situation where I had some related types that all had toString
>> functions.
>>
>> Of course in Haskell, lists all have to be composed of values of
>> exactly the same type, so instead of passing around lists of values
>> with these related types, I created a polyvariadic function
>> polyToString so that I could write:
>>
>> (polyToString value1 value2 value3 ... valueN)
>>
>> which would then become a list of strings:
>>
>> [toString value1, toString value2, ... , toString valueN]
>
> First of all, you are not using the monoidal structure of String at
> all. This trick ought to work for any type whatsoever -- you're just
> throwing them in a list.
Oops, sorry for not reading your message more closely. You were
indeed talking about the monoidal structure of list. So... nevermind
about this comment. :-P
> Other than a few brackets, commas, and a repeated identifier (which
> you can let-bind to shorten), what benefit is it giving you? I
> strongly recommend against polyvariadic functions. While you get a
> little bit of notational convenience, you lose composability. There
> are pains when you try to write a function that takes a polyvariadic
> function as an argument, or when you try to feed the function values
> from a list, etc. The mechanisms to create polyvariadic functions are
> brittle and hacky (eg. you cannot have a polymorphic return type, as
> you want in this case).
>
> Since all your values are known statically, I would recommend biting
> the bullet and doing it the way you were doing it.
>
> [ s value1, s value2, s value3, ... ]
> where
> s x = toString x
>
> (I had to eta expand s so that I didn't hit the monomorphism restriction)
>
> When you want to be passing around "heterogeneous lists", it usually
> works to convert them before you put them in the list, like you were
> doing.
>
>> I finally figured out how to do this, but it was a bit harder to
>> figure this out than I expected, and I was wondering if it might be
>> possible to create a small utility library to help other developers do
>> this.
>>
>> It seems to me that in the general case, we would be dealing with a
>> Monoid rather than a list of strings. We could have a toMonoid
>> function and then return
>>
>> polyToMonoid value1 value2 ... valueN =
>>
>> (toMonoid value1) `mappend` (toMonoid value2) 'mappend' ... (toMonoid
>> valueN)
>>
>> So anyone who wanted to convert a bunch of values of different types
>> to a Monoid could easily pass them around using polyToMonoid so long
>> as they defined the appropriate toMonoid function.
>>
>> Basically, a generalised list.
>>
>> So I tried writing the following code but GHC said it had undecidable
>> instances.
>>
>> Has this ever been done successfully?
>>
>> class Monoidable a where
>> toMonoid :: Monoid r => a -> r
>>
>> polyToMonoid :: (Monoidable a, Monoid r) => a -> r
>> polyToMonoid k = polyToMonoid' k mempty
>>
>> class PolyVariadic p where
>> polyToMonoid' :: (Monoidable a, Monoid r) => a -> r -> p
>>
>> instance Monoid r => PolyVariadic r where
>> polyToMonoid' k ss = (toMonoid k) `mappend` ss
>>
>> instance (Monoidable a, Monoid r) => PolyVariadic (a -> r) where
>> polyToMonoid' k ss = (\a -> polyToMonoid' k (toMonoid a) `mappend`
>> ss)
>>
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe at haskell.org
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>
>
More information about the Haskell-Cafe
mailing list