www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Stick a fork in it

reply Walter Bright <newshound1 digitalmars.com> writes:
I'm currently working on implementing const/invariant. It's becoming 
clear that this is a pervasive change, and will cause binary 
incompatibility with existing code. I'm trying to minimize any source 
incompatibilities.

The first few iterations of const support probably will have lots of 
problems before it gets usable.

This means that dmd will have to fork into a 1.x maintenance version and 
a 2.x beta.
May 09 2007
next sibling parent BCS <BCS pathlink.com> writes:
Walter Bright wrote:
 I'm currently working on implementing const/invariant. It's becoming 
 clear that this is a pervasive change, and will cause binary 
 incompatibility with existing code. I'm trying to minimize any source 
 incompatibilities.
 
 The first few iterations of const support probably will have lots of 
 problems before it gets usable.
 
 This means that dmd will have to fork into a 1.x maintenance version and 
 a 2.x beta.

HALLELUJAH!! <g>
May 09 2007
prev sibling next sibling parent Clay Smith <clayasaurus gmail.com> writes:
Walter Bright wrote:
 I'm currently working on implementing const/invariant. It's becoming 
 clear that this is a pervasive change, and will cause binary 
 incompatibility with existing code. I'm trying to minimize any source 
 incompatibilities.
 
 The first few iterations of const support probably will have lots of 
 problems before it gets usable.
 
 This means that dmd will have to fork into a 1.x maintenance version and 
 a 2.x beta.

I appreciate the fork. Have fun with 2.x :) ~ Clay
May 09 2007
prev sibling next sibling parent reply bobef <asd asd.asd> writes:
What is invariant?


Walter Bright Wrote:

 I'm currently working on implementing const/invariant. It's becoming 
 clear that this is a pervasive change, and will cause binary 
 incompatibility with existing code. I'm trying to minimize any source 
 incompatibilities.
 
 The first few iterations of const support probably will have lots of 
 problems before it gets usable.
 
 This means that dmd will have to fork into a 1.x maintenance version and 
 a 2.x beta.

May 09 2007
next sibling parent Bill Baxter <dnewsgroup billbaxter.com> writes:
bobef wrote:
 What is invariant?
 
 
 Walter Bright Wrote:
 
 I'm currently working on implementing const/invariant. It's becoming 
 clear that this is a pervasive change, and will cause binary 
 incompatibility with existing code. I'm trying to minimize any source 
 incompatibilities.

 The first few iterations of const support probably will have lots of 
 problems before it gets usable.

 This means that dmd will have to fork into a 1.x maintenance version and 
 a 2.x beta.


Sounds like a good chance to go ahead and make 'const' the default! Did you and Andrei discuss that idea at all? Or has it been abandoned for good? --bb
May 09 2007
prev sibling next sibling parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
bobef wrote:
 What is invariant?

http://www.digitalmars.com/d/archives/digitalmars/D/The_new_invariant._51159.html#N51164 Means "this symbol wont change what it refers to ever". ... I think... or maybe that was const.... --bb
May 09 2007
parent reply Chris Nicholson-Sauls <ibisbasenji gmail.com> writes:
Bill Baxter wrote:
 bobef wrote:
 What is invariant?

http://www.digitalmars.com/d/archives/digitalmars/D/The_new_invarian ._51159.html#N51164 Means "this symbol wont change what it refers to ever". ... I think... or maybe that was const.... --bb

