Don Clugston wrote:
> I think that's an excellent idea. If, as Walter has said, "1.0" is an arbitrary line in the sand, tying it to a particular date gives a rationale for associating a name to a particular release. If we can say "a DMD 1.0 release will exist on January 1, 2007" (or at least, 1.0 RC 1), we'd gain a lot of focus.
> 
> I thought we were really close to a 1.0 release at 0.166, but starting with the array literals in 0.167, a stable release suddenly seems a very long way off.
> On the positive side, I think that array literals and variadic templates were the two major 2.0 features which were likely to render a lot of library code obselete.
> 
> We should choose a date and stick to it. Remove the angst.

Sounds good to me, and Jan 1, 2007 is a great date to pick.

I've been playing a lot with the template tuple thing. It flings open some doors pretty wide to a great simplification of library code. That's why I put a priority on it. I've been fiddling with some of Andrei Alexandrescu's Loki C++ template code, and some of it shrinks by an *order of magnitude* with language support for tuples. Not only that, it becomes much more understandable <g>.

Another goal of mine is support for a Spirit-like library. I used to think Spirit was of only marginal use, but I am more and more thinking that, from the right point of view, it can be core to making some ubiquitous and very powerful library tools.

Walter Bright wrote:
> Don Clugston wrote:
>> I think that's an excellent idea. If, as Walter has said, "1.0" is an arbitrary line in the sand, tying it to a particular date gives a rationale for associating a name to a particular release. If we can say "a DMD 1.0 release will exist on January 1, 2007" (or at least, 1.0 RC 1), we'd gain a lot of focus.
>>
>> I thought we were really close to a 1.0 release at 0.166, but starting with the array literals in 0.167, a stable release suddenly seems a very long way off.
>> On the positive side, I think that array literals and variadic templates were the two major 2.0 features which were likely to render a lot of library code obselete.
>>
>> We should choose a date and stick to it. Remove the angst.
> 
> Sounds good to me, and Jan 1, 2007 is a great date to pick.
> 
> I've been playing a lot with the template tuple thing. It flings open some doors pretty wide to a great simplification of library code. That's why I put a priority on it. I've been fiddling with some of Andrei Alexandrescu's Loki C++ template code, and some of it shrinks by an *order of magnitude* with language support for tuples. Not only that, it becomes much more understandable <g>.

And consequently less buggy. In an early release of Loki, there was a typo which meant there was a nasty bug if tuples had exactly 27 parameters.

0.173 is an incredible release. We're getting frightening close to being able to say "D templates are a superset of the C++ template *wishlist*" <g>.

> Another goal of mine is support for a Spirit-like library. I used to think Spirit was of only marginal use, but I am more and more thinking that, from the right point of view, it can be core to making some ubiquitous and very powerful library tools.

I have a vague intuition that template tuples will enable some serious innovation in that direction. It scares me at the same time, because there's *so much* unexplored territory.

Don Clugston wrote:
> Walter Bright wrote:
>> Don Clugston wrote:
>>> I think that's an excellent idea. If, as Walter has said, "1.0" is an arbitrary line in the sand, tying it to a particular date gives a rationale for associating a name to a particular release. If we can say "a DMD 1.0 release will exist on January 1, 2007" (or at least, 1.0 RC 1), we'd gain a lot of focus.
>>>
>>> I thought we were really close to a 1.0 release at 0.166, but starting with the array literals in 0.167, a stable release suddenly seems a very long way off.
>>> On the positive side, I think that array literals and variadic templates were the two major 2.0 features which were likely to render a lot of library code obselete.
>>>
>>> We should choose a date and stick to it. Remove the angst.
>>
>> Sounds good to me, and Jan 1, 2007 is a great date to pick.
>>
>> I've been playing a lot with the template tuple thing. It flings open some doors pretty wide to a great simplification of library code. That's why I put a priority on it. I've been fiddling with some of Andrei Alexandrescu's Loki C++ template code, and some of it shrinks by an *order of magnitude* with language support for tuples. Not only that, it becomes much more understandable <g>.
> 
> And consequently less buggy. In an early release of Loki, there was a typo which meant there was a nasty bug if tuples had exactly 27 parameters.
> 
> 0.173 is an incredible release. We're getting frightening close to being able to say "D templates are a superset of the C++ template *wishlist*" <g>.
> 
>> Another goal of mine is support for a Spirit-like library. I used to think Spirit was of only marginal use, but I am more and more thinking that, from the right point of view, it can be core to making some ubiquitous and very powerful library tools.
> 
> I have a vague intuition that template tuples will enable some serious innovation in that direction. It scares me at the same time, because there's *so much* unexplored territory.

GO EXPLORE IT! /me pushes Don over the edge, into the wild new territory.

Walter Bright wrote:
> BCS wrote:

> While an independent implementation of D would be worthwhile for many reasons, there are many very successful languages for which only one implementation exists - such as Perl, Ruby, etc., so it is not a requirement.

I definitely agree.

> What I think is critical for the success of a single implementation language is it being open source, which D is.

Technically yes.

But practically, no.  D is not open source.  D is partially open source.  Just because there is an out-of-date open source compiler that does compile and an up-to-date open source front end that won't compile does not make it open source in the sense that matters most, I think.

The sense that matters is the one in which I can do "cvs update -Pd" and get the latest complete, working compiler, make changes to it, and submit those changes as patches.

