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

CLOS тогда тоже не нужен

CLOS нужен, делать hash(int,int) отдельным типом/классом от hash(int,string) - не нужно. Соответственно нет никакой нужды и в том, чтобы их различать в функциях и как-то по-разному с ними работать.

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

А в чём проблема? Корутины на евент-лупе и тредах в CL реализуются ничуть не хуже, чем в голанге. Всем известный пример https://github.com/fukamachi/woo. К слову сказать, тут как раз проблема асинхронщины встаёт в полный рост, потому что в данном случае человек запилил собственную реализацию над libev (ввиду того что cl-async тормоз), как итог пользоваться этим по факту довольно таки сложно.

Ладно, я пошёл дальше портировать clcon и яр на CCL

Если б ты всё то время, которое пилишь свой Яр (год? несколько лет?) потратил бы на то, чтобы запилить нормальную асинхронщину, т.е. не прибитую гвоздями к конкретной проблеме и библиотеке, а в виде интерфейса и «слоя переносимости» я б тебе в ноги поклонился. Даже помог бы чем смог.

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

Несколько лет тратить не буду, а несколько дней, возможно, потрачу в ближайшее время. Посмотрим, как пойдёт переход на CCL, и что там внутри у этого CCL.

Зайдя сюда через год ничего не поменялось.

Если сложить время, которое участники этой темы потратили на обсуждение, то

получится уже больше, чем я потратил на код

Не льсти себя себя словом «код». А «обсуждение» - кто-то троллит твой троллинг, кто-то дельные советы дает _другим заняться_, кто-то, не знаю зачем, по «твоей теме» что-то всерьез обсуждает.

Во-вторых, совершенно очевидно, что слои переносимости нужны, например есть bordeaux-thread и CFFI

С этим никто не спорит и все спокойно ими пользуются. А кто-то когда-то спокойно сделал эти compat layers.

И вот, вместо того, чтобы прислать мне патч

А кто ты такой?:) Хочешь делать свои слои переносимости, делай их спокойно на github и получай свои +2 stars за «актуальность».

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

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

Ладно, я пошёл дальше портировать clcon и яр на CCL. Вот сейчас пишу функцию holding-lock-p

Удачи тебе.

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

Emacs единственный пример и при этом уникальный. Полная ориентация на пользователя(программиста, хотя читал что писатели используют). Я без Emacs уже не могу. Это не фанатство, путь к освоению был связан с психологическими переживаниями, но изучив и освоив - без него не можешь. По аналогии с обучением игре на фортепиано(это не гитара с «аккордами в несколько букв»), поначалу всё выглядит примитивно.

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

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

Нет софта.

Emacs единственный пример

https://franz.com/success/ и это только ACL.

Я без Emacs уже не могу

Ну и дурак.

Лисперы всегда порываются писать библиотеки надеясь что это привлечёт авторов пользовательского софта.

Нет. Сугубо и тупо прагматичные цели. Бизнес. Производство. Библиотеки, если мы говорим про Common Lisp, и opensource, на 90% рождаются из практической необходимости и только ее. Никакое привлечение кого бы то ни было куда бы то ни было никому нафиг не сдалось. Имеешь мозг, глаза и уши - дальше сам.

Никакое привлечение кого бы то ни было куда бы то ни было никому нафиг не сдалось

И это то, что мне очень _нравится_ в CL :) Школота разбегается только шум стоит. Ни job offers, ни «батареек», ни stackoverflow на все случаи. Язык для идиотов старперов, не сомневайтесь. Вот и наш дорогой den73 убедительно показал многократно, что CL умер.

https://franz.com/success/ и это только ACL.

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

Никакое привлечение кого бы то ни было куда бы то ни было никому нафиг не сдалось.

