Остались ли ещё в России пользователи Common Lisp?

Кроме call/cc.

А как тебе нравится наш интерпретатор с точки зрения логики? Подходит на роль замены call/cc? Можно сделать компилятором.

Подходит на роль замены call/cc? Можно сделать компилятором.

1. Компилятором сделать нельзя. По крайней мере до тех пор пока suspend-request не удастся сделать работающим не внутри my-eval.

2. suspend-request — это урезанный call/cc. Частично намеренно (явный запрет на повторное выполнение), частично — синтактически (call/cc удобней использовать изнутри программы, так как захват не приостанавливает автоматически выполнение).

Если бы п.1 работал (так-то есть cl-cont, но замедляет программу почти как наш suspend-request), то с 2 можно было бы смириться.

При наличии call/cc в языке наш интерпретатор можно было бы делать компилятором и он работал бы на два порядка быстрее.

По крайней мере до тех пор пока suspend-request не удастся сделать работающим не внутри my-eval.

Может я что-то не догоняю, но мне кажется, что можно. Просто более трудоёмко. ПРо скорость не знаю.

suspend-request — это урезанный call/cc

Скорее это просто немного другая конструкция, чем call/cc. Строго говоря, не совсем такая, ведь call/cc разделяет состояние. А мы его копируем. Но могли бы и разделять.

1C-ники и внезапно лисперы? это как вообще? даже не смешно

Испытай разрыв шаблона. Censored

Может я что-то не догоняю, но мне кажется, что можно. Просто более трудоёмко.

Я честно пытался. Чтобы сделать suspend-request в компилируемой процедуре надо как-то сохранить полный стек системы, включая места возврата из функций. Причём это надо делать до окончания компиляции, потому что

(let ((x 1))
  (defun foo ()
    (incf x)
    (bar)
    x)) 

(defun foo () (bar) 2)) 

Строго говоря, не совсем такая, ведь call/cc разделяет состояние. А мы его копируем. Но могли бы и разделять.

Верно. И поэтому тоже call/cc полезнее. Например, сделать на call/cc yield достаточно тривиально, а на suspend-request почти невозможно (на каждой итерации будет копироваться как-минимум вся коллекция).

С другой стороны, гарантировано скопировать состояние мы не можем: открытые сетевые соединения, ссылки на внешние(foreign) библиотеки, большая часть потоков, замыкания не копируются вообще, так как нет способа получить их полное внутреннее состояние.

С оптимизатором печаль. В screamer это как-то решено, в т.ч. копирование замыканий. По сути, для этого нужно «огулять» весь код перед компиляцией. Для быстрого копирования коллекций есть «версионное состояние», которое можно дальше усовершенствовать.

Копировать открытые сетевые соединения мы не можем. Мы можем написать для них метод копировщика, который, к примеру, посылает нас лесом. Или отдаёт оригинальное соединение первому реально вызвавшему, а второго посылает лесом.

Но в целом - да, ты меня разубедил, я в этом не участвую :) Для того и создаётся новый язык, чтобы можно было решить подобные проблемы более легко.

Хотя нельзя сказать, что именно возможность call/cc как-то заложена в дизайн. Но можно и попробовать заложить.

В screamer это как-то решено, в т.ч. копирование замыканий. По сути, для этого нужно «огулять» весь код перед компиляцией.

И как скопировать вот такое:

(setf f (let ((x 1)) (lambda () (incf x))))

(f)
(f)
(setf st (suspend-request))
(f)
(f)
(my-eval st)

Если сделать все интерпретатором, то можно (полный интерпретатор схемы на CL от Норвига есть). Но если требуется типа-компилятор, то никак. Обход заткнётся, например, на (mapcar (lambda (x) (f)) '(1 2 3 4)). Исходники mapcar в потрохах компилятора и обходу недоступны.

Но можно и попробовать заложить.

В смысле, изнасиловать SBCL?

IMHO, проще CL написать на Racket (тогда будут все плюсы Racket с синтаксисом CL).

проще CL написать на Racket (тогда будут все плюсы Racket с синтаксисом CL).

Когда Racket перестанет быть LGPL и вместо JIT компиляции сделают нормальную, тогда можно будет это обсуждать с моим участием. Возможно, я ископаемое, но технологию JIT я вряд ли когда-то признаю. Впрочем, ископаемый не только я, но и Apple, к примеру, поэтому у него такие быстрые операционные системы :)

