Рекомендую добавить ответ типа "пока не знаю" или "затрудняюсь ответить". Я например лично пока не уверен, но и отказываться глупо.

I myself would not use it, but dont let that stop you.

У меня есть желание поэксперементировать с реализацией scheme-диалекта под колибри, может быть найду время.
Не думаю, что портирование хорошей реализации lisp (scheme), например gambit имеет смысл. Скорее всего потенциальных лисп-программистов под Колибри просто нет.
С другой стороны, миниатюрный интерпретатор с обертками для графических функций (gui), имхо мог бы быть полезен.

XVilka wrote:Интересуюсь, потому что сейчас учу лисп - а там всегда практика есть на реализации лиспа на нем самом Собственно заготовка уже есть (на С), но если будет много желающих - не проблема быстро переписать на ассемблер.

Прикрепил к сообщению одну "заготовку" -- примитивный лисп-интерпретатор, найденный на просторах интернета. Построен по принципу передачи окружения. Не имеет сборки мусора. (Про оптимизацию хвостовых вызовов не помню, наверное тоже нет.) Беда в том, что сборщик мусора в него добавить практически невозможно, т.к интерпретатор использует стек (рекурсия в сишных eval-apply). И скорректировать ссылки на лисп-объекты в стеке уже не так просто, как в окружении (top_env). Подразумевается сборка мусора простейшим методом остановки с копированием.

P.S Не голосовал.

Короче решил делать - но только не интерпретатор, а компилятор - больше соответсвует духу колибри. По поводу оберток для графических функций - посоветуйте к каким конкретно надо.

решил отталкиваться от newlisp и dream

Ключевым доводом в сторону нужности послужило то, что много экспертных систем написано на лиспе или подобных языках - а для математических расчетов они бы пригодились - например ту же какую-нибудь легкую CAS можно портировать. Например yacas http://yacas.sourceforge.net/homepage.html

Компилятор от интерпретатора в случае Лисп мало чем отличается по своей сути. Причина в том, что язык поддерживает лексическое замыкание и и окружение представляет собой уже не дерево, а граф. Т.е как си его не скомпилируешь. Плюс сборка мусора. В результате в обоих случаях мы получаем одинаковую библиотеку времени выполнения. И интерпретатор и компилятор могут проводить предобработку исходного текста ради оптимизации. Но это все так, к слову.

Просто я скептически отношусь к идее реализации лисп ради переноса в Колибри каких-нибудь лисп-проектов. В этом случае придется реализовать поддержку стандарта common lisp или scheme; короче говоря, куча мелочей, рутина, и кому это вообще нужно?

Вот пример пример другого подхода. Это интерпретатор лисп под Palm OS. Благодаря встроенным функциям работы с файлами ("Virtual File System support"), gui и др. общаться с ситемой очень просто. (Про файлы. Можно сказать, что в Palm данные хранятся в базе данных и ассоцированны с конкретными приложениями, но в lispme можно работать, например, с вашими заметками или todo просто как с текстовыми файлами). Только программировать непосредственно под палмом неудобно, но вот Колибри этого недостатка лишена. Думаю, что создавать gui-приложения на лиспе могло бы быть значительно проще и быстрее, что немаловажно для just-for-fun проекта.

В этом случае я бы попрограммировал на лисп в Колибри)

ну, я портирую как раз реализацию R5RS стандарта. Следующим этапом можно будет сделать расширение Scheme в LISP

Больше половины реализаций лиспа и схемы компилируют, причем достаточно эффективно - так что компиляция мало чем отличается от других языков - даже легче, в силу легкости синтаксиса.

XVilka wrote:ну, я портирую как раз реализацию R5RS стандарта.

Ага, просто мне показалось по первому соообщению, что у вас есть интерес к самостоятельной реализации:

XVilka wrote:Интересуюсь, потому что сейчас учу лисп - а там всегда практика есть на реализации лиспа на нем самом

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

Да, у меня интерес к самостоятельной реализации - Я делаю ее по книгам "Scheme from Scratch - Bootstraping" и "Lisp in small pieces"

Но вот смотреть в чужой код приходиться - чтобы разобраться что и как.

У меня интерес прежде всего к реализации - и прежде всего к портирования CAS - у меня был опыт портирования Yacas на мобильные платформы. А почему математика - потому что есть легкое железо, на котором серьезная система не пойдет - а колибри будет летать.

Сейчас занимаюсь I/O для компилятора - возник вопрос, каким образом лучше ( и проще ) организовать взаимодействие с компилятором? То бишь как его лучше запускать/вызывать?

Я думаю для начала достаточно запуска с параметрами, а собщения об ошибках пусть выводятся на доску отладки.
Кстати, ведь ошибки времени компиляции для scheme - это практически только лексические ошибки + непарные скобки . Остальные ошибки обнаруживаются во время запуска, и тогда вопрос, как жить без REPL?

С REPL имхо не просто, если будет поддержка GUI-функций. Ведь процесс может иметь только одно окно (если не ошибаюсь).
С другой стороны, если будет поддержка исключений, то можно обойтись без него.

интерпретатор тоже будет - просто мне надо же сначала его самого им самим под колибри собрать.

То есть таким способом - я его собираю для линукса с помощью guile
Потом скомпилированным начинаю пытаться собрать его же самого
Если все нормально - собрать его же самого только уже под колибри.

Почти допилил. Только застрял на способе загрузки библиотек и функций в них.

Много экпериментировал, пробовал портировать newLISP, много раз пробовал реализацию на racket, и понял что все слишком громоздко, не вписывается в концепцию Колибри, и опять вернулся к "dream" http://hg.droid-developers.org/kolibri-scheme/overview Пока не успел API доработать, времени мало, но раз уж заставил себя на репу залить - буду потихоньку допиливать.

Обратите внимание на язык Factor из серии цепочечных языков и вобрал в себя разные возможности.
http://factorcode.org/ спроектирован и с использованием и Лисп подхода,
проект довольно интересный и возможно лучший кандидат для включения в колибри?
языка с Лисп подходом.
http://ru.wikipedia.org/wiki/Factor_(яз ... мирования)
Краткая характеристика из википедии.

P.S. Лисп не практиковал, хотя некоторое понимание его принципов и устройства есть.
Сам сторонник Форт (Forth) языка и подключения кода, например OpenFirmware к ядру.
Factor язык, также имеет и элементы Форт языка.
Форт системы на Fasm ( revaForth, retroForth) тоже интересные разработки с большими примерами.
По возможности, есть желание поучавствовать в развитии колибри:)