не, речь не про такие enum-ы

не. enum в расте имеет больше возможностей чем в шарпах и плюсах.
Там можно во варианте enum'а хранить сложные типы. Если вам знаком термин tagged union, то это оно.

Но вы всё правильно делаете, что храните типы лексем как enum

enum Expr
{
 Val(Int x),
 Plus(Expr a, Expr b)
}

Expr x = Expr.Plus(Expr.Val(1), Expr.Val(2))

Int calc(Expr e)
{
 return e switch
 {
   Expr.Val { x } => x,
   Expr.Plus { a, b } => calc(a) + calc(b),
 }
}

calc(x) == 3

а про что-то вроде такого. Это псевдокод, который я думаю должен быть понятен шарписту

емнип в c# завозили или собирались завозить похожую фичу через закрытые классы

правда я мог бы посоветовать хранить все типы операторов и пунктуационных знаков в общем enum'е
То есть:

enum TokenKind {
    Add, Sub, ..., LParen, RParen, ...
}

Это поможет вам в будущем избежать проблем с двойными проверками, что TokenKind == Operator && token.value as OperatorKind == OperatorKind::Add
На самом деле это удобно разделять иногда, но я хз можно ли это удобно сделать в шарпах, так как плохо шарю за них, но в плюсах я сделал распределение по общему TokenKind, так как иначе придется хранить union или variant (а это небезопасно, даже если всё вроде как правильно)

вот match в моем представлении это вообще другое. Match  - это результат сопоставления, в моем случае он имеет такую структуру и используется лексическим анализатором

я заменил на уже существующий синтаксис

Короче, есть же норм языки: фшарп, котел, скалка. Зачем писать компиль на сишарпе?

Даже паскаль больше для этого подходит.

Скорее, OCaml, Haskell... 😉

Ну совсем маргинальщину предлагать не надо.

да, в целом я начинаю понимать что вы имеете в виду. т.е. заранее описанное AST - это набор структур для удобного представления и дальнейшей работы результата парсинга

а без него никак? если делать универсальный вариант для грамматики, которую могут изменить. Как поступать в этом случае?
для такого кейса не понятно что  и с лексическим анализатором делать, как тогда определять по каким правилам разбивать на токены

Да это мейнстрим! Я же не предлагаю Idris/Agda/Lean! 😂

Ладно, сойдёмся на Rust. 😁

Да, раст тоже сойдёт.

на токены можно как угодно разбивать, постройкой из токенов аст как раз парсер занимается. Удачный енам токенов упростить парсинг и лексинг

но, он парсит по регуляркам, которые надо как-то доставать из динамической грамматики)

лексинг имхо должен быть отделен от грамматики вообще

это грамматика построена на токенах, а не токены на грамматике

да, но если  писать условный аналог ANTLR, как там это решается?