Actually, that'll be 'final'. The new 'invariant' will mean "this *data* absolute does not change", and the new 'const' will mean "this is an *immutable view* into data owned by other code, which *may* change". (If I'm remembering/understanding right.) -- Chris Nicholson-Sauls
May 09 2007
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Chris Nicholson-Sauls wrote:
 Actually, that'll be 'final'.  The new 'invariant' will mean "this 
 *data* absolute does not change", and the new 'const' will mean "this is 
 an *immutable view* into data owned by other code, which *may* change".  
 (If I'm remembering/understanding right.)

You're right.
May 09 2007
next sibling parent reply Chris Nicholson-Sauls <ibisbasenji gmail.com> writes:
Walter Bright wrote:
 Chris Nicholson-Sauls wrote:
 Actually, that'll be 'final'.  The new 'invariant' will mean "this 
 *data* absolute does not change", and the new 'const' will mean "this 
 is an *immutable view* into data owned by other code, which *may* 
 change".  (If I'm remembering/understanding right.)

You're right.

Which gets me to thinking: will const parameters be implicitly passed by referance? Given something like (contrived): <code> import std.stdio; void main () { int i = 0; void inc () { ++i; } void foo (const int x) { write(x); inc(); write(x); } foo(i); } </code> Should I expect to see it output 01 or 00? -- Chris Nicholson-Sauls
May 09 2007
parent Walter Bright <newshound1 digitalmars.com> writes:
Chris Nicholson-Sauls wrote:
 Which gets me to thinking: will const parameters be implicitly passed by 
 referance?

No. Use reference parameters to pass by reference.
May 10 2007
prev sibling parent reply renoX <renosky free.fr> writes:
Walter Bright a écrit :
 Chris Nicholson-Sauls wrote:
 Actually, that'll be 'final'.  The new 'invariant' will mean "this 
 *data* absolute does not change", and the new 'const' will mean "this 
 is an *immutable view* into data owned by other code, which *may* 
 change".  (If I'm remembering/understanding right.)

You're right.

If the keywords are really like this, it's a bit weird, IMHO the most interesting one is 'invariant' which happens to be also the one with the longest name.. renoX
May 10 2007
parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
renoX wrote:
 Walter Bright a écrit :
 Chris Nicholson-Sauls wrote:
 Actually, that'll be 'final'.  The new 'invariant' will mean "this 
 *data* absolute does not change", and the new 'const' will mean "this 
 is an *immutable view* into data owned by other code, which *may* 
 change".  (If I'm remembering/understanding right.)

You're right.

If the keywords are really like this, it's a bit weird, IMHO the most interesting one is 'invariant' which happens to be also the one with the longest name..

But invariant is also the one most likely to appear on a line all by itself with just a single variable and a simple initializer. And most uses will be close to the left margin I suspect. And even if invariant is the most interesting, I think const will still be the most used. --bb
May 10 2007
parent reply Sean Kelly <sean f4.ca> writes:
Bill Baxter wrote:
 renoX wrote:
 Walter Bright a écrit :
 Chris Nicholson-Sauls wrote:
 Actually, that'll be 'final'.  The new 'invariant' will mean "this 
 *data* absolute does not change", and the new 'const' will mean 
 "this is an *immutable view* into data owned by other code, which 
 *may* change".  (If I'm remembering/understanding right.)

You're right.

If the keywords are really like this, it's a bit weird, IMHO the most interesting one is 'invariant' which happens to be also the one with the longest name..

But invariant is also the one most likely to appear on a line all by itself with just a single variable and a simple initializer. And most uses will be close to the left margin I suspect. And even if invariant is the most interesting, I think const will still be the most used.

I still can't keep all these straight in my head--the words are all synonyms. Hopefully that will change after I've used them a bit. Sean
May 10 2007
parent reply Chris Nicholson-Sauls <ibisbasenji gmail.com> writes:
Sean Kelly wrote:
 Bill Baxter wrote:
 renoX wrote:
 Walter Bright a écrit :
 Chris Nicholson-Sauls wrote:
 Actually, that'll be 'final'.  The new 'invariant' will mean "this 
 *data* absolute does not change", and the new 'const' will mean 
 "this is an *immutable view* into data owned by other code, which 
 *may* change".  (If I'm remembering/understanding right.)

You're right.

If the keywords are really like this, it's a bit weird, IMHO the most interesting one is 'invariant' which happens to be also the one with the longest name..

But invariant is also the one most likely to appear on a line all by itself with just a single variable and a simple initializer. And most uses will be close to the left margin I suspect. And even if invariant is the most interesting, I think const will still be the most used.

I still can't keep all these straight in my head--the words are all synonyms. Hopefully that will change after I've used them a bit. Sean

I think I've just about gotten my head around it, but also feel it will come moreso with use. I think of the word invariant as a "stronger" word than const(ant) -- the latter being a more common term, and the former more... formal -- so that's how I deal with it; ie, that 'invariant' is a "stronger contract" than 'const' is. At least my time with Java semi-prepared me for 'final'. -- Chris Nicholson-Sauls
May 10 2007
parent reply Don Clugston <dac nospam.com.au> writes:
Chris Nicholson-Sauls wrote:
 Sean Kelly wrote:
 Bill Baxter wrote:
 renoX wrote:
 Walter Bright a écrit :
 Chris Nicholson-Sauls wrote:
 Actually, that'll be 'final'.  The new 'invariant' will mean "this 
 *data* absolute does not change", and the new 'const' will mean 
 "this is an *immutable view* into data owned by other code, which 
 *may* change".  (If I'm remembering/understanding right.)

You're right.

If the keywords are really like this, it's a bit weird, IMHO the most interesting one is 'invariant' which happens to be also the one with the longest name..

But invariant is also the one most likely to appear on a line all by itself with just a single variable and a simple initializer. And most uses will be close to the left margin I suspect. And even if invariant is the most interesting, I think const will still be the most used.

I still can't keep all these straight in my head--the words are all synonyms. Hopefully that will change after I've used them a bit. Sean

I think I've just about gotten my head around it, but also feel it will come moreso with use. I think of the word invariant as a "stronger" word than const(ant) -- the latter being a more common term, and the former more... formal -- so that's how I deal with it; ie, that 'invariant' is a "stronger contract" than 'const' is. At least my time with Java semi-prepared me for 'final'. -- Chris Nicholson-Sauls

Mentally, I can cope with const if I view it as abbreviation of 'constrained' (if you think of it as 'constant', IMHO it gets horribly nonintuitive). It's obvious that 'invariant' is an extreme case of 'constrained'.
May 10 2007
parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Don Clugston wrote:
 Mentally, I can cope with const if I view it as abbreviation of 
 'constrained' (if you think of it as 'constant', IMHO it gets horribly 
 nonintuitive). It's obvious that 'invariant' is an extreme case of 
 'constrained'.

That's a great way to remember it. That plus Chris's "more letters means more strength than const", and there's no way I'll ever forget again. --bb
May 11 2007
parent reply renoX <renosky free.fr> writes:
Bill Baxter a écrit :
 Don Clugston wrote:
 Mentally, I can cope with const if I view it as abbreviation of 
 'constrained' (if you think of it as 'constant', IMHO it gets horribly 
 nonintuitive). It's obvious that 'invariant' is an extreme case of 
 'constrained'.

That's a great way to remember it. That plus Chris's "more letters means more strength than const", and there's no way I'll ever forget again. --bb

While this makes it easy to remember, I can't help but thinking about all these people who claims that functional programming is better.. If they're right then it should be totally the opposite: invariants by default and if we want to have a variable then we have to precise it.. renoX
May 11 2007
parent reply Deewiant <deewiant.doesnotlike.spam gmail.com> writes:
renoX wrote:
 While this makes it easy to remember, I can't help but thinking about
 all these people who claims that functional programming is better..
 
 If they're right then it should be totally the opposite:
 invariants by default and if we want to have a variable then we have to
 precise it..
 

Walter said once that he should have made const the default (this is before this const/final/invariant stuff, so just replace const with "any constant qualifier"). See the following Google Groups link, near the bottom of the post: http://groups.google.com/group/comp.lang.c++.moderated/tree/browse_frm/thread/d6695737a74e1853/18dc841928a6eee3#doc_3ff8dedacef55e17 FWIW, I think it's still not too late, especially with the 2.0 fork there can't possibly be "[t]oo much water under the bridge". If the whole const system is being rewritten anyway, might as well bring in const by default. -- Remove ".doesnotlike.spam" from the mail address.
May 12 2007
parent Johan Granberg <lijat.meREM OVEgmail.com> writes:
Deewiant wrote:

 renoX wrote:
 While this makes it easy to remember, I can't help but thinking about
 all these people who claims that functional programming is better..
 
 If they're right then it should be totally the opposite:
 invariants by default and if we want to have a variable then we have to
 precise it..
 

Walter said once that he should have made const the default (this is before this const/final/invariant stuff, so just replace const with "any constant qualifier"). See the following Google Groups link, near the bottom of the post:

 
 FWIW, I think it's still not too late, especially with the 2.0 fork there
 can't possibly be "[t]oo much water under the bridge". If the whole const
 system is being rewritten anyway, might as well bring in const by default.
 

Yes, if we got immutability as a default it could catch a number of common bugs.
May 12 2007
prev sibling parent "Anders Bergh" <anders andersman.org> writes:
Nah, 'foreach_reverse' is longer.

On 5/10/07, renoX <renosky free.fr> wrote:
 Walter Bright a écrit :
 Chris Nicholson-Sauls wrote:
 Actually, that'll be 'final'.  The new 'invariant' will mean "this
 *data* absolute does not change", and the new 'const' will mean "this
 is an *immutable view* into data owned by other code, which *may*
 change".  (If I'm remembering/understanding right.)

You're right.

If the keywords are really like this, it's a bit weird, IMHO the most interesting one is 'invariant' which happens to be also the one with the longest name.. renoX

-- Anders
May 10 2007
prev sibling next sibling parent Alexander Panek <alexander.panek brainsware.org> writes:
On Wed, 09 May 2007 11:56:14 -0700
Walter Bright <newshound1 digitalmars.com> wrote:

 I'm currently working on implementing const/invariant. It's becoming 
 clear that this is a pervasive change, and will cause binary 
 incompatibility with existing code. I'm trying to minimize any source 
 incompatibilities.
 
 The first few iterations of const support probably will have lots of 
 problems before it gets usable.
 
 This means that dmd will have to fork into a 1.x maintenance version
 and a 2.x beta.

Now THAT's great news!
May 09 2007
prev sibling next sibling parent Myron Alexander <someone somewhere.com> writes:
Thank you Walter.

This is a welcome change. I appreciate all the work you have done and 
thank you for a fantastic language.

Regards,

Myron.
d_programming...myron_alexander...
(Replace first ... with 'a t', second with .com and remove underscores)
May 09 2007
prev sibling next sibling parent Georg Wrede <georg nospam.org> writes:
Walter Bright wrote:
 
 This means that dmd will have to fork into a 1.x maintenance version and 
 a 2.x beta.

This is probably one of the best things for D I've heard in a long time! While I know that this'll give you a lot of extra work maintaining two separate versions, there's no end to the possibilities and opportunities -- for both the corporate users and the community! From now on it'll be feasible to actually use D in long-term professional development.
May 09 2007
prev sibling next sibling parent reply Charles D Hixson <charleshixsn earthlink.net> writes:
Walter Bright wrote:
 I'm currently working on implementing const/invariant. It's becoming 
 clear that this is a pervasive change, and will cause binary 
 incompatibility with existing code. I'm trying to minimize any source 
 incompatibilities.
 
 The first few iterations of const support probably will have lots of 
 problems before it gets usable.
 
 This means that dmd will have to fork into a 1.x maintenance version and 
 a 2.x beta.

Do you intend that 2.x would add features to handle multi-processor systems? (Please?) I don't have anything definite to propose, though of course Java's "synchronized" comes to mind. Well, I suppose that should first be "Do you have a proposed feature list?" of stuff that's been held back...
May 09 2007
parent reply Sean Kelly <sean f4.ca> writes:
== Quote from Charles D Hixson (charleshixsn earthlink.net)'s
article
 Do you intend that 2.x would add features to handle
 multi-processor systems?  (Please?)  I don't have anything
 definite to propose, though of course Java's "synchronized"
 comes to mind.

"synchronized" has been in D for as long as I can remember. Or am I missing something? Sean
May 09 2007
parent Charles D Hixson <charleshixsn earthlink.net> writes:
Sean Kelly wrote:
 == Quote from Charles D Hixson (charleshixsn earthlink.net)'s
 article
 Do you intend that 2.x would add features to handle
 multi-processor systems?  (Please?)  I don't have anything
 definite to propose, though of course Java's "synchronized"
 comes to mind.

"synchronized" has been in D for as long as I can remember. Or am I missing something? Sean

manual a bit more carefully.
May 10 2007
prev sibling next sibling parent reply "Chris Miller" <chris dprogramming.com> writes:
On Wed, 09 May 2007 14:56:14 -0400, Walter Bright  
<newshound1 digitalmars.com> wrote:

 I'm currently working on implementing const/invariant. It's becoming  
 clear that this is a pervasive change, and will cause binary  
 incompatibility with existing code. I'm trying to minimize any source  
 incompatibilities.

 The first few iterations of const support probably will have lots of  
 problems before it gets usable.

 This means that dmd will have to fork into a 1.x maintenance version and  
 a 2.x beta.

Well, hooray... But I wonder about this const stuff. I remember a song similar to "here a const, there a final, everywhere an invariant final" ;)
May 09 2007
parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Chris Miller wrote:
 On Wed, 09 May 2007 14:56:14 -0400, Walter Bright 
 <newshound1 digitalmars.com> wrote:
 
 I'm currently working on implementing const/invariant. It's becoming 
 clear that this is a pervasive change, and will cause binary 
 incompatibility with existing code. I'm trying to minimize any source 
 incompatibilities.

 The first few iterations of const support probably will have lots of 
 problems before it gets usable.

 This means that dmd will have to fork into a 1.x maintenance version 
 and a 2.x beta.

