А в GPU вообще любят считать в "DEC стиле", т.е. игнорируя нововведения в IEEE.

Т.е. зачем нам верифицировать то, что по определению неправильно?

--
 
У нас же есть соседний чат, про верификацию ПО. "Откочёвываем"?

Итогом работы парсера является дерево разбора (parse tree), включающее в себя части грамматики, не имеющие практически никакого значения для последующих этапов компиляции - различного рода скобки, токены для начала/конца массивов и так далее.

Если я правильно понимаю, дальнейшая работа компилятора основывается на абстрактном синтаксическом дереве (abstract syntax tree), в котором значительное число вспомогательных конструкций отсутствует и само представление кода сильно упрощено.

В тех книгах которые я читал рассматриваются различные алгоритмы разбора (LL, LR, LALR и т.д.), позволяющие получить дерево разбора и внутреннее представление (абстрактное синтаксическое дерево) но не рассматриваются алгоритмы по переводу одного в другое.

Не могли бы вы порекомендовать литературу по алгоритмам, нацеленным на "переписывание" одного дерева в другое.  Я скорее всего смогу реализовать что-то свое, все же задача не настолько сложная, но возможно есть какие-то книги/статьи где уже это рассмотрено.

AST можно строить сразу без дерева разбора

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

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

на мой взгляд генерить сразу AST проще

ну если вы пишете парсер руками
если генератором парсеров, то там вы пляшете так как вам диктует генератор )

Вот например генерация AST при разборе выражений руками: https://gist.github.com/tsukanov-as/ab9b48bee66c31cdbbd2e2ec4f5f6bef

Есть ли хоть одна причина генерить тут дерево разбора? Лично я не вижу )

Чтобы сразу генерить AST (в LL, LR и т.д.), нужен либо совсем простой предельно контекстно-свободный язык, либо нужно мучительно бороться с контекстами. Поэтому есть такой подход — создавать дерево разбора в виде недо-AST, а вторым проходом "уточнять" его до настоящего AST, заменяя некоторые "обобщённые" узлы "конкретными".

Ключевое слово — "контекстуализация".

Ну я не настоящий сварщик. А есть пример чтоб было очевидно что это удобнее?

Не удобнее. Производителнее, но с приемлемой сложностью разработки.

Вот, это как раз ближе к тому что я хочу получить. Я пишу генератор парсеров - достаточно простой - и не хочу усложнять его дополнительными возможностями, доступными прямо во время разбора. Так что выдать "недо-AST" мне как раз гораздо удобнее.

Аааа, ну с генераторами то понятно )

Алгоритм для преобразования емнип в модерн компилерах описан

А дерево разбора само по себе может быть полезно а) для реконструкции входного текста и б) для продвинутых сообщениях об ошибках и т.п.

AST — это, всё-таки, потеря информации.

вру, забыл название

это потеря информации о процессе разбора
ничего другого там не теряется если этого специально не делать