The Death of D. (Was Tango vs Phobos)

Yigal Chripun yigal100 at gmail.com
Sat Aug 16 03:46:07 PDT 2008


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



More information about the Digitalmars-d mailing list