Опердень и паттерн-матчинг.

[metaclass]

А поимею-ка я вам мозг классической задачкой из любой опердени.
Дано: в базе данных есть таблица фактов (проводки, платежи, вообще любые первичные операции). В таблице обычно имеется дата-время операции, сумма, и куча полей с аналитическими кодами (от кого, кому, дебет-кредит, тип операции, итд).

И есть набор правил, согласно которым эта таблица раскладывается по статьям некоего выходного отчета который ложится на стол Президенту РБ, т.е. к примеру "все проводки с типом операции 126 относятся на статью затрат "Цех забоя и переработки свинины", за исключением проводок со счета 91, который относится на статью затрат "Цех забоя и переработки лошадей"". В таких правилах обычно проверяется где-то 5-10 условий на значения полей записи операции, самих правил может быть порядка сотни штук. И правила могут меняться, например в 2008 году переработка лошадей и свиней делилась на две статьи, а в 2009 министерство статистики решило, что достаточно одной статьи "забой любого скота", но обязательно детализированной по фазам луны.

И вот как бы вы такое решали?

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

PS: Здесь немного объяснено, что имеется в виду под "грехом собственного языка".

Comments

[permea-kra.livejournal.com]

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

В вашем случае есть F#, который родственен окамлу и должен обеспечивать приемлимую степень изоляции и разумный набор правил.

[metaclass.livejournal.com]

Звучит привлекательно, за исключением того, что я не совсем понял, "куды здесь лошадь запрягать".
Мы встраиваем хаскель себе? Как мы с ним будем взаимодействовать - т.е. передавать ему данные и получать результат?

[permea-kra.livejournal.com]

Я пишу исключительно на хаскеле, так что для меня вопрос интеропа не стоит - программка в рантайме подцепит модуль, вытащит из него функцию про генерацию отчёта по имени и будет с ней работать (всё средствами http://hackage.haskell.org/package/hint). Поскольку вы пишете на .Net, то хаскель для вас отпадает, зато можно поискать аналогичной функциональности для F#. Посколькольку я краем уха слышал про REPL для него, есть мнение, что инструмент вроде hint должен быть.

[metaclass.livejournal.com]

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

[permea-kra.livejournal.com]

FFI- это грустно. Может оказаться удобно перехватить сеанс ghci, возможно, чуток подрихтованный. (по такому принципу устроен emacs mode для Agda2). Благо какой-то интерфейс к базам у хаскеля есть, так что с базой он в случае чего сможет работать самостоятельно, тогда морде останется только gui.

[permea-kra.livejournal.com]

К слову, тут выше XML+XSLT предлагали, я такого делать не буду, но предлагаю посмотреть на два XQuery-движка - xqills и qt-шный. Если я правильно помню, им можно подсунуть кастомную реализацию DOM'а. Тогда можно будет писать запросы на XQuery, а он всё-же достаточно удобен.

[permea-kra.livejournal.com]

s/xqills/xqilla/

[tonal.myopenid.com (from livejournal.com)]

В данном случае интероп будет не сложным: отдать поток символов (текст DSL) на обработку и получить назад поток символов (SQL).
Для простоты и отладки можно начать с простого консольного приложения. :)