View mode: basic / threaded / horizontal-split · Log in · Help
May 10, 2007
Re: Stick a fork in it
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
Re: Stick a fork in it
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
Re: Stick a fork in it
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
Re: Stick a fork in it
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
Re: Stick a fork in it
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
Re: Stick a fork in it
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
Re: Stick a fork in it
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
Re: Stick a fork in it
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
Re: Stick a fork in it
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
Re: Stick a fork in it
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.
1 2 3 4 5
Top | Discussion index | About this forum | D home