Здравствуйте, vdimas, Вы писали:

V>Я знаю, но дело в том, что к концу выражения "останется" только один вариант, т.к. грамматика SQL однозначна.

Не, ну это понятно. Неоднозначные грамматики с эвристиками (типа тернарного оператора в шарпе или угловых скобок в плюсах, ты это имел ввиду?) это уже точно кандидаты на рукопашное разруливание проблем.

V> Поэтому я упомянул параллельный LR(1). В нем в месте конфликта происходит размножение текущего состояния вычислителя (полученные копии, кстати, эффективно делят стек предыдущих вычислений), затем "ошибочные ветки" умрут сами собой к концу выражения или еще раньше.

Да в LL(*), по сути, то же самое. Только вместо внешнего явного состояния стек и исключения. Суть тут одна — парсер с откатами нужен. А это уже, как мне кажется, нельзя назвать простой до безобразия грамматикой.

V>Я все время забываю, что у этой разновидности LR(k) есть собственное название GLR

GLR это скорее LR(*). k — количество лексем, на которые парсер заглядывает вперед для принятия решения. В случае откатов, сам понимаешь, к неопределено заранее. Поэтому *.

AVK>>Ты под параллельными понимаешь парсеры с откатами (параллельным разбором правил) что ли? Тогда LL(k) или LR(k) такие парсеры называть некорректно.

V>Таки LR(k) — это разбор вширь, а не вглубь, как LL(k).

Да пофик.

AVK>>В SQL'92, емнип, больше 6 сотен только для селекта. У меня, когда я выкинул все гавно типа указания кодировок и устаревших форм различных операторов, все равно больше сотни получилось.
V>Понятно... я навскидку больше пары десятков не вспомню...

Ну, sql'92 свободно доступен и правила в нем пронумерованы. Можешь сам проверить.

V>Опять же, мы же обсуждали свой собственный DSL, лишь похожий на SQL

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

V>, а разработка поддерживаемого этим DSL синтаксиса могла бы быть, скажем так, очень пошаговой.

Мне показалось в свое время проще сперва получить sql 1 в 1 по стандарту, а потом допилить нужное. Это, помимо прочего, позволило съэкономить на документации, так как достаточно дать ссылку на стандарт и описать только отличия.

V> Ведь на каждую синтаксическую конструкцию необходимо иметь работающую трансформацию.

Там много чего надо иметь. Трансформация тоже не самое сложное, хотя и похитрее парсера.

V>У меня однажды с полпинка заработала аналогичная задача, после перекидывания ее на Пролог. Т.е. захостил движок пролога в программе, скормил ему правила вывода + структуру фактических выражениq с неизвестными и он разресолвил мне все неизвестные.

ИМХО перебор. Алгоритм вывода типов для типизированного аналога сиквела тривиален — там ведь неоднозначностей никаких нет, в отличие от того же шарпа. А вот ресолвер местами довольно хитер — правила то для сиквела в стандарте отсутствуют, он, типа, динамический. Так что часть из головы надо додумывать, часть смотреть как в реальных sql серверах сделано.
Но ресолвинг это еще не все. Отдельная песня — проверка агрегатов/неагрегатов при использовании group by. Абсолютно безошибочный алгоритм мне так и не удалось придумать в итоге — там на вложенных запросах очень хитрые ситуации могут получится.

V>и сами выражения редко более чем в 2-3 уровня склыдваются

Поверь, совсем нередко.

V>Надеюсь, повторное использование разработанной технологии в разных проектах были?

В разных местах проекта. У нас всего один основной проект.

V> Ну или сам проект кастомизируемый под разных заказчиков (что фактически одно и то же)?

Хуже, это платформа типа 1С, только намного гибче и сложнее.

V>Понятно, что вложения должны давать отдачу.

Там других вариантов не было. Поддержка нескольких разных СУБД — обязательное требование.

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

Знаешь, я тоже думал схалтурить и не реализовал сперва, скажем, часть стандартных строковых функций или having. Сейчас покрытие вменяемой части SQL'92 — 100%. И висит еще куча фич, которых в sql'92 нет, но есть в реальных серверах, типа выражений в group by.

Здравствуйте, AndrewVK, Вы писали:

AVK>Хуже, это платформа типа 1С, только намного гибче и сложнее.

