Common Lisp - заготовка для portable define-advice

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

Бабло побеждает зло

При этом просто родится новый язык. Причём те, кто пишут на Common Lisp, на него не перейдут.

Если бы мне предложили уже готовый лисп, где эти проблемы решены, а скорость - как в SBCL, я бы перешёл. Но я - это конечно, не все, кто пишут на Common Lisp. А вообще мнение лисперов не имеет значения ввиду их исчезающе малой численности. Т.е. остаётся «будет также сложно агитировать», но это всё равно гораздо лучше, чем «переманить лисперов».

Если бы мне предложили уже готовый лисп, где эти проблемы решены, а скорость - как в SBCL, я бы перешёл.

Ну Racket я уже предлагал. Если лицензия не устраивает, есть Chez Scheme с правильным хранением исходников процедур, нормальной многопоточностью и лицензией Apache 2.0.

Да. Потому что я не вижу «развития языков» в смысле какого-то существенного, качественного скачка, по сравнению с тем что есть в любом лиспе (или можно запилить не меняя языка).

Типизированные расширяемые коллекции, параметризованные классы, примеси, корутины, деструкторы, ...

Насчёт константы всё не так просто - сделав unintern, нужно ещё и убить всё, что на неё ссылается.

Зачем? Вроде как её значение останется.

* (defconstant +x1+ 1)

+X1+
* (defun f (x) (+ +x1+ x))

F
* (f 1)

2
* (unintern '+x1+)

T
* (defconstant +x1+ 2)

+X1+
* (f 1)

2

Или это UB?

Типизированные расширяемые коллекции, параметризованные классы, примеси, корутины, деструкторы, ...

Я ещё добавлю freeze-object и вообще иммутабельность и статическую проверку типов «как в Си». Но зря мы с тобой стараемся. Раз уж advice, который реализован в 3 коммерческих реализация, объявлен ненужным, то всё названное нами будет явно классифицировано как недофичи из недоязычков.

Вроде как её значение останется.

Т.е. в части состояния будет старое значение, а в части новое. Т.е. очередное усложнение состояния.

Точнее решено было в Scheme.

Где коротко про это прочитать? Мне всё же касалось, что я предпочту небезопасные фичи из CL, чем урезанность Scheme. Насчёт Chez Scheme - она по скорости как по сравнению с SBCL?

Насчёт Chez Scheme - она по скорости как по сравнению с SBCL?

За Chez не скажу, а вот Chicken практически сопоставим, но там подход разработки совсем другой(интерпретатор с repl есть, но работает медленее, чем компилятор) - пишешь код и компилируешь, как в мэйнстримовых языках.

пишешь код и компилируешь, как в мэйнстримовых языках.

Не, это не наш метод :)

Не, это не наш метод :)

Ну тогда, тебе либо придется подружиться с виртуальными машинами и смириться с кложей, либо сотворить свой нормально-лисп.

А в Chez написано, что там инкрементная компиляция. Monk говорит, что в Racket тоже она есть (правда, по сравнению с CL её там нет). Я думаю, что форкнуть CCL и сотворить нормально-лисп - умеренно дорого (и собственно, Яр - это он и есть, правда скобочки по дороге потерялись). Хотя пока я в бюджет не уложился :)

Как фичу языка - ненужно.

В общем, я услышал молчание на sbcl-devel, ccl-devel и твою точку зрения. cl-advice не будет отдельной библиотекой, а будет распространяться в составе budden-tools - раз оно отдельно никому не нужно, то я сэкономлю немного сил на том, что у меня не будет +1 репозиторий.

собственно, Яр - это он и есть, правда скобочки по дороге потерялись

Скобки это же средство, а не цель.

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

Зато в России я получаю дополнительное конкурентное преимущество. Учитывая чрезмерную конкуренцию между языкми, лучше быть первым в узкой нише, чем 118-м в широкой.

Скобки это же средство, а не цель.

