• Ola Fosheim Grostad (31/31) May 28 2021 This is an attempt to restart the other thread on making
• rikki cattermole (14/19) May 28 2021 I had a very similar idea to this previously, but specific to the parser...
• Ola Fosheim Grostad (9/13) May 28 2021 Yes, one can introduce an AST builder that provides methods for

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.

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.

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!