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 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
next 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 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:


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.
 


Yes, if we got immutability as a default it could catch a number of common
bugs.
May 12 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


More likely I am.  It looks like I need to dig through the 
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


    and comunity driven (maybe with Walter as BDFL).

 - 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


  - Versioned specification, so D can be a language specification rather a
    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