Поддержание компиляторов такой сложности как в CL это задача для компаний заинтересованных в развитии, они должны получать прибыль связанную именно с этим направлением. Lispworks продаёт лицензии, регистрация в бизнес-инкубаторе колледжа Святого Джона в Кембридже. Не встречал ни одного имени за Lispworks, только зарегистрированная в Англии компания, а там это можно сделать за 25 минут.

Угу, а ещё вот такой вопрос: почему есть boundp, fbounpd и find-class, но нет стандартного способа узнать, определён ли тип с таким именем? Опять, в CL, видимо, всё в порядке. Ты, кстати, не ответил, почему типы в полях структур нужны, также есть тип (cons integer string) и типизированные массивы, а при этом типа (hash-table integer integer) нет. Это аномалия, но ты почему-то глядишь на неё как-то избирательно. Потому что иначе придётся признать что в лиспе всё же чего-то не достаёт или, наоборот, что-то лишнее.

Так вот я написал сегодня функцию для определения того, есть ли тип с таким именем, но она «не нужна», поэтому я её не буду публиковать :P

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

Делиться не надо. С говном сожрут. Будто ты не знаешь людскую натуру.

Извиняюсь за «дурака», ты кажется парень мыслящий, коих тут мало:)

Нет имён программистов. Они же должны пиарить себя усиленно.

Это вопрос взгляда на мир. Не должны :). Просто они стоят по главе компаний. Владельцы компаний и парни сами определяющие куда и зачем им идти. Paul Graham, основатели Franz (там несколько), Marc Battyani и другие. Задача «куда пойти работать программистом» у них не стоит :)

они должны получать прибыль

Про CL vendor-ов - если они существуют, они получают, не переживай за них. Время подумать про _свою_ прибыль :)

Не, тут другая ситуация. Делаешь вещи, которые точно нужны, и тебе начинают объяснять, что они не нужны. Вот и пытаешься понять, что всё это означает.

clcon теперь поддерживает ещё и CCL, уха-ха.

Не, тут другая ситуация. Делаешь вещи, которые точно нужны, и тебе начинают объяснять, что они не нужны. Вот и пытаешься понять, что всё это означает.

Именно это и означает. Лисперов устраивает лисп такой, какой он есть. И твои усовершенствования воспринимаются примерно как предложение сделать в Си++ мультиметоды и полнофункциональные (на самом Си++) макросы. Или написать на define'ах объектную систему в Си. Вроде круто, но пользоваться не хочется.

К слову, попытки внедрить CLOS в Scheme/Racket встречают такое же непонимание. У каждого языка есть своя ниша и прививка идей из других языков не будет одобрена теме, кого эта ниша устраивает.

Сейчас подумал, из-за чего непонимание. Видимо, из-за имиджа Лиспа, созданного Полом Грэмом в «Побеждая посредственность».

Если точнее, то вот цитата:

Что же в Lisp'е такого прекрасного? Если он такой замечательный, почему его не используют все? Казалось бы, риторические вопросы, но на самом деле на них есть прямые ответы. Lisp настолько хорош не тем, что в нем есть некое волшебное качество, видимое только его приверженцам, а тем, что он — самый мощный язык программирования из существующих.

И лисперы делятся на две категории. Тех, кому лисп нравится такой, какой есть (с отсутствием статической типизации, общим пространством имён методов для всех классов, отсутствием корутин и т.д.). На самом деле, очень мало задач требуют, чтобы это было и их почти всегда лучше решать на других языках. И тех, кто поверил в то, что лисп действительно «самый мощный язык программирования из существующих». Эти люди стараются добавить в лисп все возможности, которые есть хоть в одном другом языке, чтобы утверждение выполнялось.

P.S. Я ушёл на Racket именно потому, что сам отношусь ко второй категории.

1+

