Fixing Fix

[Erik Hesselink]

Ah, thanks. That was confusing indeed, especially since the package on
hackage says "Author: Edward A. Kmett" as well. The unreleased library
does look like a good place for HFix (IFix).

Erik

On Tue, Mar 24, 2015 at 6:00 PM, Oliver Charles <ollie at ocharles.org.uk> wrote:
> 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
>> >
>> >
>
>