Белорусский налоговый учет
Apr. 10th, 2009 09:50 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
metaclassи бухгалтерия выкушают мой моск.
Кто-нибудь знает:
1) Что и в каком порядке изучать, чтобы написать интерпретатор Хаскеля?
2) Где взять готовый встраиваемый интерпретатор?
:)
Кто-нибудь знает:
1) Что и в каком порядке изучать, чтобы написать интерпретатор Хаскеля?
2) Где взять готовый встраиваемый интерпретатор?
:)
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2009-04-10 07:04 pm (UTC)no subject
Date: 2009-04-10 07:13 pm (UTC)no subject
Date: 2009-04-10 07:30 pm (UTC)no subject
Date: 2009-04-10 07:53 pm (UTC)no subject
Date: 2009-04-10 08:04 pm (UTC)А уж если вспоминать про оптимизацию, то вообще крышей поехать можно. Я периодически пытаюсь представить себе, как можно было бы оформить БД и запросы к ней (R-tree для оптимизации пространственных запросов это частный случай такого) на хаскеле таким образом, чтобы их оптимизацией занимался движок, на основе предыдущих запросов и информации о типе.
no subject
Date: 2009-04-10 08:18 pm (UTC)Тут больше newtype нужно, имхо.
Никогда не видел пространственных запросов... но думаю, что преждевременная оптимизация -- это зло, как и преждевременный рефакторинг. Действительно крыша едет, если все сразу делать.
no subject
Date: 2009-04-10 08:29 pm (UTC)Вот та же реляционная теория - она придумывалась именно как средство разделить физическую структуру данных и их логическую структуру. Но, тем не менее, до сих пор при проектировании БД приходится учитывать потенциальные способы доступа к данным и подгонять индексы, а иногда и поступаться нормализацией, ради скорости работы.
no subject
Date: 2009-04-10 08:42 pm (UTC)no subject
Date: 2009-04-10 08:47 pm (UTC)no subject
Date: 2009-04-10 09:33 pm (UTC)no subject
Date: 2009-04-10 09:49 pm (UTC)"Месье знает толк в извращениях!"
no subject
Date: 2009-04-11 12:30 am (UTC)no subject
Date: 2009-04-11 08:09 am (UTC)no subject
Date: 2009-04-10 07:09 pm (UTC)no subject
Date: 2009-04-10 07:11 pm (UTC)2) http://haskell.org/haskellwiki/Ghc_as_a_library
Вот. ;)
no subject
Date: 2009-04-10 07:29 pm (UTC)На самом деле, я как раз хочу избежать FFI и реализовать взаимодействие с БД и еще кой-какими внутренностями внешней программы так, как будто это родной модуль хаскеля, в крайнем случае, завернув его в монаду, аналогичную IO.
Тут в натуре министерство по налогам и сборам вместе с бухгалтерами сошло с ума и требует ведомости, для которых есть три варианта реализации:
1) написать вручную алгоритм, который будет грузить первичные данные из БД, их обрабатывать совершенно необъяснимым образом и потом вручную собирать выходную печатную форму. тысячи строк несамоочевидного кода
2) факторизовать код на выполняемый частично в SQL, частично в обычном языке, частично в скриптах печатной формы. Это сейчас оно реализовано так. Объяснить нормальному человеку, как ЭТО работает, будет очень сложно.
3) Прикрутить к этому Haskell-based DSL, который бы все, от загрузки из БД до генерации печатной формы делал сам. Очень сложно сначала, зато было бы гораздо проще потом и на веки вечные.
no subject
Date: 2009-04-10 07:58 pm (UTC)no subject
Date: 2009-04-10 07:58 pm (UTC)Ты опиши поточней, что тебе надо, попробуем.
no subject
Date: 2009-04-10 08:17 pm (UTC)Вкратце, идея такая: неким образом при компиляции подгружается схема БД(и, возможно, предопределенный набор запросов к ней) и из нее генерируется модуль, экспортирующий содержимое этой БД в совместимом с хаскелем виде. Т.е. таблица представляется в виде списка, а поскольку списки у нас ленивые - мы получаем обычную итерационную обработку таблицы. Запросы представляются в виде функций от параметров запроса тоже к спискам.
Сейчас из похожего я видел только HaskellDB, который для работы генерирует такой модуль своей какой-то утилитой, и вроде работает только через ODBC.
Затем мы это дело обрабатываем как нам в голову взбредет, обычным хаскелевым кодом, получаем некие выходные данные.
И эти выходные данные далее должны быть представлены в виде либо экранной либо печатной формы. Экранную по идее можно свести к печатной, а вот печатную желательно представить в строго типизированном виде и тоже желательно генерить хаскелевым кодом, это поможет избежать множества проблем - и меток пропущенных не будет, и ручная генерация произвольных форм возможна будет и логику составления от внешнего вида отделить проще.
Такое реализовать, насколько я себе представляю, достаточно сложно, поэтому я уже давно над этим думаю, но к реализации приступить не хватает мозга и времени.
no subject
Date: 2009-04-12 10:55 am (UTC)Хотя мне кажется, было бы круто иметь EDSL с синтаксисом SQL поверх HDBC.
Т.е. пишешь обычный SQL запрос, который возвращает ленивый список кртежей...
no subject
Date: 2009-04-12 05:04 pm (UTC)no subject
Date: 2009-04-13 02:50 pm (UTC)HaskellDB так же как и SQL основан на реляционной алгебре, но таки не sql.
Поэтому, какими-нибудь расширениями SQL для конкретного сервера не воспользуешься, а в случае SQL-EDSL всегда можно сделать бакенд максимально близким к конкретному диалекту.
Ну и планка входа в случае SQL-я существенно ниже - документации горы, в отличии от...
no subject
Date: 2009-04-10 09:26 pm (UTC)*шутка есичо*
no subject
Date: 2009-04-11 04:10 am (UTC)--
xaep
no subject
Date: 2009-04-11 08:40 am (UTC)no subject
Date: 2009-04-11 08:41 am (UTC)