Common Lisp V.S. Scheme

В каком месте не классы?

Только для примитивных (build-in-class) типов, и нет для всех производных типов. Т.е. нет механизма унификации по сложным типам - которые могут быть составлен с помощью набора типовых конструкторов or/member/и т.д.

(deftype cons-or-number () '(or cons number))

(defmethod foo ((a cons-or-number))
  ())
;; нет класса по имени cons-or-number, т.е. build-in типы проходят
;; процедуру отображения в классы (в реализации), а определяемые
;; пользователем не проходят такой процедуры (автоматически).

(defmethod foo ((a (or cons number)))
  ())
;; и анонимно - тем более не получится.

но filtred functions из closer-mop позволяют такое использование.

Кого это, простите, сношает?

Тех, кто решит изучать это ваш хвалёный лисп, и столкнётся с необходимостью выбора IDE.

Если Вы имели в виду Common Lisp, то попробуйте LispBox

> Меня еще в 6-м классе сильно побили вот этим, потому мне тоже не до смеха

Алгол в чём-то современные языки превосходит. Где ещё контракты (дано, надо) найдёшь? ;)

> Где ещё контракты (дано, надо) найдёшь? ;)

http://ru.wikipedia.org/wiki/Eiffel

где-то тут на ЛОРе есть чел, который пишет на нём профессионально

Ну раз уж на то пошло http://ru.wikipedia.org/wiki/D_(язык_программирования)

> Ну раз уж на то пошло http://ru.wikipedia.org/wiki/D_(язык_программирования)

и где там «контрактное программирование»?

> и где там «контрактное программирование»?

Вот тот текст что у вас в кавычках попробуйте на странице поискать.

(да, ссылка не совсем прямая :])

> Вот тот текст что у вас в кавычках попробуйте на странице поискать.

нашел, шо ж они запрятали так? =)

> Ничего себе «опечатка». Разве в CL не так же?

Не совсем. Я имел в виду, что (class-of 42) в оригинальном tiny-clos выдает ерунду, а в православном CLOS обычно #<BUILT-IN-CLASS FIXNUM>. Последствия плачевны - нельзя создать метод с диспетчеризацией по встроенному типу.

просто часто замечал как схемеры хвастаются наличием нескольких ООП реализаций

Ага, только ни в какой ревизии ООП нет, поэтому в каждой реализации свои велосипеды (именно несколько). В большинстве из них, нет даже множественного наследования, не говоря уж о мультиметодах. Где-то есть интерфейсы как в яве, где-то расширение/сужение классов - извращаются кто во что горазд. Есть большое количество реализаций ООП на прототипах, что конечно неплохо, только используют их видимо 3,5 человека, включая автора.

В общем вывод такой - пока схемеры не засунут свои ревизии сами знаете куда и не запилят Common Scheme, каждый кто захочет написать на scheme, что либо сложнее калькулятора, вынужден будет для начала запилить CLOS, рестарты, туеву хучу мелких, но полезных функций - собственно сделать из схемы - CL.

У-у-у... О таком схемеры даже и не мечтают - в их многочисленных реализациях подобное вообще не предвидится.

> Не совсем. Я имел в виду, что (class-of 42) в оригинальном tiny-clos выдает ерунду, а в православном CLOS обычно #<BUILT-IN-CLASS FIXNUM>. Последствия плачевны - нельзя создать метод с диспетчеризацией по встроенному типу.

в swindle можно.

В общем вывод такой - пока схемеры не засунут свои ревизии сами знаете куда и не запилят Common Scheme, каждый кто захочет написать на scheme, что либо сложнее калькулятора

возьмёт, например, Racket.

рестарты

в Scheme не нужны.

туеву хучу мелких, но полезных функций

Racket

собственно сделать из схемы - CL.

между CL и Scheme чуть больше отличий, чем

CLOS, рестарты, туева хуча мелких, но полезных функций

> У-у-у... О таком схемеры даже и не мечтают - в их многочисленных реализациях подобное вообще не предвидится.

толстовато

Понятно. Это всё потому что в CLOS вообще во многом интегрируется с типовой системой - это не автоматически, просто стандарт требует планомерной проработки всех «швов». Например, не только типы можно использовать как классы в специальных методах, но и классы/структуры создают типы, что может пригодится в стандартных макросах вроде

(defclass foo () (a))