Мне кажется, для некоторых это святыня. Впрочем, опять же: мнение лисперов не имеет большого значения ввиду их малочисленности.

- заметно расширяет возможности для SBCL и CCL и приводит их к общему знаменателю - в EMACS и в питоне декораторы есть, а в CL - нет - На самом деле код ещё довольно сырой - Если бы мне предложили уже готовый лисп - В общем, я услышал молчание на sbcl-devel, ccl-devel - Зато в России я получаю дополнительное конкурентное преимущество - Впрочем, опять же: мнение лисперов не имеет большого значения ввиду их малочисленности.

А что уже троллить этого троля никого не осталось? Видимо всем надоело. Тоже верно. Одно непонятно - почему санитары паренька еще не упаковали.

Т.е. очередное усложнение состояния.

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

Вот я сейчас обновил glibc и у меня в части состояния старая библиотека, а в части — новая. Но это усложнение состояния мне не мешает спокойно продолжать работать.

Где коротко про это прочитать?

http://wiki.c2.com/?SchemeLanguage

https://en.wikipedia.org/wiki/History_of_the_Scheme_programming_language

Насчёт Chez Scheme - она по скорости как по сравнению с SBCL?

Судя по https://ecraven.github.io/r7rs-benchmarks/ должно быть примерно равно. В том смысле, что chez обгоняет Racket 6.10 примерно во столько же раз, как и SBCL.

Мой тебе совет :-) Если тебе нужен Лисп, то покупай LispWorks и работай :-) Если не устраивает лицензия LispWorks, посмотри вообще на другие языки :-) Бесплатных лиспов не бывает, чем-то придётся заплатить, и заплатить весьма дорого :-) Какой там СБЦЛ, какой ЦЦЛ? :-) Лол :-) Ты ещё CLISP откопай и форкни для полного счастья :-) Лол :-) Что может быть дороже времени? :-) Возьми другой язык, если не хочешь платить деньги за нормальную реализацию Лиспа :-) Лол :-)

Monk говорит, что в Racket тоже она есть (правда, по сравнению с CL её там нет).

Это в CL её нет. ASDF неадекватно отслеживает, какие модули необходимо перекомпилировать. Более того, удаление метода CLOS или функции из файла и перекомпиляция не удаляет его из образа.

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

А в Racket модули изолированы, поэтому перекомпилируется только то, что необходимо. В CL есть аналогичный XCVB, но непопулярен и судя по тому, что последние изменения в нём были несколько лет назад, то уже и не будет

- CL умирает

- Он сам по себе «не кажется таким уж суперполезным»

- Посмотри на дату выхода последних версий SBCL по платформам - он уже отчасти умер

- Нужно думать, как спасать язык, чем его расширить

- остальным это по барабану, да и вообще лисперов становится меньше и меньше

Это то, как тебе видится ситуация. Просто с тобой никто из нормальных людей не будет в таком ключе общаться. Или пообщавшись раз, теряет всякое желание. Ты же прешь как танк против потока, ничего не слушая и никого слыша. Слышал про FORTRAN in any language symptom? Так что, как бы это тебе не казалось невероятным, людям не близки твои «задачи», которых ты сгенерировал сотни на моей памяти, *по причине того*, что ты *неправильно используешь Lisp* и эти «задачи» вообще не надо решать.

Так что, как бы это тебе не казалось невероятным, людям не близки твои «задачи», которых ты сгенерировал сотни на моей памяти, *по причине того*, что ты *неправильно используешь Lisp* и эти «задачи» вообще не надо решать.

Именно поэтому никакого нового стандарта Common Lisp не предвидится.

Стандарта не предвидится по нескольким причинам. Главное, что народ отупел) и понимают Lisp/CL тысячи/десятки тысяч, они сильно распределены по шарику и занимаются очень разными делами. В этом смысле им очень даже выгодна стабильность, замороженность стандарта и реализаций. И, внимание, Великая Тайна, *им всего хватает*.