А, ну если про П., то для такого уровня продукта ес-но, требование покрытия функционала максимальные.
Его сейчас на чем делают, если не секрет? Когда-то, помнится, на Паскале пилили модули (местами успел поучаствовать до 94-го.)

Здравствуйте, WolfHound, Вы писали:

V>>Мифы распространяют люди без профильного образования и не потрудившиеся в самостоятельном изучении. Их меньшинство, т.е. это тоже не совсем так.
WH>Меньшинство? Фигасе. Да их тут армия.

Знаю многих спецов, не написавших сюда ни строчки.


WH>Вот только когда запрос становится чуть сложнее, чем на пару строк начинается беда.
WH>Ибо в SQL нет средств декомпозиции кода.

И не нужен. Большинство актуальных запросов формируются ТОЛЬКО динамически.... Дык, где тогда должна быть декомпозиция: в SQL или в его генераторе?


WH>>>Причем недостаток знаний фундаментальная проблема. Ибо часто пока не сделаешь хоть что-то, не поймёшь что действительно нужно.
V>>Знания тут не при чем. Это такой популярный алгоритм независимо от кол-ва знаний. Действительно, тенденция сравнивать, проверять, расчитывать и т.д. за последние лет 15 куда-то ушла. Не модно. Потому что "мощщи компов все проглотят" и прочая ересь, идущая с сегмента заказухи... которой постепенно заражалась вся индустрия.
WH>Я не об этом. Многие задачи даже нельзя сформулировать пока ты их решать не начнёшь.

Очень немногие, подходящие под исследовательские задачи. Может тебя просто больше всего в эту область тянет? Она редка, вообще-то. Большинство задач IT давно сформулированы, но даже с этой формулировкой не хотят знакомиться.


V>>Для некоторых нужд я бы променял. Только не по физической структуре, а по некоторому АПИ итерирования по данным. Из-за того, что сложные вычисления на SQL не айс, т.к. интерпретатор. А преобразовать реляционные исчисления в реляционные уравнения — не бог весть какая наука. Но это 5% сценариев от силы, т.е. в общем случае таки да, SQL рулит.
WH>А если тебе дать компилируемый, статически типизированный SQL имеющий средства декомпозиции запросов?
WH>Это ведь не так сложно.

Что значит "компиллируемый" в среде, где я могу транзакционно менять структуру базы и прогонять запросы сразу же по новой структуре? В какой момент должна произойти компиляция? Не, я прекрасно понимаю о чем речь, но сценарий использования классической СУБД совсем не тот, что новомодный сценарий хранилища объектов, который "замораживает" структуру данных. База любого мало-мальски большого предприятия постоянно развивается. А уж кол-во накопленных read-only запросов вообще может не поддаваться счету. И всё это развитие происходит "наживую". Плох тот админ, которому требуется монопольный доступ к базе для её модификации.


WH>>>Есть два десятка цветовых пространств и нужно сгенерировать код по трансформации из каждого в каждое.
V>>Там точно DSL нужен, а не таблицы составляющих и коэффициентов?
WH>Таблицами тут не поможешь. Ибо есть куча цветовых пространств преобразования, между которыми очень не линейны. Да хотябы RGB и sRGB. sRGB хорош для восприятия человеком. Но при попытке, например, отмасштабировать в картинку в этом цветовом пространстве появляется куча артефактов. Поэтому нужно переводить в RGB, масштабировать и переводить обратно. Если в картинке есть альфа-канал то там нужно еще кое что сделать. Иначе опять артефакты лезут.

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

WH>Ну и не нужно забывать, что их у меня было 22 (точно не помню) писать 484 преобразования руками, мягко говоря, не хотелось. Так что я задал только несколько преобразований и по определенным правилам сгенерировал все остальные.

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


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

А какие алгоритмы фильтрации использовал? Как боролся с шумом округления? Боролся ли с интерференцией при передискретизации (ресэмплинге?). Вносил ли аддитивный шум при преобразовании к кодировке с меньшим цветовым разрешением? А как ты вообще оценивал изменения эффективной цветовой разрешающей способности при преобразовании м/у стандартами с разными цветовой кодировкой, т.е. как узнать, большая ли получается итоговая цветовая разрешающая способность или нет? А если результат привести в координаты YUV? А если вносил аддитивный шум, как оценивал необходимую амплитуду и спектр этого шума? Использовал ли информацию об исходном DPI изображения?

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