Мне кажется, категорий должно быть больше. Есть ещё дедушки, которые сидят на поддержке Legacy приложений. Legacy - оно и в африке Legacy, никто не собирается его поддерживать. Собственно, они и создают тот фон, что «лисп хорош таким, каков он есть». Потому что главный принцип при поддержке - ничего не трогать. Возможно, некоторые неокрепшие души воспринимают это как догму. Есть люди, которые начитались Грема, ткнулись в лисп, ничего не осилили и остались в некотором недоумении. Но не суть важно. Ну ладно, я уже поставил галочку, значит, надо и вправду завязывать :)

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

Дак а что ожидать от юзверей «самого лучшего в мире языка»(кстати, сам повелся на лиспы по этой причине).

Не парься, серьезно, ты и сам порой выглядишь весьма знатным троллем.

Ну, мне кажется, тут из троллей только анонимус. Быть агрессивным и быть троллем - это разные вещи всё-таки. Но я учту :)

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

Дак а что ожидать от юзверей «самого лучшего в мире языка»(кстати, сам повелся на лиспы по этой причине).

Тогда пошли на Racket. В нём есть всё, что есть в Common Lisp, а кроме этого корутины, продолжения, финалайзеры, эфемероны, модули, гигиенические макросы, статическая типизация (причём можно смешивать с динамической), ... И поддержка написания своих языков, если вдруг чего-то совсем не хватает.

Тогда пошли на Racket.

Я его даже потыкал палочкой, потом мне показалось, что живее всех тут Clojure. На нем хотя бы можно найти работу, даже в СПб.

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

написал сегодня функцию для определения того, есть ли тип с таким именем, но она «не нужна», поэтому я её не буду публиковать :P

Как же я жил без неё все эти годы.

почему типы в полях структур нужны, также есть тип (cons integer string) и типизированные массивы, а при этом типа (hash-table integer integer) нет

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

А вот для каких целей нужен (hash-table integer integer) для меня загадка. И мне не приходит на память ни один язык с динамическими типами, где был бы специальный типизированный хэш.

А типизированные хеш-таблицы - не быстрее и не компактнее нетипизированных? Лисповые массивы и структуры не годны для обмена данными с внешним миром, хотя бы потому, что в лиспе свой формат представления целых чисел, несовместимый с таковым для Си.

А типизированные хеш-таблицы - не быстрее и не компактнее нетипизированных?

А за счёт чего они будут быстрее и компактнее? Целочисленный массив - это штука которая поддерживается ЦПУ напрямую, а вот целочисленный (и вообще любой) хэш - нет.

хотя бы потому, что в лиспе свой формат представления целых чисел, несовместимый с таковым для Си.

Неужели? И что (unsigned-byte 8) несовместим? Или double-float несовместим?

А типизированные хеш-таблицы - не быстрее и не компактнее нетипизированных?

Очевидно, нет. Есть только один возможный случай, когда статика дает некоторые возможности для оптимизации, это когда типизированный ключ является value-типом, как в дотнете, за счет этого меньше разброс по памяти, большая локальность.

https://referencesource.microsoft.com/#mscorlib/system/collections/generic/di...

Но это только в дотнете и только для структурок. В остальных же случаях и в остальных языках, даже насмерть затипизированных, там обычные Object, то есть reference-типы. И виртуальные методы Equals и GetHashCode, и их аналоги, то есть статика не статика, разницы нет(надо сказать что CLOS-мультиметоды с одним параметром диспетчеризации и стандартным комбинатором довольном круто оптимизируются и от обычных виртуальных функций не слишком далеко уходят).

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

Лисповые массивы и структуры не годны для обмена данными с внешним миром

Во-первых, структуры почти нигде не годны, исключая структурки C#, а во-вторых, все же массивы определенных типов в ведущих реализациях - годны(в том же SBCL можно брать прямой указатель на данные).

А мне показалось, что ракетчики наоборот тащат в ракет всё, что гвоздями не прибито. Но с другой стороны, чем CLOS дополнит уже имеющуюся там объектную систему?

А мне показалось, что ракетчики наоборот тащат в ракет всё, что гвоздями не прибито.

