bradrn

Thank you! I've actually been thinking of opening this as an issue for a while, so it's nice to see you've already thought of it.

Actually, I've just seen that this is from 3 months ago (I didn't see that in my last comment). Do you have any idea as to when this will be...

@neongreen Can you elaborate on those tradeoffs? Perhaps if they get discussed here we might be able to find a solution which everyone's happy with. I know I'd be prepared...

@neongreen I don't know much about this area of `lens`, but here's what I think: > * Most prisms and isos live in typeclasses (`_Cons`, `_head`, `_Empty`, `_Wrapped`, `strict`, `swapped`)....

> > Is there any reason not to include those typeclasses? > > The primary reason is that either we can't provide any instances, or we have to depend to...

@neongreen I think that summarises quite well the essential tradeoffs involved in `microlens`. _Either_ we remain compatible with `lens`, _or_ we make `microlens` easy to use. Going forward I think...

> The "platform" in microlens-platform stands for "Haskell platform", not "all microlens packages". I didn't know this! I thought it was just all the microlens packages together. It's probably worth...

That's interesting - I knew `profunctors` was a large library, but I didn't know it was _that_ large. In that case, if `profunctors` already depends on most of the Haskell...

> I'd rather not do that. Yes, I agree; it was a stupid idea in the first place. ---- Anyway, since `profunctors` does come with most of the platform, it...

So to confirm: the final plan is to re-export all of `microlens-platform` from `microlens-pro`, but hiding name clashes? To be honest, if that's the final plan, I don't really see...