WH>А потом еще цветовые пространства появились.
WH>Без ДСЛ я бы это не осилил.
WH>Причем ДСЛ был очень циничен. Сами цветовые пространства описывались отдельным язычком. Но вот преобразования прямо в коде на С++.
WH>После чего я пробегался по исходнику и собирал список базовых преобразований.

Ну хорошо, а можно посмотреть отрывок этого DSL? Я так думаю, что DSL тебе был нужен для экспериментов и эвристики?


V>>Ну таки даже по результатам презентации по ссылке хотелось бы увидеть что-нить на входе и что-нить на выходе.
WH>На входе программа. На выходе проезды по памяти, race condition'ы и тп. И все на основе статического анализа. Причем почти без ложных срабатываний.

Это понятно, любопытно было увидеть реальные куски кода и найденные в них ошибки. Таки семантика разных языков очень разная.

Здравствуйте, vdimas, Вы писали:

V>Его сейчас на чем делают, если не секрет?

На C#, как несложно догадаться.

V> Когда-то, помнится, на Паскале пилили модули (местами успел поучаствовать до 94-го.)

Это совсем другой продукт. У Паруса их много было и есть.

Здравствуйте, AndrewVK, Вы писали:


V>>ИМХО, SELECT оператор SQL спроектирован превосходно, т.к. обладает реляционной полнотой и при этом отличной читабельностью.

AVK>С читабельностью, увы, не очень хорошо, особенно в его оригинальной версии.

А есть примеры языков запросов с лучшей читабельностью?

Сколько я не смотрел альтернативы в своё время, ничего лучше так и не увидел. Есть неплохой язык реляционного исчисления, популярный во всякой учебной литературе вокруг СУБД, но он (1) так и не формализован до конца, хотя используется чуть ли не как стандарт, (2) это язык все-таки для профессионалов — на нем будет трудно общаться с прикладными специалистами.


AVK>К сожалению, при его разработке много чего принесли в жертву похожести SQL запросов на естественный язык.

Это и была цель. И как показала практика — цель правильная. Альтернатив много, но в мейнстриме не прижились.


AVK>Толку с того вышло немного, а вот дизайн подзасрался основательно. Надо было делать что то вроде того, что сделали в шарпе в query comprehension. Но поезд давно ушел, увы.

Почему? Альтернативы-то есть... Но вот лучшей я пока не видел.


V>>ИМХО, это хорошо, что последние годы в кремнии встряли, т.е. не ожидается такого роста быстродействия...

AVK>Да не встрял никто в кремнии. Просто у Интела исчезла в high end процессорах конкуренция и он начал искусственно тормозить прогресс.

Чтобы нагнали и нагнули?
Обсуждали уже пару лет назад. В кремний фактически уперлись. Всего в 3 раза осталось уменьшить процесс, чтобы упереться в его теоретическую границу достоверности, бо мало подвижных зарядов на единицу объема. Ну и пороговое напряжение порядка 0,8В так и не смогли на кремнии побороть, т.е. нет возможности уменьшать рабочее напряжение, а значит проблема с теплоотводом.

Я так думаю, что это "заговор".
О новых технологиях более 5-ти лет назад рапортовали все ведущие игроки, но старательно выпускают процессоры на старых технологиях до сих пор...


V>>Для некоторых нужд я бы променял. Только не по физической структуре, а по некоторому АПИ итерирования по данным. Из-за того, что сложные вычисления на SQL не айс, т.к. интерпретатор.

AVK>Итерирование по данным, видишь ли, проблематично не из-за SQL, а из-за проблемы обеспечения ACID для таких курсоров.

Даже если взять снапшот нужных данных (или их промежуточных итогов) во временные таблицы, по потом по ним нетривиальные вычисления идут относительно долго. Относительно классической скомпиллированной числодробилки.

Здравствуйте, vdimas, Вы писали:

AVK>>С читабельностью, увы, не очень хорошо, особенно в его оригинальной версии.

V>А есть примеры языков запросов с лучшей читабельностью?

Реальных, очевиджно, нет. Совместимость с sql сейчас важнее.

V>Сколько я не смотрел альтернативы в своё время, ничего лучше так и не увидел.

