Add Data.Sequence.toList

[brandonchinn178]

Re-opening a thread for #744. I'm happy to email the libraries list for this

[chessai]

The libraries mailing list is archaic and mostly used now to request package takeovers or for CLC elections. Back in 2020 it was still used a lot more. I don't think posting there is necessary anymore.

[meooow25]

Is the motivation same as #744 (comment)?

I don't disagree with the points, but

• An alias introduces an unnecessary choice for the user
• The same motivations apply to all typeclass methods, how do we decide if a method deserves a monomorphic alias?

[brandonchinn178]

My major motivation here is consistency. Data.Set.toList is the same as Foldable.toList, thus Data.Sequence should match the same API.

[RossPaterson]

From the mailing list:

I do see that Map.toList /= Foldable.toList. But Set.toList == Foldable.toList, and it's not obvious to me why Set should have toList and not Seq.

I think the reason for the inconsistency is that Data.Map.toList and Data.Set.toList predate Foldable and Data.Sequence. Being half-consistent with this accident doesn't seem to be a compelling reason for this change. The change would also introduce an extra name clash (for the same underlying function) that would need tweaked imports, including in code that compiles now.

[brandonchinn178]

Ah thanks for the context, that makes sense. But I would still argue it's worthwhile to do, unless there's a plan to remove Data.Set.toList.

The same motivations apply to all typeclass methods, how do we decide if a method deserves a monomorphic alias?

IMO conversion functions like toList/fromList should be exceptional, since it's an API boundary between two types, where type ambiguity is most likely to appear. I'd also argue that Seq.toList == Foldable.toList is an implementation detail, and the two have different semantic meanings.

[meooow25]

But I would still argue it's worthwhile to do, unless there's a plan to remove Data.Set.toList.

We could remove it, but to me it's not a strong-enough reason to make a breaking change.

The change would also introduce an extra name clash (for the same underlying function) that would need tweaked imports, including in code that compiles now.

This may be true, but exporting a new function is not a breaking change according to PVP (https://pvp.haskell.org/), so it is less of a concern.

IMO conversion functions like toList/fromList should be exceptional, since it's an API boundary between two types, where type ambiguity is most likely to appear.

I think this a reasonable argument in favor. @treeowl @Lysxia any thoughts on this?