My concern here isn't efficiency. Data.Sequence.toList should just be a
reexport of Foldable.toList monomorphized to Seq. I just want a consistent
API with other modules in containers.
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.
On Sat, Mar 7, 2026, 3:37 PM Dan Dart
Well, it's got a Foldable instance already, which gives you a toList for anything Foldable, is it going to get any more efficient than this one? That's one of the few reasons to add extra functions already covered by type class instances, no?
Cheers
On Sat, 7 Mar 2026, 23:20 ,
wrote: An issue was opened on containers back in 2020 to add a monomorphic Data.Sequence.toList function: https://github.com/haskell/containers/issues/744. It was suggested to ask via the libraries list, and the previous reporter preferred to close the issue instead of continuing the process. I'm opening it back up: https://github.com/haskell/containers/issues/1184. Same motivation as the original issue; specifically, I always workaround this with
import Data.Foldable qualified as Seq (toList) import Data.Sequence (Seq) import Data.Sequence qualified as Seq
It's odd that Data.Sequence doesn't provide toList when Map and Set do. Are there any objections to this?
Best, Brandon Chinn _______________________________________________ Libraries mailing list -- libraries@haskell.org To unsubscribe send an email to libraries-leave@haskell.org
I second this addition. Though I will note that there are potential
performance improvements to be had for a monomorphic version due to
specialisation and inlining - I typically prefer mononorphic toList when
available. This and API uniformity are sufficient motivations to me (even
just API uniformity alone).
Brandon, 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. I don't think posting here is necessary anymore (and it was almost
never productive).
Cheers,
chessai
On Sat, Mar 7, 2026, 3:56 PM Brandon Chinn
My concern here isn't efficiency. Data.Sequence.toList should just be a reexport of Foldable.toList monomorphized to Seq. I just want a consistent API with other modules in containers.
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.
On Sat, Mar 7, 2026, 3:37 PM Dan Dart
wrote: Well, it's got a Foldable instance already, which gives you a toList for anything Foldable, is it going to get any more efficientlythan this one? That's one of the few reasons to add extra functions already covered by type class instances, no?
Cheers
On Sat, 7 Mar 2026, 23:20 ,
wrote: An issue was opened on containers back in 2020 to add a monomorphic Data.Sequence.toList function: https://github.com/haskell/containers/issues/744. It was suggested to ask via the libraries list, and the previous reporter preferred to close the issue instead of continuing the process. I'm opening it back up: https://github.com/haskell/containers/issues/1184. Same motivation as the original issue; specifically, I always workaround this with
import Data.Foldable qualified as Seq (toList) import Data.Sequence (Seq) import Data.Sequence qualified as Seq
It's odd that Data.Sequence doesn't provide toList when Map and Set do. Are there any objections to this?
Best, Brandon Chinn _______________________________________________ Libraries mailing list -- libraries@haskell.org To unsubscribe send an email to libraries-leave@haskell.org
_______________________________________________ Libraries mailing list -- libraries@haskell.org To unsubscribe send an email to libraries-leave@haskell.org
I support this change largely for the motivations originally described
https://github.com/haskell/containers/issues/744#issuecomment-689484639,
particularly predictability and safety.
I can't immediately think of a way this addition would be a liability.
-Rick
On Sat, Mar 7, 2026 at 9:01 PM chessai
I second this addition. Though I will note that there are potential performance improvements to be had for a monomorphic version due to specialisation and inlining - I typically prefer mononorphic toList when available. This and API uniformity are sufficient motivations to me (even just API uniformity alone).
Brandon, 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. I don't think posting here is necessary anymore (and it was almost never productive).
Cheers, chessai
On Sat, Mar 7, 2026, 3:56 PM Brandon Chinn
wrote: My concern here isn't efficiency. Data.Sequence.toList should just be a reexport of Foldable.toList monomorphized to Seq. I just want a consistent API with other modules in containers.
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.
On Sat, Mar 7, 2026, 3:37 PM Dan Dart
wrote: Well, it's got a Foldable instance already, which gives you a toList for anything Foldable, is it going to get any more efficientlythan this one? That's one of the few reasons to add extra functions already covered by type class instances, no?
Cheers
On Sat, 7 Mar 2026, 23:20 ,
wrote: An issue was opened on containers back in 2020 to add a monomorphic Data.Sequence.toList function: https://github.com/haskell/containers/issues/744. It was suggested to ask via the libraries list, and the previous reporter preferred to close the issue instead of continuing the process. I'm opening it back up: https://github.com/haskell/containers/issues/1184. Same motivation as the original issue; specifically, I always workaround this with
import Data.Foldable qualified as Seq (toList) import Data.Sequence (Seq) import Data.Sequence qualified as Seq
It's odd that Data.Sequence doesn't provide toList when Map and Set do. Are there any objections to this?
Best, Brandon Chinn _______________________________________________ Libraries mailing list -- libraries@haskell.org To unsubscribe send an email to libraries-leave@haskell.org
_______________________________________________ Libraries mailing list -- libraries@haskell.org To unsubscribe send an email to libraries-leave@haskell.org
_______________________________________________ Libraries mailing list -- libraries@haskell.org To unsubscribe send an email to libraries-leave@haskell.org
participants (3)
-
Brandon Chinn -
chessai -
Rick Owens