Well, hooray... But I wonder about this const stuff. I remember a song similar to "here a const, there a final, everywhere an invariant final" ;)

That't the observation that leads one to start thinking about making const the default in places where it makes sense. Like on reference parameters to functions. Rather than having to explicitly declare "hey I'm not going to modify this data" you only have to explicitly declare the "hey I AM going to modify this data" case. I really don't know if it would end up being a net gain. But it seems appealing. The nice thing is that with C++ const arguments, if you write a function foo() that doesn't modify its arguments, but forget to mark the args as const, it's often some OTHER programmer who discovers that fact, because you might never try to call foo with a const param in your program. But the poor other programmer who discovers it has to figure out whether to modify your code, or try to get you to fix it, or submit a patch or whatever, or const cast. But with const default, if you forget to specify foo's arguments as mutable and you start trying to modify them in the function you're going to find out right away, when you're writing foo, not some time later when you try to call foo. --bb
May 09 2007
parent janderson <askme me.com> writes:
Bill Baxter wrote:
 Chris Miller wrote:
 On Wed, 09 May 2007 14:56:14 -0400, Walter Bright 
 <newshound1 digitalmars.com> wrote:

 I'm currently working on implementing const/invariant. It's becoming 
 clear that this is a pervasive change, and will cause binary 
 incompatibility with existing code. I'm trying to minimize any source 
 incompatibilities.

 The first few iterations of const support probably will have lots of 
 problems before it gets usable.

 This means that dmd will have to fork into a 1.x maintenance version 
 and a 2.x beta.

