История изменений

Если брать CL reader macros, то у тебя получается путаница в использовании слова «символ» в значениях symbol и character.

Отнюдь. Ассоциировать reader macros не с сочетаниями букв, а именно с symbol - это такая фишка. Средство придать reader macros должную масштабируемость. Поскольку букв очень мало, а символов сколько хочешь.

Она включена в библиотеку budden-tools и кто-то (кажется, как раз monk) стащил её в библиотеку advanced-readtable. Хотя на comp.lang.lisp, если я правильно понял, были и другие корреспонденты, которые пользовались такой фичей. Я у себя в коде пользуюсь, на данный штук 10 разных символов-ридмакросов в общей сложности использовал за всю историю. Например, в программе расчёта Стирлинга символ mo:|[| используется для обращения к массиву. meta-parse:|[| служит для описания рекурсивных лексеров. Оба они спокойно уживаются в одной таблице чтения.

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

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

Может быть, в каком-нибудь Расте, Голанге, Ракетке или Котлине сделан лучши ридер?

Попробую ещё кастануть lovesan.

И в твоём примере с ЭсКуЭль непонятно, чем это отличается от обычного вызова функции, которая парсит строку запроса.

Там написано. Можно уже во время чтения провести лексический разбор SQL. Во-первых, можно сразу найти в нём, скажем, несбалансированные одинарные кавычки и круглые скобки.

Если ридер вызывается из IDE, то можно на основании лексического анализа разрисовать ключевые слова SQL (ридер уже будет знать, что это именно SQL и ничто иное). Зарядить в работу completion по объектам базы данных, если у нас есть копия метаданных.

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

Если брать CL reader macros, то у тебя получается путаница в использовании слова «символ» в значениях symbol и character.

Отнюдь. Ассоциировать reader macros не с сочетаниями букв, а именно с symbol - это такая фишка. Средство придать reader macros должную масштабируемость. Поскольку букв очень мало, а символов сколько хочешь.

Она включена в библиотеку budden-tools и кто-то (кажется, как раз monk) стащил её в библиотеку advanced-readtable. Хотя на comp.lang.lisp, если я правильно понял, были и другие корреспонденты, которые пользовались такой фичей. Я у себя в коде пользуюсь, на данный штук 10 разных символов-ридмакросов применяю.

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

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

Может быть, в каком-нибудь Расте, Голанге, Ракетке или Котлине сделан лучши ридер?

Попробую ещё кастануть lovesan.

И в твоём примере с ЭсКуЭль непонятно, чем это отличается от обычного вызова функции, которая парсит строку запроса.

Там написано. Можно уже во время чтения провести лексический разбор SQL. Во-первых, можно сразу найти в нём, скажем, несбалансированные одинарные кавычки и круглые скобки.

Если ридер вызывается из IDE, то можно на основании лексического анализа разрисовать ключевые слова SQL (ридер уже будет знать, что это именно SQL и ничто иное). Зарядить в работу completion по объектам базы данных, если у нас есть копия метаданных.

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