Да убрать из него откровенные косяки, типа select впереди from, и будет уже существенно лучше.

V>Это и была цель. И как показала практика — цель правильная.

Практика показала, что всем пофиг на похожесть. Особенно у нас, где английский никогда не был широко распространен.

V>Почему?

Потому что стандарт.

AVK>>Да не встрял никто в кремнии. Просто у Интела исчезла в high end процессорах конкуренция и он начал искусственно тормозить прогресс.

V>Чтобы нагнали и нагнули?

В таких вещах быстро не нагоняют.

V>Обсуждали уже пару лет назад. В кремний фактически уперлись. Всего в 3 раза осталось уменьшить процесс, чтобы упереться в его теоретическую границу достоверности

Ну вот как уменьшат, иогда и поговорим. А пока интел уменьшает техпроцесс с завидной регулярностью.

AVK>>Итерирование по данным, видишь ли, проблематично не из-за SQL, а из-за проблемы обеспечения ACID для таких курсоров.

V>Даже если взять снапшот нужных данных

Снапшот это невероятно дорого.

Здравствуйте, oldjackal, Вы писали:

O> А, ну да, оба из 70х. В любом случае, парсеры это далеко не главное. Драконовщина нанесла непоправимый вред в первую очередь как раз зацикленностью на парсерах.

Разве? Это была далеко не первая и далеко не последняя работа на эту тему. Просто одна из, заслуженно ставшая популярной.

Здравствуйте, vdimas, Вы писали:


V>Почему? Смотрел на boost::lambda? Они почти весь синтаксис С++ умудрились сделать как генератор работающего AST. Отличный пример того, как это надо делать и стартовая точка для своих наработок.

V>Ес-но, для каждого выражения — свой узел. Вот здесь в двойных скобках приводил в примере именно генерацию AST, которое исполняется "потом":

Не так давно зарелизился Boost.Phoenix 3.0 там практически полностью
ленивый (привет хаскелю ) встроенный в C++ DSL, и AST там гораздо богаче чем в boost::lambda, есть все конструкции языка практически,
в примере ниже они с _ в конце (if_, switch_ и т. п.)

std::for_each(v.begin(), v.end(),
    if_(arg1 > 5)
    [
        std::cout << arg1 << ", "
    ]
);

//...

std::for_each(c.begin(), c.end(),
    switch_(arg1)
    [
        case_<1>(std::cout << val("one") << '\n'),
        case_<2>(std::cout << val("two") << '\n'),
        default_(std::cout << val("other value") << '\n')
    ]
);

//...

std::for_each(c.begin(), c.end(),
    (
        while_(arg1--)
        [
            cout << arg1 << ", "
        ],
        cout << val("\n")
    )
);

Здравствуйте, VladD2, Вы писали:

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

Ширина охвата так себе. Книга хороша именно своей практичностью. Показывает как от теории переходить к практике. А так-то полно других работ из этой же области, с разной глубиной по разным темам (порой многократно глубже).


VD>Парсерам же вообще уделяется слишком много внимания в литературе посвященной компиляторам и языкам. Мне кажется это следствием того, что человечество до сих пор не нашло приемлемого решения этой проблемы. А проблема эта возникает самой первой при разработке языка.

И не найдет.
Чем "естественнее" язык, тем он неоднозначнее и сложнее для автоматического разбора. ИМХО, с ростом мощности компьютера стоит ожидать роста сложности обрабатываемых грамматик.


VD>Наука она идет путем перебора всех возможных вариантов (за счет того, что каждый аспирант ищет тему для дисера, которая не пересекается с другими дисерами).

Просто сейчас появились возможности для экспериментов, т.к. память больше не ресурс (С). Отсюда все эти эксперименты мемоизацией или распараллеливанием, немыслимые еще 10 лет назад.

Заметь, приличная часть дракона посвящена вопросам преобразования грамматик, чтобы впихнуть исходную грамматику в некие рамки, которые будут означать банальную реализуемость на технике тех лет.

Здравствуйте, AndrewVK, Вы писали:

AVK>Это совсем другой продукт. У Паруса их много было и есть.

Т.е. не 8-ка? Хорошо, а 8-ка на чем, если не секрет?

