Lst<A> : ISeq<A> ?

[StefanBertels]

Hi,

after using some more Freeze and ToSeq I wonder:

Is there a special reason why Lst<A> does not implement ISeq<A>?

There maybe is some reason (implementation problem?) and we probably get into hell some day for overloading all and everything (how to tell which variant of Match..., compare #275).
So this is no feature request, but just a question from conceptional view point.

[louthy]

Is there a special reason why Lst does not implement ISeq?

In some ways I regret making ISeq. The core idea was that Seq would be the 'root' type (which is borne out in the return types for the methods). Seq can actually wrap Lst:

var xs = List(1,2,3);
var sq = Seq(xs);

Behind the scenes sq is a SeqLst(xs), i.e. it maintains the Lst and gives it all the powers of a Seq. This is very, very low cost, there's no major conversion going on, just an allocation of SeqLst.

The main reason for doing this (creating SeqLst, SeqList, SeqArray, etc.) was to have a type that acted like IEnumerable but could also understand the underlying structures and make relevant optimisations.

For example Count doesn't need to use Head and Tail to loop through each item in the collection, it can make use of the fact that SeqLst already knows what the count of items are.

It also deals with windows into the collections. i.e sq.Skip(5).Take(10) will return a new SeqLst(xs, 5, 10) which uses the same Lst as sq.

So, yes the Lst type could implement Seq, but it wouldn't be able to carry those same optimisations as SeqLst; well, it could, but I think the behaviour would be 'surprising'.

[StefanBertels]

Thanks for giving details!