[Lisp] вопрос о квадратных скобках

Естественно, речь идёт о тех диалектах где [] уже не заняты под что-то другое (вектор, например).

хорошо.

синтаксический сахар в меру полезен.

>синтаксический сахар в меру полезен.

У меня почему-то как-то не поворачивается язык назвать это даже синтаксическим сахаром =)

А вообще по моему правильная идея.

>>У меня почему-то как-то не поворачивается язык назвать это даже синтаксическим сахаром =)

ну а как их еще назвать?

Эм, а смысл? По-моему, пользы от них никакой. Да и вреда тоже особо нет.

Ну [(a b) (x y)] смотрится чуть понятнее. Синтаксический сахар, как сказал предыдущий оратор.

[(a b) (x y)] смотрится чуть понятнее

это только к спискам применимо?

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

Обсуждается случай, когда [] идентичны ().

Можно и (lambda [x y z] .......) (Автора clojure это, видимо, сподвигло сделать список формальных аргументов вектором).

Ну [(a b) (x y)] смотрится чуть понятнее.

Что это означает?

Обсуждается случай, когда [] идентичны ().

Это противоестественно, две полностью идентичные сущности только увеличивают энтропию.

Самый распространенный случай использования в scheme - conditions.

(define (factorial number)
  (cond
    [(= 0 number) 1]
    [(= 1 number) 1]
    [(* number (factorial (sub1 number)))]))

То же, что и ((a b) (x y)) — последнее зависит от контекста.

Конкретно я имел в виду нечто вроде http://chicken.wiki.br/Pattern%20matching

я и спрашиваю, к процедурам это тоже относится? если так, то по-моему только во вред.

(foo [bar [+ 3 2]]) ;? первое, что бросается в глаза, если так написали, значит есть разница в ходе выполнения... к примеру аппликативная модель и какая-то другая.

Может относиться, может не относиться, по воле автора.

Уточню вопрос — в каких случаях такая замена (другие скобки при том же смысле) смотрится адекватно?

смотрится адекватно?

уж точно не когда под ними понимается одно и тоже

Я полностью одобряю то, как это сделано в clojure. Делать квадратные скобки идентичными круглым не имеет смысла - слишком расточительно.
Да и вообще, синтаксис лиспа заслуживает жизни. sexp-ы годятся только как внутреннее представление кода после синтаксического разбора, да и то - сомнительно. Может быть, какой-нибудь JSON подошёл бы лучше на эту роль. Примеры хороших лиспообразных синтаксисов - это Mathematica и Prolog.

Лучше заменить их на мета-exp'ы.

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

Вы сейчас серьёъно? sexp намного удобнее *и* компактнее JSON и для AST и для иерархических данных.

Одни скобки менять на другие незачем

> Вы сейчас серьёъно? sexp намного удобнее *и* компактнее
Я не говорю конкретно про JSON. Может быть, например, лишними являются кавычки вокруг идентификаторов. Скульные «quoted identifiers» мне ближе. Т.е., отличать символ от строки я считаю нормальным. Но, в целом, если у нас просто список и если у нас отображение, то логично иметь для них разные синтаксисы, причём, для отображения - что-то типа [a=b, c=d] или [a:b;c:d]. Так и читать легче, и ошибку при записи сделать труднее. А компактность - та же, правда, требуется другой лексер, чем в лиспе. Тут же логично отображение задавать другими скобками. Во-вторых, имея шесть закрывающих скобок, в них легче ориентироваться, если они не все одинаковые. Тогда в некоторых случаях даже без EMACS становится возможно понять, какая скобка относится к чему. Я не знаю, как Вы,а я, например, очень редко могу без EMACS написать лисповую функцию без ошибок, хотя я пользуюсь лиспом каждый день. То же я слыхал про какого-то Гуру, который ошибался со скобками, выписывая лисповые формы на доске для студентов. Почему-то в случае Паскаля или С таких проблем у меня нет, поэтому - нет, я не считаю вообще s-выражения хорошим синтаксисом.

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

