pretty printer

А еще в Common LISP есть совершенно замечательный настраиваемый pretty-printer, который можно использовать не только для того, чтобы печатать в синтаксисе лиспа. Вот, например, как генерится код на Паскале.

Кодогенерация: Common Lisp vs. Emacs Lisp

Одно из применений лиспа - это генерация кода, в т.ч. не только на лиспе, но и на других языках. Вот я думаю, может для этой задачи ограничиться Emacs Lisp, а не тащить common lisp?

Потенциальные преимущества:

• Emacs есть везде и под все, а Common Lisp - нет (для меня несущественно, но все же).
• Собственно генерация кода нужна именно для автоматизации программирования, что в принципе кажется Emacs'овой задачей.
• Язык сам по себе попроще будет, при этом, просмотрев исходники parenscript, на первый взгляд не нашел там ничего такого, что нельзя было бы сделать на Emacs Lisp. Местами используется CLOS, но это несущественно.

Недостатки:

• В Emacs Lisp нет READ-макросов, что несколько ограничивает создание DSL, и делает невозможными красоты типа CL-INTERPOL
• При макроподстановке не выполняется destructuring, (собственно он в Emacs Lisp обнаружен не был), что тоже может быть неудобно.
• Отсутствие lexical closures в основной верии Emacs, lexical-let не в счет - не могу понять последствия для этой задачи.

Читаю книжку Programming Clojure

Нужно написать нечто, и кажется что на JVM это нечто будет работать лучше всего. Хотя проект не терпит всякие "альтерниативные" языки в production коде, так как мои знания Джавы мягко говоря не очень, то мне или долго писать на Java, или выучить Clojure и быстро на нем переписать прототип, ранее сделанный на Сommon LISP, чтобы быстрее заняться другими делами, и если все будет хорошо, потом уже аккуратно сделать Java вараинт.

Книжка не очень большая, меньше 300 страниц, и легко читается, по крайней мере первые 4 главы прочел уже довольно быстро. Сам Clojure хорош (по сравнению с Java так вообще, но ... если вам не надо Java, то возьмите лучше Common LISP. Из JVM-hosted языков знаком немного с Jython, и отличие вижу в том, что в то время как Jython старается как можно больше быть похожим на C Python, Clojure этим не страдает, его задача - максимально легко использовать Java с помошью приятного функционального язычка, а на что оно похоже - не важно.

Closure Oriented Programming

Closure Oriented Programming (from http://letoverlambda.com/) hinders interactive development. I find it much easier to have separate defuns operating on complex data structures than function that are deeply nested within a "network" of closures. Despite we have fewer code lines with closures, than with declaring separate structs or classes, with more traditional approach, the code and data is much easier to explore from REPL.

let*

Почему-то не нравится let*. Хочется писать вложенные let, хоть это и больше скобок и индентации.

SXHASH

Странно работает SXHASH. Если считать хеш символа, то в 32-bit SBCL значения идут чуть ли не подряд (fixnum в районе 300 тыс. ). В Clozure CL вообще кажется идут ASCII коды символов! Если я взял символы от A до Z, как мне получить значения хеша, равномено распределенные в некотором интервале?

SLIME и PACKAGES

Обнаружил, что надо в файле обяазательно писать (in-package :mypacakge), чтобы из буфера slime-compile-defun и прочие делали это в правильном пекедже. SLIME просто ищет in-package в тексте буфера.