On Saturday, 2 March 2013 at 03:56:56 UTC, H. S. Teoh wrote:
> On Sat, Mar 02, 2013 at 04:46:57AM +0100, Denis Koroskin wrote:
> [...]
>> Anyway, feel free to take the sources and attach whatever license you want to it.
>
> Unfortunately, I don't think copyright works like that. You (the author) must be the one who licenses it. Any license applied by others will most probably be invalid, since they are not the real copyright owner, and, in the case of actual legal disputes, such a license will be indefensible.

 You can transfer ownership via written letter (not electronic) to a company/person I believe, various utilities of the GNU suite are donated that way.

 To my understanding, anything published on the internet without a license is basically informational. You can read it to understand it, but you can't compile or use it without a license/permission. The license can grant specific permissions to use (copy, modify, redistribute, etc), and terms of use.

 When in doubt consider GPL/LGPL, which will protect you in the case the malfunction/damages (for whatever reason, marked 'as is', no warranty or support, or refunds). Not sure of other licenses though, haven't read into them too much.

On 3/1/2013 7:46 PM, Denis Koroskin wrote:
> I'm no copyright lawyer, but I think ddmd being a derivative work from dmd
> should probably inherit the license from it

It does indeed. But the derived part of the work can be any license the author chooses.

> If someone is willing to bring the project back from it's stale state - I'm
> more than willing to help (by both writing patches and explaining how the
> existing code works).

Sadly, your efforts will be wasted without getting a license from the author.

If you want anybody else to use your code, you cannot ignore this issue.

On Saturday, 2 March 2013 at 04:20:27 UTC, Walter Bright wrote:
> On 3/1/2013 7:46 PM, Denis Koroskin wrote:
>> I'm no copyright lawyer, but I think ddmd being a derivative work from dmd
>> should probably inherit the license from it
>
> It does indeed. But the derived part of the work can be any license the author chooses.
>
> > If someone is willing to bring the project back from it's
> stale state - I'm
> > more than willing to help (by both writing patches and
> explaining how the
> > existing code works).
>
> Sadly, your efforts will be wasted without getting a license from the author.
>
> If you want anybody else to use your code, you cannot ignore this issue.

I should have mentioned I'm the author...

On Saturday, 2 March 2013 at 03:56:56 UTC, H. S. Teoh wrote:
> On Sat, Mar 02, 2013 at 04:46:57AM +0100, Denis Koroskin wrote:
> [...]
>> Anyway, feel free to take the sources and attach whatever license
>> you want to it.
>
> Unfortunately, I don't think copyright works like that. You (the author)
> must be the one who licenses it. Any license applied by others will most
> probably be invalid, since they are not the real copyright owner, and,
> in the case of actual legal disputes, such a license will be
> indefensible.
>
>
> T

Last year I boiled down existing ddmd to:

https://github.com/zachthemystic/ddmd-clean/

I did it because I needed to teach myself programming, and maybe there was a long shot that someone would want to use it. I rather angrily attached the GPL license because I thought I had to. But flexibility in this area comes as a welcome surprise.

I want to make another point. Dmd is perhaps written in a way that might be easier to create an automatic program translating it to D than other C++ programs. I guess that approach is worth at least a small amount of investigation. The question is whether the number of special cases required to automate will take more toll than the grunt work of direct translation.

ddmd currently does some really awkward C++ contortions of stuff which is built into D. No one would write it that way in D. While I stripped down the compiler to make my lexer/parser version of it, which is very mangled at the moment, at least you can look at the code to see how dmd would look in D.

On 3/1/2013 8:23 PM, Denis Koroskin wrote:
> I should have mentioned I'm the author...

That changes everything!

On Saturday, 2 March 2013 at 04:28:40 UTC, Zach the Mystic wrote:
> Last year I boiled down existing ddmd to:
>
> https://github.com/zachthemystic/ddmd-clean/
>
> I did it because I needed to teach myself programming, and maybe there was a long shot that someone would want to use it. I rather angrily attached the GPL license because I thought I had to. But flexibility in this area comes as a welcome surprise.
>
> I want to make another point. Dmd is perhaps written in a way that might be easier to create an automatic program translating it to D than other C++ programs. I guess that approach is worth at least a small amount of investigation. The question is whether the number of special cases required to automate will take more toll than the grunt work of direct translation.

You would definitely need an identifier translation table:

"Dsymbols *" -> "Dsymbol[]"
"NULL" -> "null"
`//printf("...%d...", s)` -> `writef("...%s...", s)`
"#ifdef XIFDEFVERSION" + nested ifdefs + "#endif"
-> "version(XIFDEFVERSION) {" + nested {}'s + "}"

"#ifdef 0" -> "version(none)"

To assemble a class, you'd need a list of methods to look up, and hints where to look up each method.

It would be good to develop a small domain specific language just for translating this. The better the language, the easier it would be to add all the special cases I'm sure would be necessary.

