Лисп или Питон

SQL - действительно очень высокоуровневый язык, а вот добавляет ли к его уровню что-то префикс «S-» - вопрос открытый.

А S-SQL имеет только одну цель - быть представлением SQL в s-выражениях. Так что это то же самое с возможностью использовать CL формы и переменные в этом DSL. В случае вашего подхода используется родное представление, а возможность использовать CL формы достигается шаблоными вставками.

Названный тобой перечень ошибок явно не полон и ошибки типа «неверный идентификатор» из него исключены зря.

Невнимательно прочли - я сказал что s-выражение с невалидными операторами или другими неправильными элементами этого DSL просто не скомпилируется в строковое представление. Всё остальное вами перечисленное это уже из области семантики самого SQL и оно связано с логикой - транслятор DSL действительно не может за всем этим следить. Его задача довольно проста - переводить AST для SQL (запрос записанный в s-выражениях это рафинированный смысл запроса, очищеный от синтаксиса (и разных закорючек :), но наделённый той же семантикой) в специфичную строковую форму.

Так что же ты выиграл в итоге?

Э.. Ничего :) Я подключаюсь к базе, как и вы. Но только другим способом. Я использую готовую библиотеку которую поддерживают > 1 человека, а вы сделали с нуля своё решения. Я выше написал, что подход с трансляцией из s-синтасиса и шаблонный подход - это два разных способа делать одно и то же, тут не о чем спорить.

Насчёт точечного доступа - а он вам так понадобился именно в связи с шаблонной работой с firebird кодом? Ведь если да, то можно сделать разбор a.b.c частью лексера (наряду с :: и ~~) без изменения самого ридера CL.

Я не сторонник переключений, это неудобно.

Ну вы же переключаетесь в пакеты с помощью in-package (shadow, опять же), почему бы не переключатся в таблицу чтения, раз уж ваш ридер может сломать код вроде

(defun foo.some (a)
  ...)

(или не сломает?)

и код вроде

(defun a^2+b (a b)
  (+ (expt a 2) b))

Да игнорь сколько угодно, шизофреник.

Насчёт точечного доступа - а он вам так понадобился именно в связи с шаблонной работой с firebird кодом?

Нет, он вообще нужен для работы со структурами. В общем, я уже переделал на ^, хотя кое-где остались старые вызовы через ., но они сделаны в предыдущей версии того же макроса и я их со временем тоже вычищу. Тем временем, вскрылись ещё одни грабли: если я считаю символ |A^B| и напечатаю его, то он напечатается, как A^B и при последующем повторном чтении считается как (--> a b). Неприятность, но придётся пережить.

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

Да, но только моё решение облегчает мою работу, а твоя библиотека создаёт лишнюю работу на пустом месте. Это как мы с тобой переводили бы всё подстрочником на Украинский и писали на-форуме по-Украински. Чтобы при чтении потом опять перевести на Русский. На том, например, основании, что у нас в роду были Хохлы (у меня были) и что мы должны быть верными предкам.

(или не сломает?)

|FOO^SOME| - не сломает. FOO^SOME - сломает, поэтому я и перешёл с точки на карат. В целом, я гружу чужие библиотеки в обычной таблице чтения, потом переключаюсь в свою. В каждом моём файле после in-package стоит in-readtable (на самом деле, есть ещё meta-parse со своей таблицей чтения и у меня на данный момент две таблицы). Для чужой библиотеки можно сделать in-readtable в asdf before- методе, но я на данном этапе гружу все чужие библиотеки сначала.

(defun a^2+b (a b)
  (+ (expt a 2) b))

Когда я пойму, что мне такой код нужен и нельзя без него обойтись, я прикручу инфиксный ридер. И будет это выглядеть примерно так: (%% a^2+b), а вовсе не (a^2+b a b). Если такая функция попадётся в библиотеке, то (|A^2+B| a b).

> на Украинский ... по-Украински. ... на Русский.

Диагноз поставить?

лисп чудесен и хорош, да только привязок к гуйни у него вроде кроме страшного tk и древнего gtk нету и не будет никогда

CL-GTK2, CommonQt. Не говоря уж про LW/CAPI.

Clojure! ;-)

Строить здание на хлипком фундаменте оракловской джавы как-то палевно :)

Common Lisp. Это круто. +20 к элитности, и сможешь троллить на ЛОРе вайтспейс-быдлокодеров.

P.S. тех, кто предлагает Питон, не слушай - это малограмотное быдло, которое пытается отвратить тебя от сияющих вершин CL.

Всё правильно сказал!

Haskell, однозначно

Говорят, единственная оплачиваемая работа в рунете, связанная с Хаскелем, закреплена за thesz. И то, менеджеры боятся его выгнать, потому что он, при всей своей неуравновешенности, штангу качает, отжимается на бутылке и регулярно публикет в ЖЖшечке фотографии страшных мускулов.

Вот тут http://lisper.ru/forum/thread/186, и разницы не заметил.

Если я всё правильно понял, то тест - полнейший бред.

Ты один раз добираешься до массива в слоте объекта структуры или класса и работаешь над этим массивом. Работа заключается в последовательной записи в массив. Т.е. ведётся измерение того, как хорошо процессор борется с трансляцией адресов, загрузкой строк кэша и т.п. А так как набор данных одинаков, плюс алгоритм ни капли не отличается, то ты получил сходные результаты.