Именно поэтому никакого нового стандарта Common Lisp не предвидится.

Ты о чём? :-) Что такое стандарт? :-) Это документ некой организации :-) Вот есть организация ANSI, пишет стандарты :-) Почему ей обязан кто-то следовать - мне неведомо :-) И что, если сделать простую реализацию Лиспа, положив с прибором на стандарт, то это уже будет не Лисп? :-) Лол :-) Чего стоит нынешний стандарт CL? :-) Ничего он не стоит :-) Это просто предписывающий текст с благой идеей «сделать много лиспов, но более-менее одинаково» :-) Кому от этого жарко или холодно? :-) Я не знаю :-) Вот в СБЦЛ принято гордиться тем, что он соответствует стандарту ANSI :-) Ну и что из этого следует? :-) Ничего из этого не следует :-) Там даже тредов нет в стандарте том :-) На кой вообще ему соответствовать тогда? :-) Ответ прост - чтобы соответствовать, это же стандарт!!1 :-) Ну ок, вам нужен стандарт - вот он, реализованный :-) Лол :-)

В твоём любимом Рэкете стандарта нет, зато есть чудесный сайт с докой, современные идеи из CS, хорошо и единообразно названные функции и символы и т.д. и т.п., и ты пользуешься и доволен :-) И стандарт тебе не нужен :-) Тебе просто дали качественную платформу :-) Возьми тот же Node.js, им пользуются миллионы :-) И вот интересно, нужен ли кому-нибудь стандарт на Node.js? :-) Лол :-)

Ну и да :-) Если кто-то сделает компактную (Racket большой, вот PicoLisp уже лучше) платформу со своей реализацией Лиспа для разработки в образе (или Яра или ещё с чем - неважно, важно что это будет маленькая и толковая платформа с хорошей докой), то толка будет больше, чем от реализации лиспа, соответствующей сферическому стандарту на много тысяч страниц :-) Только не надо делать платформу на базе СБЦЛ, пожалуйста :-) Лол :-)

Смайлик, я ведь тебя не читаю, ты зря стараешься. Иногда я вижу твои сообщения из-за какой-то баги или фичи.

Кривость asdf - это одно, а возможность переопределить отдельную функцию, или при написании файла прописать, где у тебя defvar, а где defparameter - это другое. Есть ли в схеме аналог разделения на defvar и defparameter?

Но мне нужно не просто описание схемы, а именно описание отличий,в т.ч. с т.з. гор. замены, и конкретно меня интересует chez, а не «схема вообще».

Когда разработка в образе, то сложность состояния никого не волнует.

Волнует. Кто-то написал, что сложность состояния лиспа зачастую превосходит возможности самых крутых мастеров лиспа. И когда я смотрел, как Фаре отлаживает asdf, я это тоже увидел во всей красе :)

Смайлик, я ведь тебя не читаю, ты зря стараешься. Иногда я вижу твои сообщения из-за какой-то баги или фичи.

Это личное твоё дело :-) Я тебе просто посоветовал посмотреть в сторону других языков :-) А дальше ты думай сам, тебе решать что использовать :-)

Ничего личного, я просто забанил всех анонимусов. Ты можешь зарегиться.

Типизированные расширяемые коллекции

Вопрос реализации, а не языка. Не вижу проблемы замутить коллекции на базе clos, в т.ч. «типизированные».

параметризованные классы

Т.е. говоря проще - дженерики. Зачем они в языке с динамическими типами?

примеси,

Множественное наследование покрывает все эти миксины/трайты и т.п. хрень из языков где наследование только от одного родителя.

корутины,

В том или ином виде есть в любом современном лиспе, включая CL (со своими тараканами, конечно).

деструкторы

Какие деструкторы в языке с GC? Для RAII есть unwind-protect.

Вообще странно сравнивать отдельно взятый язык со всеми языками вообще. Где всё то что тут перечислено, например в питоне? Или в таком современном и прогрессивном Golang? Что-то этим языкам отсутствие фич никак не мешает быть в мейнстриме, а не загибаться в заповедниках.

