Latest v5 alpha IEnumerable<T> ToSeq() extension is missing

[kirill-gerasimenko-da]

Hi!

A quick question - is extension method ToSeq() on IEnumerable<T> gone? I can't seem to find it. I can do AsEnumerableM() and the ToSeq() on that, but can't find the original extension method.

Is this intentional?

Thanks!

[louthy]

It is intentional. ToSeq is now part of the Foldable<F> trait. Which also means there's a ToSeq extension method that is constrained to Foldable<F>:

public static Seq<A> ToSeq<T, A>(this K<T, A> ta) 
    where T : Foldable<T> =>
    T.ToSeq(ta);

This allows any foldable to be converted to a Seq. Which is awesome, but it comes at a cost.

The original extension that worked with IEnumerable (below) can cause extension method resolution issues. If the type is both an IEnumerable<A> and a K<T, A> then the compiler doesn't know which one to pick: making ToSeq() fail for common types like Lst<A>, Arr<A>, etc.

public static Seq<A> ToSeq<A>(this IEnumerable<A> items) =>
   ...

The one type this is a major problem for is IEnumerable<A>, because it's the most common collection interface and it's not under my control. So, there are a number of solutions (as well as others that I am considering):

• AsEnumerableM() - is a new extension method that converts IEnumerable<A> to EnumerableM<A>
  • EnumerableM<A> is a wrapper for IEnumerable<A> that has trait-implementations (including Foldable<EnumerableM>)
  • That means you can call: .AsEnumerableM().ToSeq() to get to a Seq<A>
  • Nearly everything else in language-ext that returned an IEnumerable now returns an EnumerableM instead.
• You can also use toSeq(enumerable) from the Prelude will still convert from an IEnumerable<A> directly to a Seq<A>
• Or, you could consider adding your own convenience extension, like AsSeq that invokes toSeq(enumerable).

I am also considering re-adding some extension method (with an alternative name), because I too have found the lack of ToSeq extension particularly frustrating. I haven't yet thought of a name I'm happy with, AsSeq for me implies a cost-free conversion whereas ToSeq implies an action that converts.

Another approach is to change AsEnumerableM (which is quite long and ugly) to As (like the trait down-casts). That would make conversion between IEnumerable<A> and EnumerableM<A> feel lighter and make conversion to Seq<A> look like this:

enumerable.As().ToSeq()

My only issue with that is that I'd prefer to not overdo the As() thing. It may cause some confusion between the trait down-casts and just general value transformation. An alternative name might be Iso() for isomorphism. Anything that supported an isomorphism could have that as an extension, but it could also be a little obscure.

Other thoughts are that the trait members could have an alternative name, like ToSeqF, but there's already ToSeqT for nested foldables, do I then have ToSeqFT, urggh!

Naming things is hard!

Anyway, it is on my mind, I'm just not sure what my solution will be yet.

[louthy]

On thing I forgot to add. If the type you're calling ToSeq() on is under your control, then you can just implement the Foldable<YOUR_TYPE> trait to have ToSeq() work.

Below is a simple binary tree implementation:

public abstract record Tree<A> : IEnumerable<A>
{
    /// <summary>
    /// Empty binary tree
    /// </summary>
    public static readonly Tree<A> Empty = new Empty<A>();
    
    /// <summary>
    /// Add an item to the tree
    /// </summary>
    public abstract Tree<A> Add(A value);

    /// <summary>
    /// Traverse the tree left-node-right
    /// </summary>
    internal abstract IEnumerable<A> LeftNodeRight();
    
    /// <summary>
    /// Traverse the tree right-node-left
    /// </summary>
    internal abstract IEnumerable<A> RightNodeLeft();
    
    /// <summary>
    /// Standard enumerator - left/node/right 
    /// </summary>
    public IEnumerator<A> GetEnumerator() => 
        LeftNodeRight().GetEnumerator();
    
    /// <summary>
    /// Standard enumerator - left/node/right 
    /// </summary>
    IEnumerator IEnumerable.GetEnumerator() => 
        GetEnumerator();
}

/// <summary>
/// Tree node
/// </summary>
/// <param name="Value">Value stored</param>
/// <param name="Left">Left branch</param>
/// <param name="Right">Right branch</param>
public record Node<A>(A Value, Tree<A> Left, Tree<A> Right) : Tree<A>
{
    public override Tree<A> Add(A value) =>
        Comparer<A>.Default.Compare(value, Value) switch
        {
            0   => throw new Exception("Value already added"),
            < 0 => new Node<A>(Value, Left.Add(value), Right),
            > 0 => new Node<A>(Value, Left, Right.Add(value))
        };

    internal override IEnumerable<A> LeftNodeRight()
    {
        foreach (var item in Left.LeftNodeRight()) yield return item;
        yield return Value;
        foreach (var item in Right.LeftNodeRight()) yield return item;
    }

    internal override IEnumerable<A> RightNodeLeft()
    {
        foreach (var item in Right.RightNodeLeft()) yield return item;
        yield return Value;
        foreach (var item in Left.RightNodeLeft()) yield return item;
    }
}

/// <summary>
/// Empty tree node
/// </summary>
/// <typeparam name="A"></typeparam>
public record Empty<A> : Tree<A>
{
    public override Tree<A> Add(A value) =>
        new Node<A>(value, Empty, Empty);

    internal override IEnumerable<A> LeftNodeRight() =>
        [];

    internal override IEnumerable<A> RightNodeLeft() => 
        [];
}

We can make that into something that can be converted to a Seq<A> like so:

public class Tree : Foldable<Tree>
{
    public static S FoldWhile<A, S>(
        Func<A, Func<S, S>> f,
        Func<(S State, A Value), bool> predicate,
        S state,
        K<Tree, A> ta)
    {
        foreach (var item in ta.As().LeftNodeRight())
        {
            if (!predicate((state, item))) return state;
            state = f(item)(state);
        }
        return state;
    }

    public static S FoldBackWhile<A, S>(
        Func<S, Func<A, S>> f, 
        Func<(S State, A Value), bool> predicate, 
        S state, 
        K<Tree, A> ta) 
    {
        foreach (var item in ta.As().RightNodeLeft())
        {
            if (!predicate((state, item))) return state;
            state = f(state)(item);
        }
        return state;
    }
}

And make Tree<A> derive from K<Tree, A>:

public abstract record Tree<A> : IEnumerable<A>, K<Tree, A>

Now Tree<A> supports all these functions, including ToSeq.

So, if you have IEnumerable based types then it's definitely worth the effort to add foldable trait implementations.

[kirill-gerasimenko-da]

Thanks for your reply!

Maybe the whole EnumerableM could be named as Iterator 🤷‍♂️

[louthy]

Maybe the whole EnumerableM could be named as Iterator

If I were to go that route, I'd call it Iterable, which I'm not totally against. The M suffix was going to be a convention I would take forward for types that are wrapped to enable the addition of traits. M mostly because they'd end up as monads, but it could easily be K too, I guess. I need to avoid T as a suffix as that's a convention for transformers and nested-type extensions.

The other example that exists so far is StringM that implements the StringM<SELF> trait - which itself implements: IdentifierLike<SELF, string>, IEquatable<SELF>, IComparable<SELF>, ISpanParsable<SELF>, OrdString<SELF>, and Monoid<SELF>.

Iterable could well be a special-case exception to the convention, what with enumerables being so fundamental.

I'll move this to the discussions section. Anybody else has an opinion on this I am definitely open to your thoughts and ideas. Whatever is chosen just needs to be as elegant as it can be!