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

D is hardly limited by the compiler. On his own, Walter's equivalent to a medium-size team. No other language gets variadic templates, signals and slots, and  other significant template improvements only two weeks after the previous release.  Sure, GDC lags behind DMD, but really, even GDC releases are more common than compiler releases for most other languages.

It's the libraries that need attention.

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

GDC is more up to date in SVN (maybe 0.168), it just hasn't been repackaged since June.

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

Library changes are generally not too hard, but compiler changes can involve new code generation, etc, which requires a solid understanding of GCC at least.


Sean

Walter Bright wrote:
> Don Clugston wrote:
>>
>> 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.
>

Please make an announcement in d.announce to make the whole D community aware, if you are serious.

I'm sure we'll see something of a 'gold rush' to stabilize libraries and such :)

Bill Baxter wrote:
> 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.
> 

Patches, yes. But that's assuming that the current method of fixing bugs is lacking in some way. That is, we have the person most familiar with the compiler and language doing the bug fixing, so we may actually have the fastest, safest and most efficient way of getting things done. Obviously, often a patch to a seemingly simple problem can wreak havoc on other functionality. I'd hate to have someone else submitting patches to the template code right now for example.

Over the space of several releases, I took the dmdfe front-end, kept it up to date with the current front-end source code (distributed with DMD) and modified it to do header generation. I mention this because the current distribution model allows for things like that if you want to pursue it, and I don't think it was much more difficult than if the latest version was in a publicly available repository somewhere; if it took longer than a single release cycle, you'd have to keep the code you're working on in sync with the latest before you submitted the patches anyhow. One should be able to do the same with other new language features.

What may have made things easier initially is if somehow we could get a binary of the back-end to plug into the open-source front-end, because a decent amount of time was spent adjusting things to work w/ the back-end interface stubbed out. I don't want to push for that though if it would impede other progress, or make it tougher for Walter to add new features and/or fix bugs.

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

As for GDC - I don't know what the deal is there except to say that since I don't have the time to maintain it, I'm assuming that's the case with others as well.

But GDC was started to address your exact concerns and now what's needed is for people to jump-in and keep it up-to-date.

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

As mentioned above, I can't say I agree with that. After all, it's taken several years for those languages to get where they're at and D is a relative newcomer with a whole bunch of leading-edge features.

One thing that makes those languages so useful (and seems to need the most work (judging from this news-group)) is the open-source library work, and that is completely open-source for D. The current 'model' should not impede development there at all.

All IMHO.

> --bb

RA wrote:
> == Quote from Georg Wrede (georg.wrede@nospam.org)'s article
>> We might also promise to not publish a new (stable) version within 12
>> months of 1.0. (This may really be a more important promise for the
>> customers and prospective developers and consultants than we here
>> realize just off-hand.)
> 
> 
> I wouldn't want to hear a promise like that.  To me, it makes it sound like
> there's definately not going to be any new improvements\features for at least the
> next year.
> 
> I think you would be better off not making any statement about the "next"
> version... period.
> 

One way to handle this would be to not place any public links up for the "version next" model except in these newgroups. Then the community (all of us "beta testers") would be aware of it, and it would have a web presence, but the public at large wouldn't confuse it with "unstability".

> If you really want to promise anything, something along the lines of "All
> updates\versions\releases will be backwards compatible with 1.0 for the next 12
> months (or until 2.0), except for unintended 'features' caused by bugs." would be
> plenty to imply a stable platform.
> 
> Just my opinion of course.

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.

But there still is no dis-entanglement of D (the spec) and DMD (the
compiler), which really is needed if something like
std.compiler.supported_spec-version is supposed to work.

As far as I am concerned, too little focus is spent on "fixing" the spec. Bugs are important to fix, but if they are bugs according to a less than optimal spec, then what's the point?

If we can make sure that we are fairly happy with the specification, and (if possible) for future features, like const/readonly and others, try to make the spec less suspectible to breakage when those features _are_ added, then I'm all for releasing D (the spec) 1.0, preferrably after one or two release candidates. Whether DMD gains the same version number or not, I don't much care about, but we then have something real to measure against. Even if DMD is the reference implementation, it is important that DMD 1.0 don't necessarily equal D 1.0 !

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource & #D: larsivi

Walter Bright wrote:
> 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.

Interesting ! :) Can it handle partial currying ? My Bind lib is also about function/delegate currying, with arbitrary partial currying, parameter swizzling and function composition. The only thing that it's currently lacking is support of 'out', 'inout' and 'lazy' parameters. But this cannot be done without more info from the compiler. Would it be hard on your side to add more meta-info for functions and delegates ? I'm sure many people would appreciate the ability to extract parameter types, their count and a return value type for functions and delegates. The current approach to obtain this kind of meta-info is well demonstrated in the 'meta' package of Pyd: http://www.dsource.org/projects/pyd/browser/trunk/infrastructure/meta


--
Tomasz Stachowiak

