| 2021-10-14 00:00:06 +0000 | hyiltiz | (~quassel@31.220.5.250) (Ping timeout: 245 seconds) |
| 2021-10-14 00:00:58 +0000 | hippoid | (~idris@184.105.6.88) (Quit: leaving) |
| 2021-10-14 00:01:14 +0000 | idris | (~idris@184.105.6.88) |
| 2021-10-14 00:04:40 +0000 | Stotteren | (~Stotteren@pool-108-20-79-41.bstnma.fios.verizon.net) (Remote host closed the connection) |
| 2021-10-14 00:06:33 +0000 | hyiltiz | (~quassel@31.220.5.250) |
| 2021-10-14 00:06:39 +0000 | <idris> | can someone give me a hint for the Node case for defining a functor on a tree? https://paste.tomsmeding.com/W7jWvHNw |
| 2021-10-14 00:06:55 +0000 | <idris> | a question from typeclassopedia |
| 2021-10-14 00:08:00 +0000 | zaquest | (~notzaques@5.128.210.178) |
| 2021-10-14 00:09:30 +0000 | wroathe | (~wroathe@c-68-54-25-135.hsd1.mn.comcast.net) |
| 2021-10-14 00:09:30 +0000 | wroathe | (~wroathe@c-68-54-25-135.hsd1.mn.comcast.net) (Changing host) |
| 2021-10-14 00:09:30 +0000 | wroathe | (~wroathe@user/wroathe) |
| 2021-10-14 00:09:34 +0000 | <ski> | you'll need to use `Node' in the result, of course |
| 2021-10-14 00:09:45 +0000 | tdaeayusr^ | (~tdaeayusr@70.166.66.234) (Ping timeout: 265 seconds) |
| 2021-10-14 00:10:09 +0000 | <ski> | (also, you're missing a pair of brackets, in the pattern) |
| 2021-10-14 00:10:28 +0000 | emf | (~emf@2620:10d:c090:400::5:c416) (Quit: emf) |
| 2021-10-14 00:10:50 +0000 | <ski> | fixing that, you're only handling non-empty lists .. .. maybe it would be better to not match on the structure of the list here ? |
| 2021-10-14 00:12:19 +0000 | <idris> | ski: im going to ponder on that |
| 2021-10-14 00:12:46 +0000 | <ski> | (there are multiple ways to go about it .. some might be nicer than others) |
| 2021-10-14 00:13:29 +0000 | MQ-17J | (~MQ-17J@2607:fb90:1d89:67a9:1cd1:a18:a57f:e102) |
| 2021-10-14 00:17:32 +0000 | MQ-17J | (~MQ-17J@2607:fb90:1d89:67a9:1cd1:a18:a57f:e102) (Read error: Connection reset by peer) |
| 2021-10-14 00:17:50 +0000 | MQ-17J | (~MQ-17J@d192-24-122-179.try.wideopenwest.com) |
| 2021-10-14 00:18:10 +0000 | <idris> | is there a way to destructure the a Node to get at the `a` in ITree in the pattern itself? |
| 2021-10-14 00:18:48 +0000 | <ski> | that's what you're doing in your paste (modulo the bracketting mistake) |
| 2021-10-14 00:19:24 +0000 | Neuromancer | (~Neuromanc@user/neuromancer) (Ping timeout: 265 seconds) |
| 2021-10-14 00:19:25 +0000 | <ski> | however .. "is there a way to destructure a list to get at the element(s) of the list ?" |
| 2021-10-14 00:20:30 +0000 | <idris> | the (x:xs) syntax, and then recursion? |
| 2021-10-14 00:20:43 +0000 | <ski> | (perhaps even : "is there a way to do the same thing to all elements of a list ?") |
| 2021-10-14 00:21:26 +0000 | Tuplanolla | (~Tuplanoll@91-159-69-50.elisa-laajakaista.fi) (Quit: Leaving.) |
| 2021-10-14 00:21:26 +0000 | <ski> | that's one way. (my last questions hints at another way to think about it) |
| 2021-10-14 00:21:48 +0000 | <idris> | yeah, I had some thought like that - 'fmap f Node xs = Node (map f xs)' |
| 2021-10-14 00:22:23 +0000 | Psybur | (~Psybur@mobile-166-170-32-197.mycingular.net) (Remote host closed the connection) |
| 2021-10-14 00:22:37 +0000 | <idris> | but is not correct, but I think that's closer to your hints |
| 2021-10-14 00:22:42 +0000 | <ski> | yea .. except `xs' is not a list of `a's, but a list of `ITree a's .. so you can't pass `f' to `map' expecting it to call it on every element of `xs', since that doesn't work |
| 2021-10-14 00:23:00 +0000 | <ski> | instead, you have to .. *mumble* *mumble* |
| 2021-10-14 00:23:41 +0000 | <idris> | hmm. seems like another fmap |
| 2021-10-14 00:24:23 +0000 | <ski> | (`f' is a function converting `a's to `b's, remember. it doesn't accept a whole `ITree a' as input .. what would be comfortable with working on an `ITree a' ?) |
| 2021-10-14 00:25:19 +0000 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) |
| 2021-10-14 00:25:32 +0000 | <idris> | ummm, fmap? |
| 2021-10-14 00:25:40 +0000 | <ski> | maybe ? |
| 2021-10-14 00:25:46 +0000 | <idris> | haha |
| 2021-10-14 00:25:49 +0000 | <ski> | (perhaps you can explain ?) |
| 2021-10-14 00:25:49 +0000 | chexum_ | (~quassel@gateway/tor-sasl/chexum) (Remote host closed the connection) |
| 2021-10-14 00:26:06 +0000 | chexum | (~quassel@gateway/tor-sasl/chexum) |
| 2021-10-14 00:27:06 +0000 | <idris> | "what would be comfortable working on an ITree a"... where this pattern is working on a [ITree a] |
| 2021-10-14 00:27:25 +0000 | <idris> | maybe a case pattern on the right side is what I need |
| 2021-10-14 00:28:03 +0000 | <ski> | well, you could try that as well |
| 2021-10-14 00:28:23 +0000 | <koz> | Is it possible to construct a tasty option that is just a flag? I.e., instead of '--my-option=foo' it's just '--my-option'? |
| 2021-10-14 00:28:42 +0000 | <idris> | ski: you're cluing me that there's a better way |
| 2021-10-14 00:30:13 +0000 | <ski> | it's good to have multiple approaches in ones arsenal of problem attack, and to become better accquainted with their relative strengths, trade-offs, preconditions, effects |
| 2021-10-14 00:30:52 +0000 | <idris> | ok, you've given some great hints. Time to try a bunch of stuff. Thanks |
| 2021-10-14 00:31:12 +0000 | <idris> | ski++ |
| 2021-10-14 00:31:17 +0000 | <ski> | sometimes, banging one's head on a thing, for a while, exploring several avenues, is a better worth of one's while, than being served the (or rather, one particular) answer |
| 2021-10-14 00:31:23 +0000 | ski | twitches |
| 2021-10-14 00:31:31 +0000 | <idris> | agreed |
| 2021-10-14 00:31:49 +0000 | <ski> | (of course, if you're stuck, or if you want a proper explanation, feel free to ask for that) |
| 2021-10-14 00:31:54 +0000 | <idris> | thank you for NOT giving me the exact answer |
| 2021-10-14 00:34:06 +0000 | emf | (~emf@2620:10d:c090:400::5:c416) |
| 2021-10-14 00:34:23 +0000 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 265 seconds) |
| 2021-10-14 00:39:34 +0000 | brainfreeze | (~brainfree@2a03:1b20:4:f011::20d) |
| 2021-10-14 00:39:37 +0000 | <jollygood2> | @hoogle [a] -> [(a, Int)] |
| 2021-10-14 00:39:38 +0000 | <lambdabot> | Test.LeanCheck.Stats counts :: Eq a => [a] -> [(a, Int)] |
| 2021-10-14 00:39:38 +0000 | <lambdabot> | Test.Speculate.Utils counts :: Eq a => [a] -> [(a, Int)] |
| 2021-10-14 00:39:38 +0000 | <lambdabot> | ELynx.Tools sortListWithIndices :: Ord a => [a] -> [(a, Int)] |
| 2021-10-14 00:39:47 +0000 | <jollygood2> | is there something like that in base? |
| 2021-10-14 00:39:55 +0000 | <jollygood2> | or similar |
| 2021-10-14 00:40:08 +0000 | <awpr> | `zip [0..]` |
| 2021-10-14 00:40:25 +0000 | alx741 | (~alx741@186.178.108.69) (Ping timeout: 252 seconds) |
| 2021-10-14 00:40:32 +0000 | <awpr> | or with `flip` to make the order match |
| 2021-10-14 00:41:17 +0000 | <ski> | possibly that's not the intended semantics ? |
| 2021-10-14 00:41:21 +0000 | <jollygood2> | sorry, I wasn't clear, I want to get the count of identical elements |
| 2021-10-14 00:41:25 +0000 | ski | nods |
| 2021-10-14 00:42:10 +0000 | <awpr> | ah, okay. can cobble something together with `Data.IntMap.fromListWith`, but it won't be as convenient as a pre-made function |
| 2021-10-14 00:42:25 +0000 | <awpr> | `Data.Map.fromListWith` |
| 2021-10-14 00:42:46 +0000 | <geekosaur> | nothing premade but I think you can construct one with length, group, and sort |
| 2021-10-14 00:42:52 +0000 | <xsperry> | > (map (head &&& length) . group . sort) ["foo", "bar", "foo"] |
| 2021-10-14 00:42:54 +0000 | <lambdabot> | [("bar",1),("foo",2)] |
| 2021-10-14 00:45:22 +0000 | wroathe | (~wroathe@user/wroathe) (Ping timeout: 252 seconds) |
| 2021-10-14 00:45:45 +0000 | <ski> | i guess one could also search for "bag" or "multiset"/"multi-set" |
| 2021-10-14 00:48:14 +0000 | lavaman | (~lavaman@98.38.249.169) |
| 2021-10-14 00:49:14 +0000 | <Axman6> | I always called that ahistogram |
| 2021-10-14 00:50:18 +0000 | <Axman6> | % data Booly a where Truey :: Booly 'True; Falsey :: Booly 'False |
| 2021-10-14 00:50:18 +0000 | <yahb> | Axman6: |
| 2021-10-14 00:50:25 +0000 | <Axman6> | % :T Truey |
| 2021-10-14 00:50:25 +0000 | <yahb> | Axman6: unknown command ':T'; use :? for help. |
| 2021-10-14 00:50:28 +0000 | <Axman6> | % :t Truey |
| 2021-10-14 00:50:28 +0000 | <yahb> | Axman6: Booly 'True |
| 2021-10-14 00:52:28 +0000 | lavaman | (~lavaman@98.38.249.169) (Ping timeout: 252 seconds) |
| 2021-10-14 00:53:02 +0000 | alx741 | (~alx741@181.196.69.128) |
| 2021-10-14 00:54:17 +0000 | <ski> | hm, well, "histogram" entered my mind, but afaik, the word is used when you have some given partition of the possible data points, not necessarily the identity equivalence relation / the finest partition, so .. |
| 2021-10-14 00:57:03 +0000 | wroathe | (~wroathe@c-68-54-25-135.hsd1.mn.comcast.net) |
| 2021-10-14 00:57:03 +0000 | wroathe | (~wroathe@c-68-54-25-135.hsd1.mn.comcast.net) (Changing host) |
| 2021-10-14 00:57:03 +0000 | wroathe | (~wroathe@user/wroathe) |
| 2021-10-14 00:57:22 +0000 | haskellchap | (~haskellch@84-115-222-182.cable.dynamic.surfer.at) |
| 2021-10-14 00:59:47 +0000 | <haskellchap> | Hello everyone. Can anyone tell me how come this https://pastebin.com/raw/bJkmarBp program does not work when compiled with -XStrict . |
| 2021-10-14 01:00:05 +0000 | <haskellchap> | I get the error "How?" executed, even though branch is not True |
| 2021-10-14 01:00:42 +0000 | <haskellchap> | Without -XStrict the program works fine. |
| 2021-10-14 01:01:19 +0000 | hyiltiz | (~quassel@31.220.5.250) (Ping timeout: 252 seconds) |
| 2021-10-14 01:01:36 +0000 | funsafe | (~funsafe@2601:1c1:4200:e53:2875:5507:42e4:4e14) (Read error: Connection reset by peer) |
| 2021-10-14 01:01:39 +0000 | <awpr> | that's kind of the definition of `-XStrict`. it makes the data constructor `P` strict, which means the error gets forced as part of constructing the `P` |
| 2021-10-14 01:01:52 +0000 | wroathe | (~wroathe@user/wroathe) (Ping timeout: 252 seconds) |
| 2021-10-14 01:01:57 +0000 | <ski> | try `ff = M.state (\_ -> error "How ?")' |
| 2021-10-14 01:02:34 +0000 | <haskellchap> | The code runs up to the branch and then throws error |
| 2021-10-14 01:03:55 +0000 | <ski> | hm, what if you add say `() <- ()' before the `let' ? |
| 2021-10-14 01:04:16 +0000 | <ski> | er, make that `() <- return ()', of course |
| 2021-10-14 01:05:45 +0000 | brettgilio | (~brettgili@x-node.gq) (Quit: Leaving...) |
| 2021-10-14 01:05:48 +0000 | <haskellchap> | I mean, your M.state suggestion works. The code no longer throws and putting f below g will throw it. |
| 2021-10-14 01:05:49 +0000 | <ski> | hm, sorry, i should be more specific. before the second `let' (after the second `do'). (i forgot that there was a first `let') |
| 2021-10-14 01:06:14 +0000 | <haskellchap> | the M.state works even if let P{f,g} is there. If f is not called there is no throw. |
| 2021-10-14 01:06:21 +0000 | <monochrom> | What awpr said. You just need to understand: without Strict, but with "data P = P { f :: !(SM ()), g :: !(SM ())}", that is enough strictness to cause the bottom. |
| 2021-10-14 01:06:21 +0000 | funsafe | (~funsafe@2601:1c1:4200:e53:2875:5507:42e4:4e14) |
| 2021-10-14 01:06:39 +0000 | nitrix | (~nitrix@user/nitrix) (Quit: Genius is one percent inspiration and ninety-nine percent perspiration) |
| 2021-10-14 01:07:26 +0000 | <monochrom> | See also my http://www.vex.net/~trebla/haskell/strict-field.xhtml |
| 2021-10-14 01:07:37 +0000 | ski | idly wonders how it was established that the code runs up to the branch |
| 2021-10-14 01:07:45 +0000 | awpr | too |
| 2021-10-14 01:07:49 +0000 | lbseale | (~lbseale@user/ep1ctetus) (Read error: Connection reset by peer) |
| 2021-10-14 01:08:40 +0000 | <monochrom> | My theory is instead: |
| 2021-10-14 01:08:42 +0000 | wroathe | (~wroathe@c-68-54-25-135.hsd1.mn.comcast.net) |
| 2021-10-14 01:08:43 +0000 | wroathe | (~wroathe@c-68-54-25-135.hsd1.mn.comcast.net) (Changing host) |
| 2021-10-14 01:08:43 +0000 | wroathe | (~wroathe@user/wroathe) |
| 2021-10-14 01:09:07 +0000 | <haskellchap> | Interesting. In my real example the code was running and then threw error, even though the P was constructed at the top level there too. |
| 2021-10-14 01:09:27 +0000 | <monochrom> | "s <- M.get", even with State.Lazy, causes the preceding "g" to be seq'ed. |
| 2021-10-14 01:09:44 +0000 | brettgilio | (~brettgili@x-node.gq) |
| 2021-10-14 01:10:16 +0000 | <monochrom> | If g is seq'ed, then it causes the d in "P{g} = d" to be seq'ed. |
| 2021-10-14 01:10:51 +0000 | <monochrom> | If d is seq'ed, then Strict or "data = ... ! ..." causes its f field to be seq'ed, which means ff. |
| 2021-10-14 01:11:15 +0000 | <monochrom> | It totally doesn't matter whether s==4 or s/=4. |
| 2021-10-14 01:11:20 +0000 | <haskellchap> | Yep, I get it, I read the link and yes, I evaluate the parent definitely. |
| 2021-10-14 01:11:27 +0000 | <haskellchap> | Thanks for the explanation. |
| 2021-10-14 01:11:39 +0000 | o1lo01ol1o | (~o1lo01ol1@2001:8a0:6d7a:df01:74db:7502:a3aa:3820) (Read error: Connection reset by peer) |
| 2021-10-14 01:12:06 +0000 | hyiltiz | (~quassel@31.220.5.250) |
| 2021-10-14 01:12:31 +0000 | o1lo01ol1o | (~o1lo01ol1@2001:8a0:6d7a:df01:74db:7502:a3aa:3820) |
| 2021-10-14 01:12:34 +0000 | tabemann | (~tabemann@2600:1700:7990:24e0:5901:20e0:5666:a3ee) |
| 2021-10-14 01:14:00 +0000 | nitrix | (~nitrix@user/nitrix) |
| 2021-10-14 01:16:25 +0000 | haskellchap | (~haskellch@84-115-222-182.cable.dynamic.surfer.at) (Ping timeout: 256 seconds) |
| 2021-10-14 01:19:58 +0000 | MQ-17J | (~MQ-17J@d192-24-122-179.try.wideopenwest.com) (Read error: Connection reset by peer) |
| 2021-10-14 01:24:34 +0000 | MQ-17J | (~MQ-17J@8.6.144.117) |
| 2021-10-14 01:26:24 +0000 | nitrix | nitrix-or-treat |
| 2021-10-14 01:36:55 +0000 | wrengr | wrengr_away |
| 2021-10-14 01:37:57 +0000 | [_] | (~itchyjunk@user/itchyjunk/x-7353470) |
| 2021-10-14 01:40:22 +0000 | [itchyjunk] | (~itchyjunk@user/itchyjunk/x-7353470) (Ping timeout: 252 seconds) |
| 2021-10-14 01:44:51 +0000 | Neuromancer | (~Neuromanc@user/neuromancer) |
| 2021-10-14 01:46:40 +0000 | theproffesor | (~theproffe@user/theproffesor) |
| 2021-10-14 01:49:52 +0000 | YoungChiefBTW | (~youngchie@2001:470:69fc:105::214c) (Changing host) |
| 2021-10-14 01:49:52 +0000 | YoungChiefBTW | (~youngchie@user/youngchiefbtw) |
| 2021-10-14 01:53:43 +0000 | [_] | [itchyjunk] |
| 2021-10-14 01:53:51 +0000 | hyiltiz | (~quassel@31.220.5.250) (Ping timeout: 245 seconds) |
| 2021-10-14 01:58:12 +0000 | <jollygood2> | does this seem reasonable way to avoid "Pattern match(es) are non-exhaustive" warning? do c <- oneOf "xyz"; case c of X -> � Y -> � _ error "parseXYZ: can't happen!" |
| 2021-10-14 01:58:31 +0000 | <jollygood2> | case c of 'x' � even |
| 2021-10-14 01:59:07 +0000 | jinsun | (~quassel@user/jinsun) (Read error: Connection reset by peer) |
| 2021-10-14 02:01:28 +0000 | <pavonia> | Your syntax seems a bit mixed up, but I guess you mean the right thing |
| 2021-10-14 02:01:44 +0000 | <jollygood2> | it is possible, I typed it in irc client |
| 2021-10-14 02:02:11 +0000 | xff0x | (~xff0x@2001:1a81:53d3:ff00:5c0b:f69b:2ab5:cb4c) (Ping timeout: 245 seconds) |
| 2021-10-14 02:02:20 +0000 | <jollygood2> | anyway, does error seem like a reasonable way to handle default case, that can't happen? |
| 2021-10-14 02:03:15 +0000 | <ski> | an alternative would be to use `<|>', i guess |
| 2021-10-14 02:04:14 +0000 | xff0x | (~xff0x@2001:1a81:5210:a600:f14:89c2:cfb:bd25) |
| 2021-10-14 02:04:24 +0000 | <pavonia> | Use error if something really shouldn't happen under any circumstances |
| 2021-10-14 02:04:42 +0000 | hyiltiz | (~quassel@31.220.5.250) |
| 2021-10-14 02:05:11 +0000 | theproffesor | (~theproffe@user/theproffesor) (Leaving) |
| 2021-10-14 02:05:18 +0000 | <pavonia> | (In this case there should be alternatives for 'y' and 'z') |
| 2021-10-14 02:07:11 +0000 | wroathe | (~wroathe@user/wroathe) (Ping timeout: 265 seconds) |
| 2021-10-14 02:09:07 +0000 | bontaq | (~user@ool-45779fe5.dyn.optonline.net) (Ping timeout: 265 seconds) |
| 2021-10-14 02:14:20 +0000 | <dsal> | jollygood2: `error` is `undefined` but you get to write an insult next to it. |
| 2021-10-14 02:14:44 +0000 | <dsal> | You can generally write much better code without `error` and then not end up sad later. :) |
| 2021-10-14 02:14:55 +0000 | Neuromancer | (~Neuromanc@user/neuromancer) (Ping timeout: 265 seconds) |
| 2021-10-14 02:15:37 +0000 | <jollygood2> | yes, it has happened to me before that "can't happen" ends up happening anyway :). it really can't happen in here though, I think, but <|> is better yes |
| 2021-10-14 02:18:58 +0000 | wroathe | (~wroathe@user/wroathe) |
| 2021-10-14 02:23:13 +0000 | wroathe | (~wroathe@user/wroathe) (Ping timeout: 252 seconds) |
| 2021-10-14 02:23:26 +0000 | gay | (~quassel@77-120-141-90.kha.volia.net) |
| 2021-10-14 02:25:42 +0000 | <byorgey> | I use the 'error "Can't happen"' thing way too often, I guess. It has been an enlightening experience working on https://github.com/byorgey/swarm/ with the policy that there can be absolutely positively zero uses of 'undefined' or 'error', because if the game crashes it means a user loses all their progress. |
| 2021-10-14 02:26:57 +0000 | <byorgey> | so we have to come up with creative ways of either dealing with all cases gracefully, or reporting an error to the user (but not crashing the game) if something happens that really shouldn't. |
| 2021-10-14 02:30:30 +0000 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) |
| 2021-10-14 02:44:23 +0000 | werneta | (~werneta@70-142-214-115.lightspeed.irvnca.sbcglobal.net) |
| 2021-10-14 02:44:50 +0000 | <dsal> | Maybe works for "can't happen" things and composes reasonably well. |
| 2021-10-14 02:49:14 +0000 | td_ | (~td@94.134.91.240) (Ping timeout: 265 seconds) |
| 2021-10-14 02:50:55 +0000 | td_ | (~td@94.134.91.160) |
| 2021-10-14 02:50:56 +0000 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) (Ping timeout: 245 seconds) |
| 2021-10-14 02:52:51 +0000 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) |
| 2021-10-14 02:59:52 +0000 | rekahsoft | (~rekahsoft@52.129.35.150) (Ping timeout: 265 seconds) |
| 2021-10-14 03:05:04 +0000 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 252 seconds) |
| 2021-10-14 03:15:18 +0000 | wyrd | (~wyrd@70.39.83.14) |
| 2021-10-14 03:26:21 +0000 | wyrd | (~wyrd@70.39.83.14) (Quit: leaving) |
| 2021-10-14 03:27:56 +0000 | Neuromancer | (~Neuromanc@user/neuromancer) |
| 2021-10-14 03:30:31 +0000 | obfusk_ | (~quassel@a82-161-150-56.adsl.xs4all.nl) (Ping timeout: 245 seconds) |
| 2021-10-14 03:31:10 +0000 | nitrix-or-treat | (~nitrix@user/nitrix) (Quit: Genius is one percent inspiration and ninety-nine percent perspiration) |
| 2021-10-14 03:32:39 +0000 | obfusk | (~quassel@a82-161-150-56.adsl.xs4all.nl) |
| 2021-10-14 03:32:44 +0000 | nitrix | (~nitrix@user/nitrix) |
| 2021-10-14 03:42:35 +0000 | wyrd | (~wyrd@70.39.83.14) |
| 2021-10-14 03:44:30 +0000 | jess | (~jess@libera/staff/jess) (Quit: Lost terminal) |
| 2021-10-14 03:45:34 +0000 | jess | (~jess@libera/staff/jess) |
| 2021-10-14 03:49:34 +0000 | ystael | (~ystael@user/ystael) (Ping timeout: 252 seconds) |
| 2021-10-14 03:55:06 +0000 | shapr | (~user@pool-100-36-247-68.washdc.fios.verizon.net) (Ping timeout: 245 seconds) |
| 2021-10-14 03:55:48 +0000 | Gurkenglas | (~Gurkengla@dslb-002-203-144-204.002.203.pools.vodafone-ip.de) |
| 2021-10-14 04:04:20 +0000 | zmt00 | (~zmt00@user/zmt00) (Quit: Gone.) |
| 2021-10-14 04:06:04 +0000 | zmt00 | (~zmt00@user/zmt00) |
| 2021-10-14 04:08:34 +0000 | fizzsegfaultbuzz | (~segfaultf@135-180-0-138.static.sonic.net) (Ping timeout: 268 seconds) |
| 2021-10-14 04:11:05 +0000 | emf | (~emf@2620:10d:c090:400::5:c416) (Quit: emf) |
| 2021-10-14 04:13:08 +0000 | emf | (~emf@2620:10d:c090:400::5:c416) |
| 2021-10-14 04:28:19 +0000 | zebrag | (~chris@user/zebrag) (Remote host closed the connection) |
| 2021-10-14 04:29:52 +0000 | jinsun | (~quassel@user/jinsun) |
| 2021-10-14 04:37:25 +0000 | machinedgod | (~machinedg@135-23-192-217.cpe.pppoe.ca) (Ping timeout: 252 seconds) |
| 2021-10-14 04:37:25 +0000 | waleee | (~waleee@h-98-128-228-119.na.cust.bahnhof.se) (Ping timeout: 252 seconds) |
| 2021-10-14 04:44:46 +0000 | coot | (~coot@37.30.52.44.nat.umts.dynamic.t-mobile.pl) |
| 2021-10-14 04:49:32 +0000 | infinity0_ | (~infinity0@occupy.ecodis.net) |
| 2021-10-14 04:49:33 +0000 | infinity0 | Guest732 |
| 2021-10-14 04:49:33 +0000 | Guest732 | (~infinity0@occupy.ecodis.net) (Killed (copper.libera.chat (Nickname regained by services))) |
| 2021-10-14 04:49:33 +0000 | infinity0_ | infinity0 |
| 2021-10-14 04:51:10 +0000 | falafel | (~falafel@2603-8000-d800-688c-c469-52c4-b20d-779e.res6.spectrum.com) |
| 2021-10-14 05:05:31 +0000 | MQ-17J | (~MQ-17J@8.6.144.117) (Ping timeout: 252 seconds) |
| 2021-10-14 05:06:14 +0000 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) |
| 2021-10-14 05:09:24 +0000 | Neuromancer | (~Neuromanc@user/neuromancer) (Ping timeout: 265 seconds) |
| 2021-10-14 05:20:16 +0000 | emf | (~emf@2620:10d:c090:400::5:c416) (Quit: emf) |
| 2021-10-14 05:26:24 +0000 | mbuf | (~Shakthi@122.178.118.100) |
| 2021-10-14 05:27:47 +0000 | slowButPresent | (~slowButPr@user/slowbutpresent) (Quit: leaving) |
| 2021-10-14 05:29:03 +0000 | abrantesasf | (~abrantesa@187.36.170.211) |
| 2021-10-14 05:30:09 +0000 | abrantesasf | (~abrantesa@187.36.170.211) (Remote host closed the connection) |
| 2021-10-14 05:31:13 +0000 | abrantesasf | (~abrantesa@187.36.170.211) |
| 2021-10-14 05:31:47 +0000 | abrantesasf | (~abrantesa@187.36.170.211) (Remote host closed the connection) |
| 2021-10-14 05:32:55 +0000 | aegon | (~mike@174.127.249.180) (Remote host closed the connection) |
| 2021-10-14 05:33:28 +0000 | even4void | (even4void@came.here.for-some.fun) () |
| 2021-10-14 05:35:43 +0000 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 252 seconds) |
| 2021-10-14 05:36:37 +0000 | [itchyjunk] | (~itchyjunk@user/itchyjunk/x-7353470) (Read error: Connection reset by peer) |
| 2021-10-14 05:38:45 +0000 | lavaman | (~lavaman@98.38.249.169) |
| 2021-10-14 05:39:38 +0000 | falafel | (~falafel@2603-8000-d800-688c-c469-52c4-b20d-779e.res6.spectrum.com) (Remote host closed the connection) |
| 2021-10-14 05:39:53 +0000 | falafel | (~falafel@2603-8000-d800-688c-c469-52c4-b20d-779e.res6.spectrum.com) |
| 2021-10-14 05:43:08 +0000 | obfusk | (~quassel@a82-161-150-56.adsl.xs4all.nl) (Quit: No Ping reply in 180 seconds.) |
| 2021-10-14 05:43:14 +0000 | lavaman | (~lavaman@98.38.249.169) (Ping timeout: 265 seconds) |
| 2021-10-14 05:44:17 +0000 | obfusk | (~quassel@a82-161-150-56.adsl.xs4all.nl) |
| 2021-10-14 05:46:32 +0000 | takuan | (~takuan@178-116-218-225.access.telenet.be) |
| 2021-10-14 05:53:59 +0000 | carbolymer_ | carbolymer |
| 2021-10-14 05:54:33 +0000 | ubert | (~Thunderbi@77.119.175.120.wireless.dyn.drei.com) |
| 2021-10-14 05:57:04 +0000 | mjs2600 | (~mjs2600@c-24-91-3-49.hsd1.vt.comcast.net) (Quit: ZNC 1.8.2 - https://znc.in) |
| 2021-10-14 05:57:19 +0000 | mjs2600 | (~mjs2600@c-24-91-3-49.hsd1.vt.comcast.net) |
| 2021-10-14 06:04:15 +0000 | azimut | (~azimut@gateway/tor-sasl/azimut) (Ping timeout: 276 seconds) |
| 2021-10-14 06:05:06 +0000 | azimut | (~azimut@gateway/tor-sasl/azimut) |
| 2021-10-14 06:12:30 +0000 | Sgeo | (~Sgeo@user/sgeo) (Read error: Connection reset by peer) |
| 2021-10-14 06:20:06 +0000 | vjoki | (~vjoki@2a00:d880:3:1::fea1:9ae) (Ping timeout: 245 seconds) |
| 2021-10-14 06:21:16 +0000 | vjoki | (~vjoki@2a00:d880:3:1::fea1:9ae) |
| 2021-10-14 06:25:28 +0000 | jakalx | (~jakalx@base.jakalx.net) () |
| 2021-10-14 06:26:56 +0000 | dhouthoo | (~dhouthoo@178-117-36-167.access.telenet.be) |
| 2021-10-14 06:27:58 +0000 | dschrempf | (~dominik@070-207.dynamic.dsl.fonira.net) |
| 2021-10-14 06:35:27 +0000 | Neuromancer | (~Neuromanc@user/neuromancer) |
| 2021-10-14 06:37:11 +0000 | falafel | (~falafel@2603-8000-d800-688c-c469-52c4-b20d-779e.res6.spectrum.com) (Ping timeout: 245 seconds) |
| 2021-10-14 06:38:18 +0000 | jakalx | (~jakalx@base.jakalx.net) |
| 2021-10-14 06:39:01 +0000 | brainfreeze | (~brainfree@2a03:1b20:4:f011::20d) (Quit: Leaving) |
| 2021-10-14 06:41:46 +0000 | fendor | (~fendor@178.115.40.84.wireless.dyn.drei.com) |
| 2021-10-14 06:51:43 +0000 | lortabac | (~lortabac@2a01:e0a:541:b8f0:d23a:63c3:dec2:f7ab) |
| 2021-10-14 06:51:56 +0000 | visortelle | (~visortell@37.214.28.39) |
| 2021-10-14 06:52:38 +0000 | visortelle | (~visortell@37.214.28.39) (Remote host closed the connection) |
| 2021-10-14 06:58:59 +0000 | <dminuoso> | byorgey: Perhaps this is an argument that for non-trivial code with "cant happen cases" being in IO is not such a bad idea. |
| 2021-10-14 07:07:52 +0000 | wyrd | (~wyrd@70.39.83.14) (Quit: leaving) |
| 2021-10-14 07:08:03 +0000 | MQ-17J | (~MQ-17J@d192-24-122-179.try.wideopenwest.com) |
| 2021-10-14 07:08:06 +0000 | <tdammers> | I think it fits in nicely with the "small dangerous trusted core in IO, large trustworthy well-typed pure code to deal with all the complex logic" design |
| 2021-10-14 07:08:11 +0000 | wyrd | (~wyrd@70.39.83.14) |
| 2021-10-14 07:08:44 +0000 | max22- | (~maxime@lfbn-ren-1-762-224.w81-53.abo.wanadoo.fr) |
| 2021-10-14 07:09:22 +0000 | wyrd | (~wyrd@70.39.83.14) (Client Quit) |
| 2021-10-14 07:09:31 +0000 | chele | (~chele@user/chele) |
| 2021-10-14 07:10:03 +0000 | wyrd | (~wyrd@70.39.83.14) |
| 2021-10-14 07:11:00 +0000 | jtomas_ | (~jtomas@95.red-88-11-64.dynamicip.rima-tde.net) |
| 2021-10-14 07:15:17 +0000 | thonkpod | (~thonkpod@user/thonkpod) (Ping timeout: 246 seconds) |
| 2021-10-14 07:15:37 +0000 | jollygood2 | (~bc8165b6@217.29.117.252) (Quit: http://www.okay.uz/ (Session timeout)) |
| 2021-10-14 07:15:43 +0000 | thonkpod | (~thonkpod@user/thonkpod) |
| 2021-10-14 07:17:30 +0000 | MQ-17J | (~MQ-17J@d192-24-122-179.try.wideopenwest.com) (Read error: Connection reset by peer) |
| 2021-10-14 07:18:17 +0000 | MQ-17J | (~MQ-17J@d192-24-122-179.try.wideopenwest.com) |
| 2021-10-14 07:21:53 +0000 | jinsun__ | (~quassel@user/jinsun) |
| 2021-10-14 07:22:32 +0000 | wyrd | (~wyrd@70.39.83.14) (Quit: leaving) |
| 2021-10-14 07:23:32 +0000 | econo | (uid147250@user/econo) (Quit: Connection closed for inactivity) |
| 2021-10-14 07:24:09 +0000 | gehmehgeh | (~user@user/gehmehgeh) |
| 2021-10-14 07:25:06 +0000 | jinsun | (~quassel@user/jinsun) (Ping timeout: 245 seconds) |
| 2021-10-14 07:28:30 +0000 | wyrd | (~wyrd@gateway/tor-sasl/wyrd) |
| 2021-10-14 07:30:09 +0000 | michalz | (~michalz@185.246.204.93) |
| 2021-10-14 07:30:16 +0000 | hnOsmium0001 | (uid453710@id-453710.hampstead.irccloud.com) (Quit: Connection closed for inactivity) |
| 2021-10-14 07:30:40 +0000 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) |
| 2021-10-14 07:33:10 +0000 | ubert1 | (~Thunderbi@77.119.175.120.wireless.dyn.drei.com) |
| 2021-10-14 07:33:50 +0000 | wyrd | (~wyrd@gateway/tor-sasl/wyrd) (Quit: leaving) |
| 2021-10-14 07:34:04 +0000 | wyrd | (~wyrd@gateway/tor-sasl/wyrd) |
| 2021-10-14 07:34:23 +0000 | wyrd | (~wyrd@gateway/tor-sasl/wyrd) (Client Quit) |
| 2021-10-14 07:35:34 +0000 | wyrd | (~wyrd@gateway/tor-sasl/wyrd) |
| 2021-10-14 07:35:38 +0000 | oxide | (~lambda@user/oxide) |
| 2021-10-14 07:40:01 +0000 | cfricke | (~cfricke@user/cfricke) |
| 2021-10-14 07:45:27 +0000 | azeem | (~azeem@2a00:801:238:8585:a976:a6c:e179:1344) (Read error: Connection reset by peer) |
| 2021-10-14 07:45:44 +0000 | azeem | (~azeem@emp-85-170.eduroam.uu.se) |
| 2021-10-14 07:46:33 +0000 | Vajb | (~Vajb@hag-jnsbng11-58c3a8-176.dhcp.inet.fi) (Read error: Connection reset by peer) |
| 2021-10-14 07:46:45 +0000 | Vajb | (~Vajb@hag-jnsbng11-58c3a8-176.dhcp.inet.fi) |
| 2021-10-14 07:52:25 +0000 | kuribas | (~user@ip-188-118-57-242.reverse.destiny.be) |
| 2021-10-14 07:55:08 +0000 | acidjnk_new | (~acidjnk@p200300d0c703cb2624cf652eb5c49df1.dip0.t-ipconnect.de) |
| 2021-10-14 07:55:12 +0000 | <dminuoso> | tdammers: In part yes, though if you have these "impossible cant happen" situations in pure code, this results in one of several problems |
| 2021-10-14 07:55:28 +0000 | o1lo01ol1o | (~o1lo01ol1@2001:8a0:6d7a:df01:74db:7502:a3aa:3820) (Remote host closed the connection) |
| 2021-10-14 07:56:05 +0000 | <dminuoso> | Encoding these error conditions into ADTs can be tricky or annoying at times due to compositionality |
| 2021-10-14 07:56:11 +0000 | jtomas_ | (~jtomas@95.red-88-11-64.dynamicip.rima-tde.net) (Quit: Leaving) |
| 2021-10-14 07:56:44 +0000 | <c_wraith> | or a massive performance penalty |
| 2021-10-14 07:57:41 +0000 | <dminuoso> | Heh, was going to say that too. |
| 2021-10-14 07:58:06 +0000 | <dminuoso> | It's not a reason not to do this, but it can present challenges |
| 2021-10-14 07:58:39 +0000 | <kuribas> | just put some property tests on it to prove the invariant. |
| 2021-10-14 08:01:27 +0000 | <kuribas> | It just depends on how much the problem solves vs the effort required. |
| 2021-10-14 08:01:47 +0000 | <c_wraith> | I'm thinking of a particularly knotty bit of code I wrote... I think getting rid of the call to error completely invalidates the reason the code exists. |
| 2021-10-14 08:03:22 +0000 | <dminuoso> | Plus, you *can* catch error in IO |
| 2021-10-14 08:04:20 +0000 | <dminuoso> | Perhaps we should just use more `evaluate` |
| 2021-10-14 08:04:26 +0000 | <c_wraith> | also, it doesn't really help with the actual problem in that code, which is that if the circular reference is allowed to close, you get a self-referential thunk. No data type can fix *that* problem. |
| 2021-10-14 08:05:25 +0000 | <dminuoso> | c_wraith: Oh but that's not true! |
| 2021-10-14 08:05:36 +0000 | <dminuoso> | Pointers are magic |
| 2021-10-14 08:05:43 +0000 | <kuribas> | c_wraith: do you want to avoid self-referencing? |
| 2021-10-14 08:05:59 +0000 | <kuribas> | c_wraith: couldn't you use a monad to generate it? |
| 2021-10-14 08:06:12 +0000 | <c_wraith> | no. not even close. |
| 2021-10-14 08:07:20 +0000 | <c_wraith> | https://gist.github.com/chowells79/996f2749b088d287937e3eff11055522 |
| 2021-10-14 08:09:08 +0000 | tzh | (~tzh@c-24-21-73-154.hsd1.wa.comcast.net) (Quit: zzz) |
| 2021-10-14 08:09:48 +0000 | hendursa1 | (~weechat@user/hendursaga) |
| 2021-10-14 08:10:21 +0000 | hendursaga | (~weechat@user/hendursaga) (Ping timeout: 276 seconds) |
| 2021-10-14 08:10:56 +0000 | <kuribas> | c_wraith: could you make an intermediate, not self-referencial version, which you then validate and convert to tie the knot? |
| 2021-10-14 08:11:13 +0000 | <c_wraith> | that would entirely defeat the purpose |
| 2021-10-14 08:11:35 +0000 | <kuribas> | looks like an interesting problem, but I am busy right now... |
| 2021-10-14 08:11:38 +0000 | <c_wraith> | as it would add back all the overhead that's being eliminated by making them the same in the first place |
| 2021-10-14 08:13:26 +0000 | <kuribas> | I could look at it this evening, or tomorrow. |
| 2021-10-14 08:16:55 +0000 | geekosaur | (~geekosaur@xmonad/geekosaur) (Read error: Connection reset by peer) |
| 2021-10-14 08:17:36 +0000 | geekosaur | (~geekosaur@xmonad/geekosaur) |
| 2021-10-14 08:18:11 +0000 | o1lo01ol1o | (~o1lo01ol1@2001:8a0:6d7a:df01:74db:7502:a3aa:3820) |
| 2021-10-14 08:18:44 +0000 | ub | (~Thunderbi@178.115.37.32.wireless.dyn.drei.com) |
| 2021-10-14 08:19:37 +0000 | ubert1 | (~Thunderbi@77.119.175.120.wireless.dyn.drei.com) (Ping timeout: 252 seconds) |
| 2021-10-14 08:20:06 +0000 | ubert | (~Thunderbi@77.119.175.120.wireless.dyn.drei.com) (Ping timeout: 245 seconds) |
| 2021-10-14 08:20:06 +0000 | ub | ubert |
| 2021-10-14 08:26:58 +0000 | eggplantade | (~Eggplanta@2600:1700:bef1:5e10:ac5a:4bd6:3f7c:fb35) (Remote host closed the connection) |
| 2021-10-14 08:30:04 +0000 | MQ-17J | (~MQ-17J@d192-24-122-179.try.wideopenwest.com) (Read error: Connection reset by peer) |
| 2021-10-14 08:31:14 +0000 | MQ-17J | (~MQ-17J@8.6.144.117) |
| 2021-10-14 08:33:23 +0000 | max22- | (~maxime@lfbn-ren-1-762-224.w81-53.abo.wanadoo.fr) (Remote host closed the connection) |
| 2021-10-14 08:33:51 +0000 | werneta | (~werneta@70-142-214-115.lightspeed.irvnca.sbcglobal.net) (Ping timeout: 265 seconds) |
| 2021-10-14 08:34:10 +0000 | max22- | (~maxime@2a01cb0883359800f335681c9791beec.ipv6.abo.wanadoo.fr) |
| 2021-10-14 08:52:20 +0000 | o1lo01ol1o | (~o1lo01ol1@2001:8a0:6d7a:df01:74db:7502:a3aa:3820) (Remote host closed the connection) |
| 2021-10-14 08:52:54 +0000 | Pickchea | (~private@user/pickchea) |
| 2021-10-14 08:52:57 +0000 | o1lo01ol1o | (~o1lo01ol1@2001:8a0:6d7a:df01:74db:7502:a3aa:3820) |
| 2021-10-14 08:54:59 +0000 | o1lo01ol1o | (~o1lo01ol1@2001:8a0:6d7a:df01:74db:7502:a3aa:3820) (Remote host closed the connection) |
| 2021-10-14 08:55:13 +0000 | o1lo01ol1o | (~o1lo01ol1@2001:8a0:6d7a:df01:74db:7502:a3aa:3820) |
| 2021-10-14 08:58:27 +0000 | fendor_ | (~fendor@77.119.208.38.wireless.dyn.drei.com) |
| 2021-10-14 09:00:56 +0000 | fendor | (~fendor@178.115.40.84.wireless.dyn.drei.com) (Ping timeout: 245 seconds) |
| 2021-10-14 09:02:47 +0000 | o1lo01ol1o | (~o1lo01ol1@2001:8a0:6d7a:df01:74db:7502:a3aa:3820) (Remote host closed the connection) |
| 2021-10-14 09:03:27 +0000 | o1lo01ol1o | (~o1lo01ol1@2001:8a0:6d7a:df01:74db:7502:a3aa:3820) |
| 2021-10-14 09:04:10 +0000 | dolio | (~dolio@130.44.130.54) (Ping timeout: 252 seconds) |
| 2021-10-14 09:05:11 +0000 | dolio | (~dolio@130.44.130.54) |
| 2021-10-14 09:10:09 +0000 | azimut | (~azimut@gateway/tor-sasl/azimut) (Ping timeout: 276 seconds) |
| 2021-10-14 09:20:01 +0000 | mestre | (~mestre@191.177.175.57) |
| 2021-10-14 09:21:20 +0000 | tdaeayusr^ | (~tdaeayusr@70.166.66.234) |
| 2021-10-14 09:25:15 +0000 | trillp | (~trillp@69.233.98.238) |
| 2021-10-14 09:26:03 +0000 | Pickchea | (~private@user/pickchea) (Ping timeout: 265 seconds) |
| 2021-10-14 09:27:24 +0000 | eggplantade | (~Eggplanta@2600:1700:bef1:5e10:ac5a:4bd6:3f7c:fb35) |
| 2021-10-14 09:32:00 +0000 | eggplantade | (~Eggplanta@2600:1700:bef1:5e10:ac5a:4bd6:3f7c:fb35) (Ping timeout: 265 seconds) |
| 2021-10-14 09:33:19 +0000 | dschrempf | (~dominik@070-207.dynamic.dsl.fonira.net) (Ping timeout: 252 seconds) |
| 2021-10-14 09:34:13 +0000 | Kaiepi | (~Kaiepi@156.34.44.192) (Read error: Connection reset by peer) |
| 2021-10-14 09:34:25 +0000 | mei6 | (~mei@user/mei) |
| 2021-10-14 09:34:28 +0000 | Kaiepi | (~Kaiepi@156.34.44.192) |
| 2021-10-14 09:37:02 +0000 | acidjnk_new | (~acidjnk@p200300d0c703cb2624cf652eb5c49df1.dip0.t-ipconnect.de) (Ping timeout: 268 seconds) |
| 2021-10-14 09:43:26 +0000 | timCF | (~timCF@200-149-20-81.sta.estpak.ee) |
| 2021-10-14 09:46:01 +0000 | tdaeayusr^ | (~tdaeayusr@70.166.66.234) (Ping timeout: 252 seconds) |
| 2021-10-14 09:48:10 +0000 | MQ-17J | (~MQ-17J@8.6.144.117) (Ping timeout: 252 seconds) |
| 2021-10-14 09:48:20 +0000 | <timCF> | Hello! Does anyone have an idea how I could get a some sort of a list/graph/tree of Async processes currently running with information about how they are related to each other, structured and linked? Basically I'm looking for experience similar to Erlang "observer" tool, but in form of data which I can programmatically handle - send some mertics to monitoring services etc. |
| 2021-10-14 09:51:45 +0000 | <sshine> | timCF, as far as I remember, Erlang's spawn_link creates a child process and grants the parent process certain runtime privileges for monitoring if the process died, and killing child processes. |
| 2021-10-14 09:53:05 +0000 | MQ-17J | (~MQ-17J@d192-24-122-179.try.wideopenwest.com) |
| 2021-10-14 09:53:23 +0000 | <sshine> | timCF, I don't know exactly how spawn_monitor is implemented, though. but maybe it happens by wrapping the function that the child process runs inside another function that handles monitoring requests? |
| 2021-10-14 09:54:31 +0000 | <sshine> | timCF, did you see https://hackage.haskell.org/package/distributed-process ? |
| 2021-10-14 09:56:56 +0000 | <sshine> | timCF, judging by the 2018 timestamp, I don't know how popular it is. |
| 2021-10-14 09:57:29 +0000 | Neuromancer | (~Neuromanc@user/neuromancer) (Remote host closed the connection) |
| 2021-10-14 09:57:30 +0000 | <timCF> | sshine: yeah, I'm ex-Erlang programmer, and I did transfered a lot of ideas from it to my current Haskell development experience. Including linking spawned processes. Async libarary provides experience pretty close to low-level OTP functions like spawn and link. I do have some sort of generic supervisor trees implemented in terms of Async, and it mostly works. Just thinking that it might be very cool to |
| 2021-10-14 09:57:36 +0000 | <timCF> | visualize it, and use for some metrics |
| 2021-10-14 09:57:38 +0000 | bontaq | (~user@ool-45779fe5.dyn.optonline.net) |
| 2021-10-14 09:58:34 +0000 | LiaoTao | (~LiaoTao@gateway/tor-sasl/liaotao) (Remote host closed the connection) |
| 2021-10-14 09:58:55 +0000 | <timCF> | sshine: distributed-process seems overkill, they do focus a lot on distributed Erlang-like features, which is pretty hard thing to do right |
| 2021-10-14 09:59:06 +0000 | LiaoTao | (~LiaoTao@gateway/tor-sasl/liaotao) |
| 2021-10-14 09:59:32 +0000 | <sshine> | yeah, it seems like they try to embed a large part of Erlang into Haskell, rather than use similar design patterns. |
| 2021-10-14 09:59:44 +0000 | <sshine> | or rather, create a large framework for replicating those design patterns. |
| 2021-10-14 10:00:19 +0000 | <sshine> | timCF, I suppose you could create a monitoring process that kept information about the processes it monitors, and have those types of monitoring processes contain the list/graph/tree data for visualising. does sound kinda frameworkey, though. :) |
| 2021-10-14 10:00:45 +0000 | <sshine> | sounds like a partial OTP implementation, hehe. |
| 2021-10-14 10:01:22 +0000 | <sshine> | timCF, did you see https://hackage.haskell.org/package/nqe then? |
| 2021-10-14 10:01:40 +0000 | <timCF> | sshine: in my opinion distributed Erlang features do have low demand and utility, and at the same time very hard to implement right. But dynamic supervision trees are actually very useful and practical, and simpler to implement) |
| 2021-10-14 10:01:49 +0000 | jinsun__ | jinsun |
| 2021-10-14 10:02:05 +0000 | <timCF> | sshine: I'll check it, thanks) |
| 2021-10-14 10:03:06 +0000 | <sshine> | timCF, it specifically has a Control.Concurrent.NQE.Supervisor module. |
| 2021-10-14 10:03:13 +0000 | <sshine> | timCF, and it doesn't seem very huge. |
| 2021-10-14 10:03:30 +0000 | <sshine> | timCF, and jprupp made it in 2020. :) |
| 2021-10-14 10:03:40 +0000 | jollygood2 | (~bc8165b6@217.29.117.252) |
| 2021-10-14 10:06:16 +0000 | <jollygood2> | hi. is there a way to do this without as much boilerplate? |
| 2021-10-14 10:06:37 +0000 | <jollygood2> | https://paste.tomsmeding.com/3qKex6gT |
| 2021-10-14 10:13:03 +0000 | dyeplexer | (~dyeplexer@user/dyeplexer) |
| 2021-10-14 10:13:26 +0000 | <timCF> | jollygood2: Looks like `uncurry` might do the job |
| 2021-10-14 10:13:44 +0000 | <jollygood2> | :t uncurry |
| 2021-10-14 10:13:45 +0000 | <lambdabot> | (a -> b -> c) -> (a, b) -> c |
| 2021-10-14 10:13:57 +0000 | <jollygood2> | hmm, how? |
| 2021-10-14 10:14:56 +0000 | __monty__ | (~toonn@user/toonn) |
| 2021-10-14 10:16:06 +0000 | <timCF> | jollygood2: I thought it might be useful to uncurry function of multiple arguments somehow |
| 2021-10-14 10:16:47 +0000 | <jollygood2> | yeah it seems similar, but I have list as an input, not a tuple |
| 2021-10-14 10:20:21 +0000 | <timCF> | jollygood2: well, you can't use fold to gradually apply arguments one by one, because accumulator needs to be the same type |
| 2021-10-14 10:21:11 +0000 | <[exa]> | jollygood2: there's a function called chunksOf or similarly that cuts the list into parts; then you'll either need to patternmatch the [a,b,c,d,e] manually or use some var-arg magic, such as the one in Text.Printf |
| 2021-10-14 10:21:23 +0000 | <timCF> | jollygood2: but you can recursively apply, decomposing list with pattern matching, and expressing your apply-like functions in terms of each other |
| 2021-10-14 10:22:33 +0000 | <timCF> | jollygood2: for example `apply5 f (x : xs) = apply4 (f x) xs` |
| 2021-10-14 10:23:31 +0000 | <[exa]> | anyway, using !! is discouraged. apply5 f (a:b:c:d:e:xs) = f a b c d e` is much less troublesome |
| 2021-10-14 10:28:32 +0000 | <sshine> | :t ap |
| 2021-10-14 10:28:33 +0000 | <lambdabot> | Monad m => m (a -> b) -> m a -> m b |
| 2021-10-14 10:29:50 +0000 | <sshine> | jollygood2, you have some functions liftM, liftM2, liftM3, etc. that share a similar cascading effect: https://hackage.haskell.org/package/base-4.15.0.0/docs/Control-Monad.html#g:7 |
| 2021-10-14 10:29:55 +0000 | <jollygood2> | this worked apply5 f xs = apply4 f (dropFromEnd 1 xs) (last xs) |
| 2021-10-14 10:30:35 +0000 | raehik | (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) |
| 2021-10-14 10:31:11 +0000 | <jollygood2> | not sure if it is much clearer. and I could pattern match instead, like [exa] said. but then what do I do if there aren't enough elements? return error? throw exception? |
| 2021-10-14 10:31:57 +0000 | <jollygood2> | sshine I'm familiar with liftM, but I'm not sure how I could use that function for this |
| 2021-10-14 10:32:10 +0000 | <jollygood2> | those functions* |
| 2021-10-14 10:32:32 +0000 | timCF | (~timCF@200-149-20-81.sta.estpak.ee) (Quit: leaving) |
| 2021-10-14 10:34:10 +0000 | <sshine> | jollygood2, oh, hm. I'm beginning to see what you're trying to accomplish. you're trying to implement variadic functions, aren't you? i.e. functions with a number of arguments that vary at runtime. |
| 2021-10-14 10:34:52 +0000 | Neuromancer | (~Neuromanc@user/neuromancer) |
| 2021-10-14 10:34:52 +0000 | <sshine> | jollygood2, this is hard to do safely without dependent types, because you may at any point not have as many arguments as you assume. |
| 2021-10-14 10:35:57 +0000 | <jollygood2> | no I am not implementing variadic function. I have constructors that take different number of arguments, and a list of those arguments. code that precedes construction, that tests for some behavior, should ensure that I have the right number of arguments |
| 2021-10-14 10:36:34 +0000 | <jollygood2> | I just wanted to avoid cluttering the logic code with Constructor (x !! 0) (x !! 1) (x !! 2) (x !! 3) (x !! 4) |
| 2021-10-14 10:36:47 +0000 | <jollygood2> | vs apply5 Constructor xs |
| 2021-10-14 10:37:21 +0000 | <sshine> | jollygood2, did you read https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-validate/ ? -- you want to end up in a state where, if you've asserted that you have the right amount of values, then the types prevent any other scenario. |
| 2021-10-14 10:37:30 +0000 | <sshine> | !! does not prevent any other scenario :) |
| 2021-10-14 10:37:31 +0000 | <jollygood2> | and, out of curiosity, I was wondering if there was a nicer way to implement apply* functions |
| 2021-10-14 10:38:11 +0000 | <sshine> | jollygood2, seems like an x-y problem. maybe if you showed what problem you're trying to solve with apply2, apply3, apply4, that problem can be remodelled to not need unsafe variadic functions. |
| 2021-10-14 10:39:29 +0000 | <jollygood2> | here's a short example that will, hopefully, make it clear what I'm doing. https://paste.tomsmeding.com/KzM7LiOJ |
| 2021-10-14 10:41:08 +0000 | <jollygood2> | includes HandValue definition: https://paste.tomsmeding.com/QSYLVhro |
| 2021-10-14 10:43:17 +0000 | <jollygood2> | [Card] includes both player's hole cards, and table cards. it would be ideal to use types to ensure invalid state can't happen, but I have no clue how I'd do that |
| 2021-10-14 10:43:27 +0000 | acidjnk_new | (~acidjnk@p200300d0c703cb2624cf652eb5c49df1.dip0.t-ipconnect.de) |
| 2021-10-14 10:47:46 +0000 | dschrempf | (~dominik@070-207.dynamic.dsl.fonira.net) |
| 2021-10-14 10:49:49 +0000 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 265 seconds) |
| 2021-10-14 10:49:51 +0000 | <sshine> | jollygood2, sounds like [exa]'s suggestion of pattern matching is right. to answer your question, "what do I do if tehere aren't enough elements?" -- you want to catch that early on, not drag potentially-too-short lists around after a point where you've validated their length. |
| 2021-10-14 10:50:25 +0000 | <jollygood2> | that is what I was thinking as well, catch that during parsing, and then assume I have enough elements, to simplify logic code |
| 2021-10-14 10:50:42 +0000 | <jollygood2> | does apply* seem appropriate in here? |
| 2021-10-14 10:51:38 +0000 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) |
| 2021-10-14 10:51:59 +0000 | <sshine> | jollygood2, could you post the HandValue type? |
| 2021-10-14 10:52:29 +0000 | <jollygood2> | it is on the second link. https://paste.tomsmeding.com/QSYLVhro |
| 2021-10-14 10:52:36 +0000 | <sshine> | thanks |
| 2021-10-14 10:52:36 +0000 | o1lo01ol1o | (~o1lo01ol1@2001:8a0:6d7a:df01:74db:7502:a3aa:3820) (Ping timeout: 245 seconds) |
| 2021-10-14 10:53:32 +0000 | <sshine> | jollygood2, btw, I'm fairly certain that Texas Hold'em doesn't have five kickers in the NoPair case. you have one kicker, and if they're equal, it's a draw. |
| 2021-10-14 10:53:44 +0000 | <lortabac> | jollygood2: there is a simpler solution |
| 2021-10-14 10:54:03 +0000 | <lortabac> | add a type parameter to HandValue and make it a functor |
| 2021-10-14 10:54:18 +0000 | <lortabac> | then you'll get all those apply functions for free with DeriveFunctor |
| 2021-10-14 10:54:20 +0000 | <sshine> | haha |
| 2021-10-14 10:54:20 +0000 | <jollygood2> | sshine, other 3 to 4 kickers come from the table |
| 2021-10-14 10:54:28 +0000 | <sshine> | "There is a simpler solution. Use higher-kinded data!" ;) |
| 2021-10-14 10:54:54 +0000 | <jollygood2> | 3 to 5, even. if you have 2 and 3, all the kickers could come from the table |
| 2021-10-14 10:55:00 +0000 | <sshine> | jollygood2, so... the table cards are in your hand? |
| 2021-10-14 10:55:31 +0000 | <jollygood2> | [Card] in handValue contains both table and hand cards |
| 2021-10-14 10:55:42 +0000 | <jollygood2> | lortabac, can you elaborate, I'm not sure I understand |
| 2021-10-14 10:56:24 +0000 | <sshine> | jollygood2, my argument (whether it's valid or not) also applies for extending the hand to the table. so if you have two players who have sucky cards on their hands, and they tie for the highest single card on the table, no amount of sucky cards on their hand will make one hand better. |
| 2021-10-14 10:56:29 +0000 | <lortabac> | jollygood2: data HandValue a = NoPair a a a a a | OnePair Rank a a a ... |
| 2021-10-14 10:56:41 +0000 | <lortabac> | deriving (Functor) |
| 2021-10-14 10:56:55 +0000 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 252 seconds) |
| 2021-10-14 10:57:29 +0000 | <lortabac> | but to be honest I haven't followed the whole discussion, so it might not apply to your specific case |
| 2021-10-14 10:57:32 +0000 | <jollygood2> | sshine, handValue returns the best possible hand, given your hole cards and table cards. if there's no pair, then there are 5 kickers |
| 2021-10-14 10:57:36 +0000 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) |
| 2021-10-14 10:57:55 +0000 | <jollygood2> | highest 5 cards including table and your own cards |
| 2021-10-14 10:58:09 +0000 | <jollygood2> | lortabac, I have no clue either, but it seems interesting |
| 2021-10-14 10:58:23 +0000 | <jollygood2> | lortabac, not sure if this link helps: https://paste.tomsmeding.com/QSYLVhro |
| 2021-10-14 10:58:54 +0000 | <lortabac> | this solution will give you the possibility of mapping over all the Kickers in a HandValue |
| 2021-10-14 10:59:23 +0000 | <lortabac> | however if you don't have a HandValue in the first place, that's another problem |
| 2021-10-14 11:02:52 +0000 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 265 seconds) |
| 2021-10-14 11:03:32 +0000 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) |
| 2021-10-14 11:03:36 +0000 | <jollygood2> | I don't, I'm mapping [Card] to HandValue |
| 2021-10-14 11:05:03 +0000 | <sshine> | >_< I actually have a library for playing cards, but decided not to publish it because one Wikipedia rabbit hole led me to realise that what I believe are "playing cards" are really just "French-suited 52-card playing cards", where there's at least 5 other European types available, haha. |
| 2021-10-14 11:08:42 +0000 | <jollygood2> | I am basically trying to rewrite this in pure haskell, for fun. https://hackage.haskell.org/package/poker-eval-0.3.1/docs/Data-Poker.html |
| 2021-10-14 11:09:07 +0000 | Inst | (~Inst@2601:6c4:4080:3f80:4860:840:17cf:1bbb) |
| 2021-10-14 11:10:19 +0000 | <maralorn> | <sshine> ">_< I actually have a library..." <- It's really interesting how for poker or also all popular German card games French cards are the norm. There is even something called "German cards" here but no one knows it. |
| 2021-10-14 11:10:43 +0000 | chexum_ | (~quassel@gateway/tor-sasl/chexum) |
| 2021-10-14 11:10:52 +0000 | <maralorn> | (they are pretty similar though.) |
| 2021-10-14 11:10:59 +0000 | chexum | (~quassel@gateway/tor-sasl/chexum) (Remote host closed the connection) |
| 2021-10-14 11:11:13 +0000 | Neuromancer | (~Neuromanc@user/neuromancer) (Ping timeout: 252 seconds) |
| 2021-10-14 11:11:47 +0000 | geekosaur | (~geekosaur@xmonad/geekosaur) (Remote host closed the connection) |
| 2021-10-14 11:11:52 +0000 | AlexNoo_ | (~AlexNoo@178.34.163.33) |
| 2021-10-14 11:12:01 +0000 | <sshine> | maralorn, I was interested in the Swiss ones because a friend who lives in Switzerland had a really odd looking deck in his home, and his Swiss guests would say that they know games that are only played with those. |
| 2021-10-14 11:12:52 +0000 | <sshine> | yeah, they're not really breaking the format. but the picture cards are named differently, and there's a different total amount of each card. some don't have 4 of each kind, but a different amount of different kinds. |
| 2021-10-14 11:14:01 +0000 | Alex_test | (~al_test@178.34.161.78) (Ping timeout: 252 seconds) |
| 2021-10-14 11:15:00 +0000 | geekosaur | (~geekosaur@xmonad/geekosaur) |
| 2021-10-14 11:15:07 +0000 | AlexZenon | (~alzenon@178.34.161.78) (Ping timeout: 252 seconds) |
| 2021-10-14 11:15:19 +0000 | AlexNoo | (~AlexNoo@178.34.161.78) (Ping timeout: 245 seconds) |
| 2021-10-14 11:15:44 +0000 | <sshine> | jollygood2, I can see that you've derived the data type from this library. so, one of the things that I don't like about it is "The following must be true for a HandValue to be valid: All kickers must be in decending order. No Rank may not occur twice. The kickers may not construct higher-value hands." -- those constraints are not actually hard to construct using standard data types. so making a too |
| 2021-10-14 11:15:50 +0000 | <sshine> | lenient representation is perhaps only useful for being backwards-compatible with this poker library. |
| 2021-10-14 11:16:53 +0000 | <jollygood2> | sshine, how would I construct those constraints in types? |
| 2021-10-14 11:17:12 +0000 | <sshine> | jollygood2, e.g. "All kickers must be in descending order": NoPair (Set Kicker) |
| 2021-10-14 11:18:31 +0000 | <jollygood2> | ah I see. |
| 2021-10-14 11:18:57 +0000 | <jollygood2> | could still form an invalid hand though, but in a different way. you may have less than 5 kickers |
| 2021-10-14 11:19:39 +0000 | <jollygood2> | but it still nicer, kickers are sorted, and there it can't contain a pair or greater |
| 2021-10-14 11:19:57 +0000 | Alex_test | (~al_test@178.34.163.33) |
| 2021-10-14 11:21:16 +0000 | AlexZenon | (~alzenon@178.34.163.33) |
| 2021-10-14 11:23:29 +0000 | mestre | (~mestre@191.177.175.57) (Quit: Lost terminal) |
| 2021-10-14 11:23:37 +0000 | <jollygood2> | as far as, say, king of hearts appearing twice, I think that is best handled when filtering input. as far as I can tell there's no way to implement that in types in haskell |
| 2021-10-14 11:24:07 +0000 | <jollygood2> | out of curiosity, would this be possible in a language like idris? |
| 2021-10-14 11:24:19 +0000 | <sshine> | jollygood2, well, it depends on the kind of poker you're modelling. you could expose one variant in a module with constructors that fail (Either PokerError) when you can't gather five kickers. but the logic for comparing two hands using any amount of kickers is still the same. (and yes, you might end up comparing two Set Kicker with a different amount of elements, and probably your variation of poker in |
| 2021-10-14 11:24:25 +0000 | <sshine> | that module doesn't allow different-sized hands, and that'd probably be a corner case you'd rather validate your way out of.) |
| 2021-10-14 11:24:43 +0000 | <hpc> | jollygood2: yes |
| 2021-10-14 11:24:51 +0000 | <sshine> | yeah. or Haskell with some effort. |
| 2021-10-14 11:24:56 +0000 | <hpc> | imagine say, your hand is a list |
| 2021-10-14 11:25:35 +0000 | <hpc> | (x :: card) : (xs :: cards1) :: cards2 |
| 2021-10-14 11:25:45 +0000 | <hpc> | where cards1 can't contain x |
| 2021-10-14 11:25:51 +0000 | <hpc> | and cards2 = cards1 plus x |
| 2021-10-14 11:26:33 +0000 | <hpc> | well, more like a set than a list |
| 2021-10-14 11:27:07 +0000 | <jollygood2> | that looks a bit like peano numbers? |
| 2021-10-14 11:28:26 +0000 | <sshine> | more like type-level sets |
| 2021-10-14 11:28:41 +0000 | <sshine> | I guess |
| 2021-10-14 11:29:45 +0000 | <hpc> | there's probably better ways too, that is a particularly naive solution |
| 2021-10-14 11:30:17 +0000 | <jollygood2> | as a practical solution, is what I'm doing ok? just [Card], and apply* |
| 2021-10-14 11:30:31 +0000 | <jollygood2> | and ensure input is correct when parsing it |
| 2021-10-14 11:32:43 +0000 | <lortabac> | sshine: regarding your library, I have a suggestion: just do the Neapolitan cards, they are the only real playing cards :P |
| 2021-10-14 11:38:42 +0000 | machinedgod | (~machinedg@135-23-192-217.cpe.pppoe.ca) |
| 2021-10-14 11:41:18 +0000 | lavaman | (~lavaman@98.38.249.169) |
| 2021-10-14 11:43:34 +0000 | timCF | (~timCF@200-149-20-81.sta.estpak.ee) |
| 2021-10-14 11:45:25 +0000 | max22- | (~maxime@2a01cb0883359800f335681c9791beec.ipv6.abo.wanadoo.fr) (Ping timeout: 260 seconds) |
| 2021-10-14 11:45:39 +0000 | tfeb | (~tfb@88.98.95.237) |
| 2021-10-14 11:46:11 +0000 | <timCF> | Hello! Does anybody know, do I need still use `Async.link` function when I'm using high-level `Async.withAsync` bracket? Basically I want bidirectional link, where if parent process terminate, child will do as well. As well as the other way around. |
| 2021-10-14 11:46:17 +0000 | lavaman | (~lavaman@98.38.249.169) (Ping timeout: 264 seconds) |
| 2021-10-14 11:46:17 +0000 | jgeerds | (~jgeerds@55d4da80.access.ecotel.net) |
| 2021-10-14 11:48:12 +0000 | <sshine> | lortabac, honestly, the point where I gave up was when I realised that even for one country's style of playing cards, you also have a history of variations. I guess I took the 'library' part too seriously. :P |
| 2021-10-14 11:49:30 +0000 | rembo10 | (~rembo10@remulis.com) (Ping timeout: 260 seconds) |
| 2021-10-14 11:50:37 +0000 | <lortabac> | sshine: if you make it too generic it can become less useful |
| 2021-10-14 11:51:28 +0000 | <lortabac> | if I had to implement such a library, I'd just focus on one type of cards |
| 2021-10-14 11:55:35 +0000 | Lycurgus | (~juan@98.4.112.204) |
| 2021-10-14 11:58:13 +0000 | <jollygood2> | what's a better name for this? safeSucc x = if x == maxBound then minBound else succ x |
| 2021-10-14 11:59:30 +0000 | tfeb | (~tfb@88.98.95.237) (Quit: died) |
| 2021-10-14 12:00:12 +0000 | <geekosaur> | wrapSucc |
| 2021-10-14 12:00:22 +0000 | <dminuoso> | rotate |
| 2021-10-14 12:00:32 +0000 | <Lycurgus> | intGLB |
| 2021-10-14 12:00:54 +0000 | <geekosaur> | I thought about rotate but the next step is to do the same with prev |
| 2021-10-14 12:01:04 +0000 | <jollygood2> | yes I also have safePred |
| 2021-10-14 12:01:27 +0000 | <jollygood2> | I like wrapSucc|Pred |
| 2021-10-14 12:03:34 +0000 | rembo10 | (~rembo10@remulis.com) |
| 2021-10-14 12:05:17 +0000 | <merijn> | That's still not safe, though :p |
| 2021-10-14 12:05:41 +0000 | <merijn> | Hot take: Enum as-is is a terrible class that should be excised from all code |
| 2021-10-14 12:06:29 +0000 | <merijn> | Let's make that the next major compat break in base >.> |
| 2021-10-14 12:07:01 +0000 | <hpc> | no way |
| 2021-10-14 12:07:16 +0000 | <hpc> | not until we get data Bool = TRUE | FALSE | FILE_NOT_FOUND in |
| 2021-10-14 12:07:23 +0000 | <merijn> | hpc: We already have that |
| 2021-10-14 12:07:28 +0000 | <merijn> | Just install acme-php |
| 2021-10-14 12:07:32 +0000 | rembo10 | (~rembo10@remulis.com) (Client Quit) |
| 2021-10-14 12:08:24 +0000 | rembo10 | (~rembo10@remulis.com) |
| 2021-10-14 12:08:36 +0000 | <merijn> | hpc: This also seems to imply you think Enum is good, which I'm sorry to inform you is a clear sign of mental degradation :p |
| 2021-10-14 12:09:50 +0000 | <hpc> | oh don't worry, i have much clearer signs :D |
| 2021-10-14 12:11:20 +0000 | <merijn> | In fact, we should find out whos responsible for 10.2 of the Haskell 98 Report and retroactively withdraw their committee membership >.> |
| 2021-10-14 12:11:50 +0000 | coot | (~coot@37.30.52.44.nat.umts.dynamic.t-mobile.pl) (Quit: coot) |
| 2021-10-14 12:14:04 +0000 | kjak_ | (~kjak@pool-108-45-56-21.washdc.fios.verizon.net) (Ping timeout: 252 seconds) |
| 2021-10-14 12:14:07 +0000 | rond_ | (~rond_@2a02:a31a:a23c:f480:2fd7:e087:5546:a438) |
| 2021-10-14 12:15:12 +0000 | stiell | (~stiell@gateway/tor-sasl/stiell) (Remote host closed the connection) |
| 2021-10-14 12:15:40 +0000 | stiell | (~stiell@gateway/tor-sasl/stiell) |
| 2021-10-14 12:23:20 +0000 | slowButPresent | (~slowButPr@user/slowbutpresent) |
| 2021-10-14 12:27:52 +0000 | dschrempf | (~dominik@070-207.dynamic.dsl.fonira.net) (Quit: WeeChat 3.3) |
| 2021-10-14 12:27:53 +0000 | <jollygood2> | can I pattern match in MultiWayIf? something like if | (Just x = someFunc y) -> .. |
| 2021-10-14 12:29:02 +0000 | <merijn> | jollygood2: I mean, that's just case-of with a bunch of extra steps? |
| 2021-10-14 12:30:18 +0000 | <jollygood2> | yes, but that is one of dozen if clauses, so it would be convenient if the branch executed only if someFunc returns Just. I want functionality of if | (isJust $ someFunc y) -> fromJust $ someFunc y |
| 2021-10-14 12:30:18 +0000 | Lycurgus | (~juan@98.4.112.204) (Quit: Exeunt) |
| 2021-10-14 12:31:36 +0000 | __monty__ | (~toonn@user/toonn) (Quit: leaving) |
| 2021-10-14 12:32:21 +0000 | <merijn> | tbh, I find the use-case for a dozen if clauses questionable...I don't think you can pattern match in MultiWayIf, though? |
| 2021-10-14 12:32:42 +0000 | <jollygood2> | I am doing this: https://paste.tomsmeding.com/QSYLVhro |
| 2021-10-14 12:33:10 +0000 | <jollygood2> | in the updated code, isStraight returns Maybe Rank instead of Bool |
| 2021-10-14 12:33:10 +0000 | MQ-17J | (~MQ-17J@d192-24-122-179.try.wideopenwest.com) (Read error: Connection reset by peer) |
| 2021-10-14 12:33:42 +0000 | MQ-17J | (~MQ-17J@d192-24-122-179.try.wideopenwest.com) |
| 2021-10-14 12:34:46 +0000 | <jollygood2> | more context: https://paste.tomsmeding.com/teQxsvjX |
| 2021-10-14 12:34:49 +0000 | <jollygood2> | if needed |
| 2021-10-14 12:36:44 +0000 | <jollygood2> | if I am doing something else that is stupid feel free too comment :). I'm not sure I like [Card], or apply* functions |
| 2021-10-14 12:36:49 +0000 | <merijn> | jollygood2: btw, instead of reverse after sort, use Down |
| 2021-10-14 12:36:57 +0000 | <merijn> | > sortOn Down [1..5] |
| 2021-10-14 12:36:59 +0000 | <lambdabot> | [5,4,3,2,1] |
| 2021-10-14 12:37:02 +0000 | <jollygood2> | ah ok |
| 2021-10-14 12:37:13 +0000 | <merijn> | So you can just do "sortOn (Down . snd)" |
| 2021-10-14 12:37:18 +0000 | motherfsck | (~motherfsc@user/motherfsck) |
| 2021-10-14 12:37:23 +0000 | <merijn> | :t Down |
| 2021-10-14 12:37:24 +0000 | <lambdabot> | a -> Down a |
| 2021-10-14 12:37:35 +0000 | <merijn> | It's just a newtype with reversed comparisons |
| 2021-10-14 12:37:48 +0000 | <jollygood2> | that's neat |
| 2021-10-14 12:39:32 +0000 | <merijn> | btw, apply5 would be better of doing, like "apply5 f (a:b:c:d:e:_) = f a b c d e", the !! ends up rewalking the list each time |
| 2021-10-14 12:40:13 +0000 | <jollygood2> | yes. and what would I do if the list length doesn't match? return Maybe, error? |
| 2021-10-14 12:40:18 +0000 | rembo10 | (~rembo10@remulis.com) (Quit: ZNC 1.8.2 - https://znc.in) |
| 2021-10-14 12:40:27 +0000 | <merijn> | I mean, right now it already errors anyway :p |
| 2021-10-14 12:40:31 +0000 | <jollygood2> | yeah :) |
| 2021-10-14 12:41:10 +0000 | rembo10 | (~rembo10@remulis.com) |
| 2021-10-14 12:42:13 +0000 | <jollygood2> | apply5 :: String -> (a -> a -> a -> a -> a -> b) -> [a] -> b, where String is error message, so if what shouldn't happen happens, I know what to check |
| 2021-10-14 12:42:26 +0000 | <merijn> | Personally I'd probably refactor to something like: https://paste.tomsmeding.com/ychadwJh |
| 2021-10-14 12:43:04 +0000 | <merijn> | That has the same result as the multiwayif, but no extension and you can pattern match however you like |
| 2021-10-14 12:43:35 +0000 | <jollygood2> | I think I would have deeply nested cases with that? because I need to shortcircuit. hand could contain both Straight and OnePair, for example |
| 2021-10-14 12:43:41 +0000 | <merijn> | You could also define new datatype for it |
| 2021-10-14 12:44:14 +0000 | <merijn> | ok, actually |
| 2021-10-14 12:44:17 +0000 | <merijn> | Here's an idea |
| 2021-10-14 12:45:02 +0000 | <merijn> | write separate function for each scoring "straightFlush :: [Card] -> Maybe HandValue", "flush :: [Card] -> Maybe HandValue", etc. |
| 2021-10-14 12:45:28 +0000 | <merijn> | Then you apply each of them to the hand and use catMaybes |
| 2021-10-14 12:45:33 +0000 | <merijn> | :t catMaybes |
| 2021-10-14 12:45:34 +0000 | <lambdabot> | [Maybe a] -> [a] |
| 2021-10-14 12:46:07 +0000 | <merijn> | So you get "[Card] -> [HandValue]" |
| 2021-10-14 12:46:12 +0000 | <jollygood2> | sounds good, I'll try |
| 2021-10-14 12:47:02 +0000 | <jollygood2> | you see anything wrong with using [Card] and just validating input before passing cards to handValue? instead of trying to encode some guarantees in the types |
| 2021-10-14 12:48:36 +0000 | <merijn> | tbh, I dislike having pre-conditions on inputs |
| 2021-10-14 12:48:48 +0000 | <merijn> | Usually easy to forget and easy to mess up |
| 2021-10-14 12:49:31 +0000 | coot | (~coot@37.30.52.44.nat.umts.dynamic.t-mobile.pl) |
| 2021-10-14 12:49:39 +0000 | <jollygood2> | so what should I do? common invalid input I can think of: not enough cards, or too many (should be between 5 and 7). identical cards repeating more than once |
| 2021-10-14 12:50:30 +0000 | azimut | (~azimut@gateway/tor-sasl/azimut) |
| 2021-10-14 12:54:03 +0000 | <merijn> | If you use Set instead of list you rule out identical cards :p |
| 2021-10-14 12:55:33 +0000 | renzhi | (~xp@2607:fa49:6500:b100::5845) |
| 2021-10-14 13:02:14 +0000 | idris | hippoid |
| 2021-10-14 13:05:18 +0000 | shapr | (~user@pool-100-36-247-68.washdc.fios.verizon.net) |
| 2021-10-14 13:08:36 +0000 | AlexNoo_ | AlexNoo |
| 2021-10-14 13:10:39 +0000 | hendursa1 | (~weechat@user/hendursaga) (Ping timeout: 276 seconds) |
| 2021-10-14 13:18:22 +0000 | ystael | (~ystael@user/ystael) |
| 2021-10-14 13:20:57 +0000 | max22- | (~maxime@2a01cb0883359800f362ea56be7f8960.ipv6.abo.wanadoo.fr) |
| 2021-10-14 13:25:47 +0000 | azeem | (~azeem@emp-85-170.eduroam.uu.se) (Read error: Connection reset by peer) |
| 2021-10-14 13:30:48 +0000 | eggplantade | (~Eggplanta@2600:1700:bef1:5e10:ac5a:4bd6:3f7c:fb35) |
| 2021-10-14 13:33:04 +0000 | Pickchea | (~private@user/pickchea) |
| 2021-10-14 13:33:20 +0000 | azeem | (~azeem@emp-85-170.eduroam.uu.se) |
| 2021-10-14 13:35:06 +0000 | slack1256 | (~slack1256@45.4.2.52) |
| 2021-10-14 13:35:22 +0000 | eggplantade | (~Eggplanta@2600:1700:bef1:5e10:ac5a:4bd6:3f7c:fb35) (Ping timeout: 252 seconds) |
| 2021-10-14 13:36:44 +0000 | rond_ | (~rond_@2a02:a31a:a23c:f480:2fd7:e087:5546:a438) (Quit: Client closed) |
| 2021-10-14 13:38:51 +0000 | hendursa1 | (~weechat@user/hendursaga) |
| 2021-10-14 13:41:20 +0000 | nitrix | (~nitrix@user/nitrix) (Quit: Genius is one percent inspiration and ninety-nine percent perspiration) |
| 2021-10-14 13:42:25 +0000 | nitrix | (~nitrix@user/nitrix) |
| 2021-10-14 13:46:52 +0000 | MQ-17J | (~MQ-17J@d192-24-122-179.try.wideopenwest.com) (Read error: Connection reset by peer) |
| 2021-10-14 13:49:33 +0000 | Pickchea | (~private@user/pickchea) (Quit: Leaving) |
| 2021-10-14 13:52:02 +0000 | MQ-17J | (~MQ-17J@d192-24-122-179.try.wideopenwest.com) |
| 2021-10-14 13:55:07 +0000 | nvmd | (~nvmd@user/nvmd) (Ping timeout: 252 seconds) |
| 2021-10-14 13:55:21 +0000 | wroathe | (~wroathe@c-68-54-25-135.hsd1.mn.comcast.net) |
| 2021-10-14 13:55:21 +0000 | wroathe | (~wroathe@c-68-54-25-135.hsd1.mn.comcast.net) (Changing host) |
| 2021-10-14 13:55:21 +0000 | wroathe | (~wroathe@user/wroathe) |
| 2021-10-14 13:56:45 +0000 | nvmd | (~nvmd@user/nvmd) |
| 2021-10-14 14:02:36 +0000 | ishutin | (~ishutin@178-164-207-71.pool.digikabel.hu) (Ping timeout: 245 seconds) |
| 2021-10-14 14:03:20 +0000 | timCF | (~timCF@200-149-20-81.sta.estpak.ee) (Quit: leaving) |
| 2021-10-14 14:09:39 +0000 | ishutin | (~ishutin@84-236-97-21.pool.digikabel.hu) |
| 2021-10-14 14:11:48 +0000 | jollygood2 | (~bc8165b6@217.29.117.252) (Quit: http://www.okay.uz/ (Ping timeout)) |
| 2021-10-14 14:14:45 +0000 | acidjnk_new | (~acidjnk@p200300d0c703cb2624cf652eb5c49df1.dip0.t-ipconnect.de) (Ping timeout: 265 seconds) |
| 2021-10-14 14:16:27 +0000 | Lysanleo | (~Lysanleo@124.161.121.202) (Read error: Connection reset by peer) |
| 2021-10-14 14:18:53 +0000 | hnOsmium0001 | (uid453710@id-453710.hampstead.irccloud.com) |
| 2021-10-14 14:22:13 +0000 | <cigsender> | jollygood2: what about something like this? https://paste.tomsmeding.com/cwfN7nm5 |
| 2021-10-14 14:25:04 +0000 | <cigsender> | restricting your inputs to only what's valid allows you to exploit pattern-matching better |
| 2021-10-14 14:28:59 +0000 | Sgeo | (~Sgeo@user/sgeo) |
| 2021-10-14 14:33:46 +0000 | <sshine> | where did jollygood2 go? |
| 2021-10-14 14:34:03 +0000 | cigsender | shrugs |
| 2021-10-14 14:35:07 +0000 | <sshine> | /dcc get cigsender cig |
| 2021-10-14 14:35:57 +0000 | <Hecate> | cc cigsender :) |
| 2021-10-14 14:36:02 +0000 | <sshine> | I was going to suggest using a non-empty set since if you have at least one card, then no matter how you model your hand, you can always claim a high card. |
| 2021-10-14 14:36:20 +0000 | <cigsender> | is there a non-empty set in base? |
| 2021-10-14 14:36:29 +0000 | <sshine> | no, but there is one in nonempty-containers |
| 2021-10-14 14:36:40 +0000 | <cigsender> | hey Hecate <3 |
| 2021-10-14 14:36:40 +0000 | <sshine> | and it's made by jle, so I'd think it's good. |
| 2021-10-14 14:37:12 +0000 | <cigsender> | ugh wow never knew i needed this |
| 2021-10-14 14:37:21 +0000 | <sshine> | I also never knew |
| 2021-10-14 14:37:29 +0000 | <sshine> | so I ended up rabbit-holing until they left, haha. |
| 2021-10-14 14:39:14 +0000 | jollygood2 | (~bc8165b6@217.29.117.252) |
| 2021-10-14 14:39:48 +0000 | cigsender | wonders about pattern-matching on containers other than Seq |
| 2021-10-14 14:39:54 +0000 | <jollygood2> | cigsender, got disconnected, let me check. |
| 2021-10-14 14:40:20 +0000 | <sshine> | jollygood2, welcome back. |
| 2021-10-14 14:40:35 +0000 | <jollygood2> | thanks! |
| 2021-10-14 14:41:08 +0000 | <jollygood2> | cigsender, I like that, data Table = Flop Card Card Card | Turn Card Card Card Card | River Card Card Card Card Card |
| 2021-10-14 14:41:23 +0000 | <sshine> | jollygood2, I was going to suggest that if you have a non-empty set of cards to represent your hand, then your Hand -> HandValue function can easily be total, since you can default to the high card (kicker). |
| 2021-10-14 14:41:23 +0000 | <cigsender> | could be nice to have patterns for matching the minimum or maximum of a Map or a Set |
| 2021-10-14 14:42:23 +0000 | <sshine> | cigsender, you have viewpatterns. |
| 2021-10-14 14:43:06 +0000 | <cigsender> | jollygood2: yes! if you only have certain states the Table can be in, you can exhaustively match all the valid states |
| 2021-10-14 14:43:13 +0000 | <geekosaur> | also sounds like something that might be doable with a pattern synonym |
| 2021-10-14 14:44:08 +0000 | <cigsender> | sshine: view patterns are nice but i was thinking closer to pattern synonyms, where you could (?) also match on an empty Map without an Eq constraint |
| 2021-10-14 14:45:08 +0000 | <cigsender> | not that you'd ever really be in that situation :) |
| 2021-10-14 14:45:24 +0000 | <sshine> | cigsender, I kinda like that patterns are kinda dumb and that functions are kinda smart. :P |
| 2021-10-14 14:45:35 +0000 | azeem | (~azeem@emp-85-170.eduroam.uu.se) (Ping timeout: 268 seconds) |
| 2021-10-14 14:46:08 +0000 | <sshine> | cigsender, if patterns suddenly start computing things, I find it hard to reason about performance. (I think there was a similar debate about Erlang guards.) |
| 2021-10-14 14:47:01 +0000 | <cigsender> | sshine, that's a fair point, it's hard to reason about computational complexity when the computations are hidden :p |
| 2021-10-14 14:47:14 +0000 | <cigsender> | sshine, but then, how do you feel about YearMonthDay? |
| 2021-10-14 14:47:19 +0000 | <geekosaur> | that said min and max are cheap to compute |
| 2021-10-14 14:47:36 +0000 | <sshine> | cigsender, what's YearMonthDay? |
| 2021-10-14 14:47:41 +0000 | <geekosaur> | using one to search out something else in Set/Map is where you'd run into complexity |
| 2021-10-14 14:48:26 +0000 | wroathe | (~wroathe@user/wroathe) (Ping timeout: 245 seconds) |
| 2021-10-14 14:48:28 +0000 | <cigsender> | it's a pattern synonym for the Day type in time that precalculates gregorian for you instead of the julian day https://hackage.haskell.org/package/time-1.12/docs/Data-Time-Calendar.html#v:YearMonthDay |
| 2021-10-14 14:48:29 +0000 | azeem | (~azeem@emp-85-170.eduroam.uu.se) |
| 2021-10-14 14:50:17 +0000 | VoidNoir0 | (~VoidNoir0@72.80.203.52) (Quit: Connection closed) |
| 2021-10-14 14:50:42 +0000 | <sshine> | cigsender, ah, thanks, didn't know. |
| 2021-10-14 14:51:11 +0000 | <sshine> | cigsender, well, generally I'm not in favor. :) but it seems like a pretty good use-case for this kind of syntax. |
| 2021-10-14 14:52:33 +0000 | <sshine> | cigsender, if there's a somewhat constant, small computational overhead, I could totally accept it. not veto'ing. just saying it's a slippery slope. :P |
| 2021-10-14 14:53:08 +0000 | hippoid | (~idris@184.105.6.88) (Quit: leaving) |
| 2021-10-14 14:53:20 +0000 | <cigsender> | just wanted to feel out your position a little more, sshine :) |
| 2021-10-14 14:54:03 +0000 | ubert1 | (~Thunderbi@178.115.37.32.wireless.dyn.drei.com) |
| 2021-10-14 14:54:33 +0000 | <merijn> | sshine: I have a nice bunch of abuse for pattern synonyms :p |
| 2021-10-14 14:55:23 +0000 | <merijn> | sshine: Mapping 3 (4?) different "constructors" to one single universal one that has a bunch of preconditions. So my code operating on it has a simple single representation to work on, while having convenient constructors |
| 2021-10-14 14:57:04 +0000 | <sshine> | merijn, as a library API designer, it sounds like a great tool, honestly. |
| 2021-10-14 14:57:16 +0000 | hyiltiz | (~quassel@31.220.5.250) (Ping timeout: 252 seconds) |
| 2021-10-14 14:57:21 +0000 | <jollygood2> | ok I did data Table = Flop Card Card Card, but I'm not sure how to use the same code to evaluate the hand on the flop, turn and river, without pattern matching each case? if I convert Table to [Card], then I'm kind of back where I started? |
| 2021-10-14 14:57:30 +0000 | <sshine> | I've used pattern synonyms myself, but only ones that map very straight onto the internal representation. |
| 2021-10-14 14:57:44 +0000 | hyiltiz | (~quassel@31.220.5.250) |
| 2021-10-14 14:57:48 +0000 | [itchyjunk] | (~itchyjunk@user/itchyjunk/x-7353470) |
| 2021-10-14 14:58:04 +0000 | hippoid | (~idris@184.105.6.88) |
| 2021-10-14 14:58:14 +0000 | <hippoid> | :t pure |
| 2021-10-14 14:58:15 +0000 | <lambdabot> | Applicative f => a -> f a |
| 2021-10-14 14:58:35 +0000 | <hippoid> | :t pure 10 |
| 2021-10-14 14:58:36 +0000 | <lambdabot> | (Applicative f, Num a) => f a |
| 2021-10-14 14:59:02 +0000 | <cigsender> | jollygood2: you can convert Table to [Card] if you want, because you'll be sure inside handValue that you'll have at least 3 |
| 2021-10-14 14:59:07 +0000 | <jollygood2> | I guess the advantage is that if I get [Card] from Table, I am guaranteed to have 3, 4 or 5 cards, even if the [Card] doesn't show that |
| 2021-10-14 14:59:13 +0000 | <jollygood2> | cigsender, yes |
| 2021-10-14 14:59:31 +0000 | <hippoid> | `pure 10` confuses me. What is the (Applicative f) for an Int? |
| 2021-10-14 14:59:49 +0000 | <merijn> | hippoid: What do you mean "for an Int" |
| 2021-10-14 15:00:03 +0000 | <cigsender> | :k Applicative |
| 2021-10-14 15:00:05 +0000 | <lambdabot> | (* -> *) -> Constraint |
| 2021-10-14 15:00:05 +0000 | <merijn> | hippoid: pure 10 *takes* an Int (simplifying the type of 10 for now) |
| 2021-10-14 15:00:15 +0000 | <merijn> | hippoid: It returns "whatever Applicative you want" |
| 2021-10-14 15:00:21 +0000 | <merijn> | > pure 10 :: Maybe Int |
| 2021-10-14 15:00:22 +0000 | <lambdabot> | Just 10 |
| 2021-10-14 15:00:24 +0000 | <hippoid> | I thought I'd have to provide some kind of 'container' type as the first arg of pure |
| 2021-10-14 15:00:32 +0000 | <jollygood2> | Int is not Applicative, it is the value within Applicative |
| 2021-10-14 15:00:35 +0000 | wroathe | (~wroathe@c-68-54-25-135.hsd1.mn.comcast.net) |
| 2021-10-14 15:00:35 +0000 | wroathe | (~wroathe@c-68-54-25-135.hsd1.mn.comcast.net) (Changing host) |
| 2021-10-14 15:00:35 +0000 | wroathe | (~wroathe@user/wroathe) |
| 2021-10-14 15:00:38 +0000 | <merijn> | hippoid: *which* Applicative is inferred from the result |
| 2021-10-14 15:00:48 +0000 | <cigsender> | > pure @Maybe 10 |
| 2021-10-14 15:00:50 +0000 | <lambdabot> | error: |
| 2021-10-14 15:00:50 +0000 | <lambdabot> | Pattern syntax in expression context: pure@Maybe |
| 2021-10-14 15:00:50 +0000 | <lambdabot> | Did you mean to enable TypeApplications? |
| 2021-10-14 15:00:53 +0000 | <xsperry> | > pure 10 :: [Int] |
| 2021-10-14 15:00:54 +0000 | <lambdabot> | [10] |
| 2021-10-14 15:01:06 +0000 | <xsperry> | > pure 10 :: IO Int |
| 2021-10-14 15:01:08 +0000 | <lambdabot> | <IO Int> |
| 2021-10-14 15:01:12 +0000 | <hippoid> | :t pure 10 |
| 2021-10-14 15:01:13 +0000 | <lambdabot> | (Applicative f, Num a) => f a |
| 2021-10-14 15:01:21 +0000 | <hippoid> | what is f in that situation? |
| 2021-10-14 15:01:28 +0000 | <merijn> | hippoid: "any Applicative" |
| 2021-10-14 15:01:36 +0000 | <merijn> | hippoid: Which one, will be inferred when you try to use it |
| 2021-10-14 15:01:57 +0000 | <merijn> | > fromMaybe 0 (pure 10) |
| 2021-10-14 15:01:58 +0000 | <lambdabot> | 10 |
| 2021-10-14 15:02:17 +0000 | <jollygood2> | > head $ pure 10 |
| 2021-10-14 15:02:19 +0000 | <lambdabot> | 10 |
| 2021-10-14 15:02:26 +0000 | <merijn> | hippoid: fromMaybe wants a "Maybe a", so GHC infers "pure 10" has type "Maybe Int" and chooses Maybe |
| 2021-10-14 15:02:41 +0000 | <hippoid> | wow, that's mindblowing |
| 2021-10-14 15:03:30 +0000 | <hippoid> | :t pure 10 :: Either Int |
| 2021-10-14 15:03:31 +0000 | <lambdabot> | error: |
| 2021-10-14 15:03:31 +0000 | <lambdabot> | • Expecting one more argument to ‘Either Int’ |
| 2021-10-14 15:03:31 +0000 | <lambdabot> | Expected a type, but ‘Either Int’ has kind ‘* -> *’ |
| 2021-10-14 15:03:37 +0000 | <jollygood2> | Either takes two types |
| 2021-10-14 15:03:39 +0000 | <merijn> | > pure 10 :: Either Bool Int |
| 2021-10-14 15:03:41 +0000 | <lambdabot> | Right 10 |
| 2021-10-14 15:03:56 +0000 | <cigsender> | however: |
| 2021-10-14 15:04:02 +0000 | <hippoid> | ah ok, my mistake was thinking the second type would be inferred when I try to use it |
| 2021-10-14 15:04:03 +0000 | <merijn> | hippoid: Inference goes in both directions (unlike something like "auto" in C++/Java) |
| 2021-10-14 15:04:07 +0000 | <cigsender> | > pure 10 :: Either Int Bool |
| 2021-10-14 15:04:09 +0000 | <lambdabot> | error: |
| 2021-10-14 15:04:09 +0000 | <lambdabot> | • No instance for (Num Bool) arising from the literal ‘10’ |
| 2021-10-14 15:04:09 +0000 | <lambdabot> | • In the first argument of ‘pure’, namely ‘10’ |
| 2021-10-14 15:04:30 +0000 | <jollygood2> | hippoid it would be if you didn't specify it. but if you want to write explicit type, it has to be complete |
| 2021-10-14 15:04:45 +0000 | <merijn> | hippoid: If you (somehow) use something like that in a way where ghc *can't* infer the correct result, you will get an "ambiguous type" error |
| 2021-10-14 15:04:59 +0000 | <merijn> | > const 'a' (pure True) -- not sure this will give the error I want |
| 2021-10-14 15:05:01 +0000 | <lambdabot> | error: |
| 2021-10-14 15:05:01 +0000 | <lambdabot> | • Ambiguous type variable ‘f0’ arising from a use of ‘pure’ |
| 2021-10-14 15:05:01 +0000 | wroathe | (~wroathe@user/wroathe) (Ping timeout: 252 seconds) |
| 2021-10-14 15:05:01 +0000 | <lambdabot> | prevents the constraint ‘(Applicative f0)’ from being solved. |
| 2021-10-14 15:05:12 +0000 | <hippoid> | merijn: can you say more about "both directions" and type inference? To start, what are the two endpoints of the two directions? |
| 2021-10-14 15:05:30 +0000 | <merijn> | hippoid: Success! As you can see "hey, this is *some* Applicative, but not enough context to infer *which*, thus it's ambiguous" |
| 2021-10-14 15:06:10 +0000 | <merijn> | hippoid: One end is "individual syntactical tokens" which usually have types, like 'a' being Char and the top level signature |
| 2021-10-14 15:06:48 +0000 | <merijn> | hippoid: If you have "foo :: Bar -> Baz -> Quux; foo = ..." then we have 2 types, the ones specified as foo's type signature and "the type of the actual body of foo" |
| 2021-10-14 15:07:07 +0000 | <hippoid> | is it correct to say one end is terms, and the other end is types? |
| 2021-10-14 15:07:11 +0000 | <merijn> | If we write "foo = 'a'" then the 2nd would be Char, for example |
| 2021-10-14 15:08:01 +0000 | <merijn> | hippoid: More like one end is the types we *claim* something is, the other end is "the types we know the actual terms have" |
| 2021-10-14 15:08:25 +0000 | <xsperry> | perhaps it might be easier to understand polymorphic values outside of Applicative context. for example minBound |
| 2021-10-14 15:08:31 +0000 | <xsperry> | :t minBound |
| 2021-10-14 15:08:32 +0000 | <lambdabot> | Bounded a => a |
| 2021-10-14 15:08:37 +0000 | <xsperry> | > minBound :: Int |
| 2021-10-14 15:08:39 +0000 | <lambdabot> | -9223372036854775808 |
| 2021-10-14 15:08:42 +0000 | <xsperry> | > minBound :: Char |
| 2021-10-14 15:08:44 +0000 | <lambdabot> | '\NUL' |
| 2021-10-14 15:08:58 +0000 | <xsperry> | > [minBound ..] :: [Char] |
| 2021-10-14 15:09:00 +0000 | <lambdabot> | "\NUL\SOH\STX\ETX\EOT\ENQ\ACK\a\b\t\n\v\f\r\SO\SI\DLE\DC1\DC2\DC3\DC4\NAK\SY... |
| 2021-10-14 15:09:09 +0000 | <merijn> | hippoid: You can think of it as solving a bunch of equations. In the "fromMaybe 0 (pure 10)' case, then we have two pieces of information: 1) 'pure 10 :: Applicative f => f Int' and 2) 'pure 10 :: Maybe Int' (from the type of fromMaybe) |
| 2021-10-14 15:09:15 +0000 | <maerwald> | > minBound |
| 2021-10-14 15:09:17 +0000 | <lambdabot> | () |
| 2021-10-14 15:09:34 +0000 | <maerwald> | > [minBound ..] |
| 2021-10-14 15:09:36 +0000 | <lambdabot> | [()] |
| 2021-10-14 15:09:43 +0000 | <xsperry> | maerwald, I doubt that helps :P |
| 2021-10-14 15:09:55 +0000 | <merijn> | hippoid: Now typechecking is a matter of "is there a solution where these types line up?" answer "yes *iff* 'f' = 'Maybe'" |
| 2021-10-14 15:09:58 +0000 | <maerwald> | > maxBound |
| 2021-10-14 15:10:00 +0000 | <lambdabot> | () |
| 2021-10-14 15:10:00 +0000 | <maerwald> | :D |
| 2021-10-14 15:10:31 +0000 | <hippoid> | Are all these what is known as type unification? |
| 2021-10-14 15:10:39 +0000 | <hippoid> | *ideas |
| 2021-10-14 15:10:56 +0000 | <merijn> | hippoid: Type unification is part of the mechanical process of type checking/inference, yes |
| 2021-10-14 15:11:50 +0000 | <hippoid> | ahh ok, and you all are showing me examples of how to apply the logic of type checking/inference |
| 2021-10-14 15:12:03 +0000 | <merijn> | hippoid: Basically you assign every (sub)expression a new "unification" variable and then try to solve "is there a single mapping of 1 type to each unification variable that matches all restrictions" |
| 2021-10-14 15:13:05 +0000 | <merijn> | hippoid: In my example you have to try to unify "Maybe a" and "Applicative f => f Int" which works IFF 'a' = Int and 'f' = Maybe |
| 2021-10-14 15:13:33 +0000 | doyougnu | (~user@c-73-25-202-122.hsd1.or.comcast.net) |
| 2021-10-14 15:13:38 +0000 | <hippoid> | and that's what you mean by "both sides", there's an = in the middle, and then you can infer things from either side of that equal sign |
| 2021-10-14 15:13:44 +0000 | <merijn> | Right |
| 2021-10-14 15:14:38 +0000 | <hippoid> | ok, this has been very illuminating. Thanks merijn, xsperry, maerwald et al! |
| 2021-10-14 15:14:44 +0000 | <lortabac> | in practice unification alone is not sufficient to check a user-provided signature against the corresponding inferred type |
| 2021-10-14 15:15:06 +0000 | <lortabac> | you also need to check that the signature is more generic (or equal) than the inferred type |
| 2021-10-14 15:15:13 +0000 | <lortabac> | but I'm just nitpicking |
| 2021-10-14 15:15:45 +0000 | <hippoid> | right, because there can be many solutions, so you want the most generic one? |
| 2021-10-14 15:16:44 +0000 | <lortabac> | sorry I meant the inferred type is more generic than the signature |
| 2021-10-14 15:16:52 +0000 | <carbolymer> | if `MonadReader r m | m -> r`, why does this compile: https://bpa.st/YTRQ ? Is ghc assuming that there may be two different `MonadReader r m` for `m` at the same time? |
| 2021-10-14 15:17:21 +0000 | <merijn> | carbolymer: 'm' uniquely determines 'r' |
| 2021-10-14 15:17:25 +0000 | <merijn> | carbolymer: Not the other way around |
| 2021-10-14 15:17:46 +0000 | <merijn> | carbolymer: Now, obviously the same 'm' can't map to different 'r' and *you* know that |
| 2021-10-14 15:18:13 +0000 | <merijn> | carbolymer: But GHC won't discover that until you try and specify a *specific* 'm' |
| 2021-10-14 15:18:13 +0000 | <carbolymer> | merijn: I know that, but doesn't ghc too? |
| 2021-10-14 15:18:14 +0000 | <lortabac> | hippoid: so that this is valid (id :: Int -> Int; id x = x) but this is not (id :: a -> a; id x = x + 1) |
| 2021-10-14 15:18:18 +0000 | <merijn> | carbolymer: How? |
| 2021-10-14 15:18:28 +0000 | <merijn> | carbolymer: 'm' is unknown, so GHC knows nothing about it |
| 2021-10-14 15:18:37 +0000 | <carbolymer> | merijn: idk, just because functional dependency in MonadReader exists? |
| 2021-10-14 15:18:44 +0000 | <merijn> | GHC knows that *a specific* 'm' maps to a single unique 'r' |
| 2021-10-14 15:19:19 +0000 | <hippoid> | lortabac: because you can't use + on any type a |
| 2021-10-14 15:20:06 +0000 | <lortabac> | hippoid: exactly, a -> a means the function should be valid whatever 'a' is |
| 2021-10-14 15:21:07 +0000 | <hippoid> | lortabac: that's where that forall... stuff shows up. What is that called, that forall a.b... whatever notation? |
| 2021-10-14 15:22:14 +0000 | zebrag | (~chris@user/zebrag) |
| 2021-10-14 15:22:47 +0000 | geekosaur | (~geekosaur@xmonad/geekosaur) (Remote host closed the connection) |
| 2021-10-14 15:23:03 +0000 | slack1256 | (~slack1256@45.4.2.52) (Remote host closed the connection) |
| 2021-10-14 15:23:04 +0000 | <lortabac> | I don't know, I call it forall :) |
| 2021-10-14 15:24:04 +0000 | <lortabac> | I have to go, sorry |
| 2021-10-14 15:24:16 +0000 | <hippoid> | thanks for your help |
| 2021-10-14 15:24:19 +0000 | <hippoid> | lortabac++ |
| 2021-10-14 15:24:26 +0000 | geekosaur | (~geekosaur@xmonad/geekosaur) |
| 2021-10-14 15:24:31 +0000 | lortabac | (~lortabac@2a01:e0a:541:b8f0:d23a:63c3:dec2:f7ab) (Quit: WeeChat 2.8) |
| 2021-10-14 15:24:52 +0000 | hendursa1 | (~weechat@user/hendursaga) (Quit: hendursa1) |
| 2021-10-14 15:25:31 +0000 | hendursaga | (~weechat@user/hendursaga) |
| 2021-10-14 15:26:13 +0000 | eggplantade | (~Eggplanta@2600:1700:bef1:5e10:ac5a:4bd6:3f7c:fb35) |
| 2021-10-14 15:28:20 +0000 | <c_wraith> | kuribas: I just remembered it's absolutely trivial to rewrite that code without the call to error. [] type-checks there, and by construction that case cannot happen, so anything is fine. The problem is that's actually less reader-friendly to make it look like a normal case when it's actually a logical contradiction. |
| 2021-10-14 15:29:55 +0000 | <kuribas> | c_wraith: add a comment? |
| 2021-10-14 15:30:12 +0000 | <c_wraith> | comments only mean something if they're read |
| 2021-10-14 15:30:57 +0000 | <merijn> | hippoid: RankNTypes (or one of the others) |
| 2021-10-14 15:31:30 +0000 | <merijn> | hippoid: Note that (in the underlying theory/language used within GHC) all types have an *implicit* forall for every type variable |
| 2021-10-14 15:31:48 +0000 | <merijn> | hippoid: So GHC internally considers "id :: a -> a" as if it is "id :: forall a . a -> a" |
| 2021-10-14 15:32:54 +0000 | <carbolymer> | merijn: hmm, I need to meditate on that |
| 2021-10-14 15:33:43 +0000 | <dminuoso> | c_wraith: I think the real problem is that "logical contradiction" part. The reason we have bugs in the first place, is because we assume invariants to hold. Sometimes, yes, they are provably correct. Otherwise they are not, or they become bugged on some future refactoring. |
| 2021-10-14 15:33:58 +0000 | <dminuoso> | If we were always right about our assumptions, we wouldn't have bugs in the first place. |
| 2021-10-14 15:34:09 +0000 | <c_wraith> | that's exactly why the error message says you refactored it wrong. |
| 2021-10-14 15:34:20 +0000 | justsomeguy | (~justsomeg@user/justsomeguy) |
| 2021-10-14 15:34:31 +0000 | slack1256 | (~slack1256@45.4.2.52) |
| 2021-10-14 15:34:33 +0000 | <c_wraith> | If you end up in that case, you refactored it wrong, even if it was total |
| 2021-10-14 15:34:51 +0000 | <c_wraith> | I think it's better to be told you got it wrong, instead of silently working incorrectly |
| 2021-10-14 15:35:18 +0000 | <dminuoso> | c_wraith: Not if it spontaneously takes down a critical application. |
| 2021-10-14 15:35:30 +0000 | <dminuoso> | Think the previous discussion was really about how `error` can really blow up entire programs. |
| 2021-10-14 15:36:52 +0000 | <dminuoso> | And these error dont always show during development |
| 2021-10-14 15:36:54 +0000 | <kuribas> | dminuoso: unsafePerformIO to show a warning instead? |
| 2021-10-14 15:37:22 +0000 | <dminuoso> | kuribas: Heh, imprecise exceptions means you cant even properly catch that exceptoin. |
| 2021-10-14 15:37:36 +0000 | <dminuoso> | And inside pure code, this is an even tricker business |
| 2021-10-14 15:38:27 +0000 | <dminuoso> | You're giving up a lot of nice properties about your pure code, which is why we didnt have IO in the first place... |
| 2021-10-14 15:38:36 +0000 | werneta | (~werneta@70-142-214-115.lightspeed.irvnca.sbcglobal.net) |
| 2021-10-14 15:39:09 +0000 | rond_ | (~rond_@2a02:a31a:a23c:f480:2fd7:e087:5546:a438) |
| 2021-10-14 15:42:44 +0000 | <c_wraith> | I really actually mean "logical contradiction". Not just "that shouldn't happen". If you end up in that case, you have a thunk that needs to branch on the result of evaluating itself. The program will <<loop>> before it can throw that error. |
| 2021-10-14 15:43:04 +0000 | ec | (~ec@gateway/tor-sasl/ec) |
| 2021-10-14 15:43:09 +0000 | <c_wraith> | So you're crashing anyway |
| 2021-10-14 15:43:15 +0000 | <c_wraith> | the call to error is just documentation |
| 2021-10-14 15:43:25 +0000 | <merijn> | carbolymer: Basically, functional dependencies are nice an easy, 'cause you only have to "reason in one direction" |
| 2021-10-14 15:43:37 +0000 | <merijn> | carbolymer: Which simplifies how complicated things are to implement |
| 2021-10-14 15:44:11 +0000 | <merijn> | carbolymer: You are, effectively, asking "why doesn't GHC also reason *backwards*?" to which the answer is "because that's hard and why do hard things when you don't have to" |
| 2021-10-14 15:45:03 +0000 | <kuribas> | dminuoso: logging some warning, and returning a default value could be a decent alternative to simply crashing with an exception. |
| 2021-10-14 15:45:37 +0000 | <kuribas> | dminuoso: Then in pure code you could return Either err a |
| 2021-10-14 15:46:06 +0000 | <merijn> | carbolymer: Which happens to be super simple in the your example (because it's a super simple case), but doing that "in general" is hard |
| 2021-10-14 15:46:28 +0000 | <dminuoso> | kuribas: I would not, simply because due to the way IO works, that gives me no guarantees. |
| 2021-10-14 15:46:35 +0000 | lavaman | (~lavaman@98.38.249.169) |
| 2021-10-14 15:46:37 +0000 | <dminuoso> | Maybe this logs never, maybe this logs once, maybe this logs a thousand times |
| 2021-10-14 15:46:47 +0000 | mbuf | (~Shakthi@122.178.118.100) (Quit: Leaving) |
| 2021-10-14 15:46:49 +0000 | <dminuoso> | If you already have this inside Either err, just feed it outside to IO |
| 2021-10-14 15:46:52 +0000 | <dminuoso> | Or feed IO in there |
| 2021-10-14 15:47:15 +0000 | <dminuoso> | Ive come to appreciate unsafePerformIO as a strong code smell that you probably should move what you have into IO |
| 2021-10-14 15:47:30 +0000 | <dminuoso> | Too many ways Ive been bitten poorly, unsafePerformIO is really dangerous in some strange ways |
| 2021-10-14 15:47:33 +0000 | <jollygood2> | I asked yesterday, so if I can repeat my question again, as I need to decide which xml library to use now. file is only 200 kB and I am reading it once, so I'm wondering which of the half a dozen xml libraries are the simplest to use? |
| 2021-10-14 15:47:34 +0000 | <kuribas> | dminuoso: then return "Maybe a" in pure code. if it's nothing log the warning (in IO), and return a default value. |
| 2021-10-14 15:47:45 +0000 | <jollygood2> | performance shouldn't matter |
| 2021-10-14 15:48:07 +0000 | <dminuoso> | kuribas: Whats the value of the Nothing then? |
| 2021-10-14 15:48:17 +0000 | <dminuoso> | You're throwing away information now, and have shitty IO semantics for logging. |
| 2021-10-14 15:48:18 +0000 | <kuribas> | dminuoso: use the Default typeclass. |
| 2021-10-14 15:48:36 +0000 | <kuribas> | dminuoso: I mean, the goal is to continue, right? |
| 2021-10-14 15:48:36 +0000 | <dminuoso> | kuribas: I do something similar, but I dont use unsafePerformIO |
| 2021-10-14 15:48:41 +0000 | <dminuoso> | kuribas: In our SDN compiler we have this |
| 2021-10-14 15:49:12 +0000 | <kuribas> | yeah, unsafePerformIO will likely give a miserable experience. |
| 2021-10-14 15:49:54 +0000 | ec | (~ec@gateway/tor-sasl/ec) (Ping timeout: 276 seconds) |
| 2021-10-14 15:50:16 +0000 | <dminuoso> | kuribas: I have some `data CompEnv a = CompEnv { _comp_warnings :: IORef [OdinWarning], _comp_errors :: IORef [OdinError] }` |
| 2021-10-14 15:50:42 +0000 | <dminuoso> | And then my own `class UselessDefault a where useless :: a` |
| 2021-10-14 15:51:12 +0000 | <kuribas> | dminuoso: why not use Default then? |
| 2021-10-14 15:51:16 +0000 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 265 seconds) |
| 2021-10-14 15:51:24 +0000 | <dminuoso> | And then I have critical errors that bail out immediately and phase critical errors that allow the compiler to continue its current phase and then abort |
| 2021-10-14 15:51:27 +0000 | <kuribas> | dminuoso: it's just as useless :) |
| 2021-10-14 15:51:28 +0000 | <dminuoso> | kuribas: because Default has no semantics |
| 2021-10-14 15:51:52 +0000 | <dminuoso> | With UselessDefault every type I have generates special magic values that are still recognizable |
| 2021-10-14 15:51:58 +0000 | <dminuoso> | should I ever use it in the wrong place |
| 2021-10-14 15:52:08 +0000 | <dminuoso> | So now I do stuff like: |
| 2021-10-14 15:52:31 +0000 | <dminuoso> | useless <$ configErr "Something bad has happened" |
| 2021-10-14 15:53:08 +0000 | <dminuoso> | And additional combinators like `>|>` allow me conditional sequencing if no errors are present, >> will just proceed, so my compiler phases/stages use `>|>` between them |
| 2021-10-14 15:53:30 +0000 | <dminuoso> | That way my compiler can go as long as it can, collecting as many errors as it can |
| 2021-10-14 15:54:23 +0000 | <kuribas> | right |
| 2021-10-14 15:55:05 +0000 | <dminuoso> | IORefs are great things. :) |
| 2021-10-14 15:59:17 +0000 | lbseale | (~lbseale@user/ep1ctetus) |
| 2021-10-14 16:01:10 +0000 | rond_ | (~rond_@2a02:a31a:a23c:f480:2fd7:e087:5546:a438) (Quit: Client closed) |
| 2021-10-14 16:03:21 +0000 | mc47 | (~mc47@xmonad/TheMC47) |
| 2021-10-14 16:03:27 +0000 | econo | (uid147250@user/econo) |
| 2021-10-14 16:05:00 +0000 | justsomeguy | (~justsomeg@user/justsomeguy) (Ping timeout: 260 seconds) |
| 2021-10-14 16:06:45 +0000 | ec | (~ec@gateway/tor-sasl/ec) |
| 2021-10-14 16:07:27 +0000 | stiell | (~stiell@gateway/tor-sasl/stiell) (Ping timeout: 276 seconds) |
| 2021-10-14 16:08:50 +0000 | fgaz | (~fgaz@2001:470:69fc:105::842) (Quit: Bridge terminating on SIGTERM) |
| 2021-10-14 16:08:50 +0000 | jneira[m] | (~jneiramat@2001:470:69fc:105::d729) (Quit: Bridge terminating on SIGTERM) |
| 2021-10-14 16:08:50 +0000 | maerwald[m] | (~maerwaldm@2001:470:69fc:105::1ee) (Quit: Bridge terminating on SIGTERM) |
| 2021-10-14 16:08:50 +0000 | siraben | (~siraben@user/siraben) (Quit: Bridge terminating on SIGTERM) |
| 2021-10-14 16:08:50 +0000 | MatrixTravelerbo | (~voyagert2@2001:470:69fc:105::22) (Quit: Bridge terminating on SIGTERM) |
| 2021-10-14 16:08:50 +0000 | sm | (~sm@plaintextaccounting/sm) (Quit: Bridge terminating on SIGTERM) |
| 2021-10-14 16:08:50 +0000 | shiraeeshi[m] | (~shiraeesh@2001:470:69fc:105::1:77) (Quit: Bridge terminating on SIGTERM) |
| 2021-10-14 16:08:51 +0000 | unrooted | (~unrooted@2001:470:69fc:105::a4a) (Quit: Bridge terminating on SIGTERM) |
| 2021-10-14 16:08:51 +0000 | psydroid | (~psydroid@user/psydroid) (Quit: Bridge terminating on SIGTERM) |
| 2021-10-14 16:08:51 +0000 | peddie | (~peddie@2001:470:69fc:105::25d) (Quit: Bridge terminating on SIGTERM) |
| 2021-10-14 16:08:51 +0000 | cdsmith | (~cdsmithma@2001:470:69fc:105::284) (Quit: Bridge terminating on SIGTERM) |
| 2021-10-14 16:08:51 +0000 | rednaZ[m] | (~r3dnazmat@2001:470:69fc:105::ba70) (Quit: Bridge terminating on SIGTERM) |
| 2021-10-14 16:08:51 +0000 | ServerStatsDisco | (~serversta@2001:470:69fc:105::1a) (Quit: Bridge terminating on SIGTERM) |
| 2021-10-14 16:08:51 +0000 | quantum | (~quantum@user/quantum/x-8556232) (Quit: Bridge terminating on SIGTERM) |
| 2021-10-14 16:08:51 +0000 | Tisoxin | (~ikosit@user/ikosit) (Quit: Bridge terminating on SIGTERM) |
| 2021-10-14 16:08:51 +0000 | Arathorn | (~arathorn@2001:470:69fc:105::1f) (Quit: Bridge terminating on SIGTERM) |
| 2021-10-14 16:08:51 +0000 | denbrahe[m] | (~denbrahem@2001:470:69fc:105::19c0) (Quit: Bridge terminating on SIGTERM) |
| 2021-10-14 16:08:51 +0000 | ongy[m] | (~ongymatri@2001:470:69fc:105::5018) (Quit: Bridge terminating on SIGTERM) |
| 2021-10-14 16:08:51 +0000 | jophish | (~jophish@2001:470:69fc:105::670) (Quit: Bridge terminating on SIGTERM) |
| 2021-10-14 16:08:51 +0000 | YoungChiefBTW | (~youngchie@user/youngchiefbtw) (Quit: Bridge terminating on SIGTERM) |
| 2021-10-14 16:08:51 +0000 | PotatoHatsue | (~berberman@2001:470:69fc:105::b488) (Quit: Bridge terminating on SIGTERM) |
| 2021-10-14 16:08:51 +0000 | kadoban | (~kadoban@user/kadoban) (Quit: Bridge terminating on SIGTERM) |
| 2021-10-14 16:08:51 +0000 | wildsebastian | (~wildsebas@2001:470:69fc:105::1:14b1) (Quit: Bridge terminating on SIGTERM) |
| 2021-10-14 16:08:51 +0000 | maralorn | (~maralorn@2001:470:69fc:105::251) (Quit: Bridge terminating on SIGTERM) |
| 2021-10-14 16:08:51 +0000 | zwro[m] | (~zwromatri@2001:470:69fc:105::1d4) (Quit: Bridge terminating on SIGTERM) |
| 2021-10-14 16:08:51 +0000 | ericson2314 | (~ericson23@2001:470:69fc:105::70c) (Quit: Bridge terminating on SIGTERM) |
| 2021-10-14 16:08:51 +0000 | vaibhavsagar[m] | (~vaibhavsa@2001:470:69fc:105::ffe) (Quit: Bridge terminating on SIGTERM) |
| 2021-10-14 16:08:51 +0000 | the-coot[m] | (~the-cootm@2001:470:69fc:105::95f) (Quit: Bridge terminating on SIGTERM) |
| 2021-10-14 16:08:51 +0000 | carmysilna | (~brightly-@2001:470:69fc:105::2190) (Quit: Bridge terminating on SIGTERM) |
| 2021-10-14 16:08:51 +0000 | Topik[m] | (~topikmatr@2001:470:69fc:105::a082) (Quit: Bridge terminating on SIGTERM) |
| 2021-10-14 16:08:51 +0000 | bitonic | (~bitonic@2001:470:69fc:105::1812) (Quit: Bridge terminating on SIGTERM) |
| 2021-10-14 16:08:51 +0000 | zfnmxt | (~zfnmxtzfn@2001:470:69fc:105::2b32) (Quit: Bridge terminating on SIGTERM) |
| 2021-10-14 16:08:51 +0000 | Deide | (~deide@user/deide) (Quit: Bridge terminating on SIGTERM) |
| 2021-10-14 16:08:51 +0000 | Christoph[m] | (~hpotsirhc@2001:470:69fc:105::2ff8) (Quit: Bridge terminating on SIGTERM) |
| 2021-10-14 16:08:51 +0000 | kar1 | (~kar1@2001:470:69fc:105::c308) (Quit: Bridge terminating on SIGTERM) |
| 2021-10-14 16:08:52 +0000 | tsmc[m] | (~tsmcmatri@2001:470:69fc:105::1:7e1) (Quit: Bridge terminating on SIGTERM) |
| 2021-10-14 16:08:52 +0000 | Morrow[m] | (~morrowmma@2001:470:69fc:105::1d0) (Quit: Bridge terminating on SIGTERM) |
| 2021-10-14 16:08:52 +0000 | Artem[m] | (~artemtype@2001:470:69fc:105::75b) (Quit: Bridge terminating on SIGTERM) |
| 2021-10-14 16:08:52 +0000 | Ollie[m] | (~ollieocha@2001:470:69fc:105::41a5) (Quit: Bridge terminating on SIGTERM) |
| 2021-10-14 16:08:52 +0000 | moats | (~oats@user/oats) (Quit: Bridge terminating on SIGTERM) |
| 2021-10-14 16:08:52 +0000 | schuelermine[m] | (~schuelerm@user/schuelermine) (Quit: Bridge terminating on SIGTERM) |
| 2021-10-14 16:08:52 +0000 | amesgen[m] | (~amesgenm]@2001:470:69fc:105::82b) (Quit: Bridge terminating on SIGTERM) |
| 2021-10-14 16:08:52 +0000 | SawyerBergeron[m | (~sawyerber@2001:470:69fc:105::3036) (Quit: Bridge terminating on SIGTERM) |
| 2021-10-14 16:08:52 +0000 | alexfmpe[m] | (~alexfmpem@2001:470:69fc:105::38ba) (Quit: Bridge terminating on SIGTERM) |
| 2021-10-14 16:08:52 +0000 | Drew[m] | (~drewefenw@2001:470:69fc:105::c8c4) (Quit: Bridge terminating on SIGTERM) |
| 2021-10-14 16:08:52 +0000 | Magnus[m] | (~magthetch@2001:470:69fc:105::d1a7) (Quit: Bridge terminating on SIGTERM) |
| 2021-10-14 16:08:52 +0000 | ManofLetters[m] | (~manoflett@2001:470:69fc:105::3be) (Quit: Bridge terminating on SIGTERM) |
| 2021-10-14 16:08:52 +0000 | fcortesi | (~fcortesi@2001:470:69fc:105::f3a9) (Quit: Bridge terminating on SIGTERM) |
| 2021-10-14 16:08:52 +0000 | smichel17[m] | (~smichel17@2001:470:69fc:105::2d32) (Quit: Bridge terminating on SIGTERM) |
| 2021-10-14 16:08:52 +0000 | kevin[m]1 | (~pnotequal@2001:470:69fc:105::a54) (Quit: Bridge terminating on SIGTERM) |
| 2021-10-14 16:08:52 +0000 | jmcantrell | (~jmcantrel@user/jmcantrell) (Quit: Bridge terminating on SIGTERM) |
| 2021-10-14 16:08:52 +0000 | santiagopim[m] | (~santiagop@2001:470:69fc:105::e57d) (Quit: Bridge terminating on SIGTERM) |
| 2021-10-14 16:08:52 +0000 | hsek[m] | (~hsekmatri@2001:470:69fc:105::d18f) (Quit: Bridge terminating on SIGTERM) |
| 2021-10-14 16:08:52 +0000 | marinelli[m] | (~marinelli@2001:470:69fc:105::2d8) (Quit: Bridge terminating on SIGTERM) |
| 2021-10-14 16:08:52 +0000 | reddishblue[m] | (~reddishbl@2001:470:69fc:105::21eb) (Quit: Bridge terminating on SIGTERM) |
| 2021-10-14 16:08:52 +0000 | unclechu | (~unclechu@2001:470:69fc:105::354) (Quit: Bridge terminating on SIGTERM) |
| 2021-10-14 16:08:52 +0000 | aidy | (~aidy@2001:470:69fc:105::c7b4) (Quit: Bridge terminating on SIGTERM) |
| 2021-10-14 16:08:52 +0000 | fendor[m] | (~fendormat@2001:470:69fc:105::fcbd) (Quit: Bridge terminating on SIGTERM) |
| 2021-10-14 16:08:52 +0000 | srid[m] | (~sridmatri@2001:470:69fc:105::1c2) (Quit: Bridge terminating on SIGTERM) |
| 2021-10-14 16:08:53 +0000 | ru0mad[m] | (~ru0madmat@2001:470:69fc:105::9b2) (Quit: Bridge terminating on SIGTERM) |
| 2021-10-14 16:08:53 +0000 | thomasjm[m] | (~thomasjmm@2001:470:69fc:105::c6d9) (Quit: Bridge terminating on SIGTERM) |
| 2021-10-14 16:08:53 +0000 | hjulle[m] | (~hjullemat@2001:470:69fc:105::1dd) (Quit: Bridge terminating on SIGTERM) |
| 2021-10-14 16:08:53 +0000 | mekeor[m] | (~mekeormat@2001:470:69fc:105::17e4) (Quit: Bridge terminating on SIGTERM) |
| 2021-10-14 16:08:53 +0000 | hughjfchen[m] | (~hughjfche@2001:470:69fc:105::c29d) (Quit: Bridge terminating on SIGTERM) |
| 2021-10-14 16:08:53 +0000 | razor[m] | (~razormone@2001:470:69fc:105::f048) (Quit: Bridge terminating on SIGTERM) |
| 2021-10-14 16:08:53 +0000 | bb010g | (~bb010g@2001:470:69fc:105::9a5) (Quit: Bridge terminating on SIGTERM) |
| 2021-10-14 16:08:53 +0000 | bakinonion[m] | (~bakinonio@2001:470:69fc:105::ddb3) (Quit: Bridge terminating on SIGTERM) |
| 2021-10-14 16:08:53 +0000 | Deewiant | (~deewiant@2001:470:69fc:105::2fd3) (Quit: Bridge terminating on SIGTERM) |
| 2021-10-14 16:08:53 +0000 | dualinverter[m] | (~dualinver@2001:470:69fc:105::16a7) (Quit: Bridge terminating on SIGTERM) |
| 2021-10-14 16:08:53 +0000 | oak- | (~oakuniver@2001:470:69fc:105::fcd) (Quit: Bridge terminating on SIGTERM) |
| 2021-10-14 16:08:53 +0000 | ixlun | (~ixlun@2001:470:69fc:105::41b3) (Quit: Bridge terminating on SIGTERM) |
| 2021-10-14 16:08:53 +0000 | jesser[m] | (~jessermat@2001:470:69fc:105::d5ae) (Quit: Bridge terminating on SIGTERM) |
| 2021-10-14 16:08:53 +0000 | jinsun_ | (~jinsun@user/jinsun) (Quit: Bridge terminating on SIGTERM) |
| 2021-10-14 16:08:53 +0000 | reza[m] | (~rezaphone@2001:470:69fc:105::3eda) (Quit: Bridge terminating on SIGTERM) |
| 2021-10-14 16:08:53 +0000 | Orbstheorem | (~orbstheor@2001:470:69fc:105::a56) (Quit: Bridge terminating on SIGTERM) |
| 2021-10-14 16:08:54 +0000 | gdhffd[m] | (~gdhffdmat@2001:470:69fc:105::1:799) (Quit: Bridge terminating on SIGTERM) |
| 2021-10-14 16:08:54 +0000 | afotgkmnzj7asv3r | (~afotgkmnz@2001:470:69fc:105::c24b) (Quit: Bridge terminating on SIGTERM) |
| 2021-10-14 16:08:54 +0000 | asdofindia-m | (~akshaymat@2001:470:69fc:105::831) (Quit: Bridge terminating on SIGTERM) |
| 2021-10-14 16:08:54 +0000 | craige[m] | (~craigemcw@2001:470:69fc:105::35f1) (Quit: Bridge terminating on SIGTERM) |
| 2021-10-14 16:08:54 +0000 | soft | (~soft-matr@2001:470:69fc:105::c75) (Quit: Bridge terminating on SIGTERM) |
| 2021-10-14 16:08:54 +0000 | alex[m]1234567 | (~alexchete@2001:470:69fc:105::1:1001) (Quit: Bridge terminating on SIGTERM) |
| 2021-10-14 16:08:54 +0000 | justosophy[m] | (~justosoph@2001:470:69fc:105::572f) (Quit: Bridge terminating on SIGTERM) |
| 2021-10-14 16:08:54 +0000 | fakehacker[m] | (~fakehacke@2001:470:69fc:105::b5f0) (Quit: Bridge terminating on SIGTERM) |
| 2021-10-14 16:08:54 +0000 | IgnatInsarov[m] | (~kindaroma@2001:470:69fc:105::f5d9) (Quit: Bridge terminating on SIGTERM) |
| 2021-10-14 16:08:54 +0000 | dexmad[m] | (~dexmadmat@2001:470:69fc:105::e056) (Quit: Bridge terminating on SIGTERM) |
| 2021-10-14 16:08:54 +0000 | monadfritz[m] | (~ahdytmatr@2001:470:69fc:105::e1f1) (Quit: Bridge terminating on SIGTERM) |
| 2021-10-14 16:08:54 +0000 | wysteriary[m] | (~wysteriar@2001:470:69fc:105::a42e) (Quit: Bridge terminating on SIGTERM) |
| 2021-10-14 16:08:54 +0000 | cloudy | (~cloudy@2001:470:69fc:105::50c0) (Quit: Bridge terminating on SIGTERM) |
| 2021-10-14 16:08:54 +0000 | sam[m]12 | (~sammtopoi@2001:470:69fc:105::e887) (Quit: Bridge terminating on SIGTERM) |
| 2021-10-14 16:08:54 +0000 | TomasJakl[m] | (~jaklttchn@2001:470:69fc:105::a42) (Quit: Bridge terminating on SIGTERM) |
| 2021-10-14 16:08:54 +0000 | ilkecan[m] | (~ilkecanma@2001:470:69fc:105::1:79b) (Quit: Bridge terminating on SIGTERM) |
| 2021-10-14 16:08:54 +0000 | codygman[m] | (~codygman@2001:470:69fc:105::b4ba) (Quit: Bridge terminating on SIGTERM) |
| 2021-10-14 16:08:54 +0000 | stoicswe[m] | (~deadlette@2001:470:69fc:105::d277) (Quit: Bridge terminating on SIGTERM) |
| 2021-10-14 16:08:55 +0000 | xosdy[m] | (~xosdyalet@2001:470:69fc:105::31f7) (Quit: Bridge terminating on SIGTERM) |
| 2021-10-14 16:08:55 +0000 | Tavi[m] | (~factoidde@2001:470:69fc:105::1:819) (Quit: Bridge terminating on SIGTERM) |
| 2021-10-14 16:08:55 +0000 | jchia[m] | (~jchiamatr@2001:470:69fc:105::c50b) (Quit: Bridge terminating on SIGTERM) |
| 2021-10-14 16:08:55 +0000 | RosarioPulella[m | (~rosariopu@2001:470:69fc:105::a57) (Quit: Bridge terminating on SIGTERM) |
| 2021-10-14 16:08:55 +0000 | ftzm[m] | (~ftzmmatri@2001:470:69fc:105::1:dfc) (Quit: Bridge terminating on SIGTERM) |
| 2021-10-14 16:08:58 +0000 | hsiktas[m] | (~hsiktasma@2001:470:69fc:105::30d4) (Quit: Bridge terminating on SIGTERM) |
| 2021-10-14 16:10:05 +0000 | _ht | (~quassel@82-169-194-8.biz.kpn.net) |
| 2021-10-14 16:10:31 +0000 | azeem | (~azeem@emp-85-170.eduroam.uu.se) (Read error: Connection reset by peer) |
| 2021-10-14 16:12:06 +0000 | trillp | (~trillp@69.233.98.238) (Quit: nyaa~) |
| 2021-10-14 16:12:22 +0000 | azeem | (~azeem@emp-85-170.eduroam.uu.se) |
| 2021-10-14 16:13:10 +0000 | jchia[m] | (~jchiamatr@2001:470:69fc:105::c50b) |
| 2021-10-14 16:14:26 +0000 | hippoid | (~idris@184.105.6.88) (Quit: leaving) |
| 2021-10-14 16:16:33 +0000 | hendursaga | (~weechat@user/hendursaga) (Ping timeout: 276 seconds) |
| 2021-10-14 16:16:40 +0000 | azeem | (~azeem@emp-85-170.eduroam.uu.se) (Ping timeout: 260 seconds) |
| 2021-10-14 16:17:01 +0000 | justsomeguy | (~justsomeg@user/justsomeguy) |
| 2021-10-14 16:17:51 +0000 | ec | (~ec@gateway/tor-sasl/ec) (Ping timeout: 276 seconds) |
| 2021-10-14 16:19:09 +0000 | stiell | (~stiell@gateway/tor-sasl/stiell) |
| 2021-10-14 16:19:52 +0000 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) |
| 2021-10-14 16:22:44 +0000 | azeem | (~azeem@2a00:801:44b:8c08:deb2:1ae7:691a:354c) |
| 2021-10-14 16:23:29 +0000 | tromp | (~textual@dhcp-077-249-230-040.chello.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2021-10-14 16:24:04 +0000 | cfricke | (~cfricke@user/cfricke) (Quit: WeeChat 3.3) |
| 2021-10-14 16:24:46 +0000 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 265 seconds) |
| 2021-10-14 16:25:44 +0000 | oxide | (~lambda@user/oxide) (Ping timeout: 265 seconds) |
| 2021-10-14 16:25:44 +0000 | <jollygood2> | is anyone familiar with tagsoup? I can't figure out how to get tag's children |
| 2021-10-14 16:25:45 +0000 | MatrixTravelerbo | (~voyagert2@2001:470:69fc:105::22) |
| 2021-10-14 16:25:45 +0000 | dualinverter[m] | (~dualinver@2001:470:69fc:105::16a7) |
| 2021-10-14 16:25:45 +0000 | fgaz | (~fgaz@2001:470:69fc:105::842) |
| 2021-10-14 16:25:45 +0000 | peddie | (~peddie@2001:470:69fc:105::25d) |
| 2021-10-14 16:25:45 +0000 | cdsmith | (~cdsmithma@2001:470:69fc:105::284) |
| 2021-10-14 16:25:45 +0000 | Morrow[m] | (~morrowmma@2001:470:69fc:105::1d0) |
| 2021-10-14 16:25:45 +0000 | thomasjm[m] | (~thomasjmm@2001:470:69fc:105::c6d9) |
| 2021-10-14 16:25:46 +0000 | hsek[m] | (~hsekmatri@2001:470:69fc:105::d18f) |
| 2021-10-14 16:25:46 +0000 | ru0mad[m] | (~ru0madmat@2001:470:69fc:105::9b2) |
| 2021-10-14 16:25:58 +0000 | gdhffd[m] | (~gdhffdmat@2001:470:69fc:105::1:799) |
| 2021-10-14 16:25:58 +0000 | bb010g | (~bb010g@2001:470:69fc:105::9a5) |
| 2021-10-14 16:25:58 +0000 | ServerStatsDisco | (~serversta@2001:470:69fc:105::1a) |
| 2021-10-14 16:25:58 +0000 | amesgen[m] | (~amesgenm]@2001:470:69fc:105::82b) |
| 2021-10-14 16:25:58 +0000 | the-coot[m] | (~the-cootm@2001:470:69fc:105::95f) |
| 2021-10-14 16:25:59 +0000 | moats | (~oats@user/oats) |
| 2021-10-14 16:26:11 +0000 | soft | (~soft-matr@2001:470:69fc:105::c75) |
| 2021-10-14 16:26:11 +0000 | zfnmxt | (~zfnmxtzfn@2001:470:69fc:105::2b32) |
| 2021-10-14 16:26:26 +0000 | oak- | (~oakuniver@2001:470:69fc:105::fcd) |
| 2021-10-14 16:26:28 +0000 | kadoban | (~kadoban@user/kadoban) |
| 2021-10-14 16:26:28 +0000 | bitonic | (~bitonic@2001:470:69fc:105::1812) |
| 2021-10-14 16:26:28 +0000 | jophish | (~jophish@2001:470:69fc:105::670) |
| 2021-10-14 16:26:28 +0000 | ericson2314 | (~ericson23@2001:470:69fc:105::70c) |
| 2021-10-14 16:26:28 +0000 | Arathorn | (~arathorn@2001:470:69fc:105::1f) |
| 2021-10-14 16:26:29 +0000 | Ollie[m] | (~ollieocha@2001:470:69fc:105::41a5) |
| 2021-10-14 16:26:29 +0000 | PotatoHatsue | (~berberman@2001:470:69fc:105::b488) |
| 2021-10-14 16:26:29 +0000 | ixlun | (~ixlun@2001:470:69fc:105::41b3) |
| 2021-10-14 16:26:29 +0000 | unclechu | (~unclechu@2001:470:69fc:105::354) |
| 2021-10-14 16:26:29 +0000 | Deewiant | (~deewiant@2001:470:69fc:105::2fd3) |
| 2021-10-14 16:26:29 +0000 | unrooted | (~unrooted@2001:470:69fc:105::a4a) |
| 2021-10-14 16:26:29 +0000 | rednaZ[m] | (~r3dnazmat@2001:470:69fc:105::ba70) |
| 2021-10-14 16:26:30 +0000 | maralorn | (~maralorn@2001:470:69fc:105::251) |
| 2021-10-14 16:26:30 +0000 | denbrahe[m] | (~denbrahem@2001:470:69fc:105::19c0) |
| 2021-10-14 16:26:35 +0000 | chele | (~chele@user/chele) (Remote host closed the connection) |
| 2021-10-14 16:26:42 +0000 | jesser[m] | (~jessermat@2001:470:69fc:105::d5ae) |
| 2021-10-14 16:26:43 +0000 | reza[m] | (~rezaphone@2001:470:69fc:105::3eda) |
| 2021-10-14 16:26:43 +0000 | quantum | (~quantum@user/quantum/x-8556232) |
| 2021-10-14 16:26:43 +0000 | marinelli[m] | (~marinelli@2001:470:69fc:105::2d8) |
| 2021-10-14 16:26:43 +0000 | hsiktas[m] | (~hsiktasma@2001:470:69fc:105::30d4) |
| 2021-10-14 16:26:43 +0000 | Orbstheorem | (~orbstheor@2001:470:69fc:105::a56) |
| 2021-10-14 16:26:43 +0000 | craige[m] | (~craigemcw@2001:470:69fc:105::35f1) |
| 2021-10-14 16:26:43 +0000 | afotgkmnzj7asv3r | (~afotgkmnz@2001:470:69fc:105::c24b) |
| 2021-10-14 16:26:43 +0000 | schuelermine[m] | (~schuelerm@user/schuelermine) |
| 2021-10-14 16:26:43 +0000 | razor[m] | (~razormone@2001:470:69fc:105::f048) |
| 2021-10-14 16:26:43 +0000 | sm | (~sm@plaintextaccounting/sm) |
| 2021-10-14 16:26:44 +0000 | reddishblue[m] | (~reddishbl@2001:470:69fc:105::21eb) |
| 2021-10-14 16:26:56 +0000 | justosophy[m] | (~justosoph@2001:470:69fc:105::572f) |
| 2021-10-14 16:26:56 +0000 | kevin[m]1 | (~pnotequal@2001:470:69fc:105::a54) |
| 2021-10-14 16:26:56 +0000 | Deide | (~deide@user/deide) |
| 2021-10-14 16:27:08 +0000 | fakehacker[m] | (~fakehacke@2001:470:69fc:105::b5f0) |
| 2021-10-14 16:27:08 +0000 | hughjfchen[m] | (~hughjfche@2001:470:69fc:105::c29d) |
| 2021-10-14 16:27:08 +0000 | Artem[m] | (~artemtype@2001:470:69fc:105::75b) |
| 2021-10-14 16:27:20 +0000 | IgnatInsarov[m] | (~kindaroma@2001:470:69fc:105::f5d9) |
| 2021-10-14 16:27:20 +0000 | srid[m] | (~sridmatri@2001:470:69fc:105::1c2) |
| 2021-10-14 16:27:20 +0000 | psydroid | (~psydroid@user/psydroid) |
| 2021-10-14 16:27:20 +0000 | Christoph[m] | (~hpotsirhc@2001:470:69fc:105::2ff8) |
| 2021-10-14 16:27:31 +0000 | dka | (~code-is-a@ns3059207.ip-193-70-33.eu) (Quit: My Ex-Girlfriend once told me: I'm not a slut, I'm just popular) |
| 2021-10-14 16:27:32 +0000 | wysteriary[m] | (~wysteriar@2001:470:69fc:105::a42e) |
| 2021-10-14 16:27:32 +0000 | YoungChiefBTW | (~youngchie@2001:470:69fc:105::214c) |
| 2021-10-14 16:27:32 +0000 | zwro[m] | (~zwromatri@2001:470:69fc:105::1d4) |
| 2021-10-14 16:27:44 +0000 | stoicswe[m] | (~deadlette@2001:470:69fc:105::d277) |
| 2021-10-14 16:27:45 +0000 | sam[m]12 | (~sammtopoi@2001:470:69fc:105::e887) |
| 2021-10-14 16:27:45 +0000 | Topik[m] | (~topikmatr@2001:470:69fc:105::a082) |
| 2021-10-14 16:27:45 +0000 | kar1 | (~kar1@2001:470:69fc:105::c308) |
| 2021-10-14 16:27:45 +0000 | ongy[m] | (~ongymatri@2001:470:69fc:105::5018) |
| 2021-10-14 16:27:45 +0000 | alexfmpe[m] | (~alexfmpem@2001:470:69fc:105::38ba) |
| 2021-10-14 16:27:45 +0000 | asdofindia-m | (~akshaymat@2001:470:69fc:105::831) |
| 2021-10-14 16:27:45 +0000 | hjulle[m] | (~hjullemat@2001:470:69fc:105::1dd) |
| 2021-10-14 16:27:45 +0000 | Drew[m] | (~drewefenw@2001:470:69fc:105::c8c4) |
| 2021-10-14 16:27:45 +0000 | jneira[m] | (~jneiramat@2001:470:69fc:105::d729) |
| 2021-10-14 16:27:46 +0000 | Magnus[m] | (~magthetch@2001:470:69fc:105::d1a7) |
| 2021-10-14 16:27:46 +0000 | siraben | (~siraben@user/siraben) |
| 2021-10-14 16:27:46 +0000 | dexmad[m] | (~dexmadmat@2001:470:69fc:105::e056) |
| 2021-10-14 16:27:46 +0000 | smichel17[m] | (~smichel17@2001:470:69fc:105::2d32) |
| 2021-10-14 16:27:46 +0000 | SawyerBergeron[m | (~sawyerber@2001:470:69fc:105::3036) |
| 2021-10-14 16:27:46 +0000 | Tisoxin | (~ikosit@user/ikosit) |
| 2021-10-14 16:27:58 +0000 | monadfritz[m] | (~ahdytmatr@2001:470:69fc:105::e1f1) |
| 2021-10-14 16:27:58 +0000 | bakinonion[m] | (~bakinonio@2001:470:69fc:105::ddb3) |
| 2021-10-14 16:27:58 +0000 | alex[m]123 | (~alexchete@2001:470:69fc:105::1:1001) |
| 2021-10-14 16:27:58 +0000 | fcortesi | (~fcortesi@2001:470:69fc:105::f3a9) |
| 2021-10-14 16:27:58 +0000 | ManofLetters[m] | (~manoflett@2001:470:69fc:105::3be) |
| 2021-10-14 16:27:58 +0000 | cloudy | (~cloudy@2001:470:69fc:105::50c0) |
| 2021-10-14 16:27:59 +0000 | carmysilna | (~brightly-@2001:470:69fc:105::2190) |
| 2021-10-14 16:27:59 +0000 | fendor[m] | (~fendormat@2001:470:69fc:105::fcbd) |
| 2021-10-14 16:27:59 +0000 | aidy | (~aidy@2001:470:69fc:105::c7b4) |
| 2021-10-14 16:28:11 +0000 | TomasJakl[m] | (~jaklttchn@2001:470:69fc:105::a42) |
| 2021-10-14 16:28:11 +0000 | shiraeeshi[m] | (~shiraeesh@2001:470:69fc:105::1:77) |
| 2021-10-14 16:28:14 +0000 | dka | (~code-is-a@ns3059207.ip-193-70-33.eu) |
| 2021-10-14 16:28:23 +0000 | ilkecan[m] | (~ilkecanma@2001:470:69fc:105::1:79b) |
| 2021-10-14 16:28:23 +0000 | tsmc[m] | (~tsmcmatri@2001:470:69fc:105::1:7e1) |
| 2021-10-14 16:28:39 +0000 | codygman[m] | (~codygman@2001:470:69fc:105::b4ba) |
| 2021-10-14 16:28:39 +0000 | xosdy[m] | (~xosdyalet@2001:470:69fc:105::31f7) |
| 2021-10-14 16:28:39 +0000 | vaibhavsagar[m] | (~vaibhavsa@2001:470:69fc:105::ffe) |
| 2021-10-14 16:28:39 +0000 | santiagopim[m] | (~santiagop@2001:470:69fc:105::e57d) |
| 2021-10-14 16:28:51 +0000 | Tavi[m] | (~factoidde@2001:470:69fc:105::1:819) |
| 2021-10-14 16:28:52 +0000 | mekeor[m] | (~mekeormat@2001:470:69fc:105::17e4) |
| 2021-10-14 16:28:52 +0000 | jmcantrell | (~jmcantrel@user/jmcantrell) |
| 2021-10-14 16:28:53 +0000 | maerwald[m] | (~maerwaldm@2001:470:69fc:105::1ee) |
| 2021-10-14 16:28:53 +0000 | RosarioPulella[m | (~rosariopu@2001:470:69fc:105::a57) |
| 2021-10-14 16:29:01 +0000 | tzh | (~tzh@c-24-21-73-154.hsd1.or.comcast.net) |
| 2021-10-14 16:29:05 +0000 | ftzm[m] | (~ftzmmatri@2001:470:69fc:105::1:dfc) |
| 2021-10-14 16:29:05 +0000 | wildsebastian | (~wildsebas@2001:470:69fc:105::1:14b1) |
| 2021-10-14 16:29:05 +0000 | jinsun_ | (~jinsun@user/jinsun) |
| 2021-10-14 16:29:17 +0000 | mekeor[m] | (~mekeormat@2001:470:69fc:105::17e4) () |
| 2021-10-14 16:29:21 +0000 | ec | (~ec@gateway/tor-sasl/ec) |
| 2021-10-14 16:32:21 +0000 | mekeor[m] | (~mekeormat@2001:470:69fc:105::17e4) |
| 2021-10-14 16:41:58 +0000 | justsomeguy | (~justsomeg@user/justsomeguy) (Quit: WeeChat 3.2) |
| 2021-10-14 16:42:30 +0000 | pavonia | (~user@user/siracusa) (Quit: Bye!) |
| 2021-10-14 16:43:33 +0000 | kuribas | (~user@ip-188-118-57-242.reverse.destiny.be) (Quit: ERC (IRC client for Emacs 26.3)) |
| 2021-10-14 16:45:02 +0000 | <geekosaur> | jollygood2, one issue with tagsoup is that it's exactly that. (it's intended for parsing badly formed html where you can't even assume "children" is a thing) |
| 2021-10-14 16:45:32 +0000 | <geekosaur> | I mean, it manages to handle <a><b></a></b> |
| 2021-10-14 16:48:54 +0000 | <maerwald> | any gui library that works on windows and can be shipped reasonably? |
| 2021-10-14 16:48:58 +0000 | lavaman | (~lavaman@98.38.249.169) (Ping timeout: 252 seconds) |
| 2021-10-14 16:50:44 +0000 | Null_A | (~null_a@2601:645:8700:2290:6ce1:5557:ad33:ef82) |
| 2021-10-14 16:51:00 +0000 | <geekosaur> | in haskell? you already lost with "any gui library" imo |
| 2021-10-14 16:51:22 +0000 | <geekosaur> | I mean, there's gi-gtk, but bleargh |
| 2021-10-14 16:51:36 +0000 | <maerwald> | gtk can't be linked statically afair |
| 2021-10-14 16:51:58 +0000 | <geekosaur> | indeed it can't. and especially gi-gtk |
| 2021-10-14 16:52:39 +0000 | Null_A_ | (~null_a@2601:645:8700:2290:e4f7:cf97:bec9:9d10) |
| 2021-10-14 16:52:50 +0000 | ars23 | (~ars23@2a02:2f09:3e0b:6000:ecb0:eb26:7827:8e) |
| 2021-10-14 16:54:54 +0000 | <maerwald> | it seems you can only get haskellers attention about GUI when you mix it with "FRP" |
| 2021-10-14 16:55:04 +0000 | <maerwald> | and yet, nothing practical came out of it |
| 2021-10-14 16:55:31 +0000 | <monochrom> | A long time ago wx was quite preferred for covering Windows. I don't know about now. |
| 2021-10-14 16:55:38 +0000 | <maerwald> | it's abandoned |
| 2021-10-14 16:55:43 +0000 | <maerwald> | the issue tracker is on source forge |
| 2021-10-14 16:55:49 +0000 | <maerwald> | seems to not even build with v2 |
| 2021-10-14 16:55:56 +0000 | Null_A | (~null_a@2601:645:8700:2290:6ce1:5557:ad33:ef82) (Ping timeout: 245 seconds) |
| 2021-10-14 16:56:52 +0000 | <geekosaur> | wx kept changing faster than the haskell bindings could keep up :( |
| 2021-10-14 16:59:07 +0000 | tromp | (~textual@dhcp-077-249-230-040.chello.nl) |
| 2021-10-14 17:01:22 +0000 | turlando_ | (~turlando@93-42-250-112.ip89.fastwebnet.it) (Quit: turlando_) |
| 2021-10-14 17:02:27 +0000 | turlando | (~turlando@93-42-250-112.ip89.fastwebnet.it) |
| 2021-10-14 17:02:28 +0000 | turlando | (~turlando@93-42-250-112.ip89.fastwebnet.it) (Changing host) |
| 2021-10-14 17:02:28 +0000 | turlando | (~turlando@user/turlando) |
| 2021-10-14 17:11:30 +0000 | zebrag | (~chris@user/zebrag) (Quit: Konversation terminated!) |
| 2021-10-14 17:17:13 +0000 | hendursaga | (~weechat@user/hendursaga) |
| 2021-10-14 17:18:56 +0000 | <jollygood2> | geekosaur, so tagsoup can't do that? what xml parsing library can? |
| 2021-10-14 17:19:43 +0000 | cheater | (~Username@user/cheater) (Ping timeout: 265 seconds) |
| 2021-10-14 17:19:49 +0000 | mei6 | (~mei@user/mei) (Quit: mei6) |
| 2021-10-14 17:19:55 +0000 | <sm> | g'day all |
| 2021-10-14 17:20:28 +0000 | <sm> | maerwald: fltk-hs or monomer ? worth a look |
| 2021-10-14 17:21:23 +0000 | <monochrom> | Perhaps the next thing worth trying is https://hackage.haskell.org/package/xml |
| 2021-10-14 17:21:47 +0000 | <maerwald> | sm: do they work on windows without dynamic linking? |
| 2021-10-14 17:23:01 +0000 | theproffesor | (~theproffe@user/theproffesor) |
| 2021-10-14 17:23:57 +0000 | <sm> | I don't know about the linking |
| 2021-10-14 17:24:13 +0000 | fizzsegfaultbuzz | (~segfaultf@135-180-0-138.static.sonic.net) |
| 2021-10-14 17:27:00 +0000 | emf | (~emf@2620:10d:c090:400::5:c2a5) |
| 2021-10-14 17:28:04 +0000 | emf | (~emf@2620:10d:c090:400::5:c2a5) (Client Quit) |
| 2021-10-14 17:30:09 +0000 | Null_A_ | (~null_a@2601:645:8700:2290:e4f7:cf97:bec9:9d10) (Remote host closed the connection) |
| 2021-10-14 17:30:28 +0000 | amk | (~amk@109.255.169.126) (Remote host closed the connection) |
| 2021-10-14 17:30:44 +0000 | Null_A | (~null_a@2601:645:8700:2290:e4f7:cf97:bec9:9d10) |
| 2021-10-14 17:31:30 +0000 | amk | (~amk@109.255.169.126) |
| 2021-10-14 17:32:09 +0000 | Null_A | (~null_a@2601:645:8700:2290:e4f7:cf97:bec9:9d10) (Remote host closed the connection) |
| 2021-10-14 17:32:24 +0000 | Null_A | (~null_a@2601:645:8700:2290:e4f7:cf97:bec9:9d10) |
| 2021-10-14 17:39:12 +0000 | emf | (~emf@163.114.132.1) |
| 2021-10-14 17:39:45 +0000 | tromp | (~textual@dhcp-077-249-230-040.chello.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2021-10-14 17:45:05 +0000 | Null_A | (~null_a@2601:645:8700:2290:e4f7:cf97:bec9:9d10) (Remote host closed the connection) |
| 2021-10-14 17:45:25 +0000 | emf | (~emf@163.114.132.1) (Read error: Connection reset by peer) |
| 2021-10-14 17:45:37 +0000 | emf_ | (~emf@2620:10d:c090:400::5:c2a5) |
| 2021-10-14 17:47:14 +0000 | cheater | (~Username@user/cheater) |
| 2021-10-14 17:47:55 +0000 | gay | (~quassel@77-120-141-90.kha.volia.net) (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) |
| 2021-10-14 17:51:00 +0000 | ubert1 | (~Thunderbi@178.115.37.32.wireless.dyn.drei.com) (Remote host closed the connection) |
| 2021-10-14 17:53:00 +0000 | Null_A | (~null_a@2601:645:8700:2290:e4f7:cf97:bec9:9d10) |
| 2021-10-14 17:54:58 +0000 | Inst | (~Inst@2601:6c4:4080:3f80:4860:840:17cf:1bbb) (Ping timeout: 252 seconds) |
| 2021-10-14 17:57:45 +0000 | werneta | (~werneta@70-142-214-115.lightspeed.irvnca.sbcglobal.net) (Remote host closed the connection) |
| 2021-10-14 17:59:23 +0000 | tromp | (~textual@dhcp-077-249-230-040.chello.nl) |
| 2021-10-14 18:00:31 +0000 | tromp | (~textual@dhcp-077-249-230-040.chello.nl) (Client Quit) |
| 2021-10-14 18:01:19 +0000 | CiaoSen | (~Jura@p200300c95730dd002a3a4dfffe84dbd5.dip0.t-ipconnect.de) |
| 2021-10-14 18:03:52 +0000 | waleee | (~waleee@2001:9b0:216:8200:d457:9189:7843:1dbd) |
| 2021-10-14 18:14:38 +0000 | tromp | (~textual@dhcp-077-249-230-040.chello.nl) |
| 2021-10-14 18:20:29 +0000 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) |
| 2021-10-14 18:23:26 +0000 | MQ-17J | (~MQ-17J@d192-24-122-179.try.wideopenwest.com) (Read error: Connection reset by peer) |
| 2021-10-14 18:23:58 +0000 | MQ-17J | (~MQ-17J@d192-24-122-179.try.wideopenwest.com) |
| 2021-10-14 18:24:11 +0000 | YoungChiefBTW | (~youngchie@2001:470:69fc:105::214c) (Changing host) |
| 2021-10-14 18:24:11 +0000 | YoungChiefBTW | (~youngchie@user/youngchiefbtw) |
| 2021-10-14 18:26:41 +0000 | Pickchea | (~private@user/pickchea) |
| 2021-10-14 18:28:42 +0000 | tromp | (~textual@dhcp-077-249-230-040.chello.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2021-10-14 18:30:57 +0000 | tromp | (~textual@dhcp-077-249-230-040.chello.nl) |
| 2021-10-14 18:32:29 +0000 | wonko | (~wjc@62.115.229.50) |
| 2021-10-14 18:35:57 +0000 | meinside | (uid24933@id-24933.helmsley.irccloud.com) (Quit: Connection closed for inactivity) |
| 2021-10-14 18:37:14 +0000 | _bo | (~bo@217.18.216.247) |
| 2021-10-14 18:37:21 +0000 | dyeplexer | (~dyeplexer@user/dyeplexer) (Remote host closed the connection) |
| 2021-10-14 18:41:21 +0000 | tromp | (~textual@dhcp-077-249-230-040.chello.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2021-10-14 18:49:40 +0000 | Lycurgus | (~juan@98.4.112.204) |
| 2021-10-14 18:51:44 +0000 | tromp | (~textual@dhcp-077-249-230-040.chello.nl) |
| 2021-10-14 18:54:06 +0000 | eggplantade | (~Eggplanta@2600:1700:bef1:5e10:ac5a:4bd6:3f7c:fb35) (Remote host closed the connection) |
| 2021-10-14 18:54:56 +0000 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 265 seconds) |
| 2021-10-14 18:56:32 +0000 | werneta | (~werneta@70-142-214-115.lightspeed.irvnca.sbcglobal.net) |
| 2021-10-14 19:00:39 +0000 | wrengr_away | wrengr |
| 2021-10-14 19:01:47 +0000 | [exa] | (exa@srv3.blesmrt.net) (Remote host closed the connection) |
| 2021-10-14 19:02:03 +0000 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) (Quit: FinnElija) |
| 2021-10-14 19:05:55 +0000 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) |
| 2021-10-14 19:07:54 +0000 | <shapr> | Is hinotify the best way to do file watching on Linux these days? |
| 2021-10-14 19:09:34 +0000 | <dminuoso> | The only, really. |
| 2021-10-14 19:09:56 +0000 | <dminuoso> | I mean you can simply poll of course |
| 2021-10-14 19:10:07 +0000 | coot | (~coot@37.30.52.44.nat.umts.dynamic.t-mobile.pl) (Quit: coot) |
| 2021-10-14 19:11:39 +0000 | Lycurgus | (~juan@98.4.112.204) (Quit: Exeunt) |
| 2021-10-14 19:13:12 +0000 | tromp | (~textual@dhcp-077-249-230-040.chello.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2021-10-14 19:17:51 +0000 | d34df00d | (~d34df00d@2600:1700:8c60:3a10::48) |
| 2021-10-14 19:18:00 +0000 | <d34df00d> | Hi! |
| 2021-10-14 19:18:26 +0000 | <geekosaur> | œ |
| 2021-10-14 19:18:44 +0000 | <maerwald> | shapr: it's a good library |
| 2021-10-14 19:19:16 +0000 | <d34df00d> | I'm trying to add https://github.com/input-output-hk/plutus as an extra-dep to my stack-based project, basically via `extra-deps: - github: ...`. |
| 2021-10-14 19:19:45 +0000 | <maerwald> | d34df00d: you shouldn't use stack for plutus |
| 2021-10-14 19:19:45 +0000 | <d34df00d> | The error I'm getting is `No cabal file found for Archive from https://github.com/input-output-hk/plutus/archive/e2cd641501d13715120329092b3a93df35493a44.tar.gz` — which is true, there's only cabal.project. |
| 2021-10-14 19:19:56 +0000 | <d34df00d> | maerwald: what should I use instead? |
| 2021-10-14 19:19:59 +0000 | <maerwald> | cabal |
| 2021-10-14 19:20:02 +0000 | <d34df00d> | Ah ok. |
| 2021-10-14 19:20:45 +0000 | <d34df00d> | I was kinda bitten recently by a to vague bound in a plutus dep, which surprisingly didn't bite other folks working on the same code base, so I was hoping stack would give me something more reproducible. |
| 2021-10-14 19:20:54 +0000 | <d34df00d> | s/a to /a too / |
| 2021-10-14 19:21:11 +0000 | <maerwald> | use a freeze file to make it reproducible |
| 2021-10-14 19:21:35 +0000 | <d34df00d> | TIL cabal freeze files |
| 2021-10-14 19:21:39 +0000 | <geekosaur> | more completely, plutus is a collection of packages, not just one package, and you'd have to inspect the cabal.project to determine the subprojects and their cabal files, and possibly which checkouts if they're separate fromn plutus itself |
| 2021-10-14 19:22:04 +0000 | <maerwald> | but I don't think you can expect the plutus script itself to be reproducible (I mean the actual script that you generate to submit to the chain) |
| 2021-10-14 19:22:14 +0000 | <maerwald> | GHC version and other stuff might leak into tit |
| 2021-10-14 19:22:15 +0000 | <d34df00d> | Ah, I don't care abou that. |
| 2021-10-14 19:22:19 +0000 | <maerwald> | ok |
| 2021-10-14 19:22:35 +0000 | <d34df00d> | I'm writing some purely haskell stuff around plutus ecosystem, no smart contracts yet. |
| 2021-10-14 19:22:51 +0000 | <geekosaur> | (cabal.project very roughly serves the sanme purpose as stack.yaml) |
| 2021-10-14 19:22:53 +0000 | jgeerds | (~jgeerds@55d4da80.access.ecotel.net) (Ping timeout: 264 seconds) |
| 2021-10-14 19:22:55 +0000 | <d34df00d> | But that's interesting, thanks for the heads-up! |
| 2021-10-14 19:23:04 +0000 | <maerwald> | the stack file in plutus repo is outdated often. The developers use cabal primarily |
| 2021-10-14 19:24:20 +0000 | emf_ | (~emf@2620:10d:c090:400::5:c2a5) (Quit: emf_) |
| 2021-10-14 19:29:30 +0000 | tdaeayusr^^ | (~tdaeayusr@70.166.66.234) |
| 2021-10-14 19:30:04 +0000 | MQ-17J | (~MQ-17J@d192-24-122-179.try.wideopenwest.com) (Read error: Connection reset by peer) |
| 2021-10-14 19:30:17 +0000 | MQ-17J | (~MQ-17J@d192-24-122-179.try.wideopenwest.com) |
| 2021-10-14 19:30:43 +0000 | coot | (~coot@37.30.52.44.nat.umts.dynamic.t-mobile.pl) |
| 2021-10-14 19:32:08 +0000 | <d34df00d> | Good to know. Thanks! I'll stick with cabal. |
| 2021-10-14 19:34:21 +0000 | werneta | (~werneta@70-142-214-115.lightspeed.irvnca.sbcglobal.net) (Remote host closed the connection) |
| 2021-10-14 19:37:26 +0000 | abhixec | (~abhixec@c-67-169-139-16.hsd1.ca.comcast.net) (Remote host closed the connection) |
| 2021-10-14 19:40:24 +0000 | abhixec | (~abhixec@c-67-169-139-16.hsd1.ca.comcast.net) |
| 2021-10-14 19:41:55 +0000 | bontaq | (~user@ool-45779fe5.dyn.optonline.net) (Remote host closed the connection) |
| 2021-10-14 19:46:36 +0000 | benin | (~benin@183.82.206.194) |
| 2021-10-14 19:49:43 +0000 | emf | (~emf@2620:10d:c090:400::5:c2a5) |
| 2021-10-14 19:50:25 +0000 | bitdex_ | (~bitdex@gateway/tor-sasl/bitdex) |
| 2021-10-14 19:53:00 +0000 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Ping timeout: 276 seconds) |
| 2021-10-14 19:53:01 +0000 | dsf | (~dsf@cpe-66-75-56-205.san.res.rr.com) (Ping timeout: 245 seconds) |
| 2021-10-14 19:53:59 +0000 | werneta | (~werneta@70-142-214-115.lightspeed.irvnca.sbcglobal.net) |
| 2021-10-14 19:54:30 +0000 | eggplantade | (~Eggplanta@2600:1700:bef1:5e10:1cce:2f0c:1ac6:f97f) |
| 2021-10-14 19:58:51 +0000 | eggplantade | (~Eggplanta@2600:1700:bef1:5e10:1cce:2f0c:1ac6:f97f) (Ping timeout: 245 seconds) |
| 2021-10-14 20:01:19 +0000 | Null_A | (~null_a@2601:645:8700:2290:e4f7:cf97:bec9:9d10) (Remote host closed the connection) |
| 2021-10-14 20:02:43 +0000 | pavonia | (~user@user/siracusa) |
| 2021-10-14 20:04:18 +0000 | Null_A | (~null_a@2601:645:8700:2290:e4f7:cf97:bec9:9d10) |
| 2021-10-14 20:04:46 +0000 | benin | (~benin@183.82.206.194) (Ping timeout: 252 seconds) |
| 2021-10-14 20:05:19 +0000 | juhp | (~juhp@128.106.188.220) (Ping timeout: 252 seconds) |
| 2021-10-14 20:07:47 +0000 | juhp | (~juhp@128.106.188.220) |
| 2021-10-14 20:09:20 +0000 | Lycurgus | (~juan@98.4.112.204) |
| 2021-10-14 20:12:08 +0000 | neurocyte0132889 | (~neurocyte@213.188.113.91) |
| 2021-10-14 20:12:08 +0000 | neurocyte0132889 | (~neurocyte@213.188.113.91) (Changing host) |
| 2021-10-14 20:12:08 +0000 | neurocyte0132889 | (~neurocyte@user/neurocyte) |
| 2021-10-14 20:13:46 +0000 | Pickchea | (~private@user/pickchea) (Quit: Leaving) |
| 2021-10-14 20:14:37 +0000 | alx741 | (~alx741@181.196.69.128) (Ping timeout: 252 seconds) |
| 2021-10-14 20:16:12 +0000 | hexology | (~hexology@user/hexology) (Quit: hex on you ...) |
| 2021-10-14 20:20:08 +0000 | fvr | (uid503686@id-503686.uxbridge.irccloud.com) |
| 2021-10-14 20:20:42 +0000 | fluxit | (~fluxit@techsmix.net) |
| 2021-10-14 20:21:13 +0000 | mc47 | (~mc47@xmonad/TheMC47) (Remote host closed the connection) |
| 2021-10-14 20:22:45 +0000 | aegon | (~mike@174.127.249.180) |
| 2021-10-14 20:22:53 +0000 | wyrd | (~wyrd@gateway/tor-sasl/wyrd) (Quit: leaving) |
| 2021-10-14 20:24:20 +0000 | _ht | (~quassel@82-169-194-8.biz.kpn.net) (Remote host closed the connection) |
| 2021-10-14 20:30:32 +0000 | coot | (~coot@37.30.52.44.nat.umts.dynamic.t-mobile.pl) (Quit: coot) |
| 2021-10-14 20:32:11 +0000 | wonko | (~wjc@62.115.229.50) (Ping timeout: 245 seconds) |
| 2021-10-14 20:34:30 +0000 | neurocyte0132889 | (~neurocyte@user/neurocyte) (Ping timeout: 265 seconds) |
| 2021-10-14 20:36:26 +0000 | ars23 | (~ars23@2a02:2f09:3e0b:6000:ecb0:eb26:7827:8e) (Quit: Leaving) |
| 2021-10-14 20:37:46 +0000 | tom_ | (~tom@2a00:23c8:970c:4801:5b6a:e81b:79dc:f684) (Ping timeout: 252 seconds) |
| 2021-10-14 20:39:37 +0000 | Lycurgus | (~juan@98.4.112.204) (K-Lined) |
| 2021-10-14 20:41:09 +0000 | zincy | (~tom@2a00:23c8:970c:4801:5b6a:e81b:79dc:f684) |
| 2021-10-14 20:42:46 +0000 | zincy | (~tom@2a00:23c8:970c:4801:5b6a:e81b:79dc:f684) (Read error: Connection reset by peer) |
| 2021-10-14 20:45:23 +0000 | Tuplanolla | (~Tuplanoll@91-159-69-50.elisa-laajakaista.fi) |
| 2021-10-14 20:46:12 +0000 | takuan | (~takuan@178-116-218-225.access.telenet.be) (Remote host closed the connection) |
| 2021-10-14 20:46:23 +0000 | lavaman | (~lavaman@98.38.249.169) |
| 2021-10-14 20:48:46 +0000 | dhouthoo | (~dhouthoo@178-117-36-167.access.telenet.be) (Quit: WeeChat 3.3) |
| 2021-10-14 20:49:41 +0000 | tromp | (~textual@dhcp-077-249-230-040.chello.nl) |
| 2021-10-14 20:50:31 +0000 | lavaman | (~lavaman@98.38.249.169) (Ping timeout: 245 seconds) |
| 2021-10-14 20:51:59 +0000 | __monty__ | (~toonn@user/toonn) |
| 2021-10-14 20:53:32 +0000 | Neuromancer | (~Neuromanc@user/neuromancer) |
| 2021-10-14 20:55:05 +0000 | Cajun | (~Cajun@user/cajun) (Ping timeout: 256 seconds) |
| 2021-10-14 20:56:44 +0000 | acidjnk_new | (~acidjnk@p200300d0c703cb2624cf652eb5c49df1.dip0.t-ipconnect.de) |
| 2021-10-14 20:56:47 +0000 | alzgh | (~alzgh@user/alzgh) (Ping timeout: 256 seconds) |
| 2021-10-14 20:56:56 +0000 | eggplantade | (~Eggplanta@2600:1700:bef1:5e10:21fb:d4a:1e2:e3eb) |
| 2021-10-14 21:01:15 +0000 | jgeerds | (~jgeerds@55d4da80.access.ecotel.net) |
| 2021-10-14 21:01:45 +0000 | eggplantade | (~Eggplanta@2600:1700:bef1:5e10:21fb:d4a:1e2:e3eb) (Ping timeout: 268 seconds) |
| 2021-10-14 21:07:33 +0000 | eggplantade | (~Eggplanta@2600:1700:bef1:5e10:21fb:d4a:1e2:e3eb) |
| 2021-10-14 21:17:31 +0000 | ubert | (~Thunderbi@178.115.37.32.wireless.dyn.drei.com) (Ping timeout: 265 seconds) |
| 2021-10-14 21:17:37 +0000 | echoone | (~echoone@2a02:8109:a1c0:5d05:58b9:5c9f:8b69:dc13) |
| 2021-10-14 21:20:53 +0000 | eggplantade | (~Eggplanta@2600:1700:bef1:5e10:21fb:d4a:1e2:e3eb) (Remote host closed the connection) |
| 2021-10-14 21:21:56 +0000 | Null_A | (~null_a@2601:645:8700:2290:e4f7:cf97:bec9:9d10) (Remote host closed the connection) |
| 2021-10-14 21:24:34 +0000 | notzmv | (~zmv@user/notzmv) (Ping timeout: 268 seconds) |
| 2021-10-14 21:25:02 +0000 | Lord_of_Life_ | (~Lord@user/lord-of-life/x-2819915) |
| 2021-10-14 21:26:22 +0000 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) (Ping timeout: 265 seconds) |
| 2021-10-14 21:26:22 +0000 | Lord_of_Life_ | Lord_of_Life |
| 2021-10-14 21:27:15 +0000 | Null_A | (~null_a@2601:645:8700:2290:e4f7:cf97:bec9:9d10) |
| 2021-10-14 21:27:52 +0000 | wyrd | (~wyrd@gateway/tor-sasl/wyrd) |
| 2021-10-14 21:32:00 +0000 | rembo10 | (~rembo10@remulis.com) (Quit: ZNC 1.8.2 - https://znc.in) |
| 2021-10-14 21:32:16 +0000 | rembo10 | (~rembo10@remulis.com) |
| 2021-10-14 21:33:45 +0000 | chexum_ | (~quassel@gateway/tor-sasl/chexum) (Ping timeout: 276 seconds) |
| 2021-10-14 21:33:45 +0000 | jpds | (~jpds@gateway/tor-sasl/jpds) (Ping timeout: 276 seconds) |
| 2021-10-14 21:33:53 +0000 | chexum | (~quassel@gateway/tor-sasl/chexum) |
| 2021-10-14 21:34:52 +0000 | jpds | (~jpds@gateway/tor-sasl/jpds) |
| 2021-10-14 21:37:11 +0000 | Null_A | (~null_a@2601:645:8700:2290:e4f7:cf97:bec9:9d10) (Remote host closed the connection) |
| 2021-10-14 21:44:14 +0000 | michalz | (~michalz@185.246.204.93) (Remote host closed the connection) |
| 2021-10-14 21:49:08 +0000 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) |
| 2021-10-14 21:55:35 +0000 | xff0x | (~xff0x@2001:1a81:5210:a600:f14:89c2:cfb:bd25) (Ping timeout: 260 seconds) |
| 2021-10-14 21:56:32 +0000 | xff0x | (~xff0x@2001:1a81:5210:a600:1bfc:35a2:5bfe:31) |
| 2021-10-14 22:00:48 +0000 | fendor_ | (~fendor@77.119.208.38.wireless.dyn.drei.com) (Remote host closed the connection) |
| 2021-10-14 22:01:22 +0000 | max22- | (~maxime@2a01cb0883359800f362ea56be7f8960.ipv6.abo.wanadoo.fr) (Quit: Leaving) |
| 2021-10-14 22:01:27 +0000 | tromp | (~textual@dhcp-077-249-230-040.chello.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2021-10-14 22:02:25 +0000 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 252 seconds) |
| 2021-10-14 22:02:41 +0000 | gehmehgeh | (~user@user/gehmehgeh) (Quit: Leaving) |
| 2021-10-14 22:03:40 +0000 | geekosaur | (~geekosaur@xmonad/geekosaur) (Quit: Leaving) |
| 2021-10-14 22:05:07 +0000 | geekosaur | (~geekosaur@xmonad/geekosaur) |
| 2021-10-14 22:08:15 +0000 | echoone | (~echoone@2a02:8109:a1c0:5d05:58b9:5c9f:8b69:dc13) (Quit: Client closed) |
| 2021-10-14 22:08:49 +0000 | zebrag | (~chris@user/zebrag) |
| 2021-10-14 22:16:36 +0000 | agoraphobic_ | (~agoraphob@ip11-173.bon.riksnet.se) (Quit: ZNC 1.8.2+deb2+b1 - https://znc.in) |
| 2021-10-14 22:16:37 +0000 | peterhil | (~peterhil@dsl-hkibng32-54fb52-57.dhcp.inet.fi) (Read error: Connection reset by peer) |
| 2021-10-14 22:16:49 +0000 | agoraphobic | (~agoraphob@ip11-173.bon.riksnet.se) |
| 2021-10-14 22:17:31 +0000 | peterhil | (~peterhil@dsl-hkibng32-54fb52-57.dhcp.inet.fi) |
| 2021-10-14 22:17:42 +0000 | Vajb | (~Vajb@hag-jnsbng11-58c3a8-176.dhcp.inet.fi) (Read error: Connection reset by peer) |
| 2021-10-14 22:18:04 +0000 | Vajb | (~Vajb@hag-jnsbng11-58c3a8-176.dhcp.inet.fi) |
| 2021-10-14 22:18:24 +0000 | Tuplanolla | (~Tuplanoll@91-159-69-50.elisa-laajakaista.fi) (Quit: Leaving.) |
| 2021-10-14 22:21:17 +0000 | eggplantade | (~Eggplanta@2600:1700:bef1:5e10:21fb:d4a:1e2:e3eb) |
| 2021-10-14 22:25:31 +0000 | eggplantade | (~Eggplanta@2600:1700:bef1:5e10:21fb:d4a:1e2:e3eb) (Ping timeout: 245 seconds) |
| 2021-10-14 22:26:09 +0000 | Gurkenglas | (~Gurkengla@dslb-002-203-144-204.002.203.pools.vodafone-ip.de) (Ping timeout: 265 seconds) |
| 2021-10-14 22:28:15 +0000 | hexfive | (~eric@50.35.83.177) |
| 2021-10-14 22:31:04 +0000 | zero | zzz |
| 2021-10-14 22:33:52 +0000 | __monty__ | (~toonn@user/toonn) (Quit: leaving) |
| 2021-10-14 22:35:45 +0000 | zzz | yin |
| 2021-10-14 22:36:54 +0000 | hexfive | (~eric@50.35.83.177) (Quit: WeeChat 3.0.1) |
| 2021-10-14 22:37:38 +0000 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) |
| 2021-10-14 22:40:28 +0000 | werneta | (~werneta@70-142-214-115.lightspeed.irvnca.sbcglobal.net) (Remote host closed the connection) |
| 2021-10-14 22:40:36 +0000 | jollygood2 | (~bc8165b6@217.29.117.252) (Quit: http://www.okay.uz/ (Session timeout)) |
| 2021-10-14 22:41:56 +0000 | markusde | (~makrus@2604:3d08:6f80:6b00::2ba7) |
| 2021-10-14 22:42:01 +0000 | merijn | (~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 252 seconds) |
| 2021-10-14 22:52:35 +0000 | Null_A | (~null_a@2601:645:8700:2290:e4f7:cf97:bec9:9d10) |
| 2021-10-14 22:52:35 +0000 | MQ-17J | (~MQ-17J@d192-24-122-179.try.wideopenwest.com) (Read error: Connection reset by peer) |
| 2021-10-14 22:52:46 +0000 | MQ-17J | (~MQ-17J@8.6.144.117) |
| 2021-10-14 22:53:01 +0000 | eggplantade | (~Eggplanta@2600:1700:bef1:5e10:21fb:d4a:1e2:e3eb) |
| 2021-10-14 22:53:46 +0000 | abrantesasf | (~abrantesa@187.36.170.211) |
| 2021-10-14 22:55:51 +0000 | idris | (~idris@184.105.6.88) |
| 2021-10-14 22:56:04 +0000 | idris | hippoid |
| 2021-10-14 23:04:39 +0000 | <ph88> | So when the S combinator in lambda calculus is written as S=λxyz.(xz)(yz). And <*> is the S combinator for the applicative instance. Then how can the type signature of <*> be compared with the lambda equation ? S=λxyz.(xz)(yz). VS (<*>) :: Applicative f => f (a -> b) -> f a -> f b |
| 2021-10-14 23:05:00 +0000 | Everything | (~Everythin@37.115.210.35) (Quit: leaving) |
| 2021-10-14 23:06:48 +0000 | <hpc> | that lambda term more corresponds to the value of (<*>) for a specific instance |
| 2021-10-14 23:07:22 +0000 | <hpc> | you can probably work out which instance yourself |
| 2021-10-14 23:07:29 +0000 | <hpc> | hint: look at x |
| 2021-10-14 23:07:30 +0000 | <hippoid> | typeclassopedia talks about `Applicative` as a way to "encapsulate certain sorts of effectful computations". What are "effectful computations"? |
| 2021-10-14 23:08:15 +0000 | <hippoid> | wow, I jumped into this conversation at the right time apparently |
| 2021-10-14 23:08:24 +0000 | <hpc> | heh |
| 2021-10-14 23:09:17 +0000 | <hippoid> | is "effectful computations" the same things as "functions with side effects"? |
| 2021-10-14 23:09:45 +0000 | <hpc> | hippoid: it's shorthand for a fairly specific notion of "this thing expresses more than just being an integer or boolean or whatever" |
| 2021-10-14 23:09:58 +0000 | <ph88> | hpc, not sure what you are talking about |
| 2021-10-14 23:10:49 +0000 | <hippoid> | hmm |
| 2021-10-14 23:10:50 +0000 | <hpc> | ph88: S=λxyz.(xz)(yz) is value-level and Applicative f => f (a -> b) -> f a -> f b is type-level |
| 2021-10-14 23:11:01 +0000 | <hpc> | hippoid: so for example, IO or Maybe |
| 2021-10-14 23:11:12 +0000 | <hippoid> | :i Maybe |
| 2021-10-14 23:11:21 +0000 | <hpc> | or [] (the type, not the value) |
| 2021-10-14 23:11:35 +0000 | <hpc> | > (+) <$> [10, 20] <*> [1, 2] |
| 2021-10-14 23:11:37 +0000 | <lambdabot> | [11,12,21,22] |
| 2021-10-14 23:12:01 +0000 | <hippoid> | so what part of that expression is the "effectful computation"? |
| 2021-10-14 23:12:01 +0000 | <ph88> | hippoid, i also don't know but i have the idea that if you have a function a -> b it's just a function. And then when you box it (Just (a -> b)) it suddenly becomes a "computation" which needs to be unwrapped first |
| 2021-10-14 23:12:26 +0000 | <hpc> | the "effect" here is that you're doing all of the combinations and not just one specific addition |
| 2021-10-14 23:12:35 +0000 | <hpc> | in IO, the effect might be that the numbers come from stdin |
| 2021-10-14 23:12:44 +0000 | <hpc> | in Maybe, you might not have one of the numbers |
| 2021-10-14 23:13:04 +0000 | <hpc> | but underneath that you still have addition, or whatever other thing you want to do |
| 2021-10-14 23:13:19 +0000 | <ph88> | hpc, ye on value level there are 3 input parameters x, y, and z and on type level i just see two input type f (a -> b) and f a |
| 2021-10-14 23:13:28 +0000 | <dminuoso> | hippoid: The crucial part is that "effectful computation" is not something that will help you understand what we mean. |
| 2021-10-14 23:13:41 +0000 | <hippoid> | hpc: ok i think that makes sense. Typeclassopedia also talks about Applicative allowing a context for a computation, so the context could be Maybe or [] or Either ... |
| 2021-10-14 23:13:44 +0000 | <dminuoso> | hippoid: By that I mean, it's a notion that people usually adapt *after* they've grokked it. |
| 2021-10-14 23:13:57 +0000 | <hpc> | ph88: it only looks that way, some value of 'f' might be able to help you out there |
| 2021-10-14 23:14:09 +0000 | <hpc> | like how this use of id has more parameters than it should |
| 2021-10-14 23:14:12 +0000 | <hpc> | > id (+) 1 2 |
| 2021-10-14 23:14:14 +0000 | <lambdabot> | 3 |
| 2021-10-14 23:14:22 +0000 | <hippoid> | I'm grokking the Effect word is used somewhat differently than the meaning in "side effect" |
| 2021-10-14 23:14:48 +0000 | <c_wraith> | it's the same meaning in most senses, but crucially no longer on the side. |
| 2021-10-14 23:15:12 +0000 | <hippoid> | c_wraith: thats a good clarification |
| 2021-10-14 23:15:13 +0000 | <dminuoso> | hippoid: So the thing is, we usually mean it in a very lose, most general, notion. |
| 2021-10-14 23:15:29 +0000 | <ph88> | dminuoso, well interesting, been programming for a while and also didnt know what this term was supposed to mean |
| 2021-10-14 23:15:42 +0000 | <Axman6> | :t \x y z -> (x z) (y z) |
| 2021-10-14 23:15:42 +0000 | <hpc> | hippoid: it might help to look at it straight from the laws too, with no intuition |
| 2021-10-14 23:15:43 +0000 | <lambdabot> | (t1 -> t2 -> t3) -> (t1 -> t2) -> t1 -> t3 |
| 2021-10-14 23:15:47 +0000 | <hpc> | and let the two ideas meet in the middle |
| 2021-10-14 23:15:50 +0000 | <dminuoso> | The effect of [] is that of non-determinism, the effect of Maybe is anonymous exceptions |
| 2021-10-14 23:16:01 +0000 | <dminuoso> | With Cont its.. uh. I dont even know how to describe that one |
| 2021-10-14 23:16:06 +0000 | <Axman6> | :t (<*>) `asTypeOf` \x y z -> (x z) (y z) |
| 2021-10-14 23:16:07 +0000 | <lambdabot> | (t1 -> t2 -> t3) -> (t1 -> t2) -> t1 -> t3 |
| 2021-10-14 23:16:13 +0000 | _bo | (~bo@217.18.216.247) (Quit: Leaving) |
| 2021-10-14 23:16:20 +0000 | <hpc> | there's a lot of ways that the idea of "side effects" can fail to fit with Applicative |
| 2021-10-14 23:16:43 +0000 | <dminuoso> | Personally I think "effects" is a red herring when it comes to Applicative. |
| 2021-10-14 23:16:46 +0000 | <ph88> | hpc, so you are saying the parameters are a, b, a of f (a -> b) -> f a ? |
| 2021-10-14 23:17:23 +0000 | <hpc> | not quite |
| 2021-10-14 23:17:43 +0000 | <hpc> | try taking the type Axman6 gave and making it fit the type of (<*>) |
| 2021-10-14 23:17:59 +0000 | <hpc> | or in unification speak, solve the equation (t1 -> t2 -> t3) -> (t1 -> t2) -> t1 -> t3 = f (a -> b) -> f a -> f b |
| 2021-10-14 23:18:21 +0000 | <ph88> | that's useful Axman6 thanks ! |
| 2021-10-14 23:18:42 +0000 | <hippoid> | ok, i'm going to be satisfied with my current vague understandindg of that term and move on to more code |
| 2021-10-14 23:18:49 +0000 | <ph88> | hpc, i can see that t1 is analogous with f .. that explain all for me |
| 2021-10-14 23:18:58 +0000 | <hpc> | almost |
| 2021-10-14 23:19:01 +0000 | <dminuoso> | hippoid: Indeed. The intution will come on its own when you discover and work with more instances. |
| 2021-10-14 23:19:02 +0000 | <Axman6> | the type (t1 -> t2 -> t3) -> (t1 -> t2) -> t1 -> t3 can be written as: ((->) t1 (t2 -> t3) -> ((->) t1 t2) -> ((->) t1 t3) or even (((->) t1) (t2 -> t3) -> (((->) t1) t2) -> (((->) t1) t3) |
| 2021-10-14 23:19:06 +0000 | <hpc> | you're forgetting the (->) |
| 2021-10-14 23:19:15 +0000 | <ph88> | hpc, what about the -> ? |
| 2021-10-14 23:19:26 +0000 | <Axman6> | ph88: it's not t1, t1 has the wrong kind, you need something of type * -> * (or Type -> Type) |
| 2021-10-14 23:19:27 +0000 | <hpc> | well, f :: Type -> Type |
| 2021-10-14 23:19:34 +0000 | <markusde> | IMO Applicatives are the sacaffolding for effects, a monad is a way to combine effects. Like, in the Maybe applicative you can have computations that short circuit to Nothing, and you can combine expreession you know won't, but combining a -> Maybe a expressions needs a monad |
| 2021-10-14 23:19:34 +0000 | <hpc> | and t1 :: Type |
| 2021-10-14 23:19:44 +0000 | <Axman6> | :kind (->) |
| 2021-10-14 23:19:45 +0000 | <hpc> | (to jump up to the kind level for a moment) |
| 2021-10-14 23:19:56 +0000 | <Axman6> | % :kind (->) |
| 2021-10-14 23:19:56 +0000 | <yahb> | Axman6: * -> * -> * |
| 2021-10-14 23:20:00 +0000 | <Axman6> | % :kind (->) Int |
| 2021-10-14 23:20:00 +0000 | <yahb> | Axman6: * -> * |
| 2021-10-14 23:20:04 +0000 | <c_wraith> | try @kind to get lambdabot's attention |
| 2021-10-14 23:20:05 +0000 | <Axman6> | % :kind (->) Int Bool |
| 2021-10-14 23:20:05 +0000 | <yahb> | Axman6: * |
| 2021-10-14 23:20:14 +0000 | <dminuoso> | My personal interpretation is that Monads are inherently about sequencing things, and Applicatives are about branching and joining (in a diamond shape) |
| 2021-10-14 23:20:32 +0000 | <ph88> | hippoid, it's not so vague as you think. When you normally have a pure function doing 1 + 1 or whatever. Now if you have a box like Maybe you can also choose between Just x or Nothing .. that would be "the effect" of the Maybe. that's it really (afaik). So you have computation (1 + 1) put in box Just (1 + 1) and now you have a effectful computation |
| 2021-10-14 23:20:46 +0000 | <Axman6> | ph88: so, in the case of the function applicative, f ~ ((->) a) |
| 2021-10-14 23:20:48 +0000 | <dminuoso> | There's some ways in which this makes sense, but it's really just an analogy you end up when you have established a particular perspective. It's particularly terrible to explain any of this. |
| 2021-10-14 23:20:59 +0000 | <markusde> | dminuoso: I don't think that's incorrect, but it's incomplete. The sequencing operator (>>) doesn't imply bind |
| 2021-10-14 23:21:31 +0000 | <dminuoso> | markusde: In what way do you feel it to be incomplete? |
| 2021-10-14 23:21:56 +0000 | <Axman6> | hippoid: it's definitely fair to think that our use of "effect" is very general, because it definitely is general. What effect does Identity have? Well none. And what about Proxy? Even less than none! >_> |
| 2021-10-14 23:22:11 +0000 | <hpc> | haha, "less than none" |
| 2021-10-14 23:22:23 +0000 | <dminuoso> | And [] doesnt *really* model non-determinism, because there's still an ordering going on |
| 2021-10-14 23:22:24 +0000 | <Axman6> | =) |
| 2021-10-14 23:22:28 +0000 | <dminuoso> | But Logic does |
| 2021-10-14 23:22:31 +0000 | <ph88> | dminuoso, can you elaborate on branching and joining ? |
| 2021-10-14 23:22:38 +0000 | <markusde> | <dminuoso>: Bind does sequence, but sequence doesn't do bind! You need a way to combine effects and values. |
| 2021-10-14 23:23:09 +0000 | <Axman6> | hpc: in a sense, if the compiler is smart enough, then using the Proxy applicative will compile to doing nothing at all, which I think is fair to call doing less than no work at runtime :P |
| 2021-10-14 23:23:14 +0000 | <dminuoso> | markusde: and sequence is about traversable, your point? |
| 2021-10-14 23:23:17 +0000 | <ph88> | Axman6, should i be able to fill in ((->) a) for t1 and figure it out ? |
| 2021-10-14 23:23:50 +0000 | <Axman6> | ph88: no, you should be able to fil in f ~ ((->) a) (<*>)'s type |
| 2021-10-14 23:23:50 +0000 | <hpc> | for f, not t1 |
| 2021-10-14 23:23:53 +0000 | <Axman6> | :t (<*>) |
| 2021-10-14 23:23:54 +0000 | <lambdabot> | Applicative f => f (a -> b) -> f a -> f b |
| 2021-10-14 23:23:54 +0000 | <markusde> | dminuoso: That's my bad. When I said sequence I meant (>>). |
| 2021-10-14 23:24:09 +0000 | <dminuoso> | % :t (<@>) -- ph88 |
| 2021-10-14 23:24:09 +0000 | <yahb> | dminuoso: ComonadApply w => w (a -> b) -> w a -> w b |
| 2021-10-14 23:24:11 +0000 | <dminuoso> | % :t ident -- ph88 |
| 2021-10-14 23:24:12 +0000 | <yahb> | dminuoso: Applicative f => f () |
| 2021-10-14 23:24:15 +0000 | <Axman6> | % :t (<*>) @((->) Int) |
| 2021-10-14 23:24:16 +0000 | <yahb> | Axman6: (Int -> (a -> b)) -> (Int -> a) -> Int -> b |
| 2021-10-14 23:24:17 +0000 | <dminuoso> | Uh wait. |
| 2021-10-14 23:24:20 +0000 | <dminuoso> | Someone reset yahb |
| 2021-10-14 23:24:44 +0000 | <dminuoso> | % :t (<@>) -- ph88 |
| 2021-10-14 23:24:44 +0000 | <yahb> | dminuoso: Applicative f => f a -> f b -> f (a, b) |
| 2021-10-14 23:24:46 +0000 | <dminuoso> | % :t ident -- ph88 |
| 2021-10-14 23:24:46 +0000 | <yahb> | dminuoso: Applicative f => f () |
| 2021-10-14 23:25:07 +0000 | <c_wraith> | Why must I constantly stumble over the line between clean and obfuscated? |
| 2021-10-14 23:25:08 +0000 | <dminuoso> | ph88: We can think of these two things as fully descriptive of Applicative, as an alternative to <*> and pure |
| 2021-10-14 23:25:43 +0000 | <dminuoso> | (Side note: In some edge cases of infinite structures it doesnt hold true, but lets gloss over this) |
| 2021-10-14 23:26:08 +0000 | <dminuoso> | ph88: Compare that with |
| 2021-10-14 23:26:11 +0000 | <dminuoso> | % :t (>>=) |
| 2021-10-14 23:26:11 +0000 | <yahb> | dminuoso: Monad m => m a -> (a -> m b) -> m b |
| 2021-10-14 23:26:35 +0000 | <dminuoso> | ph88: See how (>>=) has a sort of sequencing baked in? We can observe this even better if we adopt this notion: |
| 2021-10-14 23:26:48 +0000 | <dminuoso> | join :: f :*: f ~> f |
| 2021-10-14 23:27:00 +0000 | <dminuoso> | And think about associativity |
| 2021-10-14 23:27:00 +0000 | <hpc> | c_wraith: go full php filthy |
| 2021-10-14 23:27:08 +0000 | <hpc> | instance Num String, (<>) = getLine, the works |
| 2021-10-14 23:27:13 +0000 | yin | (~z@user/zero) () |
| 2021-10-14 23:27:27 +0000 | <ph88> | Axman6, is (Int -> (a -> b)) -> (Int -> a) -> Int -> b supposed to look like S=λxyz.(xz)(yz) or what are you saying ? |
| 2021-10-14 23:27:34 +0000 | <dminuoso> | ph88: With the <@> description, you can see there's no dependencies. Conceptually we can think these two arguments as branches that come back together. |
| 2021-10-14 23:27:39 +0000 | <dminuoso> | Like a diamond |
| 2021-10-14 23:28:13 +0000 | <c_wraith> | hpc: that's... a different case. I'm talking like line 12 in https://paste.tomsmeding.com/1IQ276S4 |
| 2021-10-14 23:28:25 +0000 | <dminuoso> | ph88: There's a pretty deep rabbit hole in which we can generalize applicative to running two separate/incompatible effects. |
| 2021-10-14 23:28:46 +0000 | raehik | (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) (Ping timeout: 252 seconds) |
| 2021-10-14 23:28:48 +0000 | <Axman6> | ph88: it is exactly the type of that, assuming z has type Int |
| 2021-10-14 23:29:06 +0000 | <hpc> | oh yikes |
| 2021-10-14 23:29:38 +0000 | <monochrom> | c_wraith: I don't think it's obfuscated/ing |
| 2021-10-14 23:29:39 +0000 | <ph88> | dminuoso, i've never seen <@> and ident before |
| 2021-10-14 23:29:42 +0000 | <dminuoso> | ph88: Interesting side note, with the <@> and ident description, you end up with pretty cool and readable applicative laws, like `ident` being an identity with respect to <@> (up to an isomorphism) |
| 2021-10-14 23:30:00 +0000 | <c_wraith> | monochrom: I dunno, I get nervous when I see an uncurry |
| 2021-10-14 23:30:15 +0000 | <c_wraith> | It almost hurt to write it! |
| 2021-10-14 23:30:19 +0000 | <hpc> | there's probably a way to not have "maybe" there |
| 2021-10-14 23:30:29 +0000 | <c_wraith> | sure, pattern match. :P |
| 2021-10-14 23:30:39 +0000 | <hpc> | i was thinking do-notation |
| 2021-10-14 23:30:43 +0000 | <monochrom> | Then perhaps (\(x,y) -> PQ.insert x y) |
| 2021-10-14 23:30:52 +0000 | <hpc> | just shamelessly make it a few extra lines long |
| 2021-10-14 23:31:57 +0000 | <hpc> | give catMaybes . map uncons a name |
| 2021-10-14 23:32:18 +0000 | <c_wraith> | that line is a local minima for difficulty parsing it mentally. It just moves that difficulty into the semantic space. |
| 2021-10-14 23:32:35 +0000 | <ph88> | Axman6, ah ye i see it now. Still have to understand how the lambda expression represents the more general s combinator and <*> only for the instance of ((->) a) ... ill look at the equations for a bit |
| 2021-10-14 23:33:02 +0000 | <monochrom> | You know, go looks like an unfoldr, if you want obfuscating :) |
| 2021-10-14 23:33:33 +0000 | <dminuoso> | ph88: If you ever heard this "a monad is just a monoid..." joke, there's a cute interesting bit too. Applicative are monoids too (in the very same sense of that joke!), and you can in fact see this monoidal shape come into existence with this representatoin |
| 2021-10-14 23:33:47 +0000 | notzmv | (~zmv@user/notzmv) |
| 2021-10-14 23:33:58 +0000 | <c_wraith> | monochrom: I think it's more of an unfoldr |
| 2021-10-14 23:34:09 +0000 | <dminuoso> | Say: f <@> (g <@> h) ~~~ (f <@> h) <@> h |
| 2021-10-14 23:34:22 +0000 | <dminuoso> | Or `f <@> ident ~~~ f` and `ident <@> f ~~~ f` |
| 2021-10-14 23:34:40 +0000 | wroathe | (~wroathe@c-68-54-25-135.hsd1.mn.comcast.net) |
| 2021-10-14 23:34:41 +0000 | wroathe | (~wroathe@c-68-54-25-135.hsd1.mn.comcast.net) (Changing host) |
| 2021-10-14 23:34:41 +0000 | wroathe | (~wroathe@user/wroathe) |
| 2021-10-14 23:34:44 +0000 | <hpc> | you can also see a monoidal structure in Alternative - that one stands out quite a bit imo |
| 2021-10-14 23:34:56 +0000 | <dminuoso> | Monoids are everywhere. |
| 2021-10-14 23:35:20 +0000 | <hpc> | it's like the CS version of linearity |
| 2021-10-14 23:35:23 +0000 | <hpc> | when you have it, everything is easy |
| 2021-10-14 23:35:27 +0000 | <c_wraith> | it works over a seed value, updating it and emitting an element one update at a time. definitely an unfoldr. But that's not pleasant to write! |
| 2021-10-14 23:36:25 +0000 | <ph88> | dminuoso, so you can split and combine ? or how to get to diamond shape ? |
| 2021-10-14 23:36:41 +0000 | <dminuoso> | ph88: Imagine branching like haxl |
| 2021-10-14 23:36:50 +0000 | <dminuoso> | or perhaps optparse-applicative in a non-deterministic sense |
| 2021-10-14 23:37:16 +0000 | <monochrom> | (++) is at the same time <> and <|> |
| 2021-10-14 23:37:44 +0000 | <monochrom> | This should give you a whole ton of confusions until you sort it out, and then it's a whole ton of mathematical beauty. |
| 2021-10-14 23:37:56 +0000 | <dminuoso> | ph88: `f <@> g` in haxl would simply run two things in parallel and wait on the result of both. |
| 2021-10-14 23:39:47 +0000 | <dminuoso> | The only reason we never think of Applicative as perhaps generalizing "running in parallel" has to do with two facts. For one, most applicative instances also have a monad instance, and the other - this is related to the other - once you have a monad instance (which is semantically all about sequencing), there's this unwritten law demanding coherence between applicative and monad. |
| 2021-10-14 23:40:06 +0000 | wroathe | (~wroathe@user/wroathe) (Ping timeout: 265 seconds) |
| 2021-10-14 23:41:42 +0000 | <dminuoso> | So as soon as there's a monad instance, the very same applicative instance would have the monadic sequencing via a trivial instance (being defined in terms of monad) |
| 2021-10-14 23:41:53 +0000 | <dminuoso> | Making applicative mostly blant. |
| 2021-10-14 23:42:38 +0000 | <dminuoso> | So more of then than not <$> is just a monadic interface, there's strangely very few things that are Applicative (or Selective, even) but not Monadic. |
| 2021-10-14 23:45:38 +0000 | acidjnk_new3 | (~acidjnk@p200300d0c703cb999d5eb9ee05a422b5.dip0.t-ipconnect.de) |
| 2021-10-14 23:46:02 +0000 | <markusde> | Hey I have a question about a monad transformer (?) I'm not sure exists |
| 2021-10-14 23:46:16 +0000 | <markusde> | I |
| 2021-10-14 23:46:48 +0000 | <markusde> | 'm looking to promote a Maybe monad into a list, so Nothing -> [] and Just x -> [x] |
| 2021-10-14 23:47:16 +0000 | <markusde> | Is this a monad transformer thing? or is it some other structure |
| 2021-10-14 23:47:29 +0000 | <dminuoso> | markusde: This is not a monad transformer |
| 2021-10-14 23:47:46 +0000 | <dminuoso> | The technical term is called "natural transformation", and its a thing |
| 2021-10-14 23:48:06 +0000 | <dminuoso> | % import Data.Maybe |
| 2021-10-14 23:48:06 +0000 | <yahb> | dminuoso: |
| 2021-10-14 23:48:08 +0000 | <dminuoso> | % :t maybeToList |
| 2021-10-14 23:48:08 +0000 | <yahb> | dminuoso: Maybe a -> [a] |
| 2021-10-14 23:48:12 +0000 | <dminuoso> | % :t listToMaybe |
| 2021-10-14 23:48:12 +0000 | <yahb> | dminuoso: [a] -> Maybe a |
| 2021-10-14 23:49:10 +0000 | <monochrom> | But natural transformation is very broad. |
| 2021-10-14 23:49:16 +0000 | acidjnk_new | (~acidjnk@p200300d0c703cb2624cf652eb5c49df1.dip0.t-ipconnect.de) (Ping timeout: 268 seconds) |
| 2021-10-14 23:49:37 +0000 | <markusde> | dminuoso: I see! In CT Natrual transformations map functors to functors, right? |
| 2021-10-14 23:49:45 +0000 | <markusde> | I'm a little rusty |
| 2021-10-14 23:50:00 +0000 | <dminuoso> | Yes. |
| 2021-10-14 23:52:19 +0000 | <c_wraith> | monochrom: thanks, unfoldr made it both cleaner to look at and harder to understand! https://paste.tomsmeding.com/8u8NaXTp |
| 2021-10-14 23:52:35 +0000 | <markusde> | dminuoso: ty! |
| 2021-10-14 23:52:43 +0000 | <c_wraith> | and it's not using ViewPatterns anymore, so a double-win! |
| 2021-10-14 23:53:07 +0000 | <monochrom> | bwahahahaha |
| 2021-10-14 23:53:34 +0000 | Cale | (~cale@cpef48e38ee8583-cm0c473de9d680.cpe.net.cable.rogers.com) (Ping timeout: 252 seconds) |
| 2021-10-14 23:54:05 +0000 | <monochrom> | markusde: I think "monad morphism" is more specific. |
| 2021-10-14 23:54:18 +0000 | <monochrom> | https://hackage.haskell.org/package/mmorph-1.2.0/docs/Control-Monad-Morph.html may help |
| 2021-10-14 23:56:07 +0000 | zaquest | (~notzaques@5.128.210.178) (Remote host closed the connection) |
| 2021-10-14 23:57:05 +0000 | yin | (~z@user/zero) |
| 2021-10-14 23:57:08 +0000 | <yin> | hello |
| 2021-10-14 23:57:33 +0000 | <geekosaur> | hi |
| 2021-10-14 23:57:48 +0000 | <yin> | i'm trying to understand continuations |
| 2021-10-14 23:57:57 +0000 | zaquest | (~notzaques@5.128.210.178) |
| 2021-10-14 23:57:58 +0000 | <yin> | the Continuation Monad |
| 2021-10-14 23:57:58 +0000 | acidjnk_new3 | (~acidjnk@p200300d0c703cb999d5eb9ee05a422b5.dip0.t-ipconnect.de) (Ping timeout: 252 seconds) |
| 2021-10-14 23:58:24 +0000 | <monochrom> | My http://www.vex.net/~trebla/haskell/cont.xhtml may help. |
| 2021-10-14 23:58:25 +0000 | werneta | (~werneta@70-142-214-115.lightspeed.irvnca.sbcglobal.net) |
| 2021-10-14 23:58:46 +0000 | <yin> | i've started reading 3 different sources with 3 different approaches and i'm getting "Monad tutorial" flashbacks |
| 2021-10-14 23:59:09 +0000 | <yin> | thanks! let's give it a try |
| 2021-10-14 23:59:36 +0000 | <c_wraith> | It occurs to me... |
| 2021-10-14 23:59:42 +0000 | <markusde> | monochrom:that looks like it too. lots to read today ty! |
| 2021-10-14 23:59:48 +0000 | <monochrom> | I don't do analogies or intuitions. I do testable theories. |