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?