LINUX.ORG.RU

Вышла новая версия ABCL 1.1.0 — реализации языка программирования Common Lisp

 , , , ,


1

6

Armed Bear Common Lisp (ABCL) — полная реализация стандарта языка программирования Common Lisp, включающая интерпретатор и компилятор, и работающая на JVM. Изначально будучи скриптовым языком расширения для текстового редактора J, реализация теперь поддерживает JSR-223 (API скриптовoго языкa расширения для Java): то есть может быть скриптовым движком в любом приложении, написанном на Java. Вдобавок можно использовать Java <--> Lisp API интеграции для реализации (отдельных частей) на Java или Lisp.

В этом долгожданном релизе (с 9 января 2012) исправлено множество ошибок и добавлены новые возможности:

  • Рабочая реализация (A)MOP (Metaobject Protocol) благодаря упорной работе Rudi Schlatte (@rudi).
  • Эта реализация теперь может работать на большем количестве Quicklisp-инсталляций благодаря обширному тестированию. Спасибо @xach!
    Все перечисленные ниже системы нуждаются в патчах, которые появятся в следующих релизах Quicklisp:
    • CLOSER-MOP — в связи с реализацией MOP в этом релизе, ведется работа по добавлению поддержки ABCL в closer-mop;
    • CFFI;
    • HUNCHENTOOT;
    • CXML.
  • Компилятор байткода Java 5. Внутренний Lisp-to-Java байткод компилятор покрыт большим количеством регрессионных тестов с использованием Quicklisp-библиотек.
  • Возможность создания классов в рантайме через JNEW-RUNTIME-CLASS (@astalla). Довольно близко к полному покрытию примитивов для создания synthethic Java-классов в рантайме. Легко расширяемая по вашим потребностям, с разумными опциями по умолчанию.
  • Обновлен ASDF до версии 2.26.6 с включенными патчами для расширений реализации в дополнении к ANSI: URL-PATHAME и JAR-PATHNAME.
  • ABCL-CONTRIB:
    • ABCL-ASDF — инсталляция по сети с использованием Maven;
    • JSS;
    • JFLI.

Поддерживаются следующие платформы: Windows, Linux, MacOS X, OpenBSD, NetBSD, FreeBSD, Solaris или Google App Engine.

Для клиентских установок необходимы следующие версии JRE:

  • JRE 1.5.0
  • JRE 1.6.0 (patch level 10 или выше)
  • JRE 1.7.0

Для разработки/компиляции необходимы следующие версии JDK и Ant:

  • JDK 1.5.0
  • JDK 1.6.0 (patch level 10 или выше)
  • JDK 1.7.0
  • Ant 1.7.1 или выше

Бинарную сборку в архиве можно загрузить по ссылкам:

Исходный код можно загрузить по ссылкам:

>>> Подробности

★★

Проверено: maxcom ()
Последнее исправление: Silent (всего исправлений: 2)

компилятор байткода Java 5

Довольно занятно.

Deleted
()

интерпритатор

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

вообще интересно будет глянуть abcl vs. clojure в сравнении: как покажут себя на одних и тех же наборах задач и жаба-библиотек
ну и о насущном — swank'а для него еще нет?

proofit404
()
Ответ на: комментарий от buddhist

Да это просто радость какая-то! Хвостовую рекурсию не запилили?

Ты наверное имеешь ввиду оптимизацию хвостовой рекурсии?

Deleted
()
Ответ на: комментарий от anonymous

Ты, наверное, не ведаешь, сколько языков пережил лисп, даже таких могучих как ПЛ/1 и алгол.

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

эти трупы вы будете созерцать время от времени на протяжении всей вашей короткой жизни.

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

И плакал я тихонечко И напивался в дым. Меня за за тягу к скобочкам Считали голубым.

=)

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

Употребление этого термина в другом контексте было бы бессмысленным :)

Употребление Лиспа вообще бессмысленно. И беспощадно не менее.

Vudod ★★★★★
()