Bad news. Забанивание, разбанивание, истерики, (потуги на) мотивации, уход в монастырь, плач ЯРО-славны (CL умер) pun intended, ничто не призовет под твои знамена тру лисперов, эти люди знают себе цену и не ведутся на эти кривляния. Так что *если так хочется командовать толпой*, избери другую аудиторию.

В CL эффективной кроссплатформенной реализации корутин нет.

Динамические типы, кстати, это тоже недостаток для больших проектов. Смотри практику. Typescript и аннотации типов в Python 3. Когда код разрастается, возникает неудержимое стремление возложить побольше работы на компилятор. Динамизм - это хорошо, НО НЕ ВСЕГДА. То, что в этом отношении сделано в SBCL - это лишь иллюзия, в реальности достаточных проверок во время компиляции он не делает. В LW 6 ещё хуже. CCL пока не щупал.

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

Где всё то что тут перечислено, например в питоне?

Это уже следующий вопрос, неясно, стоит ли его вообще обсуждать. До этого мы обсуждали вопрос о том, есть ли в современных языках то, что нельзя сделать в CL средствами языка.

Зачем тебе маленькая? Есть конкретная задача? Компактная платформа с горячей заменой кода - это Оберон.

Не вижу проблемы замутить коллекции на базе clos, в т.ч. «типизированные».

От list, vector, string и hash наследоваться нельзя.

Т.е. говоря проще - дженерики. Зачем они в языке с динамическими типами?

