Нужен ли кому-то Common Lisp в IDEA?

Потому что ничего и нет среди моего окружения ширпотреб-софта

fix. Ещё раз повторяю: только следование логике и осторожность в выражениях - иначе балабол.

покажи хоть что-нибудь внятное на Common Lisp

https://www.grammarly.com/

Потому что ничего и нет среди моего окружения ширпотреб-софта

Это ты про коллекцию в QuickLisp? :-) Так мне как-то всё равно какой там хлам :-) Просили показать реально полезный софт, а не намекать на какую-либо помойку :-)

fix. Ещё раз повторяю: только следование логике и осторожность в выражениях - иначе балабол.

Давай я за тебя уже отвечу, раз ты такой немощный :-) Всё, что есть в Лиспе, доступно в Quicklisp :-) Но ведь понятно же какой там софт :-) Вот и вся твоя логика :-) (ql:quickload 'hunchentoot) (droch-droch-eshe-raz-droch t) Лол :-)

Всё, что есть в Лиспе, доступно в Quicklisp :-)

Нда, вот тут смайлик по месту. Как насчёт

(ql:quickload :allegro-sources)

Создано, просто ты не про всё знаешь :)

Не томи уже смайлика! Или ваш пупер-энжин - такой большой секрет и подпадает под NDA?

Мне офтопики не нужны.

Т.е. эпических историй о взаимодействии с поставщиком коммерческого ПО не будет? Ну, я, в общем-то, и не сомневался.

Нужно. Для Clojure есть вот: https://cursive-ide.com

А почему бы это именно здесь и не узнать, в чем проблемы?

«Именно здесь» — это где?

Из

(defmacro defun* (fname arglist &body body)
  (safe-define 'defun fname arglist body))

и кода safe-define структура параметров никак не следует. А если брать формальную грамматику из комментария:

- FNAME :: either the name of the function to be created, or a list with the
  following grammar:
  : fname =   FUNCTION-NAME
  :         | (FUNCTION-NAME -> TYPE [assertion])
  : assertion =       FORM
  :                 | PREDICATE-SYMBOL
  Where:
  - =TYPE= is any valid type specifier
  - =FORM= is any form, which must return non-nil if the assertion is satisfied,
    nil otherwise. Within the form, the symbol =RESULT= is bound to the
    value that is about to be returned by the function.
  - =PREDICATE-SYMBOL= is a symbol, the name of a function that accepts a single
    argument. Equivalent to the form =(PREDICATE-SYMBOL RESULT)=.

    /Note:/ if the latter (list) form for fname is used, the =DEFUN*= body may
    /not/ also contain a =:returns= form. Also note that the latter form cannot
    currently be used when defining a =(setf ...)= function or method.
- ARGLIST :: a =DEFUN*= LAMBDA LIST, which uses the following grammar:
  : arglist =   var-term*
  :           | (var-term* [&optional opt-term+])
  :           | (var-term* [&key opt-term+])
  :           | (var-term* [&rest rest-term])
  : var-term =        VARNAME
  :                 | (VARNAME TYPE/CLASS [assertion])
  : rest-term =       VARNAME
  :                 | (VARNAME ELEMENT-TYPE)
  : opt-term =        VARNAME
  :                 | (var-term DEFAULT [SUPPLIEDP])

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

А тебя просят сказать наконец что ты пытаешься доказать своими исследованиями? Вот действительно если среди популярного ширпотреб-софта платформы SBCL нигде не видно ни в результирующих продуктах ни на каком-либо участке технологической цепи создания этого самого софта то какие выводы ты хочешь сделать? Что SBCL ущербен как инструмент?

и кода safe-define структура параметров никак не следует

А, ну если так, то да - ниче не узнаешь, надо иначе макрос писать изначально. Ну или залазить уже внутрь макроса средствами какого продвинутого лексера. Тривиально в общем конечно ничего не подсветишь.

По-хорошему, здесь необходимо вводить какие-то контракты. И проверять их на этапе компиляции :)

что ты пытаешься доказать своими исследованиями?
какие выводы ты хочешь сделать? Что SBCL ущербен как инструмент?

По факту имеется недружелюбное крохотное сообщество, которое гнушается любых инициатив :-) Можно сделать вывод, что сообщество лисперов изолировано от реалий сегодняшнего дня :-) OP, как я понял, хочет найти перспективное применение Лиспу, в которое можно инвестировать своё время с целью получить реальную прибыль - в деньгах, естественно :-) Но он не уверен, поэтому и спрашивает здесь о нужности той или иной своей идеи :-) Проблема в том, что ограничившись Лиспом с его обособленным сообществом, OP сам себе резко ограничивает возможные варианты найти востребованное направление :-) Что касается SBCL, то его было бы разумно рассматривать лишь как вспомогательный инструмент, не более того :-) И по этой причине, мне было интересна толкова поддержка взаимодействия IDEA с SBCL :-) Я бы такой модуль с удовольствием бы купил, если бы он того стоил :-) Но мне видится, что таких единицы, а потому OP вряд ли на этом заработает :-)

По факту имеется недружелюбное крохотное сообщество, которое гнушается любых инициатив

Это в каком виде гнушается? Каких инициатив?

Зарабатывать на этом модуле я не собираюсь.

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

В CL так не принято. Те, кто думает, что контракты и проверки при компиляции — это хорошо, ушли на диалекты Scheme (или в рамках CL используют defstar и прочую ересь). CL-щики за это говорят, что Scheme — это не Lisp, а Algol со скобками.

Я бы посмотрел на это.

Ну что, заинтересованность просматривается. Тогда следующий вопрос: есть ли желающие поучаствовать? На входе: у меня имеется опыт разработки IDE для лиспа на базе SWANK, морда на tcl/tk. Она умеет почти всё то же, что SLIME (во всяком случае. почти всё то же, что я знаю о возможностях SLIME). В т.е. имеется пошаговая отладка.

Т.е. со стороны CL эта задача точно решается и не слишком сложна. ВОпрос о стороне IDEA. Но судя по количеству плагинов, решение тоже существует :)

открываешь единственный вроде бы работающий плагин для лиспо-подобного языка и оказывается, что он написан на Kotlin, возникает некоторое раздражение

Почему?

Нипочему, просто подустал на тот момент. Из Котлина вроде Яву можно сделать путём пары кликов мышью.

Мне сказали, что дядечки-лисперы используют либо LispWorks (те, что посерьёзнее), либо Emacs (те, что попроще).

Так что даже не знаю.

Тут дело не столько в серьёзности, сколько в выборе реализации. В Lispworks своя среда, для остальных - Emacs. Но это не так-то просто в изучении и не всегда удобно. Пока продолжаю пилить свою среду clcon, правда она давно прибита гвоздями к моим библиотека, интерес сообщества к ней был нулевой, когда я её ещё пытался пиарить, так что это несущественно.