Синтаксис Lisp

> Все остальные проблемы относились бы к косметике?

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

> Все остальные проблемы относились бы к косметике?
Вряд ли. Есть ещё довольно много недостатков конкретно у CL. Ну поищите, я про это писал не один раз. Неохота повторяться.

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

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

Только скриптовому языку для задач на пару строк.

И ты, как любитель C++(вот тут уж синтаксис так синтаксис, только перл перебьет), это должен понимать.


К тому же, к коммонлиспу приделать любой синтаксис.

У плюсов как раз проблемы не с синтаксисом. Я ненавижу С++ и до недавних пор любил лисп (да и до сих пор он мне нравится, но уже как абстрактная идея, а не как конкретно CL с множеством граблей). Тем не менее, синтаксис С++ для меня удобнее.

> К тому же, к коммонлиспу приделать любой синтаксис
Это в теории. На самом-то деле, чтобы решение было практичным, нужно покрыть лисповое ядро непрозрачным слоем нового синтаксиса, а для этого нужно поменять всё, включая ввод-вывод и среды разработки. Это не столь дешёвое развлечение, учитывая, что синтаксис лиспа при ближайшем рассмотрении оказывается довольно заковыристым (readmacro, `, #., нечитаемо печатаемые объекты). И если ставить вопрос так, то к любому языку можно приделать любой синтаксис. Операции над текстом ещё никто не отменял. Но почему-то для других языков этот вопрос обычно не встаёт, а для лиспа он регулярно встаёт. Конечно, можно списывать на то, что это глупые новички, но это также может значить, что лисп - это секта, а скобки - это догма.

>У плюсов как раз проблемы не с синтаксисом.
рекомендую посмотреть сырцы boost.

>нужно покрыть лисповое ядро непрозрачным слоем нового синтаксиса
Нахрена?
>для этого нужно поменять всё, включая ввод-вывод и среды разработки
Нахрена? Какое все?

>синтаксис лиспа при ближайшем рассмотрении оказывается довольно заковыристым
>readmacro
Ну, после ридер-макросов синтаксис лиспа это как бы не синтаксис лиспа уже.
>`
Вот как раз таки "`" отлично помогает с читабельностью сложных макросов.
>#.
Ужас какой!
А еще ведь есть "#x"! Кошмарная нечитаемая дурь! В си-подобных синтаксисах, однако, есть "0x", к которым, почему-то, таких претензий не возникает.

>к любому языку можно приделать любой синтаксис
Можно. А еще на любом языке можно писать как на фортране.

>для лиспа он регулярно встаёт
Для лиспа он встает потому, что эти самые "новички", привыкшие к синтаксису плюсов, жабы или чего еще там, похожего, никак не могут от него отвыкнуть; и, почему-то, требуют ввести в лисп как минимум похожий.

У Эди Вейтца есть отличный пример расширения синтаксиса, в библиотеке RDNZL. http://weitz.de/rdnzl/ Там он сделал опциональный ридер, работающий в пределах "[".."]", и предоставляющий доступ к членам классов/структур через ".", по подобию C#

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

> Для лиспа он встает потому, что эти самые "новички", привыкшие к синтаксису плюсов, жабы или чего еще там, похожего, никак не могут от него отвыкнуть; и, почему-то, требуют ввести в лисп как минимум похожий

А у тебя не возникало мысли, что люди легче привыкают к хорошему, чем к плохому и дело может быть тупо в этом. Опять же, повторюсь, я знаю лисп существенно лучше, чем С++ и, наверное, больше работал с лиспом. Но мне не нравится его синтаксис. Конечно, меня можно объявить психом или диссидентом, а моё мнение - артефактом :)

> >для этого нужно поменять всё, включая ввод-вывод и среды разработки
> Нахрена? Какое все?
Я не понимаю тебя. Видимо, ты чем-то из лиспа не пользуешься, если у тебя такие вопросы возникают. Например, я пользуюсь completion, code navigation, подсказкой по параметрам функции, инспектором. Также я люблю вызывать справку по функции из EMACS. Иногда я пишу в REPL (macroexpand (мой-код ...)) и смотрю на результат. Также я постоянно пользуюсь автоотступами. Также я пользуюсь навигацией по уровням вложенности sexp-выражений:

<C-backspace> backward-kill-sexp
<C-delete> kill-sexp
<C-left> backward-sexp
<C-right> forward-sexp

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

