Недавно я начал изучать cuis-smalltalk, и я не понимаю, насколько глубокое и глубокое ООП с Smalltalk по сравнению с CLOS (я использую Ruby). Я понял, что Smalltalk - это рефлексивная система, реализованная сама по себе. Я обнаружил, что Ruby имеет Рубиниус, но когда я поискал реализацию Common Lisp, написанную на Lisp, я не нашел ничего похожего. Похоже, что дистрибутива CL, написанного на CL, не существует.
В Common Lisp с CLOS и slime вы можете делать все то же, что и среда разработки Smalltalk.
Но у меня есть вопрос, может ли реализация Common Lisp быть полезной для Common Lisp? Или не добавит ничего особенного в язык, потому что гомоиконность, макросы и MOP могут справиться со всем этим. Есть ли технические ограничения, почему это невозможно сделать?
Ну, я спрашиваю о возможных причинах, по которым не существует реализации CL, написанной на CL.
Многие реализации Common Lisp написаны в основном сами по себе: SBCL, CCL, Allegro CL, LispWorks, CMUCL и т. д. И т. Д. Части среды выполнения могут быть написаны на ассемблере, C или подобном. Это не отличается от Smalltalk, поскольку части виртуальной машины Smalltalk обычно также написаны на C - в дополнение к тем частям виртуальной машины, где подмножество Smalltalk компилируется в C. Часто реализации Lisp не используют виртуальные машины и используют компиляторы, написанные на Lisp. для генерации машинного кода или кода C (или кода JVM, ...).
Если вы используете cuis-smalltalk, он также использует виртуальную машину - и части этой виртуальной машины написаны на C в дополнение к файлам C, созданным Smalltalk.
Не похоже, что Rubinius GC написан на Ruby, он написан на C++: github.com/rubinius/rubinius/blob/master/machine/memory/gc.c pp
@RainerJoswig: Ни одна виртуальная машина не написана на Ruby. Rubinius - это типичная реализация динамического языка с компилятором, который компилирует Ruby в байт-код и виртуальную машину с байт-кодом. Все, что связано с первым, написано на Ruby (компилятор, стандартная библиотека, основная библиотека, ядро), но все, что связано со вторым, написано на C++ (виртуальная машина, интерпретатор, сборщик мусора, объектная память, некоторые базовые классы ядра и методы). Как и большинство Smalltalks. Кроме того, механизм Regexp такой же, как и в YARV (Onigmo), который сам по себе уже представляет собой больше кода C, чем C++ виртуальной машины и Ruby компилятора и библиотеки вместе взятых.
Несуществующий JIT-компилятор также был написан на C++, фактически с использованием LLVM API. Я считать, новый JIT должен быть написан на Ruby для упрощения экспериментов, удобства сопровождения и читабельности.
@anquegi: Вы можете быть в восторге от Klein, виртуальной машины для Self, которая не только написана на Self, но и работает внутри самой себя. И я не имею в виду запуск одного экземпляра Klein поверх другого экземпляра. фактически запускается сам по себе, перекомпилируясь вместе с собой. Это умопомрачительно. Один из первоначальных разработчиков Self запустил Maxine, JVM, основанную на тех же концепциях. Некоторые идеи Максин теперь возвращаются в Oracle JDK.
Ваше предположение неверно, SICL - это обычная реализация lisp, написанная на общем lisp: https://github.com/robert-strandh/SICL
SICL, безусловно, крутой, но, возможно, не стоит его учитывать, поскольку он не совсем полный. Но что касается lisp в Lisp, стоит взглянуть на загрузку clos в sicl.
Пример: SBCL
В основном только большие части время выполнения реализованы в C.
Пример: Clozure Common Lisp
ядро написан на ассемблере и C.
Пример: Меццано
Меццано - это ОС, полностью написанная на собственном Common Lisp. Он работает на металле -> означает, что в него можно загрузить как операционную систему.
Ни Smalltalks полностью написан на Smalltalk, ни Rubinius не написан полностью на Ruby.
Это не отличается от таких реализаций Smalltalk, как Squeak или Pharo, где большинство частей написано на Smalltalk, некоторые части виртуальной машины генерируются из Smalltalk на C, а некоторые части виртуальной машины написаны на C.
Части Рубиниуса написаны на C++.
Bee Smalltalk полностью написан на Smalltalk.
Vast VM (VA Smalltalk) тоже (старая VM) - в ней использовался код модели Smalltalk, переносимая сборка (для кроссплатформенности). (подробнее на: instantiations.com/PDFs/presentations/Smalltalks2015/…)
Я думаю, вы объединяете Common Lisp и CLOS. CLOS (обычно реализуемый с использованием MOP, но не обязательный) - это средство, предоставляемое Common Lisp, но нет требования, чтобы сам Common Lisp был написан таким образом, чтобы он действительно использовал CLOS, где это возможно. Как упоминал Райнер, виртуальная машина Smalltalk написана не только на Smalltalk, а Common Lisp (часто) уже в значительной степени написан на Common Lisp (есть некоторый низкоуровневый код поддержки в Assembly / C / something, а также некоторые собственные библиотеки, используемые для обеспечения Среда выполнения Lisp так же, как и для виртуальной машины Smalltalk. Я подозреваю, что ее больше для виртуальной машины Smalltalk из-за абстракции более высокого уровня, которую предоставляет виртуальная машина, и большего количества кода поддержки / связующего, необходимого для поддержки фасада.)
Я думаю, вы на самом деле понимаете, было бы полезно, если бы больше самого Lisp было написано на CLOS (который на тот момент, вероятно, больше не был бы Common Lisp), поскольку Common Lisp, как он обычно реализуется, обычно не использует CLOS (вообще?), а скорее делает CLOS доступным в качестве дополнительной объектно-ориентированной инфраструктуры для ваших приложений. В том виде, в каком он (обычно) реализован, Smalltalk сосредоточен на сообщениях, отправляемых методам (т. Е. Принятии решений во время выполнения), а Common Lisp больше сфокусирован на макросах, вызывающих (неуниверсальных) функций (т. Е. Принятии многих, но не всех решений на этапе выполнения). Это фундаментальные решения по дизайну и реализации, но нет никаких причин, по которым вы не могли бы создать Лисп, более «похожий на Smalltalky», используя CLOS и откладывая больше решений на выполнение.
Как вы уже отметили, у Lisp уже есть очень динамичная среда с интерактивным «ощущением», аналогичным Smalltalk, так что же это даст вам? Как правило, вы получите более экстремальный динамизм, который предлагает среда выполнения Smalltalk, и с точки зрения организации кода вы заменили бы многое из того, что alist, plist, defparameter, defvar, и, в некоторой степени, какие пространства имен используются, на объектные слоты. Вы, вероятно, также получите меньший набор более общих функций (Common Lisp предлагает подход к функциональности кухонной раковины: макросы и функции почти для каждого варианта использования, который вы можете себе представить) для поддержки более экстремальных возможностей, которые может предложить объектно-ориентированный объект (т.е. прокси-объекты становятся тривиальными для реализации, переопределение подсистем, таких как отладчик, становится простым и т. д.) Хотя все еще существуют различия в реализациях объектно-ориентированного программирования между Smalltalk и Lisp (одиночная и множественная диспетчеризация, одиночное и множественное наследование, методы и универсальные функции, отправка сообщений против вызовов функций и т. д.), я думаю, что это может дать вам 95% + того, что предлагает Smalltalk. Сколько это вам стоит? Ясность во время компиляции и производительность во время выполнения ... цена, которую Smalltalk платит в настоящее время. Вероятно, большее беспокойство у большинства Лисперов вызвало бы то, что код будет выглядеть и ощущаться иначе, чем то, к чему они привыкли, так же, как Clojure отличается от Common Lisp. Так что в итоге вы получите новый Лисп с ощущением Smalltalky, а не другую реализацию Common Lisp.
Ваш вопрос непонятен, по крайней мере, для меня (хотя я не голосующий против).