00:00:53 <stepcut> ? 00:01:08 <stepcut> I guess there are similar issues already.. 00:01:14 <stepcut> if you do, (rPair . int . int) 00:01:50 <stepcut> oh well.. something to think about for boomerang 2 I guess 00:02:29 <alpounet> heh 00:03:38 <stepcut> anyChar is different.. because it always consumes/produces exactly one character 00:04:17 <stepcut> so.. there is only one valid parse 00:04:44 <stepcut> anyString is difficult because if you had "abcd", in theory that could match, "a", "ab", "abc", "abcd" 00:05:31 <stepcut> int is someone similar.. if you have "123a" then it could match, 1, 12, or 123 but it will definitely not consume the 'a' 00:06:37 <stepcut> if you do, int . anyChar, then it *must* be (123, 'a') 00:07:06 <stepcut> because that is the only valid parse.. but if you do, (int . int).. then things are a bit ambiguous 01:00:06 <alpounet> yeah 01:00:34 <stepcut> anyway, I made the change, because I think it is probably better for now 01:01:15 <alpounet> otoh, that's pretty hard to think of a design that would keep all the inconsistencies away 01:01:34 <stepcut> well.. that is our job! To think of the hard stuff! 01:02:19 <alpounet> yeah 01:02:45 <alpounet> but the most common behavior we expect from a parser is to get the maximal intput that matches right? 01:02:56 <alpounet> but then the int . int parser is puzzling 01:03:00 <stepcut> yes 01:03:07 <alpounet> but is it really? 01:03:11 <stepcut> int . int should probably always fail 01:03:14 <alpounet> that just shouldn't match 01:03:20 <stepcut> but the problem is making the printer fail 01:04:38 <stepcut> either you need more explicit (and noisey types) or you need to provide combinators that always have clearly delimited boundaries 01:05:38 <stepcut> so, char/anyChar are fine because they are always exactly one character 01:05:48 <stepcut> but things of variable length are troublesome 01:06:00 <stepcut> but.. that may be a job for Agda 01:06:28 <alpounet> hah 01:06:34 <stepcut> even plain old boring parser libraries allow you to express nonesense 01:06:59 <stepcut> so it is not like boomerang is worse than any other parse in that respect we can't totally eliminate the need for thinking :p 01:07:30 <stepcut> and, really, if you are trying to do, anyString . anyString or int . int.. there is something confounded about your thinking anyway 01:07:40 <alpounet> yeah 01:07:45 <alpounet> that's a pretty dumb thing to do 01:07:48 <stepcut> right 01:08:03 <alpounet> or for int . int i'd expect there to be a space between them 01:08:03 <alpounet> but then 01:08:07 <alpounet> you specify this with space 01:08:11 <stepcut> yeah 01:08:11 <alpounet> so really int . int is pointless 01:08:15 <stepcut> right 01:09:02 <stepcut> as long as the odd cases fall mostly in the 'doesn't make sense anyway' areas.. we are doing ok. 01:09:15 <stepcut> whereas, anyString </> anyString, not behaving the 'obvious' way was bad.. 01:10:50 <alpounet> yeah 'cause there are use cases for that 01:11:40 <stepcut> yeah 04:42:09 <dcoutts> alpounet: you were asking about remote-repo, if it's actually local you can use local-repo instead 18:51:53 <stepcut> KorriX: did you see I released a new boomerang related to the issue you asking about? 18:52:42 <KorriX> where is aviable ? 18:54:13 <stepcut> hackage 18:54:21 <stepcut> I uploaded it already 18:54:52 <KorriX> Text.Boomerang ? 18:54:52 <stepcut> I change anyString so that it not longer has an implied 'eos' in it.. which means that, (rPair . anyString . anyString) is a bit of nonsense now.. but I think that is ok 18:54:57 <stepcut> yeah 18:55:29 <stepcut> I changed the default behavior of anyString so that, (rPair . anyString </> anyString) works the way you think it would 18:56:21 <KorriX> so: 18:56:21 <KorriX> <> rProblemDir </> (rList anyString) . eos 18:56:21 <KorriX> will work correctly ? 18:57:50 <stepcut> that .. I don't know 18:58:16 <KorriX> i will try and inform you :) 18:58:29 <stepcut> I am not sure if rList has implied </> in it or not 18:58:50 <stepcut> you might need, rProblemDir </> (rList (anyString . eos)) ? 18:59:04 <KorriX> exactly 19:00:42 <stepcut> hmm. actually, you wanted to know if, anyString </> eos worked.. That will work now *if* the path splitter includes a "" at the end of the list when the last character is a / 19:00:49 <stepcut> "foo/" -> ["foo",""] 19:00:59 <KorriX> stepcut - you are great 19:01:07 <stepcut> :) 19:01:29 <KorriX> do you know online judges ? 19:01:44 <stepcut> I need to use boomerang more so I can polish some of the rough edges 19:02:09 <KorriX> with my friends we are building one - purely functional 19:02:27 <stepcut> KorriX: fun! what is an online judge? 19:03:07 <KorriX> my english is not so good, so i will send you this: http://en.wikipedia.org/wiki/Online_judge 19:03:32 <stepcut> neat! 19:03:46 <KorriX> and Sphere Online Judge is biggest one i think 19:03:56 <stepcut> yeah 19:04:08 <stepcut> I am familiar with that one.. just didn't know if it was related or not 19:11:57 <KorriX> http://snapframework.com/media/img/pong-bench-20101117.png <- it is possible ? 19:12:16 <KorriX> http://snapframework.com/blog/2010/11/17/snap-0.3-benchmarks 19:19:53 <KorriX> stepcut: what is exactly your diggestive-functors library ? 20:01:42 <alpounet> hi there 20:24:10 <dcoutts> alpounet: hia, hope you saw my message re cabal and local-repo 20:30:46 <KorriX> stepcut: I used cabal install web-routes-boomerang and it doesn't work after 20:32:22 <KorriX> <> rProblemDir </> (rList (anyString . eos)) did not handle trailing slash 20:33:35 <KorriX> and <> rProblemDir </> (rList anyString) . eos gives me Stack overflow 20:40:35 <alpounet> dcoutts, yup, haven't got a chance to look at the local repo type yet though 20:40:38 <alpounet> thanks 22:50:42 <adyxax> hi guys, 22:51:09 <adyxax> I encounter the same acid-state migration problem that has been discussed here recently (according to http://happstack.com/irc-logs/happs-2012-02-28.txt) 22:51:46 <adyxax> has anyone come with an answer yet?