парсер жсона писал), нормально же для каждого правила в bnf создавать отдельный узел ast, тоесть структуру/enum и соответственно для каждого правила отдельный парсер(использую парсер комбинаторы из nom) или есть практики лучше/проще(мне просто такой подход показался очевидным). И нормально ли использовать паттерн посетитель(visitor) для узлов ast в случае вышеупомянутого r7rs?(пока не уверен, что на rust этот паттерн будет смотреться по человечески вообще)
Нормально. Стандартная практика. 👍
Кое что забыл, в р7рс, есть определение токенов, которое не используется дальше в грамматике и ещё пара таковых правил в бнф(комментарии например). Зачем они нужны? А насчёт комментариев, поскольку они также нигде не упоминаются в дальнейшем определении грамматики, мне единственным решением показалось просто их убрать перед тем как скормить код парсеру, это будет правильным?
Норм. Для не-продакшен интерпретатора подойдёт.
А как бы делалось в продакшн интерпретаторе(просто любопытно)?
Production-grade интерпретатор как минимум должен качественно сообщать об ошибках со ссылками/выдержками из исходника — для этого может потребоваться сохранять комментарии.
Ничего он такого не должен (точнее, это сильно зависит от его назначения), и тому есть немало примеров. ;)
Вы про production-grade интерпретаторы Scheme говорите? Потому что мы говорили про них.
Нет, я про production-grade интерпретаторы вообще (непонятно же, что Ваше утверждение ограничено именно этим контекстом, IMHO).
Ну все мои вопросы были по р7рс
Кстати, что насчёт других определений, которые далее не используются(токены например и ещё несколько вроде), я так и не понял зачем они нужны
Обсуждают сегодня