В базовые тащат только то, что не нарушает целостность языка. CLOS противоречит идее единой точки ответственности за любую ошибку.

Но с другой стороны, чем CLOS дополнит уже имеющуюся там объектную систему?

Та объектная система не умеют мультиметоды. Потому что построена на модели обмена сообщениями. CLOS там есть и даже на типах, но крайне непопулярен. На github у swindle 3 звезды, у gls — 12. Для сравнения у racket-r7rs — 41.

CloZure CL самая приятная реализация. На Github, наверное можно предлагать pull requests.
Медленнее чем SBCL в 1.5~3 раза. Но есть много преимуществ.

Common Lisp проигрывает статической типизации и проверкам при компиляции ещё с самого создания стандарта.
Всё остальное нюансы.

Очевидно, нет. Есть

Двоемыслие.

И виртуальные методы Equals и GetHashCode,

Виртуальные методы, разрешимые статически в конкретное тело, могут инлайниться. А посмотри, к примеру, как устроен gethash в SBCL внутри. Там функция вычисления ключа вызывается с помощью funcall -а это гораздо дороже многих хеш-функций. При отсутствии системы типов исключить это нельзя. И похоже, что прехешированными символы быть не могут.

При отсутствии реальных примеров ботлнеков, у меня продолжать диалог желания нет. Это все плоды больного воображения, питаемые, видимо, дельфи-бекграундом и суровыми реалиями 20-летней давности.

Я лично вон недавно написал видеостриминг сервер на дотнете полностью, переписав с C++ почти все. И ничего, работает на отлично, тащит мегабиты. Думаю, на лиспе было бы так же примерно.

Еще недавно на эту тему как раз в одном чате доказывал что дрочево на лишние биты и лишнюю непрямую адресацию идиотизм и шизофрения.

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

Если не нужно быстродействие, то и CL вообще не нужен - достаточно tcl. В нём МП ещё мощнее, чем в CL и интроспекция богаче. А поскольку применение типов для безопасности уже было отвергнуто ранее, то с tcl вообще никаких проблем нет.

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

Думаю, на лиспе было бы так же примерно.

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

Где разница в быстродействии? Я не вижу доказательств. Без доказательств и конкретных примеров, никакой разницы нет.

Зато я могу вполне объективно утверждать, что на крупном масштабе, из-за дрочева на микрооптимизации и подобное, просирается как нормальная архитектура, так и нормальная алгоритмика, что нивелирует любые оптимизации вообще, и компиляторные, и прочие. Прекрасный пример подобного, который я не устаю приводить, это например, управление памятью в С++, которое якобы быстрее GC, а вот на практике, с тормозными «умными» указателями, атомарными операциями, разносящими кеш и шину памяти в пух и прах, нелокальностью памяти, дефрагментацией и прочими приколами - становится на порядок тормознее любого допотопного GC, а уж современного и умного, так и подавно.

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

Но есть GC, с поколениями, и так далее. Так что это довольно эфемерный плюс, учитывая что ни в одной мне известной программе работа с хешем не является ботлнеком(является много что, от преобразований кадров видео, до доступа к базе, и вообще IO, но вот уж хеши точно не являются ботлнеком).

Касательно инлайнинга. Во-первых, в том же дотнете - CLR никогда не инлайнит виртуальные методы, вообще совсем, включая GetHashCode. Во-вторых, любое вычисление хеша(кроме как от банального инта мб) занимает на порядок больше ресурсов, чем любой вызов метода. Во-третьих, если происходит агрессивный инлайн виртуальных методов, значит виртуальные методы нахрен не нужны в данном случае; архитектура говно, автор мудак.

Питон действительно подходит для многих вещей. И производительность действительно много где не нужна.

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

Я, в отличие от тебя, и высоконагруженные вещи писал, реально требующие производительности, и сравнивал .Net и CL, так что знаю, что говорю.