(typecase (make-instance 'foo)
  (foo 'foo)
  (t   'not-foo))
; =>
; FOO

Ну и то что разные typep/type-of/subtypep/... работают непротиворечиво - тоже само собой (typecase раскрывается в cond который эти функции и используют). В TinyCLOS тогда действительно баги - несоответствие стандарту CLOS (хоть оно и Tiny).

В общем вывод такой - пока схемеры не засунут свои ревизии сами знаете куда и не запилят Common Scheme

Ну тут позвольте не согласиться - видел как на Racket делаются серьёзные приложения, так что определённое движение (этот самый «большой Scheme») есть.

> в swindle можно

Работает только в PLT?

возьмёт, например, Racket

туеву хучу мелких, но полезных функций

Racket

Так и запишем - собственно scheme для программирования не пригодна. И кстати, если нужно выкинуть схему и взять что-то другое, более пригодное, может быть лучше взять сразу CL?

между CL и Scheme чуть больше отличий, чем

CLOS, рестарты, туева хуча мелких, но полезных функций

Да, есть еще одно, ну и что?

Что, уже мечтают? Ну пусть переходят на CL.

> Ну тут позвольте не согласиться - видел как на Racket делаются серьёзные приложения

Ну позвольте и мне не согласиться - рэкет может и хорош, только к схеме имеет косвенное отношение. Все равно что CL по отношению к MacLisp - согласитесь, что это разные языки.

Так а чем Racket отличается от PLT Scheme кроме названия? Как я понял там просто определённая идеологическая перестановка произошла (потому что первые репорты именно о racket - довольно древние), но это всё же scheme (некоторое время у них на сайте половина ссылок вела на plt-scheme, половина на racket :)). Но даже если это super-scheme, то туда ему и дорога :) Т.е. пусть двигается в такую сторону. По крайней мере можно взять любой код на scheme и он будет работать в Racket - R5RS, R6RS, SRFI.

Кто-нибудь SISC использует? Оно живое? А то сайт в 2007 последний раз обновлялся, wiki не пашет.

> Что, уже мечтают?

если бы оно им было надо — сделали бы.

> Так и запишем - собственно scheme для программирования не пригодна. И кстати, если нужно выкинуть схему и взять что-то другое, более пригодное, может быть лучше взять сразу CL?

так и запиши: собственно CL для программирования не пригоден, лучше взять C++/Java/Python/где-там-ещё-куча-батареек

> Да, есть еще одно

не одно, больше

> так и запиши: собственно CL для программирования не пригоден, лучше взять C++/Java/Python/где-там-ещё-куча-батареек

Ололо, какие мы обидчивые. А скажите, вы лично так схему любите потому, что это не какойто-там быдлопайтон и в ней нет батареек? Илита?

> Если бы оно им было надо — сделали бы.

Ну да, им видимо надо в каждую реализацию запиливать по 3 ни чем не совместимых, глючных ООП недосистем.

> не одно, больше

Ну ладно, два.

> Так а чем Racket отличается от PLT Scheme кроме названия?

Тем что его создатели поняли, что на голой схеме далеко не уедешь, вот и пилят свой язык наплевав на все стандарты. Кто первый встал - того и тапки.

По крайней мере можно взять любой код на scheme и он будет работать в Racket

Ну код вида (+ 1 2 3) вообще в любом лиспе будет работать, и что?

> ни чем не совместимых, глючных ООП недосистем.

пруф?

Что пруф? ООП система из bigloo совместима с системой из guile, и они обе совместимы с ООП в chicken? Ну идите маны почитайте. И да, приведите мне уже аналог clos, чтоб работал без напильника в пятой/шестой ревизии.

Ну код вида (+ 1 2 3)

У меня плохие новости: похоже вы не умеете читать :) Я ж написал - R5RS, R6RS, SRFI т.е. всё что играет в Scheme роль стандарта. Это Scheme, нечто определённое.

Тем что его создатели поняли, что на голой схеме далеко не уедешь

Ничего подобного - точно также никуда не уедешь на том о чём пишут в CLTL/CLHS, поэтому в реализациях есть много своих расширений, но ведь это по прежнему CL - т.е. стандартное ядро + набор расширений для real world, есть даже такие начинания - CADR, CLTL3 тоже с тем же подтекстом что и Racket, т.е. стандартизация уже де-факто общепринятых в разработке вещей (для CL это библиотеки утилит, которые надо бы унифицировать, сокеты, треды, потоки, интерфейс к GC, FFI ну и т.д.).

И да, приведите мне уже аналог clos

Бери уже Racket и пейши программы :) Если не понравится - бери CL.

Что делать, если не понравится CL?

Что делать, если не понравится CL?

Ну это смотря что значит «не понравится» - бывает недовольство чисто практическое, мол не хватает такой-то библиотеки и вообще язык «маргинальный» (т.е. нет серьёзных коммерческих компаний которые продвигают именно open source, у CL только ITA software немного подтолкнула ClozureCL и SBCL, да и то за счёт энтузиазма своих CL-разработчиков, плюс ещё какие-то случаи коммерческого использования с профитом для open source). В этом случае всё просто, раз это open source, пишутся патчи, пишутся библиотеки - своими силами.

