Common Lisp V.S. Scheme

Вы совершенно не умете вести дискуссию. Посмотрите какие аргументы за CL привёл я, и какие за ским привели вы:

За Common Lisp:
* Инновации (залог процветания вашего бизнеса)
* Мощные возможности (сможете решить любую проблему)
* Высоколобое сообществу (все ваши сотрудники будут очень умными)
* Конкурентные преимущества (конкуренты будут повержены)
* Лучший выбор профессионалов (что подтверждает выше сказанное)

За Scheme
* Какой-то R5RS (который даже студентам не преподают)
* недо-макросы
* недо-CLOS
* недо-loop

Понимаете разницу? Ваш Scheme какой-то детсад, не способный бросить даже лёгкую тень на величие CL. Возможно его стоит использовать для обучения программированию детей младшего школьного возраста, но не более того.

Слив засчитан.

Быстро сдаётесь, это совсем не задорно.

> Понимаете разницу? Ваш Scheme какой-то детсад, не способный бросить даже лёгкую тень на величие CL. Возможно его стоит использовать для обучения программированию детей младшего школьного возраста, но не более того.

Brilliant!

http://en.wikipedia.org/wiki/Ignoratio_elenchi

Какой-то R5RS

А R(6)RS? А SRFI? В последнем есть вещи которых до сих пор нет в библиотеках CL общего назначения - момент который ещё нужно восполнить, очевидно.

недо-макросы

Я бы сказал, что они там просто другие, в чём-то даже более «крутые».

недо-CLOS

Ну и пусть :) Настоящие схемеры вольны выбирать ООП фреймворк под задачу - благ их у них несколько штук. Да и вообще, «замыкания и состояния» заруливают любое ООП, если верить SICP (но сливают в эффективности).

недо-loop

Вот и пусть :) В самом CL можно без loop обойтись - есть map*/filter/reduce, let+dolist, the ultimate collect macro, iterate в конце концов.

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

А в первом есть call/cc :)

Не, у тебе получается только флеймить, но никак не троллить.

Флейм? Троллинг? А это что за звери? По моему я в контексте темы топика высказываюсь :) Или нет? Wikipedia sayz что эти две вещи - почти одно и то же.

Ну так про что эта песн^W этот тред?)

>> недо-CLOS

Ну и пусть :) Настоящие схемеры вольны выбирать ООП фреймворк под задачу - благ их у них несколько штук

Ты сам-то пробовал эти штуки? Сплошные недоделки и произведения в стиле proof of concept. Даже в этом вашем tiny-clos опечатка, в результате которой нативные типы не считаются за классы, да и вообще без адаптации под конкретную реализацию не работает. Да и вообще, в большинстве реализаций запилены собственные, ни с чем больше не совместимые ООП фреймворки.

Вобщем-то, в мире scheme стандарт скоро перестанет играть какую-то особую роль и фактическим стандартом станет одна из реализаций (ну ты понел).

Ты сам-то пробовал эти штуки?

Я помимо SICP, 6-ого рапорта и сам знаешь какой реализации ничего там не пробовал (разве что по мелочи), просто часто замечал как схемеры хвастаются наличием нескольких ООП реализаций (это было что-то вроде кивка в сторону).

Даже в этом вашем tiny-clos опечатка, в результате которой нативные типы не считаются за классы, да и вообще без адаптации под конкретную реализацию не работает.

Ничего себе «опечатка». Разве в CL не так же? В CL эти самые «опечатки» по отображению типов в классы занимают несколько тысяч строк кода, если что, и при этом полностью отображение не реализуется (filtred functions из closer-mop - уже дальнейшее движение в эту сторону).

>и при этом полностью отображение не реализуется
А вот это поподробнее. В каком месте не классы? Ну да, от них наследоваться нельзя, но это другой вопрос. Диспатч на них работает.

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

Только для примитивных (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 позволяют такое использование.

> Ничего себе «опечатка». Разве в 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.

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

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

> Так и запишем - собственно 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

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

ну... спасибо... но я не просил ее вроде

Я про IOLib, который уже работает везде (POSIX потому что), кроме винды.

Скоро будет doors.sockets

Но всё равно, спасибо - посмотрю. Кстати, может вам тогда посмотреть на сокеты в iolib.soсkets? Конечно они поверх POSIX сокетов, и в win32 там всё совсем иначе, но мне сам API именно в IOLib понравилось.

А как же ответить ссылкой на годную технологию которая используется в альтернативных ООП от Scheme? :) А то сравнивать собрались.