Если на входе macroexpand - не s-выражения, то логично и на выходе тоже видеть напечатанными не s-выражения. Значит, нужно переопределить не только read, но и print.

> >к любому языку можно приделать любой синтаксис
> Можно. А еще на любом языке можно писать как на фортране.
По-твоему, это ответ?

> У Эди Вейтца есть отличный пример расширения синтаксиса,
Он станет отличным, когда macroexpand будет печатать в таком же синтаксисе, а дебаггер будет показывать место в исходнике, сделанном с таким синтаксисом. Это сделано?

>В лиспе это вообще затруднительно, т.к. a.b - это идентификатор, равно как и a->b. Единственный не идентификатор - это a:b, но и здесь уже есть смысл - это символ b в пр-ве имён a. Если обобщить операцию ":" и на пр-ва имён тоже, тогда, может, ещё будет ничего.

Проблема только одна, и это ты. Мало того, что ты не понимаешь, что только благодаря такому "долбанутому префиксному синтаксису" можне очень легко и безболезненно писать макросы, которые оперируют кодом как списками, так ты еще и про readtables не удосужился прочитать. Если бы удосужился, то знал бы, что сделать точки и прочую мишуру разделителями не представляет никакой проблемы.

Кури HyperSpec, а лучше возвращайся на питон. Грэхем советовал использовать его, если с лиспом не можется/не получается.

>>У плюсов как раз проблемы не с синтаксисом

> рекомендую посмотреть сырцы boost.

Будешь критиковать синтаксис плюсов только после того, как освоишь Qi и научишься на нем делать то же, что делает boost. Тогда и сравним синтаксисы.

Или, альтернативно, выучишь С++. А пока все твои высказывания о нем -- пук в лужу.

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

Синтаксис лиспа можно рассматривать в 2 аспектах:

1. Когда он не позиционируеется как контейнер для eDSL -- тогда это ужасный синтаксис. Скрашивают жизнь только возможности писать свои литералы.

2. Когда он позиционируеется как контейнер для eDSL -- тогда встают вопросы указанные ден73 о поддержке новых синтаксисов в редакторе, print и указанный yyk вопрос о любителях на каждый чих создавать свой самобытный синтаксис.

> Кури HyperSpec, а лучше возвращайся на питон.

Ты бы хоть ознакомился, на чем ден73 программил последние 10 лет, по его постам на форуме.

> Будешь критиковать синтаксис плюсов только после того, как освоишь Qi и научишься на нем делать то же, что делает boost.

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

У меня другой вопрос. Я не работал с boost, но почему люди не пользуются m4 в тех местах, где темплейты не могут?

Для адептов C++ слово "препроцессор" как красная тряпка.

>только после того, как освоишь Qi
Зачем? Это что, отменит уродливость синтаксиса плюсов?
После ~3 вложенных шаблонов на плюсовский код страшно смотреть, это как бы факт.
Ну и, какая польза от Qi?
>то же, что делает boost.
То, что делает буст это в основной своей массе убогие костыли. Никто не спорит, что это адский труд и так далее, создать подобное на C++, но это не отменяет первого.
>Или, альтернативно, выучишь С++
Вот я единственно чего не пойму, так это почему большая часть программистов на C++ страдает манией величия. Предпосылки к этому не вижу; однако ж. Я, пожалуй, не могу "выучить" C++, хотя на это вообще мало кто способен; и не вижу смысла; однако, знаю его в достаточной степени, уверяю.
>это ужасный синтаксис.
Да нормальный там синтаксис. Все ясно и понятно: (функция . аргументы)
>тогда встают вопросы указанные ден73 о поддержке новых синтаксисов в редакторе
Это плата, конечно, но незначительная. Мне, лично, в случае с s-expr based макросами практически всегда хватало самых базовых возможностей редактора, вроде подсветки скобок и отступов. Да, есть языки, используя которые, без навороченного редактора, ide с автодополнением и прочим, прожить невозможно. Лисп к их числу не относится.
>вопрос о любителях на каждый чих создавать свой самобытный синтаксис.
Как будто бы на CL пишут тысячи индусов, и тебе надо поддерживать их код.

> Я не работал с boost, но почему люди не пользуются m4 в тех местах, где темплейты не могут?

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

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

Заодно -- я не знаю, как проверить из с++ (шаблоны + макросы), определена ли данная переменная. А это иногда надо. Сегодня наверно запощу такой вопрос в девелопмент.

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

_______________________________________________

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

