Другой взгляд на S-выражения ( gist.github.com )
Здесь программист на Lisp.
Традиционные S-выражения по своему определению игнорируют большую часть пробелов; кроме того, чтение sexeprs всегда является линейной операцией без необходимости возврата более чем на один символ.
Предложение из этого поста нарушает оба предположения, вводя двумерную структуру в код. Если цитировать примеры из этого поста, то требуется многострочная строка в
(fst-atom “”” trd-atom) 00001 00002 00003 “”” для полного считывания перед TRD-ATOM. Это также заставляет функцию считывания прыгать вертикально вверх и вниз для считывания структуры в
* ( ) * e ( ) ( ) * qm ( ) p ( ) * uaaoa 2 * lw * Автор также утверждает, что
(eq (mul (aa)) (pow (a 2))) менее читабельно, чем
* ( ) * *eq* ( ) ( ) * *mul* ( ) *pow* ( ) * *a* *a* *a* *2* * * Затем следует заключительный отрывок:
> мы надеемся, что введенная сложность оправдана читаемостью данных, выраженной таким образом.
Я не могу заставить себя воспринимать этот пост иначе, как очень неудачную шутку в стиле Бефангеса.
Да, это, должно быть, шутка!
Я видел десятки попыток сделать S-Exp «лучше» даже оригинального M-Exp. Я также провел несколько экспериментов сам. Но в конце я возвращаюсь к goo'ol s-exp. Кажется, это максимум (или минимум), найденный случайно.
Это становится хуже/лучше. Поскольку Racket позволяет вам подключать свой собственный считыватель перед (или вместо) считывателя по умолчанию, вы можете иметь такие вещи, как 2D-синтаксис:
#lang 2d ракетка (требуется 2d/match) (определить (подтип? ab) #2dmatch ╔══════════╦═════════╦════════╦═════════╗ ║ ab ║ 'Целое число ║ 'Действительное число ║ 'Комплексное число ║ ╠═════════╬═════════╩════════╩════════════╣ ║ 'Целое число ║ #t ║ ╠═════════╬══════════╗ ║ ║ 'Вещественное число ║ ║ ║ ╠═════════╣ ╚════════╗ ║ ║ 'Комплекс ║ #f ║ ║ ╚═════════╩═══════════════════════╝) https://docs.racket-lang.org/2d/index.html
Спасибо, что вернули мне здравомыслие. Был немного сбит с толку ценностью, добавленной автором.
Обычное дерево было бы легче читать
экв муль pow aaa 2
Я буду использовать свою ужасную JSONификацию S-выражений. Мне как-то нравилось иметь два вида фигурных скобок [прямые] и {кудрявые} для различения массивов и объектов, и у меня был основанный на цикле событий “параллельный” планировщик, работающий над обработкой дерева, как только будут выполнены предварительные условия. Возможно, я когда-нибудь снова займусь старым проектом, просто я зациклился на том, как я хотел обрабатывать всплывающие ошибки.
С помощью вертикального шрифта, например, японского, вы можете легко повернуть всю программу на 90 градусов вправо (как показано в нижней части целевой страницы).
https://web.archive.org/web/20240904091932/https://lookalive…
{ “#!join”: [ [ “Треугольник со стороной “, “#& сторона”, ” и основанием “, “#& основание”, “имеет гипотенузу”, { “#!sqrt”: [ [ { “#!sum”: [ [ “#!умножить сторону сторону”, “#!умножить основание основание” ] ] } ] } ] ] }
Схожий, но совсем не тот же самый, Racket имеет 2D-синтаксис (режим дополнения), который предоставляет другой способ программирования таблиц, где выходные данные зависят от двух разных входных данных.
https://docs.racket-lang.org/2d/
Это определенно расширения, которые можно добавить к S-выражениям, с этим никто не может не согласиться.
Для очень больших значений «несколько своеобразно»…
Опустим скобки:
(eq (mul (aa)) (pow (a 2))) становится
экв муль аа сила а 2
Как программист на Lisp, я просто нет.
Это хорошо и интересно, но я думаю, что в S-выражении не хватает не фанкового вертикального синтаксиса, а способа напрямую представлять объекты, которые не являются списками. В противном случае нужно придумать какое-то представление поверх S-выражений (и тогда список уже не обязательно будет списком; все проходит через дополнительный уровень кодирования/декодирования, теряя элегантность S-выражений), или использовать какой-то синтаксис расширения (обычно включающий '#'), который варьируется от языка к языку и может даже не интерпретироваться читателем (но логически расширяется до некоторого выражения списка, которое нужно будет интерпретировать снова позже, так что вы на самом деле не лучше, чем с первым подходом).
Мне бы хотелось что-то вроде того, чтобы позаимствовать синтаксис, похожий на JSON, и сгладить проблемы с пространством имен:
(foo . {type: listy-cons-cell head: bar tail: (baz quux)}) …что было бы другим способом сказать (foo bar baz quuz), но позволило бы представить любую структуру данных на том же уровне, что и атомы, строки и списки.
См. синтаксис Clojure reader: https://www.clojure.org/reference/reader
В дополнение к спискам, символам и ключевым словам вы можете иметь векторы, хэш-карты и наборы.
Source: news.ycombinator.com