What are the obstacles to writing an open source D complier? It seems to me that having D be a one man show is not the most efficient way of bringing D into the mainstream, seeing as there is a healthy community of programmers here who all could lend a hand fixing bugs and adding features.

On Thu, 08 Sep 2005 16:25:36 -0700, Kyle Furlong wrote:

> What are the obstacles to writing an open source D complier?

The language specification is neither complete or standardized.

>It seems to me that having D be a one man show is not the most efficient way of
> bringing D into the mainstream,

One person to define the language is not so bad, but having the same one then work on a compiler etc is way too much of a workload, in my opinion.

>seeing as there is a healthy community
> of programmers here who all could lend a hand fixing bugs and adding features.

If a bug is defined as "not conforming to specification" then we are in trouble as the specs are still fluid.

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
9/09/2005 9:27:39 AM

Derek Parnell wrote:
> On Thu, 08 Sep 2005 16:25:36 -0700, Kyle Furlong wrote:
> 
> 
>>What are the obstacles to writing an open source D complier? 
> 
> 
> The language specification is neither complete or standardized.
> 

So we are waiting for Walter to make the spec final?

> 
>>It seems to me that having D be a one man show is not the most efficient way of bringing D into the mainstream, 
> 
> 
> One person to define the language is not so bad, but having the same one
> then work on a compiler etc is way too much of a workload, in my opinion.
>

I agree, I was mainly talking about the compiler implementation.

> 
>>seeing as there is a healthy community of programmers here who all could lend a hand fixing bugs and adding features.
> 
> 
> If a bug is defined as "not conforming to specification" then we are in
> trouble as the specs are still fluid. 
> 

That is a valid point, but there are many bugs that are valid code in the spec, but still are broken.

Derek Parnell wrote:

[...]
> The language specification is neither complete or standardized.

Hmmm. Thats an interesting statement.

If the specs of a computer language can be considered incomplete and not standardized, what defines a computer language?

There must be another entity from which the specs can be considered
as incomplete. But there are at most three entities which can serve
such a purpose:
1. Digital Mars as the presumable holder of the rights on the
specifications,
2. Walter Bright as the presumable CEO of Digital Mars and the
author of specs and reference implementation dmd
3. the reference implementation dmd, consisting of an open source
front end and a proprietary back end.

In an defining sense entities 1 and 2 never gave anything else than specs and reference implementation to the public.

Therefore only the sources of the reference implementation can serve as an entity on which the specs can be considered incomplete. But then also the "bugs" currently contained in the reference implementation are part of the language, except one says that according to "bugs" the specs take the lead or---common sense.

Because nobody can have rights on common sense, there are currently no other intellectual pieces from which a copyright can be determined than the specs and the reference implementation.

But the frond end of the reference implementation is Open Source and gdc shows, that in the back end there are no hidden intellectual pieces to define D.

Therefore if the language specification can be considered as incomplete, the only entity from which this can be concluded is the reference implementation, which is Open Soruce and therefore the complete language including the specs must have the same OpenSource license.

But this contradicts the opinion of Walter who claims a plain old copyright on the specification of D.

Therefore the specs cannot be considered as incomplete. The current specs and only the current specs define the language D.

Therefore there cannot be any Open Source D except granted by the current license or explicitely by the holder of the rights.

Whithout this grants the only way to establish an Open Source ++D-- is to spin off from the current specs and develop silently until the intellectual rights on the current specs compared to the intellectual rights on the further development are getting marginal.

The latter way does not seem to be very promising :-)

-manfred

On Fri, 9 Sep 2005 02:29:19 +0000 (UTC), Manfred Nowak wrote:

> Derek Parnell wrote:
> 
> [...]
>> The language specification is neither complete or standardized.
> 
> Hmmm. Thats an interesting statement.
> 
> If the specs of a computer language can be considered incomplete and not standardized, what defines a computer language?

The statements of it's author.

> There must be another entity from which the specs can be considered
> as incomplete.
> But there are at most three entities which can serve
> such a purpose:

That turns out not to be the case in every situation. In this specific case, the D specifications themselves declare that there are still pieces to be completed.


> 1. Digital Mars as the presumable holder of the rights on the specifications,

Please note that I make a distinction between the specification itself and the document that contains the specification.

> 2. Walter Bright as the presumable CEO of Digital Mars and the author of specs and reference implementation dmd

Yes. Currently this is the definitive arbiter of D.

> 3. the reference implementation dmd, consisting of an open source front end and a proprietary back end.

Not so, in my opinion. Any attempt at an implementation has the possibility of containing behaviour that is not the behaviour intended by the specification author. Furthermore, the documented specification can itself carry mistakes; that is it could say things that were not intended by the creator of the language.

> In an defining sense entities 1 and 2 never gave anything else than specs and reference implementation to the public.

However, is not wise to assume that the entire specification has been presented to the public until the language creator says it has.

