LJC Lambdas Hackday

[Richard Warburton]

> Thanks for the effort and the writeup!  This has been extremely helpful for
> us!

Glad to help.

> And now you've discovered the reason why it is not yet implemented :) Our
> story for primitives is still being mapped out, and there are a number of
> options here.  If we choose to go in the direction of specializing streams
> for the common primitives (Int/Long/DoubleStream), then the sum() method
> would live there and its type would be obvious. Another alternative is to
> fuse mapping and reducing into a single operations, and have a
> sumBy(IntMapper<T>) operation.

I think it might well be useful to have sum operate over types
generally.  So if you have a Stream<T> and can provide a Mapper<T,T>
then you can sumBy generally.  Obviously there are a variety of
mathematical structures that you might want to sum that aren't
primitives - for example a vector.  I'd probably expect that many
domain objects are the kind of things that you want to sum over as
well in some cases.  Presumably any domain object that's a commutative
monoid is safe for this kind of stuff?

In these cases I think its safe for the signature of sumBy to be:

<T> T sumBy(Iterable<T> values, Mapper<T,T> summer)

And people can provide their definition of the summer function,
instead of explicitly restricting the type of <T> to things that you
can already syntactically do t1 + t2 on.

> Yes, this is one of the key education points we need to address. Laziness
> can be surprising, and the sorted() method is among the weirdest (it is lazy
> in the sense that no computation happens when you call sorted(), but eager
> in the sense that much or all of computation has already happened by the
> time the first element comes out.)

Yeah - I think that's the kind of thing that's absolutely fine -
provided it says so in the Javadoc.  I guess what I'm saying is that
you want to avoid the situation that new haskell programmers sometimes
find themselves in - when their brilliant 1 line fibonacci function
has just finished calculating the 1 billionth fibonacci instantly, but
they are stuck wondering it takes them hours to print that number out.

> We've come to the conclusion that putting these methods on Iterable<T> makes
> the confusion surrounding laziness worse, given that most Iterables (though
> not all) are backed by data structures and this colors our thinking.
>  Instead, the Stream abstraction should behave more like an Iterator, and I
> think this will help a lot -- if filter returns a Stream, the idea that it
> will be lazily computed comes more readily to mind.

I think this makes a lot of sense, hopefully we can gauge its effect
on how easy it is for people to understand things with another lambda
hackday at some point.

> Agreed.  I always felt that the "one letter rule" was borne of a delusion
> that type parameters would only be used in obvious ways, such as the
> elements of a collection.  But we passed that long ago, and we should
> acknowledge it.

Exactly.

regards,

  Richard