Чому ми не зберігаємо синтаксичне дерево замість вихідного коду?

У нас багато мов програмування. Кожна мова розбирається і перевіряється синтаксис перед тим, як перевести його в код, щоб побудувати абстрактне синтаксичне дерево (AST).

У нас є це абстрактне синтаксичне дерево, чому б ми не зберігали це дерево синтаксису замість вихідного коду (або поруч із вихідним кодом)?

Використовуючи AST замість вихідного коду. Кожен програміст в команді може серіалізувати це дерево на будь-яку мову, яку хоче (з відповідною граматикою контексту) і проаналізувати AST після їх закінчення. Таким чином, це усуне дискусію щодо питань стилю кодування (де поставити {і}, куди помістити пробіл, відступ тощо)

Які плюси і мінуси такого підходу?

Пробіли та коментарі

Зазвичай AST не включає пробіл, лінійні термінатори та коментарі.

Змістовне форматування

Ви впевнені, що в більшості випадків це є позитивним (виключає форматування святих воєн), є багато випадків, коли форматування оригінального коду передає певний сенс, наприклад, у багаторядкових літеральних рядках та "кодових абзацах" (розділяючи блоки висловлювання з порожнім рядком).

Код, який неможливо скласти

Хоча багато парсери дуже стійкі до відсутнього синтаксису, код з помилками часто призводить до дуже дивного синтаксичного дерева, що є чудовим і денді до тих пір, поки користувач не перезавантажить файл. Ви коли-небудь помиляєтесь у своєму IDE, а раптом у всього файлу з'явилися "squigglies"? Уявіть, як це було б перезавантажено іншою мовою.

Можливо, користувачі не вводять незмінний код, але, безумовно, у них є необхідність зберігати локально.

Жодна дві мови не є ідеальними

Як зазначали інші, майже не існує двох мов, які мають ідеальний паритет. Найближчим, на який я можу подумати, є VB і C #, або JavaScript і CoffeeScript, але навіть тоді VB має такі функції, як XML Literals, які не мають цілком еквівалентів у C #, і перетворення JavaScript у CoffeeScript може призвести до появи багатьох літератур JavaScript.

У програмному застосуванні, про яке я пишу, нам це потрібно зробити, оскільки очікується, що користувачі вводять "звичайні англійські" вирази, які перетворюються на JS у фоновому режимі. Ми розглядали лише можливість зберігання версії JS, але не знайшли прийнятного способу зробити це надійно завантаженим та вивантаженим, тому ми в кінцевому підсумку завжди зберігали як текст користувача, так і версію JS, а також прапор, який вказував, якщо "звичайний англійський" "версія проаналізована ідеально чи ні.

Чому б ми не зберегли це синтаксичне дерево замість вихідного коду? Кожен програміст в команді може серіалізувати це дерево на будь-якій мові, він хоче і проаналізувати AST, коли закінчив.

Дійсно, це розумна ідея. Майкрософт мав дослідницький проект у 1990-х роках, щоб зробити це майже точно .

На думку спадає кілька сценаріїв.

Перший досить тривіальний; як ви кажете, у вас може бути відображений AST на різні погляди в залежності від уподобань різних програмістів для таких речей, як інтервал і так далі. Але зберігання AST є надмірним для цього сценарію; просто напишіть собі симпатичний принтер. Коли ви завантажуєте файл у свій редактор, запустіть симпатичний принтер, щоб розмістити його у бажаному форматі, та поверніть його в початковий формат, коли ви збережете його.

Другий цікавіший. Якщо ви можете зберігати абстрактне синтаксичне дерево, зміна, що відрізняється кодом, стає не текстовою, а швидше синтаксичною. Перебудовування, де переміщується код, стає набагато простішим для розуміння. З нижньої сторони, звичайно, написання алгоритмів, що відрізняються від дерева, не зовсім тривіально, і це часто доводиться робити на мові. Текстова різниця працює майже для будь-якого мови.