то есть может быть скриптовым движком в любом приложении, написанном на Java

ужосс... Не хотел бы я поддерживать скриптовый код на Lisp. Есть же искоробочный JS, и гораздо более читабельные Beanshell,Groovy,Python. Scala вроде тоже может работать в режиме интерпретатора.

qwerky
()

Я понимаю, когда говорят C89 и C99. Я понимаю, когда говорят Python2 и Python3. Я еще многое могу понять и простить. Но когда говорят, что появился очередной диалект Лиспа... У меня в очередной раз отпадает желание хоть когда-нибудь чего-нибудь на нем написать.

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

Так новость не про очередной диалект, а про очередную реализацию.

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

Это не диалект, а все тот же стандартный Common Lisp, только на jvm платформе. Для тех, кто работал с sbcl, clisp, ecl, ccl, нет никакого труда использовать abcl.

anonymous
()
Ответ на: комментарий от qwerky

гораздо более читабельные Beanshell,Groovy,Python. Scala...

Первый не видел, но с остальными вы хорошо пошутили, да. Особенно со скалой.

naryl ★★★★★
()

OH NOES. Опять этот флуд?

А чо, давайте я буду новости про каждый новый релиз PGI FORTRAN писать. И про Интелевский тоже. И про PathScale с Ораклом до кучи.

Фортран и то живее скобчатого поноса будет. А, главное, значительно полезнее. Потому что на нем реальную математику считают, а на лиспе — одни динамические опердени и анафорические лямбды с фибоначчами.

anonymous
()
Ответ на: комментарий от naryl

Первый не видел, но с остальными вы хорошо пошутили, да. Особенно со скалой.

Что не так с читабельностью у Scala? Может, Вы просто не овладели языком? Дело в том, что освоение Scala требует определенных интеллектуальных усилий.

У профессионалов, освоивших язык на должном уровне, проблем с читаемостью не возникает.

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

на лиспе... фибоначчи

Лол, числа Фибоначчи на лиспе? Ты это всерьёз?

LISP:

(defparameter *fibs-2*
  (reclet 
      ((fibs (seq->stream
              (seq-cons
               1 (seq-cons
                  1 (seq-map
                     (lambda (x)
                       (+ (first x) (second x)))
                     (seq-zip
                      (delay-seq fibs)
                      (delay-seq (seq-cdr fibs)))))))))
    fibs))

Haskell:

fibs = 1 : 1 : zipWith (+) fibs (tail fibs)

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

Лол, числа Фибоначчи на лиспе? Ты это всерьёз?

А теперь попробуй рассчитать Фибоначчи в промышленных масштабах. Конкретно *это* решение на хаскеле слегка соснет.

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

рассчитать Фибоначчи в промышленных масштабах

Лол, так вот каково истинное предназначение лиспохаскелей.

anonymous
()
Ответ на: комментарий от void_ptr

Нет. Вы не совсем правы...

... Это не очередной диалект Lisp. Это просто версия этого... «бурно развивающегося» языка.

Впрочем, отчасти Вы правы. Если про другие языки можно сказать «смотрите, чего только не понаписано на языке *», то про Lisp можно точно сказать — «смотрите, на чем только не понаписан Lisp». )))

anonymous
()
Ответ на: комментарий от lazyklimm

А! Да не волнуйтесь...

... это в преддверии планируемого на 21.12 какого-то Конца Света некрофи... эээ... некроманты балуются. )))

anonymous
()
Ответ на: комментарий от naryl

Но-но-но...

... Милейший, я бы Вас попросил не сеять панику. Анонимусы на ЛОРе пока еще не являются вымирающим видом.

anonymous
()
Ответ на: комментарий от lazyklimm

то-то с лиспа уже 40 лет тягают идеи все кому не лень

Мейнстрим сразу же стырил хорошие вещи, а уже в 70х лишпы бесконечно отстали от полноценных ЯП, и всё, что делается на скобочном говне с того времени - это неудачные попытки стырить концепции из полноценных ЯП, оканчивающиеся многословными, глючными, неудобными, несовместимыми скобочными недо-dslчиками.

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