Well, hooray... But I wonder about this const stuff. I remember a song similar to "here a const, there a final, everywhere an invariant final" ;)

That't the observation that leads one to start thinking about making const the default in places where it makes sense. Like on reference parameters to functions. Rather than having to explicitly declare "hey I'm not going to modify this data" you only have to explicitly declare the "hey I AM going to modify this data" case. I really don't know if it would end up being a net gain. But it seems appealing. The nice thing is that with C++ const arguments, if you write a function foo() that doesn't modify its arguments, but forget to mark the args as const, it's often some OTHER programmer who discovers that fact, because you might never try to call foo with a const param in your program. But the poor other programmer who discovers it has to figure out whether to modify your code, or try to get you to fix it, or submit a patch or whatever, or const cast. But with const default, if you forget to specify foo's arguments as mutable and you start trying to modify them in the function you're going to find out right away, when you're writing foo, not some time later when you try to call foo. --bb

I think that's a good idea.
May 09 2007
prev sibling next sibling parent reply Sean Kelly <sean f4.ca> writes:
I'm not sure if anyone has asked yet, but will there be a
predefined version identifier for 1.0 vs. 2.0?  To migrate
gradually, it might be useful if there were a way to make code
cross-compilable.


Sean
May 09 2007
parent Walter Bright <newshound1 digitalmars.com> writes:
Sean Kelly wrote:
 I'm not sure if anyone has asked yet, but will there be a
 predefined version identifier for 1.0 vs. 2.0?  To migrate
 gradually, it might be useful if there were a way to make code
 cross-compilable.

