![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Белорусский налоговый учет
и бухгалтерия выкушают мой моск.
Кто-нибудь знает:
1) Что и в каком порядке изучать, чтобы написать интерпретатор Хаскеля?
2) Где взять готовый встраиваемый интерпретатор?
:)
Кто-нибудь знает:
1) Что и в каком порядке изучать, чтобы написать интерпретатор Хаскеля?
2) Где взять готовый встраиваемый интерпретатор?
:)
no subject
no subject
no subject
2) http://haskell.org/haskellwiki/Ghc_as_a_library
Вот. ;)
no subject
no subject
На самом деле, я как раз хочу избежать FFI и реализовать взаимодействие с БД и еще кой-какими внутренностями внешней программы так, как будто это родной модуль хаскеля, в крайнем случае, завернув его в монаду, аналогичную IO.
Тут в натуре министерство по налогам и сборам вместе с бухгалтерами сошло с ума и требует ведомости, для которых есть три варианта реализации:
1) написать вручную алгоритм, который будет грузить первичные данные из БД, их обрабатывать совершенно необъяснимым образом и потом вручную собирать выходную печатную форму. тысячи строк несамоочевидного кода
2) факторизовать код на выполняемый частично в SQL, частично в обычном языке, частично в скриптах печатной формы. Это сейчас оно реализовано так. Объяснить нормальному человеку, как ЭТО работает, будет очень сложно.
3) Прикрутить к этому Haskell-based DSL, который бы все, от загрузки из БД до генерации печатной формы делал сам. Очень сложно сначала, зато было бы гораздо проще потом и на веки вечные.
no subject
no subject
no subject
no subject
Ты опиши поточней, что тебе надо, попробуем.
no subject
А уж если вспоминать про оптимизацию, то вообще крышей поехать можно. Я периодически пытаюсь представить себе, как можно было бы оформить БД и запросы к ней (R-tree для оптимизации пространственных запросов это частный случай такого) на хаскеле таким образом, чтобы их оптимизацией занимался движок, на основе предыдущих запросов и информации о типе.
no subject
Вкратце, идея такая: неким образом при компиляции подгружается схема БД(и, возможно, предопределенный набор запросов к ней) и из нее генерируется модуль, экспортирующий содержимое этой БД в совместимом с хаскелем виде. Т.е. таблица представляется в виде списка, а поскольку списки у нас ленивые - мы получаем обычную итерационную обработку таблицы. Запросы представляются в виде функций от параметров запроса тоже к спискам.
Сейчас из похожего я видел только HaskellDB, который для работы генерирует такой модуль своей какой-то утилитой, и вроде работает только через ODBC.
Затем мы это дело обрабатываем как нам в голову взбредет, обычным хаскелевым кодом, получаем некие выходные данные.
И эти выходные данные далее должны быть представлены в виде либо экранной либо печатной формы. Экранную по идее можно свести к печатной, а вот печатную желательно представить в строго типизированном виде и тоже желательно генерить хаскелевым кодом, это поможет избежать множества проблем - и меток пропущенных не будет, и ручная генерация произвольных форм возможна будет и логику составления от внешнего вида отделить проще.
Такое реализовать, насколько я себе представляю, достаточно сложно, поэтому я уже давно над этим думаю, но к реализации приступить не хватает мозга и времени.
no subject
Тут больше newtype нужно, имхо.
Никогда не видел пространственных запросов... но думаю, что преждевременная оптимизация -- это зло, как и преждевременный рефакторинг. Действительно крыша едет, если все сразу делать.
no subject
Вот та же реляционная теория - она придумывалась именно как средство разделить физическую структуру данных и их логическую структуру. Но, тем не менее, до сих пор при проектировании БД приходится учитывать потенциальные способы доступа к данным и подгонять индексы, а иногда и поступаться нормализацией, ради скорости работы.
no subject
no subject
no subject
*шутка есичо*
no subject
no subject
"Месье знает толк в извращениях!"
no subject
no subject
(Anonymous) 2009-04-11 04:10 am (UTC)(link)--
xaep
no subject
no subject
no subject
no subject
Хотя мне кажется, было бы круто иметь EDSL с синтаксисом SQL поверх HDBC.
Т.е. пишешь обычный SQL запрос, который возвращает ленивый список кртежей...
no subject
no subject
HaskellDB так же как и SQL основан на реляционной алгебре, но таки не sql.
Поэтому, какими-нибудь расширениями SQL для конкретного сервера не воспользуешься, а в случае SQL-EDSL всегда можно сделать бакенд максимально близким к конкретному диалекту.
Ну и планка входа в случае SQL-я существенно ниже - документации горы, в отличии от...