Menu
Search

Forums

Forum Index

Thread overview
A rationale for more compiler exploration
May 28, 2021
rikki cattermole
May 28, 2021
Gravatar of Ola Fosheim GrostadPosted by Ola Fosheim GrostadReply
Ola Fosheim Grostad
Gravatar of Ola Fosheim Grostad


Reply

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, 2021
Gravatar of rikki cattermolePosted by rikki cattermole
in reply to Ola Fosheim Grostad		Reply
rikki cattermole
Gravatar of rikki cattermole
Posted in reply to Ola Fosheim Grostad


Reply
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, 2021
Gravatar of Ola Fosheim GrostadPosted by Ola Fosheim Grostad
in reply to rikki cattermole		Reply
Ola Fosheim Grostad
Gravatar of Ola Fosheim Grostad
Posted in reply to rikki cattermole


Reply
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!