05:57:03 <kxra> stepcut: also, i realized that a wiki plugin didn't make as much sense as just having petter permission management and simpler page editing
05:57:26 <kxra> assuming the darcs plugin already tracks changes to pages
13:33:36 <srhb> So, in trying to go from ixSet to tables, it appears I no longer have to have seperate UserId newtypes etc. But is it still advisable to do so? If I have to cross-reference to the type from another table, it would seem having the type named as such is wise, but then it conflicts with the definition in the Tabular instance.
13:34:18 <srhb> Damn, no donri? Whatever will I do...
15:10:28 <stepkut> srhb: :)
15:16:41 <srhb> Oi
15:17:10 <srhb> donri: I need your expertise. :-)
15:56:12 <donri> srhb: i like the extra type safety and self-documentation of the newtypes but yeah, you can do without them with tables
15:56:30 <donri> srhb: i ended up suffixing all my tables indices with "K"
15:56:48 <donri> so I have e.g. KeywordK to query keywords
15:57:33 <donri> K for Key
15:57:51 <donri> (T for Transformer, R for Route... common conventions)
15:58:35 <donri> i'm not fond of names like that, but namespacing sucks in haskell :p
16:03:27 <srhb> Indeed.
16:03:55 <srhb> So you'd have User = User { userId :: KUserId } ? Or would you stick that in the instance?
16:04:02 <srhb> donri: Tabular instance, I mean.
16:05:06 <srhb> Basically I'm not sure if the "table indices" are the things in my User type or the things in the Tabular instance
16:05:59 <donri> newtype UserId = UserId Int deriving Num; data User = User UserId; data Key ... where UserIdK :: Key Primary UserId ...
16:06:16 <donri> but that's just what i'd to
16:06:40 <donri> the table indices are separate from your User type and specific to tables
16:06:46 <srhb> Oh.
16:06:56 <srhb> So what does the data definition inside the instance refer to?
16:07:12 <donri> they're used for queries, like the newtypes are in ixset but not using your existing newtypes
16:07:59 <srhb> *brainmelt*
16:08:53 <srhb> So, I have User { userId :: UserId, ... }
16:09:23 <srhb> An then instance Tabular user where; data Key k User b where UserId :: Key Primary user Integer <-- duplicate declaration of UserId
16:09:51 <donri> yea make the one in Key UserIdK :: Key Primary User UserId
16:10:01 <donri> then fetch UserIdK = userId
16:10:04 <srhb> Ahhh
16:10:05 <srhb> Derp
16:10:06 <srhb> :P
16:10:07 <srhb> Thanks.
16:11:05 <donri> well make that User { _userId :: UserId } and makeLenses ''User
16:11:22 <srhb> In the example you use makeLensesWith
16:11:22 <donri> then fetch UserIdK = view userId -- or just, _userId
16:11:44 <srhb> So I guess that means it's appending _ to the lensy fields?
16:12:01 <donri> then autoTab = autoIncrement userId -- to have it increment the userId for each new user;
16:12:11 <srhb> Right. OK. I think I can get it working then. :)
16:12:25 <donri> yea, the default is to take each _foo field and make a foo lens
16:12:34 <srhb> Right, that's what I want I think.
16:12:40 <donri> don't know why the example does it different, there's no need for it
16:13:41 <donri> btw #haskell-lens is where it's at (tables and lens)
16:14:17 <srhb> Already there! :D
16:14:22 <donri> ah
16:14:27 <srhb> And oh, I thought you were the author of the example
16:14:31 <donri> nope
16:14:53 <donri> seems i've fixed a typo in it though :D
16:15:15 <srhb> Ah I guess that's why :P
16:24:10 <donri> srhb: my fugly Tabular is here http://hub.darcs.net/dag/kibr/browse/src/Kibr/Data.hs#273
16:24:36 <donri> but don't look at it, needs cleaning :$
16:27:40 <srhb> OK, I won't even take a peek.......
16:29:16 <donri> ;)
16:33:51 <srhb> So how does this affect Queries and Updates?
16:36:54 <srhb> donri: Presumably I can drop my intermediate Users type now because I don't need nextUserId
16:37:03 <srhb> But then how does my Update look that creates a new user?
16:38:10 <srhb> Oh actually I guess I do need it in order to derive a safecopy
16:39:02 <donri> srhb: Table is SafeCopy already
16:39:06 <donri> in 0.3
16:40:02 <srhb> Oh!
16:40:04 <srhb> How nice.
16:40:05 <donri> srhb: i haven't used autoIncrement but I think you just use 'insert' and it handles increment for you
16:41:14 <srhb> so I just have type Users = Table User now
16:41:26 <srhb> I can see some cruft disappearing now. Nice!
16:42:44 <donri> AppState{_users :: Table User} perhaps
16:43:13 <srhb> Ah, to get lensy.
16:44:11 <donri> getUserById uid = view $ users.ix uid :: Query AppState (Maybe User)
16:44:53 <srhb> Neat.
16:45:10 <donri> s/ix/at/ probably, in that one
16:45:44 <srhb> getAllUsers :: return . view ?
16:45:57 <donri> what type do you want them as
16:46:07 <srhb> [User]
16:46:22 <srhb> erh, s/::/=
16:46:44 <srhb> or just view users I guess
16:46:53 <donri> asks $ toListOf users
16:47:01 <srhb> Ah
16:47:06 <donri> -- or: view $ users.from table
16:48:54 <donri> actuall
16:48:56 <donri> actually
16:49:07 <donri> asks $ toListOf $ users.folded -- or users.rows
16:49:11 <donri> i think
16:49:20 <srhb> Lots of fancy combinators I've never seen before. :-)
16:49:24 <donri> "view users" gets you the Table User
16:49:28 <srhb> Ah.
16:58:43 <stepkut> combinators as far as the eye can see
17:02:50 <srhb> Is constructing a whole record still just done by referring to the _-prefixed fields?
20:37:18 <donri> srhb: or positional
20:50:30 <srhb> Like User id foo bar baz
20:50:52 <srhb> I dislike looking at the _s :P
20:51:07 <srhb> Haskell should just have deriving Lens. <_<
21:10:04 <donri> srhb: agreed https://github.com/ekmett/lens/issues/283
22:11:05 <mm_freak_> srhb: and what exactly would that "Lens" type class be?
22:12:59 <srhb> mm_freak_: Haven't the foggiest!
22:13:13 <srhb> mm_freak_: we can make a new makeSomething keyword rather than deriving?
22:16:40 <donri> myGodIt'sFullOfLenses User = User { userId :: UserId }
22:23:39 <srhb> donri: Oh yeah, or that :P
22:30:28 <srhb> donri: Is there an explanation of the various key types of tables somewhere?
22:31:42 <donri> nope!
22:31:48 <srhb>  Fantastic. :P
22:31:53 <donri> \o/
22:31:55 <donri> lesse
22:32:01 <donri> Primary is self-explanatory?
22:32:32 <donri> Candidate is like Primary but isn't primary :p a one-to-one mapping
22:33:09 <donri> Inverted is many-to-many
22:33:11 <srhb> So, Primary and Candidate basically means "unique"
22:33:18 <donri> i forgot what Supplemental is :D
22:33:23 <donri> yea something like that
22:33:43 <srhb> OK, so I should be careful with those lest I randomly overwrite rows :P
22:35:16 <donri> also Inverted is where the bug is that they just return empty tables
22:35:43 <srhb> Fun!
22:36:56 <donri> supposedly Supplemental is many-to-one or one-to-many (or one too many?)
22:37:26 <srhb> The latter, clearly.
22:37:38 <srhb> But what do these relations actually mean?
22:37:55 <srhb> Or rather, what do they _do_
22:38:21 <donri> i think it's many-to-one. which would mean that a row only has one value for that index, but other rows can have the same value for the same index
22:40:05 <donri> i think in ixset terms, ixset itself is only Inverted indices, but then it fakes Candidate with updateIx and friends
22:40:42 <srhb> Yeah.
22:43:45 <donri> if you look at tables' AnIndex type, and filter out the {Int,Hash}Map versions, you can kinda figure out these relationship variants from the types
22:45:26 <donri> PrimaryMap :: Map (PKT t) t -> AnIndex t Primary a -- one to one, i.e. (a -> t)
22:45:47 <donri> CandidateMap :: Ord a => Map a t -> AnIndex t Candidate a -- same
22:46:10 <srhb> Needs a bit of squinting...
22:46:15 <donri> InvertedMap :: Ord a => Map a [t] -> AnIndex t Inverted (Set a) -- many-to-many, i.e. (Set a -> [t])
22:46:17 <donri> yea
22:46:23 <srhb> But yeah
22:46:53 <donri> SupplementalMap :: Ord a => Map a [t] -> AnIndex t Supplemental a -- one-to-many (i was wrong then?) i.e. (a -> [t])
22:47:34 <donri> uh, i'm not sure how you use those descriptions :p
22:47:47 <srhb> Maybe not. :P
22:48:42 <donri> a -> [t] means that you query that index using 'with', passing it only one key, and you can get back a number of results
22:49:40 <donri> actually might be better to look at just the first argument to the constructors, the map
22:50:13 <donri> PrimaryMap :: Map (PKT t) t == PKT t -> t -- maps the primary key type to a single table entry
22:50:14 <donri> etc
22:50:47 <donri> no wait, gah, that doesn't suffice for inverted! :D
22:50:57 <srhb> The Ord constraints on CandidateMap is confusing, too
22:51:04 <donri> (see I don't really grok tables myself completely :p)
22:51:24 <srhb> I've learned a lot so far. ^^
22:51:31 <srhb> What happens if I _don't_ add key types?
22:51:32 <donri> Ah well, Map requires Ord for keys
22:52:03 <donri> it's not needed in PrimaryMap because Tabular has that constraint on PKT already
22:52:12 <donri> class Ord (PKT t) => Tabular t
22:52:27 <srhb> Ah yes.
22:53:37 <donri> the last type parameter in AnIndex is what you return in 'fetch'
22:54:12 <srhb> huh, isn't the 'a' the key type?
22:54:21 <donri> so if you have an inverted index, its 'fetch' function must return a Set a
22:57:23 <donri> well the 'a' is the key type for the underlying Maps
22:57:24 <srhb> Yes..
22:57:24 <srhb> I'm afraid I'm too tired to follow along right now :P
22:57:24 <srhb> Thanks for all the help, though!
22:57:24 <srhb> Nini
22:57:49 <donri> basically, tables and ixset are just a bunch of Maps from indexed values to entries
22:57:54 <donri> okies
23:53:51 <donri> stepcut: you aiming for ghc 6.9 support in hyperdrive with extensible-exceptions? :)
23:54:04 <donri> <6.9 even