Any chance to call Tango as Extended Standard Library

[Andrei Alexandrescu]

Lars Ivar Igesund wrote:
> Andrei Alexandrescu wrote:
> 
>> Lars Ivar Igesund wrote:
>>> Andrei Alexandrescu wrote:
>>> 
>>>> Lars Ivar Igesund wrote:
>>>>> Andrei Alexandrescu wrote:
>>>>> 
>>>>>> For example, I'm not sure how code in std.algorithm could 
>>>>>> help containers or streams in Tango (as it should), or how 
>>>>>> to reconcile std.algorithm with std.core.array.
>>>>> If the language (D2++) will have a new way of iteration and 
>>>>> ranges known and enforced by the compiler, then I expect 
>>>>> Tango to support those at some point, and std.algorithm would
>>>>>  presumably just work. However, if it is based on some 
>>>>> interface, ad hoc (these methods must be present) or properly
>>>>>  via an interface Range { }, I would expect Tango developers 
>>>>> to be involved in the process of defining those interfaces 
>>>>> (if Tango is meant to use/know about them). Since I have seen
>>>>>  neither, it is somewhat difficult to make a well informed 
>>>>> comment on the subject.
>>>> It's been there for a while now (since 25 Nov 2008).
>>>> 
>>>> http://www.digitalmars.com/d/2.0/statement.html#ForeachStatement
>>>> 
>>>> 
>>>> 
>>>> Scroll down to "Foreach over Structs and Classes with Ranges". 
>>>> The changelog reflects that too:
>>>> 
>>>> http://www.digitalmars.com/d/2.0/changelog.html
>>>> 
>>>> Version 2.021 mentions "Added range support to foreach 
>>>> statement."
>>> Ah, thanks :)
>>> 
>>> However, replacing the "single" opApply with 5 properties seems 
>>> somewhat excessive? At least it becomes even more obvious that a 
>>> form of (runtime queryable) struct interfaces will be necessary -
>>>  the one and only feature I really really want in D2.
>> opApply was very inefficient and defining an abstraction that 
>> allows efficient iteration was a key goal of range design and 
>> foreach overhaul. Using duck typing and implicit interfaces was a 
>> tried and true technique. On top of this framework it is easy to 
>> define and use explicit interfaces. Using classic interfaces would 
>> have hamstrung efficiency of iteration from day one.
>> 
>> I'd be curious to find out more about a runtime queryable struct 
>> interface. How would it work? What idioms would it enable?
> 
> The point is that with classes and interfaces, you can query the 
> class (at runtime) for whether it contains a certain set of 
> functionality.

I think there are a number of confusions and misunderstandings at work
here on top of one another, so allow me to try and clarify a couple.

"Five properties versus one opApply seems excessive. Therefore, a
form of runtime-queryable interface for struct is necessary."

The latter doesn't follow from the former. If five properties in an
implicit interface seems too many, then what you might be asking for is 
explicit interfaces, not dynamic-polymorphic interfaces. Something along 
the lines of:

interface InputRange(T)
{
     void next();
     bool empty();
     T head();
}

struct RandomGenerator : InputRange!(int) { ... }
class IntStream : InputRange!(int) { ... }

The two would follow different implementation strategies. For structs 
the interface would be statically checked. In all likelihood, this 
feature will be part of D2 because it allows for easy concept checking.

> Now, I know that the virtuality of doing so isn't the most efficient
> in most cases, but that is besides the point - if there is an
> efficient way of doing this with structs, then that should work with
> classes too.

This I don't understand at all. Yes, implicit interfaces do work with 
structs and classes and equally well.

> When you have functionality (at runtime) that relies only on a 
> container to have a specific set of functions/properties/methods, 
> then it seems unfair to restrict that to classes. In practice I see 
> this as something that operates via additional type info.

I confess I read this one more than a few times and couldn't understand 
it. So let me read it back in my own words: "You want to implement 
runtime functionality (?) by relying on the existence of a specific set 
of functions/properties/methods. It is unfair to restrict that to 
classes, so I'd like that to work for structs too. The way I see this 
working is by adding extra type info to structs." This doesn't do 
anything in terms of clarifying things for me, so I'd appreciate more info.


Andrei