clisp & c

>1. Как много моральных издержек надо пережить, чтобы скомпилировать >программу на лисп, так чтобы получился исполнимый файл. Какая из >свободных реализаций больше подходит для этого (gcl, clisp или какая >еще)?

Моральных издержек никаких, но из свободных реализаций только gcl и ecls позволяют создавать именно, что standalone executable. clisp вообще пока не имеет нативного компилятора (только байт-код). cmucl и sbcl генерят нативный код, но чтобы его выполнить необходим полный run-time (порядка 20M).

В любом случае gcl лучше пока не пользоваться -- он из всех реализаций наименее стандартный, даже если его собирать в ANSI-режиме

>2. Можно ли (а лучше так: у кого есть какой опыт) вызова лисп функций >из С. Возможно даже из C++. Есть ли опыт вызовов наоборот? Какие >впечатления?

C вызовом С-функций из Lispа в общем никаких проблем нет -- это поддерживается всеми реализациями и более-менее похожим образом (есть даже специальный пакет оберток, называется UFFI). Вызов Lisp'а из С -- это существенно больший геморрой, некоторые реализации (напр., sbcl) вообще этого не поддерживают вменяемым образом. Но если привязываться к конкретной реализации, то тоже особых проблем нет. Хотя, разумеется, бывают сложные случаи. Вообще мое субъективное мнение таково, что лучше call-backов не делать

>3. Я пробовал вызывать из лиспа Tk окошки. Это вполне реально и >довольно легко. Но можно ли это сделать исполнимым файлом, а не >работать через интерпретатор (реально использовался gcl)?

я не совсем понимаю, что имеется в виду

>4. Если все вышеперечисленное скорее да, чем нет ;), то можно ли >перенести код потом под Windows?

можно

>Очень нужны общие рекомендации: как лучше компилировать, связывать.

А что, существует несколько способов компиляции?

>Какой стиль программирования более приемлем для лисп (функциональный >или, например, объектный). Любые комментарии будут очень востребованы.

для лиспа приемлемы все стили -- это одна из особенностей данного языка. Кроме того, объектная и функциональная парадигмы --- друг другу не противоречат (в некотором смысле, ООП -- это частный случай функционального программирования)

>Нужна помощь в выборе документации тоже, впрочем у меня много книг, >которые выглядят вполне приличными, главное не описание языка, а чисто >технические и общенаправленческие рекомендации.

Если нужны "общенаправленческие рекомендации" можно посоветовать финскую книжку "Мир Лиспа" -- 2 тома, у нас издавал "Мир" около 1990 г. Также книжка Пола Грехема On Lisp (можно взять из сети). А также www.lisp.org и www.cliki.net

>>3. Я пробовал вызывать из лиспа Tk окошки. Это вполне реально и >довольно легко. Но можно ли это сделать исполнимым файлом, а не >работать через интерпретатор (реально использовался gcl)?

>я не совсем понимаю, что имеется в виду

Задача стоит следующая. Требуется написать некое приложение с графическим интерфейсом. Есть ядро на лисп. Надо написать фронтенд. Есть ли возможность написать этот фронтенд на лисп, на С, на Тк? И так далее

>>4. Если все вышеперечисленное скорее да, чем нет ;), то можно ли >перенести код потом под Windows?

>можно

Не могли бы вы написать чуть более конкретно. Существуют компиляторы лисп под винды?

>>Очень нужны общие рекомендации: как лучше компилировать, связывать.

>А что, существует несколько способов компиляции?

Я получал объектные файлы из лисп программы, но сделать выполнимый файл я не смог. Подскажите как это сделать с какой нибудь реализацией лиспа.

>для лиспа приемлемы все стили -- это одна из особенностей данного языка. Кроме того, объектная и функциональная парадигмы --- друг другу не противоречат (в некотором смысле, ООП -- это частный случай функционального программирования)

Мне так не кажется (что ООП - это частный случай функционального), скорее ООП - это обобщенный модульный (если иметь в виду встраивание методов в сами классы объектов). С другой стороны, шаблоны и перегрузка, видимо имеет какое-то отношение... Но все же... Функциональное программирование, насколько я понимаю, дает чуть ли не гарантию правильной работы программы. Объектный подход - это о другом. Это о биологическом представлении задачи на взаимодействующие, но независимые объекты.

В любом случае поясните что вы имеете в виду. Так как вообще говоря, можно найти еще общее между классификацией и функциональным программированием.

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

Спасибо за книжки.

> 1. Как много моральных издержек надо пережить, чтобы скомпилировать программу на лисп, так чтобы получился исполнимый файл. Какая из свободных реализаций больше подходит для этого (gcl, clisp или какая еще)?

