Якщо все, що ви хотіли, було статично набраною мовою, схожою на Lisp, ви могли це зробити досить легко, визначивши абстрактне дерево синтаксису, яке представляє вашу мову, а потім зіставивши цей AST з S-виразами. Однак я не думаю, що я би назвав результат Ліспом.
Якщо ви хочете чогось, що насправді має характеристики Lisp-y, крім синтаксису, можна зробити це зі статично набраною мовою. Однак для Lisp є багато характеристик, з яких важко отримати набагато корисні статичні типи. Для ілюстрації давайте розглянемо саму структуру списку, яку називають мінусами , яка утворює первинний будівельний блок Lisp.
Виклик списку мінусів, хоч і (1 2 3)схожий на один, є дещо помилковим. Наприклад, це зовсім не порівнянно зі статично типізованим списком, як, наприклад, зі списком C ++ std::listабо Haskell. Це одновимірні пов'язані списки, де всі комірки одного типу. Лисп щасливо дозволяє (1 "abc" #\d 'foo). Крім того, навіть якщо ви розширите свої статичні типи списків на покриття списків списків, тип цих об'єктів вимагає, щоб кожен елемент списку був підсписком. Як би ви представляли ((1 2) 3 4)в них?
Лисп конси утворюють двійкове дерево, з листям (атомами) і гілками (конси). Крім того, листя такого дерева можуть взагалі містити будь-який атомний (без мінусів) тип Lisp! Гнучкість цієї структури - це те, що робить Lisp настільки хорошим в обробці символічних обчислень, AST та самому перетворенні коду Lisp!
Отже, як би ви змоделювали таку структуру мовою, що має статичний тип? Спробуємо це в Haskell, який має надзвичайно потужну та точну систему статичного типу:
type Symbol = String
data Atom = ASymbol Symbol | AInt Int | AString String | Nil
data Cons = CCons Cons Cons
| CAtom Atom
Вашою першою проблемою буде сфера застосування типу Atom. Зрозуміло, що ми не вибрали тип Atom, який має достатню гнучкість, щоб охопити всі типи об'єктів, за якими ми хочемо перекинутись за conses. Замість того, щоб намагатися розширити структуру даних Atom, як перераховано вище (що ви добре бачите, крихкий), скажімо, у нас був магічний клас типу, Atomicякий відрізняв усі типи, які ми хотіли зробити атомними. Тоді ми можемо спробувати:
class Atomic a where ?????
data Atomic a => Cons a = CCons Cons Cons
| CAtom a
Але це не спрацює, оскільки вимагає, щоб усі атоми в дереві були одного типу. Ми хочемо, щоб вони могли відрізнятися від листя до листя. Для кращого підходу потрібно використовувати екзистенційні кількісні показники Haskell :
class Atomic a where ?????
data Cons = CCons Cons Cons
| forall a. Atomic a => CAtom a
Але тепер ви прийшли до суті справи. Що ви можете зробити з атомами в такій структурі? З якою спільною структурою вони можуть бути змодельовані Atomic a? Який рівень безпеки типу вам гарантований при такому типі? Зверніть увагу, що ми не додали жодних функцій до нашого класу типів, і це є вагома причина: атоми не мають нічого спільного в Lisp. Їх супертип у Ліспі називають просто t(тобто вершиною).
Для того, щоб використовувати їх, вам доведеться придумати механізми, щоб динамічно примусити значення атома до того, що ви можете реально використовувати. І в цей момент ви в основному реалізували динамічно типізовану підсистему у вашій статично набраній мові! (Не можна не відзначити можливий наслідок Десятого правила програмування Грінспуна .)
Зауважимо, що Haskell забезпечує підтримку саме такої динамічної підсистеми з Objтипом, що використовується в поєднанні з Dynamicтипом і класом Typeable, щоб замінити наш Atomicклас, які дозволяють зберігати довільні значення з їх типами, і явний примус назад з цих типів. Це та система, яку вам потрібно було б використовувати для роботи зі структурами Lisp мінусів у повній загальності.
Можна також зробити інший шлях та вставити статично типову підсистему в істотно динамічно набрану мову. Це дозволяє вам скористатися перевіркою статичного типу для частин програми, які можуть скористатися більш суворими вимогами типу. Це, мабуть, такий підхід, наприклад, у обмеженій формі точної перевірки типу CMUCL .
Нарешті, існує можливість наявності двох окремих підсистем, динамічно та статично типізованих, які використовують програмування в контрактному стилі, щоб допомогти орієнтуватися на перехід між ними. Таким чином мова може пристосовувати звичаї Lisp, коли статична перевірка типу буде скоріше перешкодою, ніж допомогою, а також використанням, де статична перевірка типу буде вигідною. Це такий підхід, який використовується Типізована ракетка , як ви побачите з коментарів, які випливають.