Я буквально на днях спорил на эту же тему с начальником, и в LW 6.0.1 доступ к слотам структур оказался всего в два раза быстрее, чем к слотам объектов CLOS. В принципе, да и на практике, компилятор может сгенерировать практически такой же быстрый акцессор для классов, как и для структур. Игра с экономией на структурах действительно не стоит свеч, но твой тест всё равно неправильный :)

Perl, однозначно!

менеджеры боятся его выгнать

я их понимаю

>Я буквально на днях спорил на эту же тему с начальником, и в LW 6.0.1 >доступ к слотам структур оказался всего в два раза быстрее, чем к >слотам объектов CLOS.
А кстати, сохранится ли столь малый разрыв, если слотов будет много? Или если сам акссесор содержит много методов? Как внутри реализованы слоты? Ну и, учитывая, что это одна из основных операций, мне кажется, что два раза - это два раза (как сказал Вовочка в анекдоте).

Скорость, несомненно, деградирует. С фичами CLOS нехорошо надеяться на какую-то там скорость.

есть closer-mop:standard-instance-access, которая, фактически, эквивалентна svref

Вот как нужно делать вбросы! Автора уже нет, а тред живет.

есть closer-mop:standard-instance-access, которая, фактически, эквивалентна svref

svref - это, по задумке комитета, одна машинная команда. Поэтому у simple vector такое расплывчатое определение, чтобы на каждой архитектуре свои органичения были. Всё ради доступа к элементу simple vector одной машинной командой.

В случае с CLOS одной командой не отмашешься.

> С фичами CLOS нехорошо надеяться на какую-то там скорость
Спасибо, а то тут некоторые одержимые идеей «CL идеален» типа love5an уже приблизились к тому, чтобы убедить меня в том, что со скоростью CLOS всё ОK.

плюс алгоритм ни капли не отличается

В том-то и дело что отличаются, есть разные способы доступа к слотам и они могут даже по-разному работать для структур и классов, поэтому что-то может быть дешевле, что-то дороже (в целом всё равно O(1), но всё-таки). Например, некоторое время назад в SBCL (slot-value s 'a) было хуже чем (foo-a s), где s - структура foo, но начиная с 1.0.30.40 они перестали отличаться (там забавно выхватывается информация о типах во время компиляции и форма slot-value замещается формой аккесора).

Теперь

(defstruct foo a b)

(disassemble #'(lambda () (let ((s (make-foo :a 1 :b 2))) (slot-value s 'a))))
(disassemble #'(lambda () (let ((s (make-foo :a 1 :b 2))) (foo-a s))))

Можно видеть одинаковые листинги без вызовов лишних функций, а вот для классов:

(defclass bar ()
  ((a :initarg :a :initform nil :accessor bar-a)
   (b :initarg :b :initform nil :accessor bar-b)))

(disassemble #'(lambda () (let ((c (make-instance 'bar :a 1 :b 2))) (slot-value c 'a))))
(disassemble #'(lambda () (let ((c (make-instance 'bar :a 1 :b 2))) (bar-a c))))

листинги разные, кроме того в них есть лишние вызовы - в одном случае функции-аккесора, а вдругом ещё и slot-accessor.

Спасибо, а то тут некоторые одержимые идеей «CL идеален» типа love5an уже приблизились к тому, чтобы убедить меня в том, что со скоростью CLOS всё ОK.

Вообще, у каждого свои осложнения на почве CL. Самый нейтральный персонаж, наверное, dmitry_vk.

В том-то и дело что отличаются

У тебя один раз брался объект из слота, а потом крутился цикл по этому объекту. В итоге, замерял не то, что собирался.

Может быть, я уже не помню точно что там было :) Сейчас я вижу разницу в ассемблерном листинге.

> a.b

Хм, ты не одинок: http://b.lowh.net/billitch/2010/12/21/149-define-structure-with-dotted-access...

> Хм, ты не одинок
Это неудивительно, что есть ещё другие люди, которым писать и читать
(setf x.value y.value)
несколько удобнее, чем
(setf (tree-value x) (tree-value y))

Однако, моя последняя реализация на две головы выше, чем процитированная:
1. Мне не нужно перекрывать defstruct, я могу пользоваться и структурами из библиотек, если у них нет опции conc-name.
2. Объект вообще может быть не структурой, а чем угодно, например, строкой или экземпляром класса.
3. Я могу пользоваться a^b не только для слотов, но и для функций.
4. Одновременно с декларацией префикса можно декларировать и тип.
5. a^b - это лучше, чем a.b, т.к. исключён конфликт с уже существующими символами a.b, а символы a^b встречаются крайне редко (в моём образе нет ни одного).
6. Символы a^b у меня не создаются. На этапе чтения они превращаются в (--> a «b»), а это может иметь ещё и другие применения, кроме сокращения префиксов. Если бы символы a^b создавались, (как в твоей ссылке), это бы быстро засорило пакет и затруднило completion.


Я уже готовлю свой код к публикации, ещё 2-3 месяца - и он будет где-нибудь на гугле лежать.

< Есть, Ruby.

Поддерживаю!!!