Третє більше схоже на те, що Симоній передбачав умисне програмування: що основними поняттями, спільними для мов програмування, є те, що серіалізується, і тоді ви маєте різні погляди на ці концепції, викладені різними мовами. Хоча гарна ідея, потворний факт полягає в тому, що мови є досить різними у своїх деталях, що підхід із найменшим загальним знаменником насправді не працює.

Отже, коротше кажучи, це чудова ідея, але це величезна кількість додаткової роботи для порівняно невеликої вигоди. Ось чому навряд чи хто це робить.

Ви можете стверджувати, що саме цей байт-код є в .NET. Програма рефлектора Infact redgate переводить байт-код назад у ряд мов програмування .NET.

Однак є проблеми. Синтаксис є мовою, якою є стільки, скільки є речей, які ви можете представити на одній мові, які не мають представлення на інших мовах. Це відбувається в .NET, коли C ++ є єдиною мовою .NET, яка має доступ до всіх 7 рівнів доступу.

Поза середовищем .NET стає набагато складніше. Потім кожна мова починає мати власний набір пов'язаних бібліотек. Неможливо було б відобразити загальний синтаксис як на C, так і на Java, які відображали одне й те саме виконання інструкцій, оскільки вони вирішують симуляційні задачі дуже різними способами.

Мені подобається якась ваша ідея, але ви значно завищуєте, як легко перекласти мову на мову. Якби це було просто, вам навіть не потрібно було б зберігати AST, оскільки ви завжди можете розбирати мову X в AST, а потім переходити з AST до мови Y.

Однак я хотів, щоб специфікації компілятора бажали трохи більше розкрити деяку частину AST через якийсь API. Такі речі, як орієнтоване на аспекти програмування, рефакторинг та статичний аналіз програм, можна реалізувати через такий API, без того, щоб реалізатор цих можливостей мав потребу повторити таку роботу, яку вже виконали автори компілятора.

Дивно, як часто структура даних програміста для представлення програми є купою файлів, що містять рядки.

Я думаю, що найбільш помітними є такі:

• Користі немає. Ви сказали, що це означатиме, що кожен може використовувати свою домашню тварину. Але це неправда - використання зображення синтаксичного дерева дозволило б усунути лише синтаксичні відмінності, але не семантичні. Він певною мірою працює для дуже схожих мов - таких як VB і C #, або Java та Scala. Але навіть не там повністю.

• Це проблематично. Ви здобули свободу мови, але втратили свободу інструментів. Ви більше не можете читати та редагувати код у текстовому редакторі чи навіть будь-якому IDE - це залежить від конкретного інструменту, який говорить про ваше AST-представлення як для читання, так і для редагування коду. Тут нічого не здобуто.

  Щоб проілюструвати цей останній пункт, погляньте на RealBasic, який є власною реалізацією потужного діалекту BASIC. Деякий час це мало схоже на те, що мова може знятись, але вона повністю залежала від постачальника, до того, що ви могли переглядати код лише в їх IDE, оскільки він був збережений у фірмовому нетекстовому форматі. Велика помилка.

Я думаю, якщо ви зберігаєте і текст, і AST, ви насправді не додали нічого корисного, оскільки текст вже є однією мовою, і AST можна швидко відновити з тексту.

З іншого боку, якщо ви зберігаєте лише AST, ви втрачаєте речі, такі як коментарі, які неможливо відновити.

Я вважаю, що ідея цікава в теорії, але не дуже практична, оскільки різні мови програмування підтримують різні конструкції, деякі з яких не мають еквівалентів в інших мовах.

Наприклад, X ++ має висловлювання "while select", яке неможливо записати в C # без великої кількості зайвого коду (додаткові класи, додаткова логіка тощо). http://msdn.microsoft.com/en-us/library/aa558063.aspx

Я тут говорю, що в багатьох мовах є синтаксичні цукри, які перекладаються у великі блоки коду тієї самої мови або навіть елементи, які взагалі відсутні в інших. Ось приклад, чому підхід AST не працює:

Мова X має ключове слово K, яке перекладається в AST у 4 висловлюваннях: S1, S2, S3 та S4. Тепер AST перекладається мовою Y, а програміст змінює S2. Тепер, що відбувається з перекладом назад до X? Код перекладається як 4 твердження замість одного ключового слова ...

