ждал этого коммента

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

а почему вы так думаете? в каких кейсах могут возникнуть проблемы из-за пробела?

ну смотрите.
aaa bbb, если вы на уровне лексера сделаете три токена Letter{'a'} и три токена Letter{'b'}, то на уровне парсера у вас будет 6 токенов Letter и получится просто `Variable{'aaabbb'}
Тогда вам придется создать отдельный токен для пробелов — что довольно странно.
Либо, вам придется создать специальный токен LetterNoWS, и тогда у вас будет два токена LetterNoWS{'a'} потом один Letter{'a'}. И когда вы будете парсить Variable, надо будет проверять, что внутри Variable только LetterNoWS, а в конце может быть либо Letter либо любой другой токен, который вообще не может быть в Variable.
И это очень сильно усложняет всё в принципе. Так что советую идентификаторы на уровне лексера собирать

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

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

неа. никакой неоднозначности.
asadasdasdas1232132131 — это идентификатор
asdasd  eiwubfewu — это два идентификаторы
asdasd{} — это идентификатор, потом токен {, потом токен }

то есть. у вас простые правила.
идентификатор может начинаться только с _ или буквы, а дальше к этому добавляются ещё и цифры. Но вы продолжаете собирать символы для идентификатора пока не встретите токен, который не может быть частью идентификаторы (и пробел в их числе).

а как тогда в грамматике описать что переменные могут начинаться только с нижнего подчеркивания и могут состоять только из 3-х символов

не хотелось бы это делать опять, так как я никаким образом не хороший пример, но вот лексер — он оооочень простой:
https://github.com/hazer-hazer/Jacy/blob/85967aa3f72a0181a0a4fb535eedb8982959ec45/src/parser/Lexer.cpp#L201

ну. парсить бесконечно. а потом сказать "НЕЛЬЗЯ"

LR мощнее, чем монадные парсер-комбинаторы? А можно примеров?

LR(1) мощнее, чем LL(1).

Пример:

S = Add
Add = Add + Factor | Factor
Factor = Factor * Term | Term
Term = "(" Add ")" | int

из-за левой рекурсии, для применения LL(1) или комбинаторов нужно переделать эту грамматику в не-леворекурсивную.

А у комбинаторов вместо choice оператор left-biased choice. Так что LR(1) с приоритетами мощнее комбинаторов.

В лексере описать, это ж не часть парсера

Ну. Можно же использовать left-corner хак в LL

И это не LR фича

Это фича рекурсивного подъёма, частным случаем которого является LR

Возможно. Но... Почему бы не использовать

Использовать что? Где?

В LL это можно сделать примерно никак, потому что LL - это рекурсивный спуск, а не подъём