A rationale for more compiler exploration

[Ola Fosheim Grostad]

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.