I haven't got that far yet. Probably.
May 10 2007
prev sibling next sibling parent reply Aarti_pl <aarti interia.pl> writes:
Walter Bright pisze:
 I'm currently working on implementing const/invariant. It's becoming 
 clear that this is a pervasive change, and will cause binary 
 incompatibility with existing code. I'm trying to minimize any source 
 incompatibilities.
 
 The first few iterations of const support probably will have lots of 
 problems before it gets usable.
 
 This means that dmd will have to fork into a 1.x maintenance version and 
 a 2.x beta.

Any chances to get these branches in the form of open SVN repository accessible from D main page? It would be really big step forward IMHO... BR Marcin Kuszczak (aarti_pl)
May 10 2007
next sibling parent reply Bastiaan Veelo <Bastiaan Veelo.net> writes:
Aarti_pl wrote:
 Any chances to get these branches in the form of open SVN repository 
 accessible from D main page? It would be really big step forward IMHO...

Hi, Is a repository with just the front-end useful to you? At least there is http://dgcc.svn.sourceforge.net/viewvc/dgcc/trunk/d/ and you can readily build a compiler with it. Not sure however if David is going to support two branches, or stick with one of them. Regards, Bastiaan.
May 10 2007
parent reply Aarti_pl <aarti interia.pl> writes:
Bastiaan Veelo pisze:
 Aarti_pl wrote:
 Any chances to get these branches in the form of open SVN repository 
 accessible from D main page? It would be really big step forward IMHO...