Если тебе не нравится с++ -- так выучи Qi, про что тебе и говорилось -- это будет аналогом плюсов.

> однако, знаю его в достаточной степени, уверяю.

В ответе на вопрос про &(var++) ты проглядел очевидный момент -- константные ссылки.

http://www.linux.org.ru/jump-message.jsp?msgid=3698632&cid=3698679

> Мне, лично, в случае с s-expr based макросами практически всегда хватало самых базовых возможностей редактора, вроде подсветки скобок и отступов.

Хорошо, давай ограничимся s-expr based макросами.

Вот пример записи: if x>0 then a=b else c=d end

Как оно будет выглядить на DSL c s-expr based макросами?

1. Вариант (if (> x 0) (then (setq a b)) (else (setq c d))) является сильно избыточным по скобкам.

2. Вариант (:if > x 0 :then setq a b :else setq c d) позволит ли пользоваться возможностями редактора? Вставлять вложенные if? (if > x 0 :then setq a b :else :if > p q :then setq m n)

> Как будто бы на CL пишут тысячи индусов, и тебе надо поддерживать их код.

Я считаю жалобы yyk обоснованными, хотя своего опыта в сопоставимом объеме у меня нет.

Зачем для if писать макрос какой-то особый?

> Зачем для if писать макрос какой-то особый?

Ну надо же придумать какой-то простой *и всем понятный* пример, на котором мы будем разбирать недостатки (или вдруг достоинства?) лисповского eDSL?

http://john.freml.in/teepeedee2-release

> http://john.freml.in/teepeedee2-release

Слишком сложный пример. Давай лучше рассмотрим if.

> Т.е. например (для замыканий и т.п.) адрес локальной переменной не должен уходить в глобальную.

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

> Заодно -- я не знаю, как проверить из с++ (шаблоны + макросы), определена ли данная переменная.

Кстати, я тоже не знаю как это сделать в лиспе. Можно (как обычно) переопределить defvar, завести таблицу переменных и писать во время выполнения defvar в эту таблицу. Дальше надо учесть семантику компиляции. Хм. теперь знаю. Ответ "вообще говоря, никак, но в конкретных реализациях можно", см. variable-special-p в clocc (GPL). Вообще, это хороший вопрос для FAQ, у кого есть доступ туда? У меня, по-моему, нету.

Касаемо того, определена ли такая локальная переменная - тут поможет только code walker. Однако, сделать можно. Эта возможность имеет хорошие примеры применения (iterate, screamer, ap5) и работает гладко .

>1. Вариант (if (> x 0) (then (setq a b)) (else (setq c d))) является сильно избыточным по скобкам.

А вариант

(if (> x 0) (setf a b) (setf c d))

??

>Зачем для if писать макрос какой-то особый?

Ты не поверишь, написаны и не единожды. И даже людьми, к чьему мнению в среде лисперов хоть чуть-чуть прислушиваются.

И нет - на лиспе не пишут тысячи индусов. Но за последние _десятки_ лет на нём написано столько, что чтобы ты не стал писать - с высокой степенью вероятности это будет "повторение". Но очень большая часть этого "изобилия" написана... скажем так, не в соответствии с принятыми в более позднее время правилами и стандартами ;) Так вот пытаясь в таких "завалах" найти что-то нужное и/или полезное, очень быстро приходишь к неконтролируемому желанию нещадно бить по рукам за практически любое отклонение от стандартов.

Я не говорю, что "свобода внутри лиспа" - это плохо. Плохо, когда хромает самоконтроль и самодисциплина при использовании столь "всепозволяющих" инструментов.

> А вариант (if (> x 0) (setf a b) (setf c d)) ??

также являясь избыточным по скобкам -- сравни с

if(x>0, a=b, c=d)

или даже с гипотетическим

(if > x 0 ; setf a b ; setf c d)

а также не имеет наглядности -- ключевые слова then else пропущены. Если таких слов много (ну например враппер для wget, dd, vlc...) то позиционные аргументы не катят.

> Это уже семантика.

основная ценность компилятора (и языка) именно в семантике.

> Плохо, когда хромает самоконтроль и самодисциплина при использовании столь "всепозволяющих" инструментов.

Плохо, когда язык не предоставляет фреймоворк для eDSL. Фреймоворк, который призван спасти от вавилонского столпотворения.

> if(x>0, a=b, c=d)

А что делать, если нужно выполнить несколько действий в блоках?

