Вообще кто-то слышал, чтоб стандартизацией лиспа кто-то сейчас занимался?Вот недавно обновился С++, с 2003 года последний был. ANSI CL еще с 1994 года стандарт.
Поискал на забугорных форумах как-то глухо. У кого какие мысли и надо ли вообще?

Ситуация простая. Стандарт это дорого. В лиспе сейчас таких денег нет. 

archimag, есть же фирмы, которые активно используют данный язык : LispWorks, ребята из ClozureCL пишут компилятор и есть несколько проектов своих. В Бостоне и Нью-Йорке есть несколько стартапов, которые пишут финансовые приложения на CL. В последнее время наблюдаю тенденцию, что каждый пишет свой вариатив лиспа, вместо того чтобы продвигать одно общее направление. Нет так сказать лидера. Тот же Пол Грем, сейчас полностью занялся стартапами, были потуги у него с Arc, но развития особого не вижу. Есть новая Clojure (на базе jvm,чему я не очень рад, первые тесты языка были ужасны, сейчас лучше) которая поддерживается Google.
На самом деле язык толковый, если нет денег, то есть же Foundations всякие. Есть ощущение, что забили просто.Возникает вопрос можно ли например продвигать в ANSI новый стандарт находясь не в США ? =)) иди это опять свою вариацию напишешь,если нельзя. Печально вообщем...

Дело в том, что ANSI CL довольно удачный стандарт. На данный момент новый стандарт нужен, да. Но не особо - не до такой степени чтобы волноваться по этому поводу. Не много людей знают хорошо текущий стандарт и умеют им пользоваться. А чтобы создавать новый, надо по-хорошему (а по другому не нужно) - изучить разнообразные предложения и спорные моменты касающиеся текущего. А это очень большой объём работы, предполагающий к тому же, хорошее знание текущего стандарта. Из чистого энтузиазма это делать (и сделать) - желающих вроде бы нет. Дело с мёртвой точки, мог бы сдвинуть  какой-нибудь очень крутой и крайне удобный web-ресурс для совместной работы над новым стандартом. Но этого мало, необходимо чтобы чтобы это поддерживалось сообществом, основными конторами занимающимися CL ... думаю там полно нюансов набирается. Действительно, удовольствие дорогое.
Повторюсь: не так уж сильно он нужен, текущий стандарт + библиотеки-расширения (те что стандарт-де-факто) вполне себе удобно пользоваться. Вот что реально нужно для мира CL, так это: ЦЕНТРАЛИЗОВАНОЕ управление инфраструкторой.

Вряд ли кто-то будет писать новый стандарт или улучшения к старому. Как я понимаю, то неофициальная история гласит, что стандарт писали не для того чтобы он был, а из-за боязни потерять финансирование от разных источников. Вендоров разных лиспов было на то время много, языки отличались и вкладывать деньги в разные версии лиспов мало кто хотел. Поэтому вендоры пошли на общий знаменатель. Сейчас такой ситуации нет, а то что получилось много лет назад (стандарт в текущем виде) даже на данный момент perfect. Но еще раз, это мое неофициальное понимание того, как возник стандарт.
А вот что обсуждается в lisp community и есть подвижки (даже в финансовом плане как мне показалось), то это развитие библиотек и инфаструктуры вокруг них (quicklisp на данный момент).

> На самом деле язык толковый, если нет денег, то есть же Foundations всякие. Есть ощущение, что забили просто.
Не забили. Люди используют CL. Деньги есть, но они есть в проектах, в которых используют CL. Выделять те деньги под идею нового стандарда никто не будет. Под библиотеки похоже будут.
> Возникает вопрос можно ли например продвигать в ANSI новый стандарт находясь не в США ? =))
Ну... можно в теории. Но на практике, вряд ли, то есть нет. У меня сложилось впечатление, что российкое (коректнее сказать СНГовское) common lisp community живет отдельно от западного и американского. То есть там слышали что в СНГ есть лисперы и даже что-то делают классное (тот же порт sbcl под винду), но на этом все и заканчивается.

>Повторюсь: не так уж сильно он нужен, текущий стандарт + библиотеки-расширения (те что стандарт-де-факто) вполне себе удобно пользоваться.

На самом деле, новый стандарт очень сильно нужен, так как текущее положение довольно-таки мешает написанию либ. В принципе, был ряд попыток это сдвинуть (cltl3, cdr), но ни к чему они не привели.