> Therefore only the sources of the reference implementation can serve as an entity on which the specs can be considered incomplete.

Utter rubbish! The reference implementation in this case, DMD, has many mistakes in it. That is, it does not yet conform to the language specification. DMD has things in it that it should not have (according to the specifications so far), and it omits some things that it should not omit (according to the specifications so far). It is still a work-in-progress, just as the 'official' language specification is.

> But then also the "bugs" currently contained in the reference implementation are part of the language, except one says that according to "bugs" the specs take the lead or---common sense.
> 
> Because nobody can have rights on common sense, there are currently no other intellectual pieces from which a copyright can be determined than the specs and the reference implementation.
> 
> But the frond end of the reference implementation is Open Source and gdc shows, that in the back end there are no hidden intellectual pieces to define D.
> 
> Therefore if the language specification can be considered as incomplete, the only entity from which this can be concluded is the reference implementation, which is Open Soruce and therefore the complete language including the specs must have the same OpenSource license.
> 
> But this contradicts the opinion of Walter who claims a plain old copyright on the specification of D.
> 
> Therefore the specs cannot be considered as incomplete. The current specs and only the current specs define the language D.
> 
> Therefore there cannot be any Open Source D except granted by the current license or explicitely by the holder of the rights.
> 
> Whithout this grants the only way to establish an Open Source ++D-- is to spin off from the current specs and develop silently until the intellectual rights on the current specs compared to the intellectual rights on the further development are getting marginal.

I think you are wrong in so many ways. Your logic is based on assumptions that I don't believe are true.

Just ask your self this ...

Does the currently published language specification accurately reflect the entire definition of the D language according to Walter Bright?

I believe the answer to this is - no.

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
9/09/2005 2:00:08 PM

"Kyle Furlong" <kylefurlong@gmail.com> wrote in message news:dfqh87$kia$1@digitaldaemon.com...
> What are the obstacles to writing an open source D complier?

time and expertise

> It seems to me that having D be a one man show is not the most efficient way of bringing D into the mainstream, seeing as there is a healthy community of programmers here who all could lend a hand fixing bugs and adding features.

The compiler doesn't worry me. It's the rest of the stuff that I wonder about.

Any language that is being used is a work in progress. I can point to any number of languages with mature, unchanging compilers and specifications, they'll be in the "dead language" bin <g>. Heck, I just put out another drop of the C++ compiler.

A much more interesting question is "is the compiler/language in a state where I can effectively use it"?

Walter Bright wrote:
> Any language that is being used is a work in progress. I can point to any
> number of languages with mature, unchanging compilers and specifications,
> they'll be in the "dead language" bin <g>. Heck, I just put out another drop
> of the C++ compiler.
> 
> A much more interesting question is "is the compiler/language in a state
> where I can effectively use it"?
> 
> 

I think the point/discussion I was trying to get at was that there is a large community of skilled, enthusiastic programmers here who I'm sure would like to help the d cause in a more intimate way. If the dmd compiler needs to stay closed, fine, but use the community.

Isn't gdc a open source implementation of a D compiler ??

What I see missing is at testbed compiler where every new idea is implemented and tested.

It should obvious be based on a open framework like gcc
or LLVM
http://llvm.cs.uiuc.edu/


On Thu, 08 Sep 2005 16:25:36 -0700, Kyle Furlong wrote:

> What are the obstacles to writing an open source D complier? It seems to me that having D be a one man show is not the most efficient way of bringing D into the mainstream, seeing as there is a healthy community of programmers here who all could lend a hand fixing bugs and adding features.

Kyle Furlong wrote:
> Walter Bright wrote:
> 
>> Any language that is being used is a work in progress. I can point to any
>> number of languages with mature, unchanging compilers and specifications,
>> they'll be in the "dead language" bin <g>. Heck, I just put out another drop
>> of the C++ compiler.
>>
>> A much more interesting question is "is the compiler/language in a state
>> where I can effectively use it"?
>>
>>
> 
> I think the point/discussion I was trying to get at was that there is a large community of skilled, enthusiastic programmers here who I'm sure would like to help the d cause in a more intimate way. If the dmd compiler needs to stay closed, fine, but use the community.

I think Walter should state more explicitly the project guidelines or give more responsibility to the community. Ok, we know Walter maintains the DMD "reference" compiler and the D specs with the help and suggestions of the community. One big problem is the Phobos library.

IMO we need to know, if Walter is going to dump Phobos in the near future. We desperately need a standard library that is well designed. Phobos is like a patchwork quilt now - there are no (multilevel) sub-categories like in the Java API, some of the code won't compile and there are inconsistencies in the manual. Since a lot of code in Phobos is in PD, why not make the Phobos totally free. Currently Walter cannot keep pace with all the bugs we file here. Would it be too much to ask Walter to change his tactics in order to speed up the development?