The Death of D. (Was Tango vs Phobos)

Sean Kelly sean at invisibleduck.org
Mon Aug 18 11:16:35 PDT 2008


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..

I think it's worth distinguishing a bit more detail:


                       my code
--------------------------
       standard library   |
-------------------------------------------------------
compiler runtime | garbage collector | std. lib runtime


With the above model, the runtime is actually made up of three distinct 
components: the compiler support code, the GC, and some user-visible 
runtime code which I've termed the "standard library runtime."  This 
model provides a clear division of labor: the compiler writer worries 
only about the compiler support code, OS geeks can create the GC, and 
library programmers can work on the library bit.


Sean



More information about the Digitalmars-d mailing list