"Value" заменить на "Item", нет?

Ладно, такой ещё вопрос, зачем инструкциям имя?

Чтоб ll читаемые были если надо. И для lit тестов удобнее. Если правильно вопрос понял.

Так ладно значит в отличии от имен функций и модулей оно не несет сушественной информации

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

Знаю, что тут есть некоторое число студентов и эта информация будет им интересна: пару дней назад Гугл отобрал менторские организации на Google Summer of Code 2021, и там есть множество интересных проектов, в которых студенты могли бы поучаствовать этим летом. В том числе - множество компиляторных проектов https://summerofcode.withgoogle.com/organizations/?sp-category=languages (gcc, LLVM, Haskell, Swift, Julia, R, to name a few).
Уже сейчас можно пройтись по предлагаемым идеям в проектах и начать разговаривать с менторами из участвующих команд. (Посмотрел в llvm-dev@ и в LLVM сообществе уже стоит большой шум при обсуждении тем)

И к слову, наш проект Tarantool в этом году тоже участвует в GSoC-2021 https://summerofcode.withgoogle.com/organizations/4813527870603264/ и у нас тоже есть множество идей так или иначе связанных с компиляторами, рантаймами и DSL языками - https://github.com/tarantool/tarantool/wiki/GSoC-2021
Загляните и туда!

Bear in mind that this year, Google has reduced the project scope. The project duration is now 175 hours, assuming 18 hours per week, whereas in past years it was 350 hours at 30 hours a week. The coding period is a couple of weeks shorter, and mentors will be filling out two evaluations instead of three.

Жаль я уже не студент, у вас куча интересных тем

По деньгам стало приятнее конечно, но всё равно стажировки выгоднее)

Internet Archive has launched a (beta) alternative to google scholar: https://scholar.archive.org/ Definitely not yet as good but looks promising.

Всем привет! Нисходящим парсером возможно реализовать разбор конструкций при которых нужно заглядывать на n токенов вперёд?

Наведу простой пример, vector<int64>() - expression, мы считываем токен Ident vector, затем следует токен Less < и у нас дилемма. То ли это InfixExpr (0 < 1), или же CallExpr ( vector<int64>(args) ) . При восходящем парсере это возможно было бы реализовать сверткой, но для этого требуется использовать уже существующие парсер-генераторы или писать свой (чего я не могу сделать, так как знаний очень мало в этой теме). Хотелось бы использовать LL(k) парсер, так как я его уже написал и хотелось бы его модифицировать под этим цели.

Да, можно. Почему может быть нельзя?

так LL(k) парсер на k токенов вперед и заглядывает, чтобы выбор сделать. другой вопрос, что  k > 1 может быть необходимо только в одном каком-то месте, а в остальных достаточно LL(1) парсера. ANTLR, например, дает возможность более глубокий lookahead указывать

Я хотел бы почитать о том как это реализовать, так как предоставлений не имею :)

В парсер-комбинаторах это называется lookAhead . В принципе, по типу и доке понятно как это реализовывать
https://hackage.haskell.org/package/parsec-3.1.14.0/docs/Text-Parsec-Combinator.html#v:lookAhead

Мне кажется именно такая проблема с <> полноценно решается на этапе семантики только
А ифать отдельные случаи — точно надо?

Там же ll(*), во всяком случае в 4 версии

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

У меня задано правило на проверку token.Ident, в случае если идет Lp -> CallExpr, в случае Lc -> StructExpr, default -> Ident (ветвь не меняется), после идет Pratt (operator precedence parser) разбор на наличие принадлежности к Logical, Bitwise, Arith -> InfixExpr

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

Соглашусь вот здесь. Либо можно попробовать сделать значимые пробелы, хотя это не очень хорошая идея с точки зрения дизайна имхо)

> и в случае провала сделать откат к исходному состоянию, применяя все правила по порядку

Обычный алгоритм разбора LL(k) работает не так, разве нет?

> после идет Pratt (operator precedence parser)

Значит, у Вас вообще не LL(1) parser, а recursive descent, правильно?

> Я может чего-то недогоняю, но заглядывая в текущем случае (в моей реализации LL(1)

Я не понимаю, почему Вы называете это LL(1).