Fixing Fix
Oliver Charles
ollie at ocharles.org.uk
Tue Mar 24 17:00:15 UTC 2015
Oh, I see your confusion - you're looking at `indexed` on Hackage, but I
meant the unreleased library on Github. That uses the slice category
presentation of higher-order monads/functors, which is what you're talking
about:
https://github.com/ekmett/indexed/blob/master/src/Indexed/Functor.hs#L53
Though HFix isn't there, but I feel it would be a suitable addition to the
library.
It is unfortunate that there is a name conflict.
On Tue, Mar 24, 2015 at 4:28 PM, Erik Hesselink <hesselink at gmail.com> wrote:
> That seems slightly different, more related to indexed monads with
> pre- and postconditions. They have many more type variables...
>
> Erik
>
> On Tue, Mar 24, 2015 at 5:20 PM, Oliver Charles <ollie at ocharles.org.uk>
> wrote:
> > Higher order stuff is very useful, but I don't think it needs to belong
> in
> > the same place as Data.Functor.Fix. Edward Kmett's 'indexed' library will
> > probably deal with this, when we have a GHC that's smart enough to
> > understand it ;)
> >
> > - Ollie
> >
> > On Tue, Mar 24, 2015 at 3:40 PM, Erik Hesselink <hesselink at gmail.com>
> wrote:
> >>
> >> Ugh, you're right, I renamed the variables and made a mistake. The
> >> outer variable should stay the same of course, your signature is
> >> correct.
> >>
> >> For a use site of HFix, see the multirec package [0], although that
> >> might not really clarify things :) We also have a use internally, but
> >> I just realized we can probably simplify that away.
> >>
> >> Regards,
> >>
> >> Erik
> >>
> >> [0]
> >>
> http://hackage.haskell.org/package/multirec-0.7.5/docs/Generics-MultiRec-HFix.html
> >>
> >> On Tue, Mar 24, 2015 at 4:25 PM, David Feuer <david.feuer at gmail.com>
> >> wrote:
> >> > I have no comment on your higher-order version (because I don't
> >> > understand
> >> > it yet), but the type you give for hmap looks unlikely. Did you mean
> >> >
> >> > hmap :: (g :-> h) -> f g :-> f h ?
> >> >
> >> > On Mar 24, 2015 10:58 AM, "Erik Hesselink" <hesselink at gmail.com>
> wrote:
> >> >>
> >> >> On Tue, Mar 24, 2015 at 7:23 AM, M Farkas-Dyck <strake888 at gmail.com>
> >> >> wrote:
> >> >> > On 22/03/2015 at 23:01:47 -0400, David Feuer wrote:
> >> >> >> There are a good number of different packages that define either
> >> >> >>
> >> >> >> newtype Fix f = Fix (f (Fix f))
> >> >> >>
> >> >> >> or something equivalent except for naming. Most of the name
> >> >> >> variation
> >> >> >> is in the name of the data constructor and/or record selector.
> This
> >> >> >> does not look like an ideal situation to me. Most problematically,
> >> >> >> the
> >> >> >> only way to convert one to another is with unsafeCoerce.
> >> >> >>
> >> >> >> I think it would be rather nice to choose one canonical place for
> >> >> >> this
> >> >> >> definition, and let everyone else use it.
> >> >> >
> >> >> > +1
> >> >> >
> >> >> > I propose
> >> >> >
> >> >> > module Data.Fix where
> >> >> >
> >> >> > newtype Fix f = Fix { unFix :: f (Fix f) }
> >> >>
> >> >> I'm used to
> >> >>
> >> >> newtype Fix f = In { out : f (Fix f) }
> >> >>
> >> >> But all the other suggestions look fine to me, too.
> >> >>
> >> >> I've also often used this variation:
> >> >>
> >> >> newtype HFix f a = In { out :: f (HFix f) a }
> >> >>
> >> >> This allows you to take the fixed point of e.g. monad stacks and
> >> >> indexed types. The function you propose below can then be a type
> class
> >> >> function of an indexed Functor class:
> >> >>
> >> >> type f :-> g = forall a. f a -> g a
> >> >>
> >> >> class HFunctor f where
> >> >> hmap :: (a :-> b) -> f a :-> g a
> >> >>
> >> >> Does this deserve a place somewhere as well? Or is it too
> specialized?
> >> >>
> >> >> > Perhaps too we ought to name and define _ :: (∀ a . f a -> g a) ->
> >> >> > Fix f
> >> >> > -> Fix g there.
> >> >>
> >> >> Some variation of 'map' seems sensible, like 'hmap' (but see above)
> or
> >> >> 'mapFix'.
> >> >>
> >> >> Erik
> >> _______________________________________________
> >> Libraries mailing list
> >> Libraries at haskell.org
> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20150324/64cdc606/attachment.html>
More information about the Libraries
mailing list