LINUX.ORG.RU

А бывает ли в Common Lisp объектная модель на сообщениях?

 


1

6

Как в ruby/smalltalk.

Или умерла вместе с Lisp machines/Genera/Flavors?

Хотелось бы знать, почему CLOS вытеснил все альтернативы. Плюс у сообщений в том, что для разных классов сообщения не обязаны иметь одинаковое количество параметров.

Ну и, в том же Racket, классы/объекты как раз работают на сообщениях.

★★★★★

почему CLOS вытеснил все альтернативы

потому, что более T

gensym ★★
()

Плюс у сообщений в том, что для разных классов сообщения не обязаны иметь одинаковое количество параметров.

Используй префиксы или пакеты для именования метода, если он принадлежит только одному классу, или используй &allow-other-keys и фильтруй нужные тебе аргументы.

gensym ★★
()
Ответ на: комментарий от gensym

Вот такой пример:

Python:

str1 = text-iter.text(end-iter);
str2 = text-buffer.text(start, end, include-hidden);
str2a = text-buffer.text(start, end);
str3 = button.text()

В CLOS приходится делать абсолютно тупой generic

(defgeneric text (object &key))

При том, что, например, для text-buffer реальный список параметров будет (start end &optional include-hidden), но сказать это уже никак.

И аксессор к полю text уже не сделать. Приходится городить

(defmethod text ((object text-buffer-struct) &key)
  (slot-value object 'text))

Чем плох вариант с

(defmessage text-buffer :text (start end &optional include-hidden)
   ...)
?

Всё равно, после (defgeneric text (object &key)) диспетчеризация возможна только по одному полю, так что хуже уже не будет. Опять же, не приходится делать аксессоры с именами width, height и 3d-object-length (потому как name clash). А можно делать те имена, которые удобны (совпадающие с initarg)

monk ★★★★★
() автор топика

почему CLOS вытеснил все альтернативы

Потому что более удобно. Посмотрите, при случае, на Dylan, кстати.

buddhist ★★★★★
()

Могу посоветовать посмотреть в сторону Tcl и XOTcl. Язык даже более развитый lisp-семейства, по моим скромным ощущениям более развитый нежели CL (Scheme не щупал толком, сказать ничего не могу, а Clojure - другое совсем уже ИМХО). Первый же пример XOTcl иллюстрирует как реализовать стэк приема/отсыки сообщений.

iMushroom
()
Ответ на: комментарий от buddhist

Посмотрите, при случае, на Dylan, кстати.

Там все те же грабли. Даже хуже

define method test-slot ()
end method test-slot;

define class <test> (<object>)
  slot test-slot, required-init-keyword: test-slot:;
end class <test>;

Скорей всего даст загадочную ошибку, что «такой метод уже есть».

monk ★★★★★
() автор топика
Ответ на: комментарий от iMushroom

Могу посоветовать посмотреть в сторону Tcl и XOTcl.

Так вот, смотрел. На tcl, ruby, smalltalk. А теперь с недоумением смотрю на CLOS и удивляюсь, почему это считается более удобным.

monk ★★★★★
() автор топика
Ответ на: комментарий от monk

CL и CLOS по моим скромным ощущениями слабее Tcl. Последний - не имеет налет из комьюнити Илиты, которая в большинстве своем - фанатики, поклоняющиеся упоротому синтаксису.

iMushroom
()
Ответ на: комментарий от monk

Так Dylan это «лисп без скобочек» =). Тем более от ябла (на сколько помню).

iMushroom
()
Ответ на: комментарий от buddhist

Тсссс. Не спугивай)...

А так, ИМХО, в Tcl самый простой и понятный синтаксис, составленный наименее упоротыми людьми. Как сказал в одном посте - Tcl даже с Lisp некорректно сравнивать ^_^. Один (Tcl) - мощный и гибкий язык с множеством вкусного, а другой (Lisp) - недоязычок, на котром окроме Emacs и еще пары мат.систем ничего годного не было написано. За более чем 50 лет :).

ТС'у: не мучай трупик CLOS, бери XOTcl и наслаждайся вещест...простым и понятным синтаксисом :), а так же полноценным (почти) ООП.

iMushroom
()
Ответ на: комментарий от iMushroom

Tcl самый простой и понятный синтаксис