============
Просто пример Паруса был антипример в теме о "доступности" DSL, бо как раз показывает необходимый размах проекта, чтобы DSL был оправдан.

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Язык.

Ок. Я просто требование по быстродействию не зря пропустил. Любую технологию можно загнобить сказав "а-а-а. оно не может доработать за х наносекунд",
Я думаю ты спорить не будешь, что написать какой-то "эффект" на Adobe Pixel Blender будет проще, чем его же на C. А в конечном итоге оно даже работать может быстрее, просто потому, что во много кода можно напартачить.

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

Здравствуйте, vdimas, Вы писали:

V>Это пока нам не надо повторно использовать код. А то в итоге может оказаться наоборот 30 к 1 в итоге.


V>Таки я хорошо помню, что ручками делал гораздо больше, чем могу себе позволить обобщить на шаблонах С++ сегодня. И никакой оптимизации тоже не было, ес-но, было тупое сканирование файлов данных или файлов-индексов и обработка согласно самописных алгоритмов. Так же помню, что копипасты было много.
Ну так и в C++ никакой оптимизации запросов не было. Да, копипасты было полно, но у интерпретатора есть свои преимущества — насколько я помню, на клиппере были доступны всякие забавные трюки, связанные с различным поведением функций вызываемых в различных контекстах. Бест практисов я тогда не знал, и глобальными переменными пользовался в полный рост.

V>Почему? Смотрел на boost::lambda? Они почти весь синтаксис С++ умудрились сделать как генератор работающего AST. Отличный пример того, как это надо делать и стартовая точка для своих наработок.
Нет, не смотрел. И с трудом представляю себе, как это работает.

V>Ес-но, для каждого выражения — свой узел. Вот здесь в двойных скобках приводил в примере именно генерацию AST, которое исполняется "потом":
V>

V>( (_1.managerId=_2.first, _1.amount=sum(_2.second, &Order::amount)) ) 
V>

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

V>Как раз для приведенной мною ф-ии between ничего не нужно в отличие от генерации трансформаторов для проекций, продукций и пересечений, т.к. это просто перегрузка ее сигнатуры для случая на указателя на мембер, которая должна конструировать MemberBetweenPredicate (кстате, приведенный исключительно с целью показать, во что превратится вызов between).
Во-первых, придётся иметь 8 перегрузок этого предиката. Ведь никогда не знаешь заранее, на каком месте будет стоять мембер.

V>Теперь, при наличии у некоего типа, используемого для представления даты, конструктора от С-строки, можно писать еще короче:
V>

V>between("20100101", &Order::orderDate, "20101231")
V>

Во-вторых, а дальше-то что? Вот мы имеем этот предикат. Как нам использовать его для выбора индекса для сканирования?

Здравствуйте, vdimas, Вы писали:

V>На gcc, icc и многих других компиляторах получится. Причем, зависимости от CRT указывать не надо, в отличие от зависимостей от других либ, бо стандартные ф-ии обязаны работать "изкаробки". Я уже обращал внимание на то, что если другие либы надо указывать в параметрах компилятора или линкера для включения, то относительно CRT опции чуть другие по характеру — это опции отключения CRT или выбора типа CRT.
Компилятор не имеет права самовольно включать CRT в .obj — он не в курсе, сколько ещё будет единиц компиляции.

V>Это имеет отношение к твоему утверждению, что С/С++ так же подойдет на роль DSL. Не подойдет, т.к. нет каких-либо ср-в ограничить исходный код.
Я не делал такого утверждения. Я делал утверждение про то, что отсутствие импорта библиотек не помогает для DSLности, как и его наличие не помогает выйти за пределы DSLности.

V>Я не игнорирую, я вижу что ты успел забыть на какие твои вопросы я даю ответы. Ты сделал кое-какие утверждения относительно С? Я не согласился и объяснил — почему. Потому что изкаробки слишком много возможностей, даже без внешних библиотек — из-за CRT и адресной арифметики ф-ий.
Сосредоточьтесь. Я вам напомню — мы обсуждаем, годится ли "возможность использовать библиотеки" в качестве критерия DSL. Пока что выходит, что никак не годится.

