haskell prelude

[Brian Goetz]

Such "marker" interfaces mostly just give you a false sense of 
confidence, because markers can easily "wash off".  For example, let's 
say you transform an Iterator<T> to an Iterator<U> via a mapping 
function from T -> U.  (See Iterators.map for example code.)  That's 
trivial to write, but now the resulting Iterator no longer extends 
InfiniteIterator.  Oops.

Trying to use the static type system to express dynamic properties is a 
losing game.  (As a cautionary tale, see serialization, which has played 
this game and lost.)



On 6/22/2012 5:00 PM, David Conrad wrote:
> On Fri, 22 Jun 2012 09:29:19 +0300, Olexandr Demura<
> oleksander.demura at gmail.com>  wrote:
>
>>
>> that library written with haskell laziness in mind which is not present in
>> java.
>> you can add additional laziness by replacing `fibs.eval(y, z + y)`
>> with Iterable `() ->  fibs.eval(y, z + y).iterator()`,
>> but that would not help, since `cons` requests iterator immediately,
>> causing the same problem.
>> so you need one more additional layer - lazy Iterator.
>> but Iterator is not a SAM, so it can't be named elegant:
>>
>>
>
> It is possible, and maybe even advisable, to make a SAM
> type which is a subtype of Iterator, for infinite sequences:
>
>
> interface InfiniteIterator<E>  extends Iterator<E>  {
>      boolean hasNext() default {
>          return true;
>      }
> }
>
> interface InfiniteIterable<E>  extends Iterable<E>  {
>      InfiniteIterator<E>  iterator();
> }
>
>
> This has the great advantage that it also provides a tagging
> Interface that one can check for in Iterables::count or
> Iterables::forEach or a hypothetical Iterables::last(int n) or
> other places where blindly consuming an infinite sequence
> would do Bad Things(TM).
>
> If this became idiomatic and standard APIs looked for it, it
> might head off some problems.
>
> David
>