Я с ним работал, думал он гвоздями к Tk прибит и FFI нет. Кстати в этом контексте два вопроса: где CPAN для tcl (для CL, например, common-lisp.net)? И есть ли толковая документация по переменным?

Если в lisp всего два вида переменных (special & lexical), то в TCL от uplevel и upvar вообще ничего непонятно.

И мне всегда казалось, что TCL на порядок медленней, чем sbcl

monk ★★★★★
() автор топика
Ответ на: комментарий от iMushroom

Тсссс. Не спугивай)...

составленный наименее упоротыми людьми

iMushroom

ты диллер?

nanoolinux ★★★★
()

смотрю я вот на лисп и поскольку в нём ничего не понимаю хочу спросить. что такого есть в лиспе, чего нет в ерланге? вопрос серьёзный если что. не срача ради.

nanoolinux ★★★★
()
Ответ на: комментарий от nanoolinux

что такого есть в лиспе, чего нет в ерланге?

Правильный ответ, наверное, «всё».

Изменяемые переменные. Макросы, строки. Классы, объекты. Циклы. Скобочный синтаксис :-)

monk ★★★★★
() автор топика
Ответ на: комментарий от monk

Я с ним работал, думал он гвоздями к Tk прибит и FFI нет. Кстати в этом контексте два вопроса: где CPAN для tcl (для CL, например, common-lisp.net)? И есть ли толковая документация по переменным?

Есть. Лучшую документацию чем у tcl я видел разве что в Ruby. На http://wiki.tcl.tk/ есть много кода, вопросответов, примеров, библиотек и т.п. http://tcllib.sourceforge.net/, стандартная библиотека.

http://www.tcl.tk/doc/ - тут описание всех функций, в том числе и переменных. Хотя по большому счету переменных один тип в TCL (апвар и аплевел имеют отношения к неймспейсам, а не к типам).

Аналога СРАN не припомню, полежности есть на вики. Про скорость - tcl по моему ничем не уступает CL. Разве что числодробилка на нем не слишком будет, это да. А тот же текст - обрабатывается очень шустро.

iMushroom
()
Ответ на: комментарий от nanoolinux

Лисп - программируемый язык, т.е. в нем очень сильно развито метапрограммирование. Иными словами - если что-то отсутствует, теоретически можно сделать через макросы. На практике...макросы лиспа тяжело поддерживать. Тот же tcl на порядок проще в этом отношении (как ни смешно - именно за счет своего наркоманского иснтаксиса, сила которого проявляется именнто тогда, когда занимаешься написанием макросов). Мне ерланг понравился больше лишпа + викинг более функционален, нежели язык обрезанных ногтей.

iMushroom
()
Ответ на: комментарий от monk

Кстати, а тесная интеграция с Tk - есть, т.к. тк написан на Си+Tcl, но как таковой может даже не устанавливаться с Tcl (который, кстати, имеет биндинги на все популярные тулкиты).

iMushroom
()
Ответ на: комментарий от monk

гвоздями к Tk прибит и FFI нет

Tk - рядовое расширение. FFI простой, быстрый и удобный

есть ли толковая документация по переменным

есть просто документация

где CPAN для tcl

нету

TCL на порядок медленней, чем sbcl

да. Tcl - язык, расчитанный на работу программным клеем для модулей, доступных по FFI и IPC. для того, чтобы получить эффективное приложение, все ресурсоёмкие вычисления должны выносится

jtootf ★★★★★
()
Ответ на: комментарий от iMushroom

тот же текст - обрабатывается очень шустро

нет. по крайней мере 8.5 на текстовых операциях влёгкую сдаёт всем популярным аналогам

jtootf ★★★★★
()
Ответ на: комментарий от buddhist

Это в Tcl-то не упоротый синтаксис?

а вот это вообще какой-то расхожий и совершенно потолочный миф. синтаксис Tcl будет непривычен разве что человеку, который уже пишет на языке с присваиванием с помощью знака равенства (что само по себе редкостный идиотизм); во всём остальном это C-like с гомогенным препроцессором

jtootf ★★★★★
()
Ответ на: комментарий от nanoolinux

что такого есть в лиспе, чего нет в ерланге?

Это язык общего назначения, а не скриптовый язык для скриптования кластеров на OTP.

(Да, хорошая трава у iMushroom)

naryl ★★★★★
()
Ответ на: комментарий от naryl

