it-roy-ru.com

Почему в Common Lisp не написана реализация Common LISP?

Недавно я начал изучать cuis-Smalltalk, и я не понимаю, насколько глубоким и глубоким OOP с Smalltalk по сравнению с CLOS (я использую Ruby). Я узнал, что идея Smalltalk - это отражающая система, реализованная сама по себе. Я обнаружил, что Ruby имеет Rubinius , но когда я искал реализацию Common LISP , написанную на LISP, я не смог найти ничего подобного. Кажется, что дистрибутив CL не написан на CL.

В Common LISP с CLOS и slime вы можете делать все, что можно сделать со средой разработки Smalltalk.

Но у меня есть вопрос, может ли реализация Common LISP сама по себе быть полезной для Common Lisp? Или не добавит ничего особенного в язык, потому что гомоконичность, макросы и СС могут справиться со всем этим. Существуют ли технические ограничения, почему это невозможно сделать?

7
anquegi

Пример: SBCL

В основном в Си реализованы только большие части runtime .

Пример: Clozure Common LISP

ядро ​​ написано на ассемблере и C.

Пример: Меццано

Mezzano - операционная система, полностью написанная на своем собственном Common LISP. Он работает на металле -> означает, что его можно загрузить как операционную систему.

Ни Smalltalks полностью не написаны на Smalltalk, ни Rubinius не полностью написаны на Ruby

Это ничем не отличается от реализаций Smalltalk, таких как Squeak или Pharo, где большинство частей написано на Smalltalk, некоторые части виртуальной машины сгенерированы из Smalltalk в C, а некоторые части виртуальной машины написаны на C.

Части Рубиния написаны на C++.

13
Rainer Joswig

Ваше предположение неверно, SICL - это обычная реализация LISP, написанная на общем LISP: https://github.com/robert-strandh/SICL

4
jmercouris

Я думаю, что вы объединяете Common LISP и CLOS. CLOS (обычно реализованный с использованием MOP, но не обязательный) - это средство, предоставляемое Common LISP, но нет требования, чтобы сам Common LISP был написан таким образом, чтобы он фактически использовал CLOS, где это возможно. Как упомянул Райнер, Smalltalk VM не написан чисто на Smalltalk, и Common LISP (часто) уже в значительной степени написан на Common LISP (есть некоторый низкоуровневый код поддержки в Assembly/C/what и некоторых родных библиотеках). используется для обеспечения среды выполнения LISP так же, как и для виртуальной машины Smalltalk. Я подозреваю, что ее больше для Smalltalk VM из-за высокоуровневой абстракции, которую предоставляет VM, и более поддержка/клеевой код, необходимый для поддержания фасада.)

Я думаю, что вы на самом деле получаете то, что было бы полезно, если бы большая часть самого LISP была написана в CLOS (которая на тот момент, вероятно, больше не была бы Common LISP), так как Common LISP, поскольку он обычно реализуется, обычно не использует CLOS (вообще?), но скорее делает CLOS доступным в качестве необязательного OO фреймворка для ваших приложений. Поскольку он (обычно) реализован, Smalltalk ориентирован на отправку сообщений в методы (то есть на принятие решений во время выполнения), а Common LISP больше нацелен на макросы, вызывающие (неуниверсальные) функции (то есть принятие многих, но не всех, решений на время компиляции.) Это фундаментальные решения по проектированию и реализации, но нет никаких причин, по которым вы не могли бы создать LISP, который имел бы больше ощущения Smalltalky, используя CLOS и откладывая больше решений во время выполнения.

Как вы уже отметили, LISP уже имеет очень динамичную среду с похожим интерактивным «ощущением» на Smalltalk, так что же это даст вам? Как правило, вы получите более экстремальный динамизм, который предлагает среда выполнения Smalltalk, и с точки зрения организации кода вы замените большую часть того, что alist, plist, defparameter, defvar, и в некоторой степени то, для чего используются пространства имен с объектными слотами. Вы, вероятно, также получили бы меньший набор более общих функций (Common LISP предлагает подход к функциональным возможностям для кухни: макросы и функции практически для каждого случая использования, которые вы можете себе представить) для поддержки более экстремальных возможностей, которые OO может предложение (т. е. прозрачные прокси-объекты становятся тривиальными для реализации, переопределение подсистем, таких как отладчик, становится легким и т. д.) Несмотря на то, что в реализациях OO все еще существуют различия между Smalltalk и LISP (один против нескольких отправлений, один против нескольких наследование, методы против общих функций, отправка сообщений против вызовов функций и т. д.), я думаю, что это, вероятно, даст вам 95% + от того, что предлагает Smalltalk. Сколько это будет стоить? Четкость во время компиляции и производительность во время выполнения ... цена, которую Smalltalk платит в настоящее время. Вероятно, большее беспокойство для большинства Lispers будет связано с тем, что код будет выглядеть и чувствовать себя не так, как он привык, в отличие от того, как Clojure отличается от Common LISP. В итоге вы получите новый LISP с ощущением Smalltalky, а не другую реализацию Common LISP.

1
blihp