Есть такая идея. SBCL - это спортивный автомобиль. Они всё время работают над его ускорением, но надёжность не растёт. Конкретный пример для меня - https://bugs.launchpad.net/sbcl/ bug/1424031 - бага «medium». Если мы правильно разборались со Стасом, то мой тестовый случай состоял в том, что я во многих тредах запускал попеременно (room) и (gc). SBCL при этом с низкой вероятностью падает, зависает и т.п. С моей точки зрения это означает ничто иное, как «room не работает в многопоточном коде», а поскольку SWANK многопоточен, то далее получаем теорему «в SBCL не работает room». В течение более чем года это никого не волнует, а волнует, как ускорить сборку мусора на 5%. В моей вселенной это - абсолютно неправильное направление развития продукта.
Кроме того, в SBCL нет точной сборки мусора (во всяком случае, под Intel на Linux).
В третьих, лисп нужно модернизировать, а для этого нужно более агрессивно добавлять новшества. Явно не хватает таких вещей, как брекпойнт на присваивание и биндинг переменной. Хочется внедрить symbol-readmacros, которые я сделал уже несколько лет назад. Хочется возможностей безопасно прилинковать библиотеки, использующие сигналы - в CCL они работают, а в SBCL - нет. Хочется сделать более развитые средства навигации по исходникам, подобно dspec в Lispworks. Хочется сделать defadvice, как в Lispworks. Хочется реализовать на уровне компилятора call/cc, который мы с Монком в прошлом году сделали в виде интерпретатора.
Т.е. я вижу три направления развития:
- точная сборка мусора
- повышение качества
- модернизация языка
Вопрос такой - есть ли попутчики? Надо сказать, что я не смогу этим много заниматься. Но если будет ещё хотя бы человека два, кто в этом заинтересован, я бы взялся.
