<div dir="ltr">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 ;)<div><br></div><div>- Ollie</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Mar 24, 2015 at 3:40 PM, Erik Hesselink <span dir="ltr"><<a href="mailto:hesselink@gmail.com" target="_blank">hesselink@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Ugh, you're right, I renamed the variables and made a mistake. The<br>
outer variable should stay the same of course, your signature is<br>
correct.<br>
<br>
For a use site of HFix, see the multirec package [0], although that<br>
might not really clarify things :) We also have a use internally, but<br>
I just realized we can probably simplify that away.<br>
<br>
Regards,<br>
<br>
Erik<br>
<br>
[0] <a href="http://hackage.haskell.org/package/multirec-0.7.5/docs/Generics-MultiRec-HFix.html" target="_blank">http://hackage.haskell.org/package/multirec-0.7.5/docs/Generics-MultiRec-HFix.html</a><br>
<div class="HOEnZb"><div class="h5"><br>
On Tue, Mar 24, 2015 at 4:25 PM, David Feuer <<a href="mailto:david.feuer@gmail.com">david.feuer@gmail.com</a>> wrote:<br>
> I have no comment on your higher-order version (because I don't understand<br>
> it yet), but the type you give for hmap looks unlikely. Did you mean<br>
><br>
> hmap :: (g :-> h) -> f g :-> f h ?<br>
><br>
> On Mar 24, 2015 10:58 AM, "Erik Hesselink" <<a href="mailto:hesselink@gmail.com">hesselink@gmail.com</a>> wrote:<br>
>><br>
>> On Tue, Mar 24, 2015 at 7:23 AM, M Farkas-Dyck <<a href="mailto:strake888@gmail.com">strake888@gmail.com</a>><br>
>> wrote:<br>
>> > On 22/03/2015 at 23:01:47 -0400, David Feuer wrote:<br>
>> >> There are a good number of different packages that define either<br>
>> >><br>
>> >> newtype Fix f = Fix (f (Fix f))<br>
>> >><br>
>> >> or something equivalent except for naming. Most of the name variation<br>
>> >> is in the name of the data constructor and/or record selector. This<br>
>> >> does not look like an ideal situation to me. Most problematically, the<br>
>> >> only way to convert one to another is with unsafeCoerce.<br>
>> >><br>
>> >> I think it would be rather nice to choose one canonical place for this<br>
>> >> definition, and let everyone else use it.<br>
>> ><br>
>> > +1<br>
>> ><br>
>> > I propose<br>
>> ><br>
>> > module Data.Fix where<br>
>> ><br>
>> > newtype Fix f = Fix { unFix :: f (Fix f) }<br>
>><br>
>> I'm used to<br>
>><br>
>>     newtype Fix f = In { out : f (Fix f) }<br>
>><br>
>> But all the other suggestions look fine to me, too.<br>
>><br>
>> I've also often used this variation:<br>
>><br>
>>     newtype HFix f a = In { out :: f (HFix f) a }<br>
>><br>
>> This allows you to take the fixed point of e.g. monad stacks and<br>
>> indexed types. The function you propose below can then be a type class<br>
>> function of an indexed Functor class:<br>
>><br>
>>     type f :-> g = forall a. f a -> g a<br>
>><br>
>>     class HFunctor f where<br>
>>       hmap :: (a :-> b) -> f a :-> g a<br>
>><br>
>> Does this deserve a place somewhere as well? Or is it too specialized?<br>
>><br>
>> > Perhaps too we ought to name and define _ :: (∀ a . f a -> g a) -> Fix f<br>
>> > -> Fix g there.<br>
>><br>
>> Some variation of 'map' seems sensible, like 'hmap' (but see above) or<br>
>> 'mapFix'.<br>
>><br>
>> Erik<br>
</div></div><div class="HOEnZb"><div class="h5">_______________________________________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org">Libraries@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br>
</div></div></blockquote></div><br></div>