Так что ли писать if(x>0, (a=b, c=d), (e=f, g=h)) - ну так еще хуже получается - ненужные запятые - не нужны.

> а также не имеет наглядности -- ключевые слова then else пропущены.

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

Вообще, примером правильного лиспа является математика.Вот я когда-то делал файлик с примерами использования возможностей Mathematica:

http://ecovillage.narod.ru/mathematica/igor/igor.html

>> if(x>0, a=b, c=d)

> А что делать, если нужно выполнить несколько действий в блоках?

С *самого* начала предлагал -- if x>0 then a=b else c=d end

if(x>0, a=b, c=d) -- это всего лишь демонстрация избыточности записи scabarocci.

>> а также не имеет наглядности -- ключевые слова then else пропущены.

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

ага, сделай такой враппер для dd, а я посмотрю

Ну только если какие-то надостройки.
if-let из библиотеки alexandria:

(defmacro if-let (bindings &body (then-form &optional else-form))
    (let* ((binding-list (if (and (consp bindings)
                                  (symbolp (car bindings)))
                             (list bindings)
                             bindings))
         (variables (mapcar #'car binding-list)))
    `(let ,binding-list
       (if (and ,@variables)
           ,then-form
           ,else-form))))

>Плохо, когда язык не предоставляет фреймоворк для eDSL. Фреймоворк, который призван спасти от вавилонского столпотворения.

Не совсем "догоняю" о чём вы, но в любом случае: отсутствие/наличие инструмента оправдывает... "безобразия" программиста?

>Ну только если какие-то надостройки. if-let из библиотеки alexandria:

А по мне - яркий пример (но не ярчайший ;)) того как не надо делать: мало того что, по сути, экономит только одну строчку, так ещё один ключевой момент - (and ,@variables) - ни как не отражён в названии макры. А если мне надо не and а or? Или вообще своё условие?

В результате: экономии - практически 0, универсальности - тоже 0, но целая новая конструкция, из названия которой не следует её "поведение".

Потом натыкаешься на чью-либо либу, изобилующую вот такими "новшествами", и голова пухнет: на eDSL не тянет - какая нфиг "DS", но в голове всё это безобразие держать надо.

<далее следует ненормативное излияние своих эмоций и мыслей по поводу автора, его рук, головы, других частей его тела, его ближайших родственников, его детства и игрушек, его домашних животных, физиологических особенностей его организма, пожеланий ему на ближайшее будущее>

>Как оно будет выглядить на DSL c s-expr based макросами?

Ты по паскалю скучаешь чтоли? Зачем тебе then? А else? Твой вариант

>1. Вариант (if (> x 0) (then (setq a b)) (else (setq c d))) является сильно избыточным по скобкам.

И правда избыточен по скобкам, потому что в нем непонятно для чего торчат "then" и "else". (if (> x 0) (setq a b) (setq c d)) Конечно, можно пожаловаться, что на глаз неочевидно, где тут else, особенно если первое выражение будет достаточно сложным, но это решаемо переносом на новую строку точно так же, как и в случае с :else, который посреди длинной строчки не особо хорошо заметен.

>А по мне - яркий пример (но не ярчайший ;)) того как не надо делать: мало того что, по сути, экономит только одну строчку, так ещё один ключевой момент - (and ,@variables) - ни как не отражён в названии макры. А если мне надо не and а or? Или вообще своё условие?

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

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

>Потом натыкаешься на чью-либо либу, изобилующую вот такими "новшествами", и голова пухнет: на eDSL не тянет - какая нфиг "DS", но в голове всё это безобразие держать надо.

Прошу прощения, но чем такое "безобразие" принципиально отличается от вызова функции? По-моему, так ничем: кусок кода без вредоносных побочных эффектов находится где-то там, этот код используется из других функций, экономя на операции "copy-and-paste". Почему-то такой подход в языках программирования принято считать хорошим, но, по-твоему, к лиспу это не относится?

>Не совсем "догоняю" о чём вы, но в любом случае: отсутствие/наличие >инструмента оправдывает... "безобразия" программиста?

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

(defmacro let1 (var val &body body) `(let ((,var ,val)) ,@body))

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

Общая идея - синтаксис лиспа настолько нарочито излишен, что у любого адекватного человека возникает желание срезать хотя бы наиболее острые углы. А поскольку единого принятого стиля срезания углов не существует, и поскольку макросы пишутся слишком легко, то каждый старается во что горазд. И да, я не буду каяться в том, что пользуюсь let1. Более того, я вставляю его везде и даже в примеры когда, которые я выкладываю на c.l.l, прямо вместе с определением. Кому не нравится - пусть не читает, у нас свобода :)

> С *самого* начала предлагал -- if x>0 then a=b else c=d end

Ты что, хочешь отдельную конструкцию для присваиваний?

> if(x>0, a=b, c=d) -- это всего лишь демонстрация избыточности записи scabarocci.

Какой избыточности? Избыток чего?

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

Лисперы-скобкофобы? Чур меня, чур меня... =)

>Во-вторых, принято читать описание функции или смотреть на примеры ее использования/ее код в том случае, когда документация отсутствует.

Капитан?.. =) Я о том, что со временем (опытом) стандартные (часто употребляемые) вещи ты таки запоминаешь. Погружаясь в DS область ты готов к DSL и, "переключив в голове контекст", быстро вспоминаешь что к чему. Но когда у каждого программиста свой DSL по принципу "я и есть D" - вот это "достаёт".

>Прошу прощения, но чем такое "безобразие" принципиально отличается от вызова функции?

И много ты видел функций add2, add3, add4, add5... и прочего? ИМХО - совершенно _неоправданное_ _введение новой сущности_.

> ага, сделай такой враппер для dd, а я посмотрю

какой? Ты про такой что ль (dd :if foo :of bar :bs 512 :count 5000))?

