[commit: packages/base] master: Add fmapCoerce to Functor class. (3da4fd9)

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

[commit: packages/base] master: Add fmapCoerce to Functor class. (3da4fd9)

Johan Tibell-2
Having coerce (!) show up in such a commonly used type class is a bit
alarming. Was there a libraries discussion about this? At least we
should add some docs to the method.

On Wed, Sep 25, 2013 at 12:37 AM,  <git at git.haskell.org> wrote:

> Repository : ssh://git at git.haskell.org/base
>
> On branch  : master
> Link       : http://ghc.haskell.org/trac/ghc/changeset/3da4fd92e005cb9348ab2852d9268ad61ae1b347/base
>
>>---------------------------------------------------------------
>
> commit 3da4fd92e005cb9348ab2852d9268ad61ae1b347
> Author: Austin Seipp <austin at well-typed.com>
> Date:   Tue Sep 24 23:20:35 2013 -0500
>
>     Add fmapCoerce to Functor class.
>
>     This allows coercions to work under functors that are not locally known.
>
>     Authored-by: Edward Kmett <ekmett at gmail.com>
>     Signed-off-by: Austin Seipp <austin at well-typed.com>
>
>
>>---------------------------------------------------------------
>
> 3da4fd92e005cb9348ab2852d9268ad61ae1b347
>  GHC/Base.lhs |    4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/GHC/Base.lhs b/GHC/Base.lhs
> index d876202..55172af 100644
> --- a/GHC/Base.lhs
> +++ b/GHC/Base.lhs
> @@ -105,7 +105,6 @@ module GHC.Base
>          module GHC.Err          -- import it explicitly
>    )
>          where
> -
>  import GHC.Types
>  import GHC.Classes
>  import GHC.CString
> @@ -186,6 +185,9 @@ class  Functor f  where
>      (<$)        :: a -> f b -> f a
>      (<$)        =  fmap . const
>
> +    fmapCoerce :: Coercible a b => f a -> f b
> +    fmapCoerce = fmap coerce
> +
>  {- | The 'Monad' class defines the basic operations over a /monad/,
>  a concept from a branch of mathematics known as /category theory/.
>  From the perspective of a Haskell programmer, however, it is best to
>
> _______________________________________________
> ghc-commits mailing list
> ghc-commits at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-commits


Reply | Threaded
Open this post in threaded view
|

[commit: packages/base] master: Add fmapCoerce to Functor class. (3da4fd9)

Edward Kmett-2
The discussion was back and forth with SPJ and Richard Eisenberg during the
discussion about the creation of the roles machinery and Simon suggested
the shape it currently has to me last night.

Having this in the class is the only way that this can lift over an
'unknown' Functor in local scope, and permits users of a functor that is
polymorphic to get access to the O(1) coercion machinery.

Without it Coercible is almost completely useless in any code that has any
sort of polymorphism involved.

This is analogous to (<$), which was added to Functor explicitly because it
made an asymptotic performance difference in a large number of scenarios.

The reason this has to live in the class is analogous to how Data has to
hold the at-first-glance redundant dataCast1 and dataCast2, because it is
the only place the right things are known, despite them always being gcast1
and gcast2. See 7.4 in Scrap more boilerplate: reflection, zips, and
generalised casts<http://research.microsoft.com/en-us/um/people/simonpj/papers/hmap/>
for
a discussion of an almost identical issue.

There is still some work to be done here. I definitely agree that we should
add some docs to it.

One of the reasons why we didn't in this initial commit is because there is
some of it still up in the air in terms of what is possible. The current
default definition is in terms of 'fmap coerce', so it'll currently work
with even 'illegal' functors that don't have a representational argument,
but the user doesn't see any improvement unless  One of the reasons the
docs didn't go in with the first commit was that there is room for
improvement. *If* we can improve some things about Coercible inference we
may be able to upgrade it to actually use 'coerce' via a default signature.

-Edward


On Wed, Sep 25, 2013 at 12:41 AM, Johan Tibell <johan.tibell at gmail.com>wrote:

> Having coerce (!) show up in such a commonly used type class is a bit
> alarming. Was there a libraries discussion about this? At least we
> should add some docs to the method.
>
> On Wed, Sep 25, 2013 at 12:37 AM,  <git at git.haskell.org> wrote:
> > Repository : ssh://git at git.haskell.org/base
> >
> > On branch  : master
> > Link       :
> http://ghc.haskell.org/trac/ghc/changeset/3da4fd92e005cb9348ab2852d9268ad61ae1b347/base
> >
> >>---------------------------------------------------------------
> >
> > commit 3da4fd92e005cb9348ab2852d9268ad61ae1b347
> > Author: Austin Seipp <austin at well-typed.com>
> > Date:   Tue Sep 24 23:20:35 2013 -0500
> >
> >     Add fmapCoerce to Functor class.
> >
> >     This allows coercions to work under functors that are not locally
> known.
> >
> >     Authored-by: Edward Kmett <ekmett at gmail.com>
> >     Signed-off-by: Austin Seipp <austin at well-typed.com>
> >
> >
> >>---------------------------------------------------------------
> >
> > 3da4fd92e005cb9348ab2852d9268ad61ae1b347
> >  GHC/Base.lhs |    4 +++-
> >  1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/GHC/Base.lhs b/GHC/Base.lhs
> > index d876202..55172af 100644
> > --- a/GHC/Base.lhs
> > +++ b/GHC/Base.lhs
> > @@ -105,7 +105,6 @@ module GHC.Base
> >          module GHC.Err          -- import it explicitly
> >    )
> >          where
> > -
> >  import GHC.Types
> >  import GHC.Classes
> >  import GHC.CString
> > @@ -186,6 +185,9 @@ class  Functor f  where
> >      (<$)        :: a -> f b -> f a
> >      (<$)        =  fmap . const
> >
> > +    fmapCoerce :: Coercible a b => f a -> f b
> > +    fmapCoerce = fmap coerce
> > +
> >  {- | The 'Monad' class defines the basic operations over a /monad/,
> >  a concept from a branch of mathematics known as /category theory/.
> >  From the perspective of a Haskell programmer, however, it is best to
> >
> > _______________________________________________
> > ghc-commits mailing list
> > ghc-commits at haskell.org
> > http://www.haskell.org/mailman/listinfo/ghc-commits
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20130925/da9b62cf/attachment.htm>

Reply | Threaded
Open this post in threaded view
|

[commit: packages/base] master: Add fmapCoerce to Functor class. (3da4fd9)

Joachim Breitner-2
Hi,

Am Mittwoch, den 25.09.2013, 03:04 -0400 schrieb Edward Kmett:
> The discussion was back and forth with SPJ and Richard Eisenberg
> during the discussion about the creation of the roles machinery and
> Simon suggested the shape it currently has to me last night.

given the recently intensified urge to make GHC a more community driven
project, may I suggest to reduce the amount of off-list discussions? I
find it very confusing if some discussions happen on list, some
discussion on list with certain people explictily CC?ed, and some
discusisons off-list, and some alternating between these. I believe we
are all able to ignore discussions on the list that are not relevant for
us, but on-list discussions are easily referenced and re-read later.

> Having this in the class is the only way that this can lift over an
> 'unknown' Functor in local scope, and permits users of a functor that
> is polymorphic to get access to the O(1) coercion machinery.

Is the Coercion feature really mature enough to be embedded in Functor?
There are still some open questions (e.g. the in-scope-requirements for
it). I would feel more comfortable if people have one release?s time to
break it before we put it so easily in every programmers hands.


Greetings to ICFP from the Heidelberg Laureates Forum,
Joachim

--
Joachim ?nomeata? Breitner
  mail at joachim-breitner.de ? http://www.joachim-breitner.de/
  Jabber: nomeata at joachim-breitner.de  ? GPG-Key: 0x4743206C
  Debian Developer: nomeata at debian.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20130925/bf7de85f/attachment.pgp>

Reply | Threaded
Open this post in threaded view
|

[commit: packages/base] master: Add fmapCoerce to Functor class. (3da4fd9)

Ross Paterson-2
On Wed, Sep 25, 2013 at 10:18:51PM +0200, Joachim Breitner wrote:
> given the recently intensified urge to make GHC a more community driven
> project, may I suggest to reduce the amount of off-list discussions? I
> find it very confusing if some discussions happen on list, some
> discussion on list with certain people explictily CC?ed, and some
> discusisons off-list, and some alternating between these. I believe we
> are all able to ignore discussions on the list that are not relevant for
> us, but on-list discussions are easily referenced and re-read later.

I agree with all that, and also share Johan's alarm at the sudden
appearance of coerce in this class.

On the substance, I don't think Functor is the right place for this,
as it's about lifting isomorphisms rather than functions, and type
constructors don't have to be functors to support that.


Reply | Threaded
Open this post in threaded view
|

fmapCoerce / changes in 7.8

Richard Eisenberg-2
In light of the conversations I've been having with Edward and others, I, too, wonder if we should wait a little before doing this. There is no burning fire here. Though we have Coercible in 7.8, that doesn't mean we *have* to use it. The old trick to use unsafeCoerce in the situations Edward wants to improve will still work, and it will remain as safe as it was before (i.e., not at all).

In the end, I agree with Joachim that Coercible should try to have a low profile in 7.8. I do think that the ideas behind fmapCoerce -- that is, making sure that the new `coerce` primitive is used to the best effect --  are great. But I am not convinced that we've found the best possible way to do it.

Richard

On Sep 25, 2013, at 6:22 PM, Ross Paterson wrote:

> On Wed, Sep 25, 2013 at 10:18:51PM +0200, Joachim Breitner wrote:
>> given the recently intensified urge to make GHC a more community driven
>> project, may I suggest to reduce the amount of off-list discussions? I
>> find it very confusing if some discussions happen on list, some
>> discussion on list with certain people explictily CC?ed, and some
>> discusisons off-list, and some alternating between these. I believe we
>> are all able to ignore discussions on the list that are not relevant for
>> us, but on-list discussions are easily referenced and re-read later.
>
> I agree with all that, and also share Johan's alarm at the sudden
> appearance of coerce in this class.
>
> On the substance, I don't think Functor is the right place for this,
> as it's about lifting isomorphisms rather than functions, and type
> constructors don't have to be functors to support that.
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>



Reply | Threaded
Open this post in threaded view
|

fmapCoerce / changes in 7.8

Edward Kmett-2
I agree with Richard. We're still working up the right way to get this functionality to work, and sadly the simple solution doesn't cover enough cases. As I noted during the day, this approach doesn't scale. Let's revert.

-Edward

> On Sep 25, 2013, at 8:38 PM, Richard Eisenberg <eir at cis.upenn.edu> wrote:
>
> In light of the conversations I've been having with Edward and others, I, too, wonder if we should wait a little before doing this. There is no burning fire here. Though we have Coercible in 7.8, that doesn't mean we *have* to use it. The old trick to use unsafeCoerce in the situations Edward wants to improve will still work, and it will remain as safe as it was before (i.e., not at all).
>
> In the end, I agree with Joachim that Coercible should try to have a low profile in 7.8. I do think that the ideas behind fmapCoerce -- that is, making sure that the new `coerce` primitive is used to the best effect --  are great. But I am not convinced that we've found the best possible way to do it.
>
> Richard
>
>> On Sep 25, 2013, at 6:22 PM, Ross Paterson wrote:
>>
>>> On Wed, Sep 25, 2013 at 10:18:51PM +0200, Joachim Breitner wrote:
>>> given the recently intensified urge to make GHC a more community driven
>>> project, may I suggest to reduce the amount of off-list discussions? I
>>> find it very confusing if some discussions happen on list, some
>>> discussion on list with certain people explictily CC?ed, and some
>>> discusisons off-list, and some alternating between these. I believe we
>>> are all able to ignore discussions on the list that are not relevant for
>>> us, but on-list discussions are easily referenced and re-read later.
>>
>> I agree with all that, and also share Johan's alarm at the sudden
>> appearance of coerce in this class.
>>
>> On the substance, I don't think Functor is the right place for this,
>> as it's about lifting isomorphisms rather than functions, and type
>> constructors don't have to be functors to support that.
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://www.haskell.org/mailman/listinfo/ghc-devs
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs


Reply | Threaded
Open this post in threaded view
|

fmapCoerce / changes in 7.8

David Luposchainsky
I'm also sceptical about this, regardless of whether it sounds like a
good idea now. Adding a function to a typeclass is trivial, removing it
later far from it (see fail, some, many). On the other hand, are there
reasons not to create

> class Functor f => FunctorC f where
>     fmapC :: Coercible a b => f a -> f b

instead?


David/quchen


Reply | Threaded
Open this post in threaded view
|

fmapCoerce / changes in 7.8

Edward Kmett-2
A very real problem with making such a class is it basically forces a tension on any library to make two versions of literally everything.

Consider the case of lens, which makes incredibly aggressive use of such fmap-likes to put on and take off newtypes and does very little else.

All the combinators that do so would have to duplicate to work in such a world. Because now such an instance may not exist. This is mapM vs traverse for library authors, but it is an unforced error here.

There are three agents involved in consumption and production of such  an instance:

The author of the library that demands it, the author of the library that needs to supply it and the end user of both. In my experience, making a separate class like this only really works when these three roles are partitioned among two people.

You need to support data types not supplied by the library, and not supplied by the end user.

The rest of the time it leads to a ratsnest of orphans and missing instances for something that should be supportable for every functor.

I've tried this. The result isn't maintainable for the library author or the user.

The reason we had Austin revert the patch was because this approach wasn't sufficient to solve the problem, so we backed off of it until Richard can get us better tools for composing Coercible witnesses, to let us upgrade this to something that can give you O(1) lifting over abstract transformer stacks.

When it is exiled to some other class, that sort of code just becomes something that isn't safe to use, and in many cases like while writing a transformer, isn't possible to use.

We introduce an unnecessary tension and duplication for authors and users.

-Edward

> On Sep 26, 2013, at 3:59 AM, David Luposchainsky <dluposchainsky at googlemail.com> wrote:
>
> I'm also sceptical about this, regardless of whether it sounds like a
> good idea now. Adding a function to a typeclass is trivial, removing it
> later far from it (see fail, some, many). On the other hand, are there
> reasons not to create
>
>> class Functor f => FunctorC f where
>>    fmapC :: Coercible a b => f a -> f b
>
> instead?
>
>
> David/quchen
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs