I don't know how to set up ormolu for formatting, and I don't really have time to futz with that right now. Can someone help me out?

@aspiwack aside from the formatting thing, I think this is pretty much ready. It doesn't remove all the orphans, but that can be done in another PR or two.

I don't know how to set up ormolu for formatting, and I don't really have time to futz with that right now. Can someone help me out?

You should be able to format with ./format.sh at the root of the repo. It uses stack to fetch, build and exec ormolu on the codebase.

If you have Nix installed, you can $ nix-shell --run "./format,sh". Alternatively, if you have Stack installed, you can ./format.sh.

I pushed a formatting commit.

@tbagrel1 This is a pretty big patch, please give it a review, I'll do the same myself.

@aspiwack Do you remember the motivations behind the difference of organisation between Data.Functor.Linear.xxx modules and Control.Functor.Linear.xxx modules?

@aspiwack , you seem to be fighting a long term trend to prefer explicit and qualified imports to hiding in most cases. Why is that? The former are more robust in the face of additions to the imported modules.

@aspiwack , you seem to be fighting a long term trend to prefer explicit and qualified imports to hiding in most cases. Why is that? The former are more robust in the face of additions to the imported modules.

They are more robust, but in practice they cost more of my time. My inclination is to use qualified import as much as is reasonable (which will be easier when the Local Module proposal comes to fruition). But I prefer figuring out the occasional error, than preemptively making import list management something I have to care about on a daily basis.

@aspiwack Do you remember the motivations behind the difference of organisation between Data.Functor.Linear.xxx modules and Control.Functor.Linear.xxx modules?

I think @Divesh-Otwani found it easier to document modules when they were split into smaller chunks for me. I don't care much either way as long as we have a reasonably small list of modules to import in the user-facing land.

Note: when this is merged, it would be good to give @sjoerdvisscher credit for the substantial work he did on it before I showed up. As I recall, his most interesting contribution was generic derivation of control functors. I'm not sure how best to do that in the context of git with such a wild rebase.

@aspiwack ormolu chokes doing something or other with dependencies (constraints and hedgehog) that have CPP in their module export lists when I use the stack version. The nix thing is still compiling the world.

The nix formatting approach fails for me too.

@aspiwack ormolu chokes doing something or other with dependencies (constraints and hedgehog) that have CPP in their module export lists when I use the stack version. The nix thing is still compiling the world.

I formatted it. I got no issues with ormolu (but I already had it installed through format.sh a long time ago, so maybe there is something which prevents ormolu installation via stack now?).

Closes #316 .

Note: when this is merged, it would be good to give @sjoerdvisscher credit for the substantial work he did on it before I showed up. As I recall, his most interesting contribution was generic derivation of control functors. I'm not sure how best to do that in the context of git with such a wild rebase.

I believe that if you add the line

Co-authored-by: Sjoerd Visscher <firstname.name@tweag.io>

To the relevant commits' messages, then Sjoerd will appear – at least in Github – as a coauthor of the commits.

I think it's specifically at the end of the commit message. Github's documentation is here.

Thanks @tbagrel1 for taking care of the small issues. @treeowl do you have time to address the couple of request for extra comments? In either case, I plan to merge this tomorrow, and then we make a release :slightly_smiling_face: .

I think everything's sorted now.

(Unless I've broken some ormolu junk again, in which case I imagine you can fix it.)

Thanks!

I'm guessing the dance around unsatisfiable is necessary to make it representation-polymorphic. I don't have much of a grasp of why (or why the previous implementation worked). I'd be glad if you gave a few words about it in the thread.

Thanks!

I'm guessing the dance around unsatisfiable is necessary to make it representation-polymorphic. I don't have much of a grasp of why (or why the previous implementation worked). I'd be glad if you gave a few words about it in the thread.

Yes, partly to make it representation polymorphic to match what the GHC built-in version will do as closely as we can. The previous implementation had

unsatisfiable' :: Bottom => a

This was used at type

unsatisfiable' :: Bottom  => (##) -> q

where q is the actual desired result type.

What's the rest of the dance for? The "obvious" thing is to give unsatisfiable an Unsatisfiable e constraint. But this would not be ergonomical at all, and would not match the "magical" behavior of the future built-in version. Why? Because each invocation of unsatisfiable would then have to specify the type error, completely uselessly. By using Bottom, we avoid caring, at the call site, why we couldn't possibly have gotten there.