Белорусский налоговый учет
и бухгалтерия выкушают мой моск.
Кто-нибудь знает:
1) Что и в каком порядке изучать, чтобы написать интерпретатор Хаскеля?
2) Где взять готовый встраиваемый интерпретатор?
:)
Кто-нибудь знает:
1) Что и в каком порядке изучать, чтобы написать интерпретатор Хаскеля?
2) Где взять готовый встраиваемый интерпретатор?
:)
no subject
Ты опиши поточней, что тебе надо, попробуем.
no subject
Вкратце, идея такая: неким образом при компиляции подгружается схема БД(и, возможно, предопределенный набор запросов к ней) и из нее генерируется модуль, экспортирующий содержимое этой БД в совместимом с хаскелем виде. Т.е. таблица представляется в виде списка, а поскольку списки у нас ленивые - мы получаем обычную итерационную обработку таблицы. Запросы представляются в виде функций от параметров запроса тоже к спискам.
Сейчас из похожего я видел только HaskellDB, который для работы генерирует такой модуль своей какой-то утилитой, и вроде работает только через ODBC.
Затем мы это дело обрабатываем как нам в голову взбредет, обычным хаскелевым кодом, получаем некие выходные данные.
И эти выходные данные далее должны быть представлены в виде либо экранной либо печатной формы. Экранную по идее можно свести к печатной, а вот печатную желательно представить в строго типизированном виде и тоже желательно генерить хаскелевым кодом, это поможет избежать множества проблем - и меток пропущенных не будет, и ручная генерация произвольных форм возможна будет и логику составления от внешнего вида отделить проще.
Такое реализовать, насколько я себе представляю, достаточно сложно, поэтому я уже давно над этим думаю, но к реализации приступить не хватает мозга и времени.
no subject
Хотя мне кажется, было бы круто иметь EDSL с синтаксисом SQL поверх HDBC.
Т.е. пишешь обычный SQL запрос, который возвращает ленивый список кртежей...
no subject
no subject
HaskellDB так же как и SQL основан на реляционной алгебре, но таки не sql.
Поэтому, какими-нибудь расширениями SQL для конкретного сервера не воспользуешься, а в случае SQL-EDSL всегда можно сделать бакенд максимально близким к конкретному диалекту.
Ну и планка входа в случае SQL-я существенно ниже - документации горы, в отличии от...