Proposal: Simplify/Generalize Data.Dynamic
Edward Kmett
ekmett at gmail.com
Mon Aug 25 15:15:28 UTC 2014
I'd like to propose a cleanup to the API of Data.Dynamic.
By way of (partial) motivation, a couple of years back Lennart posed a
question on stackoverflow
<http://stackoverflow.com/questions/10889682/how-to-apply-a-polymorphic-function-to-a-dynamic-value/10890414#comment39759480_10890414>
about how to use Dynamic to implement
apD :: forall f. Typeable1 f =>
(forall a. a -> f a) -> Dynamic -> Dynamic
At the time, I offered a solution that is no longer applicable in a world
with polykinded Typeable.
But, if we change the definition of Data.Dynamic to
data Dynamic where
Dynamic :: Typeable a => a -> Dynamic
from its current magic implementation in terms of unsafeCoerce and a
manually held typeRep, then
fromDynamic becomes a trivial application of Data.Typeable.cast and dynApply
becomes easier,
This would enable us to implement Data.Dynamic with its full constructor
exposed without losing safety.
In lieu of supplying the constructor, we could offer a form of
withDyn :: Dynamic -> (forall a. Typeable a => a -> r) -> r
but I'd rather expose the constructor rather than needlessly Church encode
as the kind of code/user that needs this is the kind that would bemoan
needless performance barriers in the name of nebulous encapsulation
benefits.
Now it becomes possible to write code that does polymorphic things
underneath the Dynamic wrapper, such as Lennart's example once more, but
now in a principled way.
Discusssion Period: 2 Weeks
*tl;dr* polykinded Typeable took away some power from the users of
Data.Dynamic, which we can give back in a more principled way, simplifying
the API as a result.
-Edward
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20140825/dfd819db/attachment.html>
More information about the Libraries
mailing list