Хорошо, я так понимаю, что все таки речь идет больше о схеме развития платформы, как в jvm. Наклепать библиотек и все хорошо. 
Осмелюсь заметить, что современные трендовые языки уже на протяжении 30 лет постепенно внедряют идеи взятые из ФП и в частности lisp. Представьте себе на минуту, что стандарт lisp обновляется так же как С# как язык и .Net платформа, каждые несколько лет толчек вперед. Я перешел на lisp из java около полугода назад, когда ушел с работы и неспешно искал новую. Скорость разработки одной и той же логики сравнима на порядок, на lisp в 8-10 раз быстрее чем на java, субъективное мнение естественно. Именно поэтому я задумался о новых стандартах языка, которые продолжали развитие. Конечно, можно исходить из логики "работает- не трогай", но почитав разную литературу по lisp понял, что язык постоянно эволюционировал, в отличие от костыльности других языков. Конечно для меня не последнюю роль играет личное самоудовлетворение, сделать за 2 дня, то что на java клепал бы неделю. Я не хочу сказать, что новый стандарт должен сделать одну функцию "решить задачу" и телепатировать ответ. Я скорее говорю про масштабность, насколько большие проекты можно покрывать небольшими командами используя lisp.
Интересен другой вопрос, насколько сообщество лисп сможет поддержать централизацию всего-того что уже есть, или опять нужно искать корпорацию гиганта? 

> Новый стандарт CL ?
Common Lisp'овский стандарт (язык + возможности) оказался очень удачным, должно хватить на десять лет еще. ;-)
единственное, что хотелось бы как уже сказали, хорошую централизованую инфраструктуру.
плюс, в новом стандарте, если бы такой и был создан, хотелось бы следующих плюшек по-мелочам (изкаропки):
* треды
* сеть
* MOP
* TCO(?)
* pattern-matching(?)
* больше стандартных ручек управления в GC
* более продуманную пакетную систему
* встроенный пролог
* задеприкейтить неиспользуемые формы/вызовы
Большинство из вышепeречисленного, уже есть в той или иной форме, поэтому в ближйшее время, вряд ли кто почешется.

> нужно искать корпорацию гиганта?
не помешала бы, как спонсор, но только с одним условием, чтобы не вмешивалась в стандарт.

ANSI CL закончен, и добавлять к нему уже нечего.
ISO ISLISP обновляли недавно.

elyadow,C++11x тогда нелепость, из вашей логики, и нужно было еще в 98м все закончить. Суть в том, что время не стоит на месте и появляются новые идеи и технологии, который могут занимать достойное место наряду со старыми. Честно говоря с ISLISP не разбирался, не встречал, на нем крупных проектов, по крайней мере, как я писал выше, мои знакомые в США пишут на CL.

Разве с 1994 года появились какие-то новые идеи и технологии?

ISLISP это совсем не CL. Вменяемых ISLISP реализаций тоже нет.

С тех пор мир вообще сильно изменился. 

Например?

> Например?
Например, стали популярны потоки и все возможные средства их синхронизации.
Или все эти Filenames дичайший анахронизм, который к современным реалям прикладывается через одно место. А Pretty Printer ещё и дичайший тормоз. Gray Streams вообще не стандартизованы, они правда на редкость унылы, но ничего другого взамен просто нет.
Стандарт CL мало того, что не доработан, так и ещё и сильным таким душком уже давно.

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

