LINUX.ORG.RU

Новая стандартная библиотека для CL - CLR

 ,


1

11

Привет.

Как известно, текущая стандартная библиотека Common Lisp устарела, много необходимого в ней просто нет, реализации предоставляют разрозненные наборы фич, а в репозиториях куча полуподдерживаемых библиотек.

Поэтому я тут решил потихоньку пилить новую стандартную библиотеку для CL. По образу и подобию недавно заопенсорсенного .NET Base Class Library.

https://github.com/Lovesan/CLR

Код либо адаптируется из существующих библиотек - благо лицензии в основном позволяют, либо переписывается на CL из библиотек других языков.

Важный момент - это не синтаксический сахар и не простое распихивание символов по модулям, как в том же cl21, это именно стандартная библиотека.

Сейчас у меня там совсем небольшое количество кода, и в качестве бэкенда пока только SBCL и винда, но вот неполный список планирующихся фич:

  • Унифицированные *features*
  • Разнообразные распространенные утилиты, вроде with-gensyms итд
  • Унифицированный интерфейс MOP
  • Треды, примитивы синхронизации, атомарные операции, тред пулы, таски/фьючи
  • Асинхронное высокопроизводительное IO, включая работу с сетью
  • Легковесный FFI
  • Различные коллекции, в том числе lock-free. Унифицированный интерфейс коллекций.
  • Кодировки, регулярные выражения, i18n, L10n
  • Работа с датой и временем
  • Унифицированные механизмы сериализации
  • Работа с XML и JSON
  • Работа со сжатием данных
  • Стандартная система логирования
  • Для винды - интеграция с COM по подобию .NET, работа с виндовыми сервисами

Также, в качестве отдельных модулей/asdf-систем:

  • Унифицированная работа с базами данных по примеру JDBC и сотоварищей
  • Работа с безопасностью и криптографией
  • Фреймворк для тестирования кода
  • итд

Пилю пока один, но community effort был бы очень к месту. Желающие - присоединяйтесь.

★★

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

Ты неправ. Хорошо, что пилит - иначе бы клей нюхал и лампочки бы бил в подъездах. Когда от такого, как ТС, нет вреда - то это уже само по себе польза.

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

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

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

Конкретно щас много дел, эта неделя забита, но хоть что-то постараюсь закоммитить скоро.

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

Внезапно, на хорошо распараллеливаемом бенчмарке, однопоточная программа на SBCL рвет чуть ли не в два раза распараллеленную на 4 ядра на Clojure.

У тебя пиздоглазие? clojure - 14 секунд, sbcl - 24. И, кстати, это плохо распараллеливаемая задача, т.к. тестирует гц.

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

Хорошо, что пилит

так он как раз не пилит

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

Common Lisp, Emacs Lisp, PicoLisp — настоящие лиспы.

Scheme, Racket — недолиспы.

NewLisp, Clojure — нелиспы (только скобчатый синтаксис).

интересно твоё мнение насчёт ISO ISLISP, EuLisp (сабж), T, и рефлективных: 3Lisp, Kernel (ну и до кучи Shen, оно кстати живое ли?)

Racket, кстати, почему недолисп?

PicoLisp вроде бы похож на недолисп, но он минималистично полный, и батареек в комплекте достаточно. так что да, Ъ.

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

и? как это отменяет твое пиздоглазие?

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

Clojure:
Медленная

Скорость сравнима с Java.

На JVM, в которой нет даже поддержки tailcall(какой вообще может быть функциональный язык без TCO?)

Претензии к платформе, а не языку.

Для нее нет ни нормального REPL, ни IDE - ничего сравнимого со SLIME, в силу особенностей ее архитектуры, и в частности, из-за JVM

Чего нет в cider, что есть в slime?

STM ни к селу ни к городу, батя грит плохо зделоли, лучше бы зделоли как в Scala(это же касается иммутабельности кстати)

Можешь подробнее?

Объектная система, включая мультиметоды - убога и ограничена, опять же, JVM

Объектная система здесь вообще вторична в классическом понимании этого термина, т.к. неизменяемость и все дела, совершенно другой концепт.

Нет Condition System

Опять претензии к jvm.

Нет reader-макросов

Сделано специально для унификации и бесшовной интеграции кода сторонних библиотек.

и других мощных фич CL, вроде динамических переменных

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

Опять же, из-за JVM, у нее можно считать отсутствует вменяемый FFI

Зато есть интероперабетльность с Java, а у CL она есть?

Всякие несуразности типа nil не list итд

Нету там несуразностей.

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

Как бы наоборот, намного более логично и менее многословно - сразу видно, что является формой, а что нет. Удобно для зрительного восприятия. Скобки только у самых базовых (обыденных) структур. Можешь писать без [ и { в стиле CL, если нравится. Но так никто не делает, потому что многословно.

В коммьюнити куча немытых необразованных хипстеров которые изобретают кривые велосипеды с квадратными колесами.

В коммунити CL например жизни вообще нет. Что из этого лучше? :)

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

претензии к jvm.

вообще охереть. А что, clojure где-то ещё нормально работает?
похер к кому притензии, если на это натыкаешься в кложуре — это её проблемы

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

Я видел и SLIME, и CIDER, если что. И CIDER и близко по фичастости со SLIME не валялся

Нужны подробности, если речь не о рестартах итд

особенно в области горячей замены кода и файлов-как-repl

А здесь-то что не так?

Про «упор на многопоточку» итд - вот, смешное: http://benchmarksgame.alioth.debian.org/u64q/performance.php?test=binarytrees...
Внезапно, на хорошо распараллеливаемом бенчмарке, однопоточная программа на SBCL рвет чуть ли не в два раза распараллеленную на 4 ядра на Clojure.

http://benchmarksgame.alioth.debian.org/u64q/performance.php?test=binarytrees... - ни одна версия на CL не обгоняет ни одну из трех версий на Clojure.

Мы видим что-то разное по одной и той же ссылке?

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

вообще охереть. А что, clojure где-то ещё нормально работает?

Нет, но теоретически ей ничего не мешает работать ни на CLR, ни даже в рантайме CL.

похер к кому притензии, если на это натыкаешься в кложуре — это её проблемы

Основные ограничения современной реализации clojure генетически находятся в jvm.

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

теоретически

отлично, заюзаю для теоретической разработки софта
теоретически для него вообще CL можно взять

Основные ограничения современной реализации clojure генетически находятся в jvm.

Это ясно. Речь о том что проблемы jvm это проблемы clojure.

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

отлично, заюзаю для теоретической разработки софта

:D реализация голименькая, кто спорит. Меня например не перестает высаживать потребление памяти, например.

Это ясно. Речь о том что проблемы jvm это проблемы clojure.

Я бы все-таки отделял язык от реализации при обсуждении языка (а не платформы для разработки).

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