V>Мы недообсуждали Лого, чтобы делать такие выводы. Я еще не увидел твоего примера целиком. Покажи предположительный синтаксис вызова произвольных внешних ф-ий для "расширенного Лого", а затем я тебе дам небольшой список экспорта, например, NT.DLL, с помощью которого можно уронить любую, самую защищенную программную среду.
Непонятно, что вы называете "произвольными внешними функциями". Мы имеем стандартный логовский синтаксис вызова функций/процедур:

FORWARD 100
LEFT 90

Плюс мы имеем стандартный синтаксис объявления функций и процедур:

TO CHAIR  REPEAT 4 [FD 100 RT 90]  FD 200  END

Плюс мы имеем команду IMPORT, которая втягивает лого-библиотеку, делая видимыми все функции и процедуры, определённые в них.
Никакого синтаксиса для загрузки NT.DLL нет.

S>>Совершенно верно. Поэтому изо всех языков, работающих с DOM, DSL-ями являются только CSS и XSLT. JS, как и С и C++, это типичный GPPL.

V>Опять по кругу... Если бы C/C++ не обладали CRT/CppRT, идущими как часть стандарта, и не имели адресной арифметики ф-ий, позволяющей передать управление куда угодно, я бы согласился. А так — нет.
То есть вы не считаете C++ языком общего назначения? Очень странно.

Здравствуйте, Vain, Вы писали:

V>Ничего такого здесь не подразумевалось. Речь шла про SQL как про DSL который можно сунуть везде и это прокатит.
Впервые об этом слышу. Кто вам сказал такую глупость? DSL, по определению, нельзя "сунуть везде".

Здравствуйте, vdimas, Вы писали:

AVK>>Это совсем другой продукт. У Паруса их много было и есть.

V>Т.е. не 8-ка?

Нет, 10-ка ака Торнадо.

V> Хорошо, а 8-ка на чем, если не секрет?

Дельфи + Оракл.

Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, AndrewVK, Вы писали:


V>>>ИМХО, SELECT оператор SQL спроектирован превосходно, т.к. обладает реляционной полнотой и при этом отличной читабельностью.

AVK>>С читабельностью, увы, не очень хорошо, особенно в его оригинальной версии.

V>А есть примеры языков запросов с лучшей читабельностью?
Linq?

Здравствуйте, Sinclair, Вы писали:

V>>Почему? Смотрел на boost::lambda? Они почти весь синтаксис С++ умудрились сделать как генератор работающего AST. Отличный пример того, как это надо делать и стартовая точка для своих наработок.
S>Нет, не смотрел. И с трудом представляю себе, как это работает.

Работает несложно. В С++ принято считать "исполняемым" любой тип с определенным в нем operator() (оператор вызова ф-ии). В общем, это обычный метод со специальным именем, типа как Invoke у делегатов дотнета.
Простой пример вот:

template<typename Value>
struct BetweenPredicate { 
  Value v1, v2; 
  bool operator()(const Value & v) { return  v>=v1 && v<=v2; } 
};

Это один из подобных самописных узлов исполняемого AST. Надо проинициализировать "замкнутые" значения v1, v2, а затем рассматривать этот объект как функтор с арностью 1.

Представь на C# value-типы с методом Invoke:

struct PlusOp<T> {
  public T arg1, arg2;
  T Invoke() { return arg1 + arg2; }  
}

Жаль, что в дотнете так нельзя, но в С++ можно. В дотнете нужно выкручиваться через какой-нить OperatorProxy<T>.Default.Plus(arg1, arg2);

S>Ну, вот уже пошёл птичий язык. Все эти подчерки и неименованные туплы читаются намного-намного хуже старого доброго SQL.

Дык, в старом добром SQL даже номеров переменных в тупле нет, он сугубо позиционный. В широких запросах пальчиком по экрану надо водить и номер аргумента считать, чтобы не промазать.
Хотя, спорить не буду, с непривычки нечитабельно.


V>>Как раз для приведенной мною ф-ии between ничего не нужно в отличие от генерации трансформаторов для проекций, продукций и пересечений, т.к. это просто перегрузка ее сигнатуры для случая на указателя на мембер, которая должна конструировать MemberBetweenPredicate (кстате, приведенный исключительно с целью показать, во что превратится вызов between).
S>Во-первых, придётся иметь 8 перегрузок этого предиката. Ведь никогда не знаешь заранее, на каком месте будет стоять мембер.