В общем-то, лисп - это целостная и развитая система. В ней довольно сложно что-то поменять, не потеряв какие-то возможности (я пробовал и результат меня не устраивает). Касаемо квадратных скобок - они задействованы во многих DSL. Поменяв их, мы сразу ломаем эти DSL. Поэтому, можно было бы говорить об использовании квадратных скобок только в каком-то новом языке. Правда, тогда всё равно остаётся вопрос, какие скобки оставить пользователю для его DSL-ей. В clojure цена за разнообразие скобок высока - там вообще нет подобных Common Lisp средств изменения лексического анализатора (хотя я смотрел её год назад).

>Это противоестественно, две полностью идентичные сущности только увеличивают энтропию.

Уточню вопрос — в каких случаях такая замена (другие скобки при том же смысле) смотрится адекватно?

уж точно не когда под ними понимается одно и тоже

В математике в сложных выражениях используют квадратные скобки и значат они одно и то же. И никто не плачится. Да и вообще это удобно.

> В математике в сложных выражениях используют квадратные скобки и значат они одно и то же. И никто не плачится. Да и вообще это удобно.

Ага, конечно. (1; 2] и [1; 2), (a, b) и {a, b} - принципиально разыне вещи.

http://en.wikipedia.org/wiki/M-expression

Ы?

>средств изменения лексического анализатора

ИМХО их лучше вообще не трогать.

>> В математике в сложных выражениях используют квадратные скобки и значат они одно и то же. И никто не плачится. Да и вообще это удобно.

Ага, конечно. (1; 2] и [1; 2), (a, b) и {a, b} - принципиально разыне вещи.

Не передергивай. [(2+2)*(3+3)] и ((2+2)*(3+3)) - одно и то же.

> ИМХО их лучше вообще не трогать.