Hi, Is a repository with just the front-end useful to you? At least there is http://dgcc.svn.sourceforge.net/viewvc/dgcc/trunk/d/ and you can readily build a compiler with it. Not sure however if David is going to support two branches, or stick with one of them. Regards, Bastiaan.

Your link points to GDC sources, but I wrote about DMD sources. GDC is different compiler, with additional modifications necessary to work with gcc. What's more svn repository of DMD sources should be rather accessible from DMD page not from other places... Source should be available because it's easier to track changes, check out one specific revision of compiler and prepare patches. I think also that it makes much better impression about openess of compiler development and rises quality of code. It gives also some sort of security, as open projects with many contributors are more likely to survive in longer term... Of course I am not expecting that Walter will put there sources for programs which are currently closed... BR Marcin Kuszczak (aarti_pl)
May 10 2007
next sibling parent Georg Wrede <georg nospam.org> writes:
Aarti_pl wrote:
 Bastiaan Veelo pisze:
 Your link points to GDC sources, but I wrote about DMD sources. GDC is 
 different compiler, with additional modifications necessary to work with 
 gcc. 

1
 What's more svn repository of DMD sources should be rather 
 accessible from DMD page not from other places...

2
 Source should be available because it's easier to track changes, check 
 out one specific revision of compiler and prepare patches.

3
 I think also that it makes much better impression about openess of 
 compiler development and rises quality of code. It gives also some sort 
 of security, as open projects with many contributors are more likely to 
 survive in longer term...

You make three good points!
 Of course I am not expecting that Walter will put there sources for 
 programs which are currently closed...

May 10 2007
prev sibling parent Bastiaan Veelo <Bastiaan Veelo.net> writes:
Aarti_pl wrote:
 Bastiaan Veelo pisze:
 Aarti_pl wrote:
 Any chances to get these branches in the form of open SVN repository 
 accessible from D main page? It would be really big step forward IMHO...

Hi, Is a repository with just the front-end useful to you? At least there is http://dgcc.svn.sourceforge.net/viewvc/dgcc/trunk/d/ and you can readily build a compiler with it. Not sure however if David is going to support two branches, or stick with one of them. Regards, Bastiaan.

Your link points to GDC sources, but I wrote about DMD sources.

I know.
 GDC is 
 different compiler, with additional modifications necessary to work with 
 gcc. What's more svn repository of DMD sources should be rather 
 accessible from DMD page not from other places...

Unless I missed a significant change in Walter's position on what to give away, only the front-end to the dmd compiler is published, besides Phobos. Although these sources are extremely valuable, I wonder what you would do when they were more easily accessible; hence my question.
 Source should be available because it's easier to track changes,

OK,
 check 
 out one specific revision of compiler

No, a front-end alone does not make a compiler. GDC on the other hand is.
 and prepare patches.

Unlikely, patches to a front-end that you cannot test yourself. I'd like to know if I am mistaken! OTOH, patches to GDC you can test. Then I suppose they could be ported to upstream DMD front-end. Still not sure whether a repository would help a lot here.
 I think also that it makes much better impression about openess of 
 compiler development and rises quality of code. It gives also some sort 
 of security, as open projects with many contributors are more likely to 
 survive in longer term...
 
 Of course I am not expecting that Walter will put there sources for 
 programs which are currently closed...

But the DMD compiler is still partly closed. I doubt that a repository for the front-end has much to say for the number of contributors. Phobos is an other issue however. I agree that it may be positive for a first impression to have a link to a repository on the DMD website, but it would only be for looking at it. Personally I like working with Subversion, even for projects where I am the only contributor. But it requires a new way of working if you are not used to it, and I can understand it if Walter does not want to change his procedures for this small benefit. Every now and then there is a post that is somehow about the lack of DMD as compared to a completely open source project. Be it number of contributors, eternity, quality of code (never heard that one before though) freedom, etc. *But we have GDC that provides all that*. And GDC exists by the grace of Walter, he is giving away the parts that are required for it. Of course we would all love to see DMD completely open source, but it sounds like a bit much to ask! And now we have two compilers instead of just one :-) Bastiaan.
May 10 2007
prev sibling parent reply Jeff <jeffrparsons optusnet.com.au> writes:
I really like this idea; this is one of the "lateral" changes I've been 
wanting. By that I mean changes that take a step sideways and change the 
way things are currently done, rather than moving forward with new 
features etc.

