www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - A rationale for more compiler exploration

reply Ola Fosheim Grostad <ola.fosheim.grostad gmail.com> writes:
This is an attempt to restart the other thread on making 
exploration easier. Let us drop all opinions on source code level 
design issues that may be found offensive and focus on process.

Why is it important to have more exploration and experimental 
compiler forks?

1. To get higher quality DIPs that have been testet over a longer 
period of time to identify usability issues.

2. To encourage exploration of ideas and investigate their 
usefulness before doing a quality implementation.

3. To explore ideas and try out advancements in compiler 
technology that cannot be emulated in user code.

Why is it important to make it easy?

1. So that we have competing experiments that can be compared. 
This will increase the quality of DIPs and reduce the acceptance 
of badly conceived, untested or incomplete DIPs.

2. To explore more options so that we can get novel features. It 
is usally 1-3 novel features that makes a language stand out in a 
crowd.

3. To showcase that it is a system level language.

To make it easier we need up-to-date tutorials, how?

1. By turning past experiments into tutorials.

2. Only use stable parts/interfaces of the compiler to ensure 
that tutorials remain useful over time.

3. By identifying locations in the compiler where one can put 
"empty" components that can be extended. Essentially compile time 
plugin slots. If not used the compiler optimization will remove 
those.

I don't think we need to discuss source code qualities too much 
to find a strategy on how to create "compile time slots" that are 
protected by invariants.

Or at least agree that it is desirable to get to this stage.
May 28
parent reply rikki cattermole <rikki cattermole.co.nz> writes:
On 28/05/2021 9:11 PM, Ola Fosheim Grostad wrote:
 I don't think we need to discuss source code qualities too much to find 
 a strategy on how to create "compile time slots" that are protected by 
 invariants.
 
 Or at least agree that it is desirable to get to this stage.
I had a very similar idea to this previously, but specific to the parser. Basically it would allow IDE tooling to have different passes to get information out of the code you are working on. 1) tokens 2) parse rules 3) semantic information i.e. auto completion Each pass would occur as the interval between key strokes increases, meaning very high response times, with great looking results. The IDE can utilize the parse rules from a previous call in conjunction with a later token pass, to give better hints and syntax highlighting without costing the bank. So I'm all for it, even if I think there is a lot of work to do prior to something like this.
May 28
parent Ola Fosheim Grostad <ola.fosheim.grostad gmail.com> writes:
On Friday, 28 May 2021 at 10:01:04 UTC, rikki cattermole wrote:
 I had a very similar idea to this previously, but specific to 
 the parser.
Yes, one can introduce an AST builder that provides methods for building detailed syntactical AST nodes, but actually builds the existing AST, then you can hook into that. One can have a layer between frontend and backend that allows you to query the AST nodes. Then you can tie exact syntactical information to semantics. And use an empty backend.
 So I'm all for it, even if I think there is a lot of work to do 
 prior to something like this.
Great!
May 28