2.068 - resolve remaining regressions and release

2.069 - translate to D. No new features, no refactoring. Only regression fixes and what's already in HEAD. This should give us a solid baseline. It also means that open PRs that address other issues will not be pulled for 2.069.

Perhaps we should name this 2.100, to signify such a milestone.

2.101+ -
1. Take advantage of D features to improve quality.
2. Go to full lazy semantic analysis of imports, rather than the current "analyze them all"
3. Rethink what "speculative instantiation" of templates means so we can have a coherent process of compiling them.
4. Redo CTFE interpreter so it only rarely needs to allocate memory. This was already done for constant folding, but now it's time for the rest of the interpreter.
5. Get rid of reliance on the global error count. This has been mostly done, it just hast to be finished.
6. Convert the back end to D as well.

On Sun, Jul 19, 2015 at 09:02:03PM -0700, Walter Bright via Digitalmars-d wrote:
> 2.068 - resolve remaining regressions and release

Are there any remaining naming issues (introduced in this release, that is, not stuff that's already out there -- let's not touch those anymore) that people are dying to fix? If there are, we should get them in now before the names become set in stone.


> 2.069 - translate to D. No new features, no refactoring. Only regression fixes and what's already in HEAD. This should give us a solid baseline. It also means that open PRs that address other issues will not be pulled for 2.069.

Sounds like a good idea, give ourselves a whole release to stabilise self-hosting D, without anything else to distract our efforts.


> Perhaps we should name this 2.100, to signify such a milestone.
> 
> 2.101+ -
> 1. Take advantage of D features to improve quality.
> 2. Go to full lazy semantic analysis of imports, rather than the
> current "analyze them all"
> 3. Rethink what "speculative instantiation" of templates means so we
> can have a coherent process of compiling them.

For the sake of those of us who aren't so familiar with dmd internals: what is speculative instantiation and why does matter so much?


> 4. Redo CTFE interpreter so it only rarely needs to allocate memory. This was already done for constant folding, but now it's time for the rest of the interpreter.

Yes, please! This would significantly widen the practical usage of D compile-time features in real-world projects.


> 5. Get rid of reliance on the global error count. This has been mostly done, it just hast to be finished.

Does this involve cleaning up the handling of error-gagging too?


> 6. Convert the back end to D as well.

Will a D backend still be under the same license encumbrances as the current one?


T

-- 
Why are you blatanly misspelling "blatant"? -- Branden Robinson

On 7/19/2015 9:15 PM, H. S. Teoh via Digitalmars-d wrote:
> On Sun, Jul 19, 2015 at 09:02:03PM -0700, Walter Bright via Digitalmars-d wrote:
>> 3. Rethink what "speculative instantiation" of templates means so we
>> can have a coherent process of compiling them.
>
> For the sake of those of us who aren't so familiar with dmd internals:
> what is speculative instantiation and why does matter so much?

It's the basis of static if - does this piece of code compile. It's been a rich source of bugs because if the compilation fails, it can leave the state of the compiler in an indeterminate state.


>> 5. Get rid of reliance on the global error count. This has been mostly
>> done, it just hast to be finished.
> Does this involve cleaning up the handling of error-gagging too?

Yes.


>> 6. Convert the back end to D as well.
> Will a D backend still be under the same license encumbrances as the
> current one?

Yes. Mere translation would not change the license.

But I view the backend license encumbrance as more of a theoretical issue than a practical one - the license is extremely permissive. There isn't that much more to it than agreeing to not sue Symantec.

On 20/07/2015 4:02 p.m., Walter Bright wrote:
> 2.068 - resolve remaining regressions and release
>
> 2.069 - translate to D. No new features, no refactoring. Only regression
> fixes and what's already in HEAD. This should give us a solid baseline.
> It also means that open PRs that address other issues will not be pulled
> for 2.069.
>
> Perhaps we should name this 2.100, to signify such a milestone.

Or instead, move to SEMVER? Same effect.
Although, now might be a good time to think about D3. After all, we are having a massive change in the ecosystem. It wouldn't be that strange to think of it as more of a push for polishing.

> 2.101+ -
> 1. Take advantage of D features to improve quality.

As a library perhaps?

> 2. Go to full lazy semantic analysis of imports, rather than the current
> "analyze them all"

Ooo

> 3. Rethink what "speculative instantiation" of templates means so we can
> have a coherent process of compiling them.

Can the plan include stripping out unneeded ones? And even inlining some?

> 4. Redo CTFE interpreter so it only rarely needs to allocate memory.
> This was already done for constant folding, but now it's time for the
> rest of the interpreter.

Less memory = win! E.g. can we compile + run phobos test suite in < 1gb memory?
Because it's a real pain finding single board computers that support more then 1gb.

> 5. Get rid of reliance on the global error count. This has been mostly
> done, it just hast to be finished.
> 6. Convert the back end to D as well.

Ooo, yes please.
Perhaps even as a library?

I would love to see dmd literally along with it's backends as dub packages. That would be *high pitched* awesome.