а не скриптовый язык для скриптования кластеров на OTP.

да ладно, лисп — точно такой же скриптовый, как и ерланг)) или нет?

nanoolinux ★★★★
()
Ответ на: комментарий от nanoolinux

Не припомню чтобы на скриптовых ЯП писали коммерческие ОС. Забудем пока, что все они давно закопаны. :)

naryl ★★★★★
()
Ответ на: комментарий от monk

Можно пример библиотеки, где используется?

Flavors же.

до CLOS на лисп-машинах была ООП библиотека с ООП в стиле смоллтока.

anonymous
()

Хотелось бы знать, почему CLOS вытеснил все альтернативы.

потому что общелисп это сраный треш. такой C++ мира лиспов. в одну кучу слепили из того что было несколько диалектов, а потом с грехом пополам это стандартизировали. отчего стандарт получился толстым и невнятным. какие-то бормотания, типа предки всегда так делали, поэтому в скрижалях записано вот так.

есть более аккуратные языки, изначально разумно спроектированные: схема, eulisp, ISO ISLISP.

там всё более аккуратно смотрится.

anonymous
()
Ответ на: комментарий от anonymous

К сожалению, аккуратно оно там только смотрится.

naryl ★★★★★
()
Ответ на: комментарий от anonymous

Flavors же.

И там прекрасно видно, что часть возможностей CLOS не «перекрыта».

yyk ★★★★★
()

Плюс у сообщений в том, что для разных классов сообщения не обязаны иметь одинаковое количество параметров.

Что-то я не совсем понял эту мысль и в чем тут плюс. Проиллюстрировать сможете? Хотя бы на том же Smalltalk.

yoghurt ★★★★★
()
Ответ на: комментарий от monk

В CLOS приходится делать абсолютно тупой generic

Щито? В питоновском примере все методы диспечатся только по своему классу. Ваш тупой дженерик полностью эквивалентен питоновскому коду.

Но ведь CLOS может и больше - можно иметь несколько дженериков с одинаковым названием но разными/несколькими специализациями. Параметры по которым специализация (и диспечризация) не нужна, могут быть какими угодно и сколько угодно, как и в питоне.

Мне кажется вы не вполне уловили суть того, что есть специализация обобщенной функции.

no-such-file ★★★★★
()
Ответ на: комментарий от nanoolinux

а у каких ещё не лиспоподобных она есть?

похоже что не у каких. :)

Bad_ptr ★★★★★
()
Ответ на: комментарий от yoghurt

Плюс у сообщений в том, что для разных классов сообщения не обязаны иметь одинаковое количество параметров.

Что-то я не совсем понял эту мысль и в чем тут плюс. Проиллюстрировать сможете? Хотя бы на том же Smalltalk.

a add: b. "Один параметр"
a add: c :after b, "Два параметра для OrderedCollection"

Если в CL стоит

(defgeneric add (collection item)
 ...)

То сделать

(defmethod add ((collection orderedcollection) item &key after) ...)

уже нельзя.

А переписывать сигнатуры всего и вся, до чего дотянулся (начиная с cl:length) тоже не приветствуется.

monk ★★★★★
() автор топика
Ответ на: комментарий от iMushroom

не смешите,tcl - язык общего назначения

да сколько угодно. вот только писал его Остерхаут в рамках проекта Sprite OS именно как программный клей, да и всё удачное использование опирается именно на такой подход - будь то AOL Server, Tcl ICE, Snack или OCD. цена за строковое метапрограммирование слишком высока, чтобы был смысл писать Tcl-only приложения

jtootf ★★★★★
()
Ответ на: комментарий от nanoolinux

а у каких ещё не лиспоподобных она есть?

у Tcl: всё есть строка. Tcl is LISP on drugs

jtootf ★★★★★
()
Ответ на: комментарий от no-such-file

Мне кажется вы не вполне уловили суть того, что есть специализация обобщенной функции.

Я скорее про то, что в питоне обобщенные функции живут в классе, а в CL — в пакете.

Предположим, я использую cl-containers. Там где в smalltalk будет container add: item after: old-item. В cl получаем отдельно append-item и insert-item-after.

monk ★★★★★
() автор топика
Ответ на: комментарий от nanoolinux

гомоиконность

а у каких ещё не лиспоподобных она есть?

Forth, Tcl

monk ★★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.