A couple of the others that I'd love to see:

- Phobos in a public repo
- Decoupling of the D compiler from Phobos (and maybe division of Phobos 
into separate libs) to avoid all the hacks people need to employ to use 
alternatives such as Tango

There are others I can't think of now, but I'd be interested in knowing 
what other changes people have been hoping for that fall into that 
category. (Eep, scope creep in my message; maybe this should be a 
separate thread? :P) They seem like the sort of changes to be considered 
as soon as possible, to make moving forward later easier and cleaner.

Cheers
Jeff :)
May 11 2007
parent reply Leandro Lucarella <llucax gmail.com> writes:
Jeff, el 12 de mayo a las 15:58 me escribiste:
 I really like this idea; this is one of the "lateral" changes I've been
wanting. By that I mean 
 changes that take a step sideways and change the way things are currently
done, rather than moving 
 forward with new features etc.
 
 A couple of the others that I'd love to see:
 
 - Phobos in a public repo

 - Decoupling of the D compiler from Phobos (and maybe division of Phobos into
separate libs) to 
 avoid all the hacks people need to employ to use alternatives such as Tango

compiler implementation (this will help compiler developers). -- Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/ .------------------------------------------------------------------------, \ GPG: 5F5A8D05 // F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05 / '--------------------------------------------------------------------' Home, home again. I like to be here when I can. When I come home cold and tired It's good to warm my bones beside the fire.
May 12 2007
parent Jeff <jeffrparsons optusnet.com.au> writes:
   - Versioned specification, so D can be a language specification rather a
     compiler implementation (this will help compiler developers).

Agreed! I wonder if we should start a thread dedicated to such "lateral" changes that people would like for the 2.0 fork? Any thoughts on this? To be honest, these are the changes that excite me most; they let me believe that just because some aspect of the current state of D is less than ideal, it doesn't have to stay this way.
May 13 2007
prev sibling next sibling parent Georg Wrede <georg nospam.org> writes:
Walter Bright wrote:
 I'm currently working on implementing const/invariant. It's becoming 
 clear that this is a pervasive change, and will cause binary 
 incompatibility with existing code. 

Life on the bleeding edge. That's why we're here, right?
 I'm trying to minimize any source incompatibilities.

Considering the possibly several versions with problems, I don't see minimizing source incompatibilities as a priority. Rather, I'd see even thinking about them as hampering development. Just do what it takes.
 The first few iterations of const support probably will have lots of 
 problems before it gets usable.

 This means that dmd will have to fork into a 1.x maintenance version and 
 a 2.x beta.

Actually, since we bump the major number here, this would be an excellent time to review even other things that we've skipped so far because of fear of source incompatibilities. The next good opportunity for breaking source will be D3.0, which probably is a couple of years away. -- And it damn well should, because only then can we have a thriving garden of stable and mature libraries, and serious apps built on them. (Why are beaches void of plants? Surely it's not for a lack of moisture, sunlight or nutrients. It's because the sea keeps moving the sand before any seeds sprout.) The pride, or the yardstick that libraries are measured with, should be how well they utilise the stable fork. Only that gives the stability, robustness, predictability, and long-term credibility that are needed before any real company risks choosing D for their pivot applications. We also have to admit that library writers and app builders have diametrically opposite views on ease of porting between major language versions: library writers prefer language changes that are easy to fix (as with automatic source transforms). But app builders really don't see that as a priority, because new upgrades of the app are usually written with the original language version. It would be un-economical to redo your large app just because you want to upgrade to D n+1. (Of course, the same companies will use the newest language (stable) version for their new apps.)
May 10 2007
prev sibling parent janderson <askme me.com> writes:
Walter Bright wrote:
 I'm currently working on implementing const/invariant. It's becoming 
 clear that this is a pervasive change, and will cause binary 
 incompatibility with existing code. I'm trying to minimize any source 
 incompatibilities.
 
 The first few iterations of const support probably will have lots of 
 problems before it gets usable.
 
 This means that dmd will have to fork into a 1.x maintenance version and 
 a 2.x beta.

I imagine, you would want to fork the documentation while your at it. -Joel
May 10 2007