Чтобы создавать разные типы с разными параметрами. Например нужен тебе (hash number (hash number string)) и тебе не придётся для этого писать два defclass в стороне от кода использования, а просто пишешь (make-instance '(hash number (hash number string)) ...).

Множественное наследование покрывает все эти миксины/трайты и т.п. хрень из языков где наследование только от одного родителя.

Опять же, есть у тебя GUI. В нём есть миксины bordered (добавляет рамку к элементу), shadowed (добавляет тень), disabled (блокирует обработку нажатий мыши и клавиатуры элементом), ...

В нормальном языке я пишу (make-instance (disabled (bordered button)) ...), (make-instance (shadowed (bordered window)) ...). В CL приходится вверху делать пачку defclass на каждую комбинацию миксинов. (defclass disabled-bordered-window (disabled bordered window) ...) и т.д.

В том или ином виде есть в любом современном лиспе, включая CL (со своими тараканами, конечно).

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

Какие деструкторы в языке с GC? Для RAII есть unwind-protect.

https://docs.racket-lang.org/finalizer/index.html

Динамические типы, кстати, это тоже недостаток для больших проектов. Смотри практику. Typescript и аннотации типов в Python 3. Когда код разрастается, возникает неудержимое стремление возложить побольше работы на компилятор. Динамизм - это хорошо, НО НЕ ВСЕГДА.

Статики на самом деле почти всегда не хватает. В ней невозможны интервальные вещественные типы, невозможны функциональные типы с более-менее сложными типами, невозможны типы «структура с полем типа» и т.д.

А постоянная работа со статикой приводит к аберрации сознания, когда человек считает, что для целых чисел x+1 может быть меньше x, а для выражения рациональных возможно только приблизительное представление с плавающей точкой.

Не, финалайзеры - это не деструкторы, и они в реализациях CL есть (но не в самом языке), и с ними - слабые хеш-таблицы, которые тоже в языке отсутствуют.

Финалайзеры нужны для ловли утечек ресурсов, например, утёк файловый дескриптор, а финалайзер говорит «непорядок». Они выполняются во время сборки мусора, а значит, в весьма ограниченных по возможностям условиях. Так везде, даже в Java.

От list, vector, string и hash наследоваться нельзя.

Но можно сделать классы от которых наследоваться можно.

Например нужен тебе (hash number (hash number string))

Зачем он мне нужен, если всё это можно положить в обычный «нетипизированный» хэш? И нет, если он таки понадобился, мне не нужно для этого делать 2 разных класса, т.к. тип хэша можно указать при создании инстанса (примерно так, как это сделано для последовательностей в CL).

Если же речь идёт о статической типизации, то это немного другой язык.

В нормальном языке я пишу (make-instance (disabled (bordered button)) ...),

Это что за такой «нормальный язык»?

В CL приходится вверху делать пачку defclass на каждую комбинацию миксинов.

Так это же хорошо, т.к. позволяет группировать классы по смыслу, а не тупо копипастить везде (disabled (bordered button)). Нормальные люди вообще не пишут (make-instance (disabled (bordered button)), а пишут (make-button :for-some-dialog ...)

Фактически на выбор: CPS-преобразование всего текста, из-за чего компилятор сходит с ума и ужасно тормозит

Почему-то крестовиков не смущает когда у них компилятор «сходит с ума и ужасно тормозит» от шаблонов. К тому же ты просто преувеличиваешь.

https://docs.racket-lang.org/finalizer/index.html

Про финалайзеры тебе уже ответили, что это к нормальным деструкторам не имеет никакого отношения и вообще достаточно узкоспециальная тема. Вместо деструкторов во всех «прогрессивных» языках есть try/finally, т.е. именно unwind-protect и всякие with-open-resource на его основе.

Но можно сделать классы от которых наследоваться можно.

И их нельзя будет использовать в стандартных функциях. cl-containers сделали, никто не использует.

Зачем он мне нужен, если всё это можно положить в обычный «нетипизированный» хэш?

Как минимум, чтобы при добавлении записи в хэш проверялся тип ключа и значения. А ещё, чтобы можно было написать функцию, с разными телами для (hash integer t) и (hash string t). Без параметрических классов приходится писать (defclass hash-integer (hash)), (defclass hash-string (hash)). И так по классу на каждую пару типов. Причём, что обидно, если расширял в разных пакетах, то эти классы не равны. То есть, если надо передать (hash string t) в функцию, то нельзя сделать по месту defclass, а надо найти, в каком пакете был установлен нужный метод.

Это что за такой «нормальный язык»?

Например, https://docs.racket-lang.org/guide/classes.html

Так это же хорошо, т.к. позволяет группировать классы по смыслу

Тогда и lambda надо запретить. Пусть код тоже по смыслу группируется.

Почему-то крестовиков не смущает когда у них компилятор «сходит с ума и ужасно тормозит» от шаблонов.

Лучше медленная компиляция, чем медленное выполнение

К тому же ты просто преувеличиваешь.

(cl-cont:defun/cc list-cc (n) (loop for i from 1 to n collect i))

(defun list-n (n) (loop for i from 1 to n collect i))

(time (dotimes (k 10000) (list-cc k) nil))
Evaluation took:
  26.321 seconds of real time

(time (dotimes (k 10000) (list-n k) nil))
Evaluation took:
  1.052 seconds of real time

Вместо деструкторов во всех «прогрессивных» языках есть try/finally, т.е. именно unwind-protect и всякие with-open-resource на его основе.

И как на базе try/finally сделать, например, редактор, который держит файлы открытыми пока открыты соответствующие окна? Или список, который держит соединение к БД пока пользователь его не закроет.

Вообще-то, декораторы в CLOS есть с момента ее создания, примерно. Называются :after, :before и :around методы.

И их нельзя будет использовать в стандартных функциях.

Но можно в своих, нестандартных. Т.о. и появляется новый стандарт.

cl-containers сделали, никто не использует.

Что как бы намекает на уровень нужности всей этой ботвы.

Как минимум, чтобы при добавлении записи в хэш проверялся тип ключа и значения

Это можно проверять и так, на уровне инстанса.

А ещё, чтобы можно было написать функцию, с разными телами для (hash integer t) и (hash string t)

Зачем? В динамическом языке это не требуется.

Например, https://docs.racket-lang.org/guide/classes.html

Т.е. язык ещё более маргинальный чем CL? Ну ок.

26.321 seconds of real time

Ну а что ты хотел? Ты ещё на try/catch подобный тест напиши, например для крестов, а потом плачь, что всё тормозит.

И как на базе try/finally сделать, например, редактор, который держит файлы открытыми пока открыты соответствующие окна?

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

Наследоваться от хеша? ВУТ? От массивов же наследоваться нельзя даже в какой-нибудь жабе или дуднете, по причинам производительности в том числе.

Такое ощущение что люди придумают какую-то хрень вместо того чтобы решать действительно важные проблемы. Вот например действительно важной проблемой CL является отсутствие асинхронного IO в стдлибе. Вот кто бы шелохнулся, нет, все передрачивают синтаксис и наследуются от хешей, блеать.

действительно важной проблемой CL является отсутствие асинхронного IO

А чем cl-async не хватает?

А чем cl-async не хватает?

Для начала - он прибит гвоздями к libuv.

Для начала - он прибит гвоздями к libuv.

Мне казалось, это наоборот достоинство

Вау, ты не выдержал! А ведь божился на мои посты не отвечать. Про before методы уже ответили в начале темы анонимусу. Ну и далее, не все функции, которые нужно декорировать - родовые. Я, например, сегодня декорировал ccl::%find-pkg .

Зачем? В динамическом языке это не требуется.

Ну ты уж не завирайся. CLOS тогда тоже не нужен.

Т.е. язык ещё более маргинальный чем CL?

Мне сдаётся, что Racket менее маргинален. Racket всё же (издалека) выглядит как живой организм. SBCL выглядит как гоночный автобиль - едет быстро, но механики должны в нём что-то подкручивать каждые 20 минут. Другие лиспы - как город, который полностью сгорел, но некоторые улицы отстроили заново. Или как кладбище. Хотя справедливости ради, лиспы сделаны из стали, а Racket - из пластмассы.

Ну а что ты хотел?

Он хотел, например, конкурентоспособности с голангом. А с такими бенчмарками даже нодка вас уделает.

Зачем он мне нужен, если всё это можно положить в обычный «нетипизированный» хэш?

А зачем типы полям структур? Они же в святой книге описаны. Святые отцы ошиблись?

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

И более того, я сделал вещь, которая нужна хотя бы мне. В целом, если в нескольких реализациях есть некая фича, которую их разработчики сочли нужной, то крайне глупо и неадекватно с вашей стороны оспаривать её нужность, и осуждать мою деятельность по написанию слоя переносимости. Во-первых, вы уже пытаетесь поставить себя выше разработчиков Allegro, CMU, CCL и LW, утверждая, что адвайсы не нужны. Во-вторых, совершенно очевидно, что слои переносимости нужны, например есть bordeaux-thread и CFFI. Нужно быть просто кончеными идиотами, чтобы отрицать нужность слоёв переносимости.

И вот, вместо того, чтобы прислать мне патч для LW или CLISP, вы меня осуждаете, вовлекаете в пустые дискуссии и тратите зря МОЁ драгоценное время (ваше мне не жалко). Давайте закончим вот на чём: то, что вы пишете - это полный бред. Я скажу вам словами Троцкого из кино: «вы все - импотенты» (т.е. не все, но понятно, кто).

Я вас покидаю, отписываюсь и на теме ставлю галочку.

Единственное, напоследок скажу, что мне пришло а утро в голову про const и unintern . В CL этому неудачно мешает то, что один символ может иметь много значений, например, может быть одноимённая константа и функция. Сделал unintern константе - функция отвалилась.

Вай, нехорошо.

Ладно, я пошёл дальше портировать clcon и яр на CCL. Вот сейчас пишу функцию holding-lock-p . Для SBCL и CCL знаю, как реализовать. Если у вас есть идеи по другим реализациям - шлите на мыло. В bt это нельзя писать, пока нет поддержки реализаций.

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