Почему же? Очень удобно записывать in place регулярные выражения или даты или лямбды (#L) или матрицы (как scieneer) с помощью reader macros.

> Не передергивай. [(2+2)*(3+3)] и ((2+2)*(3+3)) - одно и то же.

ну да. У тебя что ль выражения только арифметические бывают? И вообще, в математике грамматика не формальная (т.е. с грамматикой ЯП сравнивать нельзя) и очень сильно зависит от контекста - те же скобки могут обозначать сотни различных вещей в различных ситуациях.

>Почему же? Очень удобно записывать in place регулярные выражения или даты или лямбды (#L) или матрицы (как scieneer) с помощью reader macros.

Когда только для себя - да, удобно. Но потом другой человек, разбираясь с твоими reader macros, получит незабываемые впечатления. :-(

> Когда только для себя - да, удобно.

Почему же? Я же тебя привел в пример широко используемые ридер макры, которыми пользуются вполне успешно.

Но потом другой человек, разбираясь с твоими reader macros, получит незабываемые впечатления. :-(

Это проблема отдельно вязтого говнокода, а не ридер-макр как средства выразительности ЯП.

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

Ключевое слово - «широко используемые», т. е. принятые сообществом.

Это проблема отдельно вязтого говнокода, а не ридер-макр как средства выразительности ЯП.

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

> Ключевое слово - «широко используемые», т. е. принятые сообществом.

И что дальше?

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

Как, как - договариваться. Только я не пойму, какое отношение эта выдуманная ситуация имеет к ридер макрам?

>Только я не пойму, какое отношение эта выдуманная ситуация имеет к ридер макрам?

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

>Как, как - договариваться.

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

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

Тем, что они могут затруднять понимание кода другими. Ну и обе относятся к синтаксису, естественно.

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

плохонаписанная функция может затруднять понимание кода другим.

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

плохоназванная переменная может затруднять понимание кода другим.

плохой комментарий может затруднять понимание кода другим.

Так что теперь от всего этого отказаться? Не выплескиваем ли мы с водой младенца, отказавшись от ридер-макр?

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

Система с read-макросами была разработана в те времена, когда о повторном использовании вообще никогда ничего не слышал. В данный момент модифицировать *readtable* очень опасно. Её модификация возможно только в широко известных, распространенных библиотеках, и то, подходить к этому надо очень осторожно.

В данный момент, основная возможность широкого применения read-макросов - это считывание из потока/файла сериализованных данных. Но, это не требует модификации *readtable*, ибо можно сделать её копию, модифицировать это копию по собственному усмотрению, и выполнять операции чтения с этой копией. В таком контексте говорить о [] много смысла нет, ибо в чём от них может быть польза не понятно.

Надо на эту тему пост написать, как раз у меня хороший пример есть :)

Да, модификация лексера на основе *readtable* давно надо поменять. В *readtable* нет стандартно определенного способа ввести свой символ (symbol) для диспетчеризации вызова функции чтения.

Есть даже несколько проектов, пытающихся это исправить — например, named-readtable.

Лучше сразу скажи, что неосилил. Было бы оно нужно - давно бы исправили.

Может anonymous поделиться тайными знаниями? раз осилил, то и людям неплохо было бы рассказать...

Было бы оно нужно - давно бы исправили.

И много в языке было исправлено за последние 15 лет? Или его ясновидящие писали на сотни лет вперёд и вещей устаревших там просто нет?

Да ладно, все нормально с ридер-макросами.
Хороший пример использования - библиотека RDNZL.

> Да ладно, все нормально с ридер-макросами.
Так что будем делать с конфликтами при использовании нескольких библиотек?

см. rdnzl/reader.lisp

>Может anonymous поделиться тайными знаниями? раз осилил, то и людям неплохо было бы рассказать...

Ясен пень, делать опциональными. То есть включать как top-level form в файле. Пример - cl-interpol.

Так что будем делать с конфликтами при использовании нескольких библиотек?

См. выше. Удивляет постоянство, с каким бедному лиспу приписывают все смертные грехи. =)

> То есть включать как top-level form в файле.

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

Удивляет постоянство, с каким бедному

лиспу приписывают все смертные грехи.

Кажется я в подобном замечен не был, или просто забыл?

> см. rdnzl/reader.lisp

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

http://paste.lisp.org/display/92631

и вот кусочек из rdnzl/specials.lisp

(defvar *previous-readtables* nil
  "A stack which holds the previous readtables that have been pushed
here by ENABLE-RDNZL-SYNTAX.")

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

http://weitz.de/cl-interpol/#enable-interpol-syntax

(defun %enable-interpol-syntax ()
  "Internal function used to enable reader syntax and store current
readtable on stack."
  (push *readtable*
        *previous-readtables*)
  (setq *readtable* (copy-readtable))
  (set-dispatch-macro-character #\# #\? #'interpol-reader)
  (values))

(defun %disable-interpol-syntax ()
  "Internal function used to restore previous readtable." 
  (if *previous-readtables*
    (setq *readtable* (pop *previous-readtables*))
    (setq *readtable* (copy-readtable nil)))
  (values))

(defmacro enable-interpol-syntax ()
  "Enable CL-INTERPOL reader syntax."
  `(eval-when (:compile-toplevel :load-toplevel :execute)
    (%enable-interpol-syntax)))

(defmacro disable-interpol-syntax ()
  "Restore readtable which was active before last call to
ENABLE-INTERPOL-SYNTAX. If there was no such call, the standard
readtable is used."
  `(eval-when (:compile-toplevel :load-toplevel :execute)
    (%disable-interpol-syntax)))

Я не знаю, как Вы,а я, например, очень редко могу без EMACS написать лисповую функцию без ошибок, хотя я пользуюсь лиспом каждый день. То же я слыхал про какого-то Гуру, который ошибался со скобками, выписывая лисповые формы на доске для студентов. Почему-то в случае Паскаля или С таких проблем у меня нет, поэтому - нет, я не считаю вообще s-выражения хорошим синтаксисом.

Очень помогает грамотная расстановка разрывов строк и отступов. Скобки это вспомогательный элемент.

>Очень помогает грамотная расстановка разрывов строк и отступов. Скобки это вспомогательный элемент.

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

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

Студенты и сами допишут, если нужно будет.