On Monday, 20 July 2015 at 04:02:04 UTC, Walter Bright wrote:
> 2.068 - resolve remaining regressions and release
>
> 2.069 - translate to D. No new features, no refactoring. Only regression fixes and what's already in HEAD. This should give us a solid baseline. It also means that open PRs that address other issues will not be pulled for 2.069.
>
> Perhaps we should name this 2.100, to signify such a milestone.
>
> 2.101+ -
> 1. Take advantage of D features to improve quality.
> 2. Go to full lazy semantic analysis of imports, rather than the current "analyze them all"
> 3. Rethink what "speculative instantiation" of templates means so we can have a coherent process of compiling them.
> 4. Redo CTFE interpreter so it only rarely needs to allocate memory. This was already done for constant folding, but now it's time for the rest of the interpreter.
> 5. Get rid of reliance on the global error count. This has been mostly done, it just hast to be finished.
> 6. Convert the back end to D as well.

+ 1000000000

On Monday, 20 July 2015 at 05:05:52 UTC, ZombineDev wrote:
> On Monday, 20 July 2015 at 04:02:04 UTC, Walter Bright wrote:
>> 2.068 - resolve remaining regressions and release
>>
>> 2.069 - translate to D. No new features, no refactoring. Only regression fixes and what's already in HEAD. This should give us a solid baseline. It also means that open PRs that address other issues will not be pulled for 2.069.
>>
>> Perhaps we should name this 2.100, to signify such a milestone.
>>
>> 2.101+ -
>> 1. Take advantage of D features to improve quality.
>> 2. Go to full lazy semantic analysis of imports, rather than the current "analyze them all"
>> 3. Rethink what "speculative instantiation" of templates means so we can have a coherent process of compiling them.
>> 4. Redo CTFE interpreter so it only rarely needs to allocate memory. This was already done for constant folding, but now it's time for the rest of the interpreter.
>> 5. Get rid of reliance on the global error count. This has been mostly done, it just hast to be finished.
>> 6. Convert the back end to D as well.
>
> + 1000000000

I believe that migrating the the development of the compiler from C++ to D will have extremely positive effect to to the whole language and ecosystem. We should make this our number one priority!

@WalterBright and the other core developers:
Can you make a TODO list of what needs to be done to make this happen?

Is this list in bugzilla complete?
https://issues.dlang.org/buglist.cgi?bug_status=__open__&content=ddmd&list_id=202211&order=relevance%20desc&query_format=specific
(I just searched for DDMD)

On Monday, 20 July 2015 at 04:02:04 UTC, Walter Bright wrote:
> 4. Redo CTFE interpreter so it only rarely needs to allocate memory. This was already done for constant folding, but now it's time for the rest of the interpreter.

Great!

... and CTFE-able unions, thought. They are required for CTFE-able math.

On 2015-07-20 06:02, Walter Bright wrote:
> 2.068 - resolve remaining regressions and release
>
> 2.069 - translate to D. No new features, no refactoring. Only regression
> fixes and what's already in HEAD. This should give us a solid baseline.
> It also means that open PRs that address other issues will not be pulled
> for 2.069.
>
> Perhaps we should name this 2.100, to signify such a milestone.
>
> 2.101+ -
> 1. Take advantage of D features to improve quality.
> 2. Go to full lazy semantic analysis of imports, rather than the current
> "analyze them all"
> 3. Rethink what "speculative instantiation" of templates means so we can
> have a coherent process of compiling them.
> 4. Redo CTFE interpreter so it only rarely needs to allocate memory.
> This was already done for constant folding, but now it's time for the
> rest of the interpreter.
> 5. Get rid of reliance on the global error count. This has been mostly
> done, it just hast to be finished.
> 6. Convert the back end to D as well.

I like it. Please continue with these kinds of posts.

-- 
/Jacob Carlborg

On Monday, 20 July 2015 at 04:45:21 UTC, Rikki Cattermole wrote:
>> Perhaps we should name this 2.100, to signify such a milestone.
>
> Or instead, move to SEMVER? Same effect.
> Although, now might be a good time to think about D3. After all, we are having a massive change in the ecosystem. It wouldn't be that strange to think of it as more of a push for polishing.

Semver ftw! About D3: if we have to do a switch, it's the right time to remove old things left for retro-compatibility and rename/move things (and fix @property, for example).

>> 2.101+ -
>> 1. Take advantage of D features to improve quality.
>
> As a library perhaps?

+100 for library

>> 6. Convert the back end to D as well.
>
> Ooo, yes please.
> Perhaps even as a library?

+100

On Monday, 20 July 2015 at 04:02:04 UTC, Walter Bright wrote:
> 2.069 - translate to D. No new features, no refactoring. Only regression fixes and what's already in HEAD. This should give us a solid baseline. It also means that open PRs that address other issues will not be pulled for 2.069.
>
> Perhaps we should name this 2.100, to signify such a milestone.

This may also be the best moment to start keeping frontend versions among DMD/GDC/LDC synchronized, forever.