Достаточно того, что я у тебя нашёл двоемыслие. А именно, «улучшения производительности быть не может, за исключением одного примера». Ты же инженер, и должен понимать, что один контрпример ломает всю теорию. А у тебя получается «немножко беременна».

Когда я тебе говорю про инлайн, который в лиспе невозможен из-за отсутствия инфы о типах, ты говоришь мне про .Net, где его тоже, по твоим словам нет. А почему не про C++, где он есть? Стрёмно что ли с С++ сравнить? Далее ты выходишь на общие слова об умных указателях и заканчиваешь тем, что у тебя длиннее:

Я, в отличие от тебя...

Извини, это всё в сумме не выглядит убедительным ну никак, скорее выглядит так, что внутренне ты понимаешь, что CL тормозной, но боишься это осознать.

Но есть GC, с поколениями, и так далее.

Чтобы немного узнать о (негативном) влиянии GC на производительность хеш-таблиц в SBCL, изучи описание поля needs-rehash-p в хеш-таблице, и найди, где и как это поле используется. Здесь была тема несколько лет назад, где я это откопал и про это написал, но сейчас искать её лень.

И ещё одно, мне просто стыдно за вас с no-such-file, что вам надо такое объяснять. Ты хранишь в хеше, допустим, буквы. Достаёшь значение по ключу и записываешь в переменную типа «буква». При динамической типизации компилятор вставит проверку при присваивании, которую можно убрать только с помощью Safety 0. При статической проверка не нужна. Уж куда очевиднее, казалось бы? Но для вас и этого не существует. Пипец просто какой-то!

И это касается любых типизированных контейнеров, в т.ч. и массивов, для которых, кстати, есть такая прелесть, как upgraded-array-element-type - т.е. в плохих случаях даже для массива проверка типа в рантайме неустранима. В частности,

