| 2023-11-06 00:01:11 +0100 | [_] | (~itchyjunk@user/itchyjunk/x-7353470) (Ping timeout: 260 seconds) |
| 2023-11-06 00:03:23 +0100 | <EvanR> | ok Applicative has no way of doing that, I guess |
| 2023-11-06 00:04:08 +0100 | gmg | (~user@user/gehmehgeh) (Quit: Leaving) |
| 2023-11-06 00:04:39 +0100 | ciiur^^ | (~cd@70-88-177-118-Atlanta.hfc.comcastbusiness.net) (Remote host closed the connection) |
| 2023-11-06 00:07:56 +0100 | <EvanR> | if Coyoneda is a free functor factory, is Yoneda a forgetful functor factory? |
| 2023-11-06 00:12:42 +0100 | <ncf> | nah |
| 2023-11-06 00:16:03 +0100 | acidjnk | (~acidjnk@p200300d6e72b93365d0d304e1b7de813.dip0.t-ipconnect.de) (Ping timeout: 258 seconds) |
| 2023-11-06 00:16:43 +0100 | zetef | (~quassel@5.2.182.98) (Ping timeout: 264 seconds) |
| 2023-11-06 00:18:06 +0100 | pixelmonk | (~pixelmonk@50.205.76.66) (Ping timeout: 260 seconds) |
| 2023-11-06 00:18:56 +0100 | target_i | (~target_i@217.175.14.39) (Quit: leaving) |
| 2023-11-06 00:19:25 +0100 | <dolio> | Yoneda is the cofree functor. |
| 2023-11-06 00:21:17 +0100 | zetef | (~quassel@5.2.182.98) |
| 2023-11-06 00:21:19 +0100 | <dolio> | You can put anything in Coyoneda, but need it to be a functor to get it out. You can get anything out of Yoneda, but need it to be a functor to put it in. |
| 2023-11-06 00:24:55 +0100 | <ncf> | Yoneda would be the right adjoint to my forgetful functor, i think |
| 2023-11-06 00:25:02 +0100 | <dolio> | Right. |
| 2023-11-06 00:25:03 +0100 | notzmv | (~zmv@user/notzmv) |
| 2023-11-06 00:25:54 +0100 | zetef | (~quassel@5.2.182.98) (Remote host closed the connection) |
| 2023-11-06 00:25:55 +0100 | <EvanR> | I see they "got out" in the blog post by hoisting from the non-functor to a functor (the implementation monad transformer) |
| 2023-11-06 00:26:21 +0100 | zetef | (~quassel@5.2.182.98) |
| 2023-11-06 00:26:39 +0100 | zetef | (~quassel@5.2.182.98) (Read error: Connection reset by peer) |
| 2023-11-06 00:27:07 +0100 | zetef | (~quassel@5.2.182.98) |
| 2023-11-06 00:27:26 +0100 | zetef | (~quassel@5.2.182.98) (Remote host closed the connection) |
| 2023-11-06 00:27:32 +0100 | <ncf> | i'm actually confused about something now: if you put a functor through Coyoneda you're supposed to get the same functor you put in, i.e. Coyoneda (U F) ≅ F. but that would imply that functors are a full subcategory of object-mappings-and-natural-transformations, which they aren't since morphism mappings aren't unique |
| 2023-11-06 00:27:54 +0100 | zetef | (~quassel@5.2.182.98) |
| 2023-11-06 00:27:57 +0100 | zetef | (~quassel@5.2.182.98) (Read error: Connection reset by peer) |
| 2023-11-06 00:28:23 +0100 | <ncf> | a reflective subcategory even |
| 2023-11-06 00:29:26 +0100 | califax | (~califax@user/califx) (Remote host closed the connection) |
| 2023-11-06 00:29:45 +0100 | califax | (~califax@user/califx) |
| 2023-11-06 00:30:01 +0100 | <dolio> | I don't know if that's actually the right forgetful functor. |
| 2023-11-06 00:30:35 +0100 | <ncf> | i should ask agda what it thinks |
| 2023-11-06 00:31:39 +0100 | pixelmonk | (~pixelmonk@50.205.76.66) |
| 2023-11-06 00:31:59 +0100 | Square2 | (~Square4@user/square) |
| 2023-11-06 00:37:09 +0100 | <ncf> | what am i even doing |
| 2023-11-06 00:37:23 +0100 | <ncf> | Coyoneda is defined as a coend, so you can't apply it to something that's not in functor |
| 2023-11-06 00:37:40 +0100 | <ncf> | you can only do that in haskell because the coend condition is not enforced |
| 2023-11-06 00:37:55 +0100 | <ncf> | s/in/a/ |
| 2023-11-06 00:38:23 +0100 | Inst | (~Inst@120.244.192.250) (Read error: Connection reset by peer) |
| 2023-11-06 00:39:50 +0100 | xff0x | (~xff0x@2405:6580:b080:900:6924:f1c7:f24d:2a0e) (Ping timeout: 255 seconds) |
| 2023-11-06 00:40:43 +0100 | <ncf> | i think really what's going on is that every * → * in haskell is a functor even if you don't declare a Functor instance for it, because parametricity |
| 2023-11-06 00:40:50 +0100 | xff0x | (~xff0x@2405:6580:b080:900:9f61:b997:2a7f:e8b4) |
| 2023-11-06 00:40:55 +0100 | <dolio> | No. |
| 2023-11-06 00:41:05 +0100 | <ncf> | er |
| 2023-11-06 00:41:12 +0100 | <ncf> | assuming the right variance |
| 2023-11-06 00:41:19 +0100 | <dolio> | Okay, so, no. |
| 2023-11-06 00:44:43 +0100 | Inst | (~Inst@120.244.192.250) |
| 2023-11-06 00:45:42 +0100 | <EvanR> | every * -> * is a functor in the category hask restricted to having only identity morphisms? |
| 2023-11-06 00:45:59 +0100 | <EvanR> | am I doing category theory right? xD |
| 2023-11-06 00:46:02 +0100 | <dolio> | Certainly that, at least. |
| 2023-11-06 00:49:18 +0100 | L29Ah | (~L29Ah@wikipedia/L29Ah) () |
| 2023-11-06 00:50:39 +0100 | <ncf> | on Core(Hask), even |
| 2023-11-06 00:50:59 +0100 | <ncf> | ok but at least Functor is a property because of parametricity, so that solves the uniqueness mystery |
| 2023-11-06 00:51:51 +0100 | L29Ah | (~L29Ah@wikipedia/L29Ah) |
| 2023-11-06 00:55:21 +0100 | <monochrom> | My favourite "newtype D a = D (D a -> a)" is not going to be a functor. >:) |
| 2023-11-06 00:55:47 +0100 | <monochrom> | In fact, it's so contravariant to the extreme, it recovers fix. |
| 2023-11-06 00:56:40 +0100 | Square2 | (~Square4@user/square) (Quit: Leaving) |
| 2023-11-06 00:59:13 +0100 | CO2 | (CO2@gateway/vpn/protonvpn/co2) (Quit: WeeChat 4.1.1) |
| 2023-11-06 00:59:34 +0100 | <EvanR> | hold my beer |
| 2023-11-06 01:03:20 +0100 | <monochrom> | :) |
| 2023-11-06 01:05:37 +0100 | <EvanR> | fmap f (D h) = D g where g db = f (h (D h)) ? |
| 2023-11-06 01:07:04 +0100 | Ram-Z | (~Ram-Z@li1814-254.members.linode.com) (Ping timeout: 255 seconds) |
| 2023-11-06 01:08:12 +0100 | <ncf> | wee woo this is the functor police |
| 2023-11-06 01:08:53 +0100 | <ncf> | may i see your `id` |
| 2023-11-06 01:08:55 +0100 | <EvanR> | fmap id (D h) = not obviously D h |
| 2023-11-06 01:09:37 +0100 | <geekosaur> | pity lambdabot can't reasonably do multiline quotes 😛 |
| 2023-11-06 01:09:53 +0100 | <EvanR> | db isn't used so the chances of this working are low |
| 2023-11-06 01:09:54 +0100 | <Inst> | how do you even make a value of type D a = D (D a -> a)? |
| 2023-11-06 01:10:06 +0100 | <Axman6> | by being very careful |
| 2023-11-06 01:10:25 +0100 | <EvanR> | D (\_ -> 'c') is cromulent |
| 2023-11-06 01:13:40 +0100 | chiselfuse | (~chiselfus@user/chiselfuse) (Ping timeout: 256 seconds) |
| 2023-11-06 01:13:48 +0100 | <EvanR> | D (\(D h) -> h (\_ -> 'c')) |
| 2023-11-06 01:14:04 +0100 | <EvanR> | blaw |
| 2023-11-06 01:14:14 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Ping timeout: 256 seconds) |
| 2023-11-06 01:14:22 +0100 | <EvanR> | don't reinvent the wheel |
| 2023-11-06 01:15:50 +0100 | <Inst> | is there a non const function that can be embedded into D a? |
| 2023-11-06 01:15:56 +0100 | chiselfuse | (~chiselfus@user/chiselfuse) |
| 2023-11-06 01:17:01 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) |
| 2023-11-06 01:18:41 +0100 | <EvanR> | D (\(D h) -> h (D (\_ -> 'c'))), not a const |
| 2023-11-06 01:19:38 +0100 | ec | (~ec@gateway/tor-sasl/ec) |
| 2023-11-06 01:19:43 +0100 | misterfish | (~misterfis@84-53-85-146.bbserv.nl) (Ping timeout: 264 seconds) |
| 2023-11-06 01:20:03 +0100 | Ram-Z | (Ram-Z@2a01:7e01::f03c:91ff:fe57:d2df) |
| 2023-11-06 01:20:40 +0100 | <EvanR> | I think the game theory thing would come in handy here |
| 2023-11-06 01:23:34 +0100 | idgaen | (~idgaen@2a01:e0a:498:fd50:fcc6:bb5d:489a:ce8c) (Quit: WeeChat 4.1.1) |
| 2023-11-06 01:30:37 +0100 | lg188 | (~lg188@82.18.98.230) (Ping timeout: 255 seconds) |
| 2023-11-06 01:30:48 +0100 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:1052:6194:3db5:da7a) (Remote host closed the connection) |
| 2023-11-06 01:30:49 +0100 | <monochrom> | Example value: D (\d@(D f) -> f d). Recall: \x -> x x |
| 2023-11-06 01:32:23 +0100 | <monochrom> | In fact, recall what error you get if you ask Haskell about \x -> x x. |
| 2023-11-06 01:32:25 +0100 | Ekho | (~Ekho@user/ekho) (Quit: CORE ERROR, SYSTEM HALTED.) |
| 2023-11-06 01:32:27 +0100 | <monochrom> | @type \x -> x x |
| 2023-11-06 01:32:28 +0100 | <lambdabot> | error: |
| 2023-11-06 01:32:28 +0100 | <lambdabot> | • Occurs check: cannot construct the infinite type: t ~ t -> t1 |
| 2023-11-06 01:32:28 +0100 | <lambdabot> | • In the first argument of ‘x’, namely ‘x’ |
| 2023-11-06 01:33:25 +0100 | <monochrom> | So just use a newtype to define T ~ T -> t1. Now just parametrize by t1: s/T/D t1/ |
| 2023-11-06 01:33:48 +0100 | tabemann | (~tabemann@172-13-49-137.lightspeed.milwwi.sbcglobal.net) (Quit: Leaving) |
| 2023-11-06 01:33:59 +0100 | <monochrom> | I put this on the exam. >:) |
| 2023-11-06 01:34:11 +0100 | <EvanR> | what's the question |
| 2023-11-06 01:34:37 +0100 | <EvanR> | the answer is intriguing |
| 2023-11-06 01:35:43 +0100 | notzmv | (~zmv@user/notzmv) (Read error: Connection reset by peer) |
| 2023-11-06 01:36:37 +0100 | <probie> | let thing = (\x -> x x) :: (forall a . (a -> a) -> (a -> a)) -> (b -> b) -> (b -> b) in thing (\f -> f . f) (*2) 5 |
| 2023-11-06 01:36:49 +0100 | <probie> | > let thing = (\x -> x x) :: (forall a . (a -> a) -> (a -> a)) -> (b -> b) -> (b -> b) in thing (\f -> f . f) (*2) 5 |
| 2023-11-06 01:36:50 +0100 | <lambdabot> | 80 |
| 2023-11-06 01:36:53 +0100 | <ncf> | you don't get that error on GHC 9, apparently :( |
| 2023-11-06 01:37:09 +0100 | <monochrom> | Infer the types of (\f -> f (D f)) and (\w -> (unD w) w). (unD (D f) = f.) |
| 2023-11-06 01:37:12 +0100 | <geekosaur> | % :t \x -> x x |
| 2023-11-06 01:37:12 +0100 | <yahb2> | <interactive>:1:9: error: ; • Couldn't match expected type ‘t’ with actual type ‘t -> t1’ ; ‘t’ is a rigid type variable bound by ; the inferred type of it :: (t -> t1) -> t1 ; ... |
| 2023-11-06 01:37:37 +0100 | <monochrom> | Yeah I miss the infinite type message. I need it for my course! |
| 2023-11-06 01:38:43 +0100 | <monochrom> | Because I teach \x -> x x as an example of untyped lambda calculus, and I teach type inference, and why it has an occurs-check. |
| 2023-11-06 01:39:33 +0100 | <EvanR> | error: you speak an infinite deal of type |
| 2023-11-06 01:40:55 +0100 | <ncf> | looks like spj removed it in https://gitlab.haskell.org/ghc/ghc/-/commit/2b792facab46f7cdd09d12e79499f4e0dcd4293f |
| 2023-11-06 01:41:13 +0100 | <ncf> | ...three years ago |
| 2023-11-06 01:42:03 +0100 | <geekosaur> | presumably because the typechecker was now smart enouhg to catch it itself instead of going into an infinite loop |
| 2023-11-06 01:43:07 +0100 | <ncf> | > One particular point: for occurs-check errors I now just say Can't match 'a' against '[a]' rather than using the intimidating language of "occurs check". |
| 2023-11-06 01:43:09 +0100 | <lambdabot> | <hint>:1:88: error: parse error on input ‘a’ |
| 2023-11-06 01:43:23 +0100 | <geekosaur> | ah |
| 2023-11-06 01:44:12 +0100 | <ncf> | cannot construct intimidating language |
| 2023-11-06 01:44:48 +0100 | <geekosaur> | most newcomers seem to find "Couldn't match" pretty intimidating… |
| 2023-11-06 01:44:51 +0100 | <EvanR> | can't match 'a' against '[a]' sounds reasonable |
| 2023-11-06 01:45:06 +0100 | <probie> | :t let x = 42 in x x |
| 2023-11-06 01:45:08 +0100 | <lambdabot> | (Num t1, Num (t1 -> t2)) => t2 |
| 2023-11-06 01:45:37 +0100 | <geekosaur> | don't make me install caleskell 😛 |
| 2023-11-06 01:45:48 +0100 | <monochrom> | Unpopular opinion: Slippery slope. :) |
| 2023-11-06 01:45:49 +0100 | <EvanR> | that intimidates me, I demand an error message instead |
| 2023-11-06 01:46:17 +0100 | <Inst> | ah, i understand, this is fix, the type, isn't it? |
| 2023-11-06 01:47:00 +0100 | <EvanR> | D is a plausible domain for interpretation untyped lambda calculus functions |
| 2023-11-06 01:47:07 +0100 | <monochrom> | There are many different kinds of fix. But yes. |
| 2023-11-06 01:47:08 +0100 | <EvanR> | of |
| 2023-11-06 01:47:12 +0100 | <geekosaur> | sort of. it's a recursive type, and without specific checks the typechecker would go into an infinite loop |
| 2023-11-06 01:47:25 +0100 | <ncf> | is it? it doesn't satisfy D ≃ (D → D) |
| 2023-11-06 01:47:40 +0100 | <EvanR> | you have to squint |
| 2023-11-06 01:47:52 +0100 | <ncf> | seems like it can interpret *some* untyped λ terms |
| 2023-11-06 01:48:05 +0100 | <geekosaur> | but indeed I wouldn't call it a fixpoint combinator, just recursion |
| 2023-11-06 01:48:34 +0100 | <Inst> | sort of makes me ask what the mathematical underpinning of the Foldable typeclass is |
| 2023-11-06 01:48:35 +0100 | notzmv | (~zmv@user/notzmv) |
| 2023-11-06 01:48:36 +0100 | Ekho | (~Ekho@user/ekho) |
| 2023-11-06 01:49:01 +0100 | Ram-Z | (Ram-Z@2a01:7e01::f03c:91ff:fe57:d2df) (Quit: ZNC - http://znc.in) |
| 2023-11-06 01:49:09 +0100 | <Inst> | since I'm currently assuming every lawful typeclass in Haskell has a mathematical underpinning (I'm sure it's easy to find counterexamples) |
| 2023-11-06 01:49:22 +0100 | Tuplanolla | (~Tuplanoll@91-159-68-236.elisa-laajakaista.fi) (Ping timeout: 255 seconds) |
| 2023-11-06 01:49:41 +0100 | <EvanR> | Inst, tree reduction strategies, there are many, but if a monoid is used the strategies all get the same answer (this is fold). foldl and foldr don't require monoid and can differ |
| 2023-11-06 01:49:44 +0100 | <monochrom> | I wonder what if you then define newtype D1 = D1 (D D1). Then D1 ≅ D1 -> D1, I think. |
| 2023-11-06 01:50:34 +0100 | <Inst> | thanks <EvanR3 |
| 2023-11-06 01:51:35 +0100 | <EvanR> | give or take encountering bottom too early |
| 2023-11-06 01:52:07 +0100 | <ncf> | Foldable boils down to toList i think, i.e. a natural transformation to [] |
| 2023-11-06 01:52:09 +0100 | <monochrom> | Unpopular opinion: What people get backwards is that they look for practical underpinnings of Functor and mathematical underpinning of Foldable. |
| 2023-11-06 01:52:22 +0100 | <EvanR> | toList is just one application of foldable |
| 2023-11-06 01:52:26 +0100 | Ram-Z | (Ram-Z@2a01:7e01::f03c:91ff:fe57:d2df) |
| 2023-11-06 01:53:28 +0100 | <Inst> | fmap is actually adroitly named, isn't it? |
| 2023-11-06 01:53:42 +0100 | <Inst> | because it's not a true "map" in the traditional programming sense, by including laws |
| 2023-11-06 01:53:54 +0100 | <EvanR> | what is a true map |
| 2023-11-06 01:53:54 +0100 | <ncf> | EvanR: but subsumes all others |
| 2023-11-06 01:54:27 +0100 | <EvanR> | ncf, because taking seriously the idea that [] is "the free monoid", ... |
| 2023-11-06 01:54:32 +0100 | <Inst> | return the object, with all its parameters having the function applied onto it |
| 2023-11-06 01:54:48 +0100 | <EvanR> | fmap does that when that description makes sense |
| 2023-11-06 01:55:12 +0100 | <Inst> | but would you say contramap is a map in a traditional programming sense? |
| 2023-11-06 01:55:56 +0100 | <monochrom> | join is "not a true flat", and >>= is "not a true concatMap". |
| 2023-11-06 01:56:19 +0100 | falafel | (~falafel@62.175.113.194.dyn.user.ono.com) (Ping timeout: 264 seconds) |
| 2023-11-06 01:56:20 +0100 | <monochrom> | But I don't care. Bart Jacobs has decided to call join "flat". That is good enough for me. |
| 2023-11-06 01:56:37 +0100 | <EvanR> | flat is based |
| 2023-11-06 01:56:46 +0100 | <monochrom> | In a recent talk, I introduce these 3 names for >>=: bind, then, flat-map. :) |
| 2023-11-06 01:56:59 +0100 | <Inst> | >> is already called then :( |
| 2023-11-06 01:57:03 +0100 | <Inst> | >> and *> |
| 2023-11-06 01:57:24 +0100 | <EvanR> | >> is already called right shift |
| 2023-11-06 01:57:57 +0100 | <EvanR> | pure is already called return |
| 2023-11-06 01:58:15 +0100 | <monochrom> | I know another community (HOL theorem prover) who would call >>= "then". |
| 2023-11-06 01:58:30 +0100 | <talismanick> | Say an API has several different available URLs, but some don't 24/7 work and I want to check which do before using that |
| 2023-11-06 01:58:34 +0100 | <talismanick> | I could mapM wreq's "get" and asum the list of responses to pick the first one, but that would wait for all of them to 403, etc before I even starting picking one |
| 2023-11-06 01:58:58 +0100 | <EvanR> | you could async race them all |
| 2023-11-06 01:58:59 +0100 | <talismanick> | How might I lazily interleave them to halt on the first working URL? |
| 2023-11-06 01:59:06 +0100 | <monochrom> | This is because they have a lot of CPSed functions, all named like "foo_then". And their "foo_then" just means our "(foo >>=)" left sections. |
| 2023-11-06 01:59:30 +0100 | <talismanick> | EvanR: oh, that's not the worst idea I guess |
| 2023-11-06 01:59:39 +0100 | <EvanR> | which will kill all remaining losers |
| 2023-11-06 02:00:32 +0100 | talismanick | looks up if async has a pertinent Alternative instance |
| 2023-11-06 02:01:24 +0100 | <monochrom> | Probably not, on the ground that there are multiple candidates racing for it. (pun!) |
| 2023-11-06 02:01:41 +0100 | <talismanick> | Oh neat, it does |
| 2023-11-06 02:01:52 +0100 | <monochrom> | :( |
| 2023-11-06 02:02:05 +0100 | <monochrom> | Someone has to lose, I guess. |
| 2023-11-06 02:02:30 +0100 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:1052:6194:3db5:da7a) |
| 2023-11-06 02:02:36 +0100 | <talismanick> | Alternative is basically Prolog-style committed choice nondeterminism, after all |
| 2023-11-06 02:02:43 +0100 | <monochrom> | Darn, my pun was not optimized. |
| 2023-11-06 02:02:57 +0100 | <monochrom> | Optimized: There are multiple alternatives racing for it. >:) |
| 2023-11-06 02:04:07 +0100 | pixelmonk | (~pixelmonk@50.205.76.66) (Ping timeout: 264 seconds) |
| 2023-11-06 02:08:41 +0100 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) (Ping timeout: 240 seconds) |
| 2023-11-06 02:08:49 +0100 | Lord_of_Life_ | (~Lord@user/lord-of-life/x-2819915) |
| 2023-11-06 02:10:10 +0100 | Lord_of_Life_ | Lord_of_Life |
| 2023-11-06 02:12:34 +0100 | <Inst> | btw, is there a way to hide reexports in a module? |
| 2023-11-06 02:15:06 +0100 | <geekosaur> | the same way you hide anything else? |
| 2023-11-06 02:15:23 +0100 | <monochrom> | Like this? module X(module Y) where import Y hiding (y) |
| 2023-11-06 02:16:42 +0100 | <geekosaur> | if you want to use y yourself but not reexport it, import it a second time qualified |
| 2023-11-06 02:17:10 +0100 | [itchyjunk] | (~itchyjunk@user/itchyjunk/x-7353470) (Remote host closed the connection) |
| 2023-11-06 02:17:20 +0100 | [_] | (~itchyjunk@user/itchyjunk/x-7353470) |
| 2023-11-06 02:19:48 +0100 | <Inst> | erm, in importing |
| 2023-11-06 02:20:06 +0100 | <Inst> | import SomeMod hiding (SomOtherMod) |
| 2023-11-06 02:20:13 +0100 | tabemann | (~tabemann@172-13-49-137.lightspeed.milwwi.sbcglobal.net) |
| 2023-11-06 02:20:18 +0100 | <Inst> | i.e, if I want to import Vector unqualified but hide everything that conflicts with Data.Foldable |
| 2023-11-06 02:20:49 +0100 | pixelmonk | (~pixelmonk@50.205.76.66) |
| 2023-11-06 02:23:13 +0100 | <monochrom> | I don't think there is syntax for that. |
| 2023-11-06 02:23:42 +0100 | <monochrom> | Instead, people import Vector qualified. (Because it even clashes with Prelude.) |
| 2023-11-06 02:24:06 +0100 | <monochrom> | (OK maybe not Prelude but Data.List etc.) |
| 2023-11-06 02:25:21 +0100 | pixelmonk | (~pixelmonk@50.205.76.66) (Ping timeout: 240 seconds) |
| 2023-11-06 02:26:54 +0100 | pixelmonk | (~pixelmonk@50.205.76.66) |
| 2023-11-06 02:27:30 +0100 | edilmedeiros | (~user@2804:14c:658b:5993:414e:c397:748f:b8af) |
| 2023-11-06 02:28:45 +0100 | <EvanR> | import qualified Data.Vector as V |
| 2023-11-06 02:29:04 +0100 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:1052:6194:3db5:da7a) (Ping timeout: 258 seconds) |
| 2023-11-06 02:30:31 +0100 | AssCrackBandit | (~user@cust-west-par-46-193-2-167.cust.wifirst.net) (Quit: leaving) |
| 2023-11-06 02:32:01 +0100 | Ram-Z | (Ram-Z@2a01:7e01::f03c:91ff:fe57:d2df) (Quit: ZNC - http://znc.in) |
| 2023-11-06 02:34:07 +0100 | Ram-Z | (Ram-Z@2a01:7e01::f03c:91ff:fe57:d2df) |
| 2023-11-06 02:34:21 +0100 | L29Ah | (~L29Ah@wikipedia/L29Ah) (Ping timeout: 240 seconds) |
| 2023-11-06 02:34:58 +0100 | nate2 | (~nate@c-98-45-169-16.hsd1.ca.comcast.net) |
| 2023-11-06 02:36:03 +0100 | L29Ah | (~L29Ah@wikipedia/L29Ah) |
| 2023-11-06 02:39:21 +0100 | nate2 | (~nate@c-98-45-169-16.hsd1.ca.comcast.net) (Ping timeout: 240 seconds) |
| 2023-11-06 02:43:05 +0100 | dolio | (~dolio@130.44.134.54) (Quit: ZNC 1.8.2 - https://znc.in) |
| 2023-11-06 02:44:31 +0100 | dolio | (~dolio@130.44.134.54) |
| 2023-11-06 02:46:02 +0100 | stiell_ | (~stiell@gateway/tor-sasl/stiell) (Ping timeout: 256 seconds) |
| 2023-11-06 02:47:13 +0100 | dolio | (~dolio@130.44.134.54) (Client Quit) |
| 2023-11-06 02:47:55 +0100 | stiell_ | (~stiell@gateway/tor-sasl/stiell) |
| 2023-11-06 02:48:45 +0100 | dolio | (~dolio@130.44.134.54) |
| 2023-11-06 03:05:42 +0100 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:1052:6194:3db5:da7a) |
| 2023-11-06 03:07:16 +0100 | <Inst> | yeah I usually import it as |
| 2023-11-06 03:07:22 +0100 | <Inst> | import Data.Vector qualified as V |
| 2023-11-06 03:07:50 +0100 | <EvanR> | fancy |
| 2023-11-06 03:07:51 +0100 | <Inst> | Haskell's import system, tbh, is the biggest wart on the language, and you'd think someone would have language-extensioned it until it worked by now |
| 2023-11-06 03:08:01 +0100 | <EvanR> | you think haskell is bad |
| 2023-11-06 03:08:10 +0100 | <Inst> | iirc Snoyman had a rant about it |
| 2023-11-06 03:08:12 +0100 | <EvanR> | let me introduce you to every other module system (except ML) |
| 2023-11-06 03:08:46 +0100 | <jackdk> | What are you talking about? The Num typeclass is a much worse wart |
| 2023-11-06 03:08:54 +0100 | <monochrom> | Does backpack count? :) |
| 2023-11-06 03:09:08 +0100 | <EvanR> | we do have our ways of coping with stockholm syndrome, like separating out the "private" stuff into an internal module that's not hidden |
| 2023-11-06 03:09:20 +0100 | <monochrom> | heh |
| 2023-11-06 03:10:27 +0100 | <Inst> | i wonder what would have happened if the original Haskell Committee |
| 2023-11-06 03:10:29 +0100 | <monochrom> | I don't actually find Haskell's module system any different from Java's or Python's. You would have to say that theirs are warts, too. |
| 2023-11-06 03:10:36 +0100 | <Inst> | hadn't decided first-class modules were too fancy |
| 2023-11-06 03:10:48 +0100 | <monochrom> | Basically yeah only *MLs' are better. |
| 2023-11-06 03:10:51 +0100 | <jackdk> | We'd probably have had first-class modules? |
| 2023-11-06 03:11:16 +0100 | <Inst> | let me go find Michael Snoyman's rant about Haskell modules |
| 2023-11-06 03:11:36 +0100 | <monochrom> | No, I am not interested in another Snoyman rant. |
| 2023-11-06 03:11:59 +0100 | <yushyin> | few care about what that person says, lol |
| 2023-11-06 03:12:10 +0100 | <Inst> | ugh, can't find it |
| 2023-11-06 03:12:28 +0100 | <Inst> | I think if you want to rebuild the Haskell import system, Using is a great quasi-keyword |
| 2023-11-06 03:12:55 +0100 | <Inst> | because using can be the name of a macro |
| 2023-11-06 03:14:09 +0100 | <Inst> | but the overall design needs work, i.e, why am I typing qualified every time, why do I have 10 lines of imports (I've seen modules with 125 lines of imports) |
| 2023-11-06 03:15:35 +0100 | anderson- | (~anderson@user/anderson) |
| 2023-11-06 03:15:49 +0100 | <monochrom> | I know it's a fallacy to argue that the other pasture is worse, but I couldn't resist. |
| 2023-11-06 03:16:12 +0100 | <monochrom> | If you have 10 imports in Haskell, then it would be 50 imports in the Java equivalent. |
| 2023-11-06 03:16:31 +0100 | <EvanR> | Inst, get original, post your own rant somewhere |
| 2023-11-06 03:16:37 +0100 | <yushyin> | there are quite a few (some now closed or obsolete) ghc-proposals to improve (or worsen) the module system, you can work your way through them and read all about their merits and problems |
| 2023-11-06 03:16:41 +0100 | <Inst> | compare Py, though, which to me, seems to have a much better import system |
| 2023-11-06 03:16:43 +0100 | <monochrom> | Because over there the "best practice" is one import line per class, where each module have 5 classes. |
| 2023-11-06 03:16:44 +0100 | <yushyin> | it's not like people didn't try |
| 2023-11-06 03:17:15 +0100 | <monochrom> | How is Python's fewer import lines? |
| 2023-11-06 03:17:27 +0100 | <monochrom> | They almost follow the Java convention. |
| 2023-11-06 03:17:30 +0100 | <Inst> | multiple imports :) |
| 2023-11-06 03:17:43 +0100 | <EvanR> | python is great, from * import * |
| 2023-11-06 03:17:48 +0100 | <EvanR> | nothing bad happens |
| 2023-11-06 03:17:58 +0100 | <monochrom> | Our "import Data.List" becomes their "import datalist.*" and over there they actually say don't do it. |
| 2023-11-06 03:18:05 +0100 | <jackdk> | I wouldn't trust python's opinion on anything to do with software packaging. |
| 2023-11-06 03:18:17 +0100 | <monochrom> | So once again if you have 10 imports in Haskell, it becomes 30 imports in Python. |
| 2023-11-06 03:18:50 +0100 | <EvanR> | the premise is of course false, you have 50 something imports in haskell |
| 2023-11-06 03:18:53 +0100 | <monochrom> | Are you living in an alternate universe? |
| 2023-11-06 03:18:55 +0100 | <EvanR> | and extensions |
| 2023-11-06 03:20:17 +0100 | <Inst> | I guess the big difference is that Haskell is functional, i.e, do things with functions most of the time |
| 2023-11-06 03:20:40 +0100 | <jackdk> | I would rather write 50 lines of imports to write 10 lines of code than write 10 lines of imports and have to write 50 lines of code |
| 2023-11-06 03:20:48 +0100 | <Inst> | so you need more imports, one, two, Haskell has a basic prelude whereas other languages have larger prelude-equivalents |
| 2023-11-06 03:21:21 +0100 | <Inst> | extensions can also be obviated via cabal files |
| 2023-11-06 03:21:22 +0100 | <monochrom> | Then use qualified imports. |
| 2023-11-06 03:21:37 +0100 | <Inst> | qualified is ugly as sin, one good suggestion from NH was qualified by default |
| 2023-11-06 03:21:44 +0100 | <monochrom> | "import Data.List qualified as L" now you write like "L.concat" just like Python. |
| 2023-11-06 03:21:52 +0100 | <monochrom> | HOW IS THAT DIFFERENT |
| 2023-11-06 03:22:16 +0100 | <EvanR> | yes V.fromList is terrible, you should do like hip languages and say Enumerable.Vector.fromList, much better |
| 2023-11-06 03:22:37 +0100 | <EvanR> | haskell people always use 1 letter for everything, are they insane |
| 2023-11-06 03:23:26 +0100 | <Clint> | sometimes i use 2 or 3 or 4 |
| 2023-11-06 03:23:40 +0100 | <Inst> | sort of, but w/e, wasn't meaning to offend, was just hoping for a brainstorm, but it's useless when I don't have GHC contrib capability, or much of Cabal contrib capability yet :( |
| 2023-11-06 03:23:42 +0100 | <EvanR> | also, if qualified is terrible, how you seen the unreasonable effectiveness of OOP notation |
| 2023-11-06 03:23:46 +0100 | <monochrom> | I use 2.71828 letters. :) |
| 2023-11-06 03:23:59 +0100 | <c_wraith> | ah, so you name everything e |
| 2023-11-06 03:23:59 +0100 | CO2 | (CO2@gateway/vpn/protonvpn/co2) |
| 2023-11-06 03:23:59 +0100 | <EvanR> | 2.71828 is qualified, stop it |
| 2023-11-06 03:24:04 +0100 | <monochrom> | haha |
| 2023-11-06 03:24:11 +0100 | otto_s | (~user@p4ff27c21.dip0.t-ipconnect.de) (Ping timeout: 260 seconds) |
| 2023-11-06 03:24:27 +0100 | <monochrom> | There is nothing to brainstorm in this case. |
| 2023-11-06 03:24:34 +0100 | <monochrom> | Learn Haskell for real. |
| 2023-11-06 03:24:39 +0100 | machinedgod | (~machinedg@d198-53-218-113.abhsia.telus.net) (Ping timeout: 258 seconds) |
| 2023-11-06 03:24:55 +0100 | <Inst> | whoa, ghci is accepting numeric names for qualified |
| 2023-11-06 03:24:56 +0100 | <monochrom> | Then show a real difference. Then there will be something to brainstorm about. |
| 2023-11-06 03:25:09 +0100 | <Inst> | actually, it's not |
| 2023-11-06 03:25:29 +0100 | otto_s | (~user@p5de2ff30.dip0.t-ipconnect.de) |
| 2023-11-06 03:26:53 +0100 | <Inst> | import Data.Time qualified vs import time, that's a real difference, no? |
| 2023-11-06 03:27:15 +0100 | <exarkun> | not really? |
| 2023-11-06 03:27:23 +0100 | <Inst> | You can actually get the Java names disaster |
| 2023-11-06 03:27:31 +0100 | <Inst> | via import an arbitrary Haskell module with qualified only |
| 2023-11-06 03:28:16 +0100 | pretty_dumm_guy | (trottel@gateway/vpn/protonvpn/prettydummguy/x-88029655) (Ping timeout: 260 seconds) |
| 2023-11-06 03:28:37 +0100 | <monochrom> | We used to call it Time, too. |
| 2023-11-06 03:29:16 +0100 | <monochrom> | We used to say "import List" and "import Monad". |
| 2023-11-06 03:29:17 +0100 | <Inst> | monochrom, I respect you a lot, and apologize for upsetting you :( |
| 2023-11-06 03:29:41 +0100 | <Inst> | as I've said, it's useless unless I'm GHC contrib capable, and tbh, my first destination would be trying to propose named lambdas |
| 2023-11-06 03:30:00 +0100 | yin | blinks |
| 2023-11-06 03:30:07 +0100 | <exarkun> | A simpler step might be to just make an actual argument for why something different would be better. |
| 2023-11-06 03:30:09 +0100 | <monochrom> | I have no opinion on "Time" vs "Data.Time". The community switched to "Data.Time" a long time ago. Consider which direction the community considered "the fix". |
| 2023-11-06 03:31:24 +0100 | <c_wraith> | was it Haskell98 that didn't allow nested module names? |
| 2023-11-06 03:31:29 +0100 | <monochrom> | Right. |
| 2023-11-06 03:31:29 +0100 | <geekosaur> | yes |
| 2023-11-06 03:31:50 +0100 | <geekosaur> | an addendum was published shortly afterward adding them, though |
| 2023-11-06 03:32:07 +0100 | <Inst> | exarkun: I mean, the reason I'm asking for a brainstorm is because it's hard to think of a better way to do it. |
| 2023-11-06 03:32:09 +0100 | <monochrom> | Adding dots was the language extension for the module system. |
| 2023-11-06 03:32:27 +0100 | <Inst> | Ah, wait, is there still an -XNo for module dots? |
| 2023-11-06 03:32:37 +0100 | <geekosaur> | nope |
| 2023-11-06 03:32:59 +0100 | <monochrom> | You turn it on and you have almost nothing to import. |
| 2023-11-06 03:33:03 +0100 | xff0x | (~xff0x@2405:6580:b080:900:9f61:b997:2a7f:e8b4) (Ping timeout: 240 seconds) |
| 2023-11-06 03:33:18 +0100 | <monochrom> | more precisely, nothing left. |
| 2023-11-06 03:33:39 +0100 | <exarkun> | Inst: I don't think you're asking for brainstorming. I think you're asking for other people to invent ideas that suit your personal taste. |
| 2023-11-06 03:33:53 +0100 | <geekosaur> | not actually true, as the pendulum seems to be swinging back in the other direction with packages appearing that use unqualified modules |
| 2023-11-06 03:33:53 +0100 | <exarkun> | Personal taste is fine, I don't fault you for having some. |
| 2023-11-06 03:33:55 +0100 | <Inst> | I think you're right about that. |
| 2023-11-06 03:34:01 +0100 | <monochrom> | module Monad no longer exists. module List no longer exists. You disallow yourself dotted notation, you can't import sh*t. |
| 2023-11-06 03:34:05 +0100 | xff0x | (~xff0x@2405:6580:b080:900:c81e:fd76:511a:4c08) |
| 2023-11-06 03:34:06 +0100 | <exarkun> | But you're probably the best positioned to come up with ideas that suit it. |
| 2023-11-06 03:34:14 +0100 | <Inst> | I was just surprised that there was so much pushback on "Haskell import system is bleh" |
| 2023-11-06 03:34:39 +0100 | <jackdk> | Respectfully, your statement was a vibes-based assertion, not an argument. |
| 2023-11-06 03:34:39 +0100 | <exarkun> | There are better module systems. Someone pointed out ml. There's also monte (much more obscure). |
| 2023-11-06 03:35:02 +0100 | <monochrom> | No. I push back against the very flawed "Python's is better". |
| 2023-11-06 03:35:12 +0100 | <exarkun> | Maybe it would be useful to brainstorm whether those module systems _could_ fit Haskell? |
| 2023-11-06 03:35:19 +0100 | <monochrom> | Python's is not better. SML's is. Come back when you advocate SML's way. |
| 2023-11-06 03:35:23 +0100 | <exarkun> | But then you're probably right - if they could, now you have a lot of work to do to make it real. |
| 2023-11-06 03:35:34 +0100 | <Inst> | Actually, there are things Python objectively does better than Haskell, no? It's designed as an easy to learn scripting language. |
| 2023-11-06 03:35:44 +0100 | <Inst> | Where it turns into a disaster is when you try to scale it beyond the minimal scale. |
| 2023-11-06 03:35:53 +0100 | <exarkun> | Inst: Now youre goal-post moving, which is a classic troll move, watch out. |
| 2023-11-06 03:36:02 +0100 | <monochrom> | I am just talking about the context: modules and imports. |
| 2023-11-06 03:36:06 +0100 | <exarkun> | Are we talking about Haskell's module system or are we talking about Python being objectively better? |
| 2023-11-06 03:36:09 +0100 | <monochrom> | Are you context-free? |
| 2023-11-06 03:36:18 +0100 | <monochrom> | Are you even merely regular? |
| 2023-11-06 03:36:37 +0100 | <exarkun> | (Also: monochrom is right, Python's module system is not better) |
| 2023-11-06 03:36:40 +0100 | <Inst> | I guess in my particular context, where I'm interested in scripting with Haskell, the verbose Haskell import syntax is a problem. |
| 2023-11-06 03:36:51 +0100 | <exarkun> | (Reference: Python programmer for 20 years and contributor to the implementation of Python's module system) |
| 2023-11-06 03:37:29 +0100 | <Inst> | exarkun: Do you mean when you try to push it to a medium-scale application, or in the simple use case it was originally designed for? |
| 2023-11-06 03:37:58 +0100 | <exarkun> | Inst: Do you have a link to the simple use case it was originally designed for? |
| 2023-11-06 03:38:14 +0100 | <jackdk> | (Remark: Python is not easy to learn; to reliably predict the behaviour of a python program, one must imagine how a busy C programmer would have implemented the runtime. (More true in the 2.x era, but still.)) |
| 2023-11-06 03:38:25 +0100 | <exarkun> | The "scripting" solution is the same in Haskell or Python. Put most of your imports into one module, import that module from your "script". |
| 2023-11-06 03:39:20 +0100 | <Inst> | Yeah, I guess I'm pretty out of my mind with cabal run on cabal scripts these days. :) |
| 2023-11-06 03:39:38 +0100 | <Inst> | jackdk: it depends on your definition of learn, no? |
| 2023-11-06 03:39:53 +0100 | <Inst> | I have an acquaintance who's getting into arguments on Python discord because of average skill levels |
| 2023-11-06 03:40:09 +0100 | <Inst> | at the same time, I tell him: "You make money because they're bad", because his profession is cleaning up Python codebases |
| 2023-11-06 03:40:37 +0100 | <geekosaur> | exarkun, actually I do, or would if the old Usenet archives were still online |
| 2023-11-06 03:41:01 +0100 | <jackdk> | Sure. My definition of "easy to learn" includes something like "it does not take long for a new programmer to make correct predictions about whether a piece of text is a valid python program, what a given python program will do, etc." |
| 2023-11-06 03:41:01 +0100 | pixelmonk | (~pixelmonk@50.205.76.66) (Ping timeout: 240 seconds) |
| 2023-11-06 03:41:06 +0100 | <exarkun> | I remember comp.lang.python, but I only caught the tail end of it I think |
| 2023-11-06 03:41:23 +0100 | <exarkun> | jackdk: probably a different definition than most python programmers use |
| 2023-11-06 03:42:04 +0100 | <Inst> | That does into Haskeller culture, I guess, where there's a concern about correct, maintainable code, whereas in other cultures (even national programming cultures) you'll see programmers who just want to hack out code and rewrite when it goes wrong |
| 2023-11-06 03:42:05 +0100 | <exarkun> | jackdk: "know enough syntax to type in characters that the compiler doesn't reject"! |
| 2023-11-06 03:42:13 +0100 | <Inst> | ^^^ |
| 2023-11-06 03:42:44 +0100 | <exarkun> | But that's a long way removed from the module system of either language. |
| 2023-11-06 03:46:26 +0100 | <jackdk> | I don't necessarily mean that formally, but I cannot fathom how you can call it "learning programming" if you don't have _some_ idea about what you want your program to achieve, and how rapidly your attempts to write that program converge on even a partial solution |
| 2023-11-06 03:46:53 +0100 | nate2 | (~nate@c-98-45-169-16.hsd1.ca.comcast.net) |
| 2023-11-06 03:47:24 +0100 | BestSteve | (~beststeve@220-135-3-239.hinet-ip.hinet.net) (Quit: WeeChat 4.1.1) |
| 2023-11-06 03:48:14 +0100 | <geekosaur> | oh, programmers have some idea of what they want their program to achieve. they just ask google or stackoverflow for the pieces they think they need and copypasta them together |
| 2023-11-06 03:48:36 +0100 | califax | (~califax@user/califx) (Remote host closed the connection) |
| 2023-11-06 03:48:50 +0100 | <jackdk> | Right, but if you don't see at least some of the gears when you look at a piece of code, how have you learned anything? |
| 2023-11-06 03:48:52 +0100 | califax | (~califax@user/califx) |
| 2023-11-06 03:49:12 +0100 | <exarkun> | Most programs are much more complex than any programmer can hold in their head at once. It's easy, especially for inexperienced programmers (but also for very experienced programmers) to fool themselves into thinking they can do it. |
| 2023-11-06 03:49:34 +0100 | <geekosaur> | "learning anything" is explicitl;y the opposite of what they want |
| 2023-11-06 03:49:37 +0100 | <exarkun> | You might have a _lot_ of ideas about what you want your program to do and still only have a tiny fraction of an understanding of what the program you produced will actually do. |
| 2023-11-06 03:50:24 +0100 | <exarkun> | It's true in Haskell, too. The ratio is maybe a little more favorable, that's all. |
| 2023-11-06 03:51:02 +0100 | <exarkun> | If you want to be really righteous you better be writing Coq or something :) |
| 2023-11-06 03:51:29 +0100 | <monochrom> | I am learning recursion in Lean, actually. :) |
| 2023-11-06 03:52:10 +0100 | <exarkun> | Woo :) I got through a lot (but not all) of https://www.ma.imperial.ac.uk/~buzzard/xena/natural_number_game/ |
| 2023-11-06 03:52:39 +0100 | <monochrom> | I like the meme of "a suitable user-defined/definable data type gives you recursion" >:) |
| 2023-11-06 03:52:42 +0100 | <exarkun> | (which I found to be very approachable) |
| 2023-11-06 03:53:35 +0100 | <Inst> | iirc they're now complaining about people who know how to work with a proof language, but not with a manual, pen and paper proof |
| 2023-11-06 03:53:43 +0100 | <Inst> | and yeah, I loved the natural number game |
| 2023-11-06 03:55:01 +0100 | <monochrom> | We (humanity) are long past complaining about how people can code in an IDE but not with a manual, pen, and paper. (I still can, I grew up that way.) |
| 2023-11-06 03:55:15 +0100 | <exarkun> | in my day we proved commutivity of multiplication on the reals uphill both ways, through the snow |
| 2023-11-06 03:55:21 +0100 | <monochrom> | By the Curry-Howard isomorphism, I don't see why proofs have to be different. >:) |
| 2023-11-06 03:55:32 +0100 | <Inst> | I deliberately coded in wordpad for a while :) |
| 2023-11-06 03:55:47 +0100 | <Inst> | Just, VSC was so unergonomic :) |
| 2023-11-06 03:58:13 +0100 | <Inst> | so how long until someone uses imperial college's software architecture to turn rudin and artin into games? :) |
| 2023-11-06 04:03:01 +0100 | pixelmonk | (~pixelmonk@50.205.76.66) |
| 2023-11-06 04:03:02 +0100 | <Inst> | and I still code in KWrite now that I'm on Arch |
| 2023-11-06 04:06:20 +0100 | nate2 | (~nate@c-98-45-169-16.hsd1.ca.comcast.net) (Read error: Connection reset by peer) |
| 2023-11-06 04:07:36 +0100 | finn_elija | (~finn_elij@user/finn-elija/x-0085643) |
| 2023-11-06 04:07:36 +0100 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) (Killed (NickServ (Forcing logout FinnElija -> finn_elija))) |
| 2023-11-06 04:07:36 +0100 | finn_elija | FinnElija |
| 2023-11-06 04:09:31 +0100 | pixelmonk | (~pixelmonk@50.205.76.66) (Ping timeout: 264 seconds) |
| 2023-11-06 04:11:31 +0100 | emmanuelux | (~emmanuelu@user/emmanuelux) (Quit: au revoir) |
| 2023-11-06 04:14:31 +0100 | pixelmonk | (~pixelmonk@50.205.76.66) |
| 2023-11-06 04:15:35 +0100 | [Leary] | (~Leary]@user/Leary/x-0910699) (Remote host closed the connection) |
| 2023-11-06 04:15:49 +0100 | [Leary] | (~Leary]@user/Leary/x-0910699) |
| 2023-11-06 04:17:47 +0100 | edilmedeiros | (~user@2804:14c:658b:5993:414e:c397:748f:b8af) (Quit: ERC 5.4 (IRC client for GNU Emacs 28.2)) |
| 2023-11-06 04:29:25 +0100 | Unicorn_Princess | (~Unicorn_P@user/Unicorn-Princess/x-3540542) (Remote host closed the connection) |
| 2023-11-06 04:30:05 +0100 | nate2 | (~nate@c-98-45-169-16.hsd1.ca.comcast.net) |
| 2023-11-06 04:31:33 +0100 | Shock_ | (~shOkEy@178-164-206-97.pool.digikabel.hu) |
| 2023-11-06 04:35:07 +0100 | szkl | (uid110435@id-110435.uxbridge.irccloud.com) |
| 2023-11-06 04:39:01 +0100 | td_ | (~td@i5387091C.versanet.de) (Ping timeout: 240 seconds) |
| 2023-11-06 04:40:58 +0100 | Ascension | (~Ascension@176.254.244.83) (Ping timeout: 255 seconds) |
| 2023-11-06 04:40:59 +0100 | td_ | (~td@i53870928.versanet.de) |
| 2023-11-06 04:49:01 +0100 | nate2 | (~nate@c-98-45-169-16.hsd1.ca.comcast.net) (Ping timeout: 240 seconds) |
| 2023-11-06 04:58:20 +0100 | trev | (~trev@user/trev) |
| 2023-11-06 05:01:44 +0100 | rosco | (~rosco@yp-150-69.tm.net.my) |
| 2023-11-06 05:11:31 +0100 | alphastate | (~alphastat@176.254.244.83) |
| 2023-11-06 05:16:21 +0100 | [_] | (~itchyjunk@user/itchyjunk/x-7353470) (Read error: Connection reset by peer) |
| 2023-11-06 05:16:47 +0100 | <dsal> | Usually when someone references Arch in here, it's "why don't things work." I've never used Arch, so I don't know anything about it. |
| 2023-11-06 05:18:21 +0100 | waleee | (~waleee@h-176-10-144-38.NA.cust.bahnhof.se) (Ping timeout: 240 seconds) |
| 2023-11-06 05:31:03 +0100 | <Inst> | I'm finally ready to take the plunge and switch to a Nix-based workflow with NixOS, but I don't have my password book with me and the moment I lose my cookies, I'm in trouble. |
| 2023-11-06 05:45:33 +0100 | aforemny_ | (~aforemny@2001:9e8:6cd9:8900:f44b:90af:4c17:1875) |
| 2023-11-06 05:46:15 +0100 | aforemny | (~aforemny@2001:9e8:6cf3:8800:56a7:5281:8d04:8d56) (Ping timeout: 240 seconds) |
| 2023-11-06 05:57:19 +0100 | machinedgod | (~machinedg@d198-53-218-113.abhsia.telus.net) |
| 2023-11-06 06:08:01 +0100 | _ht | (~Thunderbi@28-52-174-82.ftth.glasoperator.nl) |
| 2023-11-06 06:13:12 +0100 | michalz | (~michalz@185.246.207.221) |
| 2023-11-06 06:13:32 +0100 | Inst | (~Inst@120.244.192.250) (Read error: Connection reset by peer) |
| 2023-11-06 06:15:57 +0100 | Inst | (~Inst@120.244.192.250) |
| 2023-11-06 06:22:14 +0100 | <EvanR> | when I used arch way back when it was a constant stream of breakage followed by a questionable package management command to fix it |
| 2023-11-06 06:22:44 +0100 | ddellacosta | (~ddellacos@ool-44c738de.dyn.optonline.net) (Ping timeout: 255 seconds) |
| 2023-11-06 06:23:23 +0100 | ddellacosta | (~ddellacos@ool-44c738de.dyn.optonline.net) |
| 2023-11-06 06:24:20 +0100 | <EvanR> | on disabling module dot, you can still import Numeric |
| 2023-11-06 06:24:33 +0100 | rosco | (~rosco@yp-150-69.tm.net.my) (Quit: Lost terminal) |
| 2023-11-06 06:31:24 +0100 | misterfish | (~misterfis@84-53-85-146.bbserv.nl) |
| 2023-11-06 06:32:39 +0100 | xff0x | (~xff0x@2405:6580:b080:900:c81e:fd76:511a:4c08) (Quit: xff0x) |
| 2023-11-06 06:33:10 +0100 | trev | (~trev@user/trev) (Quit: trev) |
| 2023-11-06 06:34:09 +0100 | xff0x | (~xff0x@2405:6580:b080:900:f3e:d321:f29c:28da) |
| 2023-11-06 06:34:38 +0100 | trev | (~trev@user/trev) |
| 2023-11-06 06:41:55 +0100 | ddellacosta | (~ddellacos@ool-44c738de.dyn.optonline.net) (Ping timeout: 264 seconds) |
| 2023-11-06 06:42:43 +0100 | chiselfuse | (~chiselfus@user/chiselfuse) (Remote host closed the connection) |
| 2023-11-06 06:43:10 +0100 | chiselfuse | (~chiselfus@user/chiselfuse) |
| 2023-11-06 06:43:36 +0100 | ddellacosta | (~ddellacos@ool-44c738de.dyn.optonline.net) |
| 2023-11-06 06:44:55 +0100 | notzmv | (~zmv@user/notzmv) (Ping timeout: 264 seconds) |
| 2023-11-06 06:46:04 +0100 | misterfish | (~misterfis@84-53-85-146.bbserv.nl) (Ping timeout: 255 seconds) |
| 2023-11-06 06:46:24 +0100 | hgolden | (~hgolden@2603-8000-9d00-3ed1-dd4f-298a-9c49-a0ed.res6.spectrum.com) |
| 2023-11-06 06:47:58 +0100 | misterfish | (~misterfis@84-53-85-146.bbserv.nl) |
| 2023-11-06 06:49:43 +0100 | xff0x | (~xff0x@2405:6580:b080:900:f3e:d321:f29c:28da) (Ping timeout: 264 seconds) |
| 2023-11-06 06:50:32 +0100 | xff0x | (~xff0x@2405:6580:b080:900:e0ef:e9c5:9ef8:87cb) |
| 2023-11-06 06:56:39 +0100 | xff0x | (~xff0x@2405:6580:b080:900:e0ef:e9c5:9ef8:87cb) (Ping timeout: 240 seconds) |
| 2023-11-06 06:57:44 +0100 | xff0x | (~xff0x@2405:6580:b080:900:ffab:5b77:1199:ce6b) |
| 2023-11-06 07:06:31 +0100 | pixelmonk | (~pixelmonk@50.205.76.66) (Ping timeout: 264 seconds) |
| 2023-11-06 07:09:10 +0100 | szkl | (uid110435@id-110435.uxbridge.irccloud.com) (Quit: Connection closed for inactivity) |
| 2023-11-06 07:13:03 +0100 | pixelmonk | (~pixelmonk@50.205.76.66) |
| 2023-11-06 07:21:25 +0100 | ChaiTRex | (~ChaiTRex@user/chaitrex) (Remote host closed the connection) |
| 2023-11-06 07:23:34 +0100 | takuan | (~takuan@178-116-218-225.access.telenet.be) |
| 2023-11-06 07:36:05 +0100 | foul_owl | (~kerry@185.216.231.182) (Ping timeout: 240 seconds) |
| 2023-11-06 07:39:13 +0100 | _ht | (~Thunderbi@28-52-174-82.ftth.glasoperator.nl) (Quit: _ht) |
| 2023-11-06 07:39:37 +0100 | ACuriousMoose | (~ACuriousM@142.166.18.53) (Quit: Ping timeout (120 seconds)) |
| 2023-11-06 07:39:59 +0100 | ACuriousMoose | (~ACuriousM@142.166.18.53) |
| 2023-11-06 07:40:53 +0100 | foul_owl | (~kerry@174-21-66-189.tukw.qwest.net) |
| 2023-11-06 07:44:21 +0100 | ACuriousMoose | (~ACuriousM@142.166.18.53) (Ping timeout: 240 seconds) |
| 2023-11-06 07:48:01 +0100 | foul_owl | (~kerry@174-21-66-189.tukw.qwest.net) (Ping timeout: 240 seconds) |
| 2023-11-06 07:51:36 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2023-11-06 07:52:15 +0100 | misterfish | (~misterfis@84-53-85-146.bbserv.nl) (Ping timeout: 240 seconds) |
| 2023-11-06 07:55:52 +0100 | adanwan | (~adanwan@gateway/tor-sasl/adanwan) (Remote host closed the connection) |
| 2023-11-06 07:56:41 +0100 | hsw | (~hsw@2001-b030-2303-0104-0172-0025-0012-0132.hinet-ip6.hinet.net) |
| 2023-11-06 07:56:55 +0100 | adanwan | (~adanwan@gateway/tor-sasl/adanwan) |
| 2023-11-06 08:00:41 +0100 | foul_owl | (~kerry@185.219.141.160) |
| 2023-11-06 08:03:12 +0100 | ACuriousMoose | (~ACuriousM@142.166.18.53) |
| 2023-11-06 08:07:42 +0100 | thegman | (~thegman@072-239-207-086.res.spectrum.com) (Quit: leaving) |
| 2023-11-06 08:07:56 +0100 | lisbeths | (uid135845@id-135845.lymington.irccloud.com) |
| 2023-11-06 08:08:09 +0100 | thegman | (~thegman@072-239-207-086.res.spectrum.com) |
| 2023-11-06 08:08:16 +0100 | adanwan_ | (~adanwan@gateway/tor-sasl/adanwan) |
| 2023-11-06 08:08:42 +0100 | thegman | (~thegman@072-239-207-086.res.spectrum.com) (Client Quit) |
| 2023-11-06 08:09:02 +0100 | adanwan | (~adanwan@gateway/tor-sasl/adanwan) (Ping timeout: 256 seconds) |
| 2023-11-06 08:13:30 +0100 | Inst | (~Inst@120.244.192.250) (Remote host closed the connection) |
| 2023-11-06 08:13:49 +0100 | Inst | (~Inst@120.244.192.250) |
| 2023-11-06 08:15:14 +0100 | pixelmonk | (~pixelmonk@50.205.76.66) (Quit: WeeChat 4.1.0) |
| 2023-11-06 08:21:39 +0100 | acidjnk | (~acidjnk@p200300d6e72b93215d0d304e1b7de813.dip0.t-ipconnect.de) |
| 2023-11-06 08:28:52 +0100 | mmhat | (~mmh@p200300f1c7445e0aee086bfffe095315.dip0.t-ipconnect.de) |
| 2023-11-06 08:30:05 +0100 | mmhat | (~mmh@p200300f1c7445e0aee086bfffe095315.dip0.t-ipconnect.de) (Client Quit) |
| 2023-11-06 08:35:09 +0100 | Square | (~Square@user/square) (Ping timeout: 258 seconds) |
| 2023-11-06 08:37:27 +0100 | coot | (~coot@89-69-206-216.dynamic.chello.pl) |
| 2023-11-06 08:40:12 +0100 | tzh | (~tzh@c-71-193-181-0.hsd1.or.comcast.net) (Quit: zzz) |
| 2023-11-06 08:44:03 +0100 | fendor | (~fendor@2a02:8388:1640:be00:cb6e:46f6:2fe6:1728) |
| 2023-11-06 08:48:47 +0100 | sord937 | (~sord937@gateway/tor-sasl/sord937) |
| 2023-11-06 08:50:42 +0100 | Inst | (~Inst@120.244.192.250) (Ping timeout: 255 seconds) |
| 2023-11-06 08:52:21 +0100 | danza | (~francesco@151.35.124.76) |
| 2023-11-06 08:54:32 +0100 | notzmv | (~zmv@user/notzmv) |
| 2023-11-06 08:56:30 +0100 | elevenkb | (elevenkb@thunix.net) (ERC 5.5.0.29.1 (IRC client for GNU Emacs 29.1)) |
| 2023-11-06 08:56:51 +0100 | elevenkb | (elevenkb@thunix.net) |
| 2023-11-06 08:57:32 +0100 | gmg | (~user@user/gehmehgeh) |
| 2023-11-06 09:02:44 +0100 | lortabac | (~lorenzo@2a01:e0a:541:b8f0:578c:5f9d:ee54:ec6a) |
| 2023-11-06 09:14:30 +0100 | arahael | (~arahael@119-18-2-212.771202.syd.nbn.aussiebb.net) |
| 2023-11-06 09:17:54 +0100 | sord937 | (~sord937@gateway/tor-sasl/sord937) (Remote host closed the connection) |
| 2023-11-06 09:18:20 +0100 | sord937 | (~sord937@gateway/tor-sasl/sord937) |
| 2023-11-06 09:26:50 +0100 | arahael | (~arahael@119-18-2-212.771202.syd.nbn.aussiebb.net) (Quit: "Rebooting...") |
| 2023-11-06 09:26:55 +0100 | danza | (~francesco@151.35.124.76) (Ping timeout: 264 seconds) |
| 2023-11-06 09:30:15 +0100 | misterfish | (~misterfis@145.128.244.93) |
| 2023-11-06 09:30:24 +0100 | <tomsmeding> | EvanR: my most interesting arch breakage was related to nvidia drivers |
| 2023-11-06 09:30:29 +0100 | <tomsmeding> | and I'm not too sure I can blame that on arch |
| 2023-11-06 09:30:58 +0100 | <tomsmeding> | sure, haskell on arch is broken, but ghcup exists, so I don't care |
| 2023-11-06 09:32:06 +0100 | chele | (~chele@user/chele) |
| 2023-11-06 09:39:00 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2023-11-06 09:40:54 +0100 | gooba_ | (~gooba@90-231-13-185-no3430.tbcn.telia.com) |
| 2023-11-06 09:41:11 +0100 | Jackneill_ | (~Jackneill@20014C4E1E058A00E81C5E515534C989.dsl.pool.telekom.hu) |
| 2023-11-06 09:43:07 +0100 | gooba | (~gooba@90-231-13-185-no3430.tbcn.telia.com) (Ping timeout: 264 seconds) |
| 2023-11-06 09:45:01 +0100 | Athas | (athas@sigkill.dk) (K-Lined) |
| 2023-11-06 09:48:20 +0100 | Athas | (athas@2a01:7c8:aaac:1cf:6044:bd15:3f5b:9264) |
| 2023-11-06 09:49:45 +0100 | danse-nr3 | (~danse@151.35.124.76) |
| 2023-11-06 09:51:05 +0100 | misterfish | (~misterfis@145.128.244.93) (Ping timeout: 240 seconds) |
| 2023-11-06 09:52:24 +0100 | arahael | (~arahael@119-18-2-212.771202.syd.nbn.aussiebb.net) |
| 2023-11-06 09:59:12 +0100 | Inst | (~Inst@120.244.192.250) |
| 2023-11-06 10:02:29 +0100 | kenran | (~user@user/kenran) |
| 2023-11-06 10:07:34 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2023-11-06 10:11:36 +0100 | Athas | (athas@2a01:7c8:aaac:1cf:6044:bd15:3f5b:9264) (Quit: ZNC 1.8.2 - https://znc.in) |
| 2023-11-06 10:11:47 +0100 | Athas | (athas@2a01:7c8:aaac:1cf:6044:bd15:3f5b:9264) |
| 2023-11-06 10:12:36 +0100 | tcard | (~tcard@2400:4051:5801:7500:cf17:befc:ff82:5303) (Remote host closed the connection) |
| 2023-11-06 10:12:54 +0100 | tcard | (~tcard@2400:4051:5801:7500:cf17:befc:ff82:5303) |
| 2023-11-06 10:15:41 +0100 | econo_ | (uid147250@id-147250.tinside.irccloud.com) (Quit: Connection closed for inactivity) |
| 2023-11-06 10:20:57 +0100 | szkl | (uid110435@id-110435.uxbridge.irccloud.com) |
| 2023-11-06 10:21:35 +0100 | remexre | (~remexre@user/remexre) (Ping timeout: 240 seconds) |
| 2023-11-06 10:21:40 +0100 | remexre_ | (~remexre@user/remexre) |
| 2023-11-06 10:22:47 +0100 | remexre_ | remexre |
| 2023-11-06 10:25:03 +0100 | mal1 | lieven |
| 2023-11-06 10:26:00 +0100 | Sgeo | (~Sgeo@user/sgeo) (Read error: Connection reset by peer) |
| 2023-11-06 10:26:28 +0100 | misterfish | (~misterfis@87.215.131.102) |
| 2023-11-06 10:26:44 +0100 | <danse-nr3> | moin |
| 2023-11-06 10:36:34 +0100 | <Hecate> | moin moin |
| 2023-11-06 10:40:36 +0100 | <Inst> | https://encrypted-tbn0.gstatic.com/images?q=tbn:ANd9GcRkzod5qhcSoBGScr4knWrQ39Y07IXLkVqojQ&usqp=CAU |
| 2023-11-06 10:42:03 +0100 | <Inst> | deutsch for hello, yoruba for a delicious looking bean pudding |
| 2023-11-06 10:47:51 +0100 | <Inst> | huh, that's interesting |
| 2023-11-06 10:47:55 +0100 | kuribas | (~user@ip-188-118-57-242.reverse.destiny.be) |
| 2023-11-06 10:48:21 +0100 | <Inst> | if you let and put in a bang on the definition within do (or presumably where as well), it'll be evaluated? |
| 2023-11-06 10:55:17 +0100 | idgaen | (~idgaen@2a01:e0a:498:fd50:fcc6:bb5d:489a:ce8c) |
| 2023-11-06 11:01:30 +0100 | <Inst> | let !foo = undefined causes an exception within do notation |
| 2023-11-06 11:02:48 +0100 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:1052:6194:3db5:da7a) (Remote host closed the connection) |
| 2023-11-06 11:11:42 +0100 | <tomsmeding> | > let !foo = undefined in () |
| 2023-11-06 11:11:44 +0100 | <lambdabot> | *Exception: Prelude.undefined |
| 2023-11-06 11:11:48 +0100 | <tomsmeding> | Inst: that's how bang patterns in let bindings work |
| 2023-11-06 11:11:56 +0100 | CO2 | (CO2@gateway/vpn/protonvpn/co2) (Quit: WeeChat 4.1.1) |
| 2023-11-06 11:15:31 +0100 | raehik | (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) |
| 2023-11-06 11:15:55 +0100 | Maxdamantus | (~Maxdamant@user/maxdamantus) (Ping timeout: 255 seconds) |
| 2023-11-06 11:17:04 +0100 | <Inst> | brought up by konsumlaam after i spammed CLC with a requset for base nto add pure' |
| 2023-11-06 11:17:22 +0100 | <Inst> | konsumlamm |
| 2023-11-06 11:17:44 +0100 | <probie> | Is `pure'` just `(pure $!)`? |
| 2023-11-06 11:17:46 +0100 | Maxdamantus | (~Maxdamant@user/maxdamantus) |
| 2023-11-06 11:17:48 +0100 | <Inst> | yes |
| 2023-11-06 11:18:13 +0100 | VioletJewel | (~violet@user/violetjewel) (Server closed connection) |
| 2023-11-06 11:18:27 +0100 | VioletJewel | (violet@user/violetjewel) |
| 2023-11-06 11:18:28 +0100 | <Inst> | wait, so let bindings actually actuate thunks? |
| 2023-11-06 11:18:49 +0100 | __monty__ | (~toonn@user/toonn) |
| 2023-11-06 11:19:25 +0100 | <kuribas> | Inst: why not? |
| 2023-11-06 11:20:19 +0100 | <Inst> | since it's operational? |
| 2023-11-06 11:21:01 +0100 | <nullie> | I thought that let is just substitution |
| 2023-11-06 11:21:09 +0100 | <tomsmeding> | not when bang patterns are involved |
| 2023-11-06 11:21:10 +0100 | <kuribas> | Only match is evaluating values. |
| 2023-11-06 11:21:32 +0100 | <tomsmeding> | but bang patterns are additional syntax above Haskell2010, and new syntax introduces new semantics |
| 2023-11-06 11:21:34 +0100 | <opqdonut> | nullie: even without bang patterns, let introduces sharing |
| 2023-11-06 11:21:38 +0100 | <kuribas> | pattern matches. |
| 2023-11-06 11:21:41 +0100 | <nullie> | opqdonut: yeah |
| 2023-11-06 11:21:46 +0100 | <kuribas> | (without stricness annotations). |
| 2023-11-06 11:22:47 +0100 | <opqdonut> | one can think of `let !foo = undefined in ()` as something like `let foo@(SomePattern _) = undefined in ()` |
| 2023-11-06 11:22:52 +0100 | <Inst> | > do; putStrLn "Hello"; let !foo = undefined; pure () |
| 2023-11-06 11:22:53 +0100 | <lambdabot> | <hint>:1:52: error: |
| 2023-11-06 11:22:53 +0100 | <lambdabot> | parse error (possibly incorrect indentation or mismatched brackets) |
| 2023-11-06 11:23:12 +0100 | <Inst> | > do; putStrLn "Hello"; let !foo = undefined; pure () |
| 2023-11-06 11:23:13 +0100 | <lambdabot> | <hint>:1:64: error: |
| 2023-11-06 11:23:14 +0100 | <lambdabot> | parse error (possibly incorrect indentation or mismatched brackets) |
| 2023-11-06 11:23:15 +0100 | <tomsmeding> | % do putStrLn "hi"; let !foo = undefined; puer () |
| 2023-11-06 11:23:16 +0100 | <yahb2> | <interactive>:135:48: error: ; parse error (possibly incorrect indentation or mismatched brackets) |
| 2023-11-06 11:23:22 +0100 | <tomsmeding> | % do { putStrLn "hi"; let !foo = undefined; pure () } |
| 2023-11-06 11:23:22 +0100 | <yahb2> | <interactive>:137:51: error: parse error on input ‘}’ |
| 2023-11-06 11:23:23 +0100 | <opqdonut> | no wait, the foo@(SomePattern _) doesn't fail, I thought it would |
| 2023-11-06 11:23:24 +0100 | <tomsmeding> | % do { putStrLn "hi"; let !foo = undefined; pure (); } |
| 2023-11-06 11:23:25 +0100 | <yahb2> | <interactive>:139:50: error: parse error on input ‘;’ |
| 2023-11-06 11:23:28 +0100 | <kuribas> | > let x = undefined in (1, 2) |
| 2023-11-06 11:23:30 +0100 | <lambdabot> | (1,2) |
| 2023-11-06 11:23:30 +0100 | <tomsmeding> | % do { putStrLn "hi"; let {!foo = undefined}; pure (); } |
| 2023-11-06 11:23:31 +0100 | <yahb2> | hi ; *** Exception: Prelude.undefined ; CallStack (from HasCallStack): ; error, called at libraries/base/GHC/Err.hs:74:14 in base:GHC.Err ; undefined, called at <interactive>:141:33 in interact... |
| 2023-11-06 11:23:38 +0100 | <tomsmeding> | I always do this wrong |
| 2023-11-06 11:23:38 +0100 | <kuribas> | > let (x, y) = undefined in (1, 2) |
| 2023-11-06 11:23:40 +0100 | <lambdabot> | (1,2) |
| 2023-11-06 11:23:55 +0100 | <kuribas> | hmm, shouldn't that be bottom? |
| 2023-11-06 11:24:01 +0100 | <opqdonut> | yeah that's what I was thinking as well |
| 2023-11-06 11:24:05 +0100 | <tomsmeding> | kuribas: you example? no |
| 2023-11-06 11:24:09 +0100 | <tomsmeding> | only when you use x or y |
| 2023-11-06 11:24:10 +0100 | <opqdonut> | you'd need a ~ to not have it bottom |
| 2023-11-06 11:24:12 +0100 | xff0x | (~xff0x@2405:6580:b080:900:ffab:5b77:1199:ce6b) (Ping timeout: 248 seconds) |
| 2023-11-06 11:24:14 +0100 | <tomsmeding> | > let (x, y) = undefined in (x, 2) |
| 2023-11-06 11:24:16 +0100 | <lambdabot> | (*Exception: Prelude.undefined |
| 2023-11-06 11:24:26 +0100 | <tomsmeding> | https://downloads.haskell.org/ghc/latest/docs/users_guide/exts/strict.html#extension-BangPatterns |
| 2023-11-06 11:24:43 +0100 | <Inst> | yeah but this is all of a sudden operational and I'm now thinking of let introducing thunks in a sequence ;_; |
| 2023-11-06 11:24:51 +0100 | <Inst> | if I'm not bang patterning it |
| 2023-11-06 11:24:52 +0100 | <tomsmeding> | Inst: it's new syntax |
| 2023-11-06 11:25:02 +0100 | <opqdonut> | oh right even the spec says: let p = e1 in e0 = case e1 of ~p -> e0 |
| 2023-11-06 11:25:03 +0100 | <tomsmeding> | and also, evaluation is a semantical thing |
| 2023-11-06 11:25:04 +0100 | xff0x | (~xff0x@2405:6580:b080:900:1034:83b0:f1e0:db5e) |
| 2023-11-06 11:25:05 +0100 | <Inst> | so let is still "virtual", but bang-patterned let isn't? |
| 2023-11-06 11:25:16 +0100 | <tomsmeding> | if it's bottom, that happens _then_, not later |
| 2023-11-06 11:25:27 +0100 | <kuribas> | > let ~(x, y) = undefined in (1, 2) |
| 2023-11-06 11:25:29 +0100 | <lambdabot> | (1,2) |
| 2023-11-06 11:25:57 +0100 | <tomsmeding> | > case undefined of ~(x, y) -> (1, 2) |
| 2023-11-06 11:25:58 +0100 | <lambdabot> | (1,2) |
| 2023-11-06 11:26:00 +0100 | <tomsmeding> | > case undefined of (x, y) -> (1, 2) |
| 2023-11-06 11:26:02 +0100 | <lambdabot> | *Exception: Prelude.undefined |
| 2023-11-06 11:26:06 +0100 | <tomsmeding> | it's case that is strict |
| 2023-11-06 11:26:09 +0100 | <opqdonut> | yeah |
| 2023-11-06 11:26:20 +0100 | <tomsmeding> | '~' on a let binding doesn't do anything |
| 2023-11-06 11:26:38 +0100 | <tomsmeding> | just like '!' on a case pattern :p |
| 2023-11-06 11:26:53 +0100 | <tomsmeding> | (not counting nested uses of '!', those of course do have meaning) |
| 2023-11-06 11:27:09 +0100 | <opqdonut> | interesting duality |
| 2023-11-06 11:27:14 +0100 | <Inst> | the nice thing i liked about Haskell is that I don't have to think in terms of memory allocation much of the time |
| 2023-11-06 11:27:16 +0100 | <opqdonut> | hadn't thought of it that way, thanks |
| 2023-11-06 11:27:28 +0100 | <tomsmeding> | Inst: this is not about memory allocation, it's about bottoms and exceptions |
| 2023-11-06 11:27:40 +0100 | <tomsmeding> | it only becomes about memory allocation or performance or stuff when you think operationally |
| 2023-11-06 11:27:47 +0100 | <tomsmeding> | and you seem to not want to do that, so don't :p |
| 2023-11-06 11:27:52 +0100 | <tomsmeding> | (I do) |
| 2023-11-06 11:27:52 +0100 | <Inst> | the point of pure $! / pure' is to force evaluation of a term without using evaluate |
| 2023-11-06 11:28:10 +0100 | <Inst> | without IO, you have (pure $!) . force |
| 2023-11-06 11:28:41 +0100 | <Inst> | but the implication is that a non-strict let expression is going to create thunks |
| 2023-11-06 11:28:54 +0100 | <tomsmeding> | everything creates thunks |
| 2023-11-06 11:29:01 +0100 | <tomsmeding> | a let expression creates sharing |
| 2023-11-06 11:29:16 +0100 | <tomsmeding> | if I write `pure (expensive 1 2 3)`, then that'll be a thunk, no need for 'let' |
| 2023-11-06 11:29:41 +0100 | <Inst> | how many thunks is that? |
| 2023-11-06 11:29:45 +0100 | <tomsmeding> | many :p |
| 2023-11-06 11:29:50 +0100 | <mauke> | > case undefined of !_ -> () |
| 2023-11-06 11:29:52 +0100 | <lambdabot> | *Exception: Prelude.undefined |
| 2023-11-06 11:30:10 +0100 | <tomsmeding> | :t case undefined of x -> x |
| 2023-11-06 11:30:11 +0100 | <lambdabot> | a |
| 2023-11-06 11:30:16 +0100 | <Inst> | bleh, it's my fault, I should just go watch Alexis King on laziness instead |
| 2023-11-06 11:30:32 +0100 | <Inst> | i default to accumulating parameter because I do care about operational semantics |
| 2023-11-06 11:30:39 +0100 | <mauke> | > case undefined of _ -> () |
| 2023-11-06 11:30:41 +0100 | <lambdabot> | () |
| 2023-11-06 11:30:54 +0100 | <tomsmeding> | Inst: if you care about operational semantics, don't complain that things have operational semantics :p |
| 2023-11-06 11:31:29 +0100 | rosco | (~rosco@yp-150-69.tm.net.my) |
| 2023-11-06 11:31:37 +0100 | <Inst> | i'd rather be able to assume that a let expression just gets optimized away if it isn't used |
| 2023-11-06 11:31:46 +0100 | <Inst> | whereas let !foo completely blows this intuition out of the water |
| 2023-11-06 11:31:54 +0100 | <tomsmeding> | but I haven't watched the video you're referring to, but Alexis knows what she's talking about, so probably a good source |
| 2023-11-06 11:32:15 +0100 | <Inst> | let !foo = seq (expensive computation) () in 3 |
| 2023-11-06 11:32:20 +0100 | <tomsmeding> | I mean, that's what BangPatterns are for :p |
| 2023-11-06 11:32:23 +0100 | <tomsmeding> | that's redundant |
| 2023-11-06 11:32:44 +0100 | <tomsmeding> | `let !foo = a in b` can be desugared to `let foo = a in a `seq` b` |
| 2023-11-06 11:33:02 +0100 | <tomsmeding> | oh wait different thing |
| 2023-11-06 11:33:15 +0100 | <int-e> | foo `seq` b |
| 2023-11-06 11:33:18 +0100 | <tomsmeding> | your thing is the same as "expensive computation `seq` b" |
| 2023-11-06 11:33:19 +0100 | <tomsmeding> | yeah |
| 2023-11-06 11:33:32 +0100 | <tomsmeding> | er, 3, not b |
| 2023-11-06 11:33:34 +0100 | <Inst> | and no one `foo <- pure bar`s anyways, right? |
| 2023-11-06 11:33:51 +0100 | <tomsmeding> | can be useful if "foo" is a more interesting pattern |
| 2023-11-06 11:33:53 +0100 | <Inst> | So why the left identity? Is it simply because of the adaptation of the monad concept? |
| 2023-11-06 11:34:12 +0100 | <tomsmeding> | either to trigger MonadFail, or for GADT-specific type inference reasons |
| 2023-11-06 11:34:27 +0100 | <tomsmeding> | the monad laws are all necessary to pin down what you expect of a monad |
| 2023-11-06 11:34:46 +0100 | <tomsmeding> | sure, nobody literally writes "foo <- pure bar", but you'd sure want that to do the obvious thing if you did it |
| 2023-11-06 11:34:52 +0100 | pruiz | (~user@user/pruiz) |
| 2023-11-06 11:35:06 +0100 | <tomsmeding> | and furthermore, you might do "foo <- something bar" where "something x" eventually evaluates to "pure x" |
| 2023-11-06 11:35:14 +0100 | <tomsmeding> | and you'd want that to do the obvious thing |
| 2023-11-06 11:35:15 +0100 | <Inst> | yeah, thanks |
| 2023-11-06 11:35:22 +0100 | <Inst> | I like the purescript justification of monad laws |
| 2023-11-06 11:35:50 +0100 | <Inst> | left identity -> pure foo resolves correctly, right identity, pure (some value at the end) resolves correctly |
| 2023-11-06 11:36:00 +0100 | <Inst> | they use do blocks that are binded into to justify associativity |
| 2023-11-06 11:36:25 +0100 | <Inst> | but unless I'm wrong, a better argument is that it guarantees that you don't get weird behavior from inlining of monadic code |
| 2023-11-06 11:36:27 +0100 | <tomsmeding> | Inst: have you ever seen the monad laws formulated using return and >=> instead of using return and >>= ? |
| 2023-11-06 11:37:07 +0100 | <Inst> | it's on the wiki |
| 2023-11-06 11:37:15 +0100 | <tomsmeding> | probably :p |
| 2023-11-06 11:37:16 +0100 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:718b:eff8:b2d7:bbc8) |
| 2023-11-06 11:37:28 +0100 | <Inst> | i prefer the ones based off pure and join |
| 2023-11-06 11:37:30 +0100 | <tomsmeding> | "monad is a monoid" vibe |
| 2023-11-06 11:37:32 +0100 | <Inst> | because that's easier to understand |
| 2023-11-06 11:37:49 +0100 | chomwitt | (~chomwitt@2a02:587:7a2d:bc00:1ac0:4dff:fedb:a3f1) |
| 2023-11-06 11:38:09 +0100 | <tomsmeding> | then it's good that there are multiple ways to formulate them, because 'join' is _not_ easier to understand to me :) |
| 2023-11-06 11:39:28 +0100 | <mauke> | oh, are they like associativity of >=> and return=identity? |
| 2023-11-06 11:39:40 +0100 | <mauke> | or neutral element |
| 2023-11-06 11:40:00 +0100 | <ncf> | the laws make Kleisli into a category |
| 2023-11-06 11:40:02 +0100 | ft | (~ft@p4fc2a529.dip0.t-ipconnect.de) (Quit: leaving) |
| 2023-11-06 11:40:31 +0100 | <ncf> | (where Kleisli a b = a -> m b) |
| 2023-11-06 11:41:06 +0100 | <[exa]> | Inst: you mean the 4 from here? https://en.wikibooks.org/wiki/Haskell/Category_theory#The_monad_laws_and_their_importance |
| 2023-11-06 11:41:10 +0100 | <Inst> | join . pure = join . fmap pure = (id :: m a -> m a) |
| 2023-11-06 11:41:53 +0100 | <Inst> | join . fmap join = join . join |
| 2023-11-06 11:42:21 +0100 | <tomsmeding> | mauke: yeah, return >=> m = m, m >=> return = m, a >=> (b >=> c) = (a >=> b) >=> c |
| 2023-11-06 11:42:29 +0100 | <[exa]> | I find these slightly inconvenient because I can't see how the ruleset is complete. With monoids it's super clear. |
| 2023-11-06 11:43:26 +0100 | <tomsmeding> | I mean, the second one encodes "associativity" of join |
| 2023-11-06 11:43:58 +0100 | <tomsmeding> | the first one says that you can pure in one level, or pure in the other level, and after join they both disappear |
| 2023-11-06 11:44:02 +0100 | <tomsmeding> | which is the identity laws |
| 2023-11-06 11:44:15 +0100 | <tomsmeding> | but surely (?!) one would not consider those more intuitive :p |
| 2023-11-06 11:44:30 +0100 | <Inst> | pure >=> m = m = m >=> pure |
| 2023-11-06 11:44:33 +0100 | target_i | (~target_i@217.175.14.39) |
| 2023-11-06 11:45:04 +0100 | <Inst> | a >=> (b >=> c) = (a >=> b) >=> c |
| 2023-11-06 11:45:07 +0100 | <tomsmeding> | (see, I check that the pure/join laws are complete by releating them to the monoid laws -- a procedure that's much easier with the pure/>=> laws which literally look like monoid laws) |
| 2023-11-06 11:45:16 +0100 | <tomsmeding> | *relating |
| 2023-11-06 11:45:59 +0100 | stiell | (~stiell@gateway/tor-sasl/stiell) |
| 2023-11-06 11:46:24 +0100 | <Inst> | yeah, this is more succinct than the join version, but I understand it better via join and (>>=) = (join .). fmap |
| 2023-11-06 11:47:01 +0100 | <tomsmeding> | to each their own -- that's why I said, it's good that there are multiple formulations, so that you can choose the one that's most intuitive to you :) |
| 2023-11-06 11:47:57 +0100 | <Inst> | i think join club is smallest |
| 2023-11-06 11:48:16 +0100 | <Inst> | kleisli arrows explanation is more common |
| 2023-11-06 11:48:28 +0100 | <tomsmeding> | well, it's prettier |
| 2023-11-06 11:48:35 +0100 | <tomsmeding> | which is not necessarily a good criterion for understandability |
| 2023-11-06 11:48:41 +0100 | <tomsmeding> | but it works for me /shrug/ |
| 2023-11-06 11:49:28 +0100 | stiell_ | (~stiell@gateway/tor-sasl/stiell) (Ping timeout: 256 seconds) |
| 2023-11-06 11:49:30 +0100 | <Inst> | join . pure = id = join . fmap pure |
| 2023-11-06 11:50:33 +0100 | td_ | (~td@i53870928.versanet.de) (Quit: waking up from the american dream ...) |
| 2023-11-06 11:51:26 +0100 | <dminuoso> | Regarding the laws, I think associativity of monad is still quite intuitive but in ways most programmers dont think about. |
| 2023-11-06 11:52:13 +0100 | <dminuoso> | For IO, associativity is equvialent to "You can extract any region of IO code into a separate binding" |
| 2023-11-06 11:52:29 +0100 | <dminuoso> | Or as you would say in C "You can move any chunk of code into a separate function" |
| 2023-11-06 11:52:39 +0100 | <dminuoso> | It seems so silly and obvious that one does not really think about it |
| 2023-11-06 11:53:09 +0100 | <tomsmeding> | in that sense the identity laws are like "if you don't have side effects, you don't have side effects even if you're put in a larger program" |
| 2023-11-06 11:53:13 +0100 | <dminuoso> | While the Kleisli expression looks much simpler, I think its not necessarily more intuitive |
| 2023-11-06 11:53:37 +0100 | pruiz | (~user@user/pruiz) (Remote host closed the connection) |
| 2023-11-06 11:53:54 +0100 | pruiz | (~user@user/pruiz) |
| 2023-11-06 11:54:05 +0100 | <tomsmeding> | I can remember it, and that's a big pro for me personally |
| 2023-11-06 11:54:12 +0100 | <tomsmeding> | but good points |
| 2023-11-06 11:56:08 +0100 | <opqdonut> | dminuoso: I just bumped into the fact the other week that js react hooks don't obey that law. You need to invoke the hook direcly in your component, you can't invoke it inside a helper function! |
| 2023-11-06 11:57:06 +0100 | pruiz | (~user@user/pruiz) (Remote host closed the connection) |
| 2023-11-06 11:57:23 +0100 | pruiz | (~user@user/pruiz) |
| 2023-11-06 12:00:43 +0100 | <Inst> | dminuoso: ummm, I think I brought up something similar |
| 2023-11-06 12:00:57 +0100 | <Inst> | actually, i misunderstood, you go way broader than I do |
| 2023-11-06 12:01:06 +0100 | <Inst> | like you're implying the compiler can optimize in such a way |
| 2023-11-06 12:01:37 +0100 | pruiz | (~user@user/pruiz) (Client Quit) |
| 2023-11-06 12:01:38 +0100 | <Inst> | opqdonut: isn't that because promises are a quasi-monad? |
| 2023-11-06 12:02:07 +0100 | <tomsmeding> | wasn't it true that with JS promises, there is an implicit join at the end of .then? |
| 2023-11-06 12:02:09 +0100 | pruiz | (~user@213.4.200.211) |
| 2023-11-06 12:02:24 +0100 | <tomsmeding> | so a Promise (Promise a) gets auto-flattened to Promise a |
| 2023-11-06 12:02:53 +0100 | <int-e> | tomsmeding: you can always write it like this: https://paste.tomsmeding.com/aobXsiHf |
| 2023-11-06 12:02:58 +0100 | <Inst> | i mean that Promise I'm told breaks one of the monad laws |
| 2023-11-06 12:03:53 +0100 | <int-e> | which corresponds to the idea of pulling out fragment of monadic code and turning it into a separate function |
| 2023-11-06 12:04:18 +0100 | <tomsmeding> | int-e: I think that's what Inst referred to as what purescript uses to justify the laws (which I understood only after Inst related it to what dminuoso said :D) |
| 2023-11-06 12:04:26 +0100 | <mauke> | there's an implicit pure at the end of >>= |
| 2023-11-06 12:04:59 +0100 | <tomsmeding> | ah that might be it |
| 2023-11-06 12:05:03 +0100 | <int-e> | tomsmeding: sorry, I'm half ignoring Inst |
| 2023-11-06 12:05:25 +0100 | ezzieyguywuf | (~Unknown@user/ezzieyguywuf) (Ping timeout: 255 seconds) |
| 2023-11-06 12:06:13 +0100 | ezzieyguywuf | (~Unknown@user/ezzieyguywuf) |
| 2023-11-06 12:07:37 +0100 | pruiz | (~user@213.4.200.211) (Quit: ERC 5.5.0.29.1 (IRC client for GNU Emacs 29.1)) |
| 2023-11-06 12:09:07 +0100 | anon1123_ | (~anon1123@2a02:ab88:282:b00:da3a:ddff:fe3a:947c) |
| 2023-11-06 12:09:20 +0100 | idgaen | (~idgaen@2a01:e0a:498:fd50:fcc6:bb5d:489a:ce8c) (Quit: WeeChat 4.1.1) |
| 2023-11-06 12:10:39 +0100 | <Inst> | here's some weirdness, though |
| 2023-11-06 12:10:41 +0100 | <anon1123_> | today ive found this wiki page, i found it real funny how its no way useful and on point, but rather a sea of seething over a 25 years old language design decision: https://wiki.haskell.org/If-then-else |
| 2023-11-06 12:11:19 +0100 | <Inst> | > let !foo = 3 + undefined in 4 |
| 2023-11-06 12:11:21 +0100 | <lambdabot> | 4 |
| 2023-11-06 12:11:41 +0100 | <Inst> | > let !foo = 3 + undefined `seq` 4 in 4 |
| 2023-11-06 12:11:42 +0100 | <lambdabot> | 4 |
| 2023-11-06 12:11:53 +0100 | <Inst> | > let !foo = (3 + undefined) `seq` 4 in 4 |
| 2023-11-06 12:11:55 +0100 | <lambdabot> | 4 |
| 2023-11-06 12:12:18 +0100 | <probie> | > let !foo = (3 :: Int + undefined) in 4 |
| 2023-11-06 12:12:20 +0100 | <lambdabot> | error: |
| 2023-11-06 12:12:20 +0100 | <lambdabot> | Not in scope: type constructor or class ‘+’ |
| 2023-11-06 12:12:31 +0100 | <probie> | > let !foo = ((3 :: Int) + undefined) in 4 |
| 2023-11-06 12:12:32 +0100 | <lambdabot> | *Exception: Prelude.undefined |
| 2023-11-06 12:15:39 +0100 | <kuribas> | > let (!x, !y) = undefined in 1 |
| 2023-11-06 12:15:41 +0100 | <lambdabot> | 1 |
| 2023-11-06 12:15:56 +0100 | <kuribas> | > let !(x, y) = undefined in 1 |
| 2023-11-06 12:15:58 +0100 | <lambdabot> | *Exception: Prelude.undefined |
| 2023-11-06 12:16:08 +0100 | <probie> | The type of `3 + undefined` is `forall a . Num a => a`, which is a lambda abstraction, and a lambda abstraction is already in whnf |
| 2023-11-06 12:16:29 +0100 | <ncf> | anon1123_: perhaps the "see also" section should link to https://wiki.haskell.org/Wadler%27s_Law |
| 2023-11-06 12:17:25 +0100 | billchenchina | (~billchenc@2a0d:2580:ff0c:1:e3c9:c52b:a429:5bfe) |
| 2023-11-06 12:18:03 +0100 | <Inst> | it's some weirdness with typeclasses, isn't it? |
| 2023-11-06 12:18:55 +0100 | <Inst> | the way I understand it, (3 :: Int) + undefined routes to +# (iirc), which is a strict primitive |
| 2023-11-06 12:20:15 +0100 | <anon1123_> | ncf: haha, yeah. |
| 2023-11-06 12:20:22 +0100 | td_ | (~td@i53870926.versanet.de) |
| 2023-11-06 12:21:11 +0100 | <probie> | > let !foo = (undefined :: forall a . Num a => a) in 4 |
| 2023-11-06 12:21:12 +0100 | <lambdabot> | 4 |
| 2023-11-06 12:21:45 +0100 | <ncf> | > let !foo = (undefined :: Int) in 4 |
| 2023-11-06 12:21:46 +0100 | <int-e> | ncf: you could also link the if-then-else page from that one :P |
| 2023-11-06 12:21:47 +0100 | <lambdabot> | *Exception: Prelude.undefined |
| 2023-11-06 12:22:07 +0100 | <probie> | > let !foo = (undefined :: Int -> Int) in 4 |
| 2023-11-06 12:22:08 +0100 | <lambdabot> | *Exception: Prelude.undefined |
| 2023-11-06 12:22:31 +0100 | <int-e> | . o O ( "Examples" ) |
| 2023-11-06 12:22:59 +0100 | <kuribas> | In idris: "{a:Type} -> {auto _ : Num a} -> a", shows, that this is actually a function. |
| 2023-11-06 12:23:31 +0100 | <ncf> | > let !foo = (undefined :: forall a . a) in 4 |
| 2023-11-06 12:23:32 +0100 | <lambdabot> | *Exception: Prelude.undefined |
| 2023-11-06 12:23:48 +0100 | <ncf> | hm, so the constraint is messing with it |
| 2023-11-06 12:23:52 +0100 | <probie> | % :set -XTypeApplications |
| 2023-11-06 12:23:52 +0100 | <yahb2> | <no output> |
| 2023-11-06 12:23:56 +0100 | <Inst> | > let !foo = (undefined :: forall a . Show a => a) in 4 |
| 2023-11-06 12:23:58 +0100 | <lambdabot> | 4 |
| 2023-11-06 12:23:59 +0100 | <probie> | % let !foo = (undefined :: forall a . Num a => a) @Int in 4 |
| 2023-11-06 12:23:59 +0100 | <yahb2> | *** Exception: Prelude.undefined ; CallStack (from HasCallStack): ; error, called at libraries/base/GHC/Err.hs:74:14 in base:GHC.Err ; undefined, called at <interactive>:145:13 in interactive:G... |
| 2023-11-06 12:24:22 +0100 | <Inst> | > let !foo = (undefined :: forall a . Read a => a) in 4 |
| 2023-11-06 12:24:24 +0100 | <lambdabot> | 4 |
| 2023-11-06 12:24:34 +0100 | <Inst> | > let !foo = (undefined :: String) in 4 |
| 2023-11-06 12:24:36 +0100 | <lambdabot> | *Exception: Prelude.undefined |
| 2023-11-06 12:24:47 +0100 | <Inst> | so it looks like it's the typeclass mechanism :) |
| 2023-11-06 12:24:48 +0100 | <kuribas> | "3" is a function, where the instance is passed implicitly by the compiler. |
| 2023-11-06 12:24:57 +0100 | <kuribas> | :t 3 |
| 2023-11-06 12:24:58 +0100 | <lambdabot> | Num p => p |
| 2023-11-06 12:25:32 +0100 | <Inst> | > let !foo = (mempty <> undefined :: String) in 4 |
| 2023-11-06 12:25:33 +0100 | <lambdabot> | *Exception: Prelude.undefined |
| 2023-11-06 12:25:40 +0100 | <kuribas> | In idris you can actually pass an instance explicitly. |
| 2023-11-06 12:25:40 +0100 | <Inst> | > let !foo = (mempty <> undefined) in 4 |
| 2023-11-06 12:25:42 +0100 | <lambdabot> | 4 |
| 2023-11-06 12:26:02 +0100 | <kuribas> | In haskell you can only apply the type, which will cause the instance to be resolved. |
| 2023-11-06 12:26:12 +0100 | <kuribas> | (with XTypeApplications) |
| 2023-11-06 12:26:48 +0100 | <Inst> | > :set -XTypeApplications |
| 2023-11-06 12:26:49 +0100 | <kuribas> | tomsmeding: Things like this is why I find it often easier to reason about idris2. |
| 2023-11-06 12:26:50 +0100 | <lambdabot> | <hint>:1:1: error: parse error on input ‘:’ |
| 2023-11-06 12:27:09 +0100 | <Inst> | % :set -XTypeApplications |
| 2023-11-06 12:27:09 +0100 | <yahb2> | <no output> |
| 2023-11-06 12:27:24 +0100 | <Inst> | % let !foo = (mempty <> undefined) in 4 |
| 2023-11-06 12:27:24 +0100 | <yahb2> | 4 |
| 2023-11-06 12:27:26 +0100 | <tomsmeding> | one way to see that the "function-ness" of `Num a => a` is essential and a bang pattern will not, cannot, evaluate the "body" of that function: at what type should it evaluate the function? |
| 2023-11-06 12:27:37 +0100 | <Inst> | % let !foo = (mempty <> undefined) @String in 4 |
| 2023-11-06 12:27:37 +0100 | <yahb2> | <interactive>:151:12: error: ; • Cannot apply expression of type ‘a0’ ; to a visible type argument ‘String’ ; • In the expression: (mempty <> undefined) @String ; In an equation... |
| 2023-11-06 12:27:53 +0100 | <Inst> | % let !foo = (mempty @String <> undefined) in 4 |
| 2023-11-06 12:27:54 +0100 | <yahb2> | *** Exception: Prelude.undefined ; CallStack (from HasCallStack): ; error, called at libraries/base/GHC/Err.hs:74:14 in base:GHC.Err ; undefined, called at <interactive>:153:31 in interactive:G... |
| 2023-11-06 12:28:04 +0100 | <probie> | Wasn't this whole hidden lambda thing one of the driving motivators of simplified subsumption in ghc 9? |
| 2023-11-06 12:28:11 +0100 | <tomsmeding> | kuribas: yeah I see |
| 2023-11-06 12:29:45 +0100 | rosco | (~rosco@yp-150-69.tm.net.my) (Quit: Lost terminal) |
| 2023-11-06 12:31:51 +0100 | stiell | (~stiell@gateway/tor-sasl/stiell) (Remote host closed the connection) |
| 2023-11-06 12:32:12 +0100 | pretty_dumm_guy | (trottel@gateway/vpn/protonvpn/prettydummguy/x-88029655) |
| 2023-11-06 12:32:14 +0100 | stiell | (~stiell@gateway/tor-sasl/stiell) |
| 2023-11-06 12:43:58 +0100 | kenran | (~user@user/kenran) (Remote host closed the connection) |
| 2023-11-06 12:45:00 +0100 | billchenchina | (~billchenc@2a0d:2580:ff0c:1:e3c9:c52b:a429:5bfe) (Remote host closed the connection) |
| 2023-11-06 12:53:09 +0100 | danse-nr3 | (~danse@151.35.124.76) (Read error: Connection reset by peer) |
| 2023-11-06 12:53:26 +0100 | danse-nr3 | (~danse@151.35.114.112) |
| 2023-11-06 13:01:13 +0100 | danse-nr3 | (~danse@151.35.114.112) (Ping timeout: 260 seconds) |
| 2023-11-06 13:04:27 +0100 | doyougnu | (~doyougnu@45.46.170.68) |
| 2023-11-06 13:10:55 +0100 | stiell_ | (~stiell@gateway/tor-sasl/stiell) |
| 2023-11-06 13:11:03 +0100 | stiell | (~stiell@gateway/tor-sasl/stiell) (Remote host closed the connection) |
| 2023-11-06 13:17:14 +0100 | riatre | (~quassel@2001:310:6000:f::5198:1) (Server closed connection) |
| 2023-11-06 13:17:23 +0100 | riatre | (~quassel@2001:310:6000:f::5198:1) |
| 2023-11-06 13:20:09 +0100 | CO2 | (CO2@gateway/vpn/protonvpn/co2) |
| 2023-11-06 13:21:32 +0100 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:718b:eff8:b2d7:bbc8) (Ping timeout: 248 seconds) |
| 2023-11-06 13:29:41 +0100 | misterfish | (~misterfis@87.215.131.102) (Ping timeout: 240 seconds) |
| 2023-11-06 13:32:57 +0100 | danse-nr3 | (~danse@151.35.114.112) |
| 2023-11-06 13:37:52 +0100 | Lycurgus | (~georg@user/Lycurgus) |
| 2023-11-06 13:44:02 +0100 | Athas | (athas@2a01:7c8:aaac:1cf:6044:bd15:3f5b:9264) (Quit: ZNC 1.8.2 - https://znc.in) |
| 2023-11-06 13:44:15 +0100 | Athas | (athas@2a01:7c8:aaac:1cf:6044:bd15:3f5b:9264) |
| 2023-11-06 13:44:47 +0100 | anon1123 | (~anon1123@2a02:ab88:282:b00:da3a:ddff:fe3a:947c) |
| 2023-11-06 13:45:46 +0100 | anon1123 | (~anon1123@2a02:ab88:282:b00:da3a:ddff:fe3a:947c) (Client Quit) |
| 2023-11-06 13:47:56 +0100 | tom__ | (~tom@2a00:23c8:970c:4801:5b6a:e81b:79dc:f684) (Remote host closed the connection) |
| 2023-11-06 13:50:55 +0100 | arahael | (~arahael@119-18-2-212.771202.syd.nbn.aussiebb.net) (Ping timeout: 264 seconds) |
| 2023-11-06 14:01:00 +0100 | seeg123456 | (~seeg12345@64.176.64.83) (Quit: Gateway shutdown) |
| 2023-11-06 14:02:57 +0100 | seeg123456 | (~seeg12345@64.176.64.83) |
| 2023-11-06 14:11:49 +0100 | misterfish | (~misterfis@145.128.244.93) |
| 2023-11-06 14:12:01 +0100 | edr | (~edr@user/edr) |
| 2023-11-06 14:22:59 +0100 | Lycurgus | (~georg@user/Lycurgus) (Quit: leaving) |
| 2023-11-06 14:23:55 +0100 | rosco | (~rosco@yp-150-69.tm.net.my) |
| 2023-11-06 14:25:13 +0100 | idgaen | (~idgaen@2a01:e0a:498:fd50:fcc6:bb5d:489a:ce8c) |
| 2023-11-06 14:41:51 +0100 | falafel | (~falafel@62.175.113.194.dyn.user.ono.com) |
| 2023-11-06 14:46:20 +0100 | lortabac | (~lorenzo@2a01:e0a:541:b8f0:578c:5f9d:ee54:ec6a) (Ping timeout: 248 seconds) |
| 2023-11-06 14:47:05 +0100 | lortabac | (~lorenzo@2a01:e0a:541:b8f0:9468:20ae:8f18:260b) |
| 2023-11-06 14:49:40 +0100 | falafel | (~falafel@62.175.113.194.dyn.user.ono.com) (Ping timeout: 258 seconds) |
| 2023-11-06 14:55:58 +0100 | ChaiTRex | (~ChaiTRex@user/chaitrex) |
| 2023-11-06 15:00:45 +0100 | <EvanR> | Inst, bang patterns desugar to something using seq, so whether it's "operational" gets kicked down the road to the meaning of seq |
| 2023-11-06 15:01:37 +0100 | captnemo | (~captnemo@193.32.127.239) |
| 2023-11-06 15:01:48 +0100 | captnemo | (~captnemo@193.32.127.239) (Remote host closed the connection) |
| 2023-11-06 15:02:20 +0100 | <dminuoso> | > let !foo = (undefined :: forall a . Show a => a) in 4 |
| 2023-11-06 15:02:22 +0100 | <lambdabot> | 4 |
| 2023-11-06 15:02:29 +0100 | <dminuoso> | % let !foo = (undefined :: forall a . Num a => a) @Int in 4 |
| 2023-11-06 15:02:29 +0100 | <yahb2> | *** Exception: Prelude.undefined ; CallStack (from HasCallStack): ; error, called at libraries/base/GHC/Err.hs:74:14 in base:GHC.Err ; undefined, called at <interactive>:155:13 in interactive:G... |
| 2023-11-06 15:02:31 +0100 | <dminuoso> | I quite like this. |
| 2023-11-06 15:03:22 +0100 | <dminuoso> | tomsmeding: I guess conversely, this is all why we have monomorphism restriction, so the function-ness doesnt stab you in the back unexpectedly. |
| 2023-11-06 15:03:36 +0100 | <EvanR> | Inst, and if you want to puzzle that out, look up imprecise exceptions |
| 2023-11-06 15:06:39 +0100 | <Inst> | yeha i need to go over the Haskell exceptions system again |
| 2023-11-06 15:07:15 +0100 | <Inst> | i criticize dynamically typed programmers for not understanding how to go through all the cases, because they can't, but it's similarly reckless of me not to understand Haskell's exception system |
| 2023-11-06 15:07:26 +0100 | <EvanR> | also it's interesting when you get to STG, the let there explicitly has operational semantics |
| 2023-11-06 15:07:42 +0100 | <Inst> | and avoid GHCX- Pro Edition |
| 2023-11-06 15:07:43 +0100 | <EvanR> | so you're not far off |
| 2023-11-06 15:08:33 +0100 | <EvanR> | STG is a functional language with all these similar elements, but they mean something else there |
| 2023-11-06 15:08:39 +0100 | <EvanR> | similar to haskell |
| 2023-11-06 15:10:29 +0100 | Athas | (athas@2a01:7c8:aaac:1cf:6044:bd15:3f5b:9264) (Quit: ZNC 1.8.2 - https://znc.in) |
| 2023-11-06 15:11:17 +0100 | Athas | (~athas@2a01:7c8:aaac:1cf:6044:bd15:3f5b:9264) |
| 2023-11-06 15:25:40 +0100 | CO2 | (CO2@gateway/vpn/protonvpn/co2) (Quit: WeeChat 4.1.1) |
| 2023-11-06 15:26:10 +0100 | <dminuoso> | Inst: Haskells exception system is worse than most other exception systems. |
| 2023-11-06 15:26:26 +0100 | <dminuoso> | We have exception hierarchies, except poorly adopted and not well documented. |
| 2023-11-06 15:26:46 +0100 | <dminuoso> | And, whether its ignored or adopted - nobody really documents what exceptions can be thrown. |
| 2023-11-06 15:27:03 +0100 | <dminuoso> | And then there's the issue of IO exceptions, Either and the various effect systems. Every library does something else |
| 2023-11-06 15:27:25 +0100 | lortabac | (~lorenzo@2a01:e0a:541:b8f0:9468:20ae:8f18:260b) (Quit: WeeChat 3.5) |
| 2023-11-06 15:27:42 +0100 | <dminuoso> | While golang is extremely frustrating to work with explicitly testing return codes, at least the error mechanism is very uniform, |
| 2023-11-06 15:27:45 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2023-11-06 15:27:46 +0100 | <Inst> | in practice people just go to simulated exceptions to avoid throwing exceptions, no? |
| 2023-11-06 15:27:55 +0100 | <dminuoso> | Inst: Depends on the library, really. |
| 2023-11-06 15:28:19 +0100 | <dminuoso> | As soon as you enter IO, you have a wealth of IO exceptions that are thrown to you, often by transitive use. |
| 2023-11-06 15:28:30 +0100 | <dminuoso> | They rarely get caught/repacked. |
| 2023-11-06 15:30:38 +0100 | thegeekinside | (~thegeekin@189.141.80.123) |
| 2023-11-06 15:31:34 +0100 | <danse-nr3> | huh you mean go encodes failures in the result? |
| 2023-11-06 15:31:47 +0100 | hgolden | (~hgolden@2603-8000-9d00-3ed1-dd4f-298a-9c49-a0ed.res6.spectrum.com) (Remote host closed the connection) |
| 2023-11-06 15:32:03 +0100 | <danse-nr3> | like we could with Either? |
| 2023-11-06 15:33:30 +0100 | hgolden | (~hgolden@2603-8000-9d00-3ed1-dd4f-298a-9c49-a0ed.res6.spectrum.com) |
| 2023-11-06 15:34:08 +0100 | ystael | (~ystael@user/ystael) |
| 2023-11-06 15:35:03 +0100 | lortabac | (~lorenzo@2a01:e0a:541:b8f0:6ae1:edee:a8c:cfb9) |
| 2023-11-06 15:36:36 +0100 | <exarkun> | The trouble with IO is that too many things can go wrong. |
| 2023-11-06 15:37:09 +0100 | <exarkun> | Has anyone explored splitting IO into more fine-grained pieces where you could conceivably do something sensible for each of the things that could possibly go wrong? |
| 2023-11-06 15:37:41 +0100 | <exarkun> | Otherwise, it's hardly practical do more than check one or two specific things you can deal with and let everything else blow up the program. |
| 2023-11-06 15:38:01 +0100 | <tomsmeding> | danse-nr3: go code looks like this https://stackoverflow.com/questions/70509411/should-return-err-be-put-in-else-for-if-statement-wit… |
| 2023-11-06 15:38:05 +0100 | <tomsmeding> | that's manual Eithering |
| 2023-11-06 15:38:11 +0100 | <tomsmeding> | in a language without sum types, no less |
| 2023-11-06 15:38:29 +0100 | <danse-nr3> | yeah i came to the same conclusion from https://go.dev/doc/tutorial/handle-errors |
| 2023-11-06 15:39:10 +0100 | Shock_ | (~shOkEy@178-164-206-97.pool.digikabel.hu) (Ping timeout: 255 seconds) |
| 2023-11-06 15:40:58 +0100 | Shock_ | (~shOkEy@77-234-80-134.pool.digikabel.hu) |
| 2023-11-06 15:42:18 +0100 | CO2 | (CO2@gateway/vpn/protonvpn/co2) |
| 2023-11-06 15:43:27 +0100 | pavonia_ | (~user@user/siracusa) |
| 2023-11-06 15:43:43 +0100 | pavonia | (~user@user/siracusa) (Ping timeout: 264 seconds) |
| 2023-11-06 15:43:44 +0100 | Guest420 | (~Guest420@2607:fb91:f85:4d2:3d7e:6749:7ae0:78be) |
| 2023-11-06 15:43:56 +0100 | pavonia_ | pavonia |
| 2023-11-06 15:46:26 +0100 | bsima | (~bsima@2604:a880:400:d0::19f1:7001) (Quit: ZNC 1.8.2 - https://znc.in) |
| 2023-11-06 15:47:09 +0100 | bsima | (~bsima@143.198.118.179) |
| 2023-11-06 15:47:59 +0100 | Guest420 | (~Guest420@2607:fb91:f85:4d2:3d7e:6749:7ae0:78be) (Client Quit) |
| 2023-11-06 15:49:39 +0100 | kuribas | (~user@ip-188-118-57-242.reverse.destiny.be) (Quit: ERC (IRC client for Emacs 27.1)) |
| 2023-11-06 15:49:57 +0100 | kuribas | (~user@ip-188-118-57-242.reverse.destiny.be) |
| 2023-11-06 15:50:47 +0100 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:718b:eff8:b2d7:bbc8) |
| 2023-11-06 15:54:12 +0100 | dtman34 | (~dtman34@2601:447:d000:93c9:1930:f752:99bd:543d) (Ping timeout: 240 seconds) |
| 2023-11-06 15:55:59 +0100 | dtman34 | (~dtman34@c-76-156-89-180.hsd1.mn.comcast.net) |
| 2023-11-06 15:59:08 +0100 | <pounce> | it has 'some' types |
| 2023-11-06 16:01:00 +0100 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:718b:eff8:b2d7:bbc8) (Ping timeout: 248 seconds) |
| 2023-11-06 16:03:05 +0100 | ChaiTRex | (~ChaiTRex@user/chaitrex) (Remote host closed the connection) |
| 2023-11-06 16:04:36 +0100 | apache2 | (apache2@anubis.0x90.dk) (K-Lined) |
| 2023-11-06 16:07:55 +0100 | ChaiTRex | (~ChaiTRex@user/chaitrex) |
| 2023-11-06 16:10:04 +0100 | misterfish | (~misterfis@145.128.244.93) (Ping timeout: 248 seconds) |
| 2023-11-06 16:19:20 +0100 | billchenchina | (~billchenc@2a0d:2580:ff0c:1:e3c9:c52b:a429:5bfe) |
| 2023-11-06 16:24:06 +0100 | <dminuoso> | │15:36:36 exarkun │ The trouble with IO is that too many things can go wrong. │ Ankhers |
| 2023-11-06 16:24:12 +0100 | <dminuoso> | I dont believe this to be a fundamental problem. |
| 2023-11-06 16:24:39 +0100 | raehik | (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) (Ping timeout: 245 seconds) |
| 2023-11-06 16:24:46 +0100 | <dminuoso> | What maybe feels annoying about Java checked exceptions is just a call to reality. |
| 2023-11-06 16:25:23 +0100 | <dminuoso> | It's one of those things I wish we had in Haskell. |
| 2023-11-06 16:26:32 +0100 | <danse-nr3> | what is the advantage over Either? |
| 2023-11-06 16:28:05 +0100 | Logio | (em@kapsi.fi) (Server closed connection) |
| 2023-11-06 16:28:13 +0100 | Logio | (em@kapsi.fi) |
| 2023-11-06 16:29:01 +0100 | <exarkun> | danse-nr3: Well, you can't leave Either polymorphic and do anything very useful with the value |
| 2023-11-06 16:29:23 +0100 | <exarkun> | Oh or maybe you meant the advance of Java checked exceptions. |
| 2023-11-06 16:29:52 +0100 | <exarkun> | dminuoso: Yea I don't know if it is a fundamental problem. Or arguably must not be, since many Haskell programs prove useful in the real world. :) |
| 2023-11-06 16:30:11 +0100 | <EvanR> | extensible records with scoped labels contains a tangent discussion of extensible variants and its application to the Either way of dealing with untold number of kinds of exceptions at once |
| 2023-11-06 16:31:01 +0100 | raehik | (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) |
| 2023-11-06 16:31:02 +0100 | <EvanR> | meanwhile the language zig decided on an uberpragmatic single global error type that everything uses |
| 2023-11-06 16:31:15 +0100 | <EvanR> | that type is... an integer from 0 to 200 or so |
| 2023-11-06 16:31:34 +0100 | <danse-nr3> | ugh that's extreme |
| 2023-11-06 16:31:43 +0100 | <EvanR> | haha |
| 2023-11-06 16:32:09 +0100 | <danse-nr3> | not sure what is the polymorphism problem with Either, but if extensible records solve that, it is promising |
| 2023-11-06 16:33:22 +0100 | <EvanR> | extensible variants would let you combine an Either E1 a and an Either E2 a to get an Either <E1|E2> a. Solves it? good question |
| 2023-11-06 16:33:38 +0100 | waleee | (~waleee@h-176-10-144-38.NA.cust.bahnhof.se) |
| 2023-11-06 16:33:55 +0100 | <exarkun> | And then you can combine an `Either <E1|E2> a` with an `Either E3 a` to get an `Either <<E1|E2>|E3> a`! |
| 2023-11-06 16:34:12 +0100 | <EvanR> | yeah |
| 2023-11-06 16:34:14 +0100 | <exarkun> | It seems like it just automates the mess you can already make if you try to have a lot of exception types and merge them up? |
| 2023-11-06 16:35:07 +0100 | <EvanR> | there is some quality of life features possible for <<E1|E2>|E3> to make it easier to manage but the main thing is you didn't define any new types |
| 2023-11-06 16:35:21 +0100 | <EvanR> | similar to extensible records |
| 2023-11-06 16:35:48 +0100 | <danse-nr3> | "extensible records" ... i would call that an anonymous sum type |
| 2023-11-06 16:36:24 +0100 | <exarkun> | EvanR: ah |
| 2023-11-06 16:36:28 +0100 | <EvanR> | also there is the dual to row polymorphism |
| 2023-11-06 16:36:32 +0100 | <EvanR> | involved |
| 2023-11-06 16:36:59 +0100 | <danse-nr3> | i think i have read from Gabriella Gonzales that haskell is "heavily nominal"? Maybe i get that, since anonymous sum types seem so hard to reach |
| 2023-11-06 16:37:05 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2023-11-06 16:37:10 +0100 | <EvanR> | this function could throw an E or some other unknown type of error |
| 2023-11-06 16:37:40 +0100 | <EvanR> | according to a type signature |
| 2023-11-06 16:39:13 +0100 | <EvanR> | and yeah record types are anonymous product types with fields |
| 2023-11-06 16:39:55 +0100 | <EvanR> | the extensible records with scoped labels paper uses labels for the extensible variants, which is why it even comes up |
| 2023-11-06 16:43:18 +0100 | ChaiTRex | (~ChaiTRex@user/chaitrex) (Remote host closed the connection) |
| 2023-11-06 16:43:21 +0100 | Square | (~Square@user/square) |
| 2023-11-06 16:43:42 +0100 | ChaiTRex | (~ChaiTRex@user/chaitrex) |
| 2023-11-06 16:53:29 +0100 | danse-nr3 | (~danse@151.35.114.112) (Read error: Connection reset by peer) |
| 2023-11-06 16:54:22 +0100 | danse-nr3 | (~danse@151.37.110.121) |
| 2023-11-06 16:55:43 +0100 | <EvanR> | liftA2 is a method in the Applicative class now, mind blown |
| 2023-11-06 16:57:51 +0100 | <danse-nr3> | what was it before? |
| 2023-11-06 16:58:06 +0100 | <mauke> | freestanding |
| 2023-11-06 16:58:08 +0100 | <EvanR> | just a library function defined in terms of pure and <*> |
| 2023-11-06 16:58:25 +0100 | <EvanR> | @src liftA2 |
| 2023-11-06 16:58:25 +0100 | <lambdabot> | liftA2 f a b = f <$> a <*> b |
| 2023-11-06 16:58:37 +0100 | <EvanR> | or that |
| 2023-11-06 16:58:38 +0100 | <ddellacosta> | does that mean it existed before Applicative was a thing? |
| 2023-11-06 16:58:40 +0100 | <danse-nr3> | "This became a typeclass method in 4.10.0.0" |
| 2023-11-06 16:58:44 +0100 | <ddellacosta> | huh |
| 2023-11-06 16:58:46 +0100 | <ddellacosta> | TIL |
| 2023-11-06 16:59:10 +0100 | <mauke> | @src liftM2 |
| 2023-11-06 16:59:10 +0100 | <lambdabot> | liftM2 f m1 m2 = do |
| 2023-11-06 16:59:10 +0100 | <lambdabot> | x1 <- m1 |
| 2023-11-06 16:59:10 +0100 | <lambdabot> | x2 <- m2 |
| 2023-11-06 16:59:10 +0100 | <lambdabot> | return (f x1 x2) |
| 2023-11-06 16:59:36 +0100 | <danse-nr3> | i find `f <$> a <*> b` more readable most of the times anyways |
| 2023-11-06 16:59:38 +0100 | <c_wraith> | oh no! don't compile that with -XApplicativeDo! |
| 2023-11-06 16:59:49 +0100 | <EvanR> | so yeah it existed in the form of a monad routine |
| 2023-11-06 17:00:11 +0100 | <ddellacosta> | danse-nr3: yeah same |
| 2023-11-06 17:00:39 +0100 | <danse-nr3> | but probably there are usages for when one wants to pass the lifted on |
| 2023-11-06 17:00:43 +0100 | <EvanR> | liftA2 f is handy if you need to pass someone a (binary) function |
| 2023-11-06 17:05:36 +0100 | <EvanR> | ¶ |
| 2023-11-06 17:05:44 +0100 | <EvanR> | it is written somewhere in a haddock for a well known package that Functor provides substitution and Monad provides, on top of that, "renormalization". What pithy thing could you say Applicative provides? |
| 2023-11-06 17:06:47 +0100 | misterfish | (~misterfis@84-53-85-146.bbserv.nl) |
| 2023-11-06 17:06:51 +0100 | gmg | (~user@user/gehmehgeh) (Remote host closed the connection) |
| 2023-11-06 17:07:10 +0100 | <danse-nr3> | just to expand on the nonsense? |
| 2023-11-06 17:07:17 +0100 | Athas | (~athas@2a01:7c8:aaac:1cf:6044:bd15:3f5b:9264) (Quit: ZNC 1.8.2 - https://znc.in) |
| 2023-11-06 17:07:32 +0100 | gmg | (~user@user/gehmehgeh) |
| 2023-11-06 17:07:40 +0100 | <EvanR> | is it nonsense |
| 2023-11-06 17:09:06 +0100 | <danse-nr3> | the definitions given above do not sound particularly enlightening to me, but maybe i ignore the context where those terms make more sense |
| 2023-11-06 17:09:09 +0100 | <ddellacosta> | it's hard, I feel like it's basically about letting you execute operations in a context, without as much power as Monad, but that's not pithy |
| 2023-11-06 17:09:25 +0100 | <ddellacosta> | and depends on talking about other concepts |
| 2023-11-06 17:09:48 +0100 | <exarkun> | who benefits from such pithy descriptions |
| 2023-11-06 17:09:49 +0100 | <int-e> | eww, they made abstract burritos |
| 2023-11-06 17:10:02 +0100 | <exarkun> | either you already know what it is, in which case you don't, or you don't already know what it is, in which case you don't |
| 2023-11-06 17:10:02 +0100 | <ddellacosta> | exarkun: yeah good point |
| 2023-11-06 17:10:03 +0100 | <EvanR> | it's a big pith conspiracy |
| 2023-11-06 17:10:37 +0100 | <danse-nr3> | pithy is good for business |
| 2023-11-06 17:11:06 +0100 | <exarkun> | not sure pithy replaces a nice $900 suit |
| 2023-11-06 17:14:59 +0100 | <isekaijin> | EvanR: I thought that, for an expression type “data Expr a = Var a | ...”, the “instance Monad Expr where ...” was the one that gave you the ability to substitute a variable with another subexpression? |
| 2023-11-06 17:16:40 +0100 | <EvanR> | Functor lets you substitute to get an Expr (Expr a) then the monad lets you flatten that to get a Expr a again |
| 2023-11-06 17:17:20 +0100 | <EvanR> | for instance by throwing away the Var wrapper |
| 2023-11-06 17:17:27 +0100 | <danse-nr3> | :t join |
| 2023-11-06 17:17:28 +0100 | <lambdabot> | Monad m => m (m a) -> m a |
| 2023-11-06 17:19:29 +0100 | <EvanR> | fmap :: (String -> Expr String) -> Expr String -> Expr (Expr String) |
| 2023-11-06 17:20:47 +0100 | lortabac | (~lorenzo@2a01:e0a:541:b8f0:6ae1:edee:a8c:cfb9) (Quit: WeeChat 3.5) |
| 2023-11-06 17:26:20 +0100 | qqq | (~qqq@92.43.167.61) (Remote host closed the connection) |
| 2023-11-06 17:32:41 +0100 | Square | (~Square@user/square) (Ping timeout: 240 seconds) |
| 2023-11-06 17:35:38 +0100 | Athas | (athas@2a01:7c8:aaac:1cf:d300:623e:69e4:545f) |
| 2023-11-06 17:37:33 +0100 | <kiriakos> | Is it possible to ask hoogle about typeclasses that require a specific signature to be implemented? |
| 2023-11-06 17:37:47 +0100 | targetdisk | (~daemonchi@45-33-4-162.ip.linodeusercontent.com) (Server closed connection) |
| 2023-11-06 17:37:56 +0100 | targetdisk | (~daemonchi@45-33-4-162.ip.linodeusercontent.com) |
| 2023-11-06 17:39:07 +0100 | <Athas> | If you search for the method type, won't you find any relevant classes? |
| 2023-11-06 17:39:10 +0100 | <danse-nr3> | well, `(a -> b) -> f a -> f b` gives me `<$>` among the results |
| 2023-11-06 17:43:54 +0100 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:718b:eff8:b2d7:bbc8) |
| 2023-11-06 17:45:43 +0100 | _ht | (~Thunderbi@28-52-174-82.ftth.glasoperator.nl) |
| 2023-11-06 17:47:30 +0100 | lisbeths | (uid135845@id-135845.lymington.irccloud.com) (Quit: Connection closed for inactivity) |
| 2023-11-06 17:52:14 +0100 | erty | (~user@user/aeroplane) |
| 2023-11-06 17:54:07 +0100 | [exa] | (~exa@user/exa/x-3587197) (Remote host closed the connection) |
| 2023-11-06 17:54:47 +0100 | Lycurgus | (~georg@li1192-118.members.linode.com) |
| 2023-11-06 17:54:47 +0100 | Lycurgus | (~georg@li1192-118.members.linode.com) (Changing host) |
| 2023-11-06 17:54:47 +0100 | Lycurgus | (~georg@user/Lycurgus) |
| 2023-11-06 18:01:01 +0100 | misterfish | (~misterfis@84-53-85-146.bbserv.nl) (Ping timeout: 240 seconds) |
| 2023-11-06 18:05:08 +0100 | <monochrom> | EvanR: Perhaps Functor provides unary substitution, Applicative provides 0-ary and 2-ary substitution? |
| 2023-11-06 18:06:55 +0100 | <EvanR> | applicative is sort of monoiding things together, you start with two "applicatives" and end up with one |
| 2023-11-06 18:07:32 +0100 | <monochrom> | There is also that. Applicative is found to be lax monoidal something. |
| 2023-11-06 18:08:10 +0100 | <EvanR> | also I only just realized the preponderance of this language: value of type f x is "a functor", or "an applicative", in one case it's "a traversable", instead of "a whateveric value" |
| 2023-11-06 18:08:23 +0100 | <EvanR> | it's all over the blogosphere |
| 2023-11-06 18:08:34 +0100 | Lycurgus | (~georg@user/Lycurgus) (Quit: leaving) |
| 2023-11-06 18:09:01 +0100 | <EvanR> | an m a is even "a monad" sometimes D: |
| 2023-11-06 18:09:07 +0100 | <monochrom> | Yeah natural languages and COBOL are hard. :) |
| 2023-11-06 18:09:47 +0100 | <monochrom> | Logic and axiomatic systems are so much easier. |
| 2023-11-06 18:10:41 +0100 | waleee | (~waleee@h-176-10-144-38.NA.cust.bahnhof.se) (Ping timeout: 240 seconds) |
| 2023-11-06 18:11:00 +0100 | misterfish | (~misterfis@84-53-85-146.bbserv.nl) |
| 2023-11-06 18:11:06 +0100 | <EvanR> | in another universe this one really threw me into a spin, a struct value / record value / or dumb object with just fields was referred to as "a type" D: |
| 2023-11-06 18:11:36 +0100 | <EvanR> | clojure universe |
| 2023-11-06 18:11:43 +0100 | <monochrom> | haha |
| 2023-11-06 18:12:03 +0100 | <dolio> | Records are the values. |
| 2023-11-06 18:12:07 +0100 | <int-e> | . o O ( typewriter ) |
| 2023-11-06 18:15:08 +0100 | <ddellacosta> | I suppose to give them the benefit of the doubt, they may be thinking of prototypal inheritance? 😅 https://en.wikipedia.org/wiki/Prototype-based_programming |
| 2023-11-06 18:15:51 +0100 | <monochrom> | It is tough. If you have "x :: Num a => a", what do you call x? It is reasonable to say "x is a number". Now "number" is spelt slightly different from "Num", there seems to be no clash. But in another time line it is also very plausible that the other committee names the type class "Number". So now if "x :: Number a => a", then x is a lowercase("Number") too. I bet people are reasoning along the same line for Monad etc. |
| 2023-11-06 18:16:31 +0100 | <kuribas> | x could be a function |
| 2023-11-06 18:16:37 +0100 | <exarkun> | "x is a value of a type with a Num instance" is quite a mouthful. |
| 2023-11-06 18:16:48 +0100 | <exarkun> | "x is a number" is a desire path |
| 2023-11-06 18:17:02 +0100 | <EvanR> | x is "a Num" ? xD |
| 2023-11-06 18:17:32 +0100 | <EvanR> | this is a bit outside the pattern above since there's no * -> * type constructor |
| 2023-11-06 18:18:01 +0100 | machinedgod | (~machinedg@d198-53-218-113.abhsia.telus.net) (Ping timeout: 240 seconds) |
| 2023-11-06 18:18:23 +0100 | <monochrom> | If "Monad" were spelled "MonadClass" instead, then there would be no clash between "the value is a monad" and "the type is a MonadClass". But we didn't go there. (And I support not going there. Type-level hungarian notation?! Thanks but no thanks.) |
| 2023-11-06 18:18:51 +0100 | <EvanR> | IsString a, "x is an IsString" |
| 2023-11-06 18:19:09 +0100 | <monochrom> | Then again "the value is a monad" is wrong mathematically. Yeah, about the * -> * kind. |
| 2023-11-06 18:20:45 +0100 | <dolio> | ncf: BTW, I think the (co)yoneda lemma from that (co)free angle is basically that there is a correspondence between functors and isomorphisms F ≅ (Co)Yoneda F. Does that resolve your issue? |
| 2023-11-06 18:21:05 +0100 | <EvanR> | also we're being inconsistent with the declensions, you got your Applicative (functor) you got your Traversable (functor) you got your Representable (functor) etc but not your Monadic (functor) |
| 2023-11-06 18:21:24 +0100 | chele | (~chele@user/chele) (Remote host closed the connection) |
| 2023-11-06 18:21:56 +0100 | <monochrom> | Yeah OOP may also have biased people. If x ∈ C1 ⊆ C2, then both of "x is a C1" and "x is a C2" are acceptable. And OOP uses ⊆ to emulate our type classes. |
| 2023-11-06 18:22:21 +0100 | kuribas | (~user@ip-188-118-57-242.reverse.destiny.be) (Quit: ERC (IRC client for Emacs 27.1)) |
| 2023-11-06 18:22:31 +0100 | <monochrom> | The extra fun being "C1 is a C2" is also acceptable. >:) |
| 2023-11-06 18:22:41 +0100 | <dolio> | The arrow mappings correspond to (co)algebra structures, and that is the missing part of an isomorphism like that in general, I think. |
| 2023-11-06 18:23:27 +0100 | <EvanR> | C1 is a C2 can't be right |
| 2023-11-06 18:23:44 +0100 | <danse-nr3> | why? |
| 2023-11-06 18:24:00 +0100 | <EvanR> | kind mismatch! |
| 2023-11-06 18:24:07 +0100 | <danse-nr3> | XD i knew! |
| 2023-11-06 18:24:50 +0100 | <monochrom> | I think mathematicians also have their share of defining "monadic functor" to be different from "monad". |
| 2023-11-06 18:26:34 +0100 | <erty> | Sorry to bump in but I just have a simple question. If I have a class, [class SomeNumbers a where...] and an instance [instance SomeNumbers a where...], here I want to apply 'Num' constraint to 'a'. Where can I specify that? Thanks |
| 2023-11-06 18:27:28 +0100 | <exarkun> | You want to make an instance for all a where there is a Num instance for a? |
| 2023-11-06 18:27:49 +0100 | <erty> | I expect 'a' to always be a number |
| 2023-11-06 18:27:59 +0100 | <EvanR> | instance SomeNumbers a where -- would be defining the instance for all types ever? |
| 2023-11-06 18:28:06 +0100 | <exarkun> | `instance Num a => SomeNumbers a where ...`? |
| 2023-11-06 18:28:18 +0100 | <EvanR> | and that Num a constraint won't help |
| 2023-11-06 18:28:52 +0100 | <danse-nr3> | so probably it is for the class... strange question though |
| 2023-11-06 18:29:07 +0100 | zetef | (~quassel@5.2.182.98) |
| 2023-11-06 18:29:11 +0100 | <danse-nr3> | usually the constraint comes up naturally where you need a class' functions |
| 2023-11-06 18:29:23 +0100 | <EvanR> | sounds like you just want to define some functions that work on any Num |
| 2023-11-06 18:29:55 +0100 | <EvanR> | instead of a new class |
| 2023-11-06 18:30:48 +0100 | <monochrom> | You should not. Use a newtype wrapper. See for example Sum and Product. |
| 2023-11-06 18:31:00 +0100 | rosco | (~rosco@yp-150-69.tm.net.my) (Quit: Lost terminal) |
| 2023-11-06 18:31:01 +0100 | <danse-nr3> | :t Sum |
| 2023-11-06 18:31:03 +0100 | <lambdabot> | a -> Sum a |
| 2023-11-06 18:31:04 +0100 | <erty> | :EvanR yes |
| 2023-11-06 18:31:37 +0100 | <danse-nr3> | :i Sum |
| 2023-11-06 18:31:38 +0100 | <monochrom> | "instance Num a => Monoid (Sum a)" not "instance Num a => Monoid a". |
| 2023-11-06 18:31:54 +0100 | <danse-nr3> | > :i Sum |
| 2023-11-06 18:31:56 +0100 | <lambdabot> | <hint>:1:1: error: parse error on input ‘:’ |
| 2023-11-06 18:32:02 +0100 | <danse-nr3> | % :i Sum |
| 2023-11-06 18:32:03 +0100 | <yahb2> | <interactive>:1:1: error: Not in scope: ‘Sum’ |
| 2023-11-06 18:32:28 +0100 | <geekosaur> | % import Data.Monoid |
| 2023-11-06 18:32:28 +0100 | <yahb2> | <no output> |
| 2023-11-06 18:32:33 +0100 | <geekosaur> | % :i Sum |
| 2023-11-06 18:32:33 +0100 | <yahb2> | type Sum :: * -> * ; newtype Sum a = Sum {getSum :: a} ; -- Defined in ‘base-4.16.4.0:Data.Semigroup.Internal’ ; instance Applicative Sum ; -- Defined in ‘base-4.16.4.0:Data.Semigroup.Internal... |
| 2023-11-06 18:32:44 +0100 | <danse-nr3> | cheers geekosaur ^^; |
| 2023-11-06 18:32:58 +0100 | <erty> | :t Product |
| 2023-11-06 18:32:59 +0100 | <lambdabot> | a -> Product a |
| 2023-11-06 18:33:15 +0100 | <danse-nr3> | % :i Product |
| 2023-11-06 18:33:16 +0100 | <yahb2> | type Product :: * -> * ; newtype Product a = Product {getProduct :: a} ; -- Defined in ‘base-4.16.4.0:Data.Semigroup.Internal’ ; instance Applicative Product ; -- Defined in ‘base-4.16.4.0:Dat... |
| 2023-11-06 18:33:32 +0100 | Putonlalla | (~Putonlall@it-cyan.it.jyu.fi) (Server closed connection) |
| 2023-11-06 18:33:54 +0100 | Putonlalla | (~Putonlall@it-cyan.it.jyu.fi) |
| 2023-11-06 18:34:18 +0100 | <EvanR> | ok then, erty what is in the SomeNumbers class |
| 2023-11-06 18:34:22 +0100 | <ncf> | dolio: not seeing it. coalgebras for what functor? |
| 2023-11-06 18:34:42 +0100 | ph88 | (~ph88@2a02:8109:9e26:c800::302a) (Quit: Leaving) |
| 2023-11-06 18:35:24 +0100 | <erty> | EvanR: I just randomly came up with that name. I just want to create a set of functions which would only accept numbers (float,int etc.) |
| 2023-11-06 18:35:51 +0100 | <EvanR> | well just for that you don't need a class |
| 2023-11-06 18:35:54 +0100 | <geekosaur> | that sounds like a Num constraint on the function |
| 2023-11-06 18:35:57 +0100 | <geekosaur> | (s) |
| 2023-11-06 18:36:28 +0100 | AlexZenon | (~alzenon@178.34.161.199) (Ping timeout: 272 seconds) |
| 2023-11-06 18:36:50 +0100 | <geekosaur> | beware, thinking like OOP won't get you very far in Haskell, the types don't work that way |
| 2023-11-06 18:36:52 +0100 | <erty> | ok, i got it. Its better to use newType in this case. |
| 2023-11-06 18:37:19 +0100 | <EvanR> | what is the newtype for |
| 2023-11-06 18:37:30 +0100 | <exarkun> | erty: no, if you want a function that works on a Num, then `f :: Num a => a -> whatever` |
| 2023-11-06 18:38:38 +0100 | gdown | (~gavin@h69-11-149-109.kndrid.broadband.dynamic.tds.net) |
| 2023-11-06 18:39:32 +0100 | <danse-nr3> | coming from object oriented one feels too loose this way. At least a newtype provides some idea of encapsulation =D |
| 2023-11-06 18:39:59 +0100 | <EvanR> | you can encapsulate your set of functions in a module |
| 2023-11-06 18:40:17 +0100 | <exarkun> | But of course the feeling will lead you astray, because Haskell is not a class-oriented OO language. |
| 2023-11-06 18:40:21 +0100 | tzh | (~tzh@c-71-193-181-0.hsd1.or.comcast.net) |
| 2023-11-06 18:40:41 +0100 | econo_ | (uid147250@id-147250.tinside.irccloud.com) |
| 2023-11-06 18:41:13 +0100 | <dolio> | ncf: Coalgebras of Yoneda, or algebras of Coyoneda. |
| 2023-11-06 18:41:53 +0100 | <EvanR> | or is it? Haskell's overlooked object system |
| 2023-11-06 18:42:04 +0100 | <EvanR> | 2005 |
| 2023-11-06 18:42:30 +0100 | CO2 | (CO2@gateway/vpn/protonvpn/co2) (Quit: WeeChat 4.1.1) |
| 2023-11-06 18:42:52 +0100 | <geekosaur> | most of those miss one or more points of OOP, don't they? similarly the modeling of (some) OOP features using comonads |
| 2023-11-06 18:43:09 +0100 | CO2 | (CO2@gateway/vpn/protonvpn/co2) |
| 2023-11-06 18:44:05 +0100 | <erty> | Ok, This is a very minimal example that I've created, 'a' is always a String. THis is giving me errors. How can I correct it? |
| 2023-11-06 18:44:09 +0100 | <erty> | http://ix.io/4KR7/haskell |
| 2023-11-06 18:44:12 +0100 | iteratee_ | (~kyle@162.218.222.207) (Quit: leaving) |
| 2023-11-06 18:44:23 +0100 | AlexZenon | (~alzenon@178.34.161.199) |
| 2023-11-06 18:44:34 +0100 | <exarkun> | You don't _know_ a is always String |
| 2023-11-06 18:44:41 +0100 | zetef | (~quassel@5.2.182.98) (Read error: Connection reset by peer) |
| 2023-11-06 18:44:57 +0100 | <geekosaur> | that's not how typeclasses work. `instance Eyes a where` declares the instance to be for every type |
| 2023-11-06 18:45:10 +0100 | jrm | (~jrm@user/jrm) (Quit: ciao) |
| 2023-11-06 18:45:23 +0100 | <geekosaur> | `instance Eyes String where` declares an instance for Strings |
| 2023-11-06 18:45:46 +0100 | <danse-nr3> | recently i realised existential types are a great resource for object-oriented thinking, check them out erty: wiki.haskell.org/Existential_type |
| 2023-11-06 18:46:12 +0100 | <tomsmeding> | danse-nr3: someone who doesn't grok instances yet is _not_ going to be a good person to throw existential types at |
| 2023-11-06 18:46:31 +0100 | <geekosaur> | ^ |
| 2023-11-06 18:46:42 +0100 | <danse-nr3> | hum ... yeah you are probably right |
| 2023-11-06 18:46:48 +0100 | jrm | (~jrm@user/jrm) |
| 2023-11-06 18:47:28 +0100 | <danse-nr3> | but then people like to jump at monad transformers without much understanding of other aspects... everyone is different |
| 2023-11-06 18:48:15 +0100 | <EvanR> | sympathy to those who get a job at a haskell shop and the first thing they need to learn is lens xD |
| 2023-11-06 18:48:31 +0100 | <exarkun> | could be worse |
| 2023-11-06 18:48:33 +0100 | koolazer | (~koo@user/koolazer) (Server closed connection) |
| 2023-11-06 18:48:50 +0100 | <tomsmeding> | exarkun: could also be servant, you mean? |
| 2023-11-06 18:48:51 +0100 | thegman | (~thegman@072-239-207-086.res.spectrum.com) |
| 2023-11-06 18:48:53 +0100 | <exarkun> | :) |
| 2023-11-06 18:48:55 +0100 | koolazer | (~koo@user/koolazer) |
| 2023-11-06 18:49:05 +0100 | <erty> | geekosaur: Sorry for that mistake, But what if I expect 'a' to be anyof the Num instanes |
| 2023-11-06 18:49:08 +0100 | <tomsmeding> | (disclaimer, I haven't ever actually used servant) |
| 2023-11-06 18:49:09 +0100 | <exarkun> | actually I was going to say something about profunctors but then I remembered they are a dependency of lens, so. |
| 2023-11-06 18:49:20 +0100 | <mauke> | EvanR: lens was the second thing. the first thing was streaming |
| 2023-11-06 18:49:22 +0100 | <mauke> | also pipes |
| 2023-11-06 18:49:25 +0100 | <exarkun> | (servant was one of the first serious haskell libraries I used while learning haskell, though) |
| 2023-11-06 18:49:51 +0100 | <danse-nr3> | where by "serious" we can freely interpret "painful" |
| 2023-11-06 18:50:10 +0100 | <exarkun> | pain is just weakness leaving the body, etc |
| 2023-11-06 18:50:11 +0100 | <geekosaur> | `instance Num a => Cat a where` — with the caveat that this locks you out of all other possible types, because `Num a` has to be checked at the use site |
| 2023-11-06 18:50:57 +0100 | <geekosaur> | (every possible `a` has to carry around proof that it is a `Num` instance) |
| 2023-11-06 18:51:52 +0100 | <danse-nr3> | see, problem missing with existentials! :P |
| 2023-11-06 18:52:39 +0100 | pixelmonk | (~pixelmonk@173.46.79.26) |
| 2023-11-06 18:52:44 +0100 | <tomsmeding> | erty: in other words, you can only make instances for "types with a particular shape". An instance for 'a' is "all types"; 'String' is "just String". You can also make an instance for 'Maybe a', which is Maybe Int, Maybe String, Maybe Bool, etc. |
| 2023-11-06 18:53:16 +0100 | <tomsmeding> | Within those shapes, you can also add further _constraints_ for which types of that shape are _actually_ valid; this is the 'Num a =>' that geekosaur suggested |
| 2023-11-06 18:53:44 +0100 | <tomsmeding> | but you can't give one instance for "all types satisfying Num", another instance for "all types satisfying Ord", etc. |
| 2023-11-06 18:53:51 +0100 | pixelmonk | (~pixelmonk@173.46.79.26) (Client Quit) |
| 2023-11-06 18:53:59 +0100 | <tomsmeding> | that's a result of the design of haskell typeclasses |
| 2023-11-06 18:53:59 +0100 | <EvanR> | .oO( if the Eyes class defines stuff eyes-supporting types, and cats and dogs are types... then instance Eyes Cat where, and instance Eyes Dog where seems cromulent. Of course that's super vague ) |
| 2023-11-06 18:54:08 +0100 | <EvanR> | stuff for |
| 2023-11-06 18:54:43 +0100 | <tomsmeding> | erty: the underlying idea is that if someone writes make a new instance of some typeclass, then code that worked should continue working |
| 2023-11-06 18:55:01 +0100 | <tomsmeding> | (this is a certain form of "monotonicity", if you're a mathematician) |
| 2023-11-06 18:56:00 +0100 | <tomsmeding> | if you could do what I described, one instance for all types satisfying Num, one instance for all types satisfying Ord, etc., then you'd break that monotonicity property: once someone makes a type _both_ an instance of Num and of Ord, your code breaks because which instance is to be used? |
| 2023-11-06 18:56:08 +0100 | <tomsmeding> | so we don't allow that at all |
| 2023-11-06 18:56:54 +0100 | <tomsmeding> | (if anyone brings up -XIncoherentInstances now they can fuck off, that's explicitly breaking the rules) |
| 2023-11-06 18:57:20 +0100 | <EvanR> | you just told yourself to fuck off |
| 2023-11-06 18:57:20 +0100 | <tomsmeding> | (and may not even help here) |
| 2023-11-06 18:57:21 +0100 | <geekosaur> | I think it's still rejected even then |
| 2023-11-06 18:57:23 +0100 | <tomsmeding> | yes |
| 2023-11-06 18:57:29 +0100 | <danse-nr3> | interesting i do not see monotonicity there. That is what makes a function reversable most of the times? |
| 2023-11-06 18:57:31 +0100 | <tomsmeding> | yeah, just realised |
| 2023-11-06 18:57:40 +0100 | <erty> | tomsmeding: Thanks for all those points, I will take some time and analyze |
| 2023-11-06 18:57:50 +0100 | <tomsmeding> | danse-nr3: monotonicity in that given more information about types (more instances), things only become more defined, not less |
| 2023-11-06 18:58:02 +0100 | <danse-nr3> | oh, i see |
| 2023-11-06 18:58:09 +0100 | <tomsmeding> | erty: good luck! This is probably unfamiliar terrain for you, but it's cool stuff once you get used to it :) |
| 2023-11-06 18:58:29 +0100 | <danse-nr3> | more instances do not change class information much though |
| 2023-11-06 18:58:52 +0100 | <tomsmeding> | danse-nr3: hm? |
| 2023-11-06 18:59:20 +0100 | <tomsmeding> | if the described situation (overlapping Num a => a and Ord a => a instances) would be allowed, more instances could make programs ill-defined because it could become ambiguous which instance to use |
| 2023-11-06 18:59:56 +0100 | <danse-nr3> | nevermind, i did not follow carefully enough |
| 2023-11-06 19:00:01 +0100 | <danse-nr3> | thanks anyway |
| 2023-11-06 19:00:10 +0100 | <tomsmeding> | :) |
| 2023-11-06 19:00:12 +0100 | <geekosaur> | worse, if the instances are defined in different modules then which one is used depende on what you have imported |
| 2023-11-06 19:00:21 +0100 | <tomsmeding> | right, also that |
| 2023-11-06 19:00:43 +0100 | <tomsmeding> | but that's not quite the same consistency property that's being preserved there |
| 2023-11-06 19:00:44 +0100 | <EvanR> | isn't that the case anyway |
| 2023-11-06 19:01:00 +0100 | pixelmonk | (~pixelmonk@173.46.79.26) |
| 2023-11-06 19:01:07 +0100 | <EvanR> | without overlapping |
| 2023-11-06 19:01:16 +0100 | <tomsmeding> | EvanR: the rules for instances, absent OverlappingInstances stuff, imply that that cannot happen -- or importing the two modules together would error |
| 2023-11-06 19:01:33 +0100 | <tomsmeding> | I guess that's not quite monotone, true |
| 2023-11-06 19:01:40 +0100 | <tomsmeding> | importing more stuff makes the program less defined |
| 2023-11-06 19:01:41 +0100 | <EvanR> | oh oh, orphan instances not allowed |
| 2023-11-06 19:01:48 +0100 | <tomsmeding> | oh! |
| 2023-11-06 19:01:50 +0100 | <tomsmeding> | yes |
| 2023-11-06 19:01:51 +0100 | <tomsmeding> | thank you |
| 2023-11-06 19:01:51 +0100 | pixelmonk | (~pixelmonk@173.46.79.26) (Client Quit) |
| 2023-11-06 19:02:59 +0100 | pixelmonk2 | (~pixelmonk@173.46.79.26) |
| 2023-11-06 19:03:30 +0100 | pixelmonk2 | (~pixelmonk@173.46.79.26) (Client Quit) |
| 2023-11-06 19:03:30 +0100 | pavonia | (~user@user/siracusa) (Quit: Bye!) |
| 2023-11-06 19:03:45 +0100 | pixelmonk | (~pixelmonk@173.46.79.26) |
| 2023-11-06 19:04:01 +0100 | raehik | (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) (Ping timeout: 240 seconds) |
| 2023-11-06 19:05:23 +0100 | pixelmonk | (~pixelmonk@173.46.79.26) (Client Quit) |
| 2023-11-06 19:05:37 +0100 | pixelmonk | (~pixelmonk@173.46.79.26) |
| 2023-11-06 19:09:12 +0100 | pixelmonk | (~pixelmonk@173.46.79.26) (Client Quit) |
| 2023-11-06 19:09:31 +0100 | pixelmonk | (~pixelmonk@173.46.79.26) |
| 2023-11-06 19:09:46 +0100 | CO2 | (CO2@gateway/vpn/protonvpn/co2) (Quit: WeeChat 4.1.1) |
| 2023-11-06 19:10:59 +0100 | <ddellacosta> | erty: I think Wadler's original paper is really great for understanding type classes in a straightforward way, not to pile on too much https://people.csail.mit.edu/dnj/teaching/6898/papers/wadler88.pdf |
| 2023-11-06 19:13:43 +0100 | CO2 | (CO2@gateway/vpn/protonvpn/co2) |
| 2023-11-06 19:14:33 +0100 | pixelmonk | (~pixelmonk@173.46.79.26) (Quit: WeeChat 4.1.0) |
| 2023-11-06 19:14:52 +0100 | pixelmonk | (~pixelmonk@173.46.79.26) |
| 2023-11-06 19:14:54 +0100 | pixelmonk | (~pixelmonk@173.46.79.26) (Client Quit) |
| 2023-11-06 19:15:00 +0100 | danse-nr3 | adds that to the reading list that monotonically increases... |
| 2023-11-06 19:15:08 +0100 | pixelmonk | (~pixelmonk@173.46.79.26) |
| 2023-11-06 19:15:44 +0100 | zetef | (~quassel@5.2.182.98) |
| 2023-11-06 19:17:53 +0100 | pixelmonk | (~pixelmonk@173.46.79.26) (Client Quit) |
| 2023-11-06 19:18:34 +0100 | ggranberry | (sid267884@id-267884.uxbridge.irccloud.com) (Server closed connection) |
| 2023-11-06 19:18:35 +0100 | Tuplanolla | (~Tuplanoll@91-159-68-236.elisa-laajakaista.fi) |
| 2023-11-06 19:18:42 +0100 | ggranberry | (sid267884@id-267884.uxbridge.irccloud.com) |
| 2023-11-06 19:18:44 +0100 | pixelmonk | (~pixelmonk@173.46.79.26) |
| 2023-11-06 19:19:13 +0100 | Lycurgus | (~georg@user/Lycurgus) |
| 2023-11-06 19:23:23 +0100 | f-a | (ff2a@drunk.24-7.ro) |
| 2023-11-06 19:26:50 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2023-11-06 19:27:29 +0100 | <EvanR> | the concept of a monotone function is hugely abstractable. x <= y implies f(x) <= f(y), i.e. it's a functor where <= denotes arrows in a category |
| 2023-11-06 19:28:33 +0100 | zetef | (~quassel@5.2.182.98) (Ping timeout: 260 seconds) |
| 2023-11-06 19:29:03 +0100 | <tomsmeding> | EvanR: typically the (<=) indicates some kind of ordering; arrows in a category don't quite make an ordering |
| 2023-11-06 19:29:18 +0100 | neceve | (~neceve@user/neceve) |
| 2023-11-06 19:29:21 +0100 | <tomsmeding> | if (<=) is not an ordering any more in any sense, then I'm not sure you can still call it "monotone" |
| 2023-11-06 19:29:22 +0100 | <EvanR> | in this example, it's an ordering |
| 2023-11-06 19:29:52 +0100 | <tomsmeding> | a category with two objects X and Y, with four arrows: id_X, id_Y, X->Y and Y->X, is a category |
| 2023-11-06 19:29:58 +0100 | <tomsmeding> | but it doesn't define an order |
| 2023-11-06 19:30:11 +0100 | <tomsmeding> | because (->) is not antisymmetric |
| 2023-11-06 19:31:14 +0100 | <danse-nr3> | i get what EvanR means, but i was not sure about the domain and codomain in the conversation above |
| 2023-11-06 19:31:27 +0100 | <EvanR> | the formula as is still makes sense the more you forget about the example until you are left with a category and the functor |
| 2023-11-06 19:31:31 +0100 | <EvanR> | two categories |
| 2023-11-06 19:31:31 +0100 | Lycurgus | (~georg@user/Lycurgus) (Quit: leaving) |
| 2023-11-06 19:31:54 +0100 | <danse-nr3> | monotonicity and categories .... it gets trickier |
| 2023-11-06 19:31:57 +0100 | <tomsmeding> | EvanR: oh for sure |
| 2023-11-06 19:32:07 +0100 | <tomsmeding> | I'm just not sure you can still call it "monotonicity" at that point :p |
| 2023-11-06 19:32:17 +0100 | <EvanR> | that's where the abstractable comes in |
| 2023-11-06 19:32:40 +0100 | <tomsmeding> | is f then not just an endofunctor |
| 2023-11-06 19:32:51 +0100 | <EvanR> | not talking about endofunctors |
| 2023-11-06 19:32:55 +0100 | Inst | (~Inst@120.244.192.250) (Ping timeout: 264 seconds) |
| 2023-11-06 19:33:07 +0100 | <EvanR> | it could be two different categories |
| 2023-11-06 19:33:07 +0100 | <tomsmeding> | well your f _is_ an endofunctor, right |
| 2023-11-06 19:33:12 +0100 | <tomsmeding> | ah |
| 2023-11-06 19:33:13 +0100 | <EvanR> | no not necessarily |
| 2023-11-06 19:33:14 +0100 | <tomsmeding> | functor, then |
| 2023-11-06 19:33:33 +0100 | <danse-nr3> | EvanR's is just the simplest definition of monotonicity ... i am confused |
| 2023-11-06 19:33:42 +0100 | <EvanR> | it's so simple it hurts |
| 2023-11-06 19:33:53 +0100 | <tomsmeding> | danse-nr3: we've abstracted the order to a preorder https://en.wikipedia.org/wiki/Preorder |
| 2023-11-06 19:34:03 +0100 | <tomsmeding> | and at that point f is just a functor |
| 2023-11-06 19:34:03 +0100 | <EvanR> | functors are super generalized monotone functions xD |
| 2023-11-06 19:34:06 +0100 | <tomsmeding> | :p |
| 2023-11-06 19:34:14 +0100 | <tomsmeding> | everything is traverse vibes |
| 2023-11-06 19:34:22 +0100 | <danse-nr3> | ^^; |
| 2023-11-06 19:34:44 +0100 | apache2 | (apache2@anubis.0x90.dk) |
| 2023-11-06 19:36:07 +0100 | <EvanR> | in the haskell semantics you call the denotation of functions monotone functions because they preserve the definedness ordering... which isn't a total order |
| 2023-11-06 19:36:53 +0100 | <EvanR> | the semantic functions can't make your results less defined as you keep computing |
| 2023-11-06 19:37:21 +0100 | <EvanR> | but the universe of values isn't laid out in a 1D line either |
| 2023-11-06 19:37:46 +0100 | <tomsmeding> | fair |
| 2023-11-06 19:37:57 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2023-11-06 19:37:58 +0100 | waleee | (~waleee@h-176-10-144-38.na.cust.bahnhof.se) |
| 2023-11-06 19:38:04 +0100 | <tomsmeding> | can't I have some double standards here? |
| 2023-11-06 19:38:18 +0100 | <tomsmeding> | I can use "monotone" with vaguely defined not-even-preorders, you can't |
| 2023-11-06 19:41:57 +0100 | <EvanR> | in some languages the universe of values does seem to be laid out in a 1D line, because you can compare any thing with anything. I wonder what this means for their semantics xD |
| 2023-11-06 19:45:40 +0100 | <erty> | tomsmeding: I think I need to practice a bit more to understand the haskell way of writing code, and then only I would be able to understand what I am doing wrong. But nevertheless, thanks for all the help to you and everyone. |
| 2023-11-06 19:46:16 +0100 | <erty> | ddellacosta: Thanks for the paper. I like the paper is from 1988 and it still valid today |
| 2023-11-06 19:46:30 +0100 | <erty> | *how |
| 2023-11-06 19:46:36 +0100 | Natch | (~natch@c-9e07225c.038-60-73746f7.bbcust.telenor.se) (Ping timeout: 248 seconds) |
| 2023-11-06 19:47:08 +0100 | jumper | (~jumper@mobile-access-2e8413-105.dhcp.inet.fi) |
| 2023-11-06 19:47:55 +0100 | Natch | (~natch@c-9e07225c.038-60-73746f7.bbcust.telenor.se) |
| 2023-11-06 19:48:34 +0100 | <tomsmeding> | erty: again, good luck and hopefully have fun :) |
| 2023-11-06 19:49:35 +0100 | neceve | (~neceve@user/neceve) (Ping timeout: 255 seconds) |
| 2023-11-06 19:51:37 +0100 | <monochrom> | EvanR: I think it means that their values can only be finite data structures, never functions or even infinite data. Then it is simple but boring. |
| 2023-11-06 19:52:46 +0100 | <monochrom> | Well, that's a sane way to do it. |
| 2023-11-06 19:53:16 +0100 | <monochrom> | The insane way is, for example, compare function pointers and denounce extensional equality... |
| 2023-11-06 19:53:18 +0100 | <EvanR> | you could encode functions as data structures |
| 2023-11-06 19:53:38 +0100 | <EvanR> | yeah I'm kidding, they all just compare pointers xD |
| 2023-11-06 19:54:00 +0100 | <EvanR> | values has not caught on much in 2023 |
| 2023-11-06 19:57:20 +0100 | hgolden | (~hgolden@2603-8000-9d00-3ed1-dd4f-298a-9c49-a0ed.res6.spectrum.com) (Remote host closed the connection) |
| 2023-11-06 19:57:40 +0100 | hgolden | (~hgolden@2603-8000-9d00-3ed1-a6e3-3ba3-0107-8cff.res6.spectrum.com) |
| 2023-11-06 20:00:13 +0100 | szkl | (uid110435@id-110435.uxbridge.irccloud.com) (Quit: Connection closed for inactivity) |
| 2023-11-06 20:06:36 +0100 | [exa] | (~exa@user/exa/x-3587197) |
| 2023-11-06 20:09:20 +0100 | jumper | (~jumper@mobile-access-2e8413-105.dhcp.inet.fi) (Quit: leaving) |
| 2023-11-06 20:09:21 +0100 | misterfish | (~misterfis@84-53-85-146.bbserv.nl) (Ping timeout: 240 seconds) |
| 2023-11-06 20:12:02 +0100 | billchenchina | (~billchenc@2a0d:2580:ff0c:1:e3c9:c52b:a429:5bfe) (Remote host closed the connection) |
| 2023-11-06 20:13:25 +0100 | xstill_9 | (xstill@fimu/xstill) |
| 2023-11-06 20:13:43 +0100 | MironZ6 | (~MironZ@nat-infra.ehlab.uk) |
| 2023-11-06 20:13:44 +0100 | qhong | (~qhong@rescomp-21-400677.stanford.edu) |
| 2023-11-06 20:14:04 +0100 | henrytill_ | (e0180937c3@2604:bf00:561:2000::e8c) |
| 2023-11-06 20:14:05 +0100 | fgaz__ | (1ff9197ed6@2604:bf00:561:2000::11ea) |
| 2023-11-06 20:14:09 +0100 | sus_ | (1b7af6299f@user/zeromomentum) |
| 2023-11-06 20:14:10 +0100 | bsima1_ | (9d7e39c8ad@2604:bf00:561:2000::dd) |
| 2023-11-06 20:14:17 +0100 | fn_lumi_ | (3d621153a5@2604:bf00:561:2000::df7) |
| 2023-11-06 20:14:18 +0100 | raghavgururajan_ | (ea769b8000@2604:bf00:561:2000::242) |
| 2023-11-06 20:14:23 +0100 | chaitlatte0_ | (ea29c0bb16@2604:bf00:561:2000::1124) |
| 2023-11-06 20:14:30 +0100 | jmcantrell_ | (644f1bed9a@user/jmcantrell) |
| 2023-11-06 20:14:31 +0100 | bgamari_ | (~bgamari@64.223.173.10) |
| 2023-11-06 20:14:32 +0100 | ymherklotz_ | (cb2c9cfbdd@2604:bf00:561:2000::29a) |
| 2023-11-06 20:14:32 +0100 | shreyasminocha_ | (51fdc93eda@user/shreyasminocha) |
| 2023-11-06 20:14:33 +0100 | theesm_ | (2cbdf4b38a@2604:bf00:561:2000::11c8) |
| 2023-11-06 20:14:33 +0100 | _0xa_ | (~user@2001:19f0:5001:2ba8:5400:1ff:feda:88fc) |
| 2023-11-06 20:14:34 +0100 | whereiseveryone_ | (206ba86c98@2604:bf00:561:2000::2e4) |
| 2023-11-06 20:14:35 +0100 | b0o_ | (0e4a0bf4c9@2604:bf00:561:2000::1bf) |
| 2023-11-06 20:14:35 +0100 | rselim_ | (ce261f06ff@user/milesrout) |
| 2023-11-06 20:14:36 +0100 | acertain__ | (sid470584@id-470584.hampstead.irccloud.com) |
| 2023-11-06 20:14:36 +0100 | jleightcap_ | (7bc4014b62@user/jleightcap) |
| 2023-11-06 20:14:38 +0100 | liyang_ | (sid322268@id-322268.uxbridge.irccloud.com) |
| 2023-11-06 20:14:38 +0100 | jmct_ | (sid160793@id-160793.tinside.irccloud.com) |
| 2023-11-06 20:14:39 +0100 | liyang | (sid322268@id-322268.uxbridge.irccloud.com) (Killed (zinc.libera.chat (Nickname regained by services))) |
| 2023-11-06 20:14:39 +0100 | liyang_ | liyang |
| 2023-11-06 20:15:16 +0100 | Unode_ | (~Unode@fg-ext-220.embl.de) |
| 2023-11-06 20:16:13 +0100 | xnbya | (~xnbya@2a01:4f8:c17:cbdd::1) |
| 2023-11-06 20:16:22 +0100 | it__ | (~quassel@v2202212189510211193.supersrv.de) |
| 2023-11-06 20:16:53 +0100 | mjrosenb_ | (~mjrosenb@pool-96-232-177-77.nycmny.fios.verizon.net) |
| 2023-11-06 20:17:34 +0100 | dexter2 | (dexter@2a01:7e00::f03c:91ff:fe86:59ec) |
| 2023-11-06 20:17:45 +0100 | PHO`_ | (~pho@akari.cielonegro.org) |
| 2023-11-06 20:18:14 +0100 | CAT_S_ | (apic@brezn3.muc.ccc.de) |
| 2023-11-06 20:18:21 +0100 | shreyasminocha | (51fdc93eda@user/shreyasminocha) (Ping timeout: 246 seconds) |
| 2023-11-06 20:18:21 +0100 | qhong_ | (~qhong@rescomp-21-400677.stanford.edu) (Ping timeout: 246 seconds) |
| 2023-11-06 20:18:21 +0100 | theesm | (2cbdf4b38a@2604:bf00:561:2000::11c8) (Ping timeout: 246 seconds) |
| 2023-11-06 20:18:21 +0100 | jmcantrell | (644f1bed9a@user/jmcantrell) (Ping timeout: 246 seconds) |
| 2023-11-06 20:18:21 +0100 | jmct | (sid160793@id-160793.tinside.irccloud.com) (Ping timeout: 246 seconds) |
| 2023-11-06 20:18:21 +0100 | fn_lumi | (3d621153a5@2604:bf00:561:2000::df7) (Ping timeout: 246 seconds) |
| 2023-11-06 20:18:22 +0100 | fgaz_ | (1ff9197ed6@2604:bf00:561:2000::11ea) (Ping timeout: 246 seconds) |
| 2023-11-06 20:18:22 +0100 | adamCS | (~adamCS@ec2-34-207-160-255.compute-1.amazonaws.com) (Ping timeout: 246 seconds) |
| 2023-11-06 20:18:22 +0100 | _0xa | (~user@user/0xa/x-3134607) (Ping timeout: 246 seconds) |
| 2023-11-06 20:18:22 +0100 | rselim | (ce261f06ff@user/milesrout) (Ping timeout: 246 seconds) |
| 2023-11-06 20:18:22 +0100 | whereiseveryone | (206ba86c98@2604:bf00:561:2000::2e4) (Ping timeout: 246 seconds) |
| 2023-11-06 20:18:23 +0100 | jleightcap | (7bc4014b62@user/jleightcap) (Ping timeout: 246 seconds) |
| 2023-11-06 20:18:23 +0100 | b0o | (0e4a0bf4c9@2604:bf00:561:2000::1bf) (Ping timeout: 246 seconds) |
| 2023-11-06 20:18:23 +0100 | ymherklotz | (cb2c9cfbdd@2604:bf00:561:2000::29a) (Ping timeout: 246 seconds) |
| 2023-11-06 20:18:23 +0100 | chaitlatte0 | (ea29c0bb16@user/chaitlatte0) (Ping timeout: 246 seconds) |
| 2023-11-06 20:18:23 +0100 | sus | (1b7af6299f@user/zeromomentum) (Ping timeout: 246 seconds) |
| 2023-11-06 20:18:23 +0100 | raghavgururajan | (ea769b8000@user/raghavgururajan) (Ping timeout: 246 seconds) |
| 2023-11-06 20:18:24 +0100 | bgamari | (~bgamari@64.223.173.10) (Ping timeout: 246 seconds) |
| 2023-11-06 20:18:24 +0100 | Raito_Bezarius | (~Raito@wireguard/tunneler/raito-bezarius) (Ping timeout: 246 seconds) |
| 2023-11-06 20:18:24 +0100 | acertain_ | (sid470584@id-470584.hampstead.irccloud.com) (Ping timeout: 246 seconds) |
| 2023-11-06 20:18:24 +0100 | Unode | (~Unode@fg-ext-220.embl.de) (Ping timeout: 246 seconds) |
| 2023-11-06 20:18:24 +0100 | mjrosenb | (~mjrosenb@pool-96-232-177-77.nycmny.fios.verizon.net) (Ping timeout: 246 seconds) |
| 2023-11-06 20:18:25 +0100 | Adran | (~adran@botters/adran) (Ping timeout: 246 seconds) |
| 2023-11-06 20:18:25 +0100 | CAT_S | (apic@brezn3.muc.ccc.de) (Ping timeout: 246 seconds) |
| 2023-11-06 20:18:25 +0100 | nullie | (~nullie@2a01:4f8:c2c:6177::1) (Ping timeout: 246 seconds) |
| 2023-11-06 20:18:25 +0100 | bsima1 | (9d7e39c8ad@2604:bf00:561:2000::dd) (Ping timeout: 246 seconds) |
| 2023-11-06 20:18:26 +0100 | dexter1 | (dexter@2a01:7e00::f03c:91ff:fe86:59ec) (Ping timeout: 246 seconds) |
| 2023-11-06 20:18:26 +0100 | henrytill | (e0180937c3@2604:bf00:561:2000::e8c) (Ping timeout: 246 seconds) |
| 2023-11-06 20:18:26 +0100 | xnbya2 | (~xnbya@2a01:4f8:c17:cbdd::1) (Ping timeout: 246 seconds) |
| 2023-11-06 20:18:26 +0100 | MironZ | (~MironZ@nat-infra.ehlab.uk) (Ping timeout: 246 seconds) |
| 2023-11-06 20:18:26 +0100 | xstill_ | (xstill@fimu/xstill) (Ping timeout: 246 seconds) |
| 2023-11-06 20:18:27 +0100 | PHO` | (~pho@akari.cielonegro.org) (Ping timeout: 246 seconds) |
| 2023-11-06 20:18:28 +0100 | it_ | (~quassel@v2202212189510211193.supersrv.de) (Ping timeout: 246 seconds) |
| 2023-11-06 20:18:28 +0100 | jmct_ | jmct |
| 2023-11-06 20:18:28 +0100 | theesm_ | theesm |
| 2023-11-06 20:18:28 +0100 | fn_lumi_ | fn_lumi |
| 2023-11-06 20:18:28 +0100 | acertain__ | acertain_ |
| 2023-11-06 20:18:29 +0100 | sus_ | sus |
| 2023-11-06 20:18:29 +0100 | MironZ6 | MironZ |
| 2023-11-06 20:18:29 +0100 | ymherklotz_ | ymherklotz |
| 2023-11-06 20:18:29 +0100 | rselim_ | rselim |
| 2023-11-06 20:18:29 +0100 | chaitlatte0_ | chaitlatte0 |
| 2023-11-06 20:18:29 +0100 | jmcantrell_ | jmcantrell |
| 2023-11-06 20:18:29 +0100 | b0o_ | b0o |
| 2023-11-06 20:18:30 +0100 | bsima1_ | bsima1 |
| 2023-11-06 20:18:30 +0100 | henrytill_ | henrytill |
| 2023-11-06 20:18:30 +0100 | fgaz__ | fgaz_ |
| 2023-11-06 20:18:30 +0100 | whereiseveryone_ | whereiseveryone |
| 2023-11-06 20:18:30 +0100 | jleightcap_ | jleightcap |
| 2023-11-06 20:18:30 +0100 | shreyasminocha_ | shreyasminocha |
| 2023-11-06 20:18:31 +0100 | Unode_ | Unode |
| 2023-11-06 20:18:31 +0100 | xstill_9 | xstill_ |
| 2023-11-06 20:18:34 +0100 | nullie | (~nullie@2a01:4f8:c2c:6177::1) |
| 2023-11-06 20:18:45 +0100 | ggb | (a62ffbaf4f@2604:bf00:561:2000::3ac) (Read error: Connection reset by peer) |
| 2023-11-06 20:18:45 +0100 | rselim | (ce261f06ff@user/milesrout) (Read error: Connection reset by peer) |
| 2023-11-06 20:18:45 +0100 | jakzale | (6291399afa@user/jakzale) (Read error: Connection reset by peer) |
| 2023-11-06 20:18:45 +0100 | evanrelf | (3addc196af@2604:bf00:561:2000::f0) (Read error: Connection reset by peer) |
| 2023-11-06 20:18:45 +0100 | fluffyballoon | (45ce440a48@2604:bf00:561:2000::e2) (Read error: Connection reset by peer) |
| 2023-11-06 20:18:45 +0100 | theesm | (2cbdf4b38a@2604:bf00:561:2000::11c8) (Read error: Connection reset by peer) |
| 2023-11-06 20:18:45 +0100 | shreyasminocha | (51fdc93eda@user/shreyasminocha) (Read error: Connection reset by peer) |
| 2023-11-06 20:18:45 +0100 | ymherklotz | (cb2c9cfbdd@2604:bf00:561:2000::29a) (Read error: Connection reset by peer) |
| 2023-11-06 20:18:45 +0100 | cpli | (77fc530071@2604:bf00:561:2000::252) (Read error: Connection reset by peer) |
| 2023-11-06 20:18:45 +0100 | probie | (cc0b34050a@user/probie) (Read error: Connection reset by peer) |
| 2023-11-06 20:18:45 +0100 | jmcantrell | (644f1bed9a@user/jmcantrell) (Read error: Connection reset by peer) |
| 2023-11-06 20:18:45 +0100 | MonsoonSecrecy | (f78c86e960@2604:bf00:561:2000::f99) (Read error: Connection reset by peer) |
| 2023-11-06 20:18:46 +0100 | sus | (1b7af6299f@user/zeromomentum) (Read error: Connection reset by peer) |
| 2023-11-06 20:18:46 +0100 | raghavgururajan_ | (ea769b8000@2604:bf00:561:2000::242) (Read error: Connection reset by peer) |
| 2023-11-06 20:18:46 +0100 | b0o | (0e4a0bf4c9@2604:bf00:561:2000::1bf) (Write error: Connection reset by peer) |
| 2023-11-06 20:18:46 +0100 | henrytill | (e0180937c3@2604:bf00:561:2000::e8c) (Read error: Connection reset by peer) |
| 2023-11-06 20:18:46 +0100 | brettgilio | (a35ba67324@2604:bf00:561:2000::260) (Read error: Connection reset by peer) |
| 2023-11-06 20:18:47 +0100 | whereiseveryone | (206ba86c98@2604:bf00:561:2000::2e4) (Read error: Connection reset by peer) |
| 2023-11-06 20:18:47 +0100 | fn_lumi | (3d621153a5@2604:bf00:561:2000::df7) (Read error: Connection reset by peer) |
| 2023-11-06 20:18:47 +0100 | bsima1 | (9d7e39c8ad@2604:bf00:561:2000::dd) (Read error: Connection reset by peer) |
| 2023-11-06 20:18:47 +0100 | fgaz_ | (1ff9197ed6@2604:bf00:561:2000::11ea) (Read error: Connection reset by peer) |
| 2023-11-06 20:18:47 +0100 | jleightcap | (7bc4014b62@user/jleightcap) (Read error: Connection reset by peer) |
| 2023-11-06 20:18:47 +0100 | chaitlatte0 | (ea29c0bb16@2604:bf00:561:2000::1124) (Read error: Connection reset by peer) |
| 2023-11-06 20:18:47 +0100 | akspecs | (00cc8321af@sourcehut/user/akspecs) (Read error: Connection reset by peer) |
| 2023-11-06 20:18:47 +0100 | Ankhers | (e99e97ef8e@2604:bf00:561:2000::2a2) (Read error: Connection reset by peer) |
| 2023-11-06 20:18:47 +0100 | arcadewise | (52968ed80d@2604:bf00:561:2000::3df) (Read error: Connection reset by peer) |
| 2023-11-06 20:18:47 +0100 | fvr | (ef3e56ca8b@2604:bf00:561:2000::3c4) (Read error: Connection reset by peer) |
| 2023-11-06 20:18:47 +0100 | samhh | (7569f027cf@2604:bf00:561:2000::e4) (Read error: Connection reset by peer) |
| 2023-11-06 20:18:47 +0100 | jkoshy | (99b9359beb@user/jkoshy) (Read error: Connection reset by peer) |
| 2023-11-06 20:18:47 +0100 | JoelMcCracken | (5ea8252fbb@2604:bf00:561:2000::10e3) (Read error: Connection reset by peer) |
| 2023-11-06 20:18:48 +0100 | aniketd | (32aa4844cd@2604:bf00:561:2000::dcb) (Read error: Connection reset by peer) |
| 2023-11-06 20:18:48 +0100 | filwisher | (2e6936c793@2604:bf00:561:2000::170) (Read error: Connection reset by peer) |
| 2023-11-06 20:18:48 +0100 | lukec | (9dfd4d094e@2604:bf00:561:2000::10e) (Read error: Connection reset by peer) |
| 2023-11-06 20:18:48 +0100 | sm2n | (ae95cb1267@user/sm2n) (Read error: Connection reset by peer) |
| 2023-11-06 20:18:48 +0100 | samhh_ | (7569f027cf@2604:bf00:561:2000::e4) (Write error: Connection reset by peer) |
| 2023-11-06 20:18:58 +0100 | fvr | (ef3e56ca8b@2604:bf00:561:2000::3c4) |
| 2023-11-06 20:18:59 +0100 | theesm | (2cbdf4b38a@2604:bf00:561:2000::11c8) |
| 2023-11-06 20:18:59 +0100 | filwisher | (2e6936c793@2604:bf00:561:2000::170) |
| 2023-11-06 20:19:00 +0100 | fgaz_ | (1ff9197ed6@2604:bf00:561:2000::11ea) |
| 2023-11-06 20:19:01 +0100 | ggb | (a62ffbaf4f@2604:bf00:561:2000::3ac) |
| 2023-11-06 20:19:01 +0100 | raghavgururajan | (ea769b8000@user/raghavgururajan) |
| 2023-11-06 20:19:01 +0100 | bsima1 | (9d7e39c8ad@2604:bf00:561:2000::dd) |
| 2023-11-06 20:19:01 +0100 | lukec | (9dfd4d094e@2604:bf00:561:2000::10e) |
| 2023-11-06 20:19:02 +0100 | samhh | (7569f027cf@2604:bf00:561:2000::e4) |
| 2023-11-06 20:19:12 +0100 | jleightcap | (7bc4014b62@user/jleightcap) |
| 2023-11-06 20:19:12 +0100 | shreyasminocha | (51fdc93eda@user/shreyasminocha) |
| 2023-11-06 20:19:21 +0100 | jakzale | (6291399afa@user/jakzale) |
| 2023-11-06 20:19:21 +0100 | jmcantrell | (644f1bed9a@user/jmcantrell) |
| 2023-11-06 20:19:23 +0100 | Raito_Bezarius | (~Raito@82-65-118-1.subs.proxad.net) |
| 2023-11-06 20:19:28 +0100 | evanrelf | (3addc196af@2604:bf00:561:2000::f0) |
| 2023-11-06 20:19:28 +0100 | sus | (1b7af6299f@user/zeromomentum) |
| 2023-11-06 20:19:32 +0100 | fluffyballoon | (45ce440a48@2604:bf00:561:2000::e2) |
| 2023-11-06 20:19:32 +0100 | aniketd | (32aa4844cd@2604:bf00:561:2000::dcb) |
| 2023-11-06 20:19:42 +0100 | brettgilio | (a35ba67324@2604:bf00:561:2000::260) |
| 2023-11-06 20:19:42 +0100 | whereiseveryone | (206ba86c98@2604:bf00:561:2000::2e4) |
| 2023-11-06 20:19:42 +0100 | probie | (cc0b34050a@user/probie) |
| 2023-11-06 20:19:42 +0100 | sm2n | (ae95cb1267@user/sm2n) |
| 2023-11-06 20:20:01 +0100 | adamCS | (~adamCS@ec2-34-207-160-255.compute-1.amazonaws.com) |
| 2023-11-06 20:20:05 +0100 | henrytill | (e0180937c3@2604:bf00:561:2000::e8c) |
| 2023-11-06 20:20:08 +0100 | MonsoonSecrecy | (f78c86e960@2604:bf00:561:2000::f99) |
| 2023-11-06 20:20:11 +0100 | Ankhers | (e99e97ef8e@2604:bf00:561:2000::2a2) |
| 2023-11-06 20:20:13 +0100 | rselim | (ce261f06ff@user/milesrout) |
| 2023-11-06 20:20:21 +0100 | doyougnu | (~doyougnu@45.46.170.68) (Ping timeout: 240 seconds) |
| 2023-11-06 20:20:22 +0100 | arcadewise | (52968ed80d@2604:bf00:561:2000::3df) |
| 2023-11-06 20:20:30 +0100 | cpli | (77fc530071@2604:bf00:561:2000::252) |
| 2023-11-06 20:20:37 +0100 | ymherklotz | (cb2c9cfbdd@2604:bf00:561:2000::29a) |
| 2023-11-06 20:20:38 +0100 | samhh_ | (7569f027cf@2604:bf00:561:2000::e4) |
| 2023-11-06 20:20:39 +0100 | akspecs | (00cc8321af@sourcehut/user/akspecs) |
| 2023-11-06 20:20:39 +0100 | b0o | (0e4a0bf4c9@2604:bf00:561:2000::1bf) |
| 2023-11-06 20:20:46 +0100 | chaitlatte0 | (ea29c0bb16@user/chaitlatte0) |
| 2023-11-06 20:20:52 +0100 | CO2 | (CO2@gateway/vpn/protonvpn/co2) (Quit: WeeChat 4.1.1) |
| 2023-11-06 20:20:57 +0100 | jkoshy | (99b9359beb@user/jkoshy) |
| 2023-11-06 20:20:57 +0100 | fn_lumi | (3d621153a5@2604:bf00:561:2000::df7) |
| 2023-11-06 20:20:59 +0100 | JoelMcCracken | (5ea8252fbb@2604:bf00:561:2000::10e3) |
| 2023-11-06 20:21:25 +0100 | f-a | (ff2a@drunk.24-7.ro) () |
| 2023-11-06 20:21:55 +0100 | Adran | (~adran@botters/adran) |
| 2023-11-06 20:28:41 +0100 | AlexZenon | (~alzenon@178.34.161.199) (Quit: ;-) |
| 2023-11-06 20:30:32 +0100 | doyougnu | (~doyougnu@45.46.170.68) |
| 2023-11-06 20:34:30 +0100 | sord937 | (~sord937@gateway/tor-sasl/sord937) (Quit: sord937) |
| 2023-11-06 20:44:35 +0100 | misterfish | (~misterfis@84-53-85-146.bbserv.nl) |
| 2023-11-06 20:45:20 +0100 | AlexZenon | (~alzenon@178.34.161.199) |
| 2023-11-06 20:46:41 +0100 | erty | (~user@user/aeroplane) (Ping timeout: 240 seconds) |
| 2023-11-06 20:53:11 +0100 | CO2 | (CO2@gateway/vpn/protonvpn/co2) |
| 2023-11-06 20:56:03 +0100 | danse-nr3 | (~danse@151.37.110.121) (Ping timeout: 260 seconds) |
| 2023-11-06 20:56:22 +0100 | danse-nr3 | (~danse@151.43.123.164) |
| 2023-11-06 20:57:01 +0100 | pixelmonk | (~pixelmonk@173.46.79.26) (Ping timeout: 240 seconds) |
| 2023-11-06 20:59:19 +0100 | Unicorn_Princess | (~Unicorn_P@user/Unicorn-Princess/x-3540542) |
| 2023-11-06 20:59:41 +0100 | Pickchea | (~private@user/pickchea) |
| 2023-11-06 21:01:42 +0100 | pixelmonk | (~pixelmonk@173.46.79.26) |
| 2023-11-06 21:06:35 +0100 | fendor | (~fendor@2a02:8388:1640:be00:cb6e:46f6:2fe6:1728) (Remote host closed the connection) |
| 2023-11-06 21:08:35 +0100 | pixelmonk | (~pixelmonk@173.46.79.26) (Ping timeout: 240 seconds) |
| 2023-11-06 21:09:28 +0100 | CAT_S_ | (apic@brezn3.muc.ccc.de) (Quit: Reconnecting) |
| 2023-11-06 21:09:40 +0100 | CATS | (apic@brezn3.muc.ccc.de) |
| 2023-11-06 21:15:09 +0100 | trev | (~trev@user/trev) (Quit: trev) |
| 2023-11-06 21:15:54 +0100 | CATS | CAT_S |
| 2023-11-06 21:20:51 +0100 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:718b:eff8:b2d7:bbc8) (Remote host closed the connection) |
| 2023-11-06 21:21:22 +0100 | pixelmonk | (~pixelmonk@173.46.79.26) |
| 2023-11-06 21:24:34 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2023-11-06 21:25:35 +0100 | <EvanR> | what's up with this documentation, other than the exmaple typo, it says under virtual record fields you could access something with "#fullname", but I have not seen a way to get ghc to accept syntax #fullname |
| 2023-11-06 21:25:40 +0100 | <EvanR> | https://downloads.haskell.org/ghc/latest/docs/users_guide/exts/hasfield.html |
| 2023-11-06 21:26:04 +0100 | <EvanR> | getField @"fullname" whatever does work as mentioned elsewhere on the page |
| 2023-11-06 21:26:49 +0100 | <int-e> | > let (#) = id in id#4 |
| 2023-11-06 21:26:50 +0100 | <lambdabot> | error: |
| 2023-11-06 21:26:50 +0100 | <lambdabot> | • Variable not in scope: id# :: t0 -> t |
| 2023-11-06 21:26:51 +0100 | <lambdabot> | • Perhaps you meant one of these: |
| 2023-11-06 21:26:56 +0100 | <int-e> | > let (#) = id in id #4 |
| 2023-11-06 21:26:58 +0100 | <lambdabot> | 4 |
| 2023-11-06 21:27:09 +0100 | <int-e> | (whoops, MagicHash is enabled in lambdabot) |
| 2023-11-06 21:28:07 +0100 | pixelmonk | (~pixelmonk@173.46.79.26) (Ping timeout: 264 seconds) |
| 2023-11-06 21:30:33 +0100 | <danse-nr3> | someone should invent documentation bug reports, so that documentations can be improved |
| 2023-11-06 21:30:49 +0100 | <tomsmeding> | EvanR: -XOverloadedLabels |
| 2023-11-06 21:31:32 +0100 | <EvanR> | oooooh |
| 2023-11-06 21:32:55 +0100 | pixelmonk | (~pixelmonk@173.46.79.26) |
| 2023-11-06 21:33:09 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2023-11-06 21:33:40 +0100 | hovsater | (sid499516@id-499516.lymington.irccloud.com) (Server closed connection) |
| 2023-11-06 21:33:49 +0100 | hovsater | (sid499516@id-499516.lymington.irccloud.com) |
| 2023-11-06 21:36:53 +0100 | sa1 | (sid7690@id-7690.ilkley.irccloud.com) (Server closed connection) |
| 2023-11-06 21:37:03 +0100 | sa1 | (sid7690@id-7690.ilkley.irccloud.com) |
| 2023-11-06 21:40:28 +0100 | ft | (~ft@p4fc2a529.dip0.t-ipconnect.de) |
| 2023-11-06 21:43:46 +0100 | motherfsck | (~motherfsc@user/motherfsck) (Ping timeout: 260 seconds) |
| 2023-11-06 21:46:49 +0100 | danse-nr3 | (~danse@151.43.123.164) (Ping timeout: 255 seconds) |
| 2023-11-06 21:48:11 +0100 | danse-nr3 | (~danse@151.43.123.164) |
| 2023-11-06 21:49:40 +0100 | zetef | (~quassel@5.2.182.98) |
| 2023-11-06 21:49:45 +0100 | tritlo_ | (sid58727@id-58727.hampstead.irccloud.com) (Server closed connection) |
| 2023-11-06 21:49:59 +0100 | tritlo_ | (sid58727@id-58727.hampstead.irccloud.com) |
| 2023-11-06 21:50:39 +0100 | todi | (~todi@p4fd1a3e6.dip0.t-ipconnect.de) |
| 2023-11-06 21:50:58 +0100 | todi | (~todi@p4fd1a3e6.dip0.t-ipconnect.de) (Read error: Connection reset by peer) |
| 2023-11-06 21:52:24 +0100 | zetef | (~quassel@5.2.182.98) (Remote host closed the connection) |
| 2023-11-06 21:53:00 +0100 | zetef | (~quassel@5.2.182.98) |
| 2023-11-06 21:55:20 +0100 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:718b:eff8:b2d7:bbc8) |
| 2023-11-06 21:58:04 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Ping timeout: 256 seconds) |
| 2023-11-06 21:59:08 +0100 | zetef | (~quassel@5.2.182.98) (Remote host closed the connection) |
| 2023-11-06 21:59:31 +0100 | eggplant_ | (~Eggplanta@104-55-37-220.lightspeed.sntcca.sbcglobal.net) |
| 2023-11-06 21:59:38 +0100 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:718b:eff8:b2d7:bbc8) (Ping timeout: 255 seconds) |
| 2023-11-06 21:59:44 +0100 | zetef | (~quassel@5.2.182.98) |
| 2023-11-06 22:02:53 +0100 | machinedgod | (~machinedg@d198-53-218-113.abhsia.telus.net) |
| 2023-11-06 22:03:08 +0100 | qeef | (~qeef@138-169-143-94.cust.centrio.cz) |
| 2023-11-06 22:04:04 +0100 | eggplant_ | (~Eggplanta@104-55-37-220.lightspeed.sntcca.sbcglobal.net) (Ping timeout: 255 seconds) |
| 2023-11-06 22:05:11 +0100 | _ht | (~Thunderbi@28-52-174-82.ftth.glasoperator.nl) (Quit: _ht) |
| 2023-11-06 22:05:44 +0100 | zetef | (~quassel@5.2.182.98) (Remote host closed the connection) |
| 2023-11-06 22:06:40 +0100 | zetef | (~quassel@5.2.182.98) |
| 2023-11-06 22:06:58 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) |
| 2023-11-06 22:08:07 +0100 | zetef | (~quassel@5.2.182.98) (Remote host closed the connection) |
| 2023-11-06 22:08:32 +0100 | zetef | (~quassel@5.2.182.98) |
| 2023-11-06 22:09:20 +0100 | __monty__ | (~toonn@user/toonn) (Quit: leaving) |
| 2023-11-06 22:09:51 +0100 | zetef | (~quassel@5.2.182.98) (Remote host closed the connection) |
| 2023-11-06 22:10:38 +0100 | zetef | (~quassel@5.2.182.98) |
| 2023-11-06 22:13:35 +0100 | Jackneill_ | (~Jackneill@20014C4E1E058A00E81C5E515534C989.dsl.pool.telekom.hu) (Ping timeout: 255 seconds) |
| 2023-11-06 22:14:51 +0100 | zmt01 | (~zmt00@user/zmt00) |
| 2023-11-06 22:15:52 +0100 | danse-nr3 | (~danse@151.43.123.164) (Ping timeout: 258 seconds) |
| 2023-11-06 22:18:04 +0100 | pavonia | (~user@user/siracusa) |
| 2023-11-06 22:18:12 +0100 | doyougnu- | (~doyougnu@45.46.170.68) |
| 2023-11-06 22:18:55 +0100 | zmt00 | (~zmt00@user/zmt00) (Ping timeout: 252 seconds) |
| 2023-11-06 22:19:14 +0100 | doyougnu | (~doyougnu@45.46.170.68) (Ping timeout: 245 seconds) |
| 2023-11-06 22:20:15 +0100 | oo_miguel | (~Thunderbi@78-11-179-96.static.ip.netia.com.pl) (Ping timeout: 240 seconds) |
| 2023-11-06 22:28:00 +0100 | target_i | (~target_i@217.175.14.39) (Quit: leaving) |
| 2023-11-06 22:29:00 +0100 | dcoutts | (~duncan@cpc69402-oxfd27-2-0-cust903.4-3.cable.virginm.net) |
| 2023-11-06 22:34:31 +0100 | zetef | (~quassel@5.2.182.98) (Remote host closed the connection) |
| 2023-11-06 22:34:39 +0100 | ThePenguin | (~ThePengui@cust-95-80-24-166.csbnet.se) (Ping timeout: 245 seconds) |
| 2023-11-06 22:35:12 +0100 | zetef | (~quassel@5.2.182.98) |
| 2023-11-06 22:35:54 +0100 | justache | justThanks |
| 2023-11-06 22:38:07 +0100 | ThePenguin | (~ThePengui@cust-95-80-24-166.csbnet.se) |
| 2023-11-06 22:41:26 +0100 | zetef | (~quassel@5.2.182.98) (Remote host closed the connection) |
| 2023-11-06 22:42:20 +0100 | zetef | (~quassel@5.2.182.98) |
| 2023-11-06 22:42:23 +0100 | todi | (~todi@p4fd1a3e6.dip0.t-ipconnect.de) |
| 2023-11-06 22:43:07 +0100 | todi | (~todi@p4fd1a3e6.dip0.t-ipconnect.de) (Read error: Connection reset by peer) |
| 2023-11-06 22:45:57 +0100 | zetef | (~quassel@5.2.182.98) (Read error: Connection reset by peer) |
| 2023-11-06 22:46:07 +0100 | notzmv | (~zmv@user/notzmv) (Ping timeout: 264 seconds) |
| 2023-11-06 22:46:26 +0100 | todi | (~todi@p4fd1a3e6.dip0.t-ipconnect.de) |
| 2023-11-06 22:46:43 +0100 | zetef | (~quassel@5.2.182.98) |
| 2023-11-06 22:47:40 +0100 | todi | (~todi@p4fd1a3e6.dip0.t-ipconnect.de) (Read error: Connection reset by peer) |
| 2023-11-06 22:52:32 +0100 | todi | (~todi@p4fd1a3e6.dip0.t-ipconnect.de) |
| 2023-11-06 22:52:44 +0100 | todi | (~todi@p4fd1a3e6.dip0.t-ipconnect.de) (Read error: Connection reset by peer) |
| 2023-11-06 22:54:11 +0100 | end` | (end@user/end/x-0094621) |
| 2023-11-06 22:54:18 +0100 | Lycurgus | (~georg@user/Lycurgus) |
| 2023-11-06 22:56:31 +0100 | todi | (~todi@p4fd1a3e6.dip0.t-ipconnect.de) |
| 2023-11-06 22:57:46 +0100 | zetef | (~quassel@5.2.182.98) (Remote host closed the connection) |
| 2023-11-06 22:57:52 +0100 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:6dde:4903:7d59:6a8d) |
| 2023-11-06 22:58:36 +0100 | todi | (~todi@p4fd1a3e6.dip0.t-ipconnect.de) (Read error: Connection reset by peer) |
| 2023-11-06 23:01:54 +0100 | todi | (~todi@p4fd1a3e6.dip0.t-ipconnect.de) |
| 2023-11-06 23:02:00 +0100 | zetef | (~quassel@5.2.182.98) |
| 2023-11-06 23:02:21 +0100 | todi | (~todi@p4fd1a3e6.dip0.t-ipconnect.de) (Read error: Connection reset by peer) |
| 2023-11-06 23:02:41 +0100 | stiell_ | (~stiell@gateway/tor-sasl/stiell) (Remote host closed the connection) |
| 2023-11-06 23:03:11 +0100 | zetef | (~quassel@5.2.182.98) (Read error: Connection reset by peer) |
| 2023-11-06 23:03:20 +0100 | stiell_ | (~stiell@gateway/tor-sasl/stiell) |
| 2023-11-06 23:06:07 +0100 | todi | (~todi@p4fd1a3e6.dip0.t-ipconnect.de) |
| 2023-11-06 23:06:07 +0100 | todi | (~todi@p4fd1a3e6.dip0.t-ipconnect.de) (Read error: Connection reset by peer) |
| 2023-11-06 23:09:18 +0100 | todi | (~todi@p4fd1a3e6.dip0.t-ipconnect.de) |
| 2023-11-06 23:09:48 +0100 | todi | (~todi@p4fd1a3e6.dip0.t-ipconnect.de) (Read error: Connection reset by peer) |
| 2023-11-06 23:11:18 +0100 | Pickchea | (~private@user/pickchea) (Quit: Leaving) |
| 2023-11-06 23:14:38 +0100 | danza | (~francesco@151.47.97.80) |
| 2023-11-06 23:14:55 +0100 | takuan | (~takuan@178-116-218-225.access.telenet.be) (Remote host closed the connection) |
| 2023-11-06 23:15:43 +0100 | todi | (~todi@p4fd1a3e6.dip0.t-ipconnect.de) |
| 2023-11-06 23:17:12 +0100 | todi | (~todi@p4fd1a3e6.dip0.t-ipconnect.de) (Read error: Connection reset by peer) |
| 2023-11-06 23:20:18 +0100 | todi | (~todi@p4fd1a3e6.dip0.t-ipconnect.de) |
| 2023-11-06 23:20:53 +0100 | todi | (~todi@p4fd1a3e6.dip0.t-ipconnect.de) (Read error: Connection reset by peer) |
| 2023-11-06 23:22:52 +0100 | ubert | (~Thunderbi@91.141.42.10.wireless.dyn.drei.com) |
| 2023-11-06 23:34:49 +0100 | coot | (~coot@89-69-206-216.dynamic.chello.pl) (Quit: coot) |
| 2023-11-06 23:45:33 +0100 | rubin55 | (sid175221@id-175221.hampstead.irccloud.com) (Server closed connection) |
| 2023-11-06 23:45:52 +0100 | rubin55 | (sid175221@id-175221.hampstead.irccloud.com) |
| 2023-11-06 23:49:26 +0100 | danza | (~francesco@151.47.97.80) (Ping timeout: 255 seconds) |
| 2023-11-06 23:51:01 +0100 | pixelmonk | (~pixelmonk@173.46.79.26) (Ping timeout: 240 seconds) |
| 2023-11-06 23:52:28 +0100 | chomwitt | (~chomwitt@2a02:587:7a2d:bc00:1ac0:4dff:fedb:a3f1) (Ping timeout: 258 seconds) |
| 2023-11-06 23:53:27 +0100 | acidjnk | (~acidjnk@p200300d6e72b93215d0d304e1b7de813.dip0.t-ipconnect.de) (Ping timeout: 240 seconds) |
| 2023-11-06 23:54:59 +0100 | gmg | (~user@user/gehmehgeh) (Quit: Leaving) |
| 2023-11-06 23:58:58 +0100 | end` | end |
| 2023-11-06 23:59:13 +0100 | end | end` |