Другое дело принципиальное недовольство, то есть самой архитектурой языка. Кому-то не нравится Scheme из-за своей рафинированности, кому-то СL из-за своей императивности или отсутствия каких-то выразительных средств. Тут уже «на вкус и цвет ...» и выбор под задачу - я пока не видел универсального языка, в любом случае можно дойти до границ выразительности или найти вещи для которых язык не предназначен.

В общем на чашах весов всегда «нравится сам язык» и «но вот, блин, много пилить надо».

> Что пруф? ООП система из bigloo совместима с системой из guile, и они обе совместимы с ООП в chicken?

вай-вай, странно, но если я не подключу какой-нибудь модуль/библиотеку (в любом языке), то у меня функции из этого модуля/библиотеки не работают =( библиотека не совместима с моим языком! не пишите бред. вещи, не описанные в стандарте языка не обязаны быть одинаковыми в разных реализациях. то же самое и в CL: MOP представлен разными пакетами в разных реализациях, в LispWorks он в пакете CLOS, в SBCL — в SB-MOP, TCO так же никто не гарантирует и т.д. и т.п.

> Что делать, если не понравится CL?

вдоль.

> Я ж написал - R5RS, R6RS, SRFI т.е. всё что играет в Scheme роль стандарта

А что (+ 1 2 3) не соответствует r5rs?

Вы же сами сказали:

видел как на Racket делаются серьёзные приложения

Вот именно, что не на R5RS/R6RS + SRFI. Эти приложения на рэкете запустятся на MIT-scheme? Или может быть в scheme48?

> поэтому в реализациях есть много своих расширений, но ведь это по прежнему CL - т.е. стандартное ядро + набор расширений для real world

Вопрос где кончается язык и начинаются библиотеки - очень тонкий, особенно в лиспе. ИМХО есть стандарт, все что в него включается есть базис, который должен быть доступен везде и от которого можно плясать не опасаясь, что где-то программа не заработает. В этом смысле CLOS часть CL, неотъемлемая часть. Где нет CLOS, это уже не CL. Тоже самое и с рестартами и с функциями-утилитами и т.п.

тоже с тем же подтекстом что и Racket, т.е. стандартизация уже де-факто общепринятых в разработке вещей (для CL это библиотеки утилит, которые надо бы унифицировать, сокеты, треды, потоки, интерфейс к GC, FFI ну и т.д.).

Во-первых, все эти библиотеки, интерфейсы и прочее прекрасно работает в большинстве реализаций CL. Благо в нем есть #+ для специфичных вещей.

Во-вторых, общий стандарт для всех это одно, а vendor-specific фичи рэкета это немного другое.

Подключи мне ООП систему из рэкета в MIT-scheme - посмотрю, как профи работают.

> Бери уже Racket и пейши программы :)

Там таки есть аналог CLOS? Даже с произвольными комбинаторами методов?

Если не понравится - бери CL

Давно уже взял.

> Во-первых, все эти библиотеки, интерфейсы и прочее прекрасно работает в большинстве реализаций CL. Благо в нем есть #+ для специфичных вещей.

ты не поверишь, но для Схемы есть, например, snowfort — набор библиотек, работающий на большинстве известных реализаций.

> Там таки есть аналог CLOS? Даже с произвольными комбинаторами методов?

Да. Да.

Я себе представил как это тормозит.

> Я себе представил как это тормозит.

ну ты можешь представлять себе что угодно, да. на реальность это не влияет

Ок, давай сравним. Производительность CLOS в SBCL и как оно там называется в «Racket». Но, только, разумеется, если оно там сравнимо по возможностям с оригинальным CLOS+MOP. Т.е. не только обобщенные функции, но и фичастые классы, множественное наследование, комбинаторы методов, и прочее, и все оное же в рантайме создаваемое и изменяемое.

Над эффективными реализациями CLOS для CL люди, в т.ч. несколько коммерческих компаний немаленького размера, работали десятилетиями.
И то, тормозит.

Поэтому в производительность оного в реализации полуакадемической Scheme(ну ладно, Racket) продвигаемой одной небольшой компанией, я не верю.

> но и фичастые классы

что это значит? (остальное имеется)

и как сравнивать будем?

А что (+ 1 2 3) не соответствует r5rs?

Не в этом дело - нужно чётко очерчивать понятия, сумма трёх чисел это ничего, а вот r5rs это целая категория которая собственно и определяет что такое Scheme как язык. Сразу всё понятно, Scheme это:

