to post messages and comments.

Дано: проект (2шт) ну или их кабал файлы, внешний скрипт, который будет запускаться runhaskell (ну или даже пусть executable в одном из пакетов), хочется в скрипте собрать все определенные инстансы.
В принципе это вполне можно сделать если заимпортировать инстансы из всех модулей. Вопрос, как это сделать?
(ну или может можно распарсить .hi файлы, но тогда вопрос чем это сделать просто)

Сидел тут возился с inline-c и начал ловить прекрасные гейзенбаги, у меня в одном файле контекст, в других он подгружается и используется, так вот в других он иногда не подгружался, т.е. запускаешь и там где должна быть аннотация типа в сплайсе TH парсер типа не видит. Запускаешь второй раз все ок (иногда не ок), добавляешь --dump-splices — ничего полезного. В общем решил добавляя --ghc-option='-j1' на <ghc-7.10 не проверял.

В общем получается что на уровне модуля парралельность появилась или из-за TH компилятор тупит и не ждет пока в зависимостях код сгенерируется? Или это просто получается, что безопасно в каких-то случаях не ждать полную сборку зависимости, но при этом данное предположение ломается на TH.

(минимального примера не будет)

Вот есть у меня необходимость генерировать запросы к базе данных. Имею на руках схему в виде csv, в которой имена таблиц, полей, связи и прочая. Схема каждый пуск программы может быть разная. Например в haskell-relational-record <github.com> для того, чтобы генерировать код, надо определить таблицы через TH как типы, в esqueleto что-то подобное. TH собирает типы во время компиляции. Либо я что-то где-то недочитал, либо нет возможности генерировать sql типобезопасно, если не знать всю схему БД во время компиляции. А следовательно надо писать нетипобезопасный генератор sql и самому. Скажите мне, пожалуйста, что я неправ, и не туда копаю.

[d|deriving instance Ord $(undefined)|]
Вполне компилируется, а вот конструктор StandaloneDerivD в Dec появился только в template-haskell-2.10
Выходит, что непервоклассная квазиквота `d` возвращает значение, которое невозможно сконструировать, или оно просто не экспортировано (но зачем?!)
Пиздос, что там за ад творится в этих магических квазиквотах и почему они таки не первоклассные? Пора наверное TH в base совать, чтобы он шел вместе с компилятором ... ну и haskell-src-exts туда же.

А кто у нас делал свои шекспироквазиквотеры?
Что вообще означают поля в ShakespeareSettings? Конкретно toBuilder, wrap, unwrap, preConversion, modifyFinalValue, justVarInterpolation?
Вообще, хочу квазиквотер для postgresql-simple с интерполяцией переменных внутрь sql запроса через инстанс `ToField` ну и заиметь всякие `$forall` на халявку

*cabal?
конфигурирую так
cabal configure --enable-executable-profiling --enable-tests
получаю при билде вот это
http://bpaste.net/show/185257/
вот проект
https://github.com/s9gf4ult/market
Если убрать ` --enable-executable-profiling` то все работает. Библиотека собралась норм, при сборке теста ожидает почемуто Fields.o вместо Fields.p_o
если добавить флаг `-p` библиотека собирается с профилировкой тоже нормально
модуль Market.Models использует TH и импортирует типы из Market.Models.Fields
Что за нах? Кто нибудь встречался?

возможно тупой вопрос, но как из Language.Haskell.TH.Exp получить его "значение"? Т.е. из LitE (IntegerL 1) просто 1 Не интерпретатор же писать? По сути хотелось QuasiQuoter использовать для произвольной строки

смотри, жуйка
haskell.org
очень круто. Я считал и вчитаю что кодогенерация в хаскеле — это зло. (как ты будешь отлаживать генеринованный код, а ?). Дженерики менее гибкие, но дерайвинг инстансов для любого типа на них выглядить очень логичным. Посему вопрос: что правильнее использовать deepseq или generic-deepseq, который делает все тоже самое, но без TH и с автоматическими инатснами NFData для всех типов с deriving Generic. Если бы deepseq не был интегрирован в другие пакеты, я бы даже не задавал этот вопрос. А вообще, нужно либо в компиляторе добавить опцию для автоматического дерайвинга Generic для всех типов, либо в исходном коде всех пакетов добавить это ко всем декларациями data, это решало бы ...

/me упоролся TH с сделал генерацию методов Рунге-Кутта по таблице его описывающей (пока для неявных методов только один вариант):
github.com
сами методы:
github.com
опыт какой-то неоднозначный. Проще ли было описать методы какой-нибудь структурой прямо в языке? наверное нет, т.к. парсер получился простой
и вполне расширяемый конечно можно было заюзать haskell-src, но это как-нибудь в другой раз. Проще ли было не использовать TH? Тоже наверное
нет, т.к. он спасает от кучи boiler-plate кода и потом править можно в одном месте, а лечиться будет везде. Можно ли было сделать проще?
Да-да и ещё раз да, используя магические [| |] и $( ) весь код можно бы было сократить во много раз и сделать понятным, но как ими воспользоваться
в моём случае я так и не понял.

почитал про TH, но в общем-то не очень понял как сделать (можно ли сделать) следующую штуку:
нужно таблицу
mathEq | mathEq .. mathEq
...
— + -----
| mathEq .. mathEq
преобразовать в формулу, где mathEq любое мат выражение, которое после вычисления будет const double.

вчера казалось, что TH — это что-то крышесносящее. Но ничо, въехал кое-как, вполне можно писать (хоть и синтаксис аля перл). А сегодня пытался разобраться с интерфейсом к avahi через dbus — вот это действительно что-то с чем-то. Интерфейс самого dbus убойный, у avahi ещё хлеще...