Should everything in purescript-prelude be exported in Prelude?

[milesfrain]

If I want to use lift2, I need to import it from Control.Apply, even though it's part of purescript-prelude. Is this intentional, or should we expect everything in purescript-prelude to be reexported in Prelude?

Usually this is a non-issue when working in an IDE with auto-imports. But it becomes annoying in the repl and in TryPureScript. If I find a function on Pursuit that's part of purescript-prelude I don't know whether I need to explicitly import it without digging into Prelude. For example, these functions appear to be similarly available in Prelude from the initial Pursuit results:

• add, purescript-prelude, Data.Semiring
• lift2, purescript-prelude, Control.Apply

[hdgarrood]

That is intentional, yes; we don't expect everything to be re-exported by Prelude. The idea is that stuff should only get re-exported by Prelude if it's something we expect people to use often enough that they don't need a hint (in the form of a separate import) to remember what it is and where it comes from.

I'm sure there are some cases you could point to where there are things which maybe deserve more to be in Prelude and other things which don't deserve to be in Prelude, but realistically changing these would cause more harm than good, so to an extent it's the way it is because it just is. Of course it's fairly easy to see how removing things from Prelude could cause pain downstream, but it's worth noting that adding things to Prelude can cause pain too - if I add an identifier to Prelude, but someone was already using that identifier for something else, their project will start producing warnings when they update.

I think if you want to know whether a function is exported by Prelude, it should be fine to just import Prelude and try to use it? If it fails, then you know you need to import something else.

[ursi]

You actually can't expose everything in prelude, as there is at least one case of overlapping names - apply and apply.