Any chance to call Tango as Extended Standard Library

[Sean Kelly]

Benji Smith wrote:
> Don wrote:
>> Lars Ivar Igesund wrote:
>>> Don wrote:
>>> druntime should certainly not become any bigger (in scope), as that 
>>> would defeat the purpose of separating the runtime from userspace in 
>>> the first place. The topic of common userspace functionality should 
>>> be kept separate from the topic of druntime.
>>>
>>
>> I think you are confusing druntime (the project) with the D runtime. 
>> druntime includes the gc as well the runtime, though they are seperate.
>> I see no reason why including core modules in the druntime project 
>> would  destroy the seperation.
>>
>> Really, this is entirely a question of naming.
>>
>> core.XXX seems to me to be the perfect namespace, certainly for the 
>> key math modules which I'm most concerned about 
>> (std.math/(tango.math.Math, tango.math.IEEE), and possibly also the 
>> low-level bigint routines. These are all functionality which is 
>> closely tied to the compiler).
> 
> Totally agree.
> 
> Although the name 'druntime' implies it'll only contain the runtime, I 
> think it ought to contain all the common functionality that virtually 
> all applications and libraries will absolutely need: the runtime itself, 
> gc, TypeInfo, math, containers (including ranges), algorithms, string 
> processing, date/time, and IO.

After the dsource project was created, someone suggested using the name 
'd-core' instead--I think it's more appropriate than 'd-runtime'.  That 
aside, I personally see the visible portion of the runtime to be roughly 
similar to java.lang.  Basically, I think it should contain the stuff 
that's required for a D app to simply load and run, but anything that's 
sufficiently intrinsic to the language or language philosophy is 
appropriate as well.  In addition to what's already there, I think an 
argument could be made for a range definition, essential math routines, 
and probably  a few other things.  But things that are simply commonly 
used belong in the standard library.

> Without those commonalities, any "compatibility" between Phobos and 
> Tango will be purely illusory.

True enough.  But attempting to include all of the stuff you mentioned 
above would require design agreement between the Phobos and Tango folks 
on quite a bit in terms of API philosophy.

> Whether the commonality is realized within druntime, or within some 
> other low-level common library (like "dcore"), is immaterial to me. And 
> actually, I don't really care whether Phobos and Tango have their own 
> implementations. But there should be an API (interfaces? concepts? some 
> new template-interface mechanism? doesn't matter.) that both Phobos and 
> Tango implement, so that library consumers can seamlessly pass low-level 
> objects between Phobos and Tango dependent libraries.

I agree that this is a fine goal.  It just isn't a task I have any 
intention of pursuing, personally.


Sean