И как скопировать вот такое:

Я не помню. Если тебе интересно, посмотри, как он это делает. Впрочем, там речь идёт об откате выбранных побочных эффектов, а не о копировании состояния. Когда-то я сделал прототип call/cc, пропатчив screamer, и вот коммит, которым я это выпилил:

https://bitbucket.org/budden/yar/commits/113823c244f83664812e0093807bfbbc2bf1...

Не уверен, что твоя задача там решена, но весьма вероятно, что да. screamer в целом работает через автоматический CPS, с целью которого он и «огуливает» код.

Когда Racket перестанет быть LGPL

Это не влияет на языки на базе Racket. А изменения в сам код компилятора вносить не требуется (в отличие от SBCL).

вместо JIT компиляции сделают нормальную

#lang racket
(require disassemble)

(define (fact x) (if (> x 1) (* x (fact (- x 1))) 1))

> (disassemble fact)
       0: 8b4804                         (mov ecx (mem32+ eax #x4))
       3: 894bfc                         (mov (mem32+ ebx #x-4) ecx)
       6: 8b4808                         (mov ecx (mem32+ eax #x8))
       9: 894bf8                         (mov (mem32+ ebx #x-8) ecx)
       c: 83c3f8                         (add ebx #xfffffff8)
       f: 8b13                           (mov edx (mem32+ ebx))
      11: 8b5220                         (mov edx (mem32+ edx #x20))
      14: 8b4204                         (mov eax (mem32+ edx #x4))
      17: 8943fc                         (mov (mem32+ ebx #x-4) eax)
...... пропущено для уменьшения сообщения
     277: 5f                             (pop edi)
     278: 5e                             (pop esi)
     279: 5b                             (pop ebx)
     27a: 5d                             (pop ebp)
     27b: c3                             (ret)
> 

screamer в целом работает через автоматический CPS

Это решение очень сильно тормозит результат. Ну и проблема с mapcar и прочей стандартной библиотекой остаётся, так как для нормальной работы через CPS надо провести все используемые функции.

Это не влияет на языки на базе Racket.

Ещё как влияет. Захочу я сделать свой 1С на лиспе, сделаю его на базе Racket по статье Дмитрия Павлова, и обрадуюсь, а тут вдруг окажется, что это GPL.

По Яру, я думаю, на сегодняшний день в сумме 85% трудозатрат - это IDE (притом, что она грубо сшита из крупных готовых кусков), 10% - это спецификация языка, и 5% - это реализация первой версии, которая уже давно работает.

Захочу я сделать свой 1С на лиспе, сделаю его на базе Racket по статье Дмитрия Павлова, и обрадуюсь, а тут вдруг окажется, что это GPL.

LGPL, его можно использовать и не открывать свой код.

тут вдруг окажется, что это GPL

Ты же не боишься разрабатывать Яр под линуксом, у которого ядро под GPL, а базовая библиотека под LGPL. Ситуация аналогична.

сделаю его на базе Racket по статье Дмитрия Павлова

Никакого изменения исходного кода Racket в данной статье не предполагается. Значит ограничения LGPL не действуют.

под линуксом, у которого ядро под GPL, а базовая библиотека под LGPL

В их лицензиии добавлены разрешительные исключения на системные вызовы и испоьзование в составе ОС соответсвенно.

В их лицензиии добавлены разрешительные исключения на системные вызовы и испоьзование в составе ОС соответсвенно.

Я к тому, что linux kernel и glibc не заражают (GPL'ем) программы, которые их используют, также как и Racket.

Может вы пойдете и в чятиках переговорите? Тема слилась в офтоп

Не заражают, что бы это не означало, в том числе и из-за дополнилительный исключений:) Которых у обычной LGPL нет. И их не правильно ставить в пример для подражания. К слову если у racket действительно чистый LGPL без runtime exception аналогичным gcc. То это делает ситуацию двусмысленой.

Речь даже не о Runtime exception, потому что речь идёт не об использовании Racket, а о его расширении. Если я делаю «свой 1С», то логично начать со среды DrScheme или как её там называют, как с фундамента: редактор, отладчик, библиотека ГПИ. Допустим, я хочу добавить к этому набору таблицу (grid) для вывода данных. Этот код как бы станет частью DrRacket и тем самым попадёт под LGPL. Во всяком случае такая ситуация с EMACS. GPL заражает абсолютно весь код на el. Поэтому сервер SLIME под public domain, а клиент - под GPL. Именно по этой причине я сразу отказался от возможности использовать EMACS в своих разработках в качестве среды разработки. Может быть я что-то не понял насчёт лицензии. Но даже в случае LLGPL может быть проблема, если я пытаюсь распространять образ, содержащий LLGPL библиотеку, сохранённый с помощью save-image.

Относительно mapcar. Наш ведь интерпретатор тоже его не понимает, верно?

(defun inner (x) (print x) (ew:suspend-request))
(ew:my-eval '(mapcar 'inner '(1 2 3)))
==>
error: suspend-request должен быть в интерпретируемом коде

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

У Glibc никаких исключений нет: http://www.palamida.com/posts/view/19

чистый LGPL без runtime exception аналогичным gcc

У gcc GPL. Поэтому необходим runtime exception. А был бы LGPL, его можно было бы в закрытых продуктах библиотекой подключать.

К слову если у racket действительно чистый LGPL без runtime exception аналогичным gcc. То это делает ситуацию двусмысленой.

Нет, не делает. https://docs.racket-lang.org/license/index.html

Если я делаю «свой 1С», то логично начать со среды DrScheme или как её там называют, как с фундамента: редактор, отладчик, библиотека ГПИ.

DrRacket. Да, его изменённая версия будет LGPL. Но его можно использовать именно как платформу, а не модифицировать непосредственно. Программа, запущенная из DrRacket может быть с любой лицензией.

Допустим, я хочу добавить к этому набору таблицу (grid) для вывода данных. Этот код как бы станет частью DrRacket и тем самым попадёт под LGPL. Во всяком случае такая ситуация с EMACS.

EMACS под GPL. grid попадёт под LGPL только в том случае, если будет являться неотъемлемой частью DrRacket. В виде плагина или библиотеки может быть не LGPL.

Тогда наверное чтобы поддерживать mapcar и обойтись без CPS - это только разобраться в устройстве стека и лямбд и научиться их осознанно копировать, обходя все ссылки и предпринимая нужное действие для каждой из них. Возможно, что SBCL это даже вовсе не умеет, потому что у него для стеков консервативный сборщик мусора.

Вот это я и имел в виду под «suspend-request или call/cc для компилированного кода».

Т.е., видимо, SBCL не знает, что у него на стеке. CCL должен уметь.

Интересно было бы сравнить по скорости. Оптимизатор там вроде сильно хуже.

А тут пишут, что там JIT

https://docs.racket-lang.org/guide/performance.html

Ну и мой список того, почему я отверг Racket, ещё далеко не закончился :)

Например: плохое название, кроме организационных проблем с *GPL есть и чисто символико-религиозные (коротко говоря - дьявольщина нарисована). «DrRacket instruments programs for debugging, and debugging instrumentation can significantly degrade performance for some programs», т.е. можно заподозрить качество отладчика примерно как в 1С, где производительность при отладке падает на порядок.

Производительность в принципе ниже где-то вдвое, чем у SBCL, согласно «Computer Benchmark Game», хотя тут была тема, где это оспаривалось. Про отсутствие unwind-protect вроде тоже что-то ответили. Так что по этим двум вопросам пока для меня «серая зона».

Кроме того, я занимаюсь разработкой языка и платформа для меня подлежит изменениям заведомо. Например, завтра я захочу сделать форк SBCL, чтобы вместо разгона заняться качеством - могу. Захочу форкнуть для русификации, если не получится русифицировать по-хорошему - могу. Захочу форкнуть, чтобы сделать call/cc - могу. Захочу выпилить из tk tcl и заменить его на CL - могу. Захочу выпустить перевести реализацию SBCL полностью на Яр - могу. Захочу поменять сборщик мусора - могу. Всё могу.

А если я завязался на *GPL, то я сразу связан по рукам.

Т.е.. может быть для проекта «свой 1С» DrRacket и подходит. Но для проекта Яр он не подходит и это окончательное решение.

Вот это я и имел в виду под «suspend-request или call/cc для компилированного кода».

Это было одним из вариантов для раскраски. И я даже пытался обратиться к Коваленко и ещё к кому-то из метров. 20 долларов в час само по себе не так страшно, но страшно при том, что масштаб проекта непонятен + плюс потом поддерживать всю жизнь, если команда SBCL не захочет залить в основной репозиторий, плюс возникновение новых багов на низком уровне, отладкой которого я не владею и не особо хочу, чтобы мне это пришлось делать. Посему у нас реализован интерпретатор ровно под ту задачу, которая была актуальна на тот момент.

дьявольщина нарисована

Где? Там вроде только буква lambda на красно-синем фоне. По названию согласен, не самое удачное.

производительность при отладке падает на порядок

Это везде так. В sbcl (debug 3) от (debug 0) тоже на порядок.

Производительность в принципе ниже где-то вдвое, чем у SBCL

Да. Аналог (safety 0) там не хотят делать по принципиальным соображениям: мол, программу без проверок пускать в продакшен будет только самоубийца.

Про отсутствие unwind-protect вроде тоже что-то ответили.

dynamic-wind

А если я завязался на *GPL, то я сразу связан по рукам.

Только тем, что *GPL компоненты обязан поставлять своим клиентам с исходниками. Это разве так сложно или неприемлемо? А всё остальное и в рамках *GPL можешь.

Но для проекта Яр он не подходит и это окончательное решение.

Я не спорю. Тем более, что рабочий вариант на CL+Tcl/Tk уже есть. Без веских причин было бы глупо всё начинать заново.

Посему у нас реализован интерпретатор ровно под ту задачу, которая была актуальна на тот момент.

У него проблема с производительностью и памятью из-за «интерпретатор + глубокое копирование с запоминанием/сравнением всех узлов». Если их станет не хватать (для длинных текстов программ), то исправить можно только полной сменой спецификации.

хоть в дурдом

К остальным лисперам.

Судя по аналогичной проблеме с cl-js, мы каким-то образом умудрились занять чем-то почти всю память (в текущей версии Яра интерпретатор для раскраски лиспа отключен), так что это может быть не его проблема, а проблема среды, в которой он поселён. Исправляется переходом на 64 разряда. Если и этого не хватит, то это явно какая-то утечка памяти (баг).

А ты откуда такой осведомленный? Неужели, лисперы в соседней палате?

Ну так что? Лисперы нашли друг друга и тред можно закрывать?

Когда Racket перестанет быть LGPL и вместо JIT компиляции сделают нормальную

А чем jit компиляция хуже нормальной? Разве есть хоть один недостаток?

А ты откуда такой осведомленный?

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

вместо JIT компиляции сделают нормальную

К слову, в SBCL тоже JIT. В качестве байткода .fasl. Для лиспов, скорее всего по-другому нельзя, так как иначе придётся компилировать вместо вызова функции проверку, что эта функция не поменялась.

Разве есть хоть один недостаток?

Есть. Время компиляции. Например, GNU coreutils на языке с JIT работали бы значительно медленней.

Если и этого не хватит, то это явно какая-то утечка памяти (баг).

В существующей системе раскраски объём памяти зависит от количества строк в лучшем случае линейно, в худшем — квадратично (в каждой строке по ссылке доступны соседние строки).

У gcc GPL. Поэтому необходим runtime exception.

Нeт помому что плюсовый компилятор добавляет свои артефакты в скомпилированый код. И их комбинация уникальна для каждой сборки. И даже если бы он был под lgpl то конечному получателю закрытого кода пришлось бы давать права и способ по перекомпиляции продукта для возможности замены этих артефактов. С racket ситуация полностью аналогичная. У тоже стандартная библиотека должна влазить в итоговый код в рамках раскрытия макросов например. Или должны быть гарантии что такие артефакты будут локализованы где-то в другом месте.

Нет, не делает. https://docs.racket-lang.org/license/index.html

Там про racket software и ничего про производные и написаные на базе racket-а языки. А вот в самй lgpl как раз сказано, что производные от собственно lgpl-кода должно оставаться под той же лицензией.

завтра я захочу сделать форк SBCL, чтобы вместо разгона заняться качеством - могу ... и абзац дальше
А если я завязался на *GPL, то я сразу связан по рукам.

Чисто для протокола. Форкать под свои нужды gpl ни в коем случае запрещает и даже приветствует:)

Форкнуть могу, продать без исходников не могу. Я это имел в виду. Т.е., если я начну с рекета, я _никогда_ не сделаю «другой платный 1С». Если начну с SBCL и tcl/tk, то я _могу_ это сделать, если захочу. Захочу или нет - другой вопрос. Но вот сделать call/cc для SBCL я в принципе могу. А избавиться от *GPL - в принципе не могу.

Нeт помому что плюсовый компилятор добавляет свои артефакты в скомпилированый код.

Мне всегда казалось, что программы, собранные GCC - это продукт его работы, а не продукт, производный от GCC, и они не подпадают под GPL.

К слову, в SBCL тоже JIT. В качестве байткода .fasl.

Да, похоже я неверно понимал смысл термина JIT, считая, что там обязательно заложен профайлер и компиляция основана на результатах его работы.

Но я не думаю, что SBCL - это JIT, поскольку он не умеет исполнять байт-код. В CMU CL был исполнитель байт-кода, но его выпилили из SBCL. Согласно Википедии, JIT - «технология увеличения производительности программных систем, использующих байт-код, компиляции байт-кода в машинный код или в другой формат непосредственно во время работы программы.». Т.е., SBCL - это, как минимум, вырожденный случай. Обычный eval исполняет не байт-код, а непосредственно консы. и SBCL не компилирует фаслы, а делает с ними что-нибудь другое.

Также, если мы сохраняем исполняемый образ (как сделано в Яре), а не грузим фаслы, то у нас вообще нет никакой компиляции во время работы программы и это уже точно не JIT. Загрузка ускоряется раз в 10. Что и является прекрасной иллюстрацией такого недостатка JIT, как тормозная загрузка.

что программы, собранные GCC - это продукт его работы, а не продукт, производный от GCC, и они не подпадают под GPL.

Это заявленая цель, не правило. С оговоркой что собраное не должно использовать и зависеть от рантайма gcc. В принципе зная внутрености gcc можно написать программу которая будет производная от gpl-кода компилятора. В рамках С-шного компилятора эта цель выполнялась. В рамках плюсового возникли сложности, он таки сам независмо от пользователя линкует части рантайма. При этом пользователь без вины но все равно попадает. Добавили исключение на рантайм дабы убрать неоднозначности. Когда gcc переводили на gpl3 это исключение временно исчезло. И заметивший это народ плакал и страдал.

Форкнуть могу, продать без исходников не могу. Я это имел в виду

Я понимаю. Но все же своди тогда спич к «хочу платную 1С». Это всем понятно в отличае от перпендикулярных рассужденях о форках.

Там про racket software и ничего про производные и написаные на базе racket-а языки.

так производные и написанные на базе racket'a языки - и есть racket software.

Или должны быть гарантии что такие артефакты будут локализованы где-то в другом месте.

О каких артефактах речь? У экспандера racket таковых нету. У байткода, насколько я знаю, тоже.

Но я не думаю, что SBCL - это JIT, поскольку он не умеет исполнять байт-код.

Racket тоже вроде как не умеет, если только не пересобрать его как интерпретатор.

А остались тролли жЫрнее тебя?

В нём очень много полезных идей, которые применимы в других языках: контексты, сигнальный протокол, мультиметоды... В других языках реализация будет выглядеть неуклюже, но знать полезно также как и Design Patterns. Даёт новые термины для описания решения задачи.

вот ты всё-таки будешь смеяться, но даже метаобъектный протокол применим. см. диссер Константина Книжника про ООСУБД GOODS: он его на С++ применил. изобрёл сначала рефлексию в С++96, потом поверх неё МОП, потом поверх него — стратегии СУБД (обработка транзакций, одно/многопоточность, кеширование объектов через подкачку, и т.п.).

в общем, переизобрёл АОП через МОП через рефлексию.

вообще, такие штуки как ООСУБД или тот же MUMPS СУБД (например, компилятор наподобие Okane'овского, MUMPS-> C++ только теперь в лисп) на CL выглядят просто и наглядно.

ещё видел где-то куски компилятора STEP EXPRESS в лисп, тоже разумная идея же, с этим вот language-oriented programming workbench.

элизу вот откопал, намедни. обзор реализаций

Кстати, коллега мой ранее занимался (и сейчас вроде как поддерживает) систему на PicoLisp

интересно. поделись историей успеха от него. что за система, почему «Radical approach to RAD» и прочее, почему PicoLisp.