Чому компілятори самостійного розміщення вважаються обрядом проходження нових мов?

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

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

Чи не було б більше сенсу витрачати зусилля, працюючи над тим, що дасть кращі результати?

Як що?

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

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

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

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

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

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

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

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

Стів Єгге написав чудову публікацію в блозі, яка, дещо опосередковано, вирішує це питання.

Велике значення №1: компілятори охоплюють майже всі аспекти інформатики. Вони курси вищого рівня, тому що вам потрібно знати всі інші речі, які ви дізнаєтесь у навчальній програмі з інформатики, щоб почати роботу. Структура даних, пошук та сортування, асимптотична продуктивність, забарвлення графіків? Це все там.

Існує причина, що Кнут працював над своїм монументальним (і нескінченним) «Мистецтвом комп’ютерного програмування» протягом декількох десятиліть, навіть незважаючи на те, що він починався як (просто) підручник із компілятора. Так само, як сказав Карл Саган: "Якщо ви хочете зробити яблучний пиріг з нуля, ви повинні спочатку винайти Всесвіт", якщо ви хочете написати компілятор, ви повинні спочатку розібратися майже з кожним аспектом інформатики.

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

Велика справа №2: від 30 000 футів дивовижна кількість проблем виглядає так само, як і компілятори.

Компілятори беруть потік символів, з'ясовують їх структуру за деякими заздалегідь визначеними доменними правилами та перетворюють їх в інший потік символів. Звучить досить загально, чи не так? Ну так.

Незалежно від того, працюєте ви в команді Visual C ++ чи ні, вам дуже часто доведеться робити щось, що схоже на частину компілятора. Я роблю це буквально кожен день.

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

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

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

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

Цього місяця я використовую порівняно новий і відомий некомплектний компілятор (ви, напевно, можете здогадатися, який із них), і я не можу пройти 2 дні, без того, що б це було зроблено. Цікаво, скільки дизайнерам насправді довелося цим користуватися.

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

Але ви не хочете більше писати компілятор мовою Y, ніж це потрібно, тож для початку ви реалізуєте лише підмножину мови - усуваючи зайві конструкції. У разі мови типу «С», в той час як , але не для чи робити під час . якщо ні, то жоден випадок або третій оп. Ніяких структур, об'єднань чи перерахувань. І т. Д. Те, що у вас залишилося, достатньо лише мови, щоб написати парсер і генератор рудиментарних кодів для мови X. Потім перевірте вихід. Знову.

Після цього ви зможете переписати джерело компілятора, яке було написано мовою Y, на мову X, і скомпілювати джерело мови X за допомогою компілятора, написаного мовою Y. Вихідним результатом буде новий компілятор, написаний новою мовою X, компілює мову X, тобто зараз це самохостинг. Однак це не є повним, оскільки ви реалізували лише підмножину мови мовою Y.

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

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

Ще 60 років тому, коли на сцену вперше прибули комп'ютери (а пізніше знову, коли мікропроцесори вперше прибули), інших мов Y, придатних для реалізації початкового компілятора, не було. Отже, перші компілятори повинні були бути записані в асемблерному коді, а потім, коли достатньо компілятора запущено, код збірки буде замінений версією, написаною новою мовою. Немає також асемблера? Весь процесор опустився на інший рівень, при цьому асемблер спочатку був записаний у машинному коді .

Чи можливо створити мову програмування, яка не розроблена для написання компілятора, але добре розроблена для інших цілей?

Дивлячись на таку мову, як SQL, я вважаю, що відповідь - так. Але мови такого характеру не мають загального призначення.

Хто це каже? ... все одно, це лише думка. Деякі можуть погодитися, інші - ні, тут немає правильного чи неправильного. Деякі мови мають компілятори, написані самі собою, а інші - ні. Що б там не було.

Тим не менш, я думаю, що це приємне вправа / доказ концепту, якщо мова здатна "самоскомпілювати" ... це просто ... приємно ... і це підтверджує, що мова підходить робити складні речі.

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

Кланг написаний на С ++. Перезаписати компілятор Clang Objective-C у Objective-C не було б надто складно, але тоді це було б зовсім марно. Будь-які зміни у компіляторі C ++ повинні були бути перероблені в Objective-C і навпаки. Так чому?

Зараз компілятор Clang Swift. Безумовно, що компілятор міг бути переписаний у Swift. Але яка це була б? Щоб продемонструвати, що мова достатньо потужна, щоб написати в ній компілятор? Нікого не хвилює, чи можна писати компілятори в Swift. Люди дійсно хвилює , якщо ви можете написати призначені для користувача інтерфейси в Swift, і ви явно можете.

Якщо у вас є добре перевірений компілятор, який легко адаптується для компіляції різних мов, переписувати його на різні мови зовсім безглуздо, якщо тільки перезапис однією іншою мовою не полегшить роботу з компілятором. І якщо це мало б сенс писати Clang в Swift, наприклад, то Clang C, C ++, і компілятор Objective-C буде все записати в Swift.

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

Це показує, що мова здатна обробляти складну обробку рядків і переводити її на іншу мову / інтерпретувати себе.

У процесі створення компілятора (перший великий проект) виникнуть питання, які вийдуть на перший план.