Сколько человек готовы программировать на LISP в Колибри?

Find out what others think about your ideas

POLL Стали бы вы программировать на LISP в Колибри?

Total votes: 36
Да
47%
17
Нет
53%
19

  • Рекомендую добавить ответ типа "пока не знаю" или "затрудняюсь ответить". Я например лично пока не уверен, но и отказываться глупо.
  • I myself would not use it, but dont let that stop you.
    "Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius -- and a lot of courage -- to move in the opposite direction." Albert Einstein
  • У меня есть желание поэксперементировать с реализацией scheme-диалекта под колибри, может быть найду время.
    Не думаю, что портирование хорошей реализации lisp (scheme), например gambit имеет смысл. Скорее всего потенциальных лисп-программистов под Колибри просто нет.
    С другой стороны, миниатюрный интерпретатор с обертками для графических функций (gui), имхо мог бы быть полезен.
    XVilka wrote:Интересуюсь, потому что сейчас учу лисп - а там всегда практика есть на реализации лиспа на нем самом Собственно заготовка уже есть (на С), но если будет много желающих - не проблема быстро переписать на ассемблер.
    Прикрепил к сообщению одну "заготовку" -- примитивный лисп-интерпретатор, найденный на просторах интернета. Построен по принципу передачи окружения. Не имеет сборки мусора. (Про оптимизацию хвостовых вызовов не помню, наверное тоже нет.) Беда в том, что сборщик мусора в него добавить практически невозможно, т.к интерпретатор использует стек (рекурсия в сишных eval-apply). И скорректировать ссылки на лисп-объекты в стеке уже не так просто, как в окружении (top_env). Подразумевается сборка мусора простейшим методом остановки с копированием.

    P.S Не голосовал.
    Attachments
    lisp.c (13.25 KiB)
    lisp interpreter ;)
    Downloaded 421 times
  • Короче решил делать - но только не интерпретатор, а компилятор - больше соответсвует духу колибри. По поводу оберток для графических функций - посоветуйте к каким конкретно надо.

    решил отталкиваться от 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) тоже интересные разработки с большими примерами.
    По возможности, есть желание поучавствовать в развитии колибри:)
  • Who is online

    Users browsing this forum: No registered users and 6 guests