> Вот пример записи: if x>0 then a=b else c=d end Как оно будет выглядить на DSL c s-expr based макросами?

Зачем пытаться переопределить конструкцию языка, которая уже есть в языке?

> 2. Вариант (:if > x 0 :then setq a b :else setq c d) позволит ли пользоваться возможностями редактора?

Можно реализовать. Пользоваться возможностями редактора (кстати какими? - все-равно macroexpand будет превращаться в тривиальный if) позволит в полной мере.

> Вставлять вложенные if? (if > x 0 :then setq a b :else :if > p q :then setq m n)

Ты хочешь *такого* - (my-if > x 0 :then setq a b :else (my-if > p q :then setq m n))?

>Конечно, отсутствие инструмента оправдывает безобразия.

ИМХО - объясняет, но не оправдывает.

>Я сам тоже написал свои расшерения для элементарных вещей. Например, абсурдно писать 4 лишних скобки, когда нужно определить всего одну переменную.

ИМХО - абсурдно вводить новую сущность из-за желания избавиться от 4-х скобок.

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

Субъективно. По-началу. Потом проходит (не у всех - да).

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

Любой != каждый. Каждый не старается.

>И да, я не буду каяться в том, что пользуюсь let1. Более того, я вставляю его везде и даже в примеры когда, которые я выкладываю на c.l.l, прямо вместе с определением. Кому не нравится - пусть не читает, у нас свобода :)

И свобода перемещения! "Желаю счастья с Питоном!" =)

> Например, абсурдно писать 4 лишних скобки, когда нужно определить всего одну переменную. И я сделал макрос:

Странно слышать от человека, который собирается переезжать на питон, жалобы на 4 лишние скобки. В этом самом питоне, даже repeat until нет и каждый раз приходиться писать на целую строчку больше и вводя ненужную переменную; нет нормальных анонимных функций - поэтомум нужно и название придумать (что весьма нехило засоряет код и снижает читаемость) и return с def написать (тоже немалый оверхед по сравнению с 4 скобками), нет обычного цикла (не всегда нужно и не всегда можно воспользоваться list comprehension и iteratorами) - будь готов писать for x in xrange(n) - вместо простого и понятного dotimes.

> Странно слышать от человека, который собирается переезжать на питон, жалобы на 4 лишние скобки

Т.е., ты считаешь, что (let ((a (+ 1 b))) a) - это круто и его не стоило бы заменить на (let1 a (+ 1 b) a)?
Вообще - это несколько экстремальная точка зрения среди лисперов. Лисперы обычно признают, что s-выражения не особо удобны, но говорят, что зато макросы удобно делать. И только в пылу спора лисперы могут начать доказывать, что s-выражения - это наилучший синтаксис. В таком споре я участвовать, конечно, не буду :)

Кстати, вроде бы, никто иной, как Пол Грехем тоже в своё время предлагал что-то вроде let1, хотя я не люблю прибегать к авторитетам :)

