Синтаксис Lisp

АААААА!!!11 СКОБКЄЄЄ¡!!!11

скобки лучче

Так баян же:

Received: 2003/11/23
Draft: 2003/11/30-2004/01/28
Revised: 2005/05/29

А в PLT Scheme есть такая штука:

> Honu is a family of languages built on top of Scheme. Honu syntax resembles Java. 

Просто я как раз про такую штуку думал, когда нашел. Забавно.
Кроме того эта штука - просто другое представление s-expressions.
Она работает точно так же как и скобочки.

Если речь идёт про Scheme,то я не знаю - никогда ничего заметного не писал. Если речь идёт про CL, то я уже много раз писал, у него полно других проблем, кроме s-выражений. Но если уж бороться именно с синтаксисом, то нужен полноценный инфиксный синтаксис с операциями a.b.
В лиспе это вообще затруднительно, т.к. a.b - это идентификатор, равно как и a->b. Единственный не идентификатор - это a:b, но и здесь уже есть смысл - это символ b в пр-ве имён a. Если обобщить операцию ":" и на пр-ва имён тоже, тогда, может, ещё будет ничего.
Также есть другие проблемы синтаксиса лиспа:
1. разные виды биндингов создают лишние уровни вложенности. Например, let и flet - это две разные конструкции. Эта проблема решаема, гуглим c.l.l по словам budden и proga.
2. используются одинаковые скобки там, где в других языках используются разные. С одной стороны, это хорошо (скобки остаются свободными для DSL), с другой - основной язык становится трудночитаемым. Кроме того, всё равно далеко не уедешь: если захочется использовать два DSL, оба из которых переопределяют [], придётся что-то менять. Способа заставить их жить вместе нет. Хотя я на самом деле его (вроде) придумал, гуглим budden и cl-fix по c.l.l.
Если у меня всё правильно работает (вроде должно), то можно писать
dsl1:[] и dsl2:[], правда я сделал только основу для того, чтобы так можноб было писать, а примеров у меня нет, да и вообще там не всё гладко, поскольку внутри скобок будет временно изменён текущий пакет.

Если не пользоваться моим кодом, то поскольку всего есть не более 4 видов скобок, угловые скобки заняты под операторы сравнения и хочется что-то оставить для DSL, получается, что нет никакого выхода, кроме как использовать более длинные сочетания, чем односимвольные, где-то в синтаксисе.

Например, в программе относительно мало функций. Не было бы проблемы завершать defun словом end-defun (особенно, если бы редактор умел скакать от начала к концу и обратно). В Cl есть пример синтаксиса массива #(), который тоже более-менее пригоден (хотя на самом деле не особо).

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

И ещё один вариант - пользоваться специальными редакторами с подсвечиванием скобок. Хотя я не пользовался.

Просто перейти на отступы делает код более читаемым, но жонглировать в редакторе всё же гораздо удобнее с s-выражениями. Хотя, пожалуй, читаемость кода важнее, чем удобство его редактирования.

Много буков ниочем. Не надо бороться с синтаксисом. Не нравится - есть просто туева хуча языков с "более читабельным" (для сишника и прочих) синтаксисом. Отступы - такое же тупорылое решение как и обилие скобок, уже столько компий сломали на тему "Питон - говно ибо отступы не Ъ", ан нет лишь бы чужое обос**ть.

Извиняюсь за резкость, но уже надоело подтирать сопли пионэрам. 50 лет эту тему мусолят, но до сих пор находятся гениальные велосипедисты. Еще раз сорри.

>Отступы - такое же тупорылое решение

Отступы это способ гарантировать вменяемое форматирование кода.
Что ты нашел в них плохого?

Дык, эта... Тов. den73, вроде, пионером ещё во времеа СССР был...

> Просто перейти на отступы делает код более читаемым, но жонглировать в редакторе всё же гораздо удобнее с s-выражениями. Хотя, пожалуй, читаемость кода важнее, чем удобство его редактирования.

Emacs+slime делает форматирование отступами (можно и во время набора текста программы), и в то же время позволяет по sexp'ам бегать распальцовками.

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

> Emacs+slime делает форматирование отступами
> (можно и во время набора
> текста программы), и в то же время позволяет
> по sexp'ам бегатьраспальцовками.
Ну я, в общем, так и живу. Облом наступает при попытке набить s-выражение в форуме или нарисовать на бумажке. При рисовании четырёх и более закрывающих смайликов ошибка почти гарантирована )))))