1) Два репорта, первый очерчивает все специальные формы и функции, синтаксис и семантику языка, второй добавляет много слов, но специальных форм вводит всего несколько - главным образом eval и call/cc.

2) Не совместимые между собой реализации

3) SRFI расширения

4) Отдельные библиотеки - переносимые между разными реализациями или нет.

А теперь, если сравнить с Common Lisp:

1) Есть стандарт, описанный в CLHS и CLTL1, есть ANSI стандарт, который расходится в мелочах с CLTL2 (нет некоторых фич из последней).

2) Есть не совместимые между собой реализации

3) Есть «стек» прослоек которые унифицируют различия между реализациями. Эти библиотеки не стандартизированы, хотя многие согласны с тем, что надо бы, чтобы это всё было закреплено и реализации предоставляли именно такой интерфейс, без прослоек.

4) И расширения/библиотеки/приложения. Причём из-за (3) они, в принципе, должны быть более менее общими для реализаций.

видел как на Racket делаются серьёзные приложения

Вот именно, что не на R5RS/R6RS + SRFI. Эти приложения на рэкете запустятся на MIT-scheme? Или может быть в scheme48?

Это было конкретное приложение конкретно для Racket (т.е. из серии «вам шашечки или ехать?» :)). К примеру, ни на стандартном Scheme, ни на стандартном CL не напишешь веб-сервера (как и на определённом в Prelude хаскеле, ну и т.д. - бывают языки, вроде Python, в которых вообще не думают о таких вещах как стандартизация, а есть языки в которых закрепляют небольшое абстрактное ядро - остальное на совести реализаций).

А ещё, я могу запилить Scheme который будет соответствовать R5RS, ведь язык простой, но это будет просто поделка на которой ничего толкового не напишешь - ну и что, мало ли сколько игрушечных лиспов было сделано? Это никак не характеризует другие языки имеющие в качестве базового подмножества Scheme. Можно рассуждать о архетиктуре языка (тогда не говорим о библиотеках, коммунити, юзабилити и т.д.), можно говорить о практическом применении (тут смотрим в сторону самого активного проекта, вот Racket - чем плох?).

Метаклассы, метаобъекты слотов, обобщенная функция change-class(меняет класс объекта), классы funcallable-standard-class и его инстанс, класс funcallable-standard-object(его объекты можно использовать как функции).

И да, там тоже многоступенчатая инициализация объектов? (make-instance вызывает allocate-instance, а потом initialize-instance, а та вызывает shared-initialize)

как сравнивать попозже придумаю

> Метаклассы, метаобъекты слотов, обобщенная функция change-class(меняет класс объекта), классы funcallable-standard-class и его инстанс, класс funcallable-standard-object(его объекты можно использовать как функции).

И да, там тоже многоступенчатая инициализация объектов? (make-instance вызывает allocate-instance, а потом initialize-instance, а та вызывает shared-initialize)

все есть. единственное насчет funcallable-* сомневаюсь, ибо не нужно оно в Схеме

Вопрос где кончается язык и начинаются библиотеки - очень тонкий, особенно в лиспе.

Не понял, по моему тут всё понятно, и никакие лиспы ни при чём. Можно исходить из «расширяемой расширяемости», когда каждый новый макрос будет таким дополнением языка. А можно исходить из концепции фиксированных наборов базовых специальных форм на каждом уровне абстракций. Иначе - в самом CL, как в языке, что-то вроде 25 примитивов, сколько-то стандартных макросов и over 1000 функций. Это язык и нужно подумать прежде чем вводить что-то новое наряду рядом с базовыми средствами - а лучшее вообще очертить новую (не охваченную базовым CL) область и все вводимые макросы понимать как специальные формы этой области - например, системы ASDF, средства CFFI или какие-нибудь консистентные АТД. В этом случае есть один язык (CL), его библиотеки и библиотеки которые вводят свои языки с набором примитивов, которые не мешаются с примитивами CL.

ИМХО есть стандарт, все что в него включается есть базис, который должен быть доступен везде и от которого можно плясать не опасаясь, что где-то программа не заработает.

Это правильно, но и в Scheme и в CL стандарт - не базис от которого можно сплясать что угодно. Да, CL более полный в этом смысле. Но, к примеру, нужны мне сокеты - я могу взять полу-обвёрточную usocket которая будет работать «везде», но (ИМХО) придётся терпеть её API, а могу взять прямой IOLib, но на оно винде работать не будет - и накаких стандартов тут.

Кстати, вот ссылка на устройство диспетчера в PCL (реализация CLOS в CMUCL/SBCL) - Efficient Method Dispatch in PCL.

>но на оно винде работать не будет - и накаких стандартов тут.
Скоро будет doors.sockets
Следить за подробностями тут:
http://github.com/Lovesan/doors