Останній аргумент проти підходу AST - це функції платформи: що відбувається, коли функція вбудована в платформу? Як і .NET’s Environment.GetEnvironmentVariable. Як ви це перекладаєте?

Навколо цієї ідеї побудована система: JetBrains MPS . Редактор трохи дивний, або просто інший, але загалом це не така велика проблема. Найбільша проблема, добре, що це не текст більше, тому ви не можете використовувати будь-якого зі звичайних текстових інструментів - інші редакторів, grep, sed, злиття і диференціалів інструментів і т.д.

Насправді є декілька продуктів, загальновідомих як "мовні робочі стійки", які зберігають AST і представляють у своїх редакторах "проекцію" AST назад на певну мову. Як сказала @ sk-logic, MPS JetBrains 'є однією з таких систем. Інший - Intentional Workbench від Intentional Software.

Потенціал для мовних робочих місць здається дуже високим, особливо в області доменних мов, оскільки ви можете створити проекцію, що залежить від домену. Наприклад, навмисна демонстрація DSL, що стосується електричної енергії, що проектується як схема, набагато простіше та точніше для обговорення та критики доменного експерта, ніж схема, описана на текстовій мові програмування.

На практиці мовні робочі стійки досить повільно втягуються, оскільки, окрім роботи з DSL, розробники, напевно, вважають за краще працювати на звичній загальній мові програмування. Якщо порівнювати голову до тексту з текстовим редактором або програмуванням IDE, мовні верстаки мають багато накладних витрат, і їх переваги не є настільки очевидними. Жодна з мовних робочих груп, яку я бачив, не зав'язала себе під час завантаження, до того моменту, коли вони можуть легко розширити власні IDE, тобто - тобто якщо мовні робочі верстати чудово підходять для продуктивності, чому б не покращилися інструменти мовних верстаків. -і - краще за швидшими та швидшими ставками?

Ви читали мою думку.

Коли я пройшов курс компіляторів, кілька років тому я виявив, що якщо взяти AST і серіалізувати його, з позначенням префікса замість звичайного позначення інфіксації, і використовувати дужки для розмежування цілих висловлювань, ви отримуєте Lisp. У той час як я дізнався про схему (діалект Лісп) у моїх студентських студіях, я ніколи насправді не оцінив її. Я безумовно вдячний Лісу та його діалектам, як результат цього курсу.

Проблеми з пропозицією:

1. важко / повільно скласти AST у графічному середовищі. Зрештою, більшість з нас може набрати швидше, ніж ми можемо рухати мишкою. І все ж виникає питання "як написати програмний код планшетом?" Введення на планшеті повільне / громіздке порівняно з клавіатурою / ноутбуком із апаратною клавіатурою. Якщо ви могли створити AST, перетягуючи компоненти з палітри на полотно на великому сенсорному екрані, програмування пристрою на планшеті може стати справжньою справою.

2. мало / жоден з наших існуючих інструментів це підтримує. У нас десятиліття розвитку завершилися створенням все складніших IDE та все більш інтелектуальних редакторів. У нас є всі ці інструменти для переформатування тексту, порівняння тексту, пошуку тексту. Де знаходяться інструменти, які можуть виконувати еквівалент звичайного пошуку виразів по дереву? Або різниця двох дерев? Всі ці речі легко зробити з текстом. Але вони можуть лише порівняти слова. Змініть ім’я змінної так, щоб слова були різними, але смислове значення було однаковим, і ці різні інструменти можуть зіткнутися з проблемою. Такі інструменти, розроблені для роботи над AST замість тексту, дозволять вам наблизитися до порівняння смислового значення. Це було б гарною справою.