> Извиняюсь за резкость
Мог бы просто сэкономить немного букв :)

> Не надо бороться с синтаксисом.
На самом деле, такие свойства, как выразительность и удобочитаемость языка достаточно объективны и могут быть формализованы. То, что лисп слил пользователей при своём прекрасном дизайне и богатом наследии, имеет какие-то объективные причины, независимо от наших предпочтений. Конечно, задним числом можно подогнать под свершившийся факт всё, что угодно, но здесь, как раз, всё сходится: объективные критерии удобочитаемости в случае лиспа не выполнены. Назову три, хотя и в неформальном виде.

1. В хорошем языке имеется система "вех", за которые глазу удобно цепляться. В реальности, лисповый текст удобно читать _только_ тогда, когда он отформатирован с отступами, иначе вехи теряются и остаётся только лес из скобок. Т.е., в лиспе отступы и так по факту используются. В сях и прочем есть альтернативные круглым скобкам вехи, поэтому там ситуация менее драматична, хотя текст с непривычно расставленными {} тоже читать поначалу тяжело и это занятие может довести до белого каления.
2. Не должно быть заведомо лишних сущностей. В С++ переменная видна от области определения до конца блока. Блоки обычно достаточно малы. В лиспе нужно писать let и flet, увеличивая глубину вложенности слишком часто.
3. Должен соблюдаться стиль. Одно из свойств стиля в человеческих языках - не повторение одного и того же слова слишком часто. Здесь сливает уже контекстно-независимое именование сущностей в лиспе. В выражении
(let ((h (make-hash-table ...)))
(setf (gethash h 3) 4))

слово hash употреблено два раза. Хотя должно быть употреблено только один (при создании), а обращение должно быть через слово get. Здесь лучшие, чем лисп, языки, помогают за счёт того, что помнят контекст, либо ценой статической типизации, либо ценой дополнительных тормозов.

В CL и Scheme оба пути тернисты.

Вот. Совокупность трёх этих вещей, с моей точки зрения, и отправила лисп на помойку, несмотря на все положительные стороны.

>1. В хорошем языке имеется система "вех", за которые глазу удобно цепляться. В реальности, лисповый текст удобно читать _только_ тогда, когда он отформатирован с отступами, иначе вехи теряются и остаётся только лес из скобок. Т.е., в лиспе отступы и так по факту используются. В сях и прочем есть альтернативные круглым скобкам вехи, поэтому там ситуация менее драматична, хотя текст с непривычно расставленными {} тоже читать поначалу тяжело и это занятие может довести до белого каления.

честно говоря я пока невидел ниодного языка, код на котором был бы читаемым без человеческого форматирования

>2. Не должно быть заведомо лишних сущностей. В С++ переменная видна от области определения до конца блока. Блоки обычно достаточно малы. В лиспе нужно писать let и flet, увеличивая глубину вложенности слишком часто.

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

1]
форматирование нужно почти всегда.
по этому полезно сделать его частью синтаксиса.
2]
можно убрать отступ после let. получится объявление переменных ала C

>и отправила лисп на помойку,

>Oh, my! I've never heard that before! Dying? When? Have you
informed the others?
>Good grief. Lisp has been "dying" for over 50 years, now, despite the
fact that it is growing. Get a clue.
>As for lisp being ok, do you really think we would have these
discussions if we didn't think there could be improvements? Do you
really think we would be putting out new modules, some completely open-
source, if we didn't want users to accept them and to put pressure on
other lisp vendors to implement the necessary changes?
>Your penchant for spreading FUD is truly amazing.

>> Отступы это способ гарантировать вменяемое форматирование кода. Что ты нашел в них плохого?

Я - ничего. Тут как заведено: обсуждаем Питон, начинаются возгласы, что принудительное форматирование кода не Ъ, т.к. можно форматировать табами и пробелами, а потом если над одним куском кода поработают несколько программистов со своими мнеинями об "эстетике", то в конце концов получается некомпилируемый код, ибо нету скобок, обсуждаем Лисп - скобки это зло, надо все зарулить в 2-мерный синтаксис без скобок. Еще не хватает завалинки и семечек :)

