Re: Gee Functional iterators

[Martin DeMello <martindemello gmail com>]

On Wed, Jul 14, 2010 at 9:01 AM, Maciej Piechotka <uzytkownik2 gmail com> wrote:
> On 13/07/10 17:23, Didier 'Ptitjes' wrote:
>> All in all, breaking the ABI/API is not a problem, as we still have at
>> least one anticipated round of developement where we do expect to break
>> the ABI. So don't let that limit your imagination/creativity/engineering...
>
> I've done some thinking and I'm somehow unhappy about current
> Iterator<G> design (I was discussing it before but it wasn't so big
> problem as it was on iterator-as-primary-thing-we-operate-on). I know
> that would be a big change in interface so it may be something we should
> be really careful.

Here's another idea, that will preserve the "collection as atomic
unit" behaviour, but avoid creation of multiple temp arrays:

We could divide the enumerable methods into two classes, "lenses",
that layer a lazy transformation over a collection, and evaluators,
that force the transformation.

A lens would be any method with the signature f : Collection <A>, fn
(A, int -> Maybe A) -> Collection <A>, that is, it takes a function
that can map and/or filter individual elements, to return a new
collection. The passed in function should take both an element and an
index, to allow for methods like take and drop

An evaluator would either be the special method `collect`, which just
transforms a collection via its nested collection of lenses (e.g. b =
a.map(f).filter(g).map(h).collect()), or a function of the form
Collection <A> , B, fn (A, B, int -> B) -> B, which reduces the
collection to a scalar (e.g. fold or count).

That should get around the problems associated with giving the user
the intermediate iterators, while not unnecessarily allocating.

Also, now that vala has support for generic delegates, we can try
playing with a very simple Collection -> Collection set of methods,
just to get a feel for the api.

martin