И в clojure тоже let сделан без внутренних скобок, а внешние круглые скобки заменены квадратными. Вместо

(let ((a (+ b 1)) (c (+ d 1))) (+ a c))

в clojure пишут:

(let [a (+ b 1) c (+ d 1)] (+ a c))

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

Не знаю, кто как, а я освоил в своё время m4 и мою голову сложно запудрить заклинаниями о том, что якобы, s-выражения _необходимы_ для макросов. На самом деле, нет. Они всего лишь делают макросы более удобными. Большинство (наверное, 75%) макросов укладываются в квазицитирование, а оно прекрасно делается с помощью средств, подобных m4 (в любом синтаксисе). Тот же cpp и шаблоны С++ - это тоже (плохие) примеры квазицитирования, хотя почему-то никто их так не называет.

Остаются только 25% самых сложных макросов, для которых действительно нужно представлять AST в виде какого-то дерева данных и программно с ним манипулировать. Ну так я готов иметь трудности с этими 25%. Их нужно писать редко, а основной синтаксис - перед глазами постоянно.

Учитывая, что макросы и так составляют в моём коде порядка 10%, получается, что я вынужден читать s-выражения ради облегчения своей работы над 2.5% всего кода, который составляют сложные макросы. Это ИМХО неоправдано.

Лисперы обычно неспособны воспринять эту простую мысль, поскольку она эквивалентна высказыванию "а король-то голый"! В общем-то, пристрастие к синтаксису CL я могу объяснить только как религиозное пристрастие. Что же, атаковать чужую веру - это дело неблагодарное и даже не особо хорошее :)

Ну, в общем, ладно. Я надеюсь, я раскрыл тему "чем плох синтаксис лисп"? Спорить мне неинтересно - эти вопросы для меня давно закрыты, ничего нового я не узнаю, переубедить тоже вряд ли кого-то получится. Зачем тогда терять время?

>Я надеюсь, я раскрыл тему "чем плох синтаксис лисп"?

Ты забыл добавить "для меня". А так всё верно. Не будем больше терять время ;)

> Т.е., ты считаешь, что (let ((a (+ 1 b))) a) - это круто и его не стоило бы заменить на (let1 a (+ 1 b) a)?

Легче, стоило, не спорю. Я про то, что в лиспе можно избегать повторений кода и добиваться более простого, понятного синтаксиса, вводя конструкции более высокого уровня уже сейчас, с помощью макр. В питоне этого нет, и сделать это без мегакостылей (easy extend, на котором написать конструкцию сложнее repeat until или when - уже непросто, или с помощью низкоуровневого eval, или шарясь по AST вручную) не представляется возможным. Поэтому мне и непонятны переживания по поводу 4ых скобок, когда в питоне будут "лишними" целые конструкции и сделать с этим ничего нельзя. Кстати, если тебе хочется макр и хочется синтаксиса - почему не руби? - это же твоя мечта - лисп с python-like синтаксисом и богатым набором библиотек.

> Вообще - это несколько экстремальная точка зрения среди лисперов. Лисперы обычно признают, что s-выражения не особо удобны, но говорят, что зато макросы удобно делать. И только в пылу спора лисперы могут начать доказывать, что s-выражения - это наилучший синтаксис. В таком споре я участвовать, конечно, не буду :)

На мой взгляд lisp сложнее читать только потому, что (1) один регистр (2) старая любовь лисперов к сложным, вложенным друг в друга выражениям, поэтому обычно удобней читать лисповый код с конца или середины выражений, раскручивая его в голове, и приходя к началу. Если писать в лиспе в "императивно-отрывочном стиле" (progn (setf a b) (setf c (func1 f g)) (func2 a c)) , то оно будет много понятней и ясней. Попытка использовать лисп-стайл кодинг в других языках приводит к абсолютно такому же нагромождению скобок, и в случае с отдельными языками (например, С) - приводит к еще более "ужасному", чем в лиспе коду. Так что, это по большому счету не проблема самого синтаксиса, а сложившегося стиля программирования. Мне s-expressions нравятся своей консистеностью (тебе, как я понимаю, именно это и не нравится) и возможностью ими жонглировать в редакторе.

> Не знаю, кто как, а я освоил в своё время m4 и мою голову сложно запудрить заклинаниями о том, что якобы, s-выражения _необходимы_ для макросов. На самом деле, нет. Они всего лишь делают макросы более удобными. Большинство (наверное, 75%) макросов укладываются в квазицитирование, а оно прекрасно делается с помощью средств, подобных m4 (в любом синтаксисе). Тот же cpp и шаблоны С++ - это тоже (плохие) примеры квазицитирования, хотя почему-то никто их так не называет.