>> 1. В хорошем языке имеется система "вех", за которые глазу удобно цепляться. В реальности, лисповый текст удобно читать _только_ тогда, когда он отформатирован

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

>> В С++ переменная видна от области определения до конца блока. Блоки обычно достаточно малы. В лиспе нужно писать let и flet, увеличивая глубину вложенности слишком часто.

Это с пол пинка решается макросами. Чего не скажешь о сях :))

>> Должен соблюдаться стиль. Одно из свойств стиля в человеческих языках - не повторение одного и того же слова слишком часто [...]

Кхм... Ну ты даешь... Т.е. ты хочешь сказать, что в лиспе нет ООП и перегруженных методов? Это новость!

>Oh, my! I've never heard that before! Dying? When? Have you
informed the others?
Это видимо написал kt. Но он сейчас зарабатывает деньги javaScript-ом, что и служит наилучшей иллюстрацией к теме.
То, что лисп умирает, вполне очевидно при сравнении интенсивности и перечня обсуждаемых тем в c.l.l с аналогичными форумами по clojure, питону или даже boo.

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

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

> Это с пол пинка решается макросами. Чего не скажешь о сях :))
Ну я для себя решил, вот, уже постил здесь когда-то:
(proga
 (flet foo (arg) (list arg))
 (let bar (foo 1))
 (macrolet a-foo (foo bar))
 (cons a-foo bar) 
 )
вместо 
(flet ((foo (arg) (list arg))))
 (let ((bar (foo 1)))
  (macrolet ((a-foo (foo-bar)))
   (cons a-foo bar))))

Однако для полноценной реализации нужно писать целый code walker, т.к. внутри cond я пока что не могу использовать такой синтаксис. И на c.l.l только один человек отозвался об этом хорошо, а остальные - плохо. Мне, в принципе, по барабану, что думают на c.l.l, т.к. я не вижу реальной поддержки от сообщества в виде зрелых, надёжных и документированных библиотек (только море прототипов) и поэтому я собираюсь попробовать питон. 

> Кхм... Ну ты даешь... Т.е. ты хочешь сказать, что в лиспе нет ООП и перегруженных методов? Это новость!
Перегруженных методов в лиспе действительно нет - сигнатура должна быть одинаковой. Невозможно определить метод cl:get, который бы годился на все случаи жизни и в то же время проверял параметры. В С++ я могу использовать одно и то же слово get, т.к. каждый класс создаёт своё виртуальное пр-во имён. В лиспе я мог бы писать my-package:get. Но тогда на всю оставшуюся жизнь гарантирован гемор с конструированием новых пакетов. Кроме того, понадобится часто повторять слово my-package (заметим, что в лиспе нет и питоновского import as, поэтому нельзя сделать локальные и короткие псевдонимы для слова my-package). В итоге, остаётся следовать возможному пути. И писать gethash и т.п., хотя на самом деле, смысл конкретного get и его параметры в половине случаев определяются типом первого аргумента. Что и есть повторение слова. 

Далее, родовые функции намного медленнее обычных и это часто бывает существенно. И наконец, gethash уже есть в стандарте. Что, писать своё поверх существущего? А смысл существования языка тогда в чём?

Хотя нет, похоже, что это написал не kt. Не помню, кто.

>> Перегруженных методов в лиспе действительно нет - сигнатура должна быть одинаковой. Невозможно определить метод cl:get, который бы годился на все случаи жизни и в то же время проверял параметры

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

(defmethod beat ((drum snare-drum) (stick wooden-drumstick)) ...)
(defmethod beat ((drum snare-drum) (stick brush)) ...)
(defmethod beat ((drum snare-drum) (stick soft-mallet)) ...)
(defmethod beat ((drum tom-tom) (stick wooden-drumstick)) ...)
(defmethod beat ((drum tom-tom) (stick brush)) ...)
(defmethod beat ((drum tom-tom) (stick soft-mallet)) ...)

И где тут одинаковая сигнатура?

>> В С++ я могу использовать одно и то же слово get, т.к. каждый класс создаёт своё виртуальное пр-во имён. В лиспе я мог бы писать my-package:get. Но тогда на всю оставшуюся жизнь гарантирован гемор с конструированием новых пакетов

А не надо так писать. Достаточно параметризовать get с аргументом нового типа и не важно в каком пакете он сидит.

