Начинается эра бэйсика?

> Толи я совсем уж дурак, толи крыша поехала...

:) Ладно, и вправду закругляйся, ИМХО тема исчерпала себя...

> Единственная моя версия -- уж очень он неудачен...

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

> Уй, а я не глядел...

Это я так, извини, если я на неуместный менторский тон перешёл.

Кстати, вспомнил. Есть сходство в плане распространённости с языком Forth. Он тоже имеет свою нишу, даже довольно широкую, если считать PostScript диалектом, оригинальную концепцию, но никогда особо популярным не был.

2anonymous_incognito:

> Есть сходство в плане распространённости с языком Forth. Он тоже имеет свою нишу, даже довольно широкую, если считать PostScript диалектом, ...

А я об чем! Как сейчас принято говорить, DSL!!

Хотя, кстати, пример с Постскриптом показывает, что именно удачный диалект много значит. Кто сейчас вспоминает про Форт? А про Постскрипт, думаю, все слышали.

Я к чему: если не нравится трактовка "Грэм -- мошенник", возможна трактовка "Грэм показал мощь Лиспа как DSL для фильтрации спама". Кстати, а Дядька Столлман заюзал сий DSL вообще как доктор прописал, для обработки списков...

2CrazyPit:

>> ...группирование в начале комплексного выражения произвольного...

Пардон, в конце.

Ладно, вот пример.

Функциональная запись, вычисляемая в 7:
Plus(
     2, 
     Multiply(
               Plus(0,1),
               Plus(2,3)
     )  
)

(типа ранних Лисповских М-выражений)

Аналогично без лесенки, для иллюстрации проблемы:

Plus(2,Multiply(Plus(0,1),Plus(2,3)))
Семантика прозрачна, но скобки    ^^^ достают.

Лисперы предпочли им S-выражения, в духе Лямбды, понимаю. В высшей
степени научно! Но, что интересно, Лямбды-то не получилось!!

От скобок избавиться легко в прямой Польской записи:

+ 2 * + 0 1 + 2 3
    ^^^
Операции иногда группируются, _немного_ анноит. Но операции-то хоть
по-разному обозначаются (в отличие от скобок!) (кстати, в обратной
Польской нотации все вообще совершенно читабельно: 2 3 + 0 1 + * 2 +:
хотя операции и группируются, но _порядок_ группировки естественнен).

Но это ненаучно (ибо в Лямбде мы валентность не фиксируем). В 
результате получаем:
(Plus 2 (Multiply (Plus 0 1)(Plus 2 3)))
                                     ^^^ это -- удобно?

В чем сермяжная истина S-выражений (versus M-выражений)? В отсутствии
запятых?
 
И сравним это с чисто императивной инфиксной  конструкцией cо
скобками:
2+((0+1)*(2+3))

Вот, только честно, предположим, мы не знаем ни Лямбды, ни Польской
записи, -- какой вариант наиболее читабелен? Я ставлю на инфиксную
нотация со скобками. Даже без приоритетов (привычных со школы!) оно
как-то читабельнее.

Для арифметического всё правильно, но... в большинстве моих прог арифметического, по сложности превышающего (+ 1 x) не больше полпроцента. Форт конешно хорош, очень хорош, да. Только вот, при ошибках в записи, например при пропуске оператора, стек перекосит и найти ашыпку весьма проблематично. Также, не очень прикольно в такой записи генерить 1st class functions, вместо простого '(+ 1 x).

2bugmaker:

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

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

Однако, ИМХО не так уж сложно это решить на стадии компиляции. Более того, Форт -- не шедевр. Можно было сделать все гораздо лучше, наверное...

> Для арифметического всё правильно, но... в большинстве моих прог арифметического, по сложности превышающего (+ 1 x) не больше полпроцента.

Это ж просто пример! Замени арифметические операции на любые другие операторы...

> Также, не очень прикольно в такой записи генерить 1st class functions, вместо простого '(+ 1 x).

Ну, в Постскрипте это так звучит: {1 x add}

ИМХО проще...

> Можно было сделать все гораздо лучше, наверное...

Нельзя, принципиально. Можно только в лучшем случае определить дисбаланс. Например я делаю PUSH(v1) PUSH(v2) PUSH(v3) CALL(2) CALL(3), где PUSH - поместить одно в стек, а CALL(n) - извлечь n параметров из стека, выполнив некоторую функцию и поместить 1 результат в стек. Видиш, для последнего вызова не хватает аргументов. Кто может угодать, где я забыл аргумент, в начале функции, перед самым последним вызовом или где-то в середине? CALL(2) вызывается с правильными аргументами или уже на этом этапе стек перекошен? А такие цепочки операций могут быть очень длинными...

> Замени арифметические операции на любые другие операторы...

Заменил... Одна мелкая задачка, случайно увиденная недавно на одном из форумов: http://lib.mexmat.ru/forum/viewtopic.php?t=3322

> Данные целые числа p,q, {a_i} i in [0..N), p>=q. В последовательности {a_i} заменить нулями члены,модуль которых при делении на p дает в остатке q.

На лиспе всё просто и изящно (mapcar (lambda (x) (if (eq q (mod (abs x) p)) 0 x)) a). Попорбуй на чём-нибудь другом? В том то и дело, что арифметические операции имеют исторически сложившиеся неудачные записи, а лисп не пытаецо следовать неудачным традициям просто в целях "совместимости".

> Ну, в Постскрипте это так звучит: {1 x add}

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

(setq z '(* 2 3 4))

(eval z)

(eval (cons '+ (rest z)))

в последнем умножение * заменяется на сложение +.