The Death of D. (Was Tango vs Phobos)

[Lars Ivar Igesund]

Yigal Chripun wrote:

> Lars Ivar Igesund wrote:
>> Lutger wrote:
>> 
>>> Lars Ivar Igesund wrote:
>>>
>>>> Steven Schveighoffer wrote:
>>>>  
>>>>> This is my view (might not work, but I think it could).  For purposes
>>>>> of simplicity, I'll assume Walter currently develops the Phobos
>>>>> runtime (not that he doesn't, but I'm really not sure :).
>>>>>
>>>>> Maintenance of the merged runtime would become Walter's
>>>>> responsibility, with your help if necessary (ideas and help
>>>>> understanding, and enhancements if
>>>>> you wish).  Any changes desired for the runtime would go through
>>>>> Phobos (and
>>>>> Walter).  The Tango lib would use the now tango-fied Phobos runtime,
>>>>> with alias imports for existing code (e.g. tango.core.Thread would
>>>>> either publicly import std.thread or would privately import it, and
>>>>> alias the Thread class).
>>>> Based on historical evidence, this doesn't sound like a particularly
>>>> good idea. The current situation ensued for a reason.
>>>>
>>>> Also, I find that this discussion quite completely ignores the fact
>>>> that DMD is not the only D compiler anymore, and Walter is not the only
>>>> one with a vested interest in the functionality. In fact it looks like
>>>> quite many of the Tango conference attendants wants to discuss the
>>>> runtime.
>>> How does it ignore it? It sounds rather like the opposite to me: the
>>> very existence of multiple runtimes and the vested interest in those
>>> runtimes (Tango's primarily) are the key reason for unification.
>> 
>> Unification, yes. You misunderstood my point, which is that the runtime
>> implementation (not the compiler specific portion and direct language
>> support) should, IMO, be independent. As long as Walter/DigitalMars is
>> the developer of the language itself, it will be natural that eventual
>> new features that the language requires from the runtime, will be
>> bootstrapped by code from Walter, but I think Sean's work on the runtime
>> in Tango shows that such initial implementation can have large potential
>> for improvements.
>> 
>>>  
>>>> If there should be a common-common (not only "just" compatible)
>>>> runtime, it shouldn't be controlled by one compiler vendor. Note that
>>>> the Tango runtime consists of 3 parts, where only one is compiler
>>>> specific. That particular part should probably be controlled/reviewed
>>>> by the compiler vendor, the rest (GC, threading, other things) should
>>>> be independent.
>>> I'll admit my understanding is limited, but I'd guess that will lead to
>>> even further fragmentation and non-portability.
>> 
>> The compiler part would have to conform to the necessary interfaces, of
>> course, but at some level the implementation details needs to be, and not
>> all can be kept in the compiler itself, thus it must be somewhere in the
>> runtime. I don't see this as a problem, just a necessary evil.
>> 
> 
> I don't understand your point. are you suggesting that things like the
> GC will be independent from the compiler?
> It seems to me that the model suggested by Sean is the way to go:
> ie:
> 
> my code
> ----------
> standard library user code and standardized APIs to the runtime
> (threading, etc
> ---------------------------------
> compiler + runtime A  | compiler + runtime B | .....
> 
> 
> if a user isn't satisfied by runtime/compiler A he should just switch
> vendors.
> All the user facing APIs are standardized in the stdlib so all is needed
> is to recompile..

A common interface (API and ABI) would make this easier, but I just tend to
think that a common implementation as long as possible would be even
better - unification of efforts etc.

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource, #d.tango & #D: larsivi
Dancing the Tango