04:24:09 <levi> It piggybacks on ghc, doesn't it?
04:24:13 <levi> ghci, I mean.
16:04:34 <dcoutts> gaa! makeAcidic cannot see through type aliases
16:04:41 <dcoutts> turns out to be really annoying! :-)
16:05:14 <dcoutts> want to write:
16:05:37 <dcoutts> exampleTx :: Blah -> DbTxUpdate ()
16:05:48 <dcoutts> type DbTxUpdate a = UTCTime -> StdGen -> Update Database (a, [LogEntry])
16:06:13 <dcoutts> but makeAcidic complains and wants me to write it all out explicitly
16:06:43 <dcoutts> Lemmih: cheeky feature request ^^ :-)
16:10:44 <dcoutts> ah hah, I can do it without a type sig, that works ok...
16:15:33 <donri> makes sense why that's a problem, i think; it needs to generate an ADT for each transaction
16:16:06 <donri> obvious fix would be to manually expand types in the TH but i wonder if it would work to generate GADT syntax instead... does TH support that?
16:16:50 <dcoutts> donri: I don't see that it makes sense
16:16:57 <dcoutts> but yes it would have to expand type aliases
16:17:13 <dcoutts> in the TH code that does these various validation checks
16:17:24 <donri> dcoutts: it's generating data ExampleTx = ExampleTx Blah (DbTxUpdate ()) basically
16:17:50 <dcoutts> no, it doesn't fail in the generated result
16:17:58 <dcoutts> it's in the pre-generation checks
16:18:13 <dcoutts> it's walking down the ->'s in the type
16:18:25 <dcoutts> and expects to find that the final type is  Update x y
16:18:29 <dcoutts> or Query
16:18:45 <donri> ah, yeah
16:18:58 <dcoutts> yes, it'd have to expand a type alias there if it encounters one
16:19:13 <dcoutts> to see if it expands to Update/Query, or more ->'s
16:19:28 <dcoutts> basically just expand and carry on
16:19:52 <donri> i wonder if there's a way to cheat and get ghc to expand it. ghc does like to get rid of type synonyms for you
16:43:17 <dcoutts> ghc tends to keep aliases unless it needs to expand them
16:43:23 <dcoutts> which is usually very helpful
16:43:37 <dcoutts> for error messages, reporting inferred types etc
16:54:23 <donri> dcoutts: yeah but it quickly forgets about them too, which results in interesting type errors when using lens for example
16:54:29 <donri> dcoutts: maybe that could be exploited here ;)
16:54:37 <dcoutts> heh
16:57:46 <donri> hm http://hackage.haskell.org/package/th-expand-syns
17:08:55 <stepcut> yeah, makeAcidic has a few shortcomings like that.. fixable things, but fixes that require you to do battle with TH
17:36:29 <dcoutts> donri: oh nice find
18:06:24 <donri> stepcut: i wonder if this could make hsp more convenient https://github.com/ghc/ghc/blob/master/docs/users_guide/7.8.1-notes.xml#L258
18:06:41 <donri> picking an arbitrary instance sounds completely insane and also perhaps exactly what we want for hsp
18:14:26 <donri> i still don't quite understand why we need overlapping instances anyway
18:21:49 <stepcut> I've generally found that if I need IncoherentInstances.. I am doing something wrong :)
18:22:06 <stepcut> we need overlapping instances for the same reason we need the XMLGenT type :(
18:22:14 <stepcut> it is was allows you to embed one XML block inside another
18:28:49 <donri> odd, you'd think it'd just figure it out just like it figures out nested mtl stuff
18:28:59 <donri> but i believe you ;)