Для библиотеки не жалко. Только я бы, по праву автора библиотеки, ограничил бы вдвое, чтобы в середине всегда был мембер.


S>Во-вторых, а дальше-то что? Вот мы имеем этот предикат. Как нам использовать его для выбора индекса для сканирования?

Зависит от отображения типов на хранилище. Если используем какой-нить boost::multiindex, то на нем как раз индексы можно описать через мемберы хранимых элементов (т.е. ключ не дублируется, в отличие от std::map<> или System::Dictionary<>).

В общем, ничего нового под луной: чем меньше захардкожено в отображениии типов и соотв. хранилища под его экземпляры, тем больше потребуется метаинформации. Обычно метаинформацию о типах С++ организуют как инстансы неких описательных структур, в которых хранятся опять же указатели на мемберы типа.

Здравствуйте, WolfHound, Вы писали:

I>>Например на ней легко делать рекурсивные запросы любой глубины и сложности.
I>>На реляционной надо сначала приседать с запросом,
WH>Это зависит от языка.

И много языков умеет сервер рсубд ?

I>>потом приседать с перформансом запроса.
WH>А в объектной модели, которая маппится на реляционную БД все будет просто летать?

когда, куда и как сохранится модель персистентных объектов это дело десятое. Главное что в ней многие вещи делать проще и перформанс искаропки.

Здравствуйте, Ikemefula, Вы писали:

I>И много языков умеет сервер рсубд ?
Зачем сервер?

I>когда, куда и как сохранится модель персистентных объектов это дело десятое. Главное что в ней многие вещи делать проще и перформанс искаропки.
То-то народ плачет глядя на то как тяжёлые ОРМ тормозят.

Здравствуйте, vdimas, Вы писали:

V>>>Мифы распространяют люди без профильного образования и не потрудившиеся в самостоятельном изучении. Их меньшинство, т.е. это тоже не совсем так.
WH>>Меньшинство? Фигасе. Да их тут армия.
V>Знаю многих спецов, не написавших сюда ни строчки.
А сколько таких кого ты не знаешь?
Короче ты нерепрезентативен. Твой маааленький круг общения тоже.

WH>>Ибо в SQL нет средств декомпозиции кода.
V>И не нужен. Большинство актуальных запросов формируются ТОЛЬКО динамически.... Дык, где тогда должна быть декомпозиция: в SQL или в его генераторе?
Осталось понять, почему они формируются динамически.

V>Что значит "компиллируемый" в среде, где я могу транзакционно менять структуру базы и прогонять запросы сразу же по новой структуре? В какой момент должна произойти компиляция? Не, я прекрасно понимаю о чем речь, но сценарий использования классической СУБД совсем не тот, что новомодный сценарий хранилища объектов, который "замораживает" структуру данных. База любого мало-мальски большого предприятия постоянно развивается. А уж кол-во накопленных read-only запросов вообще может не поддаваться счету. И всё это развитие происходит "наживую".
И это вызывает массу проблем.
Все запросы должны быть проверены на соответствие новой структуре БД.
Иначе получишь вылеты в рантайме. Динамическая типизация во всей красе.

V>Плох тот админ, которому требуется монопольный доступ к базе для её модификации.
Плох тот админ, который руками в продакшен базу лезет.
Обновления в продакшен должны выкатываться только после тестирования.

V>Что значит "масштабировать"? Любой ресэмплинг неважно в какую сторону предполагает один из алгоритмов фильтрации. А фильтрация ес-но должна быть сугубо покомпонентной. Кодировки с одинаковыми компонентами отличаются от цветоразностных тем, что оперируют одной и той же частотой сглаживания и цветовой глубиной. Альфа-канал — это тоже независимая компонента, по которой над делать независимую фильтрацию.
Теоретик.
Вот что получается, если альфу игнорировать.

А так если нет.


V>Есно, достаточно одной лишь зависимости, чтобы транзитивно вывести остальные — это св-во линейности преобразований. Но этого мало, ведь при преобразовании м/у кодировками меняется цветовое разрешение.
Смешно. Ибо многие преобразования нелинейные.

V>Ну хорошо, а можно посмотреть отрывок этого DSL?
Нельзя. У меня на руках исходников нет. Они все в конторе остались.

V>Я так думаю, что DSL тебе был нужен для экспериментов и эвристики?
Нет. Для продакшена.