Третий вариант (оттуда, откуда ты взял) эффективнее хаскелевского.

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

Числа Фибиноччи - это всего лишь тест на то, правильно ли реализованы потоки и последовательности. За деревьями нужно уметь видеть лес. Или ты так для красного словца?

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

Только наркоман будет так реализовывать числа Фибоначчи на CL.

Правильно. Третий вариант (не приведенный здесь) через make-seq эффективнее хаскелевского (старые вычисленные значения тут же забываются) и много проще для восприятия (аналогия с составлением cons-ячеек).

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

Кстати, можно упростить (но все равно гораздо лучше делать через make-seq):

(defparameter *fibs-2*
  (reclet 
      ((fibs (seq->stream
              (seq-cons
               1 (seq-cons
                  1 (seq-map #'+    
                             (delay-seq fibs)
                             (delay-seq (seq-cdr fibs))))))))
    fibs))
dave ★★★★★
()
Ответ на: комментарий от anonymous

Вот, этот вариант эффективнее хаскелевского (если нужен именно ленивый поток, то добавь seq->stream перед make-seq), и он не такой мозгодробительный. Если разобраться, то все примитивно до невозможного:

(defparameter *fibs-3*
  (make-seq
   (labels ((traverse (a b)
              (enum-cons a (traverse b (+ a b)))))
     (traverse 1 1))))
dave ★★★★★
()
Ответ на: комментарий от lazyklimm

Боюсь...

... оттуда уже нечего таскать. Все уже утащено до нас.

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

В качестве квеста попробуйте написать на Scala или F# такое же решение через ленивый поток. Не думаю, что будет короче, чем на лиспе. А хаскель останется чемпионом по числам Фибоначчи - тут не спорю.

Теперь объясняю.

Тест на числа Фибоначчи показывает, что можно работать с ленивыми последовательностями и потоками. А это означает, что открывается возможность использовать эффективные алгоритмы по работе c (чаще всего, иммутабельными) структурами данных.

Например, один из самых эффективных способов сравнить на равенство два бинарных дерева - это создать две последовательности значений, и сравнить уже эти две последовательности. Тем самым, мы сводим более сложную начальную задачу к более простой.

Сравнивать деревья нужно, например, чтобы определить, а совпадают ли размерности моделируемых физических или экономических величин.

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

Тест на числа Фибоначчи показывает, что можно работать с ленивыми последовательностями и потоками. А это означает, что открывается возможность использовать эффективные алгоритмы по работе c (чаще всего, иммутабельными) структурами данных.

Но ведь иммутабельность не нужна. Это — своеобразный карго-культ в теоретическом программировании; божок, на которого молятся функциональщики.

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

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

а уже в 70х лишпы бесконечно отстали от полноценных ЯП

ты про ML?

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

Необоснованные утверждения и подмена понятий. От иммутабельности проку большого нет при программировании на Си или Си++, поскольку там нет автоматической сборки мусора (а та, что есть в виде библиотек, - медленная, некрасивая, неэффективная и т.п.). Тут могу согласиться, что иммутабельность не очень-то и нужна конкретно для этих языков, поскольку там она не дает бенефитов, а скорее, усложняет код.

Но уже на уровне C# (а я - профессиональный разработчик C#, т.е. получаю деньгу за свой труд) иммутабельность становится полезной, и я ее применяю в нашем проекте, также как и Linq (кстати, Linq и clojure были источниками вдохновения для generic sequences). В функциональных же языках иммутабельность - это просто кладезь хороших практичных решений, особенно если есть хороший REPL как в лиспе, когда можно проектировать снизу-вверх, сразу же тестируя код. Если программа не использует функциональный стиль, то тестировать будет тяжелее.

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

Наконец, иммутабельные объекты существую даже в Си. Например, это - обычные числа.

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