DSL proposal #72

akantsevoi · 2025-12-31T09:48:11Z

No description provided.

docs/dsl-examples-echo.md

dkorolev · 2025-12-31T19:21:14Z

docs/dsl-examples-echo.md

+}
+```
+
+Ingress/egress queues (illustrative bindings):


I'd imagine these rules are also part of the DSL itself, no?

(Personally, I'm a big fan of the idea that the order of declaration does not matter, and neither do file/dir names, so that we can just concatenate everything into a single "maroon source file" and "compile" it "in one piece". So that incress/egress definitions may well be in separate files, but still — they are part of the DSL imho.

dkorolev · 2025-12-31T19:25:23Z

docs/dsl-examples-echo.md

+
+v1 state (current in the example above):
+
+```dsl


Ah, now I see what the state is, it's for migration. Let's dig deeper into this on the next call!

Your idea may well be great, we need more realistic examples though. My thought was that there can only be two versions of the state, "current" and "next", or "emerging" and "previous" if you wish. And then migration is seamless "copy-on-write", almost like a constructor call during the cast.

But it's a longer conversation, and we may well think how deep down this rabbit hole we want to go as of now.

In practice this has more to do with the notion of "the lifetime of data objects" vs. the lifetime of "programming language objects". There exists higher-order primitives that have value as business logic entities. We probably want to annotate them as such somehow, since they are no longer just "records in the hash-map" or "pointers/references to an external maroon-powered storage" (such as S3 with checksums).

This would be a cool chat to have, and we almost have an example to ride with, so let's chat about it first thing next year?

dkorolev · 2025-12-31T19:37:53Z

docs/dsl-language.md

+
+## Fiber State and Persistence
+- No global app state. Each fiber owns its own persistent state, defined inside that fiber.
+- Define per‑fiber state in the DSL: within a `fiber` block, declare `state vN { ... }`. Only these schema types are persisted for that fiber.


Yep, see comments above, we're getting close to this conversation — great!

dkorolev · 2025-12-31T19:39:38Z

docs/dsl-language.md

+## Fiber State and Persistence
+- No global app state. Each fiber owns its own persistent state, defined inside that fiber.
+- Define per‑fiber state in the DSL: within a `fiber` block, declare `state vN { ... }`. Only these schema types are persisted for that fiber.
+- First activation initializes state deterministically. Upgrades use per‑fiber migrations: `migrate vN -> vN+1 { ... }`.


This is actually quite a bold statement that migration is per-fiber. That's one model I've considered first, it may well be the one we converge on, but I'm having second thoughts tbh.

Another option is to migrate per data type, i.e. the type (struct) of the next version is something the users can access only the new representation of starting at some era, and then after all "older" instances of that struct have disappeared, it can be obsoleted. I don't have a strong opinion yet, but this may well be a more powerful model.

docs/dsl-language.md

dkorolev · 2025-12-31T19:40:45Z

docs/dsl-language.md

+- Initialize state explicitly in `on start { ... }` or during `migrate` steps; avoid relying on implicit defaults.
+
+### Constructor parameters
+- Fiber constructor parameters (identity, handles like queues, config) are read-only fields of the fiber instance.


The line is quite blurred for me now between on start and the constructor.

dkorolev · 2025-12-31T19:46:52Z

docs/dsl-language.md

+- Fiber constructor parameters (identity, handles like queues, config) are read-only fields of the fiber instance.
+- Access them as `self.<param>` inside the fiber (e.g., `self.name`, `self.inbox_queue`).
+- Parameters cannot be reassigned; locals remain bare identifiers. Shadowing parameter names is not allowed.
+- In `select`, the sugar `self.queue.await` is valid and desugars to `await recv(self.queue)`.


Is this for Rust compatibility or because we want it this way? Personally, I'm in favor of The One Way of Doing Things, so that we'd have a short list of language-level identifiers that we know exactly mean precise things (and they can be syntax-highlighted, etc.)

And await is one of them — personally I'd even say we can merge await and select, since await is just select with one arm.

Something like:

let e: Entry = await queue.next();

Vs.

let e: Entry1 | Entry2 = await { queue1.next(), queue2.next() };

Or, if the type is the same for queue1 and queue2:

let e: (Entry, idx) = await { (queue1.next(), 1), (queue2.next(), 2) };

This way it's the good old match afterwards, and each await arm (which is the select arm, technically), is an arbitrary async function — and if it's "in the middle of execution" whatever it has "polled" is logically destructed. And this also nicely solves the type system compilation time problem that some async events "can not be undone" — i.e. if we're talking about the queue where there's no way to "un-pop" the message, then the await / select arm for it must be of a single maroon step, otherwise it will break the "async borrow checking" invariant.