(upgraded-array-element-type 'cons)
T

То же касается заполнения хеш-таблицы.

Если кто-то говорит, что лисп «high performance», то все приведённые вещи являются однозначной целью для оптимизации, и если ты посмотришь в SBCL, то увидишь, что там повсеместно за такие оптимизации борются, повсеместно и агрессивно используют вывод типов и inline, выкидывают как можно больше веток в typecase статике. Т.е. то самое «дрочево на микрооптимизации», только его делает сам компилятор. И ты не хуже меня знаешь, что все примеры на «computer benchmark game» построены на статической типизации, и если её выкинуть, то производительность сразу грандиозно просядет. Ну вот что за детский сад тут происходит, вроде взрослые, опытные, компетентные люди, а такую хрень несёте!

И самое главное - ты написал свой видео-стриминг на дотнете, а не на CL. Что как раз лучше всего говорит о плачевном состоянии лиспового мира. Не смог продвинуть лисп заказчику-работдателю, да.

CloZure CL самая приятная реализация.

Да, вроде поприятнее. Сразу порадовало, что показывает реальное состояние тредов, а не всегда «running» как SBCL. Но посмотрим, как дальше пойдёт. Насчёт предлагать pull requests - вряд ли они заинтересованы в расширении языка. Но вроде у них (step) стоит в задачах - попробую запилить инструментирующий пошаговый отладчик - может быть, примут. Хотя опять же, с лиспом безнадёжно.

Насчёт статической типизации, в CMU/SBCL довольно много сделано по статической типизации - там есть и inline, и вывод типов (даже глобальный вроде бы есть в рамках модуля). Но остаётся такая особенность, как то, что для каждого объекта неявно написано volatile, поэтому лисп лишён возможностей для очень многих оптимизаций. Плюс вот это дерьмо с отсутствием типизированных контейнеров - неустранимые потери времени в рантайме (или void *). Далее, сборка мусора, двигающая объекты, лишает возможности идентифицировать объект своим адресом, далее нельзя представить 64-разрядное целое одним словом. Отсюда тормознутость SBCL в 1.5~3 раза по сравнению с С++. При том, что SBCL - это спортивная версия, где явно гонятся за скоростью.

И что (unsigned-byte 8) несовместим? Или double-float несовместим?

fixnum несовместим, я только это хотел сказать.

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

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

А твои любимые типы это классы и структуры.

Дальше просто вспомни что в лиспе динамическая типизация. И дальше - не хочешь срать - не мучай жопу, как говорится.

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

Все остальное решает (optimize (speed 3) (safety 0) (debug 0)) Жаловаться, что без этого хинта компилятору, что-то тормозит - как минимум шизофренично.

Дальше у тебя какой-то набор слов, как обычно, даже отвечать лень. Даже примеров ботлнеков не привел, опять какие-то отсылки на C++ и бенчмарки. Уровень 20-летнего студента, который еще отступы красиво расставлять не научился, зато знает что C++ это «риальне быстра и круто». Про C++ кстати уже говорил, что на реальных проектах, из-за экспоненциально растущей сложности и окостыливания кода на нем, его по производительности уделывает любая жаба.

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

при извлечении компилятор всё равно вставит проверку типа. И избежать этого опять же можно с помощью (safety 0),

Достаточно того, что я у тебя нашёл двоемыслие

Своё двоемыслие не пахнет?

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

А чего не займёшься то? Всего хватает?

CloZure CL самая приятная реализация. На Github, наверное можно предлагать pull requests.

Предлагать pull requests ты можешь в любой opensource lisp.

Не вижу в чем особенная «приятность» CCL, а после того как Gary Byers отошел от разработки по состоянию здоровья, вообще непонятно что будет с CCL.

Совершенно бесполезно им что-то объяснять. Схемеры, ракетчики и прочие алголоиды со скобками это непробиваемые шланги. У них инкрементальности и разработки в образе нет, лиспа как такового вообще нет, а они вечно готовы упарываться миллионами ненужных «фич», как монк выше показательно обрисовал. «Почему я выбрал Racket», или как недавно Fare со своим «Почему я выбрал Gerbil» - для меня диагноз - Вечный Нытик.

я потихоньку пилю свое clr, в планах запилить портабельный кодволкер на основе macroexpand-dammit, аналог тасков .net, и async/await поверх них

Дядька, я с тобой столкнулся не так давно и, честно говоря, далеко не сразу понял всю твою серьезность

Сильно. Рекомендую, пока не поздно, своим умом начать жить, книжек каких почитать, а то не ровен час в секту den74 вступишь. Ну и в церковь сходить )))

Я тебе уже говорил, что ты совершенно не понимаешь систему типов CL.

Ты телепат?

Своё двоемыслие не пахнет?

А у меня его нет.

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

Рекомендую, пока не поздно, своим умом начать жить

Вроде как и так живу своим умом.

а то не ровен час в секту den74

Врядли.

Ну и в церковь сходить

Воздержусь

Ладно, давай мы предположим на секунду, что у тебя длиннее. Хотя я, например, исправил https://bugs.launchpad.net/sbcl/ bug/1733622, которая идёт со времён CMU. Stassats сказал, что я там что-то «изуродовал» и патч мой не был принят, но я к этому всерьёз не отношусь, т.к. давно наблюдаю процесс поддержки SBCL. Во всяком случае, SBCL собирается, штатная тест-сюита проходят и бага не проявляется. Помимо этого, я сумел кое-как добавить иммутабельные хеш-таблицы в SBCL. Это тоже никому не нужно (в лиспе же всего хватает, да). Но мой форк умел ругатся во время компиляции при попытке осуществить запись в иммутабельную хеш-таблицу. При этом иммутабельная хеш-таблица имеет тип (and hash-table (mutable 0)), а мутабельная - (and hash-table (mutable 1)), соответственно, вывод типов может рассуждать о мутабельности. Что он не умел - так это корректно обрабатывать момент вызова freeze-object, при котором иммутабельная таблица превращается в мутабельную, поскольку в этом месте происходит небывалое - тип объекта меняется. Система вывода типов SBCL не заточена на такое, именно поэтому возникла та бага. Она наивно полагает, что (cons integer) всегда таковым и останется, и делает оптимизации (которые нельзя отключить, кстати) на базе этой информации. В этом и состоит смысл упомянутой баги. Чтобы решить вопрос с freeze-type, пришлось, бы по сути, перерабатывать вывод типов. Чтобы понять, как он сейчас работает, я решил вооружиться степпером, который в SBCL тоже хронически не работает. Я довольно много поправил в степпере и тут окончательно осознал, что SBCL вообще низкокачественный и что в нём придётся чинить не только вывод типов, а ещё и всё остальное, что команда ничего делать не будет (а на самом деле я могу только реализовать концепт, для доведения до настоящего качества моей квалификации не хватает, нужна помощь команды, а они меня послали) и что мне всё это в сумме на данный момент не потянуть.