Tom S wrote:
> Interesting ! :) Can it handle partial currying ?

I don't know.

> My Bind lib is also about function/delegate currying, with arbitrary partial currying, parameter swizzling and function composition. The only thing that it's currently lacking is support of 'out', 'inout' and 'lazy' parameters. But this cannot be done without more info from the compiler. Would it be hard on your side to add more meta-info for functions and delegates ? I'm sure many people would appreciate the ability to extract parameter types, their count and a return value type for functions and delegates. The current approach to obtain this kind of meta-info is well demonstrated in the 'meta' package of Pyd: http://www.dsource.org/projects/pyd/browser/trunk/infrastructure/meta

You are way, way ahead of me with this stuff. Wow!

BTW, I am considering changing the ==function and ==delegate is expressions, which you use, to the following:


==return gets the return type:

> template Return(dg)
> {
>     static if (is(dg R == return))
> 	alias R Return;
>     else
> 	static assert(0, "argument has no return type");
> }

==function or ==delegate gets the parameter types as a tuple:

> template Parameters(dg)
> {
>     static if (is(dg P == function))
> 	alias P Parameters;
>     else static if (is(dg P == delegate))
> 	alias P Parameters;
>     else static if (is(dg P == P*))
> 	alias Parameters!(P) Parameters;
>     else
> 	static assert(0, "argument has no parameters");
> }

This will require some adjustment in your code. I didn't think anyone was using that stuff. Will it be an issue for you? Or should I find another way to do it?

Walter Bright wrote:
> BTW, I am considering changing the ==function and ==delegate is expressions, which you use, to the following:
> 
> 
> ==return gets the return type:
> 
>> template Return(dg)
>> {
>>     static if (is(dg R == return))
>>     alias R Return;
>>     else
>>     static assert(0, "argument has no return type");
>> }
> 
> ==function or ==delegate gets the parameter types as a tuple:
> 
>> template Parameters(dg)
>> {
>>     static if (is(dg P == function))
>>     alias P Parameters;
>>     else static if (is(dg P == delegate))
>>     alias P Parameters;
>>     else static if (is(dg P == P*))
>>     alias Parameters!(P) Parameters;
>>     else
>>     static assert(0, "argument has no parameters");
>> }
> 
> This will require some adjustment in your code. I didn't think anyone was using that stuff. Will it be an issue for you? Or should I find another way to do it?

Whoa, That would be awesome ! I don't think anyone would mind such a change :)
I'm certainly not the only one to use that code/feature. E.g. that link I gave you is from Kirk's Pyd, which contains modified versions of my code. It's also based on efforts from Daniel Keep. But I'm sure they will gladly welcome the enhancement you're proposing :)

One question thought: will the 'P' tuple from your example be able to remember in/out/inout/lazy modifiers ?


--
Tomasz Stachowiak

Walter Bright wrote:
> Tom S wrote:
>> Interesting ! :) Can it handle partial currying ?
> 
> I don't know.
> 
>> My Bind lib is also about function/delegate currying, with arbitrary partial currying, parameter swizzling and function composition. The only thing that it's currently lacking is support of 'out', 'inout' and 'lazy' parameters. But this cannot be done without more info from the compiler. Would it be hard on your side to add more meta-info for functions and delegates ? I'm sure many people would appreciate the ability to extract parameter types, their count and a return value type for functions and delegates. The current approach to obtain this kind of meta-info is well demonstrated in the 'meta' package of Pyd: http://www.dsource.org/projects/pyd/browser/trunk/infrastructure/meta
> 
> You are way, way ahead of me with this stuff. Wow!
> 
> BTW, I am considering changing the ==function and ==delegate is expressions, which you use, to the following:
> 
> 
> ==return gets the return type:
> 
>> template Return(dg)
>> {
>>     static if (is(dg R == return))
>>     alias R Return;
>>     else
>>     static assert(0, "argument has no return type");
>> }
> 
> ==function or ==delegate gets the parameter types as a tuple:
> 
>> template Parameters(dg)
>> {
>>     static if (is(dg P == function))
>>     alias P Parameters;
>>     else static if (is(dg P == delegate))
>>     alias P Parameters;
>>     else static if (is(dg P == P*))
>>     alias Parameters!(P) Parameters;
>>     else
>>     static assert(0, "argument has no parameters");
>> }
> 
> This will require some adjustment in your code. I didn't think anyone was using that stuff. Will it be an issue for you? Or should I find another way to do it?

This would be great! The one thing we lose is the ability to get the underlying function type of a delegate. If you were to also add some mechanism to freely convert a function type to a delegate type and vice versa, that would be perfect.

The other thing that would be nice is the ability to derive the storage classes of a function's arguments (in/out/inout/lazy). That linked-to code only works with functions that only have 'in' arguments. (With some limited inout support I added to deal with opApply.)

-- 
Kirk McDonald
Pyd: Wrapping Python with D
http://pyd.dsource.org