It's great that there's an open source D compiler, and I applaud the effort of those folks who have gotten it to where it is.  But it really should be the MAIN compiler not a sad also-ran huffing and puffing to keep up.

I'm pretty sure I could get to the point where I could submit simple patches to fix some things here and there in the front end, but frankly I have very little interest in spending that time if it's just going to serve the purpose of getting an out-of-date compiler a smidge closer to where DMD was three months ago.  Maybe not everyone feels that way, but I'd be willing to bet a significant number do.  I love new features.  I like to get stuff that's hot off the presses.  I have the source code for 5 or 6 open source projects on my harddrive right now that I sometimes contribute to.

Open source is most motivating when everyone is working together to create something new and useful and cutting edge, but it's not so exciting when the goal is the re-create that which was new and cutting edge last month.  I can only assume that at least some other would-be contributors feel the same way.

Anyway, I do applaud you for making so much of D open source.  I think it probably wouldn't be going as strong today if you hadn't.  But at the same time, you shouldn't have any illusions that DMD's model is equivalent to or contains the same magic open source recipe that helped Perl or Ruby or Python make it to where they are today.  It's more like Java's recipe, but Sun had megabucks with which to force Java down everyone's throat despite not being fully open source.

--bb

Bill Baxter wrote:
> It's great that there's an open source D compiler, and I applaud the effort of those folks who have gotten it to where it is.  But it really should be the MAIN compiler not a sad also-ran huffing and puffing to keep up.

There's nothing impeding anyone from submitting the patches to it to keep it up to date. I try pretty hard to make all the updates to the D language in the front end, to make getting it to GDC easier. For the rest, I am available for advice and help in any way I can (although I cannot work on the gnu backend code itself, as I wish to avoid 'taint').

Don Clugston wrote:
> I have a vague intuition that template tuples will enable some serious innovation in that direction. It scares me at the same time, because there's *so much* unexplored territory.

It's fun pulling on that string and seeing where it goes! For example, I now have a working Curry template, which will curry *any* function or delegate.

Walter Bright wrote:
> Bill Baxter wrote:
>> It's great that there's an open source D compiler, and I applaud the effort of those folks who have gotten it to where it is.  But it really should be the MAIN compiler not a sad also-ran huffing and puffing to keep up.
> 
> There's nothing impeding anyone from submitting the patches to it to keep it up to date. I try pretty hard to make all the updates to the D language in the front end, to make getting it to GDC easier. For the rest, I am available for advice and help in any way I can (although I cannot work on the gnu backend code itself, as I wish to avoid 'taint').

Hmm.  So why isn't the strategy working?
Current GDC is based on 0.162 from June 22.  Over ten releases, 4 months,  dozens of bug fixes, and at least ten significant features behind DMD.

In your estimation, for someone who knows what they are doing, how long should it take to update GDC for 'an average DMD release'?  Is the problem just that we've been lacking anyone who meets the qualifications since July?  Did I miss the good old days when GDC and DMD used to walk hand in hand and frolic in the Autumn mist?

--bb

Bill Baxter wrote:
> Walter Bright wrote:
>> Bill Baxter wrote:
>>> It's great that there's an open source D compiler, and I applaud the effort of those folks who have gotten it to where it is.  But it really should be the MAIN compiler not a sad also-ran huffing and puffing to keep up.
>>
>> There's nothing impeding anyone from submitting the patches to it to keep it up to date. I try pretty hard to make all the updates to the D language in the front end, to make getting it to GDC easier. For the rest, I am available for advice and help in any way I can (although I cannot work on the gnu backend code itself, as I wish to avoid 'taint').
> 
> Hmm.  So why isn't the strategy working?

If everyone expects someone else to do it, it won't happen. The whole point of open source is so that anyone can contribute, and should contribute when they need something from it.

Me, I cannot work on gcc for legal reasons. Since I work on compilers professionally, I wish to avoid even the appearance of impropriety.

Bill Baxter wrote:

> Current GDC is based on 0.162 from June 22.  Over ten releases, 4 months,  dozens of bug fixes, and at least ten significant features behind DMD.

To be fair, "current GDC" is up to about DMD 166 or so.
http://dgcc.svn.sourceforge.net/viewvc/dgcc/trunk/d/

It is still 2 months and lack D 2.0 features, but anyway...
I haven't done any gdcmac/gdcwin, waited for a GDC release.

I have been working on a GUI library and an IDE instead. :-)

> In your estimation, for someone who knows what they are doing, how long should it take to update GDC for 'an average DMD release'?  Is the problem just that we've been lacking anyone who meets the qualifications since July?  Did I miss the good old days when GDC and DMD used to walk hand in hand and frolic in the Autumn mist?

David Friedman is the one maintaining the GDC compiler...
I don't think there would be a GCC D Compiler without him.

Historic track record for DMD and GDC releases is at:
http://www.prowiki.org/wiki4d/wiki.cgi?HistoryRoadmap

It averages around two weeks, except when David is busy.

--anders

Walter Bright wrote:

> There's nothing impeding anyone from submitting the patches to it to keep it up to date. I try pretty hard to make all the updates to the D language in the front end, to make getting it to GDC easier. For the rest, I am available for advice and help in any way I can (although I cannot work on the gnu backend code itself, as I wish to avoid 'taint').

The one feature I miss the most from DMD is version(Unix) and std.c.unix

version(linux) and std.c.linux really makes porting to Mac more "work".

--anders