Почему нет реализации Common Lisp, написанной на Common Lisp?

Недавно я начал изучать cuis-smalltalk, и я не понимаю, насколько глубокое и глубокое ООП с Smalltalk по сравнению с CLOS (я использую Ruby). Я понял, что Smalltalk - это рефлексивная система, реализованная сама по себе. Я обнаружил, что Ruby имеет Рубиниус, но когда я поискал реализацию Common Lisp, написанную на Lisp, я не нашел ничего похожего. Похоже, что дистрибутива CL, написанного на CL, не существует.

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

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

Ваш вопрос непонятен, по крайней мере, для меня (хотя я не голосующий против).

Leandro Caniglia 10.08.2018 15:45

Ну, я спрашиваю о возможных причинах, по которым не существует реализации CL, написанной на CL.

anquegi 10.08.2018 15:54

Многие реализации Common Lisp написаны в основном сами по себе: SBCL, CCL, Allegro CL, LispWorks, CMUCL и т. д. И т. Д. Части среды выполнения могут быть написаны на ассемблере, C или подобном. Это не отличается от Smalltalk, поскольку части виртуальной машины Smalltalk обычно также написаны на C - в дополнение к тем частям виртуальной машины, где подмножество Smalltalk компилируется в C. Часто реализации Lisp не используют виртуальные машины и используют компиляторы, написанные на Lisp. для генерации машинного кода или кода C (или кода JVM, ...).

Rainer Joswig 10.08.2018 18:05

Если вы используете cuis-smalltalk, он также использует виртуальную машину - и части этой виртуальной машины написаны на C в дополнение к файлам C, созданным Smalltalk.

Rainer Joswig 10.08.2018 18:09

Не похоже, что Rubinius GC написан на Ruby, он написан на C++: github.com/rubinius/rubinius/blob/master/machine/memory/gc.c‌ pp

Rainer Joswig 10.08.2018 18:19

@RainerJoswig: Ни одна виртуальная машина не написана на Ruby. Rubinius - это типичная реализация динамического языка с компилятором, который компилирует Ruby в байт-код и виртуальную машину с байт-кодом. Все, что связано с первым, написано на Ruby (компилятор, стандартная библиотека, основная библиотека, ядро), но все, что связано со вторым, написано на C++ (виртуальная машина, интерпретатор, сборщик мусора, объектная память, некоторые базовые классы ядра и методы). Как и большинство Smalltalks. Кроме того, механизм Regexp такой же, как и в YARV (Onigmo), который сам по себе уже представляет собой больше кода C, чем C++ виртуальной машины и Ruby компилятора и библиотеки вместе взятых.

Jörg W Mittag 10.08.2018 23:54

Несуществующий JIT-компилятор также был написан на C++, фактически с использованием LLVM API. Я считать, новый JIT должен быть написан на Ruby для упрощения экспериментов, удобства сопровождения и читабельности.

Jörg W Mittag 10.08.2018 23:56

@anquegi: Вы можете быть в восторге от Klein, виртуальной машины для Self, которая не только написана на Self, но и работает внутри самой себя. И я не имею в виду запуск одного экземпляра Klein поверх другого экземпляра. фактически запускается сам по себе, перекомпилируясь вместе с собой. Это умопомрачительно. Один из первоначальных разработчиков Self запустил Maxine, JVM, основанную на тех же концепциях. Некоторые идеи Максин теперь возвращаются в Oracle JDK.

Jörg W Mittag 11.08.2018 00:31
Стоит ли изучать PHP в 2023-2024 годах?
Стоит ли изучать PHP в 2023-2024 годах?
Привет всем, сегодня я хочу высказать свои соображения по поводу вопроса, который я уже много раз получал в своем сообществе: "Стоит ли изучать PHP в...
Поведение ключевого слова "this" в стрелочной функции в сравнении с нормальной функцией
Поведение ключевого слова "this" в стрелочной функции в сравнении с нормальной функцией
В JavaScript одним из самых запутанных понятий является поведение ключевого слова "this" в стрелочной и обычной функциях.
Приемы CSS-макетирования - floats и Flexbox
Приемы CSS-макетирования - floats и Flexbox
Здравствуйте, друзья-студенты! Готовы совершенствовать свои навыки веб-дизайна? Сегодня в нашем путешествии мы рассмотрим приемы CSS-верстки - в...
Тестирование функциональных ngrx-эффектов в Angular 16 с помощью Jest
В системе управления состояниями ngrx, совместимой с Angular 16, появились функциональные эффекты. Это здорово и делает код определенно легче для...
Концепция локализации и ее применение в приложениях React ⚡️
Концепция локализации и ее применение в приложениях React ⚡️
Локализация - это процесс адаптации приложения к различным языкам и культурным требованиям. Это позволяет пользователям получить опыт, соответствующий...
Пользовательский скаляр GraphQL
Пользовательский скаляр GraphQL
Листовые узлы системы типов GraphQL называются скалярами. Достигнув скалярного типа, невозможно спуститься дальше по иерархии типов. Скалярный тип...
7
8
1 265
3
Перейти к ответу Данный вопрос помечен как решенный

Ответы 3

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

SICL, безусловно, крутой, но, возможно, не стоит его учитывать, поскольку он не совсем полный. Но что касается lisp в Lisp, стоит взглянуть на загрузку clos в sicl.

Dan Robertson 10.08.2018 19:59
Ответ принят как подходящий

Пример: SBCL

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

Пример: Clozure Common Lisp

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

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

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

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

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

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

Bee Smalltalk полностью написан на Smalltalk.

Leandro Caniglia 10.08.2018 20:30

Vast VM (VA Smalltalk) тоже (старая VM) - в ней использовался код модели Smalltalk, переносимая сборка (для кроссплатформенности). (подробнее на: instantiations.com/PDFs/presentations/Smalltalks2015/…)

tukan 11.08.2018 18:53

Я думаю, вы объединяете 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.

Другие вопросы по теме