>> И наконец, gethash уже есть в стандарте. Что, писать своё поверх существущего? А смысл существования языка тогда в чём?

Мы говорим о лиспе или о реализации ООП в нем? gethash - это не метод. Почему не возникает вопросов по поводу GTK-ных километровых названий функций? gethash - это неизбежный продукт процедурного программирования. В сях то поди для работы с хеш-таблицами тоже есть набор функций с уникальными именами? а?

заметим, что в лиспе нет и питоновского import as, поэтому нельзя сделать локальные и короткие псевдонимы для слова my-package

rename-package?

>Но он сейчас зарабатывает деньги javaScript-ом, что и служит наилучшей иллюстрацией к теме.
Ну да, да. "My hair is a bird, your argument is invalid"

btw:
duane at franz dot com

>вполне очевидно
Кому очевидно? Может это у кого-то просто галлюцинации?

> Облом наступает при попытке набить s-выражение в форуме или нарисовать на бумажке

У нас когда на доске нужно было написать код на лиспе просто
нумеровали скобочки (открывающие — по возрастанию,
закрывающие — по убыванию от последней открытой) под строками.

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

Перегрузка идет по параметрам диспатча. Статической перегрузки нет потому, что типизация динамическая, и типы как бы неизвестны при компиляции. На самом деле, такая ошибка, попытка замены статической перегрузкой диспатчем, возникает у многих. Но это концептуально разные вещи. Сигнатура, вне параметров диспетчеризации, может меняться(т.е. - у методов с разными аргументами - разная). Например, при определении обобщенной функции указать &key, а в методах определять конкретные именованные параметры. И использовать один из аргументов диспетчеризации для указания действия.

>Невозможно определить метод cl:get, который бы годился на все случаи жизни и в то же время проверял параметры. В С++ я могу использовать одно и то же слово get, т.к. каждый класс создаёт своё виртуальное пр-во имён.

В CL у классов нет методов. Тут _по-другому_. В стиле C++ или Си, или Жабы какой-нибудь, на лиспе писать хреново, да. Аналогично и на этих языках в лисповском стиле(вспоминаем, какое нечитаемое говно представляет из себя код, автор которого пытается заняться метапрограммированием на шаблонах). Вот это просто надо понять. Ты пытаешься использовать обобщенные функции как методы классов(переписываешь код с жабы/плюсов?). На них надо смотреть по другому - как на объекты, управляющие взаимодействием.
А get можно написать так:

(defgeneric u-get (source &rest args))

(defmethod u-get ((source hash-table) &key key)  
  (gethash key source))

