LINUX.ORG.RU
Ответ на: комментарий от quasimoto

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

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

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

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

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

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

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

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

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

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

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

http://barzilay.org/Swindle/

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

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

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

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

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

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

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

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

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

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

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

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

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

С - язык с 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, не считая коммерческих). При этом о всех остальных реализациях, как это ни печально, нужно, наверное, забывать.

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

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

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

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

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

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