00:23:21 <stepcut> kxra: that's just a warning
00:23:49 <stepcut> kxra: though, that one might be worth fixing now
00:24:11 <stepcut> there is a similar one that I am holding off on because it forces the lower bound of some package to be higher than really needed
01:00:01 <pro-tip> check out my new nick :)
07:08:47 <kxra> pro-tip: nice [=
07:08:59 <kxra> pro-tip: sorry, i sent the wrong part of the output
07:09:01 <kxra> http://pastebin.ca/2308022
07:09:15 <kxra> happy-1.18 can install fine, but that doesn't fix anything
07:09:17 <kxra> http://pastebin.ca/2308023
07:09:30 <kxra> and that's what happens when i try 1.17
11:07:56 <mm_freak> pro-tip: i just had an epiphany
11:08:24 <mm_freak> a simple change to netwire turns it into a full-fledged form library with all the nice features we want + more =)
11:09:45 <mm_freak> it allows an amazing concept of form validation…  you want to keep people from brute-forcing logins?  write a simple validator =)
11:10:00 <mm_freak> myForm . require (< 3) . avgFps 10
11:10:25 <mm_freak> the average submits per second over up to the last 10 submits must be less than 3
11:11:28 <mm_freak> and yes, 'require' and 'avgFps' come with netwire itself…  they are nothing form-specific =)
11:12:12 <mm_freak> we also get the machinery to capture multiple errors and render to different markup types for free
11:12:34 <mm_freak> i will work on it this evening
11:14:07 <mm_freak> pro-tip: by integrating it into the framework itself this solves all the problems and keeps all the goodies you listed =)
11:16:50 <mm_freak> a form can look as simple as:  inputInteger + inputInteger
11:16:51 <donri> sounds intriguing
11:16:55 <mm_freak> yes, you guessed right
11:16:58 <mm_freak> the result is the sum =)
11:17:08 <donri> i imagine it would be a better foundation for ajaxified validation as well?
11:17:14 <mm_freak> yes
11:18:46 <mm_freak> another good thing:  the path from idea to code is much shorter…  you can use them right away without having to write any instances or glue code
11:19:00 <mm_freak> even if you have a custom error type
11:19:07 <mm_freak> the only requirement is that the error type is a monoid
11:22:08 <donri> so to capture multiple errors you just use for example a list instead of First?
11:22:19 <mm_freak> yeah
11:22:27 <mm_freak> and you can capture them inline
11:22:49 <mm_freak> now you can also have arbitrary layouts, disconnecting labels from inputs entirely
11:24:03 <donri> and i18n for errors and the unification with library provided errors works out i imagine
11:24:21 <mm_freak> sure
11:24:43 <mm_freak> either ad hoc or builtin
11:25:58 <mm_freak> you can also refer to arbitrarily old submissions…  if you don't, there is no additional overhead
11:26:14 <mm_freak> everything "just works" and is proven under the AFRP model
11:26:28 <donri> coolness
11:27:07 <mm_freak> so your error message could be, "come on, you've made the same mistake ten times in a row!"
11:27:10 <mm_freak> =)
11:27:39 <donri> and you can still use applicative when it makes sense right, or even arrow yea? arrow solving the ordering problem better
11:28:30 <mm_freak> integer <|> error . "come on, after 10 trials it's time that you get it right!" . afterI 10 <|> error "not an integer"
11:28:39 <mm_freak> that machinery is already there =)
11:28:52 <mm_freak> yeah, you can use Applicative
11:28:58 <mm_freak> i've just used Alternative =)
11:29:03 <donri> what about views, is it still connected to the form or separate? if so, what about static safety cf digestive's lack thereof
11:29:24 <mm_freak> you can choose
11:29:43 <mm_freak> if you prefer disconnected views, you can write the whole view at the bottom
11:29:49 <mm_freak> but you can also interleave
11:30:27 <mm_freak> views are not as disconnected as in digestive-functors though…  you can't separate them entirely from the Form computation
11:30:34 <mm_freak> but you can separate field definitions from the view
11:31:24 <donri> and you get compositional safety wrt field names?
11:31:45 <mm_freak> yes + the ability to select field names, if you need to
11:32:15 <donri> how about using the token stream approach i mentioned so you can reuse field names without generated suffixes
11:32:32 <mm_freak> i have to think about that
11:32:55 <donri> that way you can compose two forms with email fields and both get to be named 'email'
11:33:25 <mm_freak> should work actually, but to guarantee compositional safety you can't have a field name in common with a field name in a subform
11:34:12 <donri> hm, but why not if it goes by order rather than naming?
11:34:56 <mm_freak> say the root form name is empty
11:35:14 <mm_freak> liftA2 (,) user user
11:35:55 <mm_freak> then the email fields would become "_1-email" and "_2-email" respectively
11:36:05 <mm_freak> this is necessary
11:36:10 <mm_freak> otherwise you lose the safety
11:36:20 <donri> i don't see why
11:36:54 <mm_freak> think of liftA2 (,) form1 form2, where form1 and form2 come from unrelated sources beyond your control
11:37:02 <mm_freak> if they both define an 'email' field, you can't compose them
11:37:27 <mm_freak> at least not safely…  it would probably work by accident, but it's very unsafe and unpredictable
11:37:39 <donri> i don't see why, we're not using the name fields, only the order
11:37:58 <mm_freak> what do you mean?
11:38:33 <mm_freak> suppose that form1 would generate <input name="email" value="" />
11:38:39 <mm_freak> and form2 would have the same field
11:38:54 <mm_freak> with the prefixing approach this works
11:39:11 <mm_freak> technically i could implement an unsafeRename combinator
11:39:29 <mm_freak> so that form1 could actually choose to name its field "email" disregarding the current compositional context
11:39:48 <donri> if you have two <input name=email> in the same form and submit it, it's send as email=a&email=b, then to parse it into a Form we ignore the names and parse ["a","b"] similar to how we parse routes etc
11:40:11 <mm_freak> i understand that
11:40:18 <mm_freak> as said, it would work by accident
11:40:31 <donri> why accident? this is in the specs i think
11:40:51 <mm_freak> but remember that netwire forms would actually allow you to dynamically react to user input…  after a submission a form might choose not to render the input anymore
11:41:22 <mm_freak> for example a form with multiple pages is a single form!
11:42:24 <donri> anyway the "first field is unprefixed" is probably good enough for most uses
11:42:31 <donri> brb
11:43:55 <mm_freak> unsuffixed =)
11:44:04 <mm_freak> unless it's another withName
11:56:57 <donri> well you said "_1-email" which looks prefixed to me ;)
12:02:47 <mm_freak> it has a prefix and an empty suffix
15:12:52 <Palmik> The tables package looks really great. :)
15:39:27 <pro-tip> nice
15:39:33 <pro-tip> I'm hoping to check it out soon
15:40:47 <donri> Palmik: it's cool, but you should finish data-store anyway! :)
15:55:51 <Palmik> donri: Yes, I will get back to it soon, I was busy with school lately.
15:56:25 <donri> alright!
17:42:44 <HugoDaniel> cabal install -j is fresh air :D
17:46:45 <donri> HugoDaniel: how about the new cabal init
17:51:03 <HugoDaniel> yes! that also :)
17:51:43 <donri> finds your modules and dependencies and versions
17:54:25 <HugoDaniel> oh, i didn't knew about that one :D
17:54:38 <HugoDaniel> ive been using cabal init for a while, and i like that questionaire on the beginning
17:55:28 <donri> this is if you already have code but no .cabal
17:55:52 <donri> which isn't really my workflow but
17:57:40 <HugoDaniel> yeah, i also usually start with cabal init on an empty dir
18:00:42 <donri> i don't even use cabal init! :D
18:00:46 <donri> vim snippets
18:01:36 <HugoDaniel> oh, i dont know about those :)
18:01:52 <donri> i wrote them
18:20:44 <HugoDaniel> :D
18:20:49 <HugoDaniel> must go
18:20:50 <HugoDaniel> ttyl