> А как же ответить ссылкой на годную технологию которая используется в альтернативных ООП от Scheme?

не знаю насчёт технологий, но я уже не раз упоминал здесь название реализации CLOS-подобной объектной системы для PLT, ну и конечно же в доках к PLT она указана.

http://barzilay.org/Swindle/

А то сравнивать собрались.

ну я думал Love5fan какой-нибудь тест придумает

>Кстати, может вам тогда посмотреть на сокеты в iolib.soсkets? Конечно они поверх POSIX сокетов, и в win32 там всё совсем иначе, но мне сам API именно в IOLib понравилось.

Ну, doors.sockets будет просто оберткой над winsock2 api, т.е. вещью довольно низкоуровневой(хотя и lisper-friendly - вместо перечислений - списки кейвордов, к примеру, вместо указателей на агрегированные типы данных в функции будут передаваться сами лисповские данные(структуры, массивы), а не указатели на сырую память, вместо кодов возврата будут выкидываться соответствующие исключения etc.), без какой-то особой лисповской надстройки(классы там, etc.).

Что интересно:

CLOS - Copyright (c) 1985-1990 Xerox Corporation. All rights reserved.

Tiny-CLOS - Copyright (c) 1992 Xerox Corporation. All Rights Reserved.

что интересно?

что интересно?

Люди из Xerox сначала сделали реализацию CLOS которая попала в CMUCL и SBCL. Они же сделали Tiny-CLOS чуть позже, которая была основой для Swindle. Так что я думаю Tiny-CLOS должна использовать те же технологии что и CLOS. Правда, код PCL из SBCL за 20 гораздо больше точился, чем Tiny-CLOS, но это уже не принципиальное различие.

ну не совсем, потому и tiny. но в swindle автор уже сделал достаточно близко к CLOS, плюс ещё кучу вспомогательных и просто удобных чтук накрутил, правда я их не смотрел =)

Ладно, давайте я перефразирую свою мысль. Программу на С (без выкрутасов а ля gcc) можно скомпилировать компилятором C++. Значит ли это что C и C++ - один и тот же язык?

С - язык с real-world стандартом (имеется в виду, что стандартизировано не только абстрактное ядро языка, если приплести POSIX и libc).

C++ - другой язык, с другим, тоже real-world, стандартом.

А вот и Scheme и CL - языки со стандартами только на абстрактные подмножества этих языков. Все real-world вещи не стандартизированы и существуют только в реализациях. Так что Racket это Scheme по стандарту и что-то ещё просто так. Нет никакого CL++ или Scheme++ в которых бы стандартизировалось (как в C++) что-то ещё - эти «что-то ещё» есть, но в виде библиотек, т.е. нет *разных* языков.

Я понимаю вашу мысль - мол, стандарт Scheme столь лаконичен, что ничего толком написать реального не получится. Но это «шашечки», что мешает взять Racket - это ж Scheme, по стандарту :) Но то же самое и с CL (man linuxfan — «потоков нет, повсюду FFI, и т.д.»), но опять же, «шашечки», - берём LispWorks/SBCL + юзаем «стек» обвёрток.

Я просто хочу сказать, что в нынешней ситуации что для CL, что для Scheme нужно не о стандартах думать, а брать самое мощное существующее решение и его использовать (т.е. ориентироваться на самую лучшую реализацию, если такая есть (Racket?), или на те три-четыре лучших, что есть (SBCL, ECL, ABCL, не считая коммерческих). При этом о всех остальных реализациях, как это ни печально, нужно, наверное, забывать.

> Racket это Scheme по стандарту и что-то ещё просто так. Нет никакого CL++ или Scheme++ в которых бы стандартизировалось (как в C++) что-то ещё - эти «что-то ещё» есть, но в виде библиотек, т.е. нет *разных* языков.

В том то и дело что не в виде библиотек, а встроено, прикручено и приварено намертво. В рэкете есть встроенная система ООП, есть встроенное декларирование типов и еще куча всего. Именно scheme++.

Ну ладно, пусть Racket будет таким Scheme++. Дело не в названиях - в отличии от C/C++ где есть выбор (и даже холивар) что взять, тут выбора нет - сферический Scheme не получится взять (разве что для целей обучения - SICP, там, или HTDP (который вообще что-то вроде титуриала к PLT, теперь - Racket)), можно брать (для программирования, как такового) только Racket.