add map back to Functor

[Carter Schonwald]

All good :) , complicated stuff is hard to communicate.  I and likely
others always benefit from more practice and folks comfortably asking
questions spurred by ambiguity

By migration in this context I think we all mean / desire a way to change a
name / definition in such a way that the new name / interface works,  but
also that all previous code still works, as well as code that’s a
combination of both old and new also works.

Such a mechanism or set of such tools (vaguely described as they are here
), is what I mean.

So  we mean migration of meaning or underlying language spec, while not
breaking perfectly great code

On Sat, Feb 9, 2019 at 3:19 PM Elliot Cameron <eacameron at gmail.com> wrote:

> In that case I must have misunderstood what the automatic migration would
> be.
>
> On Sat, Feb 9, 2019, 2:56 PM Carter Schonwald <carter.schonwald at gmail.com
> wrote:
>
>> No... the point of such an extension would be that no code that already
>> works would need to change.  Except to the extent
>>
>>
>> If I’m not understanding your misapprehension,
>> Could you lay out a specific micro example ?
>>
>> On Sat, Feb 9, 2019 at 8:07 AM Elliot Cameron <eacameron at gmail.com>
>> wrote:
>>
>>> Even with a tool to automate it I know many authors would be very
>>> disturbed by such a huge diff in their code. On larger teams with many
>>> active branches this kind of sweeping change is quite difficult to maneuver.
>>>
>>> On Fri, Feb 8, 2019, 4:42 PM Bardur Arantsson <spam at scientician.net
>>> wrote:
>>>
>>>> On 08/02/2019 19.45, Edward Kmett wrote:
>>>> > If we had a way (say a pragma or other syntactic form) to say that
>>>> fmap
>>>> > and map were somehow the 'same name' or something and so that defining
>>>> > one was the same as defining the other, so that this tax didn't
>>>> exist, I
>>>> > could see how we might get there.
>>>> >
>>>>
>>>> +1 for "the way"
>>>>
>>>> Most of these 'migrations' which are mostly syntactic should be
>>>> automatable and really should be *automated* via some sort of tool
>>>> support. I still haven't experienced a language where this sort of thing
>>>> "just works", but IMO gofix and scalafix have sort of the right idea.
>>>>
>>>> (In Haskell we have the luxury of 'only' having to guarantee source
>>>> compatibility.)
>>>>
>>>> If people are worried about having to add CPP sections, then I would
>>>> submit it's very possible to convert diffs (between pre-fix to post-fix)
>>>> to CPP. That, or one can usually create a *-compat library which
>>>> contains the CPP and just use that as a dependency. Ugly, yes, but in
>>>> practical terms it seems to be quite simple.
>>>>
>>>> Regards,
>>>>
>>>> _______________________________________________
>>>> Libraries mailing list
>>>> Libraries at haskell.org
>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>>>
>>> _______________________________________________
>>> 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/20190209/a2c6f388/attachment.html>