Hi,
I played around and tried to implement something like the ranges in D. You can find the result here https://gist.github.com/AdrianV/5397444
from playing around I felt again that Nimrod needs to have interfaces. When you look at the example code I did not define any basic range type, instead I used the overloading and generic power of Nimrod. This works fine so far - but if you look at the iterator elements at the end you will see why interfaces would be nice:
The problem in this example is that I cannot declare the abstract range to be of certain type [T]. When we had something like interfaces I could write:
type
range[T] = interface
empty: proc() : bool
front: proc(): T
popFront: proc()
TSeqRange* [T] = ref RSeqRange[T] implements range[T]
...
and later
iterator items [T] (ran: range[T]): T {.inline.} =
# since it is an interface all its procs are pulled in like mixin empty, front, popFront
while not empty(ran):
yield front(ran)
popFront(ran)
cheers, Adrian.
The feature you want here are more expressive type constraints; and indeed that's a planned feature. However, implementing an iterator via a range is blasphemy. ;-) I can't see why you would want that as implementing an iterator directly is much less work. And if code size is your concern, you now can use a first class ("closure") iterator instead of an inline iterator.
Proper interfaces imply runtime polymorphism which I'm not a fan of for various reasons. Having real interfaces in the language would encourage their usage and what's worse programmers consider them "clean" and good style. Alas, they are not.
sorry for the blasphemy, but I didn't want to create an iterator in first place - I wanted to create an inputrange and the iterator is an example where I failed (maybe not a good example, because the iterator is not needed) and thought a lightweight interface (or abstract type or whatever you call it) would be nice. With mixin you can declare, that you need empty, popFront and front, but not that empty returns bool, front returns a T (here the iterator fails) from the range and popFront which returns void.
So mixin is nice, but not enough. IMHO an abstract type (I call it now abstract type, because I am not talking about runtime polymorphism) would be better, because it could hold all the information needed:
I hope my intention is now a little bit clearer.