Предположим, что ты более меняя преуспел в изучении начинки SBCL (который, кстати, не полностью соблюдает стандарт CL в плане declare и the).

Проблема в том, что слово lattice я не слышал со времён алгебры на мехмате. Поэтому, естественно, я не знаю, что в SBCL не lattice. Я сейчас посмотрел, что такое lattice и из определений я не смог заключить, каким образом в Дельфи Lattice. Но из этого отнюдь не следует, что я не понимаю SBCL - иначе я не смог бы сделать то, что я сделал.

То есть, я считаю, что я достаточно точно понимаю, что есть в системе типов (и в системе контроля типов, если тебе так угодно) CL, SBCL, что из этого мне годится, а чего не хватает.

И вот тут приходишь ты и говоришь, что я не понимаю. Давай, говори, что я конкретно не понимаю. Или это будет просто выглядеть как некий наброс на вентилятор (клевета). Впрочем, я на 95% уверен, что это оно и есть, но оставшиеся 5% стоят того, чтобы вот это написать.

Далее, то, что ты пишешь про оптимизации - в корне неверно. Либо какая-то система ставит целью быть high performance - тогда она должна ревностно относиться к любым случаям, когда другая система быстрее, добиваться своего преимущества и доказывать его. SBCL декларируется как high performance, и исключительно поэтому я обратил на него своё внимание. Если бы мне не нужно было performance, я бы уже давно его забыл как страшный сон.

В этом случае «я переписал с С++ на .net и наверняка на лиспе было бы не медленнее» совершенно никуда не годится как обоснование.

Если же система позиционируется как «пригодная для ваших целей», то тогда да, защитник этой системы имеет право спрашивать ботлнеки. Т.е. непонятно, почему я тебе должен что-то предъявлять - мне нужно high performance и SBCL декларируется как high performance. Знаешь ты это или нет, и как ты это не назови, но его performance базируется на выводе типов, на отсечении в рантайме истинных и ложных ветвей, на подстановке специализированных тел функций в зависимости от известных в статике типов аргументов, на вычислениях во время компиляции, на исключении динамических проверок типов, если соответствие типов доказано статически (и для этого вовсе не нужно safety 0). В этом контексте достаточно сказать «неустранимая проверка типов в рантайме», «невозмодно сделать inline из-за отсутствия информации о типах» и все всё сразу поймут. Ты не понимаешь - это вопрос к твоей квалификации, не к моей. Кроме того, предъявлять тебе всё равно нет смысла, поскольку даже свой CLR ты последний раз выкладывал 2 года назад, и практическая польза от тебя строго равна нулю. А я свой последний коммит лиспового кода сделал сегодня. Если я предъявлю, ты всё равно это не сможешь исправить. Я, например, точно знаю, что я могу в сжатые сроки (за несколько дней) сделать более быстрые типизированные хеш-таблицы для SBCL. Но не буду. Для CCL может быть и сделаю когда-нибудь.