LINUX.ORG.RU

Какую LISP среду выбрать?


0

0

Собрался изучать LISP. В debian есть как минимум cmucl, sbcl, clisp кажись.

Один нужен для, собственно, изучения, а один для встраивания ,например, в проги на C/C++.

Большое спасибо.

★★★

Забыл вопрос :]. Какой посоветуете?

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

Для встраивания лучше guile, а для изучения - DrScheme. Правда, это Scheme, а не CL, но это и к лучшему. :)

ero-sennin ★★
()

>Один нужен для, собственно, изучения, а один для встраивания ,например, в проги на C/C++.

Для встраивания есть ECL, но он еще не соответсвуют стандарту ANSI. Есть недоделки. Но в процесс идет.

http://ecls.sourceforge.net/

Встраивание -- вещь вообще такая. Можно же и не встраивать, а использовать IPC. Если "встраивание" в смысле "скриптование"/extension language, то лучше тогда действительно guile либо какой-нибудь librep. Это больше Схемы.

http://www.gnu.org/software/guile/guile.html

http://librep.sourceforge.net/

Zubok ★★★★★
()

Ещё можно поглядеть на www.intelib.org, в плане встраивания лиспа в С++. 
Вот например:

 //       File isomorph.cpp
 #include "lisp/lisp.hpp"
 #include "lisp/lsymbol.hpp"
 #include "lfun_std.hpp"

 LSymbol ISOMORPHIC("ISOMORPHIC");

 static LFunctionalSymbol<LFunctionDefun> DEFUN("DEFUN");
 static LFunctionalSymbol<LFunctionCond> COND("COND");
 static LFunctionalSymbol<LFunctionAtom> ATOM("ATOM");
 static LFunctionalSymbol<LFunctionAnd> AND("AND");
 static LFunctionalSymbol<LFunctionCar> CAR("CAR");
 static LFunctionalSymbol<LFunctionCdr> CDR("CDR");

 LListConstructor L;

 void LispInit_isomorphic() {
   static LSymbol TREE1("TREE1");
   static LSymbol TREE2("TREE2");
   ////////////////////////////////////////////////
   //
   (L|DEFUN, ISOMORPHIC, (L|TREE1, TREE2),
     (L|COND, 
       (L|(L|ATOM, TREE1), (L|ATOM, TREE2)),
       (L|(L|ATOM, TREE2), NIL),
       (L|T, (L|AND,
         (L|ISOMORPHIC, (L|CAR, TREE1), 
                        (L|CAR, TREE2)),
         (L|ISOMORPHIC, (L|CDR, TREE1), 
                        (L|CDR, TREE2))
   )))).Evaluate();
   //
   ////////////////////////////////////////////////
 } 
 //      end of file
Well, this code is a complete C++ module and it does compile pretty well.

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

>А CMUCL не катит чтоли? Что-то все SBCL советуют. Может и мне перейти ?

Нет, ну почему не катит? Катит. Я не могу оценить глобально, как идет его развитие, но он старше того же SBCL, который и вырос из CMUCL, как форк. CMUCL гораздо труднее портируется на другие платформы, чем SBCL, о чем сказано в FAQ. SBCL активнее развивается. Большинство программистов начинают писать и тестировать свои библиотеки и программы раньше на SBCL, чем на CMUCL. Но из-за близкой связи этих реализаций проблем больших нет. По моим наблюдениям, в c.l.l и др. ресурсах, пользователей SBCL гораздо больше. Но все-равно я пока не вижу большой необходимости скакать туда-сюда.

Кстати, я тут кое-какие свои предварительные небольшие наработки хотел на нескольких лиспах проверить, так у меня CMUCL в debian грязно выругался при установке. В чем причина -- не знаю. Но он даже работать не захотел. Скорее всего, мэйтейнеры что-то накосячили. Разбираться пока не стал. Как-нибудь позже. Не горит. Рабочие лошадки мои сейчас -- это SBCL и CLISP. Последний весьма привлекателен для пользователей очень старых машин. CLISP может работать при весьма малой памяти. Если нет жесткой числодробильни, то CLISP очень неплохой выбор. И размер памяти потребляемой можно ограничить.

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

А не подскажите ли биндинг QT какой-нить попроще в установке, а то что-то lisp-cffi-qt... ниасилил (не хочет компилится). Что-нить простое, типа lambda-gtk (вроде пошло).

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

> Если нет жесткой числодробильни, то CLISP очень неплохой выбор.

...если только не понимать под "числодробильней" большие целые числа, на которых таки clisp уделывает sbcl/cmucl. И ещё clisp более "вылизан" в пределах той функциональности, которую он предоставляет (имхо).

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

> А не подскажите ли биндинг QT какой-нить попроще в установке, а то что-то lisp-cffi-qt... ниасилил (не хочет компилится). Что-нить простое, типа lambda-gtk (вроде пошло).

Если на cliki и иже с ним ничего не нашёл - боюсь и нет. В чистом виде (как ffi-обвязка) это получится монстр ещё тот. Или, как тут предлагали - через IDL (напиши, если последнее получится) :)

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

>А не подскажите ли биндинг QT какой-нить попроще в установке, а то что-то lisp-cffi-qt... ниасилил (не хочет компилится). Что-нить простое, типа lambda-gtk (вроде пошло).

Боюсь, что кроме этого ничего нет. Во всяком случае, я не натыкался. Си++ вообще очень недружественный язык для биндингов. Тут он по всем параметрам проигрывает GTK да и остальным чисто сишным библиотекам. Еще lisp-cffi-qt требует сборки какой-то какой-то связующей библиотеки на C++ libgui.so, чтобы хоть как-то прилинковаться к Qt. Если пробуешь в CMUCL, то есть вероятность, что не получится, так как в README написано, что:

Requires Lisp + CFFI and Qt4 / currently FreeBSD, Linux, Windows

Tested with CFFI version "cffi-060626.tar.gz" (included, see "examples/cffi/") and

- CLISP 2.38

- SBCL 0.9.12 (CFFI note: some platforms don't currently support callbacks)

- ECL 0.9i (Not tested with other Lisps or on Mac OS X.)

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

Zubok ★★★★★
()

Хозяйке на заметку. В SBCL 0.9.17 появился режим интерпретации. То есть можно отключить компилятор, и исходный текст будет интерпретироваться. Наверное, это удобно, когда в программе на CL требуется какой-то скрипт на этом же CL, но только без компиляции. Сам я не пробовал, так как 0.9.16 еще стоит. Вот из мануала:

http://www.sbcl.org/manual/Interpreter.html#Interpreter

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