(defmethod u-get ((source list) &key (type :list) key test)
  (case type
    (:list (check-type key integer)
           (elt source key))
    (:plist (getf source key))
    (:alist (assoc key source :test (or test #'eql)))))

(defmethod u-get ((source array) &rest subscripts)
  (apply #'aref source subscripts))

(и соответствующий u-set или (setf u-get))

>В лиспе я мог бы писать my-package:get. Но тогда на всю оставшуюся жизнь гарантирован гемор с конструированием новых пакетов. 

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

>Кроме того, понадобится часто повторять слово my-package (заметим, что в лиспе нет и питоновского import as, поэтому нельзя сделать локальные и короткие псевдонимы для слова my-package)

(setf (symbol-function 'my.get) #'my-package:get)
(setf (symbol-function 'another.get) #'another-package:get)

> rename-package?
Хочешь стать жонглёром - стань им. Я не хочу.

> стиле C++ или Си, или Жабы какой-нибудь, на лиспе писать хреново, да.
Ага. И по моим наблюдениям, в большинстве случаев стиль С++ или Жабы в этом отношении лучше, да.

> Сигнатура, вне параметров диспетчеризации, может меняться(т.е. - у методов с разными аргументами - разная). Например, при определении обобщенной функции указать &key, а в методах определять конкретные именованные параметры
ИМХО это всё же одинаковая сигнатура. И, кроме того:

1. Кто-то мог занять имя get до тебя и иметь своё мнение на счёт параметров. Я сталкивался с ситуацией, когда была занята функция add. Ты предлагаешь патчить/форкать всё подряд?

2. Просто &key лишает тебя предупреждения компилятора о неправильно применённом ключевом слове. Мне лично эта подсказка полезна и нужна. Кроме того, мне полезно и увидеть возможные ключевые слова в строке статуса. Этого я тоже лишаюсь. Мне множественная диспетчеризация нужна на порядок меньше, чем вот эти "мелочи", из которых и состоит наше ремесло. И если бы её не было, её можно было бы макрами накрутить. А то, что я хочу, никак не сделаешь в рамках CLOS (или я всё ещё не понимаю).

> (defgeneric u-get (source &rest args))
Те же проблемы.

> (setf (symbol-function 'my.get) #'my-package:get)
Это стрёмно и вообще неправильно. Во-первых, я не найду определения my.get, нажав M-. Во-вторых, где разместить этот setf? В-третьих, при перекомпиляции my-package:get нужно не забыть выполнить setf повторно. В четвёртых, что, если это не функция, а макрос? Не сломается ли code walker, выискивающий my-package:get по eq? В пятых, не пойдёт ли лесом inline?

Так что ты предлагаешь хак, от которого будут побочные эффекты. Правильное решение - это иметь псевдонимы пакетов, как в питоне. В CL есть псевдонимы, но они глобальны (и это - тупость).

> Мы говорим о лиспе или о реализации ООП в нем? gethash - это не метод. > Почему не возникает вопросов по поводу GTK-ных километровых названий
> функций? gethash - это неизбежный продукт процедурного
> программирования. В сях то поди для работы с хеш-таблицами тоже есть
> набор функций с уникальными именами? а?
Ну вот, а в С++, жабе и питоне hash.get - это метод, причём он может быть и не виртуальным. Т.е., процедурная скорость при объектно-ориентированной выразительности. С в этом отношении - не пример для подражания.

> (defmethod beat ...)
Ну она одинаковая (конгруэнтная). Отличаются только типы. В С++ может отличаться количество обязательных параметров.

Только я прошу понять - я не агитирую за С++. Я скорее акцентируюсь на недостатках лиспа в его существующем виде.

Возможно я чего-то не понимаю, но вот смотрю я на
http://clojure.org/java_interop
и гляжу как там мапится джава синтаксис в лисповый,
и мне кажется что вполне неплохо ложится, если считать s-expr
самоцелью.
Искренне не понимаю посему не сделать эквивалентные макры для CLOS.

>> стиле C++ или Си, или Жабы какой-нибудь, на лиспе писать хреново, да.

> Ага. И по моим наблюдениям, в большинстве случаев стиль С++ или Жабы в этом отношении лучше, да.

Я бы рассмотрел вопрос совсем в другом ключе и выкинул слово "стиль" как неправильное. Речь идет об инструменте. Имеется инструмент 1 "выбор функции на этапе исполнения" и при этом он не делает ненужным инструмент 2 "выбор функции на этапе компиляции". Хотя в принципе, казалось бы, можно обойтись И1 без И2 в языке, но часты случаи, когда это усложняет код.

Да кстати, этот И2 по-идее должно предоставлять Qi, нет?

> Возможно я чего-то не понимаю, но вот смотрю я на
> http://clojure.org/java_interop
> и гляжу как там мапится джава синтаксис в лисповый
Конкретно этот синтаксис не получится использовать, т.к. нужно сильно менять ридер. Кроме того, суть проблемы-то как раз в том, что методы не принадлежат классам в лиспе. Т.е., в Яве и С++, говоря "hash", мы сразу вводим в контекст исходника все методы, принадлежащие именно этому классу. В лиспе вместо этого у нас есть просто "слова", и нет контекста.
Слова можно организовывать только в пространства имён (package). Наличие контекста автоматически делает запись лаконичной, но читателю нужно зарезервировать место в стеке своего мозга, чтобы помнить контекст.

Вообще говоря, спорно, что лучше, контекст или без контекста. Но, имхо, человек рассчитан на чтение текстов с контекстом. Когда человек читает C++, он использует свой стек контекста, как надо. Когда человек читает лисп, то стек пылится без дела, зато глаза перенапрягаются, гребя по строчкам повторяющихся слов.

Но я отвлёкся. Именно безконтекстность лиспа делает такой синтаксис для лиспа безсмыслленным. Как минимум, для того, чтобы сделать такой синтаксис, нужна другая система ООП для лиспа, в которой методы принадлежали бы типам. Сделать простое ООП по типу С++/Java - совсем не сложно (я думаю, это уложится килобайт в 50), но дальше возникает вопрос отторжения культурным сообществом - лисперы скажут, что CLOS - это правильно.

Хммм... Ну отсылка к clojure была именно с целью показать пример
синтаксиса без избыточности описаний.
Насчет контекста... Не готов сходу ответить, кажется ли мне это
необходимым, но если взглянуть на мир так: каждый метод возвращает
что-либо, как правило себя. А последующие функции получают его первым
аргументом за счет макросов a-la clojure.
Типа
(. obj (meth1 param) (meth2 param))
Где . макра генерящая
(setf val1 obj)
(setf val1 (meth1 val1 param))
(setf val1 (meth2 val1 param))
(Да я знаю про let, gensym и т.д - этот код just to describe the idea)
Вопрос только с возвращаемыми значениями.
Но вобщем из всех вышеперечисленных проблем, мне кажется реальной,
только отсутствие возможности создания методов с разной сигнатурой.

А вообще, вдруг стало интересно, а зачем именно джавовскую объектную
модель использовать в лиспе? Для взаимодействия с не лисп-ооп-кодом
в едином стиле? Может разумнее враппер в лисп стайл сделать?

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

> Вообще говоря, спорно, что лучше, контекст или без контекста. Но, имхо, человек рассчитан на чтение текстов с контекстом. Когда человек читает C++, он использует свой стек контекста, как надо. Когда человек читает лисп, то стек пылится без дела, зато глаза перенапрягаются, гребя по строчкам повторяющихся слов.

Такое тоже бывает, но я опять не соглашусь со словом "контекст".

Вместо него -- "ненужная деталь реализации".

Когда мы пишем a=b[c], то нас не волнует что такое b -- хэш, или может интерфейс к базе данных, или это может вылиться в доступ по сети, или локальному пользователю будет предложено вставить ДВД номер 5 с бэкапом, или даже b[c] может быть просто-напросто перевычеслено второй раз (и ничем практически не отличаться от b(c), хотя смысл в квадратных скобках какой-то должен быть)

Да, а насчет переделывания reader-а я не совсем осознал проблему...
Ну да если именно точку использовать - может и не очень, но ИМХО,
(with_object obj (meth)) не сильно страшно.

> А вообще, вдруг стало интересно, а зачем именно джавовскую объектную модель использовать в лиспе?

Насколько я понял, ден73 предлагает отнюдь не явовскую объектную модель (т.к. у явы нет невиртуальных функций).

Давайте различать объектную модель и разрешение имен.

>(with_object obj (meth))
а имхо это настолько страшнее
obj.meth(), что такой язык хочется сразу отправить на помойку.
Точка бы ещё куда не шла, но увы... Вряд ли можно переносимо
задействовать любой односимвольный идентификатор под это дело.
Хотя можно и забить на переносимость.

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

> Насколько я понял, ден73 предлагает отнюдь не явовскую объектную
> модель (т.к. у явы нет невиртуальных функций)
Я не особо знаю Яву (и не знал, что там всё так плохо :)

В общем, да, речь идёт именно о разрешении имён. Я очень долго был противником ООП, т.к. реализованная в С++ и Яве (насколько я её знаю) модель ООП слишком ограничена и кажется надуманной. МП, конечно, мощнее как средство построения абстракций. Но наконец-то я понял, что именно
организация сущностей в контексты даёт силу С++. При этом, весьма помогает и статическая типизация, хотя это уже несколько другая тема.
Опять же, если речь идёт о хеше, то мы не пишем каждый раз слово hash и при этом имеем быстрый доступ только потому, что у нас уже однократно объявлено, что это - хеш.

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

С моей точки зрения, лисп сегодня - это всё же хорошая платформа.

Кстати, вот тут вышел ccl 1.3, который, как заверяют авторы, работает и под win32. Это очень хорошая новость. Похоже, что мы, наконец, имеем open-source реализацию Common Lisp с тредами под win32 (clisp я не считаю, т.к. он тормозной). При этом, ccl написан гораздо культурнее Sbcl (лучше соблюдает стандарт и вроде бы меньше багов), у него компилятор быстрее в разы, код он генерит несколько послабее чем sbcl, но всем питонам с руби до CCL далеко, конечно. Также ccl компактнее sbcl.

>Да кстати, этот И2 по-идее должно предоставлять Qi, нет?
Qi - это совсем другой язык поверх лиспа, мне не особо интересно.

> Вобщем, буду искренне благодарен за кусок кода демонстрирующий
необходимость именно джава стиля ооп, и не являющегося притягиванием
за уши чуждой идеологии, как метапрограммирование в с++.
Да речь не идёт о необходимости. Речь идёт лишь об удобстве. Ценой многократного повторения скобок и лишних слов всё то же самое можно написать в лиспе. Потом кое-где срезать путь макросами. Но удобство тоже много значит, если мы хотим получать удовольствие.

Ну как бы, это индивидуально. Точка конечно красивее.
Но вон в clojure и .. используется. Так что и 2-хсимвольный
идентификатор вроде не смертельно. Но я вобщем то даже не об этом.
ИМХО длинна идентификатора, это проблема эстетического плана.
А вот проблема сигнатур - уже плана функциональности.
Мне бы просто хотелось в идеале увидеть список претензий,
разделенный на функционал и эстетику, и понять что этот функционал даст.
Просто ИМХО если он даст полезные возможности - а единственные минусы,
это неэстетичность в сейчашних реализациях лисп. То почему не забить
на тех кого устраивает уже существующее и не сделать свое.
Где все будет красиво и эстетично.
Тем более, что Вы говорили что это вроде все излечимо.
Вон clojure делает свое дело и живет хотя не CL и newlisp живет
как-то.

>В пятых, не пойдёт ли лесом inline?

Несколько лет назад в русской эхе по лиспу мне предлагали "кошерное" решение.

>В общем, чёта мне поднадоела эта тема. Мне кажется, я сказал всё,
>что хотел: проблемы с синтаксисом лиспа - это далеко не только s-
>выражения, да и не столько они. Проблемы носят комплексный характер
>и одной заменой s-выражений на отступы ничего не добиться.

Ну коли умудрились прославиться как знаток и почти единственный
практический пользователь лиспа на ЛОР, прийдется расплачиваться.
Автографы там, футболки с портетами, подписи на книгах
"Чем неудобен Лисп" собственного авторства. :)

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

>Да речь не идёт о необходимости. Речь идёт лишь об удобстве. Ценой
>многократного повторения скобок и лишних слов всё то же самое можно
>написать в лиспе. Потом кое-где срезать путь макросами. Но удобство
>тоже много значит, если мы хотим получать удовольствие.
Видимо Вы меня неверно поняли. То же и на асемблере написать можно и
на брэйнфаке. Я не об этом. Просто для многих задач, в разных языках подходят разные средства. Можно и в функциональных императив писать,
но неудобно. Вот я и хочу пример, чтобы я мог понять, неудобно это,
или просто это не надо так делать.

>Кстати, вот тут вышел ccl 1.3, который, как заверяют авторы, работает и под win32...

У него там полная ж... с "интернационализацией". А заниматься этим по второму кругу у меня нет ни малейшего желания. Тем более что судя по постам в эхе "нижняя" часть у него на с++ (у sbcl на с), и её там на много больше.

Плюс явно проигрывает в получаемом двоичном коде.

Допилят интернационализацию - поковыряю ещё.

> Вон clojure делает свое дело и живет
clojure заморочено на ФП. Боюсь, скоро здесь будут вопросы типа "двухсвязный список в clojure".

>Мне бы просто хотелось в идеале увидеть список претензий,
>разделенный на функционал и эстетику, и понять что этот функционал >даст.
Да в любой тьюринг-полной системе можно делать что угодно. В лиспе - ещё и в динамике. Список претензий к лиспу я уже публиковал неоднократно, см. поиск по моему имени.

Можно же и с другой стороны подойти. Что есть в лиспе такого, чего нет в других языках? Ответ - почти ничего. Главная сила - это МП, но МП можно делать и на уровне текста с помощью того же m4. Есть примеры метапрограмм: yacc, make, autoconf. И все они написаны не на лиспе.
Другая сила - динамизм, но и это в других языках, в принципе, достижимо. REPL - да, хорошо, но тоже есть в некоторых других языках.
Конечно, тут ускользает то, что все эти вещи очень разумно взаимосвязаны. Но похоже, что с помощью грубой силы в других языках тоже достигнут подобный уровень практичности для МП (вот ознакомлюсь с easyExtend - скажу, так ли это для питона).

Значит, при условии свободного выбора, можно опираться не только на функционал, но и на удобство (я надеюсь, что моё мировосприятие достаточно целостно и поэтому удобство - это примерно то же, что и эстетика) и на наличие библиотек. Здесь лисп не особо силён.

> То почему не забить на тех кого устраивает уже существующее и не сделать свое. Где все будет красиво и эстетично.

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

>То почему не забить
на тех кого устраивает уже существующее и не сделать свое.

Для "себя любимого" можно. Но "начитавшись" пакетов для CL, вроде даже полезных, в которых некоторые авторы сначала лепят "тулс", в котором помимо чего-то полезного куча "мелочи" а-ля "if" с "else", и тебе действительно приходится "сурово" перестраивать "ридер" в своей голове, привыкший к стандарту, начинаешь очень бережно относиться к стандарту и к возможным его "расширениям".

>Тем более, что Вы говорили что это вроде все излечимо.

Теоретически - да. Практически - нет. CL-сообщество действительно консервативно. Вы не наберёте "критическую" массу для внесения изменений. Разве что только для чего-то совсем нового.

>Вон clojure делает свое дело и живет хотя не CL и newlisp живет
как-то.

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

> Вот я и хочу пример, чтобы я мог понять, неудобно это,
> или просто это не надо так делать

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

Ну попробую разжевать проблему с get.

Допустим мы определили класс persistent-variable, у которого естественно, должен быть метод get. Он имеет совершенно определённую сигнатуру:
(defgeneric get (variable))
(defmethod get ((variable persistent-variable))
Всё вроде понятно.

Также мы захотели сделать лаконичный интерфейс для нашего класса отображения.
Делаем
(defmethod get ((set my-map) map-key &key test key)

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

В С++ - образном языке мы бы написали (извините, если налажаю)
class persistentVariable {
t get(); // t - это тип t из лиспа
};

class myMap {
t get(t mapKey,predicate test=foo, predicate key=bar)
};

и далее
persistentVariable v;
v.get()

myMap m;
m.get(list(1,2),&equalp);

В лиспе мы вынуждены будем переименовать один (а скорее всего, оба) get-а, чтобы они означали разное.

В общем-то, и весь пример. Для меня этот пример достаточно ярок.
Потому что есть несколько слов, которые применимы почти ко всему.
Например, create, delete, get, put, print, add.
Поскольку в CL эти слова (кроме print) не определены, то и получается, что у них нет заранее заданной сигнатуры. Значит,
авторы библиотек имеют возможность несовместимо определить эту сигнатуру (а точнее говоря, вообще не имеют возможности её определить, т.к. нельзя менять пакет common-lisp). В итоге,
хорошая практика состоит в том, чтобы избегать этих слов вообще или всегда предварять их префиксом пакета, если используется чужой get. Довольно глупо!

> У него там полная ж... с "интернационализацией".
Я завёл новую тему.

> реализованная в С++ и Яве (насколько я её знаю) модель ООП слишком ограничена

да, и притом еще гвоздями прибита^W^W приварена газовой сваркой

> и кажется надуманной.

нет.

> Но "начитавшись" пакетов для CL, вроде даже полезных, в которых некоторые авторы сначала лепят "тулс", в котором помимо чего-то полезного куча "мелочи" а-ля "if" с "else", и тебе действительно приходится "сурово" перестраивать "ридер" в своей голове, привыкший к стандарту, начинаешь очень бережно относиться к стандарту и к возможным его "расширениям".

Это проблема eDSL, которую должны решать разработчики *языка* (лиспа в данном случае), если он позиционируется как язык для eDSL.

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

При этом он еще не должен быть сборной солянкой, а должен быть стройным, построен на достаточно малом числе принципов. Вот так.

Да, задача трудная, но *мне* нравится.

Этот то момент я как раз понял. Он прозрачен.
Если бы вдруг с неба упал CL с CLOS который бы вдруг позволил:
(defgeneric get (variable))
(defmethod get ((variable persistent-variable))
(defgeneric get (set))
(defmethod get ((set my-map) map-key &key test key)
Или просто:
(defmethod get ((variable persistent-variable))
(defmethod get ((set my-map) map-key &key test key)
Все остальные проблемы относились бы к косметике?