3. в той час як перетворення вихідного коду програми в AST є відносно добре зрозумілим (у нас є компілятори та інтерпретатори, чи не так?), перетворення AST у програмний код не дуже добре зрозуміло. Помноження двох простих чисел для отримання великого, складеного числа є відносно простим, але множити велике, складене число назад на прості кошти набагато складніше; ось де ми знаходимось з розбором проти декомпіляції AST. Ось де різниця між мовами стає проблемою. Навіть у межах певної мови існує кілька способів декомпілювати AST. Ітерація через колекцію предметів і отримання якогось результату, наприклад. Використовувати цикл, повторюючи масив? Це було б компактно і швидко, але є обмеження. Використовуйте якийсь ітератор, працює над колекцією? Ця колекція може бути змінного розміру, що додає гнучкості за (можливий) рахунок швидкості. Карта / зменшення? Більш складний, але неявно паралельний. І це тільки для Java, залежно від ваших уподобань.

З часом зусилля з розробки будуть витрачені, і ми будемо розвиватися за допомогою сенсорних екранів та AST. Введення тексту стане менш необхідним. Я бачу, що сьогодні це є логічним прогресом, де ми знаходимось, дивлячись на те, як ми використовуємо комп’ютери, це вирішить №1.

Ми вже працюємо з деревами. Лісп - це просто серіалізовані АСТ. XML (і HTML за розширенням) - це просто серіалізоване дерево. Для пошуку у нас вже є пара прототипів: XPath та CSS (для XML та HTML відповідно). Коли будуть створені графічні інструменти, які дозволяють нам створювати селектори та модифікатори стилів CSS, ми вирішили частину №2. Коли ці селектори можуть бути розширені на підтримку регулярних виразів, ми будемо ближче. Ще шукаємо хороший графічний інструмент для порівняння двох XML або HTML документів. Коли люди розроблять ці інструменти, №2 буде вирішено. Люди вже працюють над такими речами; їх просто ще немає.

Єдиний спосіб я бачу можливість декомпілювати ASTs на текст мови програмування - це щось, що прагне до мети. Якщо я змінюю існуючий код, мета може бути досягнута алгоритмом, який робить мій модифікований код максимально подібним до початкового коду (мінімальна текстова різниця). Якщо я пишу код з нуля, мета може бути найменшим, найкруткішим кодом (можливо, для циклу). Або може бути код, який паралелізує максимально ефективно (можливо, карта / зменшення чи щось із залученням CSP). Отже, той самий AST може призвести до істотно різного коду, навіть тієї ж мови, виходячи з того, як були поставлені цілі. Розробка такої системи вирішила б №3. Це було б обчислювально складно, це означає, що нам, мабуть, знадобиться якесь розташування клієнт-сервер,

Якщо ви маєте намір усунути дискусію щодо стилів форматування, то, можливо, те, що ви хочете, - це редактор, який читає у вихідному файлі, форматує його відповідно до ваших особистих уподобань для відображення та редагування, але, зберігаючи його, переформатує у вибраний стиль команда використовує.

Це досить просто, якщо ви використовуєте такий редактор, як Emacs . Зміна стилю форматування цілого файлу - це три командні завдання.

Ви також повинні мати можливість створити гачки для автоматичного перетворення файлу у ваш власний стиль при завантаженні та перетворення його у командний стиль при збереженні.

Читати та змінювати AST важко замість вихідного коду.

Однак деякі інструменти, пов'язані з компілятором, дозволяють використовувати AST. Байт-код Java та проміжний код .NET працюють аналогічно AST.

це приємна ідея; але AST кожної мови відрізняється від усіх інших.

Єдине відоме мені виключення для VB.NET та C #, де microsoft стверджує, що вони "абсолютно однакова мова з різним синтаксисом". Навіть інші мови .NET (IronPython, F #, що завгодно) відрізняються на рівні AST.

Те ж саме і з мовами JVM, усі вони націлені на один і той же байт-код, але мовні конструкції різні, що робить його різними мовами та різними AST.

Навіть мови тонкого шару, як CoffeScript та Xtend, поділяють багато теорії основних мов (JavaScript та Java відповідно); але запровадити концепції вищого рівня, які (або повинні бути) зберігаються на рівні AST.

якби Xtend можна було реконструювати з Java AST, я думаю, що це було б визначено як "uncipiler" від Java до Xtend, який магічно створює абстракції вищого рівня з існуючого коду Java, ви не думаєте?