Ranges

[Lutger]

Yigal Chripun wrote:

> Lutger wrote:
>> Yigal Chripun wrote:
>> ...
>>> IMHO, duck-typing in D is a tragic mistake...  This should have been
>>> implemented with compile time interfaces.
>> 
>> Care to provide arguments?
>> 
>> 
> 
> duck typing makes more sense in dynamic languages like Ruby which is
> famous for it.
> 
> in static languages I as a user prefer to trade flexibility due to
> duck-typing for compile time checks.
> 
> yes, at compile time, duck typing and (compile-time) interfaces are
> basically the same thing, but since the rest of the language uses formal
> interfaces, it is more consistent (and easier to understand) to use the
> same approach at compile-time as well. point in case, look how much
> unnecessary confusion Ranges cause which would be eliminated had D
> allowed for compile-time interfaces.
> i.e.
> Interface I { .. }
> struct S : I { ... }
> this is basically the same as C++ concepts only without redundant and
> confusing syntax.

Not sure what that would do, but C++ concepts are not exactly compile time 
interfaces. This is very important: in C++0X, a type T which satisfies the 
concept Comparable<T> does not implement the concept explicitly, whereas 
languages with explicit constraints on generics do require T to be inherited 
from IComparable. The consequence is a bit of bloat and more rigid demands 
on what is supposed to relax the inflexible regime of the static type 
system. This bloat and rigidity is also a cognitive burden in it's own 
right, for example when it requires workarounds when the system is not 
expressive enough. 

Concepts provide two benefits in this context: documentation and extra type 
checking for templates. But they do retain structural typing. In D, we 
already have this covered with template constraints.* If you look at 
std.range, this is exactly what you see: all the interfaces (and even 
semantics) are nicely named and documented explicitly. So would we have had 
compile time interfaces, they would add next to nothing about the 
documentation or understanding of ranges.
 
> templates are hard for users to understand and one of the main reasons
> for this is that templates are essentially a completely different
> language with different syntax and semantics which to me looks like
> mis-design.

I don't think it is hard to understand because of structural typing.  
Generics are inherently somewhat difficult in a static typing language, 
because of it's abstract nature. You don't have this problem in dynamic 
languages. (or you can't escape it, depending on your POV)

I don't agree that templates are a completely different language though. 
When used purely for parametric polymorphism, it does integrate nicely in 
the normal type system. When you do use it for meta-programming, which is 
relatively rare, then the above also applies: this is an inherently 
difficult way of programming. Just look at something like lisp where you can 
metaprogram in the same language. Does that make it easy to understand? Or 
CTFE and string mixins in D, same language, but it's also difficult. Adding 
more constraints can never solve the fact that humans don't easily grok 
programs which generate programs. 

* I don't think the extra type checking is done, but perhaps it could be.