Agree

> Остаются только 25% самых сложных макросов, для которых действительно нужно представлять AST в виде какого-то дерева данных и программно с ним манипулировать. Ну так я готов иметь трудности с этими 25%. Их нужно писать редко, а основной синтаксис - перед глазами постоянно.

Ждем пока David Мoon допилит PLOT? :) хотя по большому счету, я бы допилил что-нибудь живое.

> Учитывая, что макросы и так составляют в моём коде порядка 10%, получается, что я вынужден читать s-выражения ради облегчения своей работы над 2.5% всего кода, который составляют сложные макросы. Это ИМХО неоправдано. Ну мне не сильно сложно читать s-expressions, по крайней мере не сложнее, чем синтаксис других языков. У меня нет идиосинкразии на скобки. А вот кому-то не нравится significant whitespace. И это все вопросы личного восприятия и ощущения, а не objective issue.

Хотя и не ден73, отвечу

> Мне s-expressions нравятся своей консистеностью (тебе, как я понимаю, именно это и не нравится) и возможностью ими жонглировать в редакторе.

Мне они не нравятся избыточностью (о чем и писал уже М раз), а консистентность безусловно нравится. Однако консистентность достигается и другими способами, в том числе указанным мною if x>0 then a=b else c=d end без лишней избыточности.

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

> Мне они не нравятся избыточностью (о чем и писал уже М раз)

Еще раз - какая избыточность? Я не совсем тебя понимаю, поясни, пожалуйста.

> if x>0 then a=b else c=d

Синтаксис, в котором есть разношерстные конструкции, сложно назвать "однообразным" (хотя это вопрос определений ). Тем более на этом примитивном примере псевдокода соверешенно непонятно, как будут записываться блоки. На нашем воображемом edsl-lispe это запишется, как if > x 0 :then do-a :else do-b - большой разницы не заметил. Кстати, в отличие от s-expression твой if - statement, т.е. в список аргументов его не запихнешь. И как раз таки т.н. "скобочная избыточность" обязана именно функциональной природе лиспа - в котором любая форма вычисляется - т.е. суть выражение.

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

Собственно, поэтому тебе и не приходится видеть такое в сях: my-function (if (x > 0) { make_something (a, b); f(0)} else h(d), make_instance (0, 5)), но является вполне традиционным для лиспа.

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

> опять же соглашусь с ден73 -- раз в треде лисперы начали защищать sexpr как образец читабельности (а не образец легкости макрописания) -- пора покидать тред.

Я говорил не о том, что sexpress образец читаемости, а о том, что он не настолько страшен и нечитаем, и что по-большому счету львиная доля "нечитаемости", имхо, из-за своей expression nature, а не потому что он просто плохой. Образцом читаемости для меня, наверное, был бы как раз indentation-lisp-based синтаксис с сохранением самой семантики навроде того, который по ссылке ТК (хотя у меня очень большие сомнения по поводу редактирования и поддрежки такого кода), но и cl синтаксис тоже сойдет. Опять же повторю, что это все вопросы "религии, веры, вкуса и личного восприятия" - тут спора быть не может, только обмен мнениями.

> Кстати, в отличие от s-expression твой if - statement, т.е. в список аргументов его не запихнешь. И как раз таки т.н. "скобочная избыточность" обязана именно функциональной природе лиспа - в котором любая форма вычисляется - т.е. суть выражение.

Вовсе не обязана:

(setq y (+ :if > x 0 :then x :else - x :end 1))

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

setq a b ; setq c d ; setq e f

> Еще раз - какая избыточность? Я не совсем тебя понимаю, поясни, пожалуйста.

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

Возможно еще тут синтаксический шум.

> my-function (if (x > 0) { make_something (a, b); f(0)} else h(d), make_instance (0, 5))

x>0
?
({ make_something (a, b); f(0); })
:
({ h(d); make_instance (0, 5); })

gnu c/c++ extention -- зачем сделали? для макросов, вестимо :-)

> Опять же повторю, что это все вопросы "религии, веры, вкуса и личного восприятия" - тут спора быть не может, только обмен мнениями.

Полезно было бы найти объективные критерии качества синтаксиса. Хотя вариации на тему вкусов могут быть.