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 wrote:

In that case I must have misunderstood what the automatic migration would be.

On Sat, Feb 9, 2019, 2:56 PM Carter Schonwald

...

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 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

...

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@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries