Proposal: Simplify/Generalize Data.Dynamic

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Proposal: Simplify/Generalize Data.Dynamic

Edward Kmett-2
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 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

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

RE: Proposal: Simplify/Generalize Data.Dynamic

Simon Peyton Jones

Yes, this would be a great improvement.  Often proposed, but never executed!

 

Simon

 

From: Libraries [mailto:[hidden email]] On Behalf Of Edward Kmett
Sent: 25 August 2014 16:15
To: Haskell Libraries
Subject: Proposal: Simplify/Generalize Data.Dynamic

 

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 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


_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Simplify/Generalize Data.Dynamic

John Wiegley-2
In reply to this post by Edward Kmett-2
>>>>> Edward Kmett <[hidden email]> writes:

> 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, 

+1

John
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Simplify/Generalize Data.Dynamic

Niklas Haas
In reply to this post by Edward Kmett-2
On Mon, 25 Aug 2014 11:15:28 -0400, Edward Kmett <[hidden email]> wrote:
> data Dynamic where
>   Dynamic :: Typeable a => a -> Dynamic

+1, this is actually how I thought Dynamic was implemented under the
hood until your e-mail suggest to me otherwise.
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Simplify/Generalize Data.Dynamic

John Lato-2
In reply to this post by Edward Kmett-2
+1, and +1 for exposing the constructor.  If we implemented Dynamic from scratch today this is what it would look like, so let's get rid of the old cruft!

John L.


On Mon, Aug 25, 2014 at 11:15 PM, Edward Kmett <[hidden email]> wrote:
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 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

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries



_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Simplify/Generalize Data.Dynamic

Emil Axelsson-2
In reply to this post by Edward Kmett-2
+1

/ Emil

Den 2014-08-25 17:15, Edward Kmett skrev:

> 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
>
>
>
> _______________________________________________
> Libraries mailing list
> [hidden email]
> http://www.haskell.org/mailman/listinfo/libraries
>
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Simplify/Generalize Data.Dynamic

Milan Straka
In reply to this post by Edward Kmett-2
Hi all,

+1 here, including exporting the constructor.

Cheers,
Milan Straka

> -----Original message-----
> From: Edward Kmett <[hidden email]>
> Sent: 25 Aug 2014, 11:15
>
> 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

> _______________________________________________
> Libraries mailing list
> [hidden email]
> http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries