High-Level Syntax for Caiman Programs

[Checkmate50]

At the moment, Caiman's only programming interface is a RON-based intermediate language. It is not convenient for humans to read or write. Our high-level goal in this project is to create a frontend that we can actually write programs in! This frontend should translate a new, custom syntax into the RON files that the existing Caiman backend can take and compile/execute. This is @liamdaniels's task, should they choose to accept it! 😄

One wrinkle is that the Caiman language as we envision it is "split" into a value language and a schedule language, but the current backend implementation (with its RON input files) is pretty intermingled. @od0x0 is working on splitting this out into two languages. But our overall trajectory here is going to be to start by inventing a syntax/frontend for the language as it currently exists, while the work to do the "big split" continues apace. Then, once that's ready, we will also split the frontend syntax to match the new input format for the backend.

Here's a plan for how the project will go:

1. Bikeshed details of language design (we have a preliminary language, so we will start by developing a language as this exists) [1 week or so]
2. Develop a lexer/parser for this initial combined language where the backend exists, along with sketch of AST [2 weeks or so]
3. Write some examples in this combined language to test that things scale / are managed correctly [1 week or so]
4. Expand the language to be split into 2 [3 weeks or so]
5. Test the split languages and show that schedules can be written [1 week or so]
6. Work out the translation to the created IR in more detail / expand the language [3 weeks (will probably be unfinished)]
7. Write up results [1 week or so]

The above plan is only a sketch—please weigh in here with questions, comments, and revisions.

[miahdan]

This sounds like a wonderful plan to me in general! I do have a few questions.

The first one is a higher-level direction one, which is: How will the combined and split frontend languages be similar enough that it's worth it to start the original combined language? I'm assuming it will be the case, but I just wanna make sure and understand for myself why that is by hearing more about the thought process behind this part of the plan.

My others are just about step 1. Firstly, are we going to (for now) scrap the language detailed in the frontend doc since it has two separate syntaxes, and work toward it later during the splitting phase? Or is it our starting point? (In that case, how is the language further split later?) Finally, and this is just me-specific, but where should I begin with this first step? Once we have a language I'll know what to do next, but it does feel a bit open-ended to me at this phase.