Не, ну описание семантики языка в многопоточном окружении как часть стандарта - это я еще могу понять, но сеть?Ну давайте еще функции для работы с HTTP в стандарт запихнем, да. И пролог, ггг, тоже круто будет.
Одна из проблем стандарта CL как стандарта языка программирования - как раз в том, что в него запихнули стандартную библиотеку.
А практически вся безнадежно, окончательно, и бесповоротно, устарела. Все  I/O, например, pathnames, "модули", и прочее, что было не таким уж плохим в 1994, все это сейчас вообще неадекватно реальности, и только занимает место в пакете #:common-lisp.
В стандарте языка должно быть описание примитивных типов языка, семантики, синтаксиса(в случае лиспа - описание интерфейса reader'a), объектной системы, системы неймспейсов(ну в случае CL - пакетов), системы обработки исключений, и для лиспа - интерфейса компилятора, но и всё. Немного про многопоточность и GC тоже можно включить, но не больше чем на уровне "В каком треде запускается GC - неизвестно, и запускается ли вообще - тоже".
ANSI CL как стандарт языка - отлично справляется со своей работой. Язык ни в коем случае не устарел, и наоборот даже впереди планеты всей. Ну да, даже пакеты - я считаю, лично, они вполне ок(не иерархические? Ну давайте им имена через точку(напр. #:my.package и #:my.package.subpackage), и ставьте :use первого в определении второго).
Другой вопрос в том, что CL это не столько язык, сколько виртуальная машина. И вот если уж описывать какой-то референс для этой машины, ее модель многопоточности, работу сборщика мусора, систему модулей, и стандартную библиотеку, то это нужно описывать либо в отдельном стандарте(как это для .NET CLI сделано, например), либо не описывать вообще, потому что всем возможным реализациям не угодить(ну запихнем мы в стандарт VM виндово-подобный GUI например - а как быть реализациям, запускающимся на голом железе или на мобилках? Запихнем требование реализации компилятора внутри рантайма - а как быть реализациям, встраиваемым через Си?).
Я думаю, пока у кого-нибудь не будет дохрена лишних денег на стандартизацию VM, то, ну не очень то она и нужна - просто выбирайте какую-то одну продвинутую реализацию(ну типа SBCL, или там, LW), и пишите под нее.

Pretty-printer как раз хорошая штука.Я им генерирую код на Си время от времени.
Тормоз - ну отключай когда не надо, и не используй - проблема то блин.

Я еще кое-что добавлю насчет например многопоточности в стандарте языка и так далее.
Вот посмотрите стандарты ECMA и спецификации MS касательно C#:
http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-334.pdf
http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=7029
Там практически _нихрена_ нет о многопоточности и прочем. О BCL тоже практически не слова.
Именно такими стандарты языков и должны быть.
А пихать в стандарт языка треды и "сеть" - это бред.

> Например, стали популярны потоки и все возможные средства их синхронизации.
Едва ли к CL можно приделать треды.
> Или все эти Filenames дичайший анахронизм, который к современным реалям прикладывается через одно место.
Прекрасно прикладывается, если не считать современными реалиями тупую конкатенацию компонентов.
> А Pretty Printer ещё и дичайший тормоз.
В 1994 году его посчитали приемлемо быстрым.
> Стандарт CL мало того, что не доработан, так и ещё и сильным таким душком уже давно.Демагогия.

> А пихать в стандарт языка треды и "сеть" - это бред.
Ну хорошо, в стандарт ЯЗЫКА не надо. Но хотя бы иметь какую нибудь "Standard Common Lisp Platform" (c), где были бы эти все средства "изкаропки" поддерживаемые всеми вендорами CL.

> поддерживаемые всеми вендорами CL
а не на стороне, в каком-нибудь репозитарии, забившего на него болт, разработчика

Стандарт CL как языка — более, чем good enough. Его итак менять то не смысла, а учитывая то, каких усилий это стоит — тем более.
Стандарт CL как платформы (всякие там pathnames, threads, sockets, streams и т.п.) — да, морально устарел. С другой стороны для меня вопросом является то, должно ли это входить в стандарт CL? Для прикладного программиста — это вообще (особо) не проблема, т.к. практически всегда можно полагаться на то, что предоставляет реализация. А у реализации и без стандарта есть стимул развиваться (наоброт, так даже проще).
Т.е. проблема есть только для тех, кто пишет библиотеки. Давайте посмотрим, как она решается. Как правило, несколько человек, которым это больше всего нужно (среди них обычно есть представители каких-то реализаций) договариваются о том, что им нужно. Примерно так появились bordeaux-threads, gray-streams и т.п. Или же просто кто-то пишет библиотеку, которая предоставляет усредненный интерфейс (usocket). Эти решения, в принципе, работают: например, hunchentoot вполне себе юзает bordeaux-threads и usocket, и никто не замечает из-за этого каких-то особых проблем. Т.е. суть не в формальном стандарте, а в стандартах де-факто. И чем обсуждать абстрактный стандарт в вакууме, лучше, по-моему, создавать такие мини-стандарты самим. Как, например, на ECLM Nikodemus Siivola и Stelian Ionescu обсуждали то, как забацать переносимый cl-posix. (Вот, кстати, Posix — тоже ведь во порядком устарел, а новый стандарт никто, вроде как, и не разрабатывает ;)

> hunchentoot вполне себе юзает bordeaux-threads и usocket, и никто не замечает из-за этого каких-то особых проблем. 
Ну, вообще говоря замечает, ибо на usocket современный веб-сервер не сделать ;)
> Posix — тоже ведь во порядком устарел, а новый стандарт никто, вроде как, и не разрабатывает
Posix как и CL делали на деньги американских военных . Времена изменились и больше вояки в такое дело денег не вкладывают.

> на ECLM Nikodemus Siivola и Stelian Ionescu обсуждали

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

Обсуждение было в баре.Видео будут, как смонтируем.Хороший отчет можно почитать тут: http://kvardek-du.kerno.org/2011/10/eclm-2011.html

> Хороший отчет можно почитать тут: http://kvardek-du.kerno.org/2011/10/eclm-2011.html
Уже :)
> Видео будут, как смонтируем.


Здорово!

> Я перешел на lisp из java около полугода назад, когда ушел с работы и неспешно искал новую.
Я тоже перешёл из java (в смысле окончательно). На Java, участвовал в разработке банковского софта для банка ВТБ.
> Скорость разработки одной и той же логики сравнима на порядок, на lisp в 8-10 раз быстрее чем на java, субъективное мнение естественно.
Не субъективное мнение, я тоже так считаю - на CL на порядок быстрее.
А по поводу стандарта: так модульно должно быть всё! Т.е. должен быть какой-нибудь cl-core lev.1, cl-core lev.2, cl-base, cl-stdlib, в таком духе. Ну для начала типа стандарты де-факто, да.