Я думаю перед тем как использовать эти системы, нужно начать сохранять код в виде этого самого AST, а не в plain text как это сейчас делается

это что ж, код с синтаксическими ошибками в мастер не закоммитить? непорядок! :)

Да!

Добавить комментарии в AST? Вроде ничего плохого не случится…

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

так может надо не хранить в AST (хранимые дифы только на размер влияют), а уметь сравнивать AST (а тут уже можно точнее, чем на тексте, дифф делать)?

А вот это очень интересно. К вопросу о "Haskell -- идеальный язык для написания компиляторов" ;)

Вместо одного универсального инструмента, понимающего почти любой текстовый формат, делать по отдельному инструментарию для каждого языка? Типичный фуллстек-веб проект использует минимум 5 различных языков программирования и разметки. Маслобойка получается

и что к этому вопросу имеете добавить? :)

Они там давно орут за то чтобы один язык для всего использовать (например, JS или Clojure) — будет весомый повод чтобы реально так и делать. 😉

Не очень понял, зачем на эту тему отвлеченно рассуждать. IDE, которые работают на уровне AST, существуют давно, просто они не популярны. Но есть же исключение — JetBrains MPS. Для ЯП из среды MPS вполне логично хранить код в виде деревьев, а не текста. Что тут нового?

Более того, у него нет возможности хранить код в виде текста — только AST.

Про эквивалентность — да, очень интересно. Изящное решение.

С помощью понятия контекста, эквивалентность сводится к универсальному понятию останова: два выражения эквивалентны, если не существует контекста, в котором одно выражение приведет к останову, а другое — не приведет (т.е., приведет к зацикливанию).

Остается очень выпуклым тот факт, что эквивалентность (в общем случае) не вычислима. А обобщение до выражения покрывает и функции (подпрограммы).

Спасибо за ссылку! Весьма познавательно )

Предложенная формализация позволяет убедительно ответить на вопрос, добавляет ли новая фича ("конструктор") выразительной мощности языку.  Но все-таки, она не позволяет сравнивать разные языки, и даже разные базовые фичи одного языка.

Например, одна фича добавляет выразительной мощности, и другая (независимая от первой) тоже добавляет. А какая добавляет больше? А язык с первой фичей или со второй фичей обладает большей выразительной мощностью?



Кстати, кажется докладчик делает логическую ошибку, когда говорит (момент 32:26), что из сохранения эквивалентности следует, что новая фича не привносит мощности (т.е., она выразима через существующие фичи).

Теорема (она в лекции приведена далее) говорит, что из нарушения эквивалентности следует невыразимость фичи.

И обратное неверно. А верно: из выразимости фичи следует сохранение эквивалентности.

этот универсальный инструмент слишком низкого качества

Ну если они выберут Rust для всего, то я за. А так ну нафиг

> А какая добавляет больше? А язык с первой фичей или со второй фичей обладает большей выразительной мощностью?

Лично мне не понятна практическая значимость "большей выразительности", но, наверное, можно "посчитать" сколько контекстов "сломалось" — кто больше "сломал", тот и выразительнее. 🤷‍♀️😁

Как будто для Rust есть AST-based IDE/diff/VCS/etc... 🤷‍♀️

Из этих соображений придётся MPS выбирать, как и сделали JetBrains для YouTrack.

Напишем!😁