вообще никакого гимороя, в linux есть такая вещь как binfmt_misc, с помощью ее можно сделать скомпилиравонный lisp запускаемым.

> 2. Можно ли (а лучше так: у кого есть какой опыт) вызова лисп функций из С. Возможно даже из C++. Есть ли опыт вызовов наоборот? Какие впечатления?

Практически у всех реализаций common lisp, есть поддержка FFI. Насколько мне известно самая лучшая у cmucl, никаких проблем с прямым и обратным вызовом (сам использую)

> 3. Я пробовал вызывать из лиспа Tk окошки. Это вполне реально и довольно легко. Но можно ли это сделать исполнимым файлом, а не работать через интерпретатор (реально использовался gcl)?

см 1

> 4. Если все вышеперечисленное скорее да, чем нет ;), то можно ли перенести код потом под Windows?

нормальных реализаций lisp под win нету ;)

> Очень нужны общие рекомендации: как лучше компилировать, связывать. Какой стиль программирования более приемлем для лисп (функциональный или, например, объектный). Любые комментарии будут очень востребованы. Нужна помощь в выборе документации тоже, впрочем у меня много книг, которые выглядят вполне приличными, главное не описание языка, а чисто технические и общенаправленческие рекомендации.

Попробуй и классический подход и использование CLOS как способ обьектизации

> И последний вопрос. У кого есть опыт перевода каких-либо программ с elisp на clisp?

лучше делать наоборот, писать на clisp и переносить на elisp, особенно когда есть такая офигенная вещь как http://www.emacswiki.org/cgi-bin/wiki/EmacsCommonLisp

>вообще никакого гимороя, в linux есть такая вещь как binfmt_misc

А можно конкретнее, а то я не знаю что это такое. Положим у меня есть программа на лисп, в которой пара функций и просто текст. Я ее компилирую с gcl и получаю .o файл. После этого он ничем и ни с чем не линкуется. Как быть?

>нормальных реализаций lisp под win нету ;)

А коммерческих тоже? Например, аллегро годится? Вопрос не праздный. Речь идет о полублаготворительной разработке нескольких головоломок-игрушек, я не хочу браться, если только не на лиспе (чтобы поизучать - хоть польза была бы). Но нужно, чтобы можно было потом сделать рабочий файл для винды. cygwin пойдет для демонстрации, но потом надо будет компилировать. В этом суть задачки (одной из).

> CLOS

Он действительно полезен? Это типа объектный подход? В чем его преимущества по сравнению с приплюснутыми сями?

Спасибо за очень полезный ответ. До завтра - ушел спать

>> вообще никакого гимороя, в linux есть такая вещь как binfmt_misc

> А можно конкретнее, а то я не знаю что это такое. Положим у меня есть программа на лисп, в которой пара функций и просто текст. Я ее компилирую с gcl и получаю .o файл. После этого он ничем и ни с чем не линкуется. Как быть?

я не знаю насчет gcl(я пользую cmucl). Общая логика такова что если у тебя есть бинарный файл с неким магиком в начале то ты это можещь зарегистрить в binfmt_misc чтобы при запуске выполнялся соотвествующий скрипт запуска. Таким обрзом можно сделать .exe фаилы (MZ) запускаемыми или скомпиленные lisp файлы запускаемыми (но при этом) все же будет нужен установленный интерпретатор таких файлов

> А коммерческих тоже? Например, аллегро годится? Вопрос не праздный. Речь идет о полублаготворительной разработке нескольких головоломок-игрушек, я не хочу браться, если только не на лиспе (чтобы поизучать - хоть польза была бы). Но нужно, чтобы можно было потом сделать рабочий файл для винды. cygwin пойдет для демонстрации, но потом надо будет компилировать. В этом суть задачки (одной из).

без понятия, помочь не смогу. Возможно можно просто каким нибудь образом законкатенировать lisp интерпретатор и скомпиленый(необязательно) образ программы(например как это сделано в Python) чтобы создать конечный запускаемый файл, который не требует наличия интерпретатора(так как он уже в самом файле).

>> CLOS

> Он действительно полезен? Это типа объектный подход? В чем его преимущества по сравнению с приплюснутыми сями?

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

Самая естественная для Лиспа парадигма программирования - это метапрограммирование. Или это лучше назвать метапарадигмой? ;)

а вы, часом, Lisp с рефалом не путаете, сударь, а?

Ни разу. defmacro - супермегарулез, однако. Всем читать Пола Грехема.

да кто ж спорит... defmacro --- оно и в Африке defmacro :)