Wdyt?

(We can still make the syntax Rust-friendly I believe, if only by just calling this construct Await! or maroon_await! instead of just await.

dkorolev · 2025-12-31T19:47:36Z

docs/dsl-language.md

+- Fiber constructor parameters (identity, handles like queues, config) are read-only fields of the fiber instance.
+- Access them as `self.<param>` inside the fiber (e.g., `self.name`, `self.inbox_queue`).
+- Parameters cannot be reassigned; locals remain bare identifiers. Shadowing parameter names is not allowed.
+- In `select`, the sugar `self.queue.await` is valid and desugars to `await recv(self.queue)`.


(We can still make the syntax Rust-friendly I believe, if only by just calling this construct Await! or maroon_await! instead of just await.

docs/dsl-language.md

dkorolev · 2025-12-31T19:48:59Z

docs/dsl-language.md

+
+## Resource Limits
+- We track CPU/memory/I/O “cost”.
+- Per-transaction and per-fiber limits apply; hit a limit -> get a backpressure.


Yes, but perhaps not on all fibers, the priority here is to not have the "main business logic" get stuck somehow.

dkorolev · 2025-12-31T19:49:29Z

docs/dsl-language.md

+## Static Checks (examples)
+- `pure` functions can’t call effects or timers.
+- `Map`/`Set` keys must be orderable (canonical encoding available).
+- `select` cases must be cancellable or time-bounded.


Yes, unless they must be single-step by definition, for what can not be cancelled if it's already in flight!

Discussed: remove this line.

dkorolev · 2025-12-31T19:49:39Z

docs/dsl-language.md

+- Values: `Unit | Bool | I64 | U64 | Decimal{s} | Bytes | String | Vec<T> | Map<K,V> | Set<T> | struct | enum`.
+- Queues: named FIFO channels of `Value`.
+- Futures/Timers: one-shot futures; `after(ms)` creates a timer; `await` resolves.
+ - Fibers: define a fiber type with parameters (identity) and its private `state` and handlers.


Bad indent.

dkorolev · 2025-12-31T19:50:38Z

docs/dsl-language.md

+- Futures/Timers: one-shot futures; `after(ms)` creates a timer; `await` resolves.
+ - Fibers: define a fiber type with parameters (identity) and its private `state` and handlers.
+
+### Queue API (explicit and sugar)


I seriously think we're better off not thinking about sugar and syntax desugaring yet — it's a v1, more important to have the skeleton right that to think of end-used cleanliness of the code imho.

dkorolev · 2025-12-31T19:51:02Z

docs/dsl-language.md

+### Select Syntax and Waitables
+- Waitables: any `Future<T>` can be selected: `recv(queue)`, `after(ms)`, `external(...)`, etc.
+- Canonical arms:
+  - `case await recv(queue) as v: T => { ... }`


This actually may be a great idea, to introduce case as!

Discussed: rust compatible. In our case we won't have await because it will go to macros name

akantsevoi · 2026-01-04T19:34:08Z

docs/dsl-language.md

+
+## Fiber State and Persistence
+- No global app state. Each fiber owns its own persistent state, defined inside that fiber.
+- Define per‑fiber state in the DSL: within a `fiber` block, declare `state current { ... }`. Optionally, during upgrades, also declare `state next { ... }`. Only these schema types are persisted for that fiber.


Should be discussed more. Firstly we should define schema migration for fiber interfaces(queues for cross-fibers and gateways for external APIs). How the data is stored inside fiber is important but not as much.

akantsevoi · 2026-01-04T19:41:42Z

docs/dsl-language.md

+
+## Static Checks (examples)
+- `pure` functions can’t call effects or timers.
+- `Map`/`Set` keys must be orderable (canonical encoding available).


Discussed: we should provide hashMaps as well but all the data structures should be deterministic (all operations)

DSL proposal

000cf72

dkorolev reviewed Dec 31, 2025

View reviewed changes

akantsevoi added 3 commits January 3, 2026 12:35

Distinguish send/recv/dupliex queues

5941dab

use init

7da1b30

only current/next states

b03c1eb

akantsevoi commented Jan 4, 2026

View reviewed changes

few fixes after discussions

3d48d56

DSL proposal #72

Are you sure you want to change the base?

DSL proposal #72

Uh oh!

Conversation

akantsevoi commented Dec 31, 2025

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants