Зачем в Lisp-е столько скобок?

http://www.gwydiondylan.org/fragments/values.phtml

Э... а комментировать чем будем? :-)

На самом деле нечто подобное можно соорудить, ЕСЛИ ИМЕЕТ РЕАЛЬНЫЙ СМЫСЛ В ТВОЕЙ ПРОГРАММЕ. Пока что другого смысла, кроме культивирования старых привычек, не видно.

На самом деле скобки удобны - просто у тебя привычки очень дурные, мешают тебе въехать. Чем меньше синтаксиса - тем проще, и для компутера, и для человека.

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

Пример - макра loop в Common Lisp. Или макра infix (см. на cliki). Пример расширения синтаксиса для Схемы - http://dslengine.sourceforge.net/ - для Лиспа всё делается совершенно аналогично и даже проще - есть куча готовых генераторов парсеров, не надо с recursive descendant извращаться.

на самом деле нужно скрестить Лисп с Фортом. Стек Форта расширить, позволить ему хранить любые вещи (в частности функции и вложенные стеки/списки), а не только целые числа.

> Зачем в Lisp-е столько скобок?

Если еще не понял - читай дальше. Хотя, похоже, понял:

> Нет ли возможности уменьшить число скобок в Lisp-программах за счет введения других символов разделителей списков ?

И "других" разделителей списков будет ровно столько же, сколько и скобок. Ибо и код, и данные - список. Или, скорее, все - списки, только некоторые из них заквочены :)

Можно. Домашнее задание: сам найди как ;)

> Программы бы смотрелись более элегантно.

Когда (если) "проникнешься" лиспом, списочная структура покажется самой элегантной :))))

Зачем скрещивать ужа с ежом? Лисп умеет гораздо больше, чем Форт. И написать к Лиспу Форт-образоное расширение можно в 10 строк...

P.S. Похоже кое-кто таки заинтересовал Practical Common Lisp :))))))

> Лисп умеет гораздо больше, чем Форт.

Форт со стеком в котором можно хранить функции и т.п. будет уметь ровно столько же сколько и Лисп. Просто мы древовидность переносим из исходного кода в состояние абстрактной машины..

>Форт со стеком в котором можно хранить функции и т.п. будет уметь ровно столько же сколько и Лисп.

Так ли это? В Форте, кажется, нет lexical binding.

Будет - но гораздо бОльшей ценой. Непрактично это. Иметь Форт внутри Лиспа - практично (и я так и делаю, что можно по тому же dslengine проследить, там какая-то ранняя версия Форт-layer-а была), потому как не теряется качество компиляции, и не теряются все остальные доступные в Лиспе вычислительные семантики - а если пытаться перенести Лисп в Форт, то придётся и всё остальное переделывать заново, и оптимизирующий компилятор потеряется.

> Так ли это? В Форте, кажется, нет lexical binding.

IIUC если нужно сделать lexical binding, ты ложишь объект на стек. После этого там где lexical binding валиден, ты просто знаешь местоположение объекта в стеке.

> просто знаешь местоположение объекта в стеке.

конечно нужно чтобы в этом фортоподобном языке слово не могло возвращать переменное кол-во объектов..

> довольно громоздкую конструкцию ((x)...(y)...(z)) можно было заменить на (x; y; z;)

(defmacro each-list (&rest body)
           (loop for i in body
                 collect (list i)))

(each-list x y z) => ((x) (y) (z))

> (eq x 0)

Так делать не надо.

> На самом деле скобки удобны - просто у тебя привычки очень дурные,
> мешают тебе въехать. Чем меньше синтаксиса - тем проще, и для
> компутера, и для человека.

Имхо все же спорный вопрос. Я сейчас параллельно ковыряюсь с лиспом и
Nemerle; так вот (не отвлекаясь на обсуждение сравнительных достоинств
и недостатков собственно языков), код на Nemerle имхо на порядок
читабельней. Можно, конечно, списать это на дурное воздействие C/C++ на
неокрепшие юные мозги... но бездоказательно этого делать все же не
стоит =)

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

Хотя, конечно, альтернативный вариант - редактор с умной подсветкой
синтаксиса ;)

нетривиальный синтаксис встроенный в язык лишает его божественности

Именно так. Тривиальный синтаксис внутри + подсветка и/или избыточный синтаксис (макры), прозрачно трансформирующийся в тривиальный - для человека.

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

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


Синтаксис перла - это не перегибание палки, это пример языка,
задизайненного по принципу "художников"-модернистов aka "а я так
вижу!". Т.е. чистый бред, без какой-либо рационализации, просто
незамутненный поток сознания =) в чем и состоит его эстетическая
ценность...

Решпект! Обалденное сравнение - мне такое и в голову не приходило...

скобок в лиспе всего две, ( и ). если сможешь обойтись одной -- флаг тебе в руки

смысл loop использовать? (mapcar 'list body)

> Так делать не надо.

ага, ибо не квотированная конструкция ((x) ..) - не имеет смысла

> смысл loop использовать? (mapcar 'list body)

Ну, я ишшо не LISP-гуру. Все подробности сразу в голове не помещаются пока :)

> ибо не квотированная конструкция ((x) ..) - не имеет смысла

Это относилось к (eq x 0).

Common Lisp makes no guarantee that eq is true even when both its arguments are ``the same thing'' if that thing is a character or number.

Спорим, я могу обойтись вообще без скобок? На 100GBP?

блин, на перле можно писать как на С `if (cond) {act}'. Нравится -- пожалуйста. не нравится -- `act if cond', `cond && act'. Проблемы не вижу.
Кстати о мыслях -- перл, имхо, это вообще очень мощный текстовый фильтр. В нем, кажется, все оптимизировано для процессинга текстового потока:
<>, for (), массивы-списки, умолчальная переменная, s///, y///.

Не... Он очень ограниченный текстовый фильтр. С ParSec - и рядом не валялся...

>блин, на перле можно писать как на С `if (cond) {act}'. Нравится -- пожалуйста. не нравится -- `act if cond', `cond && act'.

Писать то можно. Это да. По первости даже прикольно было. Но вот читать ....

Веришь, нет -- хорошо читаю. Если написано с прицелом на то, чтоб читали. Если нет -- небе никто не поможет от обфускации кода.

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

Заглянул, но не нашел того самого Форт-layer'a. Подскажи
поподробней, пожалуйста, как именно можно получить Форт
в Лиспе?
Быть может мы о разном говорим: меня интересует не реализация парсера и лексера для Форта с помощью Лисп системы, а именно привязка одной системы к другой, т.е. как добиться того, чтобы форт-система выполняла низкоуровневые вызовы и численную математику с плавающей точкой до определенного уровня сложности, а все что выше - было нагрузкой лисп-системы, но
при этом они были бы синхронизованы

(Предыдущее сообщение тоже было мое - поторопился)

И кстати, насколько масштабируема такая система будет? В реальной системе на один компьютер - несколько физических устройств, с которыми общается форт-система (плюс в том, что постепенно низкоуровневые операции переводятся в электронику, но сразу в один момент перевести все невозможно - реалии бюджета) все управление возлагается на лисп-систему. Если действительно можно прикрутить форт без потери производительности, то следующий шаг - несколько компьютеров и опять в системе под управление лиспа. Примеры message passing есть и для локалки годятся, но как в реальности дело обстоит с развертыванием в нескольких сетях одновременно (не столько с точки зрения подключения, сколько с точки зрения обеспечения единой системы безопасноти и увязки ее с лиспом) - для меня пока загадка - реального опыта на лиспе маловато. Тем не менее выглядит очень и очень заманчиво и красиво, но почему так не делают? В чем грабли?

--Antey

Идея тривиальная - Форт компилируется в Лисп (а тот, соответственно, в ассемблер целевой платформы). Для удобства стеки Форта реализуем на Лисповских списках.

Производительности можно добиться какой угодно: вовсе не обязательно компилировать Форт в Лисп, можно сразу в таргет, и стек использовать нормальный, а не список. То есть - в собственно рантайме Лисп не участвует, он включается только в компиляцию.

Почему так не делают? А не знаю. Очень много чего хорошего и умного не делают, а вот глупости - на каждом шагу - на C++ пишут, на Java, используют везде M$ Windows... ;)

без скобок любой пионер на паскале или на форте напишет,
ты попробуй с одной!

Не канает, в Паскале парные скобки есть - begin/end, (/), [/]...

В Форте - тоже.

Меня собственно сразу второй подход и интересовал:
Fort -> (with Lisp) => TargetASM

Для одного компа и это пройдет, а вот реализация
распределенной системы таких машин (под управлением Lisp)
в котором основная лошадка - форт - мне не ясна.

т.е. я все равно не понял, как синхронизовать две системы форт и лисп
в рантайм?
Ну не крутить же проверку общего состояния!
(да еще и в обоих, из-за синхронизации)

--Antey

Тогда придётся держать рантайм Лиспа на всех узлах, передавать исходник (возможно, после какого-то минимального препроцессора), и компилировать каждый раз на месте. Тогда целостность каждого рантайма гарантируется.

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

однако это эначит - прощай точность (по времени) и скорость
(сейчас борьба идет о долях микросекунд при софт-верной реализации, поскольку электронная дает доли наносекунд, но не всегда оправдана и не всегда надолго <==> т.е. дорога)

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

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

Что я не догоняю?

--Antey

Если при этом

> Производительности можно добиться какой угодно:

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

Никакой (U)FFI с этим не справится - требуется срашивание "словарей" - иначе неизбежные накладные расходы

Исключение - лисп-машины, но их никогда массово не выпускали
А на регистровой архитектуре- увы

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

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

С/С++ декларирует и то, и это, но слишком большой кровью
девелоперов

Однако реальной альтернативы без поддержки
со стороны архитектуры не видно,
а ведь такая альтернатива со всеми преимушествами
(лиспа/схемы и форта)- это именно то, что было бы востребовано
и критическая масса хороших приложений бы набралась быстро

Что скажешь, Виталий?