On Friday, 1 March 2013 at 16:44:53 UTC, js.mdnq wrote:
>
> There is no problem with circular dependencies as long as the language spec has a fixed subset that the compiler is written in. The reason is that any future version then can compile the compiler source because the future versions all support the subset.
>
> This is why it is so important to get the fixed language subset down because it will the core language features and can't be changed without causing regressive dependencies.
>
> Any evolution of the D compiler will compile it's own compiler source as long as it properly implements the D language subset. This subset also has to be a subset of the current dmd language implementation to bootstrap from.

Exactly. This fixed subset would be very limited in comparison to the full language (I can imagine something looking a bit like a smaller Go, there would probably be no templates at all, no CTFE, maybe even no exceptions, for instance), but would be orthogonal, completely stable in terms of spec, and known to work. It could be defined for other real world usages as well, like embedding in small appliances.

On Thursday, 28 February 2013 at 21:11:20 UTC, js.mdnq wrote:
> I believe a complete rewrite from the ground up using a fixed stable dmd is needed. The reason is two fold: Many things have been learned about the evolution of the D language over time. Much of the trouble of D has been stabling the D implementation and spec. Second, Trying to port the C++ code to D to make a D compiler will only multiply the bugs in DMD. (i.e., it will introduce new bugs from the conversion and retain the old bugs)
>
> Instead, I believe proper project management is needed along with a SOLID language specification and clear delineation of goals. If the language spec itself is flawed then the same things will occur as is with DMD.
>
> To tie the dependence on C/C++ the D compiler would need to be written in the language subset of the intersection between DMD and the new language spec. This should not be hard to do but must be strictly maintained. Else one will always require dmd to compile the compiler.
>
> Hence, a solid language spec for the new D compiler is needed. The language spec must overlap with the old spec and the D compiler must only be written in this overlap. (It should be obvious but this allows the D compiler to be compiled in DMD or itself, after the bootstrap one can gradually evolve the subset to include the newer features a few versions behind since the old dmd is not needed)
>
> The problem with such an undertaking behind successful is all in the project management. I would say we need a solid language spec and the subset between it and the current spec(frozen at some point). I imagine they would be almost identical so actually little real work would be needed.
>
> So, who's up for writing the D 3.0 spec?

I believe this is the better strategy. At least, we have a reference compiler, so that it's easy to know at each point in time if the new compiler is at least as good as the old one. However, it's such a long road that all these efforts will mean the development of the current compilers are nearly completely stopped, which is problemaic, given that important features are still missing.

So the question now is, what exactly which features can a rewrite in D make it easier to add ?

On Friday, 1 March 2013 at 11:45:42 UTC, Don wrote:
> On Thursday, 28 February 2013 at 00:37:50 UTC, Andrei Alexandrescu wrote:
>> Hello,
>>
>>
>> Walter and I have had a long conversation about the next radical thing to do to improve D's standing. Like others in this community, we believe it's a good time to consider bootstrapping the compiler. Having the D compiler written in D has quite a few advantages, among which taking advantages of D's features and having a large codebase that would be its own test harness.
>>
>> By this we'd like to initiate a dialog about how this large project can be initiated and driven through completion. Our initial basic ideas are:
>>
>> 1. Implement the dtoh standalone program that takes a D module and generates its corresponding C++ header.
>>
>> 2. Use dtoh to initiate and conduct an incremental port of the compiler. At given points throughout the code D code will coexist and link with C++ code.
>>
>> 3. At a point in the future the last C++ module will be replaced with a D module. Going forward there will be no more need for a C++ compiler to build the compiler (except as a bootstrapping test).
>>
>> It is essential that we get support from the larger community for this. This is a large project that should enjoy strong leadership apart from Walter himself (as he is busy with dynamic library support which is strategic) and robust participation from many of us.
>>
>> Please chime in with ideas on how to make this happen.
>
> This would be a huge step forward, I'm sure all of us who have made significant contributions to the compiler are frustrated by the many things that are difficult in C++ but would be easy in D.
>
> But in my view, before step 2 can happen, we need to clean up the glue layer.
> Once we have an isolated, clearly defined front-end that is shared between dmd, gdc and ldc, we can start converting it.

Like js.mdnq wrote, I'm pretty sure this will fail because of the circular dependency problem and because of memory problems, if the compiler isn't written in a strict subset of the language. AFAIK, Ocaml is compiled in a strict subset of Caml, for instance, and I would believe many bootstrapping compilers do the same.

On Saturday, 2 March 2013 at 06:50:32 UTC, SomeDude wrote:
>
> Exactly. This fixed subset would be very limited in comparison to the full language (I can imagine something looking a bit like a smaller Go, there would probably be no templates at all, no CTFE, maybe even no exceptions, for instance), but would be orthogonal, completely stable in terms of spec, and known to work. It could be defined for other real world usages as well, like embedding in small appliances.

It would also make it easy to bootstrap the compiler on new platforms.