| 2022-01-18 00:01:39 +0100 | alx741 | (~alx741@157.100.93.160) |
| 2022-01-18 00:05:09 +0100 | alx741 | (~alx741@157.100.93.160) (Read error: Connection reset by peer) |
| 2022-01-18 00:11:21 +0100 | jkaye | (~jkaye@2601:281:8300:7530:443b:68a:5f3e:dbe3) |
| 2022-01-18 00:11:36 +0100 | DNH | (~DNH@2a02:8108:1100:16d8:6155:4b1c:4cef:c11c) |
| 2022-01-18 00:11:40 +0100 | chomwitt | (~chomwitt@2a02:587:dc0b:200:12c3:7bff:fe6d:d374) (Remote host closed the connection) |
| 2022-01-18 00:15:26 +0100 | wyrd | (~wyrd@gateway/tor-sasl/wyrd) (Remote host closed the connection) |
| 2022-01-18 00:15:44 +0100 | wyrd | (~wyrd@gateway/tor-sasl/wyrd) |
| 2022-01-18 00:18:34 +0100 | eggplantade | (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) (Remote host closed the connection) |
| 2022-01-18 00:19:43 +0100 | Inst | (~delicacie@c-98-208-218-119.hsd1.fl.comcast.net) (Ping timeout: 256 seconds) |
| 2022-01-18 00:20:02 +0100 | wroathe | (~wroathe@user/wroathe) (Ping timeout: 240 seconds) |
| 2022-01-18 00:20:12 +0100 | eggplantade | (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) |
| 2022-01-18 00:22:40 +0100 | __monty__ | (~toonn@user/toonn) (Quit: leaving) |
| 2022-01-18 00:23:16 +0100 | alx741 | (~alx741@157.100.93.160) |
| 2022-01-18 00:23:37 +0100 | jkaye | (~jkaye@2601:281:8300:7530:443b:68a:5f3e:dbe3) (Ping timeout: 240 seconds) |
| 2022-01-18 00:24:47 +0100 | mmhat | (~mmh@55d4d096.access.ecotel.net) (Quit: WeeChat 3.4) |
| 2022-01-18 00:26:46 +0100 | alx741 | (~alx741@157.100.93.160) (Read error: Connection reset by peer) |
| 2022-01-18 00:26:54 +0100 | ksqsf | (~user@134.209.106.31) |
| 2022-01-18 00:28:40 +0100 | burnsidesLlama | (~burnsides@dhcp168-045.wadham.ox.ac.uk) (Remote host closed the connection) |
| 2022-01-18 00:28:45 +0100 | wroathe | (~wroathe@206-55-188-8.fttp.usinternet.com) |
| 2022-01-18 00:28:45 +0100 | wroathe | (~wroathe@206-55-188-8.fttp.usinternet.com) (Changing host) |
| 2022-01-18 00:28:45 +0100 | wroathe | (~wroathe@user/wroathe) |
| 2022-01-18 00:32:11 +0100 | ksqsf | (~user@134.209.106.31) (Ping timeout: 256 seconds) |
| 2022-01-18 00:33:02 +0100 | wroathe | (~wroathe@user/wroathe) (Ping timeout: 240 seconds) |
| 2022-01-18 00:34:09 +0100 | jgeerds | (~jgeerds@55d4090e.access.ecotel.net) |
| 2022-01-18 00:34:26 +0100 | cosimone | (~user@2001:b07:ae5:db26:c24a:d20:4d91:1e20) (Ping timeout: 250 seconds) |
| 2022-01-18 00:34:50 +0100 | geekosaur | (~geekosaur@xmonad/geekosaur) (Quit: Leaving) |
| 2022-01-18 00:35:59 +0100 | geekosaur | (~geekosaur@xmonad/geekosaur) |
| 2022-01-18 00:37:57 +0100 | yauhsien | (~yauhsien@61-231-62-246.dynamic-ip.hinet.net) |
| 2022-01-18 00:43:17 +0100 | alx741 | (~alx741@157.100.93.160) |
| 2022-01-18 00:43:46 +0100 | Tuplanolla | (~Tuplanoll@91-159-68-166.elisa-laajakaista.fi) (Quit: Leaving.) |
| 2022-01-18 00:46:42 +0100 | alx741 | (~alx741@157.100.93.160) (Read error: Connection reset by peer) |
| 2022-01-18 00:48:56 +0100 | burnsidesLlama | (~burnsides@dhcp168-045.wadham.ox.ac.uk) |
| 2022-01-18 00:49:02 +0100 | machinedgod | (~machinedg@24.105.81.50) (Ping timeout: 240 seconds) |
| 2022-01-18 00:51:39 +0100 | <Axman6> | Is there a name in lens for the function which takes Traversal s t a b, (a -> m b) and s and gives back m t? I know it's just `traversal func s` but it feels weird using it's sort of hidden structure |
| 2022-01-18 00:52:13 +0100 | <Axman6> | @hoogle Traversal s t a b -> (a -> m b) -> s -> m t -- probably should've done this first |
| 2022-01-18 00:52:13 +0100 | <lambdabot> | No results found |
| 2022-01-18 00:52:17 +0100 | <dibblego> | id |
| 2022-01-18 00:54:05 +0100 | <Axman6> | just wondering if it has a more... semantic? name |
| 2022-01-18 00:54:39 +0100 | <Axman6> | looks like traverseOf |
| 2022-01-18 00:54:53 +0100 | <Axman6> | traverseOf :: LensLike f s t a b -> (a -> f b) -> s -> f t |
| 2022-01-18 00:54:53 +0100 | <Axman6> | traverseOf = id |
| 2022-01-18 00:56:55 +0100 | waleee | (~waleee@2001:9b0:21d:fc00:398f:b003:b90d:acf4) |
| 2022-01-18 00:58:49 +0100 | Vajb | (~Vajb@hag-jnsbng11-58c3a8-176.dhcp.inet.fi) (Read error: Connection reset by peer) |
| 2022-01-18 00:58:58 +0100 | Vajb | (~Vajb@hag-jnsbng11-58c3a8-176.dhcp.inet.fi) |
| 2022-01-18 00:59:07 +0100 | max22- | (~maxime@2a01cb088335980081b93665fb35a9cb.ipv6.abo.wanadoo.fr) (Remote host closed the connection) |
| 2022-01-18 01:02:04 +0100 | DNH | (~DNH@2a02:8108:1100:16d8:6155:4b1c:4cef:c11c) (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 2022-01-18 01:02:17 +0100 | n3rdy1 | (~n3rdy1@2600:1700:4570:3480:1b88:50f:dae0:9293) (Ping timeout: 240 seconds) |
| 2022-01-18 01:03:19 +0100 | alx741 | (~alx741@157.100.93.160) |
| 2022-01-18 01:06:53 +0100 | Shiranai | (~Shiranai@190.237.13.17) |
| 2022-01-18 01:07:11 +0100 | alx741 | (~alx741@157.100.93.160) (Read error: Connection reset by peer) |
| 2022-01-18 01:07:55 +0100 | <Axman6> | it is also (%%~) |
| 2022-01-18 01:09:07 +0100 | <Shiranai> | Hello, I want to compute the list of differences of a Int list, i.e. `difs [1,3,6] == [2,4]`. I can do this by pattern matching but I'm wondering if there is some way to do if by using folds or maps |
| 2022-01-18 01:09:37 +0100 | <c_wraith> | Shiranai: it's typical to do it with a zip |
| 2022-01-18 01:09:41 +0100 | <monochrom> | Does it mean difs [a,b,c,d] = [b-a, c-b, d-c]? |
| 2022-01-18 01:09:53 +0100 | <jackdk> | monochrom: no d-c |
| 2022-01-18 01:09:56 +0100 | <Shiranai> | monochrom yes |
| 2022-01-18 01:10:03 +0100 | <jackdk> | Shiranai: what is `difs []`? |
| 2022-01-18 01:10:18 +0100 | <Shiranai> | jackdk [] |
| 2022-01-18 01:10:38 +0100 | <Shiranai> | same with `difs [n]` |
| 2022-01-18 01:11:02 +0100 | <jackdk> | Shiranai: you can write it as a map after zipping the list with its own tail, but you'll need to handle the empty list separately |
| 2022-01-18 01:11:17 +0100 | merijn | (~merijn@c-001-002-002.client.esciencecenter.eduvpn.nl) |
| 2022-01-18 01:11:18 +0100 | <monochrom> | [b-a, c-b, d-c] = zipWith (-) [b,c,d] [a,b,c,d] |
| 2022-01-18 01:11:18 +0100 | <c_wraith> | jackdk: nap, zip handles the empty list |
| 2022-01-18 01:11:29 +0100 | <Axman6> | > zipWith f [a,b,c] [d,e,f] |
| 2022-01-18 01:11:30 +0100 | <c_wraith> | Err. *nah*. |
| 2022-01-18 01:11:30 +0100 | <lambdabot> | error: |
| 2022-01-18 01:11:30 +0100 | <lambdabot> | • Ambiguous type variable ‘c0’ arising from a use of ‘show_M421258202089... |
| 2022-01-18 01:11:30 +0100 | <lambdabot> | prevents the constraint ‘(Show c0)’ from being solved. |
| 2022-01-18 01:11:36 +0100 | <Axman6> | > zipWith f [a,b,c] [d,e,f] :: [Expr] |
| 2022-01-18 01:11:37 +0100 | <lambdabot> | [f a d,f b e,f c f] |
| 2022-01-18 01:11:57 +0100 | <jackdk> | c_wraith: but `tail` doesn't |
| 2022-01-18 01:12:10 +0100 | <geekosaur> | your f is ambiguous there |
| 2022-01-18 01:12:17 +0100 | [itchyjunk] | (~itchyjunk@user/itchyjunk/x-7353470) (Ping timeout: 240 seconds) |
| 2022-01-18 01:12:18 +0100 | <c_wraith> | jackdk: but zip/zipWith does. The order it examines its arguments in is defined. |
| 2022-01-18 01:12:24 +0100 | <Axman6> | iif you're careful zipWith won't evaluate the tail [] |
| 2022-01-18 01:12:27 +0100 | <c_wraith> | > zipWith [] undefined |
| 2022-01-18 01:12:28 +0100 | <monochrom> | Consider "drop 1" |
| 2022-01-18 01:12:29 +0100 | <lambdabot> | error: |
| 2022-01-18 01:12:29 +0100 | <lambdabot> | • Couldn't match expected type ‘a1 -> b -> c’ |
| 2022-01-18 01:12:29 +0100 | <lambdabot> | with actual type ‘[a0]’ |
| 2022-01-18 01:12:36 +0100 | <c_wraith> | > zipWith (+) [] undefined |
| 2022-01-18 01:12:37 +0100 | <lambdabot> | [] |
| 2022-01-18 01:12:45 +0100 | <jackdk> | wow, TIL. cool. |
| 2022-01-18 01:12:46 +0100 | <c_wraith> | No special cases needed |
| 2022-01-18 01:12:48 +0100 | <Shiranai> | yeah I think I need to cover the [] case with an if-statement and then dothe zip thing |
| 2022-01-18 01:12:58 +0100 | <Shiranai> | ooo |
| 2022-01-18 01:13:00 +0100 | <Shiranai> | nice |
| 2022-01-18 01:13:03 +0100 | <jackdk> | until five seconds ago I would've agreed with you |
| 2022-01-18 01:13:06 +0100 | <Axman6> | nope, no need to use if here at all |
| 2022-01-18 01:13:22 +0100 | <monochrom> | c_wraith: May I entice you with a prank algebra exercise? Expand and simplify (x-a)(x-b)(x-c)...(x-z). >:) |
| 2022-01-18 01:13:22 +0100 | <Axman6> | if is almost always a code smell in haskell too |
| 2022-01-18 01:13:37 +0100 | biog | (~user1@159.224.42.85) (Quit: ZZZzzz…) |
| 2022-01-18 01:13:47 +0100 | <geekosaur> | 0 |
| 2022-01-18 01:13:53 +0100 | <Axman6> | I set x = a, and get ... 0 |
| 2022-01-18 01:14:03 +0100 | <Axman6> | hmmm, I feel tricked |
| 2022-01-18 01:14:08 +0100 | <geekosaur> | don;t even need that, x-x is in the middle of it |
| 2022-01-18 01:14:15 +0100 | Adran | (~adran@botters/adran) (Quit: Este é o fim.) |
| 2022-01-18 01:14:24 +0100 | <Axman6> | yeah. I've been had! |
| 2022-01-18 01:14:25 +0100 | <monochrom> | This is similar to the "f c f" there. >:) |
| 2022-01-18 01:15:31 +0100 | <Axman6> | > product $ zipWith (-) (repeat x) [a,b,c,d,e,f,g] :: Expr |
| 2022-01-18 01:15:32 +0100 | <lambdabot> | 1 * (x - a) * (x - b) * (x - c) * (x - d) * (x - e) * (x - f) * (x - g) |
| 2022-01-18 01:15:57 +0100 | <Axman6> | > iterate simplify $ (product $ zipWith (-) (repeat x) [a,b,c,d,e,f,g] :: Expr) |
| 2022-01-18 01:15:59 +0100 | <lambdabot> | error: |
| 2022-01-18 01:15:59 +0100 | <lambdabot> | • Variable not in scope: simplify :: Expr -> Expr |
| 2022-01-18 01:15:59 +0100 | <lambdabot> | • Perhaps you meant ‘simply’ (imported from Control.Lens) |
| 2022-01-18 01:16:13 +0100 | <Axman6> | of course lens has something called simply |
| 2022-01-18 01:16:21 +0100 | <geekosaur> | ^5 |
| 2022-01-18 01:16:29 +0100 | [itchyjunk] | (~itchyjunk@user/itchyjunk/x-7353470) |
| 2022-01-18 01:16:34 +0100 | little_mac | (~little_ma@2601:410:4300:3ce0:ed98:da79:669a:f2be) (Remote host closed the connection) |
| 2022-01-18 01:17:06 +0100 | <jackdk> | Axman6: and in keeping with today's theme, it is yet another `id` |
| 2022-01-18 01:17:08 +0100 | <Axman6> | simply :: forall p f s a rep (r :: TYPE rep). (Optic' p f s a -> r) -> Optic' p f s a -> r -- | This is an adverb that can be used to modify many other Lens combinators to make them require simple lenses, simple traversals, simple prisms or simple isos as input. |
| 2022-01-18 01:17:28 +0100 | Axman6 | glares at edwardk |
| 2022-01-18 01:17:44 +0100 | <jackdk> | the real prank is that everything in lens is actually `id` (/s) |
| 2022-01-18 01:19:11 +0100 | <Axman6> | :t id id id id id id id id |
| 2022-01-18 01:19:12 +0100 | <lambdabot> | a -> a |
| 2022-01-18 01:20:28 +0100 | edwardk | feels his neck burning and looks up. |
| 2022-01-18 01:20:34 +0100 | <Axman6> | from :: AnIso s t a b -> Iso b a t s <- this is what got us into this whole COVID mess in the first place! |
| 2022-01-18 01:20:49 +0100 | <jackdk> | "how many `id`s have we got in this lib, anyhow?" (with apologies to Mel Brooks and Col. Sandurz) |
| 2022-01-18 01:21:00 +0100 | ksqsf | (~user@134.209.106.31) |
| 2022-01-18 01:21:05 +0100 | <edwardk> | Axman6: it just 'id', so 'simply' seems well named |
| 2022-01-18 01:21:38 +0100 | <Axman6> | I just feel like I've been pranked half the time I look at lens' definitions and it's always id |
| 2022-01-18 01:21:45 +0100 | <edwardk> | =) |
| 2022-01-18 01:21:58 +0100 | Adran | (~adran@botters/adran) |
| 2022-01-18 01:22:10 +0100 | <edwardk> | if you ignore the newtypes even more of its definitions are just id in disguise |
| 2022-01-18 01:22:50 +0100 | <Axman6> | "It turns out all we actually needed from SKI was I" |
| 2022-01-18 01:24:55 +0100 | dka | (~code-is-a@ns3059207.ip-193-70-33.eu) (Quit: My Ex-Girlfriend once told me: I'm not a slut, I'm just popular) |
| 2022-01-18 01:24:56 +0100 | alx741 | (~alx741@157.100.93.160) |
| 2022-01-18 01:25:01 +0100 | <awpr> | so I just accidentally wrote a maybe-kinda-useful extensible records library while trying to write a joke extensible records library: https://replit.com/@AndrewPritchard/ImplicitParamRecords2#Main.hs |
| 2022-01-18 01:25:31 +0100 | dka | (~code-is-a@ns3059207.ip-193-70-33.eu) |
| 2022-01-18 01:25:32 +0100 | ksqsf | (~user@134.209.106.31) (Ping timeout: 240 seconds) |
| 2022-01-18 01:25:46 +0100 | <geekosaur> | now I'm wondering if that's how lens started out :þ |
| 2022-01-18 01:26:47 +0100 | <awpr> | the central idea: if I horribly abuse ImplicitParams to represent the fields, then GHC's constraint solver will do all the "hard" work of plumbing fields around for me |
| 2022-01-18 01:27:39 +0100 | <awpr> | why you should use it over _any other inferior extensible records library_: it ~~accidentally~~totally on purpose has something equivalent to RecordWildCards. |
| 2022-01-18 01:27:41 +0100 | <boxscape_> | vulkan let's me create a SurfaceKHR which is a newtype over Word64, but for GLFW-b, I need a Ptr instead. What's the proper way to convert a Word64 into a Ptr? (I'm assuming the Word64 is simply the memory address) |
| 2022-01-18 01:28:19 +0100 | <Axman6> | what's IP stand for? |
| 2022-01-18 01:28:21 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) |
| 2022-01-18 01:28:43 +0100 | <awpr> | that's the internal class under the hood for ImplicitParams: `?aoeu :: Int` is actually `IP "aoeu" Int` |
| 2022-01-18 01:28:43 +0100 | alx741 | (~alx741@157.100.93.160) (Read error: Connection reset by peer) |
| 2022-01-18 01:29:45 +0100 | <boxscape_> | ...alternatively, is there a way to create a fresh Ptr for an arbitrary type? |
| 2022-01-18 01:30:52 +0100 | Shiranai | (~Shiranai@190.237.13.17) (Quit: Connection closed) |
| 2022-01-18 01:31:23 +0100 | zmt01 | (~zmt00@user/zmt00) |
| 2022-01-18 01:31:31 +0100 | <boxscape_> | (without allocating any memory for it) |
| 2022-01-18 01:31:41 +0100 | <EvanR> | boxscape_, Word64... really... |
| 2022-01-18 01:32:01 +0100 | <jackdk> | convert to Word, and use WordPtr newtype, then wordPtrToPtr? |
| 2022-01-18 01:32:03 +0100 | <EvanR> | well, it might be coercable |
| 2022-01-18 01:32:10 +0100 | <boxscape_> | I can try that |
| 2022-01-18 01:32:13 +0100 | <boxscape_> | thanks |
| 2022-01-18 01:32:13 +0100 | <jackdk> | haven't done ffi for a while, ymmv |
| 2022-01-18 01:32:34 +0100 | ksqsf | (~user@134.209.106.31) |
| 2022-01-18 01:32:37 +0100 | zmt00 | (~zmt00@user/zmt00) (Ping timeout: 240 seconds) |
| 2022-01-18 01:32:50 +0100 | aplainze1akind | (~johndoe@captainludd.powered.by.lunarbnc.net) |
| 2022-01-18 01:32:54 +0100 | <Axman6> | awpr: I hate this, it just feels like data soup, there's no structure D: but it works, and I'm curious how well it works and performs |
| 2022-01-18 01:33:11 +0100 | <jackdk> | docs for distributive say: Categorically every Distributive functor is actually a right adjoint, and so it must be Representable endofunctor and preserve all limits. This is a fancy way of saying it isomorphic to (->) x for some x. this means Distributive and Representable are equivalent concepts on Hask? |
| 2022-01-18 01:33:32 +0100 | xff0x | (~xff0x@2001:1a81:53cb:cc00:be2f:4794:e7a4:33cb) (Ping timeout: 240 seconds) |
| 2022-01-18 01:33:41 +0100 | <awpr> | I have no idea other than that it seems to work for the examples at the bottom of the file. I don't have any plans to use it for anything beyond entertainment though |
| 2022-01-18 01:33:43 +0100 | <jackdk> | I assume this is not the case on Hask^Hask -> Hask (I've been thinking about rank2 representable as a way to index record fields with a GADT) |
| 2022-01-18 01:33:48 +0100 | waleee | (~waleee@2001:9b0:21d:fc00:398f:b003:b90d:acf4) (Ping timeout: 250 seconds) |
| 2022-01-18 01:34:28 +0100 | <awpr> | jackdk, that's https://hackage.haskell.org/package/ten-0.1.0.2/docs/Data-Ten-Representable.html#t:Representable10 FWIW |
| 2022-01-18 01:34:49 +0100 | xff0x | (~xff0x@2001:1a81:53cb:cc00:10bf:48ef:429:dca8) |
| 2022-01-18 01:34:55 +0100 | hamishmack_ | (sid389057@id-389057.hampstead.irccloud.com) (Ping timeout: 268 seconds) |
| 2022-01-18 01:34:59 +0100 | <Axman6> | maybe ImplicitParams died too early (even if they do live on in the stack traces' implementation) |
| 2022-01-18 01:35:03 +0100 | Jon | (jon@dow.land) (Quit: ZNC - http://znc.in) |
| 2022-01-18 01:35:04 +0100 | Hobbyboy | (Hobbyboy@hobbyboy.co.uk) (Quit: The BNC has broken!) |
| 2022-01-18 01:35:24 +0100 | <jackdk> | awpr: another one! I was only aware of rank2classes, conkin, and barbies. |
| 2022-01-18 01:35:32 +0100 | ProofTechnique | (sid79547@id-79547.ilkley.irccloud.com) (Ping timeout: 268 seconds) |
| 2022-01-18 01:35:32 +0100 | amir | (sid22336@user/amir) (Ping timeout: 268 seconds) |
| 2022-01-18 01:35:33 +0100 | <awpr> | I think future versions of https://hackage.haskell.org/package/hkd-0.1/docs/Data-HKD.html are slated to have something equivalent too? |
| 2022-01-18 01:35:38 +0100 | <jackdk> | thanks for the link. a shame none seem to be canonical |
| 2022-01-18 01:36:10 +0100 | cstml[m] | (~cstmlmatr@2001:470:69fc:105::1:5c07) (Ping timeout: 268 seconds) |
| 2022-01-18 01:36:10 +0100 | jmcantrell | (~jmcantrel@user/jmcantrell) (Ping timeout: 268 seconds) |
| 2022-01-18 01:36:10 +0100 | Topik[m] | (~topikmatr@2001:470:69fc:105::a082) (Ping timeout: 268 seconds) |
| 2022-01-18 01:36:10 +0100 | jneira[m] | (~jneiramat@2001:470:69fc:105::d729) (Ping timeout: 268 seconds) |
| 2022-01-18 01:36:11 +0100 | Nate[m]1 | (~m52957mat@2001:470:69fc:105::1:591a) (Ping timeout: 268 seconds) |
| 2022-01-18 01:36:11 +0100 | marinelli[m] | (~marinelli@2001:470:69fc:105::2d8) (Ping timeout: 268 seconds) |
| 2022-01-18 01:36:11 +0100 | eoiles[m] | (~eoilesmat@2001:470:69fc:105::1:6164) (Ping timeout: 268 seconds) |
| 2022-01-18 01:36:11 +0100 | kadoban | (~kadoban@user/kadoban) (Ping timeout: 268 seconds) |
| 2022-01-18 01:36:11 +0100 | wildsebastian | (~wildsebas@2001:470:69fc:105::1:14b1) (Ping timeout: 268 seconds) |
| 2022-01-18 01:36:11 +0100 | aidy | (~aidy@2001:470:69fc:105::c7b4) (Ping timeout: 268 seconds) |
| 2022-01-18 01:36:11 +0100 | vaibhavsagar[m] | (~vaibhavsa@2001:470:69fc:105::ffe) (Ping timeout: 268 seconds) |
| 2022-01-18 01:36:11 +0100 | benjamin[m]1234 | (~benjaminm@2001:470:69fc:105::1:3f2f) (Ping timeout: 268 seconds) |
| 2022-01-18 01:36:11 +0100 | IgnatInsarov[m] | (~kindaroma@2001:470:69fc:105::f5d9) (Ping timeout: 268 seconds) |
| 2022-01-18 01:36:11 +0100 | carmysilna | (~brightly-@2001:470:69fc:105::2190) (Ping timeout: 268 seconds) |
| 2022-01-18 01:36:11 +0100 | kawzeg | (kawzeg@2a01:7e01::f03c:92ff:fee2:ec34) (Ping timeout: 268 seconds) |
| 2022-01-18 01:36:11 +0100 | hexagoxel | (~hexagoxel@2a01:4f8:c0c:e::2) (Ping timeout: 268 seconds) |
| 2022-01-18 01:36:17 +0100 | mrmonday | (~robert@what.i.hope.is.not.a.tabernaevagant.es) (Ping timeout: 240 seconds) |
| 2022-01-18 01:36:32 +0100 | raehik | (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) (Ping timeout: 240 seconds) |
| 2022-01-18 01:36:41 +0100 | <awpr> | huh, I didn't find rank2classes when I surveyed the ecosystem... amusingly its description is extremely similar to mine |
| 2022-01-18 01:36:46 +0100 | hsiktas[m] | (~hsiktasm]@2001:470:69fc:105::30d4) (Ping timeout: 268 seconds) |
| 2022-01-18 01:36:46 +0100 | aplainzetakind | (~johndoe@captainludd.powered.by.lunarbnc.net) (Ping timeout: 268 seconds) |
| 2022-01-18 01:36:46 +0100 | cyphase | (~cyphase@user/cyphase) (Ping timeout: 268 seconds) |
| 2022-01-18 01:36:46 +0100 | maralorn | (~maralorn@2001:470:69fc:105::251) (Ping timeout: 268 seconds) |
| 2022-01-18 01:36:46 +0100 | siraben | (~siraben@user/siraben) (Ping timeout: 268 seconds) |
| 2022-01-18 01:36:46 +0100 | parseval | (sid239098@id-239098.helmsley.irccloud.com) (Ping timeout: 268 seconds) |
| 2022-01-18 01:36:46 +0100 | oxytocat | (~alloca@user/suppi) (Ping timeout: 268 seconds) |
| 2022-01-18 01:36:46 +0100 | krjst | (~krjst@2604:a880:800:c1::16b:8001) (Ping timeout: 268 seconds) |
| 2022-01-18 01:36:46 +0100 | thonkpod | (~thonkpod@user/thonkpod) (Ping timeout: 268 seconds) |
| 2022-01-18 01:36:55 +0100 | hamishmack_ | (sid389057@id-389057.hampstead.irccloud.com) |
| 2022-01-18 01:37:02 +0100 | ksqsf | (~user@134.209.106.31) (Ping timeout: 240 seconds) |
| 2022-01-18 01:37:15 +0100 | robertm | (robertm@lattice.rojoma.com) (Ping timeout: 250 seconds) |
| 2022-01-18 01:37:15 +0100 | zaquest | (~notzaques@5.130.79.72) (Remote host closed the connection) |
| 2022-01-18 01:37:37 +0100 | waleee-cl | (~waleee@2001:9b0:21d:fc00:398f:b003:b90d:acf4) |
| 2022-01-18 01:37:51 +0100 | kawzeg | (kawzeg@2a01:7e01::f03c:92ff:fee2:ec34) |
| 2022-01-18 01:37:57 +0100 | ProofTechnique | (sid79547@id-79547.ilkley.irccloud.com) |
| 2022-01-18 01:38:02 +0100 | parseval | (sid239098@id-239098.helmsley.irccloud.com) |
| 2022-01-18 01:38:03 +0100 | amir | (sid22336@user/amir) |
| 2022-01-18 01:38:04 +0100 | mrmonday | (~robert@what.i.hope.is.not.a.tabernaevagant.es) |
| 2022-01-18 01:38:05 +0100 | <awpr> | I'd love for `ten` to become canonical (afaik it's as complete as any other one), but it looks like `hkd` will win by virtue of `lens` depending on it in the moderate future |
| 2022-01-18 01:38:08 +0100 | cyphase | (~cyphase@user/cyphase) |
| 2022-01-18 01:38:08 +0100 | oxytocat | (~alloca@user/suppi) |
| 2022-01-18 01:38:25 +0100 | thonkpod | (~thonkpod@user/thonkpod) |
| 2022-01-18 01:38:25 +0100 | Jon | (jon@dow.land) |
| 2022-01-18 01:38:30 +0100 | <jackdk> | at least hkd doesn't have that awful Identity-erasing type familyy |
| 2022-01-18 01:38:53 +0100 | <jackdk> | why does `lens` need to depend on `hkd`? |
| 2022-01-18 01:38:54 +0100 | hexagoxel | (~hexagoxel@hexagoxel.de) |
| 2022-01-18 01:38:56 +0100 | robertm | (robertm@lattice.rojoma.com) |
| 2022-01-18 01:39:01 +0100 | <awpr> | yeah, people seem to love that thing for reasons I can't understand |
| 2022-01-18 01:39:01 +0100 | krjst | (~krjst@2604:a880:800:c1::16b:8001) |
| 2022-01-18 01:39:03 +0100 | Hobbyboy | (Hobbyboy@hobbyboy.co.uk) |
| 2022-01-18 01:39:03 +0100 | zaquest | (~notzaques@5.130.79.72) |
| 2022-01-18 01:39:28 +0100 | <jackdk> | because they don't reach a point where the inconsistency it introduces becomes painful |
| 2022-01-18 01:39:28 +0100 | <awpr> | (re: `hkd` becoming canonical) in which case I'll probably just try to get the novel stuff from `ten` absorbed into `hkd` |
| 2022-01-18 01:40:34 +0100 | <boxscape_> | actually I lied, I do need to allocate the memory, so maybe I should just use Foreign.Marshal.Alloc.malloc. Only problem is I'm not sure there's a way to programmatically find out how much memory I need for SurfaceKHR, but I guess I'll just have to rely on them never changing the size |
| 2022-01-18 01:40:53 +0100 | <awpr> | IIUC the reason for growing the dependency is that `distributive` can be expressed in a much more performant way by being built on top of HKD ideas, with the core method being `Functor10 f => f g -> g (f Identity)` |
| 2022-01-18 01:40:55 +0100 | <boxscape_> | s/malloc/mallocBytes |
| 2022-01-18 01:41:06 +0100 | <jackdk> | awpr: you don't seem to have contravariant, and nobody seems to have divisible and decidable , but I don't know if those are useful for at rank2 |
| 2022-01-18 01:41:29 +0100 | yauhsien | (~yauhsien@61-231-62-246.dynamic-ip.hinet.net) (Ping timeout: 256 seconds) |
| 2022-01-18 01:41:38 +0100 | <awpr> | yeah, true, I typed it in but left it commented out because I didn't have a use for it at the time |
| 2022-01-18 01:42:07 +0100 | <awpr> | also don't know if Divisible10 and Decidable10 would be useful |
| 2022-01-18 01:43:48 +0100 | <boxscape_> | ah, never mind, I suppose I can use malloc because it's Storable, solving that issue |
| 2022-01-18 01:44:42 +0100 | <jackdk> | awpr: I like that you have variants of sequenceA etc that are ergonomic when you have Identity kicking around |
| 2022-01-18 01:44:57 +0100 | waleee-cl | (~waleee@2001:9b0:21d:fc00:398f:b003:b90d:acf4) (Ping timeout: 240 seconds) |
| 2022-01-18 01:44:57 +0100 | alx741 | (~alx741@157.100.93.160) |
| 2022-01-18 01:45:32 +0100 | <monochrom> | identity strikes again, this time at the type level too :) |
| 2022-01-18 01:45:33 +0100 | <awpr> | yeah, tbh I just wasn't sure which form was more useful, so I threw both in there. the names get a bit dense though |
| 2022-01-18 01:45:49 +0100 | Nate[m]1 | (~m52957mat@2001:470:69fc:105::1:591a) |
| 2022-01-18 01:45:51 +0100 | merijn | (~merijn@c-001-002-002.client.esciencecenter.eduvpn.nl) (Ping timeout: 256 seconds) |
| 2022-01-18 01:46:09 +0100 | cstml[m] | (~cstmlmatr@2001:470:69fc:105::1:5c07) |
| 2022-01-18 01:46:12 +0100 | jneira[m] | (~jneiramat@2001:470:69fc:105::d729) |
| 2022-01-18 01:46:17 +0100 | carmysilna | (~brightly-@2001:470:69fc:105::2190) |
| 2022-01-18 01:46:26 +0100 | jmcantrell | (~jmcantrel@user/jmcantrell) |
| 2022-01-18 01:47:15 +0100 | <awpr> | the main thing in `ten` that I'm not aware of any other library doing well is dealing with constraints that are common to every field type: `fmap10C @Show (Const . show)` says if you have a record where every field has a Show instance, then you can just go and 'show' each field with relatively little fanfare |
| 2022-01-18 01:48:00 +0100 | <jackdk> | https://hackage.haskell.org/package/constraints-extras gives you that, and gets used a bit in the DMapverse |
| 2022-01-18 01:48:39 +0100 | kadoban | (~kadoban@user/kadoban) |
| 2022-01-18 01:48:56 +0100 | <awpr> | ah yeah, looks like a very similar implementation |
| 2022-01-18 01:49:21 +0100 | alx741 | (~alx741@157.100.93.160) (Read error: Connection reset by peer) |
| 2022-01-18 01:50:16 +0100 | kaph | (~kaph@net-2-47-208-144.cust.vodafonedsl.it) (Ping timeout: 250 seconds) |
| 2022-01-18 01:50:30 +0100 | <awpr> | along the same lines, https://hackage.haskell.org/package/ten-unordered-containers is similar functionality to DMap except with a valid license |
| 2022-01-18 01:50:30 +0100 | <jackdk> | but if hkd is going to be everywhere because it's depended on by the 500lb gorilla of teh haskell depgraph, then the best thing to do may be to pump your best ideas into that? |
| 2022-01-18 01:50:56 +0100 | <awpr> | yeah, that's probably the direction it'll end up going |
| 2022-01-18 01:52:24 +0100 | wildsebastian | (~wildsebas@2001:470:69fc:105::1:14b1) |
| 2022-01-18 01:52:29 +0100 | <jackdk> | interesting to see these libraries coming out with Google copyrights and recent dates. Have they started adopting more Haskell? |
| 2022-01-18 01:52:37 +0100 | eoiles[m] | (~eoilesmat@2001:470:69fc:105::1:6164) |
| 2022-01-18 01:52:38 +0100 | Topik[m] | (~topikmatr@2001:470:69fc:105::a082) |
| 2022-01-18 01:52:40 +0100 | vaibhavsagar[m] | (~vaibhavsa@2001:470:69fc:105::ffe) |
| 2022-01-18 01:52:42 +0100 | IgnatInsarov[m] | (~kindaroma@2001:470:69fc:105::f5d9) |
| 2022-01-18 01:52:42 +0100 | <awpr> | well I've started open-sourcing more Haskell |
| 2022-01-18 01:52:43 +0100 | marinelli[m] | (~marinelli@2001:470:69fc:105::2d8) |
| 2022-01-18 01:52:53 +0100 | wroathe | (~wroathe@206-55-188-8.fttp.usinternet.com) |
| 2022-01-18 01:52:53 +0100 | wroathe | (~wroathe@206-55-188-8.fttp.usinternet.com) (Changing host) |
| 2022-01-18 01:52:53 +0100 | wroathe | (~wroathe@user/wroathe) |
| 2022-01-18 01:53:42 +0100 | benjamin[m]1234 | (~benjaminm@2001:470:69fc:105::1:3f2f) |
| 2022-01-18 01:54:16 +0100 | aidy | (~aidy@2001:470:69fc:105::c7b4) |
| 2022-01-18 01:54:43 +0100 | maralorn | (~maralorn@2001:470:69fc:105::251) |
| 2022-01-18 01:54:43 +0100 | siraben | (~siraben@user/siraben) |
| 2022-01-18 01:55:20 +0100 | <jackdk> | noice |
| 2022-01-18 01:55:23 +0100 | hsiktas[m] | (~hsiktasm]@2001:470:69fc:105::30d4) |
| 2022-01-18 01:58:06 +0100 | zfnmxt | (~zfnmxtzfn@2001:470:69fc:105::2b32) (Changing host) |
| 2022-01-18 01:58:06 +0100 | zfnmxt | (~zfnmxtzfn@user/zfnmxt) |
| 2022-01-18 01:59:32 +0100 | jgeerds | (~jgeerds@55d4090e.access.ecotel.net) (Ping timeout: 240 seconds) |
| 2022-01-18 02:01:25 +0100 | lavaman | (~lavaman@98.38.249.169) |
| 2022-01-18 02:01:47 +0100 | machinedgod | (~machinedg@24.105.81.50) |
| 2022-01-18 02:04:01 +0100 | ksqsf | (~user@134.209.106.31) |
| 2022-01-18 02:05:32 +0100 | lavaman | (~lavaman@98.38.249.169) (Ping timeout: 240 seconds) |
| 2022-01-18 02:07:17 +0100 | zebrag | (~chris@user/zebrag) (Quit: Konversation terminated!) |
| 2022-01-18 02:07:29 +0100 | alx741 | (~alx741@157.100.93.160) |
| 2022-01-18 02:08:32 +0100 | ksqsf | (~user@134.209.106.31) (Ping timeout: 240 seconds) |
| 2022-01-18 02:09:05 +0100 | Shiranai | (~Shiranai@190.237.13.17) |
| 2022-01-18 02:09:27 +0100 | <Shiranai> | Why can't I eta reduce `f x = (*3) $ div 2 x` to `f = (*3) $ div 2`? |
| 2022-01-18 02:09:44 +0100 | alx741 | (~alx741@157.100.93.160) (Read error: Connection reset by peer) |
| 2022-01-18 02:10:08 +0100 | <Axman6> | )@src ($) |
| 2022-01-18 02:10:11 +0100 | <Axman6> | @src ($) |
| 2022-01-18 02:10:11 +0100 | <lambdabot> | f $ x = f x |
| 2022-01-18 02:10:31 +0100 | <Axman6> | div 2 is the argument x |
| 2022-01-18 02:10:55 +0100 | <Axman6> | so what you've written is ((*3) (div 2)) |
| 2022-01-18 02:11:16 +0100 | pavonia | (~user@user/siracusa) |
| 2022-01-18 02:11:24 +0100 | <Axman6> | which is ((\n ->n*3) (\p -> div 2 p)) |
| 2022-01-18 02:11:28 +0100 | albet70 | (~xxx@2400:8902::f03c:92ff:fe60:98d8) (Remote host closed the connection) |
| 2022-01-18 02:11:50 +0100 | <Axman6> | you _can_ write (*3) . div 2 |
| 2022-01-18 02:11:55 +0100 | <Axman6> | @src (.) |
| 2022-01-18 02:11:55 +0100 | <lambdabot> | (f . g) x = f (g x) |
| 2022-01-18 02:12:02 +0100 | CiaoSen | (~Jura@p200300c95737a2002a3a4dfffe84dbd5.dip0.t-ipconnect.de) (Ping timeout: 240 seconds) |
| 2022-01-18 02:12:53 +0100 | <Shiranai> | ohh got it, thanks! |
| 2022-01-18 02:14:38 +0100 | <Axman6> | it's worth going through this exercise, translating both expressions and see what you get back - what does ((\n ->n*3) (\p -> div 2 p)) become? |
| 2022-01-18 02:15:33 +0100 | wroathe | (~wroathe@user/wroathe) (Read error: Connection reset by peer) |
| 2022-01-18 02:16:02 +0100 | Rembane | (~Rembane@li346-36.members.linode.com) (Ping timeout: 265 seconds) |
| 2022-01-18 02:16:10 +0100 | Rembane | (~Rembane@li346-36.members.linode.com) |
| 2022-01-18 02:16:59 +0100 | fiddlerwoaroof | (~fiddlerwo@user/fiddlerwoaroof) (Quit: Gone.) |
| 2022-01-18 02:17:00 +0100 | justJustache | (~justache@user/justache) (Remote host closed the connection) |
| 2022-01-18 02:17:28 +0100 | waleee-cl | (~waleee@2001:9b0:21d:fc00:398f:b003:b90d:acf4) |
| 2022-01-18 02:17:35 +0100 | albet70 | (~xxx@2400:8902::f03c:92ff:fe60:98d8) |
| 2022-01-18 02:18:00 +0100 | justJustache | (~justache@user/justache) |
| 2022-01-18 02:18:05 +0100 | bens | (~bens@www.typius.com) (Ping timeout: 268 seconds) |
| 2022-01-18 02:18:17 +0100 | fiddlerwoaroof | (~fiddlerwo@user/fiddlerwoaroof) |
| 2022-01-18 02:18:28 +0100 | bens | (~bens@www.typius.com) |
| 2022-01-18 02:20:46 +0100 | wroathe | (~wroathe@206-55-188-8.fttp.usinternet.com) |
| 2022-01-18 02:20:46 +0100 | wroathe | (~wroathe@206-55-188-8.fttp.usinternet.com) (Changing host) |
| 2022-01-18 02:20:46 +0100 | wroathe | (~wroathe@user/wroathe) |
| 2022-01-18 02:24:08 +0100 | ksqsf | (~user@134.209.106.31) |
| 2022-01-18 02:24:32 +0100 | machinedgod | (~machinedg@24.105.81.50) (Ping timeout: 240 seconds) |
| 2022-01-18 02:24:48 +0100 | ec | (~ec@gateway/tor-sasl/ec) (Ping timeout: 276 seconds) |
| 2022-01-18 02:25:55 +0100 | ec | (~ec@gateway/tor-sasl/ec) |
| 2022-01-18 02:26:36 +0100 | alx741 | (~alx741@157.100.93.160) |
| 2022-01-18 02:31:08 +0100 | alx741 | (~alx741@157.100.93.160) (Read error: Connection reset by peer) |
| 2022-01-18 02:32:19 +0100 | ProfSimm | (~ProfSimm@87.227.196.109) (Ping timeout: 256 seconds) |
| 2022-01-18 02:44:26 +0100 | cross_ | cross |
| 2022-01-18 02:46:02 +0100 | Gurkenglas | (~Gurkengla@dslb-002-203-144-204.002.203.pools.vodafone-ip.de) (Ping timeout: 240 seconds) |
| 2022-01-18 02:47:46 +0100 | alx741 | (~alx741@157.100.93.160) |
| 2022-01-18 02:48:20 +0100 | lavaman | (~lavaman@98.38.249.169) |
| 2022-01-18 02:49:17 +0100 | xsperry | (~xs@user/xsperry) (Remote host closed the connection) |
| 2022-01-18 02:50:24 +0100 | xsperry | (~xs@user/xsperry) |
| 2022-01-18 02:51:47 +0100 | alx741 | (~alx741@157.100.93.160) (Read error: Connection reset by peer) |
| 2022-01-18 02:55:58 +0100 | Shiranai | (~Shiranai@190.237.13.17) (Quit: Connection closed) |
| 2022-01-18 02:58:37 +0100 | mvk | (~mvk@2607:fea8:5cdd:f000::55f8) (Ping timeout: 240 seconds) |
| 2022-01-18 02:58:44 +0100 | Erutuon | (~Erutuon@user/erutuon) (Ping timeout: 250 seconds) |
| 2022-01-18 02:58:57 +0100 | SlowLearner | (~SlowLearn@2804:14c:65a1:452d:faeb:2e8a:da33:265f) (Ping timeout: 256 seconds) |
| 2022-01-18 03:01:50 +0100 | Erutuon | (~Erutuon@user/erutuon) |
| 2022-01-18 03:02:08 +0100 | werneta | (~werneta@70-142-214-115.lightspeed.irvnca.sbcglobal.net) (Quit: Lost terminal) |
| 2022-01-18 03:04:15 +0100 | werneta | (~werneta@70-142-214-115.lightspeed.irvnca.sbcglobal.net) |
| 2022-01-18 03:05:49 +0100 | califax- | (~califax@user/califx) |
| 2022-01-18 03:08:45 +0100 | slack1256 | (~slack1256@186.11.99.46) (Ping timeout: 256 seconds) |
| 2022-01-18 03:08:55 +0100 | alx741 | (~alx741@157.100.93.160) |
| 2022-01-18 03:10:18 +0100 | califax | (~califax@user/califx) (Ping timeout: 276 seconds) |
| 2022-01-18 03:10:19 +0100 | califax- | califax |
| 2022-01-18 03:10:44 +0100 | kaph | (~kaph@net-2-47-208-144.cust.vodafonedsl.it) |
| 2022-01-18 03:11:27 +0100 | alx741 | (~alx741@157.100.93.160) (Read error: Connection reset by peer) |
| 2022-01-18 03:12:19 +0100 | deadmarshal | (~deadmarsh@95.38.228.70) |
| 2022-01-18 03:16:32 +0100 | deadmarshal | (~deadmarsh@95.38.228.70) (Ping timeout: 240 seconds) |
| 2022-01-18 03:18:40 +0100 | waleee-cl | (~waleee@2001:9b0:21d:fc00:398f:b003:b90d:acf4) (Ping timeout: 250 seconds) |
| 2022-01-18 03:20:32 +0100 | alp | (~alp@user/alp) (Ping timeout: 240 seconds) |
| 2022-01-18 03:22:08 +0100 | xff0x | (~xff0x@2001:1a81:53cb:cc00:10bf:48ef:429:dca8) (Ping timeout: 250 seconds) |
| 2022-01-18 03:24:02 +0100 | xff0x | (~xff0x@2001:1a81:5209:df00:e795:8bea:73be:6c45) |
| 2022-01-18 03:24:17 +0100 | neurocyte0917090 | (~neurocyte@IP-185189141194.dynamic.medianet-world.de) |
| 2022-01-18 03:24:17 +0100 | neurocyte0917090 | (~neurocyte@IP-185189141194.dynamic.medianet-world.de) (Changing host) |
| 2022-01-18 03:24:17 +0100 | neurocyte0917090 | (~neurocyte@user/neurocyte) |
| 2022-01-18 03:26:01 +0100 | <alexfmpe[m]> | @free x :: Int |
| 2022-01-18 03:26:01 +0100 | <lambdabot> | x = x |
| 2022-01-18 03:26:02 +0100 | neurocyte091709 | (~neurocyte@user/neurocyte) (Ping timeout: 240 seconds) |
| 2022-01-18 03:26:02 +0100 | neurocyte0917090 | neurocyte091709 |
| 2022-01-18 03:28:02 +0100 | alx741 | (~alx741@157.100.93.160) |
| 2022-01-18 03:28:23 +0100 | ksqsf | (~user@134.209.106.31) (Ping timeout: 268 seconds) |
| 2022-01-18 03:31:06 +0100 | waleee-cl | (~waleee@2001:9b0:21d:fc00:398f:b003:b90d:acf4) |
| 2022-01-18 03:31:21 +0100 | <Axman6> | awpr: I feel at least a blog post is deserved from that record thing |
| 2022-01-18 03:31:55 +0100 | lavaman | (~lavaman@98.38.249.169) (Remote host closed the connection) |
| 2022-01-18 03:32:08 +0100 | lavaman | (~lavaman@98.38.249.169) |
| 2022-01-18 03:38:19 +0100 | ksqsf | (~user@134.209.106.31) |
| 2022-01-18 03:41:44 +0100 | merijn | (~merijn@c-001-001-018.client.esciencecenter.eduvpn.nl) |
| 2022-01-18 03:43:32 +0100 | ksqsf | (~user@134.209.106.31) (Ping timeout: 240 seconds) |
| 2022-01-18 03:55:04 +0100 | waleee-cl | (~waleee@2001:9b0:21d:fc00:398f:b003:b90d:acf4) (Ping timeout: 250 seconds) |
| 2022-01-18 03:57:40 +0100 | <Axman6> | Anyone know if anyone has written a linker in Haskell? |
| 2022-01-18 04:01:12 +0100 | nunggu | (~q@user/nunggu) |
| 2022-01-18 04:02:59 +0100 | tomku | (~tomku@user/tomku) (Read error: Connection reset by peer) |
| 2022-01-18 04:03:48 +0100 | <jackdk> | what are you thinking of Axman6 |
| 2022-01-18 04:05:26 +0100 | little_mac | (~little_ma@2601:410:4300:3ce0:ed98:da79:669a:f2be) |
| 2022-01-18 04:06:15 +0100 | <Axman6> | I was reading https://maskray.me/blog/2021-12-19-why-isnt-ld.lld-faster and thinking "Surely linking is just tying the knot" |
| 2022-01-18 04:07:34 +0100 | tomku | (~tomku@user/tomku) |
| 2022-01-18 04:08:02 +0100 | Erutuon | (~Erutuon@user/erutuon) (Ping timeout: 240 seconds) |
| 2022-01-18 04:10:25 +0100 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) (Killed (NickServ (Forcing logout FinnElija -> finn_elija))) |
| 2022-01-18 04:10:25 +0100 | finn_elija | (~finn_elij@user/finn-elija/x-0085643) |
| 2022-01-18 04:10:25 +0100 | finn_elija | FinnElija |
| 2022-01-18 04:11:24 +0100 | ec | (~ec@gateway/tor-sasl/ec) (Ping timeout: 276 seconds) |
| 2022-01-18 04:15:04 +0100 | Everything | (~Everythin@46-133-77-215.mobile.vf-ua.net) (Quit: leaving) |
| 2022-01-18 04:16:11 +0100 | merijn | (~merijn@c-001-001-018.client.esciencecenter.eduvpn.nl) (Ping timeout: 256 seconds) |
| 2022-01-18 04:19:44 +0100 | ksqsf | (~user@134.209.106.31) |
| 2022-01-18 04:21:25 +0100 | pretty_dumm_guy | (trottel@gateway/vpn/protonvpn/prettydummguy/x-88029655) (Quit: WeeChat 3.4) |
| 2022-01-18 04:24:41 +0100 | ksqsf | (~user@134.209.106.31) (Ping timeout: 256 seconds) |
| 2022-01-18 04:27:32 +0100 | raym | (~raym@user/raym) (Ping timeout: 240 seconds) |
| 2022-01-18 04:29:36 +0100 | raym | (~raym@user/raym) |
| 2022-01-18 04:35:51 +0100 | td_ | (~td@94.134.91.126) (Ping timeout: 256 seconds) |
| 2022-01-18 04:37:12 +0100 | little_mac | (~little_ma@2601:410:4300:3ce0:ed98:da79:669a:f2be) (Remote host closed the connection) |
| 2022-01-18 04:37:30 +0100 | little_mac | (~little_ma@2601:410:4300:3ce0:c076:ae6d:3ec6:202c) |
| 2022-01-18 04:37:32 +0100 | td_ | (~td@muedsl-82-207-238-179.citykom.de) |
| 2022-01-18 04:41:00 +0100 | geranim0 | (~geranim0@modemcable242.171-178-173.mc.videotron.ca) (Ping timeout: 250 seconds) |
| 2022-01-18 04:46:35 +0100 | <lagash> | "First comes love..." |
| 2022-01-18 04:51:42 +0100 | mbuf | (~Shakthi@136.185.86.67) |
| 2022-01-18 04:52:44 +0100 | mbuf | (~Shakthi@136.185.86.67) (Remote host closed the connection) |
| 2022-01-18 04:54:48 +0100 | Jing | (~hedgehog@240e:390:7c53:a7e1:a9:59ba:3231:6160) |
| 2022-01-18 04:56:36 +0100 | little_mac | (~little_ma@2601:410:4300:3ce0:c076:ae6d:3ec6:202c) (Ping timeout: 250 seconds) |
| 2022-01-18 04:57:56 +0100 | mbuf | (~Shakthi@136.185.86.67) |
| 2022-01-18 05:05:02 +0100 | ksqsf | (~user@134.209.106.31) |
| 2022-01-18 05:06:01 +0100 | jackson99 | (~bc8147f2@cerf.good1.com) |
| 2022-01-18 05:06:46 +0100 | vysn | (~vysn@user/vysn) |
| 2022-01-18 05:09:32 +0100 | ksqsf | (~user@134.209.106.31) (Ping timeout: 240 seconds) |
| 2022-01-18 05:12:27 +0100 | burnsidesLlama | (~burnsides@dhcp168-045.wadham.ox.ac.uk) (Remote host closed the connection) |
| 2022-01-18 05:13:03 +0100 | <Axman6> | Then comes code... |
| 2022-01-18 05:16:48 +0100 | yauhsien | (~yauhsien@61-231-62-246.dynamic-ip.hinet.net) |
| 2022-01-18 05:21:51 +0100 | yauhsien | (~yauhsien@61-231-62-246.dynamic-ip.hinet.net) (Ping timeout: 268 seconds) |
| 2022-01-18 05:31:49 +0100 | dyeplexer | (~dyeplexer@user/dyeplexer) |
| 2022-01-18 05:36:28 +0100 | ezzieyguywuf | (~Unknown@user/ezzieyguywuf) (Ping timeout: 250 seconds) |
| 2022-01-18 05:37:12 +0100 | jinsun__ | (~quassel@user/jinsun) |
| 2022-01-18 05:38:33 +0100 | ezzieyguywuf | (~Unknown@user/ezzieyguywuf) |
| 2022-01-18 05:39:09 +0100 | alMalsamo | (~alMalsamo@gateway/tor-sasl/almalsamo) (Ping timeout: 276 seconds) |
| 2022-01-18 05:41:01 +0100 | jinsun | (~quassel@user/jinsun) (Ping timeout: 256 seconds) |
| 2022-01-18 05:41:48 +0100 | Erutuon | (~Erutuon@user/erutuon) |
| 2022-01-18 05:43:45 +0100 | <Axman6> | awpr: ... why ten/10? |
| 2022-01-18 05:44:31 +0100 | <Axman6> | ah, not in the README but is in Data.Ten - reading |
| 2022-01-18 05:47:37 +0100 | emf | (~emf@2620:10d:c090:400::5:2d26) (Ping timeout: 240 seconds) |
| 2022-01-18 05:50:20 +0100 | emf | (~emf@2620:10d:c090:400::5:2d26) |
| 2022-01-18 05:53:58 +0100 | ksqsf | (~user@134.209.106.31) |
| 2022-01-18 05:58:32 +0100 | ksqsf | (~user@134.209.106.31) (Ping timeout: 240 seconds) |
| 2022-01-18 05:59:54 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Quit: = "") |
| 2022-01-18 06:01:14 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) |
| 2022-01-18 06:01:35 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Client Quit) |
| 2022-01-18 06:01:56 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) |
| 2022-01-18 06:06:05 +0100 | slack1256 | (~slack1256@186.11.99.46) |
| 2022-01-18 06:08:43 +0100 | jenna8912 | (~jenna@c-107-5-104-51.hsd1.mi.comcast.net) |
| 2022-01-18 06:11:50 +0100 | ksqsf | (~user@134.209.106.31) |
| 2022-01-18 06:12:29 +0100 | troydm | (~troydm@host-176-37-124-197.b025.la.net.ua) (Ping timeout: 252 seconds) |
| 2022-01-18 06:12:30 +0100 | merijn | (~merijn@c-001-001-018.client.esciencecenter.eduvpn.nl) |
| 2022-01-18 06:16:11 +0100 | deadmarshal | (~deadmarsh@95.38.228.70) |
| 2022-01-18 06:16:46 +0100 | ksqsf | (~user@134.209.106.31) (Ping timeout: 250 seconds) |
| 2022-01-18 06:21:26 +0100 | troydm | (~troydm@host-176-37-124-197.b025.la.net.ua) |
| 2022-01-18 06:21:48 +0100 | boxscape_ | (~boxscape_@p4ff0b9d5.dip0.t-ipconnect.de) (Quit: Connection closed) |
| 2022-01-18 06:23:27 +0100 | <awpr> | hmm, the GitHub repo README is more thorough, but not shown on Hackage. I should find a way to get that included (I think it's just extra-source-files, but this README is in the directory above the package, so it might take an extra symlink or copy or something) |
| 2022-01-18 06:23:30 +0100 | <awpr> | https://github.com/google/hs-ten/issues/6 |
| 2022-01-18 06:23:34 +0100 | ksqsf | (~user@134.209.106.31) |
| 2022-01-18 06:30:55 +0100 | ksqsf | (~user@134.209.106.31) (Ping timeout: 268 seconds) |
| 2022-01-18 06:36:28 +0100 | wroathe | (~wroathe@user/wroathe) (Ping timeout: 268 seconds) |
| 2022-01-18 06:38:26 +0100 | dyeplexer | (~dyeplexer@user/dyeplexer) (Ping timeout: 250 seconds) |
| 2022-01-18 06:43:36 +0100 | bens | (~bens@www.typius.com) (Quit: leaving) |
| 2022-01-18 06:44:18 +0100 | <Axman6> | Great, thanks :) |
| 2022-01-18 06:44:59 +0100 | wroathe | (~wroathe@206-55-188-8.fttp.usinternet.com) |
| 2022-01-18 06:44:59 +0100 | wroathe | (~wroathe@206-55-188-8.fttp.usinternet.com) (Changing host) |
| 2022-01-18 06:44:59 +0100 | wroathe | (~wroathe@user/wroathe) |
| 2022-01-18 06:44:59 +0100 | gentauro | (~gentauro@user/gentauro) (Read error: Connection reset by peer) |
| 2022-01-18 06:45:19 +0100 | gentauro | (~gentauro@user/gentauro) |
| 2022-01-18 06:46:57 +0100 | merijn | (~merijn@c-001-001-018.client.esciencecenter.eduvpn.nl) (Ping timeout: 268 seconds) |
| 2022-01-18 06:48:02 +0100 | vysn | (~vysn@user/vysn) (Ping timeout: 240 seconds) |
| 2022-01-18 06:49:32 +0100 | wroathe | (~wroathe@user/wroathe) (Ping timeout: 240 seconds) |
| 2022-01-18 06:49:42 +0100 | arjun_ | (~arjun@user/arjun) |
| 2022-01-18 06:50:18 +0100 | mvk | (~mvk@2607:fea8:5cdd:f000::55f8) |
| 2022-01-18 06:50:42 +0100 | <arjun_> | hi |
| 2022-01-18 06:50:59 +0100 | <arjun_> | what's the least painful way to bound a type range? |
| 2022-01-18 06:51:21 +0100 | <arjun_> | if i want a type that only is Float 0.0 to 1.0 and would error on range outside it |
| 2022-01-18 06:57:42 +0100 | ksqsf | (~user@134.209.106.31) |
| 2022-01-18 06:59:15 +0100 | slowButPresent | (~slowButPr@user/slowbutpresent) (Quit: leaving) |
| 2022-01-18 06:59:50 +0100 | <c_wraith> | if Float/Double weren't pariahs at the type level, I'd say the refined package. But they are, so... not that. |
| 2022-01-18 07:00:19 +0100 | <arjun_> | what's even a pariah? : P |
| 2022-01-18 07:01:12 +0100 | <jackdk> | c_wraith is saying that you can't have typelevel Float/Double like you can Int |
| 2022-01-18 07:01:44 +0100 | <c_wraith> | pariah - someone/something that must be avoided. |
| 2022-01-18 07:01:45 +0100 | <jackdk> | I would probably write `data Clamped a = Clamped { cMin :: a, cMax :: a, cVal :: a }` |
| 2022-01-18 07:01:49 +0100 | <arjun_> | i want to ask why but im scared lol |
| 2022-01-18 07:01:55 +0100 | werneta | (~werneta@70-142-214-115.lightspeed.irvnca.sbcglobal.net) (Quit: Lost terminal) |
| 2022-01-18 07:02:02 +0100 | <c_wraith> | I honestly have no idea. |
| 2022-01-18 07:02:21 +0100 | <c_wraith> | I don't know why GHC didn't promote all the primitive types when it promoted String and Integer |
| 2022-01-18 07:02:59 +0100 | ksqsf | (~user@134.209.106.31) (Ping timeout: 268 seconds) |
| 2022-01-18 07:03:12 +0100 | <arjun_> | i'd rather have them checked compile time rather than blowing at runtime or being have to carry around a smart constructor |
| 2022-01-18 07:03:32 +0100 | alMalsamo | (~alMalsamo@gateway/tor-sasl/almalsamo) |
| 2022-01-18 07:03:38 +0100 | <arjun_> | things like Type 0.3 + Type 0.4 should be allowed since they result in Type 0.7 |
| 2022-01-18 07:04:00 +0100 | <arjun_> | but Type 1.0 + Type 0.4 should be not since > 1.0 |
| 2022-01-18 07:04:02 +0100 | <c_wraith> | that seems... difficult... to do at compile time |
| 2022-01-18 07:04:24 +0100 | <c_wraith> | ie, it only would work with completely static paths |
| 2022-01-18 07:04:31 +0100 | <c_wraith> | um.. code paths |
| 2022-01-18 07:04:46 +0100 | <c_wraith> | Any time something might behave differently based on input, it would fail |
| 2022-01-18 07:07:04 +0100 | <arjun_> | refine seems alright |
| 2022-01-18 07:10:05 +0100 | <arjun_> | refined* |
| 2022-01-18 07:12:55 +0100 | <Axman6> | data Probability = Probability Word64 -- represents 1/n |
| 2022-01-18 07:12:58 +0100 | <Axman6> | >_> |
| 2022-01-18 07:13:18 +0100 | <Axman6> | hmm, I guess that makes 0.75 very difficult to represent |
| 2022-01-18 07:15:37 +0100 | <awpr> | if that's meant to be a way of mapping things onto [0,1) by definition: `newtype Unity = Unity Double -- represents 0.5 + 0.5*log(p/(1-p))` is one traditional way to do it. |
| 2022-01-18 07:17:05 +0100 | <Axman6> | > map (\p -> 0.5 + 0.5*log(p/(1-p))) [0,1,10,-1,-10] |
| 2022-01-18 07:17:07 +0100 | <lambdabot> | [-Infinity,Infinity,NaN,NaN,NaN] |
| 2022-01-18 07:17:31 +0100 | <Axman6> | > map (\p -> 0.5 + 0.5*log(p/(1-p))) [0.1,0.5,0.9] |
| 2022-01-18 07:17:32 +0100 | <lambdabot> | [-0.5986122886681096,0.5,1.5986122886681098] |
| 2022-01-18 07:17:35 +0100 | <arjun_> | it's not to map |
| 2022-01-18 07:17:47 +0100 | <awpr> | I got the specifics very wrong, but it's meant to turn "approaches infinity" into "approaches 1" and "approaches -infinity" into "approaches 0" |
| 2022-01-18 07:18:49 +0100 | <Axman6> | Interesting - would love to learn more |
| 2022-01-18 07:19:07 +0100 | <awpr> | > map (\a -> exp a / (1 + exp a)) [-1000, -100, -10, -1, 0, 1, 10, 100, 1000) |
| 2022-01-18 07:19:09 +0100 | <lambdabot> | <hint>:1:75: error: parse error on input ‘)’ |
| 2022-01-18 07:19:17 +0100 | <awpr> | > map (\a -> exp a / (1 + exp a)) [-1000, -100, -10, -1, 0, 1, 10, 100, 1000] |
| 2022-01-18 07:19:18 +0100 | <lambdabot> | [0.0,3.720075976020836e-44,4.5397868702434395e-5,0.2689414213699951,0.5,0.73... |
| 2022-01-18 07:19:55 +0100 | `2jt | (~jtomas@10.red-83-58-228.dynamicip.rima-tde.net) |
| 2022-01-18 07:21:36 +0100 | <awpr> | > map (\a -> realToFrac (exp a / (1 + exp a)) :: Fixed Milli) [-1000 :: Double, -100, -10, -1, 0, 1, 10, 100, 1000] |
| 2022-01-18 07:21:38 +0100 | <lambdabot> | error: |
| 2022-01-18 07:21:38 +0100 | <lambdabot> | Ambiguous occurrence ‘Fixed’ |
| 2022-01-18 07:21:38 +0100 | <lambdabot> | It could refer to |
| 2022-01-18 07:21:53 +0100 | <EvanR> | Axman6, egyptian fractions to the rescue or something |
| 2022-01-18 07:22:24 +0100 | ksqsf | (~user@134.209.106.31) |
| 2022-01-18 07:22:47 +0100 | <EvanR> | arjun_, if possible, make a new type for 0 to 1 and only have api functions that make sense for those, i.e. times but not plus |
| 2022-01-18 07:23:25 +0100 | <Axman6> | yeah you can't make a sensible Num instance for that |
| 2022-01-18 07:24:02 +0100 | <arjun_> | EvanR, how do i newtype a range? |
| 2022-01-18 07:25:11 +0100 | deadmarshal | (~deadmarsh@95.38.228.70) (Ping timeout: 268 seconds) |
| 2022-01-18 07:25:57 +0100 | <Axman6> | @hoogle log1p |
| 2022-01-18 07:25:57 +0100 | <lambdabot> | Numeric log1p :: Floating a => a -> a |
| 2022-01-18 07:25:57 +0100 | <lambdabot> | GHC.Float log1p :: Floating a => a -> a |
| 2022-01-18 07:25:57 +0100 | <lambdabot> | Protolude log1p :: Floating a => a -> a |
| 2022-01-18 07:29:03 +0100 | <EvanR> | arjun_, a new type wrapper allows you to control how values are constructed, gating them behind a check, in this case that they are in range |
| 2022-01-18 07:29:17 +0100 | <EvanR> | aol keyword "smart constructor" |
| 2022-01-18 07:29:42 +0100 | <EvanR> | that's a runtime techinque though |
| 2022-01-18 07:29:55 +0100 | <EvanR> | but it's not painful |
| 2022-01-18 07:31:17 +0100 | zmt01 | (~zmt00@user/zmt00) (Ping timeout: 240 seconds) |
| 2022-01-18 07:38:08 +0100 | kaph | (~kaph@net-2-47-208-144.cust.vodafonedsl.it) (Ping timeout: 268 seconds) |
| 2022-01-18 07:39:32 +0100 | notzmv | (~zmv@user/notzmv) (Ping timeout: 240 seconds) |
| 2022-01-18 07:40:14 +0100 | deadmarshal | (~deadmarsh@95.38.228.70) |
| 2022-01-18 07:44:05 +0100 | <arjun_> | > a new type wrapper allows you to control how values are constructed, gating them behind a check |
| 2022-01-18 07:44:07 +0100 | <lambdabot> | <hint>:1:7: error: parse error on input ‘type’ |
| 2022-01-18 07:44:09 +0100 | <arjun_> | i didn't know that |
| 2022-01-18 07:44:21 +0100 | <arjun_> | do you have an example the top of your head EvanR ? |
| 2022-01-18 07:46:28 +0100 | xff0x | (~xff0x@2001:1a81:5209:df00:e795:8bea:73be:6c45) (Ping timeout: 250 seconds) |
| 2022-01-18 07:46:32 +0100 | michalz | (~michalz@185.246.204.101) |
| 2022-01-18 07:46:50 +0100 | <arjun_> | nvm, i think i found it : p |
| 2022-01-18 07:46:53 +0100 | <arjun_> | https://www.haskell.org/tutorial/moretypes.html |
| 2022-01-18 07:47:15 +0100 | xff0x | (~xff0x@2001:1a81:5209:df00:1935:85e:8166:55b) |
| 2022-01-18 07:50:27 +0100 | alp | (~alp@user/alp) |
| 2022-01-18 07:53:47 +0100 | vglfr | (~vglfr@46.96.179.132) (Ping timeout: 256 seconds) |
| 2022-01-18 07:54:21 +0100 | hololeap | (~hololeap@user/hololeap) (Excess Flood) |
| 2022-01-18 07:55:43 +0100 | fef | (~thedawn@user/thedawn) |
| 2022-01-18 07:55:44 +0100 | _ht | (~quassel@2a02:a468:b619:1:c1f2:a735:3541:23f8) |
| 2022-01-18 07:55:46 +0100 | hololeap | (~hololeap@user/hololeap) |
| 2022-01-18 08:06:43 +0100 | fcc977 | (~kaph@151.19.243.144) |
| 2022-01-18 08:07:48 +0100 | slac19759 | (~slack1256@191.125.99.76) |
| 2022-01-18 08:09:35 +0100 | deadmarshal | (~deadmarsh@95.38.228.70) (Ping timeout: 268 seconds) |
| 2022-01-18 08:10:12 +0100 | slack1256 | (~slack1256@186.11.99.46) (Ping timeout: 268 seconds) |
| 2022-01-18 08:10:53 +0100 | mikoto-chan | (~mikoto-ch@213.177.151.239) |
| 2022-01-18 08:11:32 +0100 | max22- | (~maxime@2a01cb0883359800958d49fa3415ab33.ipv6.abo.wanadoo.fr) |
| 2022-01-18 08:15:03 +0100 | coot | (~coot@89-64-85-93.dynamic.chello.pl) |
| 2022-01-18 08:15:30 +0100 | fcc977 | (~kaph@151.19.243.144) (Remote host closed the connection) |
| 2022-01-18 08:15:50 +0100 | fcc977 | (~kaph@151.19.243.144) |
| 2022-01-18 08:17:35 +0100 | MajorBiscuit | (~MajorBisc@c-001-025-054.client.tudelft.eduvpn.nl) |
| 2022-01-18 08:18:18 +0100 | deadmarshal | (~deadmarsh@95.38.228.70) |
| 2022-01-18 08:19:50 +0100 | yauhsien | (~yauhsien@61-231-62-246.dynamic-ip.hinet.net) |
| 2022-01-18 08:22:33 +0100 | little_mac | (~little_ma@2601:410:4300:3ce0:6136:2d74:4238:7594) |
| 2022-01-18 08:23:06 +0100 | <arjun_> | anyway i can borrow or point to the fromInteger method of Double's Num ? :P |
| 2022-01-18 08:23:20 +0100 | <arjun_> | and _just_ the fromInteger method |
| 2022-01-18 08:26:02 +0100 | yauhsien | (~yauhsien@61-231-62-246.dynamic-ip.hinet.net) (Ping timeout: 240 seconds) |
| 2022-01-18 08:27:03 +0100 | foul_owl | (~kerry@94.140.8.107) (Ping timeout: 256 seconds) |
| 2022-01-18 08:32:02 +0100 | deadmarshal | (~deadmarsh@95.38.228.70) (Ping timeout: 240 seconds) |
| 2022-01-18 08:32:12 +0100 | mc47 | (~mc47@xmonad/TheMC47) |
| 2022-01-18 08:34:00 +0100 | wyrd | (~wyrd@gateway/tor-sasl/wyrd) (Ping timeout: 276 seconds) |
| 2022-01-18 08:37:02 +0100 | Erutuon | (~Erutuon@user/erutuon) (Ping timeout: 240 seconds) |
| 2022-01-18 08:37:39 +0100 | newsham | (~newsham@2603-800c-2d00-e994-c564-1d76-1f18-c3ec.res6.spectrum.com) |
| 2022-01-18 08:37:47 +0100 | <newsham> | ?bot |
| 2022-01-18 08:37:47 +0100 | <lambdabot> | :) |
| 2022-01-18 08:37:53 +0100 | <newsham> | > fix id |
| 2022-01-18 08:37:55 +0100 | <lambdabot> | *Exception: <<loop>> |
| 2022-01-18 08:38:00 +0100 | <newsham> | hi |
| 2022-01-18 08:40:01 +0100 | Erutuon | (~Erutuon@user/erutuon) |
| 2022-01-18 08:40:39 +0100 | foul_owl | (~kerry@97-126-11-68.tukw.qwest.net) |
| 2022-01-18 08:41:55 +0100 | shriekingnoise | (~shrieking@201.231.16.156) (Quit: Quit) |
| 2022-01-18 08:42:53 +0100 | cfricke | (~cfricke@user/cfricke) |
| 2022-01-18 08:42:58 +0100 | merijn | (~merijn@c-001-001-018.client.esciencecenter.eduvpn.nl) |
| 2022-01-18 08:53:54 +0100 | lortabac | (~lortabac@2a01:e0a:541:b8f0:8c5a:efae:38ab:4ad2) |
| 2022-01-18 08:55:16 +0100 | gehmehgeh | (~user@user/gehmehgeh) |
| 2022-01-18 08:55:56 +0100 | fcc977 | (~kaph@151.19.243.144) (Read error: Connection reset by peer) |
| 2022-01-18 08:58:18 +0100 | alp | (~alp@user/alp) (Ping timeout: 268 seconds) |
| 2022-01-18 08:59:21 +0100 | wagle | (~wagle@quassel.wagle.io) (Quit: http://quassel-irc.org - Chat comfortably. Anywhere.) |
| 2022-01-18 08:59:41 +0100 | fcc977 | (~kaph@151.43.53.126) |
| 2022-01-18 08:59:55 +0100 | wagle | (~wagle@quassel.wagle.io) |
| 2022-01-18 09:00:07 +0100 | deadmarshal | (~deadmarsh@95.38.228.70) |
| 2022-01-18 09:01:50 +0100 | kuribas | (~user@ptr-25vy0ia11vvy5vw4h88.18120a2.ip6.access.telenet.be) |
| 2022-01-18 09:01:50 +0100 | wagle | (~wagle@quassel.wagle.io) (Client Quit) |
| 2022-01-18 09:02:23 +0100 | wagle | (~wagle@quassel.wagle.io) |
| 2022-01-18 09:02:34 +0100 | o | (~niko@libera/staff/niko) |
| 2022-01-18 09:03:15 +0100 | fcc977 | (~kaph@151.43.53.126) (Remote host closed the connection) |
| 2022-01-18 09:04:32 +0100 | fcc977 | (~kaph@151.43.53.126) |
| 2022-01-18 09:05:00 +0100 | <hololeap> | is there a preferred way to stream data from a TCP connection, which can handle network errors, EOF, and the like? I'm looking at the connection library, but it seems like it's missing something to stream the incoming chunks into something like attoparsec and still deal with errors and closing the socket on EOF. |
| 2022-01-18 09:06:21 +0100 | <kuribas> | hololeap: conduit, streamly, pipes, etc... ? |
| 2022-01-18 09:06:41 +0100 | <kuribas> | any decent streaming library would give you that. |
| 2022-01-18 09:07:23 +0100 | alp | (~alp@user/alp) |
| 2022-01-18 09:07:49 +0100 | <kuribas> | https://hackage.haskell.org/package/conduit-extra-1.3.5 |
| 2022-01-18 09:07:51 +0100 | <hololeap> | sure, but those libraries don't seem to have any network-specific functions. this seems like something that would be common enough to have a preferred solution |
| 2022-01-18 09:07:57 +0100 | fcc977 | (~kaph@151.43.53.126) (Read error: Connection reset by peer) |
| 2022-01-18 09:08:11 +0100 | fcc977 | (~kaph@151.43.53.126) |
| 2022-01-18 09:08:17 +0100 | <kuribas> | https://hackage.haskell.org/package/conduit-extra-1.3.5/docs/Data-Conduit-Network.html |
| 2022-01-18 09:08:49 +0100 | <hololeap> | ok. I will add that I _did_ look at that and could not understand how to actually use it |
| 2022-01-18 09:09:40 +0100 | <kuribas> | there are probably tutorials somewhere. |
| 2022-01-18 09:10:03 +0100 | dhouthoo | (~dhouthoo@178-117-36-167.access.telenet.be) |
| 2022-01-18 09:11:11 +0100 | <kuribas> | If you first read a tutorial on using conduit, then the types for the more specific libraries should make more sense. |
| 2022-01-18 09:11:22 +0100 | <hololeap> | this looks like what I'm looking for, but it hasn't been updated in a couple years: https://hackage.haskell.org/package/conduit-connection-0.1.0.5/docs/Network-Connection-Conduit.htm… |
| 2022-01-18 09:11:34 +0100 | <hololeap> | I guess I'll just have to try it out |
| 2022-01-18 09:12:32 +0100 | <hololeap> | conduit makes sense, and I could probably build this myself, but it seems like _such_ a common problem that there must be a prebuilt solution. the Data.Conduit.Network module just confuses me |
| 2022-01-18 09:13:51 +0100 | <hololeap> | sourceSocket and sinkSocket make sense. the rest is just poorly documented |
| 2022-01-18 09:14:13 +0100 | <hololeap> | data AppData -- The data passed to an Application. |
| 2022-01-18 09:14:16 +0100 | <hololeap> | ok thanks |
| 2022-01-18 09:14:59 +0100 | [itchyjunk] | (~itchyjunk@user/itchyjunk/x-7353470) (Remote host closed the connection) |
| 2022-01-18 09:15:11 +0100 | <kuribas> | yeah, that module is poorly documented. |
| 2022-01-18 09:17:02 +0100 | merijn | (~merijn@c-001-001-018.client.esciencecenter.eduvpn.nl) (Ping timeout: 240 seconds) |
| 2022-01-18 09:20:45 +0100 | ubert1 | (~Thunderbi@p200300ecdf09949ebd4b43e35031000e.dip0.t-ipconnect.de) |
| 2022-01-18 09:24:24 +0100 | fcc977 | (~kaph@151.43.53.126) (Ping timeout: 250 seconds) |
| 2022-01-18 09:29:46 +0100 | Sgeo | (~Sgeo@user/sgeo) (Read error: Connection reset by peer) |
| 2022-01-18 09:30:13 +0100 | max22- | (~maxime@2a01cb0883359800958d49fa3415ab33.ipv6.abo.wanadoo.fr) (Remote host closed the connection) |
| 2022-01-18 09:32:32 +0100 | max22- | (~maxime@lfbn-ren-1-1026-62.w92-139.abo.wanadoo.fr) |
| 2022-01-18 09:34:48 +0100 | deadmarshal | (~deadmarsh@95.38.228.70) (Ping timeout: 250 seconds) |
| 2022-01-18 09:40:57 +0100 | wyrd | (~wyrd@gateway/tor-sasl/wyrd) |
| 2022-01-18 09:50:15 +0100 | machinedgod | (~machinedg@24.105.81.50) |
| 2022-01-18 09:50:43 +0100 | Erutuon | (~Erutuon@user/erutuon) (Ping timeout: 268 seconds) |
| 2022-01-18 09:51:16 +0100 | bontaq | (~user@ool-45779fe5.dyn.optonline.net) (Ping timeout: 250 seconds) |
| 2022-01-18 09:52:28 +0100 | notzmv | (~zmv@user/notzmv) |
| 2022-01-18 09:57:09 +0100 | n8chan | (~nate@108-233-125-227.lightspeed.sntcca.sbcglobal.net) (Ping timeout: 256 seconds) |
| 2022-01-18 09:59:16 +0100 | merijn | (~merijn@c-001-001-018.client.esciencecenter.eduvpn.nl) |
| 2022-01-18 10:00:20 +0100 | tromp | (~textual@dhcp-077-249-230-040.chello.nl) |
| 2022-01-18 10:03:36 +0100 | jgeerds | (~jgeerds@55d4090e.access.ecotel.net) |
| 2022-01-18 10:04:19 +0100 | chele | (~chele@user/chele) |
| 2022-01-18 10:07:58 +0100 | n8chan | (~nate@108-233-125-227.lightspeed.sntcca.sbcglobal.net) |
| 2022-01-18 10:09:47 +0100 | ksqsf | (~user@134.209.106.31) (Ping timeout: 256 seconds) |
| 2022-01-18 10:10:56 +0100 | Erutuon | (~Erutuon@user/erutuon) |
| 2022-01-18 10:11:46 +0100 | <hololeap> | conduit-connection at least compiles on my system, so that's a good sign |
| 2022-01-18 10:12:48 +0100 | wmacmil | (~wmacmil@83-233-165-97.cust.bredband2.com) |
| 2022-01-18 10:14:06 +0100 | wyrd | (~wyrd@gateway/tor-sasl/wyrd) (Ping timeout: 276 seconds) |
| 2022-01-18 10:15:14 +0100 | rusrushal13 | (~rusrushal@2401:4900:447e:3bb1:d351:e0e8:3fcf:bb54) |
| 2022-01-18 10:15:31 +0100 | Pickchea | (~private@user/pickchea) |
| 2022-01-18 10:16:51 +0100 | wyrd | (~wyrd@gateway/tor-sasl/wyrd) |
| 2022-01-18 10:17:40 +0100 | allbery_b | (~geekosaur@xmonad/geekosaur) |
| 2022-01-18 10:17:40 +0100 | geekosaur | (~geekosaur@xmonad/geekosaur) (Killed (NickServ (GHOST command used by allbery_b))) |
| 2022-01-18 10:17:43 +0100 | allbery_b | geekosaur |
| 2022-01-18 10:20:22 +0100 | vysn | (~vysn@user/vysn) |
| 2022-01-18 10:20:23 +0100 | rusrushal13 | (~rusrushal@2401:4900:447e:3bb1:d351:e0e8:3fcf:bb54) (Ping timeout: 256 seconds) |
| 2022-01-18 10:27:15 +0100 | timCF | (~timCF@200-149-20-81.sta.estpak.ee) |
| 2022-01-18 10:27:38 +0100 | lavaman | (~lavaman@98.38.249.169) (Remote host closed the connection) |
| 2022-01-18 10:27:52 +0100 | lavaman | (~lavaman@98.38.249.169) |
| 2022-01-18 10:28:00 +0100 | lavaman | (~lavaman@98.38.249.169) (Remote host closed the connection) |
| 2022-01-18 10:28:49 +0100 | deadmarshal | (~deadmarsh@95.38.228.70) |
| 2022-01-18 10:29:01 +0100 | <timCF> | Hello! Is there some type and corresponding transformer similar to Either/ExceptT which behaves similar way, but don't fail on first Left value, and keep going accumulating Left values into some sort of monoid, let's say a list? |
| 2022-01-18 10:30:07 +0100 | <merijn> | Validation from |
| 2022-01-18 10:30:10 +0100 | <merijn> | @hackage either |
| 2022-01-18 10:30:10 +0100 | <lambdabot> | https://hackage.haskell.org/package/either |
| 2022-01-18 10:31:14 +0100 | <timCF> | merijn: thanks! I knew it was there something like this, but totally forgot name. I guess I have to implement transformer myself if I need? |
| 2022-01-18 10:31:40 +0100 | <merijn> | arguably there is no transformer, because it's not a lawful Monad |
| 2022-01-18 10:31:46 +0100 | tzh | (~tzh@c-24-21-73-154.hsd1.wa.comcast.net) (Quit: zzz) |
| 2022-01-18 10:31:59 +0100 | <timCF> | aah, got it |
| 2022-01-18 10:34:04 +0100 | <lortabac> | there is also Errors in Control.Applicative.Lift |
| 2022-01-18 10:34:36 +0100 | Gurkenglas | (~Gurkengla@dslb-002-203-144-204.002.203.pools.vodafone-ip.de) |
| 2022-01-18 10:35:13 +0100 | <lortabac> | I've never used it though |
| 2022-01-18 10:36:02 +0100 | ksqsf | (~user@134.209.106.31) |
| 2022-01-18 10:36:33 +0100 | aplainze1akind | (~johndoe@captainludd.powered.by.lunarbnc.net) (Quit: Free ZNC ~ Powered by LunarBNC: https://LunarBNC.net) |
| 2022-01-18 10:36:45 +0100 | aplainzetakind | (~johndoe@captainludd.powered.by.lunarbnc.net) |
| 2022-01-18 10:38:27 +0100 | <timCF> | lortabac: I guess it's kinda the same like Validation? Allows independent applicative computations, but not if computations do depend on each other (monadic) |
| 2022-01-18 10:38:44 +0100 | Vajb | (~Vajb@hag-jnsbng11-58c3a8-176.dhcp.inet.fi) (Read error: Connection reset by peer) |
| 2022-01-18 10:39:09 +0100 | <merijn> | timCF: You can trivially convert between Validation and Either, though. So you can write some wrapper around >>= that unwraps and rewraps |
| 2022-01-18 10:39:54 +0100 | econo | (uid147250@user/econo) (Quit: Connection closed for inactivity) |
| 2022-01-18 10:40:23 +0100 | <lortabac> | timCF: I think so, but Validation is more widely used, so probably a better choice |
| 2022-01-18 10:41:02 +0100 | ksqsf | (~user@134.209.106.31) (Ping timeout: 240 seconds) |
| 2022-01-18 10:42:45 +0100 | eggplantade | (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) (Remote host closed the connection) |
| 2022-01-18 10:43:44 +0100 | <timCF> | I think I'll try Validation for now, at least it's clear how to replace Either in pure computations to simplify error accumulation |
| 2022-01-18 10:44:13 +0100 | <timCF> | Places with side-effects more tricky of course |
| 2022-01-18 10:45:15 +0100 | Vajb | (~Vajb@2001:999:50:e6be:1e98:9376:d93e:4506) |
| 2022-01-18 10:46:31 +0100 | <kuribas> | timCF: also checkout "these" |
| 2022-01-18 10:47:32 +0100 | <kuribas> | https://hackage.haskell.org/package/these |
| 2022-01-18 10:48:44 +0100 | takuan | (~takuan@178-116-218-225.access.telenet.be) |
| 2022-01-18 10:52:05 +0100 | <timCF> | kuribas: you mean ChronicleT? |
| 2022-01-18 10:52:27 +0100 | <kuribas> | yeah, ChrincleT is the transformer version of these. |
| 2022-01-18 10:53:02 +0100 | ubert1 | (~Thunderbi@p200300ecdf09949ebd4b43e35031000e.dip0.t-ipconnect.de) (Remote host closed the connection) |
| 2022-01-18 10:53:28 +0100 | <kuribas> | ChronicleT |
| 2022-01-18 10:53:35 +0100 | ksqsf | (~user@134.209.106.31) |
| 2022-01-18 10:53:43 +0100 | little_mac | (~little_ma@2601:410:4300:3ce0:6136:2d74:4238:7594) (Remote host closed the connection) |
| 2022-01-18 10:54:23 +0100 | jgeerds | (~jgeerds@55d4090e.access.ecotel.net) (Ping timeout: 256 seconds) |
| 2022-01-18 10:58:21 +0100 | ksqsf | (~user@134.209.106.31) (Ping timeout: 256 seconds) |
| 2022-01-18 10:58:31 +0100 | lavaman | (~lavaman@98.38.249.169) |
| 2022-01-18 11:02:19 +0100 | Akiva | (~Akiva@user/Akiva) (Ping timeout: 256 seconds) |
| 2022-01-18 11:02:25 +0100 | <hololeap> | at least Applicatives compose, so you can get a Validation "applicative transformer" |
| 2022-01-18 11:03:29 +0100 | lavaman | (~lavaman@98.38.249.169) (Ping timeout: 268 seconds) |
| 2022-01-18 11:03:32 +0100 | <hololeap> | you're just stuck with combining results, not chaining them |
| 2022-01-18 11:03:36 +0100 | alx741 | (~alx741@157.100.93.160) (Quit: alx741) |
| 2022-01-18 11:04:51 +0100 | <merijn> | Data.Functor.Compose :) |
| 2022-01-18 11:08:32 +0100 | foul_owl | (~kerry@97-126-11-68.tukw.qwest.net) (Ping timeout: 240 seconds) |
| 2022-01-18 11:10:20 +0100 | DNH | (~DNH@2a02:8108:1100:16d8:edf9:3833:cff9:92b3) |
| 2022-01-18 11:13:10 +0100 | Pickchea | (~private@user/pickchea) (Ping timeout: 250 seconds) |
| 2022-01-18 11:13:46 +0100 | ksqsf | (~user@134.209.106.31) |
| 2022-01-18 11:16:32 +0100 | xff0x | (~xff0x@2001:1a81:5209:df00:1935:85e:8166:55b) (Ping timeout: 240 seconds) |
| 2022-01-18 11:17:22 +0100 | xff0x | (~xff0x@2001:1a81:5209:df00:5e7c:4acd:2a77:4d24) |
| 2022-01-18 11:17:32 +0100 | deadmarshal | (~deadmarsh@95.38.228.70) (Ping timeout: 240 seconds) |
| 2022-01-18 11:18:55 +0100 | ksqsf | (~user@134.209.106.31) (Ping timeout: 256 seconds) |
| 2022-01-18 11:20:59 +0100 | deadmarshal | (~deadmarsh@95.38.228.70) |
| 2022-01-18 11:21:22 +0100 | arjun_ | (~arjun@user/arjun) (Ping timeout: 268 seconds) |
| 2022-01-18 11:22:29 +0100 | foul_owl | (~kerry@174-21-143-101.tukw.qwest.net) |
| 2022-01-18 11:31:04 +0100 | <hololeap> | oh, hey Validation is an example of a Selective functor |
| 2022-01-18 11:31:04 +0100 | Vajb | (~Vajb@2001:999:50:e6be:1e98:9376:d93e:4506) (Read error: Connection reset by peer) |
| 2022-01-18 11:31:12 +0100 | Vajb | (~Vajb@hag-jnsbng11-58c3a8-176.dhcp.inet.fi) |
| 2022-01-18 11:31:30 +0100 | <merijn> | All monad and applicatives are selective |
| 2022-01-18 11:31:42 +0100 | <merijn> | the real question is: Which ones have interesting selective instances :p |
| 2022-01-18 11:31:47 +0100 | machinedgod | (~machinedg@24.105.81.50) (Remote host closed the connection) |
| 2022-01-18 11:32:20 +0100 | <hololeap> | all monads are selective, but not all applicatives, I don't think. but I haven't grokked selective yet |
| 2022-01-18 11:32:55 +0100 | machinedgod | (~machinedg@24.105.81.50) |
| 2022-01-18 11:34:32 +0100 | Vajb | (~Vajb@hag-jnsbng11-58c3a8-176.dhcp.inet.fi) (Read error: Connection reset by peer) |
| 2022-01-18 11:34:46 +0100 | Vajb | (~Vajb@hag-jnsbng11-58c3a8-176.dhcp.inet.fi) |
| 2022-01-18 11:35:26 +0100 | <merijn> | hololeap: They are, because there's even a default implementation for Applicative :p |
| 2022-01-18 11:36:27 +0100 | <merijn> | See selectA |
| 2022-01-18 11:36:57 +0100 | <merijn> | The default Applicative/Monad implementation don't allow "proper" under-/overestimation |
| 2022-01-18 11:37:04 +0100 | <hololeap> | yeah, I'm looking at that now. it says: We can write a function with the type signature of select using the Applicative type class, but it will always execute the effects associated with the second argument, hence being potentially less efficient. |
| 2022-01-18 11:37:31 +0100 | <merijn> | hololeap: The same goes for Monad, though :) |
| 2022-01-18 11:37:45 +0100 | <hololeap> | no, it shouldn't |
| 2022-01-18 11:39:03 +0100 | <hololeap> | because you can peek into the contents of the monad and check if it is Left or Right, then execute the `f (a -> b)` only if it's needed |
| 2022-01-18 11:39:53 +0100 | fcc977 | (~kaph@151.43.53.126) |
| 2022-01-18 11:40:05 +0100 | ksqsf | (~user@134.209.106.31) |
| 2022-01-18 11:40:56 +0100 | <merijn> | Then you can't get Overapproximation, though? |
| 2022-01-18 11:41:22 +0100 | <hololeap> | I don't know what that means |
| 2022-01-18 11:41:38 +0100 | <hololeap> | is that from the paper? |
| 2022-01-18 11:41:41 +0100 | <merijn> | hololeap: Yeah |
| 2022-01-18 11:41:51 +0100 | <hololeap> | I haven't read it yet |
| 2022-01-18 11:42:10 +0100 | <hololeap> | I'm just looking at the types from the module |
| 2022-01-18 11:42:15 +0100 | Lord_of_Life_ | (~Lord@user/lord-of-life/x-2819915) |
| 2022-01-18 11:42:32 +0100 | <merijn> | hololeap: The point of selective is that you can inspect "what's the minimum effects guaranteed to execute" (underapproximation) vs "what is the maximum amount of effects executed?" (overapproximation) |
| 2022-01-18 11:43:07 +0100 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) (Ping timeout: 256 seconds) |
| 2022-01-18 11:43:20 +0100 | eggplantade | (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) |
| 2022-01-18 11:43:28 +0100 | fcc977 | (~kaph@151.43.53.126) (Client Quit) |
| 2022-01-18 11:43:41 +0100 | fcc977 | (~kaph@151.43.53.126) |
| 2022-01-18 11:44:19 +0100 | <hololeap> | well, with a Monad you can choose to execute the secondary effect and discard the `a -> b` result. with an Applicative you don't have that choice |
| 2022-01-18 11:44:56 +0100 | <hololeap> | the default implementation selectM just skips the execution of `y` if the inner value is Right: https://hackage.haskell.org/package/selective-0.5/docs/src/Control.Selective.html#selectM |
| 2022-01-18 11:45:05 +0100 | Lord_of_Life_ | Lord_of_Life |
| 2022-01-18 11:47:32 +0100 | eggplantade | (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) (Ping timeout: 240 seconds) |
| 2022-01-18 11:52:28 +0100 | <hololeap> | instance Monoid m => Applicative (Over m) where ... |
| 2022-01-18 11:52:46 +0100 | <hololeap> | how can you have a Monoid on something with the kind (Type -> Type)? |
| 2022-01-18 11:53:05 +0100 | <hololeap> | oh, no `a` is just a phantom type here |
| 2022-01-18 11:53:32 +0100 | kaph | (~kaph@151.43.53.126) |
| 2022-01-18 11:53:36 +0100 | <hololeap> | newtype Over m a = Over { getOver :: m } |
| 2022-01-18 11:53:53 +0100 | aeka | (~aeka@user/hiruji) (Read error: Connection reset by peer) |
| 2022-01-18 11:54:27 +0100 | fcc977 | (~kaph@151.43.53.126) (Ping timeout: 256 seconds) |
| 2022-01-18 11:56:55 +0100 | kaph | (~kaph@151.43.53.126) (Read error: Connection reset by peer) |
| 2022-01-18 11:57:11 +0100 | aeka | (~aeka@user/hiruji) |
| 2022-01-18 11:58:23 +0100 | kaph | (~kaph@151.43.53.126) |
| 2022-01-18 11:59:48 +0100 | <hololeap> | this seems like it could be interesting, although I don't quite understand it at the moment: https://hackage.haskell.org/package/selective-0.5/docs/src/Control.Selective.html#line-421 |
| 2022-01-18 12:00:57 +0100 | fef | (~thedawn@user/thedawn) (Remote host closed the connection) |
| 2022-01-18 12:01:24 +0100 | alx741 | (~alx741@157.100.93.160) |
| 2022-01-18 12:03:00 +0100 | kaph | (~kaph@151.43.53.126) (Remote host closed the connection) |
| 2022-01-18 12:03:09 +0100 | leibniz | (~leibniz@cpc101088-sgyl37-2-0-cust22.18-2.cable.virginm.net) |
| 2022-01-18 12:03:35 +0100 | <leibniz> | hi, is anyone online? i was asking something the other day but there was noone around |
| 2022-01-18 12:03:54 +0100 | raehik | (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) |
| 2022-01-18 12:04:01 +0100 | <hololeap> | 732 |
| 2022-01-18 12:04:23 +0100 | <leibniz> | similar to the number online then, i guess many are not infact real users |
| 2022-01-18 12:04:49 +0100 | <leibniz> | someone suggested it would be more likely to find actual people during the daytime |
| 2022-01-18 12:05:42 +0100 | <leibniz> | im just trying to find the question i asked in the logs, hang on |
| 2022-01-18 12:06:44 +0100 | <geekosaur> | many are real users, but IRC is 24/7 and people are around according to their timezones/work schedules |
| 2022-01-18 12:07:39 +0100 | <leibniz> | sorry i got distracted looking up Control.Selective which hololeap mentioned |
| 2022-01-18 12:09:16 +0100 | <Axman6> | leibniz: you definitely qwon't get any help if you dson't ask your question :) |
| 2022-01-18 12:09:39 +0100 | <leibniz> | i cant find it in the logs... |
| 2022-01-18 12:09:52 +0100 | <hololeap> | ax the axman |
| 2022-01-18 12:09:56 +0100 | <leibniz> | i probably didnt phrase it all that well anyway, i could try again i suppose |
| 2022-01-18 12:10:32 +0100 | <leibniz> | so you need to start with a listlike thing that has the tail wrapped in a monad |
| 2022-01-18 12:10:45 +0100 | <leibniz> | then you cant write a "lazy traverse" instance |
| 2022-01-18 12:11:01 +0100 | <leibniz> | since not all applicatives commute with the monad |
| 2022-01-18 12:11:08 +0100 | <Axman6> | sounds just like the various streaming/iteratee libraries |
| 2022-01-18 12:11:08 +0100 | <leibniz> | im wondering about this phenomina |
| 2022-01-18 12:11:42 +0100 | kaph | (~kaph@151.43.53.126) |
| 2022-01-18 12:11:53 +0100 | <leibniz> | the proposal is that for these monadically wrapped tail lists, that there should be something other than traverse |
| 2022-01-18 12:12:08 +0100 | <leibniz> | its much more high level as a consideration than a streaming library |
| 2022-01-18 12:12:24 +0100 | <Axman6> | they're all essentially some variiation of data Step m a r = Done r | Step a (m (Step m a r) |
| 2022-01-18 12:12:35 +0100 | <leibniz> | exactly |
| 2022-01-18 12:12:54 +0100 | <Axman6> | do you have example of the type you're talking about? |
| 2022-01-18 12:12:56 +0100 | <leibniz> | listT done right, i have seen it called |
| 2022-01-18 12:13:04 +0100 | <hololeap> | logict? |
| 2022-01-18 12:13:43 +0100 | <leibniz> | data MList' m a = MNil | a `MCons` MList m a |
| 2022-01-18 12:13:44 +0100 | <leibniz> | type MList m a = m (MList' m a) |
| 2022-01-18 12:13:44 +0100 | <leibniz> | newtype ListT m a = ListT { runListT :: MList m a } |
| 2022-01-18 12:13:54 +0100 | <leibniz> | from; https://wiki.haskell.org/ListT_done_right |
| 2022-01-18 12:14:33 +0100 | <Axman6> | that's essentially what Step above is |
| 2022-01-18 12:14:48 +0100 | <leibniz> | hololeap: thats; (a -> m r -> m r) -> m r -> m r |
| 2022-01-18 12:14:57 +0100 | <leibniz> | not sure that is the same |
| 2022-01-18 12:15:29 +0100 | <Axman6> | the only difference is the Done r |
| 2022-01-18 12:15:31 +0100 | <leibniz> | seems like a continuation wrapping a head value somehow |
| 2022-01-18 12:15:42 +0100 | <leibniz> | Axman6: sure, yours would have an instance |
| 2022-01-18 12:15:59 +0100 | <leibniz> | basically the idea is that any monadically wrapped tail thing should |
| 2022-01-18 12:16:04 +0100 | <leibniz> | if its strictly infinite even |
| 2022-01-18 12:16:07 +0100 | <leibniz> | etc. |
| 2022-01-18 12:16:35 +0100 | newsham | (~newsham@2603-800c-2d00-e994-c564-1d76-1f18-c3ec.res6.spectrum.com) (Quit: Client closed) |
| 2022-01-18 12:16:43 +0100 | <leibniz> | oh right, yours is nonempty |
| 2022-01-18 12:17:11 +0100 | <leibniz> | anyway, i cant quite communicate this properly |
| 2022-01-18 12:17:18 +0100 | deadmarshal | (~deadmarsh@95.38.228.70) (Ping timeout: 250 seconds) |
| 2022-01-18 12:17:24 +0100 | <leibniz> | and i dont think i would be able to write a coherent proposal for the class |
| 2022-01-18 12:17:29 +0100 | <Axman6> | well, it would be empty if you got rid of the monadic return value r thst most streaming libraries provide because it's often useful |
| 2022-01-18 12:17:42 +0100 | deadmarshal | (~deadmarsh@95.38.228.70) |
| 2022-01-18 12:17:44 +0100 | <hololeap> | if I understand logict correctly, (a -> m r -> m r) corresponds to MCons, and the second (m r) corresponds to (m MNil), |
| 2022-01-18 12:18:25 +0100 | <hololeap> | I might be wrong there |
| 2022-01-18 12:18:34 +0100 | <leibniz> | yeah, so its like a continuation right? it says, "given a constructor and a list, ill give you back a new list" presumably acting as a continuation over the head |
| 2022-01-18 12:19:31 +0100 | <leibniz> | i guess i should check its instances to see if thats actually what its doing, but in any case, i dont think it seems like the same thing as ListT or Axmans nonempty version |
| 2022-01-18 12:19:33 +0100 | alMalsamo | (~alMalsamo@gateway/tor-sasl/almalsamo) (Ping timeout: 276 seconds) |
| 2022-01-18 12:19:47 +0100 | <hololeap> | I think (a -> m r -> m r) is the success continuation and the second (m r) is the failure case |
| 2022-01-18 12:20:10 +0100 | <leibniz> | what makes you suggest it here? |
| 2022-01-18 12:20:15 +0100 | <Axman6> | yeah, that's just the... church encoding of the type above, roughly speaking |
| 2022-01-18 12:20:20 +0100 | <leibniz> | ah ok |
| 2022-01-18 12:20:25 +0100 | <leibniz> | so it should have an instance also |
| 2022-01-18 12:20:29 +0100 | <Axman6> | they are equivallent |
| 2022-01-18 12:20:30 +0100 | <hololeap> | because it's literally been called ListT done right |
| 2022-01-18 12:20:34 +0100 | <Axman6> | -ish |
| 2022-01-18 12:20:37 +0100 | <leibniz> | fair |
| 2022-01-18 12:20:54 +0100 | <leibniz> | sure, if its an instance of the class, no problem |
| 2022-01-18 12:20:57 +0100 | <Axman6> | basially all the streaming libraries are some variation of the ListT done right idea |
| 2022-01-18 12:21:06 +0100 | <leibniz> | im sure there are are a bunch of equivalent encodings |
| 2022-01-18 12:21:22 +0100 | <leibniz> | the point is to work at the class level to encapsulate all of them under the same abstraction |
| 2022-01-18 12:21:29 +0100 | arjun_ | (~arjun@user/arjun) |
| 2022-01-18 12:21:50 +0100 | <leibniz> | Axman6: i just dont see how its a "library" its more like a Functor, its a class |
| 2022-01-18 12:22:11 +0100 | <leibniz> | calling it a library is kind of dismising it as a fundamental thing |
| 2022-01-18 12:22:38 +0100 | <leibniz> | and not having the correct abstraction presented formally means its rewritten needlessly |
| 2022-01-18 12:22:46 +0100 | pretty_dumm_guy | (trottel@gateway/vpn/protonvpn/prettydummguy/x-88029655) |
| 2022-01-18 12:23:08 +0100 | <Axman6> | I think that's because the details of implementation matter when you care about performance |
| 2022-01-18 12:23:23 +0100 | <hololeap> | you would have to look into the differences between e.g. conduit and pipes. I'm not sure they have such a common interface |
| 2022-01-18 12:23:23 +0100 | <leibniz> | the point is that we can give the monadically wrapped tail things Functor instances, etc, but fail at Traverse |
| 2022-01-18 12:23:33 +0100 | <hololeap> | there is |
| 2022-01-18 12:23:36 +0100 | <hololeap> | @hackage streaming-commons |
| 2022-01-18 12:23:36 +0100 | <lambdabot> | https://hackage.haskell.org/package/streaming-commons |
| 2022-01-18 12:23:42 +0100 | <hololeap> | but I doubt that's what you want |
| 2022-01-18 12:24:01 +0100 | <leibniz> | im trying to formulate a proposal |
| 2022-01-18 12:24:13 +0100 | <leibniz> | for a class similar to Traverse |
| 2022-01-18 12:24:41 +0100 | <leibniz> | that takes into account this thing about the Applicative and Monad not commuting and this messing up lazyness |
| 2022-01-18 12:24:41 +0100 | <hololeap> | well, even Traverse doesn't specify if its instance is lazy or eager in the implementation |
| 2022-01-18 12:25:30 +0100 | <leibniz> | the point is that it would be blocking in a blocking tail call, eg if evaluating the tail called a server in realtime to get the next value |
| 2022-01-18 12:25:51 +0100 | <leibniz> | you need lazyness for them to compose - to get the "algebra" |
| 2022-01-18 12:26:28 +0100 | <leibniz> | since really you should be able to pass the heads as they are made available, through several traverse like opperations |
| 2022-01-18 12:27:12 +0100 | <Axman6> | what is the type of functions you want to travewrse with? just a -> m b? |
| 2022-01-18 12:27:13 +0100 | <leibniz> | but unless the constructor and the applicative in the traversal commute, which they dont in general, because of the monad, then this is not possible |
| 2022-01-18 12:28:11 +0100 | <leibniz> | Axman6: i can see two options, either you demand the monad and applicative commute, and just use the types as they appear in traverse |
| 2022-01-18 12:28:14 +0100 | <leibniz> | :t traverse |
| 2022-01-18 12:28:15 +0100 | <lambdabot> | (Traversable t, Applicative f) => (a -> f b) -> t a -> f (t b) |
| 2022-01-18 12:28:37 +0100 | <leibniz> | or you specialise Applicative f to be StateL |
| 2022-01-18 12:28:49 +0100 | <leibniz> | and just have mapAccumL |
| 2022-01-18 12:28:52 +0100 | <leibniz> | :t mapAccumL |
| 2022-01-18 12:28:53 +0100 | <lambdabot> | Traversable t => (a -> b -> (a, c)) -> a -> t b -> (a, t c) |
| 2022-01-18 12:29:01 +0100 | <leibniz> | as the thing you need to implement for the class |
| 2022-01-18 12:29:23 +0100 | <hololeap> | it sounds like you're talking about three different types here. a Traversable, an Applicative, and a Monad... but the combinators you've mentioned only have two of those |
| 2022-01-18 12:29:45 +0100 | <leibniz> | obviously the monadic context allows some generalization, ie (a -> b -> m (a, c)) |
| 2022-01-18 12:30:46 +0100 | waleee-cl | (~waleee@2001:9b0:21d:fc00:398f:b003:b90d:acf4) |
| 2022-01-18 12:31:02 +0100 | coot | (~coot@89-64-85-93.dynamic.chello.pl) (Quit: coot) |
| 2022-01-18 12:31:08 +0100 | <leibniz> | hololeap: Traversable requires that the deconstructed head is returned into an applicative, which are then sequenced together. however, for the traverse instance, the constructor is mapped into the applicative, and unless you want to sequence together all the applicatives (not lazy) to then be able to chain togther all the constructors |
| 2022-01-18 12:31:25 +0100 | <leibniz> | then you need to comute the constructor with the applicative, and then the monad and applicative need to comute |
| 2022-01-18 12:32:02 +0100 | <hololeap> | what makes you think that sequencing applicatives isn't ever lazy? |
| 2022-01-18 12:32:15 +0100 | kaph | (~kaph@151.43.53.126) (Read error: Connection reset by peer) |
| 2022-01-18 12:32:52 +0100 | <leibniz> | the point is that you either need the monad and applicative to commute, or that the "applicatives can be sequenced lazyily" as you suggest... though im not too sure about this |
| 2022-01-18 12:33:00 +0100 | <leibniz> | basicall i know it works with StateL |
| 2022-01-18 12:33:26 +0100 | <hololeap> | also, where is Monad coming into this. traverse just mentions Traversable and Applicative |
| 2022-01-18 12:33:45 +0100 | <leibniz> | and this specialised/restricted behaviour is enough to make it nice and useful |
| 2022-01-18 12:33:54 +0100 | <leibniz> | hololeap: the monad wraps the tail |
| 2022-01-18 12:34:37 +0100 | chexum | (~quassel@gateway/tor-sasl/chexum) (Remote host closed the connection) |
| 2022-01-18 12:34:43 +0100 | <hololeap> | hm, are you sure that the functor wrapping the tail needs to be a monad for this to work? |
| 2022-01-18 12:34:44 +0100 | <leibniz> | Monda m => t m a |
| 2022-01-18 12:34:49 +0100 | __monty__ | (~toonn@user/toonn) |
| 2022-01-18 12:34:58 +0100 | alMalsamo | (~alMalsamo@gateway/tor-sasl/almalsamo) |
| 2022-01-18 12:35:00 +0100 | chexum | (~quassel@gateway/tor-sasl/chexum) |
| 2022-01-18 12:35:10 +0100 | <leibniz> | i guess there is no actual requirement for it to be a monad. |
| 2022-01-18 12:35:21 +0100 | <hololeap> | because applicatives always compose, which seems to be the issue you're worried about |
| 2022-01-18 12:35:34 +0100 | <hololeap> | I'd have to work this out by hand to see what you're talking about specifically |
| 2022-01-18 12:35:38 +0100 | kaph | (~kaph@151.43.53.126) |
| 2022-01-18 12:36:03 +0100 | <leibniz> | you want to not have to sequence together all the applicatives all the way to the basecase of a potentially infinte stream |
| 2022-01-18 12:36:15 +0100 | <leibniz> | in order to start composing together the constructors |
| 2022-01-18 12:36:40 +0100 | <leibniz> | you want each head in turn to be available to subsequent traversals |
| 2022-01-18 12:36:51 +0100 | <leibniz> | this being basically "lazyness" |
| 2022-01-18 12:37:13 +0100 | deadmarshal | (~deadmarsh@95.38.228.70) (Ping timeout: 268 seconds) |
| 2022-01-18 12:37:13 +0100 | <leibniz> | at some point you need the "monad" and applicative to commute |
| 2022-01-18 12:38:10 +0100 | <leibniz> | hololeap; i guess you would run into the issue trying to get a monoidally composable traverse like opperation for monadically wrapped tails in a strictly infinite stream |
| 2022-01-18 12:39:16 +0100 | <leibniz> | im not sure whats the correct way to present it though, either you require the commutation opperation is made available by a superclass |
| 2022-01-18 12:39:39 +0100 | <leibniz> | or you just restrict the arbitrary applicative in traverse to StateL and just work with mapAccumL opperations |
| 2022-01-18 12:39:52 +0100 | <hololeap> | so we are talking about some structure that looks like this: x : m ( y : m ( z : m [] ) ) |
| 2022-01-18 12:39:59 +0100 | <leibniz> | yes |
| 2022-01-18 12:43:16 +0100 | CiaoSen | (~Jura@p200300c95737a2002a3a4dfffe84dbd5.dip0.t-ipconnect.de) |
| 2022-01-18 12:43:45 +0100 | kaph | (~kaph@151.43.53.126) (Ping timeout: 256 seconds) |
| 2022-01-18 12:44:51 +0100 | <leibniz> | im not sure how to move the discussion along, i guess it would be good to see someone else understand where the snag of commutation arises |
| 2022-01-18 12:45:19 +0100 | <hololeap> | I'm trying to translate this into free monads if possible, because that might give some insight |
| 2022-01-18 12:45:51 +0100 | <leibniz> | oh, ok |
| 2022-01-18 12:48:56 +0100 | <hololeap> | Free (Compose ((,) x) m) () -- this is what it seems to be equivalent to, but the insight fizzled. probably because I still don't understand the problem correctly. maybe write up some code demonstrating what you're trying to do |
| 2022-01-18 12:49:18 +0100 | <hololeap> | sorry, I've got limited energy right now |
| 2022-01-18 12:50:47 +0100 | Erutuon | (~Erutuon@user/erutuon) (Ping timeout: 268 seconds) |
| 2022-01-18 12:51:09 +0100 | <leibniz> | not a problem |
| 2022-01-18 12:51:33 +0100 | <leibniz> | i guess you could use Cofree aswell |
| 2022-01-18 12:51:53 +0100 | <leibniz> | anyway, its not really an issue of which representation you use for the monadically wrapped tail thing |
| 2022-01-18 12:52:21 +0100 | <leibniz> | more of how to present the class that all of these instantiate |
| 2022-01-18 12:52:34 +0100 | <hololeap> | I just don't see the connection between the monads composing and the lazy/eager issue |
| 2022-01-18 12:52:51 +0100 | <leibniz> | i cant tell if i should propose the version with the applicative restricted to StateL or the version with a commutation relation via a superclass |
| 2022-01-18 12:53:26 +0100 | <leibniz> | hololeap: i guess since they are only monads as an artefact of using IO as m, to demonstraite how with a "blocking" class |
| 2022-01-18 12:53:29 +0100 | <leibniz> | call* |
| 2022-01-18 12:53:42 +0100 | <leibniz> | that the basecase would be inaccessible |
| 2022-01-18 12:53:42 +0100 | cheater | (~Username@user/cheater) (Ping timeout: 250 seconds) |
| 2022-01-18 12:54:04 +0100 | <leibniz> | its the applicative that compise |
| 2022-01-18 12:54:07 +0100 | <leibniz> | compose* |
| 2022-01-18 12:54:17 +0100 | <leibniz> | the monadic bind opperation isnt actually used i dont think |
| 2022-01-18 12:55:00 +0100 | <leibniz> | maybe it is somewhere, eg to flatten down a double nesting if the function returns the result in a monad aswell |
| 2022-01-18 12:55:16 +0100 | <hololeap> | I need to get some sleep, but good luck with your proposal |
| 2022-01-18 12:55:19 +0100 | <sshine> | what's the GHC extension that implies that nested type signatures refer to the parent variable if there isn't an explicit 'forall' in the inner type signature? |
| 2022-01-18 12:55:25 +0100 | <sshine> | ScopedTypeVariables? |
| 2022-01-18 12:55:27 +0100 | <leibniz> | (Applicative f,Monad m) => a -> m (f a) |
| 2022-01-18 12:56:04 +0100 | <leibniz> | sshine: no you need an outer forall for that to work |
| 2022-01-18 12:56:11 +0100 | <hololeap> | sshine: probably RankNTypes |
| 2022-01-18 12:56:53 +0100 | SummerSonw | (~The_viole@203.77.49.232) |
| 2022-01-18 12:56:56 +0100 | <leibniz> | oh right, yes, you can ommit the forall on the inner type signature in a where block, nested like you say. its both RankNTypes and ScopedTypeVariables in combination |
| 2022-01-18 12:57:11 +0100 | coot | (~coot@89-64-85-93.dynamic.chello.pl) |
| 2022-01-18 12:57:47 +0100 | <leibniz> | hololeap: ok thanks for your help |
| 2022-01-18 12:58:05 +0100 | <leibniz> | i wonder if Axman is still online, im not sure if anyone managed to follow what i was writing |
| 2022-01-18 13:02:15 +0100 | <hololeap> | try to work out a signature for your function first... would it be: (Traversable t, Applicative f, Monad m) => (a -> f b) -> t m a -> f (t m b) ? |
| 2022-01-18 13:02:28 +0100 | <hololeap> | anyway, gnight |
| 2022-01-18 13:03:02 +0100 | <leibniz> | (Traversable t, Applicative f, Monad m,Commutes f m) => (a -> m (f b)) -> t m a -> f (t m b) |
| 2022-01-18 13:03:22 +0100 | <leibniz> | or, setting f ~ StateL, and using mapAccumL |
| 2022-01-18 13:03:27 +0100 | <leibniz> | :t mapAccumL |
| 2022-01-18 13:03:28 +0100 | <lambdabot> | Traversable t => (a -> b -> (a, c)) -> a -> t b -> (a, t c) |
| 2022-01-18 13:03:50 +0100 | <leibniz> | Traversable t => (a -> b ->m (a, c)) -> a -> t m b -> (a, t m c) |
| 2022-01-18 13:04:01 +0100 | <leibniz> | erp, not Traversable |
| 2022-01-18 13:04:04 +0100 | Midjak | (~Midjak@may53-1-78-226-116-92.fbx.proxad.net) |
| 2022-01-18 13:04:15 +0100 | <leibniz> | whatever this new class would be called |
| 2022-01-18 13:04:21 +0100 | <sshine> | https://gist.github.com/sshine/8f350c862a1e49a1e7a3e1fca5bd12b6 -- 'employee' and 'skill' were originally fixed types, and I'd like to parameterise them. but somehow unification fails. I'm not sure if the Ord constraints are messing it up, or what. |
| 2022-01-18 13:06:31 +0100 | <leibniz> | sshine: does it still throw an error if you enable AllowAmbiguousTypes? |
| 2022-01-18 13:07:06 +0100 | <sshine> | leibniz, yes. |
| 2022-01-18 13:07:13 +0100 | <leibniz> | or a functional dependecy stating that skill can be determined from employee |
| 2022-01-18 13:07:32 +0100 | <sshine> | I'm not sure how to express that. |
| 2022-01-18 13:07:47 +0100 | <sshine> | I thought I didn't have to express functional dependencies for this. |
| 2022-01-18 13:08:29 +0100 | <leibniz> | it seems like it cant infer skill in the return type from employee in the input type |
| 2022-01-18 13:09:06 +0100 | <leibniz> | i would have thought that with ApplowAmbiguousTypes you could just specify both with a typeApplication |
| 2022-01-18 13:09:29 +0100 | <leibniz> | s/typo/notypo |
| 2022-01-18 13:10:25 +0100 | deadmarshal | (~deadmarsh@95.38.228.70) |
| 2022-01-18 13:11:03 +0100 | <leibniz> | the fundep is for a class, my mistake sorry |
| 2022-01-18 13:11:18 +0100 | <leibniz> | maybe injective types? |
| 2022-01-18 13:14:55 +0100 | deadmarshal | (~deadmarsh@95.38.228.70) (Ping timeout: 256 seconds) |
| 2022-01-18 13:15:55 +0100 | lavaman | (~lavaman@98.38.249.169) |
| 2022-01-18 13:16:06 +0100 | <leibniz> | aha |
| 2022-01-18 13:16:14 +0100 | <leibniz> | you need a type application on "staff" |
| 2022-01-18 13:18:07 +0100 | <leibniz> | er, or somewhere else, since staff actually has the correct "skill" and something else is expecting an arbitrary skill |
| 2022-01-18 13:18:32 +0100 | <leibniz> | im guessing Set.empty |
| 2022-01-18 13:20:45 +0100 | lavaman | (~lavaman@98.38.249.169) (Ping timeout: 256 seconds) |
| 2022-01-18 13:21:12 +0100 | <leibniz> | erg! it was your foralls! |
| 2022-01-18 13:21:23 +0100 | <leibniz> | you need to have them in one forall statement for some reason! |
| 2022-01-18 13:22:02 +0100 | <leibniz> | such a weird error, its a bug? |
| 2022-01-18 13:22:21 +0100 | <leibniz> | sshine^ |
| 2022-01-18 13:23:27 +0100 | leibniz | (~leibniz@cpc101088-sgyl37-2-0-cust22.18-2.cable.virginm.net) (Quit: Connection closed) |
| 2022-01-18 13:25:02 +0100 | deadmarshal | (~deadmarsh@95.38.228.70) |
| 2022-01-18 13:25:16 +0100 | arjun_ | (~arjun@user/arjun) (Remote host closed the connection) |
| 2022-01-18 13:25:28 +0100 | tromp | (~textual@dhcp-077-249-230-040.chello.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2022-01-18 13:27:10 +0100 | ksqsf | (~user@134.209.106.31) (Ping timeout: 268 seconds) |
| 2022-01-18 13:27:42 +0100 | cosimone | (~user@93-47-230-83.ip115.fastwebnet.it) |
| 2022-01-18 13:29:50 +0100 | tromp | (~textual@dhcp-077-249-230-040.chello.nl) |
| 2022-01-18 13:30:30 +0100 | geranim0 | (~geranim0@modemcable242.171-178-173.mc.videotron.ca) |
| 2022-01-18 13:31:48 +0100 | jkaye | (~jkaye@2601:281:200:1958:8e74:ef22:c471:c2e) |
| 2022-01-18 13:33:57 +0100 | cheater | (~Username@user/cheater) |
| 2022-01-18 13:35:36 +0100 | slack1256 | (~slack1256@186.11.99.46) |
| 2022-01-18 13:38:16 +0100 | slac19759 | (~slack1256@191.125.99.76) (Ping timeout: 268 seconds) |
| 2022-01-18 13:43:24 +0100 | stiell_ | (~stiell@gateway/tor-sasl/stiell) (Ping timeout: 276 seconds) |
| 2022-01-18 13:43:57 +0100 | echoone | (~echoone@188.74.32.13) |
| 2022-01-18 13:45:36 +0100 | eggplantade | (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) |
| 2022-01-18 13:46:04 +0100 | xlei_ | (~akans@pool-71-125-19-142.nycmny.fios.verizon.net) |
| 2022-01-18 13:46:51 +0100 | xlei_ | (~akans@pool-71-125-19-142.nycmny.fios.verizon.net) (Client Quit) |
| 2022-01-18 13:47:42 +0100 | caro_ | (~caro@212.83.144.58) |
| 2022-01-18 13:47:47 +0100 | xlei | (~akans@pool-71-125-19-142.nycmny.fios.verizon.net) (Ping timeout: 256 seconds) |
| 2022-01-18 13:48:13 +0100 | xlei_ | (~akans@pool-71-125-19-142.nycmny.fios.verizon.net) |
| 2022-01-18 13:48:19 +0100 | fef | (~thedawn@user/thedawn) |
| 2022-01-18 13:48:59 +0100 | caro_ | caro |
| 2022-01-18 13:49:32 +0100 | eggplantade | (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) (Ping timeout: 240 seconds) |
| 2022-01-18 13:50:52 +0100 | ksqsf | (~user@134.209.106.31) |
| 2022-01-18 13:51:29 +0100 | jackson99 | (~bc8147f2@cerf.good1.com) (Quit: CGI:IRC (Session timeout)) |
| 2022-01-18 13:53:31 +0100 | tromp | (~textual@dhcp-077-249-230-040.chello.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2022-01-18 13:55:53 +0100 | ksqsf | (~user@134.209.106.31) (Ping timeout: 256 seconds) |
| 2022-01-18 13:56:11 +0100 | stiell_ | (~stiell@gateway/tor-sasl/stiell) |
| 2022-01-18 13:56:24 +0100 | wyrd | (~wyrd@gateway/tor-sasl/wyrd) (Ping timeout: 276 seconds) |
| 2022-01-18 13:56:44 +0100 | wyrd | (~wyrd@gateway/tor-sasl/wyrd) |
| 2022-01-18 13:57:34 +0100 | burnsidesLlama | (~burnsides@dhcp168-015.wadham.ox.ac.uk) |
| 2022-01-18 13:58:00 +0100 | max22- | (~maxime@lfbn-ren-1-1026-62.w92-139.abo.wanadoo.fr) (Ping timeout: 268 seconds) |
| 2022-01-18 14:07:49 +0100 | ksqsf | (~user@134.209.106.31) |
| 2022-01-18 14:08:21 +0100 | deadmarshal | (~deadmarsh@95.38.228.70) (Ping timeout: 256 seconds) |
| 2022-01-18 14:08:22 +0100 | Pickchea | (~private@user/pickchea) |
| 2022-01-18 14:08:32 +0100 | burnsidesLlama | (~burnsides@dhcp168-015.wadham.ox.ac.uk) (Remote host closed the connection) |
| 2022-01-18 14:13:25 +0100 | ksqsf | (~user@134.209.106.31) (Ping timeout: 268 seconds) |
| 2022-01-18 14:15:55 +0100 | slowButPresent | (~slowButPr@user/slowbutpresent) |
| 2022-01-18 14:16:32 +0100 | leibniz | (~leibniz@cpc101088-sgyl37-2-0-cust22.18-2.cable.virginm.net) |
| 2022-01-18 14:17:02 +0100 | <leibniz> | so how do you open a proposal anyway? |
| 2022-01-18 14:18:45 +0100 | ksqsf | (~user@134.209.106.31) |
| 2022-01-18 14:19:42 +0100 | deadmarshal | (~deadmarsh@95.38.228.70) |
| 2022-01-18 14:21:45 +0100 | fef | (~thedawn@user/thedawn) (Ping timeout: 276 seconds) |
| 2022-01-18 14:23:35 +0100 | kaph | (~kaph@net-2-47-208-144.cust.vodafonedsl.it) |
| 2022-01-18 14:23:50 +0100 | <leibniz> | i was hoping to get some feedback on which was the best way to phrase it before doing so though |
| 2022-01-18 14:23:59 +0100 | rusrushal13 | (~rusrushal@2401:4900:4471:78e2:d490:6737:3704:78a1) |
| 2022-01-18 14:24:19 +0100 | SummerSonw | (~The_viole@203.77.49.232) (Quit: Leaving) |
| 2022-01-18 14:24:29 +0100 | <tomsmeding> | a ghc implementation proposal? |
| 2022-01-18 14:24:31 +0100 | <leibniz> | basically the "refine the applicative to StateL" version, or "allow all applicatives that commute with the tails monad" version |
| 2022-01-18 14:24:37 +0100 | SummerSonw | (~The_viole@203.77.49.232) |
| 2022-01-18 14:24:38 +0100 | <leibniz> | tomsmeding: yeah |
| 2022-01-18 14:24:45 +0100 | <tomsmeding> | look here https://github.com/ghc-proposals/ghc-proposals |
| 2022-01-18 14:24:48 +0100 | <leibniz> | thanks |
| 2022-01-18 14:25:45 +0100 | SummerSonw | (~The_viole@203.77.49.232) (Client Quit) |
| 2022-01-18 14:25:48 +0100 | echoone | (~echoone@188.74.32.13) (Quit: Client closed) |
| 2022-01-18 14:26:17 +0100 | <leibniz> | hmm, it doesnt seem like a new Prelude class is one of the types of thing that a proposal is for |
| 2022-01-18 14:26:50 +0100 | xkuru | (~xkuru@user/xkuru) (Read error: Connection reset by peer) |
| 2022-01-18 14:27:06 +0100 | <tomsmeding> | leibniz: maybe here? https://github.com/haskell-core/core-libraries-proposals |
| 2022-01-18 14:27:09 +0100 | <jkaye> | leibniz, Would that not be more of a library change than a GHC change? |
| 2022-01-18 14:27:21 +0100 | <jkaye> | tomsmeding, Yep just what I was thinking |
| 2022-01-18 14:27:21 +0100 | <leibniz> | yeah |
| 2022-01-18 14:27:25 +0100 | <leibniz> | thanks |
| 2022-01-18 14:27:27 +0100 | SummerSonw | (~The_viole@203.77.49.232) |
| 2022-01-18 14:27:35 +0100 | <merijn> | leibniz: What class would that be? |
| 2022-01-18 14:27:57 +0100 | <merijn> | leibniz: Also, changes to Prelude are fairly unpopular because they affect nearly all code |
| 2022-01-18 14:28:12 +0100 | <leibniz> | its just another class... shouldnt be a breaking change |
| 2022-01-18 14:28:19 +0100 | <leibniz> | depends which version, the commuting type i havent actually been using so i dont have a name for |
| 2022-01-18 14:28:34 +0100 | <tomsmeding> | another class _is_ a breaking change, for user code that used that same name for something else :) |
| 2022-01-18 14:28:38 +0100 | <leibniz> | the version which requires the user to implement a monadic version of mapAccumL im calling a Scanner |
| 2022-01-18 14:28:48 +0100 | <merijn> | leibniz: If that classes' name conflicts with anything in existing code, it *is* breaking |
| 2022-01-18 14:29:04 +0100 | <tomsmeding> | might want to consider putting it not in Prelude, but somewhere else in base |
| 2022-01-18 14:29:11 +0100 | <tomsmeding> | then it's not a breaking change |
| 2022-01-18 14:29:12 +0100 | <leibniz> | tomsmeding: ok, modulo naming conflicts... oh right, i guess you cant guarantee the name is unused. guess a hackage search could show up any conflicts though |
| 2022-01-18 14:29:13 +0100 | whatsupdoc | (uid509081@id-509081.hampstead.irccloud.com) (Quit: Connection closed for inactivity) |
| 2022-01-18 14:29:20 +0100 | <tomsmeding> | (I didn't read any of the stuff before in this channel, sorry) |
| 2022-01-18 14:29:23 +0100 | <merijn> | leibniz: You are introducing a new typename/function names in the global scope of every program//library without an explicit Prelude |
| 2022-01-18 14:29:29 +0100 | <merijn> | leibniz: But why prelude? |
| 2022-01-18 14:29:38 +0100 | <leibniz> | because its basically Traverse |
| 2022-01-18 14:29:40 +0100 | <merijn> | leibniz: Why not in a different module in base? |
| 2022-01-18 14:29:46 +0100 | <leibniz> | ie, its about as high level as you can get |
| 2022-01-18 14:30:05 +0100 | <leibniz> | sure, maybe eg. Data.Scanner or something |
| 2022-01-18 14:30:19 +0100 | <merijn> | Traversable in Prelude was already controversial and that one was widely used before the change :p |
| 2022-01-18 14:30:19 +0100 | <leibniz> | idk how to ensure its shipped with base though |
| 2022-01-18 14:30:36 +0100 | <leibniz> | its quite category theoretic |
| 2022-01-18 14:30:39 +0100 | <leibniz> | things like Functor |
| 2022-01-18 14:30:54 +0100 | <leibniz> | basicaly formalising the abstraction of map for regular lists |
| 2022-01-18 14:31:03 +0100 | <merijn> | leibniz: Will this class a superclass of existing stuff in base? |
| 2022-01-18 14:31:04 +0100 | <leibniz> | this is along those lines |
| 2022-01-18 14:31:27 +0100 | <merijn> | If not, then it could just as easily be outside of base, though |
| 2022-01-18 14:31:30 +0100 | <leibniz> | merijn: im not sure, i dont think so since it requires an extra parameter |
| 2022-01-18 14:31:51 +0100 | <merijn> | @hackage witherable |
| 2022-01-18 14:31:51 +0100 | <lambdabot> | https://hackage.haskell.org/package/witherable |
| 2022-01-18 14:31:59 +0100 | <leibniz> | its kind of like Monad m => Traversable (f m) |
| 2022-01-18 14:32:01 +0100 | <merijn> | leibniz: i.e. why couldn't it be a separate package like witherable? |
| 2022-01-18 14:32:24 +0100 | <leibniz> | functor ships with base though? |
| 2022-01-18 14:32:30 +0100 | <leibniz> | thats the proposal |
| 2022-01-18 14:32:36 +0100 | <leibniz> | that it qualifies for that kind of status |
| 2022-01-18 14:32:51 +0100 | <leibniz> | otherwise it would just be a library, i guess thats what im having to defend |
| 2022-01-18 14:33:02 +0100 | <leibniz> | but cant argue more than just its formal centrality |
| 2022-01-18 14:33:08 +0100 | <merijn> | leibniz: Making base bigger is a rather unpopular idea |
| 2022-01-18 14:33:35 +0100 | <leibniz> | if it was missing something like Functor, im sure it would be addapted despite this |
| 2022-01-18 14:33:36 +0100 | <merijn> | leibniz: Because the bigger base is, the more often breaking changes happen, so we either have to accept "base continually breaking" |
| 2022-01-18 14:33:46 +0100 | <merijn> | or "stuff doesn't change because it'd break base" |
| 2022-01-18 14:33:55 +0100 | <leibniz> | ok, well this wasnt discovered before |
| 2022-01-18 14:33:56 +0100 | fef | (~thedawn@user/thedawn) |
| 2022-01-18 14:34:10 +0100 | <leibniz> | its unlikely it will need to be added again either |
| 2022-01-18 14:34:36 +0100 | <leibniz> | sorry if that seems like a strange argument. but i cant exactly predict "no similar discoveries will occur" |
| 2022-01-18 14:34:49 +0100 | <leibniz> | and can only argue that this is fundamental enough |
| 2022-01-18 14:34:55 +0100 | <leibniz> | which i guess is debatable |
| 2022-01-18 14:36:01 +0100 | <leibniz> | if it "started a trend of inflating base", i guess as long as it was sufficiently justified, this wouldnt be a bad thing |
| 2022-01-18 14:36:16 +0100 | <leibniz> | "search for higher order formalisms" |
| 2022-01-18 14:36:26 +0100 | <ksqsf> | base is already a big mudball; i kinda hope there will be a base 5 rewrite :] |
| 2022-01-18 14:37:42 +0100 | <leibniz> | my main reason for approaching the committee is because i cant argue these rationalisations, or design the library sufficiently to have it accepted |
| 2022-01-18 14:37:47 +0100 | <leibniz> | alone |
| 2022-01-18 14:37:49 +0100 | <geekosaur> | we already had one split base,m maybe it's time for another |
| 2022-01-18 14:38:47 +0100 | <leibniz> | i dont want to get into the details too much, but i have reason to believe this to be a very high order abstraction, based on some theorems to do with isomorphic containers |
| 2022-01-18 14:39:20 +0100 | <leibniz> | something like "the monad on the tail can contain the structure directing index required for shaped pattern matching" |
| 2022-01-18 14:41:15 +0100 | <leibniz> | which is where (for anything (traversable containers?) more shaped than lists, eg trees) you need extra data on the constructor to retain the shape during traversal implemented by pattern matching on a head/tail opperation (the structure directing index is required as an argument to the constructor) |
| 2022-01-18 14:41:18 +0100 | burnsidesLlama | (~burnsides@dhcp168-015.wadham.ox.ac.uk) |
| 2022-01-18 14:41:37 +0100 | <leibniz> | since the monadic tail thing subsumes this, and thats a pretty high level thing, i guess that makes this super high level |
| 2022-01-18 14:42:01 +0100 | <leibniz> | "its really a thing" => "it should go in base" |
| 2022-01-18 14:42:10 +0100 | <lortabac> | leibniz: if it can technically be implemented as a new library, I'd do it as a library anyway |
| 2022-01-18 14:42:21 +0100 | deadmarshal | (~deadmarsh@95.38.228.70) (Ping timeout: 256 seconds) |
| 2022-01-18 14:42:25 +0100 | <leibniz> | point is that would have me doing it alone |
| 2022-01-18 14:42:48 +0100 | <leibniz> | id rather kind of consult on the design of a proposal and have people that can do things properly do it |
| 2022-01-18 14:42:53 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Quit: = "") |
| 2022-01-18 14:43:11 +0100 | <tomsmeding> | the advantage of writing a library is that you can completely rewrite it when you get new insight :) |
| 2022-01-18 14:43:19 +0100 | <leibniz> | might seem like a cop out, but i think its both complex and important enough to have it done by pros, instead of me |
| 2022-01-18 14:43:20 +0100 | <tomsmeding> | for example insight from other people |
| 2022-01-18 14:43:43 +0100 | <tomsmeding> | I think a proposal for including stuff in base would be stronger anyway if there is an existing implementation that people can look at |
| 2022-01-18 14:43:44 +0100 | <lortabac> | in any case it's better to make a library, then it can be moved to base if it becomes popular enough |
| 2022-01-18 14:43:46 +0100 | <leibniz> | iv written it several times, at this point im suggesting a proposal that would involve the GHC team |
| 2022-01-18 14:44:20 +0100 | <leibniz> | lortabac: i think thats whats being debated, i disagree, i think infact that assertion is whats preventing its acceptance |
| 2022-01-18 14:44:41 +0100 | <merijn> | "the GHC team" always makes me think that people think GHC has a whole lot more people than it does :p |
| 2022-01-18 14:44:51 +0100 | <leibniz> | ok "you lot" |
| 2022-01-18 14:45:05 +0100 | <leibniz> | :-/ |
| 2022-01-18 14:45:15 +0100 | alx741 | (~alx741@157.100.93.160) (Read error: Connection reset by peer) |
| 2022-01-18 14:45:28 +0100 | <tomsmeding> | I feel like the best way to continue would be to write up what you think, and post it in this channel, on reddit and perhaps on haskell weekly, and get discussions going |
| 2022-01-18 14:45:52 +0100 | <leibniz> | did you see the presentation in the scrollup? |
| 2022-01-18 14:46:04 +0100 | <tomsmeding> | if you feel like you're to a point where you think "this is a good idea and it should be implemented in this form", make a proposal |
| 2022-01-18 14:46:08 +0100 | <tomsmeding> | no sorry lol |
| 2022-01-18 14:46:12 +0100 | <leibniz> | right... |
| 2022-01-18 14:46:16 +0100 | <tomsmeding> | hence my point, make a writeup in one document |
| 2022-01-18 14:46:23 +0100 | <leibniz> | im saying i cant |
| 2022-01-18 14:46:39 +0100 | <leibniz> | i have the theoretical results but cant write well enough |
| 2022-01-18 14:47:08 +0100 | <leibniz> | which is difficult for both myself and the comunity, since neither party actually benifits from the existence of the results |
| 2022-01-18 14:48:05 +0100 | <leibniz> | this is why i was asking for "help drfing a proposal" |
| 2022-01-18 14:48:17 +0100 | <leibniz> | drafting* |
| 2022-01-18 14:49:23 +0100 | <leibniz> | tomsmeding: also, its stateable in one line |
| 2022-01-18 14:50:52 +0100 | <leibniz> | "my thing is either a refinement over traverse, to the StateL Applicative, for monadically wrapped tail list-like things, or its a requirement that a more general applicative comute with the monad, to ensure the lazy traversability permits monoidal composition in a blocking monadic streaming setting for example" |
| 2022-01-18 14:50:58 +0100 | <leibniz> | or various similar presentations |
| 2022-01-18 14:51:48 +0100 | <leibniz> | "scanner algebras" result from the version refining the applicative to StateL, idk much about the general version with the commuting |
| 2022-01-18 14:51:51 +0100 | <tomsmeding> | sounds interesting but still very abstract |
| 2022-01-18 14:52:06 +0100 | <tomsmeding> | "I have the theoretical results" sounds like you have some more mathematical results; is that true? |
| 2022-01-18 14:53:17 +0100 | <leibniz> | theres some theorems like "everything of a certain style is isomorphic to free lists - so basically is trees, so thats what you want structure directing indexes for, and abstractions that subsume these" |
| 2022-01-18 14:53:26 +0100 | <leibniz> | the theorem being the isomorphic to trees statement |
| 2022-01-18 14:54:22 +0100 | <leibniz> | "theoretically, this is important" ... :-/ |
| 2022-01-18 14:54:39 +0100 | <leibniz> | sorry... |
| 2022-01-18 14:55:28 +0100 | <lortabac> | I'd suggest this: if you have some mathematical insights to share, write a blog post; if you have an implementation, write a library; if you have a vague intuition that needs to be refined, write a post on Reddit |
| 2022-01-18 14:56:03 +0100 | <leibniz> | so basically you suggest not approaching it directly on the active channel, and presenting it in a way which i have stated i cannot |
| 2022-01-18 14:56:04 +0100 | <leibniz> | thanks! |
| 2022-01-18 14:56:09 +0100 | <leibniz> | i think i should go |
| 2022-01-18 14:56:20 +0100 | cosimone | (~user@93-47-230-83.ip115.fastwebnet.it) (Remote host closed the connection) |
| 2022-01-18 14:56:27 +0100 | <leibniz> | perhaps these results, at some point, can be written by someone other than myself |
| 2022-01-18 14:56:31 +0100 | <leibniz> | peace |
| 2022-01-18 14:56:33 +0100 | leibniz | (~leibniz@cpc101088-sgyl37-2-0-cust22.18-2.cable.virginm.net) (Quit: Connection closed) |
| 2022-01-18 14:56:40 +0100 | <tomsmeding> | ideas like these typically benefit from writing some kind of exposition, and feedbacking a fixed piece of text |
| 2022-01-18 14:56:40 +0100 | <tomsmeding> | oh |
| 2022-01-18 14:56:47 +0100 | <tomsmeding> | o/ |
| 2022-01-18 14:57:10 +0100 | <yushyin> | oO |
| 2022-01-18 15:01:24 +0100 | alx741 | (~alx741@157.100.93.160) |
| 2022-01-18 15:04:41 +0100 | deadmarshal | (~deadmarsh@95.38.228.70) |
| 2022-01-18 15:04:46 +0100 | <ksqsf> | :( ghc doesn't let me use 𝟙 as an identifier |
| 2022-01-18 15:05:29 +0100 | <geekosaur> | > generalCategory '𝟙' |
| 2022-01-18 15:05:31 +0100 | <lambdabot> | DecimalNumber |
| 2022-01-18 15:07:50 +0100 | <ksqsf> | it's not a number anyway |
| 2022-01-18 15:08:08 +0100 | <geekosaur> | > 𝟙 |
| 2022-01-18 15:08:09 +0100 | <lambdabot> | <hint>:1:1: error: lexical error at character '\120793' |
| 2022-01-18 15:08:18 +0100 | neurocyte091709 | (~neurocyte@user/neurocyte) (Ping timeout: 268 seconds) |
| 2022-01-18 15:08:34 +0100 | neurocyte0917090 | (~neurocyte@user/neurocyte) |
| 2022-01-18 15:08:35 +0100 | alx741 | (~alx741@157.100.93.160) (Read error: Connection reset by peer) |
| 2022-01-18 15:08:46 +0100 | <geekosaur> | interesting the category is number but you can't use it as one |
| 2022-01-18 15:11:42 +0100 | michalz | (~michalz@185.246.204.101) (Remote host closed the connection) |
| 2022-01-18 15:12:47 +0100 | rusrushal13 | (~rusrushal@2401:4900:4471:78e2:d490:6737:3704:78a1) (Ping timeout: 256 seconds) |
| 2022-01-18 15:13:21 +0100 | neverwas | (jpneverwas@swissbox.unperson.link) (Ping timeout: 256 seconds) |
| 2022-01-18 15:13:53 +0100 | <pfurla-matrix> | !whois puffnfresh |
| 2022-01-18 15:14:28 +0100 | pfurla | (~pfurla@2804:d41:4331:4800:2caa:3e9f:9236:25d4) |
| 2022-01-18 15:14:41 +0100 | <geekosaur> | did you want /whois ? |
| 2022-01-18 15:15:31 +0100 | <sshine> | is there a notify service on libera chat? |
| 2022-01-18 15:16:19 +0100 | <pfurla-matrix> | I did but I am in a matrix.org bridge , bang-ircCommand is supposed to be a irc command, but apparently only in special chat room |
| 2022-01-18 15:16:35 +0100 | <geekosaur> | looks like they have memoserv. need to have a registered nick both to send and to receive |
| 2022-01-18 15:16:53 +0100 | <geekosaur> | lambdabot also has @tell |
| 2022-01-18 15:22:20 +0100 | neverwas | (jpneverwas@swissbox.unperson.link) |
| 2022-01-18 15:23:06 +0100 | Snoopy4 | (~Snoopy@host-82-49-101-122.retail.telecomitalia.it) |
| 2022-01-18 15:23:33 +0100 | <Snoopy4> | Haskell is the esoteric language with the most money invested in, and still manages to suck. Congrats ^^ |
| 2022-01-18 15:23:47 +0100 | Snoopy4 | (~Snoopy@host-82-49-101-122.retail.telecomitalia.it) (Client Quit) |
| 2022-01-18 15:25:58 +0100 | michalz | (~michalz@185.246.204.122) |
| 2022-01-18 15:26:38 +0100 | <sshine> | haha |
| 2022-01-18 15:26:48 +0100 | <sshine> | if that were true |
| 2022-01-18 15:27:00 +0100 | <kuribas> | well, someone invested money in haskell, that's good news :) |
| 2022-01-18 15:27:09 +0100 | <sshine> | I think there are legacy languages that have way more money invested and "suck" in a different sense :) |
| 2022-01-18 15:27:21 +0100 | alx741 | (~alx741@157.100.93.160) |
| 2022-01-18 15:27:48 +0100 | <geekosaur> | javascript immediately came to mind for some reason |
| 2022-01-18 15:27:55 +0100 | <sshine> | but I'm impressed at how far Haskell has gotten in production considering how impractical its toolchain is, and how hard the language itself is to learn. :D |
| 2022-01-18 15:28:00 +0100 | <kuribas> | I agree that haskell sucks, just less than other languages :) |
| 2022-01-18 15:28:34 +0100 | <sshine> | kuribas, I recall that being the motto behind mutt, the email client. how many still use that? ;) |
| 2022-01-18 15:28:58 +0100 | <geekosaur> | it's still my go-to if I'm limited to TUI |
| 2022-01-18 15:29:15 +0100 | <sshine> | I'll quit email before I get a good email client. |
| 2022-01-18 15:29:20 +0100 | <geekosaur> | thankfully that doesn't happen much any more, but. |
| 2022-01-18 15:30:08 +0100 | <sshine> | apparently people use email to send these "job contracts" and "job applications" and they keep bugging me to check it. it's so unproductive! |
| 2022-01-18 15:30:27 +0100 | <sshine> | like, don't they have /dcc send? |
| 2022-01-18 15:31:13 +0100 | alx741 | (~alx741@157.100.93.160) (Read error: Connection reset by peer) |
| 2022-01-18 15:31:18 +0100 | fef | (~thedawn@user/thedawn) (Quit: Leaving) |
| 2022-01-18 15:33:57 +0100 | wroathe | (~wroathe@206-55-188-8.fttp.usinternet.com) |
| 2022-01-18 15:33:57 +0100 | wroathe | (~wroathe@206-55-188-8.fttp.usinternet.com) (Changing host) |
| 2022-01-18 15:33:57 +0100 | wroathe | (~wroathe@user/wroathe) |
| 2022-01-18 15:35:02 +0100 | nvmd | (~nvmd@user/nvmd) |
| 2022-01-18 15:36:06 +0100 | ystael | (~ystael@user/ystael) |
| 2022-01-18 15:38:51 +0100 | deadmarshal | (~deadmarsh@95.38.228.70) (Ping timeout: 256 seconds) |
| 2022-01-18 15:39:16 +0100 | vglfr | (~vglfr@46.96.165.111) |
| 2022-01-18 15:40:32 +0100 | deadmarshal | (~deadmarsh@95.38.228.70) |
| 2022-01-18 15:41:17 +0100 | leibniz | (~leibniz@cpc101088-sgyl37-2-0-cust22.18-2.cable.virginm.net) |
| 2022-01-18 15:41:30 +0100 | <leibniz> | hey, sorry, i had to duck out |
| 2022-01-18 15:41:55 +0100 | <leibniz> | i think we were discussing the format of the proposal |
| 2022-01-18 15:42:11 +0100 | <leibniz> | where there were considerations about limited bandwidth |
| 2022-01-18 15:42:49 +0100 | <leibniz> | i personally dont feel confident to author a persistent article |
| 2022-01-18 15:43:06 +0100 | <leibniz> | it seems this is a sticking point |
| 2022-01-18 15:44:33 +0100 | <merijn> | sshine: What makes you say the toolchain is impractical? |
| 2022-01-18 15:44:52 +0100 | deadmarshal | (~deadmarsh@95.38.228.70) (Ping timeout: 250 seconds) |
| 2022-01-18 15:44:57 +0100 | <leibniz> | i guess this means that the most help i can be is to answer any questions anyone has |
| 2022-01-18 15:44:58 +0100 | <merijn> | I'm genuinely curious, because nearly every other language I use has toolchains that seem way less practical than cabal |
| 2022-01-18 15:45:14 +0100 | razetime | (~quassel@49.207.203.87) |
| 2022-01-18 15:45:32 +0100 | <leibniz> | merijn: it seemed like a flippant comment |
| 2022-01-18 15:45:41 +0100 | <merijn> | And I'm also curious which toolchains you've used that seem better... |
| 2022-01-18 15:46:18 +0100 | <leibniz> | discussing the merits of haskell as a language on a channel dedicated to haskell seems a bit pointless |
| 2022-01-18 15:46:42 +0100 | <leibniz> | its not as if its advertising to anyone not already part of the community |
| 2022-01-18 15:47:19 +0100 | <leibniz> | but certainly stack, by allowing persistent builds across time, is an unprecedentedly useful tool, setting haskells toolchain arguably ahead of any other language |
| 2022-01-18 15:47:22 +0100 | alx741 | (~alx741@157.100.93.160) |
| 2022-01-18 15:49:14 +0100 | shriekingnoise | (~shrieking@201.231.16.156) |
| 2022-01-18 15:49:16 +0100 | mmhat | (~mmh@55d4d6e9.access.ecotel.net) |
| 2022-01-18 15:49:51 +0100 | leibniz | (~leibniz@cpc101088-sgyl37-2-0-cust22.18-2.cable.virginm.net) (Quit: Connection closed) |
| 2022-01-18 15:50:28 +0100 | alx741 | (~alx741@157.100.93.160) (Read error: Connection reset by peer) |
| 2022-01-18 15:51:11 +0100 | <merijn> | I fear you have much more faith in stack than I, and that's not the part of the toolchain I'd consider good, tbh :p |
| 2022-01-18 15:51:57 +0100 | <ksqsf> | cabal is great. it is mostly declarative but also supports advanced constructs like 'if'. |
| 2022-01-18 15:52:39 +0100 | <ksqsf> | though some keywords are really weird, like 'hs-source-dirs' |
| 2022-01-18 15:52:57 +0100 | <merijn> | ksqsf: Seems perfectly cromulent? |
| 2022-01-18 15:54:14 +0100 | <ksqsf> | it's acceptable but i don't know why there is 'hs-' |
| 2022-01-18 15:54:35 +0100 | <sclv> | cabal also allows persistent builds across time and also lots of tools for lots of languages |
| 2022-01-18 15:54:50 +0100 | <Sqaure> | i couldnt get hs-source-dirs to handle ../some/path some days ago. But im on some 2-3 yo cabal version. |
| 2022-01-18 15:54:58 +0100 | <sclv> | The idea has been around a minute |
| 2022-01-18 15:55:32 +0100 | <sclv> | src dirs shouldn’t handle paths like that because those don’t go into tarballs |
| 2022-01-18 15:56:01 +0100 | <merijn> | ksqsf: You can package C sources in Haskell packages (and there's work on C++ too, and no reason other languages couldn't be included) |
| 2022-01-18 15:56:49 +0100 | <merijn> | ksqsf: so hs- lets you distinguish from (potential) future extensions such as c-source-dirs and cxx-source-dirs, etc. :) |
| 2022-01-18 15:56:54 +0100 | <sshine> | merijn, I like Rust's cargo a lot :) I *think* Go's toolchain is good (but I've never used it), and I *have* used Perl's, which is not that bad, although, of course, the language itself is... let's not go there. :-P |
| 2022-01-18 15:56:58 +0100 | <ksqsf> | merijn: nice to know, thanks |
| 2022-01-18 15:57:11 +0100 | Guest49 | (~Guest49@2405:201:1e:5848:ecc5:3ef:bb63:fa9f) |
| 2022-01-18 15:58:05 +0100 | <Guest49> | Hi |
| 2022-01-18 15:58:28 +0100 | <merijn> | sshine: Go's toolchain is only good if you believe "sacrificing hundreds/thousands of man hours to ensure everything always works with HEAD of everything else" is both feasible and good |
| 2022-01-18 15:59:03 +0100 | <Guest49> | Is there a way that I can contribute to Haskell? |
| 2022-01-18 15:59:21 +0100 | <sshine> | merijn, good toolchains require sacrifices. I can't say what went into it, but I did once try to install Go code, and it was easy. |
| 2022-01-18 15:59:22 +0100 | <merijn> | Depends what kinda contributions you are interested in making? :) |
| 2022-01-18 15:59:38 +0100 | <merijn> | sshine: Hackage doesn't have the manpower to make that work |
| 2022-01-18 15:59:44 +0100 | LukeHoersten | (~LukeHoers@user/lukehoersten) |
| 2022-01-18 15:59:56 +0100 | <sshine> | merijn, I think you can make a statement about the quality of a tool without making a moral statement about how it came to be. but sure, the latter is not unimportant. |
| 2022-01-18 15:59:57 +0100 | <fendor[m]> | didn't go move to a cargo like approach? |
| 2022-01-18 16:00:06 +0100 | <merijn> | sshine: It's the same with people saying "oh, bet debian packages make this work!". Sure, by virtue of throwing hundreds of man hours to fix each individual issue" |
| 2022-01-18 16:00:08 +0100 | max22- | (~maxime@2a01cb08833598005d86ce1a880654d8.ipv6.abo.wanadoo.fr) |
| 2022-01-18 16:00:37 +0100 | <sshine> | merijn, I also use Debian. apparently I believe in sacrificing humans. |
| 2022-01-18 16:00:39 +0100 | <sshine> | :P |
| 2022-01-18 16:00:40 +0100 | <merijn> | sshine: I'm saying the quality you observe isn't a part of the tool, but the manpower thrown against the problem |
| 2022-01-18 16:00:52 +0100 | <maerwald> | I doubt that |
| 2022-01-18 16:00:56 +0100 | <merijn> | sshine: i.e. if we threw the same manpower at hackage we'd have the same result |
| 2022-01-18 16:01:09 +0100 | <maerwald> | debian is the perfect example: lots of manpower and lots of f-ups |
| 2022-01-18 16:01:43 +0100 | <sshine> | merijn, the tool is the thing I download and see working, because of the time spent to make it work. it sounds like you're justifying why a tool isn't bad because people didn't kill themselves fixing it (yet) :) |
| 2022-01-18 16:02:26 +0100 | <Guest49> | Something simple, maybe adding a small but missing feature in the std lib. or maybe some issue that I can try to fix |
| 2022-01-18 16:02:59 +0100 | <Clint> | debian doesn't have lots of manpower |
| 2022-01-18 16:03:23 +0100 | <sshine> | Guest49, this might be for you: https://discourse.haskell.org/t/a-new-future-for-cryptography-in-haskell/3888 |
| 2022-01-18 16:03:38 +0100 | <ksqsf> | Clint: why? debian has ~1000 DDs and DMs |
| 2022-01-18 16:03:56 +0100 | <sshine> | Clint, I think what's meant here is that Debian's maintainer model depends on manpower. |
| 2022-01-18 16:04:04 +0100 | <merijn> | sshine: I don't mean "fixing the tool" I mean that most breakage isn't breakage in the tooling, but in the packages you are trying to install |
| 2022-01-18 16:04:06 +0100 | <Clint> | ksqsf: most of whom are not active |
| 2022-01-18 16:04:30 +0100 | <sshine> | merijn, my software isn't broken, you're giving it wrong inputs! |
| 2022-01-18 16:04:34 +0100 | <merijn> | sshine: Most "cabal problems" are "this set of dependencies doesn't install", which is not a problem with cabal, but with your dependencies |
| 2022-01-18 16:04:57 +0100 | <ksqsf> | NixOS has far less manpower, but a great tool (Nix) helps a lot |
| 2022-01-18 16:05:02 +0100 | <merijn> | Clint: It does compared to Hackage |
| 2022-01-18 16:05:16 +0100 | <merijn> | Clint: Hackage has, like, low double digit people *at best* |
| 2022-01-18 16:05:36 +0100 | <ksqsf> | iirc Nix ships even more packages than Debian does |
| 2022-01-18 16:06:27 +0100 | <sshine> | merijn, maybe it is impossible to even define the quality of a tool without making statements about its dependencies, and so any statement about the tool is really a statement about other things. :-D somehow, this completely derails any comparative assessment about toolchains. |
| 2022-01-18 16:06:44 +0100 | Guest49 | (~Guest49@2405:201:1e:5848:ecc5:3ef:bb63:fa9f) (Quit: Client closed) |
| 2022-01-18 16:07:13 +0100 | <merijn> | sshine: The quality of a toolchain, to me, is how easily you can integrate it into larger systems. How predictable it's behaviour is. etc. |
| 2022-01-18 16:07:57 +0100 | <merijn> | cabal-install is very predictable, allows for all the possible control I've needed and integrates into larger build system fairly well (there's some room for improvement still, but infinitely better than, say, pip) |
| 2022-01-18 16:08:59 +0100 | alx741 | (~alx741@157.100.93.160) |
| 2022-01-18 16:08:59 +0100 | <maerwald> | not sure a constraint solver is really what you'd call predictable from a user pov |
| 2022-01-18 16:09:21 +0100 | max22- | (~maxime@2a01cb08833598005d86ce1a880654d8.ipv6.abo.wanadoo.fr) (Ping timeout: 268 seconds) |
| 2022-01-18 16:09:32 +0100 | <merijn> | maerwald: It is a 1) a predictable constraint solver and 2) you can freeze it and/or use index-state to achieve that for users |
| 2022-01-18 16:09:33 +0100 | pavonia | (~user@user/siracusa) (Quit: Bye!) |
| 2022-01-18 16:10:21 +0100 | <maerwald> | I'm not sure what a predictable constraint solver is... I'm talking about naive user interaction |
| 2022-01-18 16:10:40 +0100 | <maerwald> | stack has predictability as a priority, I don't think cabal has |
| 2022-01-18 16:11:50 +0100 | <merijn> | maerwald: as of v2-build the solver is (to the best of my knowledge) deterministic, so that the same index-state will always produce the same plan (and always preferring the newest admissible versions) |
| 2022-01-18 16:12:07 +0100 | alx741 | (~alx741@157.100.93.160) (Read error: Connection reset by peer) |
| 2022-01-18 16:12:15 +0100 | <maerwald> | sure |
| 2022-01-18 16:12:27 +0100 | <maerwald> | well, not exactly, but almost |
| 2022-01-18 16:12:32 +0100 | <maerwald> | flags and pkg-config can change that |
| 2022-01-18 16:12:39 +0100 | <sshine> | merijn, I'm talking about the experience of using the tool. in the case of Cabal, the experience is pretty good in spite of how you can delegate the responsibility/probability of success to however coherent the package graph you happen to refer to at the time of evaluation. clearly there's some ideological difference here where it seems like you don't want any one point of failure to reflect the quality |
| 2022-01-18 16:12:45 +0100 | <sshine> | of "the thing" (tool, language, ecosystem, whatever), whereas with e.g. Stack's snapshots, you do get something to point your fingers at if it breaks, but you also have to sacrifice humans to make those snapshots both consistent and recent. |
| 2022-01-18 16:12:55 +0100 | zmt01 | (~zmt00@user/zmt00) |
| 2022-01-18 16:13:15 +0100 | texasmynsted | (~texasmyns@99.96.221.112) |
| 2022-01-18 16:14:11 +0100 | <ksqsf> | I think most of this UX problem is just that GHC insists on having a set of compatible versions |
| 2022-01-18 16:14:40 +0100 | Sgeo | (~Sgeo@user/sgeo) |
| 2022-01-18 16:15:22 +0100 | <maerwald> | merijn: from a user POV, cabal is not predictable. By default, the input is mutable/rolling and the result of a resolution is not something they would be able to predict |
| 2022-01-18 16:15:27 +0100 | <ksqsf> | ksqsf: while Rust just compiles and links every needed major versions |
| 2022-01-18 16:15:51 +0100 | wroathe | (~wroathe@user/wroathe) (Ping timeout: 256 seconds) |
| 2022-01-18 16:16:10 +0100 | <sshine> | ksqsf, a set of compatible versions of what? |
| 2022-01-18 16:16:19 +0100 | <ksqsf> | sshine: build-depends |
| 2022-01-18 16:16:35 +0100 | dsrt^ | (~dsrt@wsip-98-188-242-61.mc.at.cox.net) (Remote host closed the connection) |
| 2022-01-18 16:17:38 +0100 | <merijn> | ksqsf: GHC actually admits conflicting versions, to some extend |
| 2022-01-18 16:18:03 +0100 | <merijn> | ksqsf: But it's messy and hairy and cabal doesn't allow it for that reason, because it's likely to break shit |
| 2022-01-18 16:18:13 +0100 | <merijn> | *extent |
| 2022-01-18 16:21:05 +0100 | jackson99 | (~bc8147f2@cerf.good1.com) |
| 2022-01-18 16:21:39 +0100 | <ksqsf> | hmm, I'm not really sure GHC can be like Rust in this regard; Rust has more restrictions on class instances for coherence |
| 2022-01-18 16:22:34 +0100 | Pickchea | (~private@user/pickchea) (Ping timeout: 250 seconds) |
| 2022-01-18 16:23:15 +0100 | <ksqsf> | but it would be great if it turned out to be feasible |
| 2022-01-18 16:23:52 +0100 | wroathe | (~wroathe@206-55-188-8.fttp.usinternet.com) |
| 2022-01-18 16:23:52 +0100 | wroathe | (~wroathe@206-55-188-8.fttp.usinternet.com) (Changing host) |
| 2022-01-18 16:23:52 +0100 | wroathe | (~wroathe@user/wroathe) |
| 2022-01-18 16:26:05 +0100 | ksqsf | (~user@134.209.106.31) (Remote host closed the connection) |
| 2022-01-18 16:26:24 +0100 | ksqsf | (~user@134.209.106.31) |
| 2022-01-18 16:27:27 +0100 | xb0o2 | (~xb0o2@user/xb0o2) |
| 2022-01-18 16:27:44 +0100 | LukeHoersten | (~LukeHoers@user/lukehoersten) (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 2022-01-18 16:28:28 +0100 | wroathe | (~wroathe@user/wroathe) (Ping timeout: 268 seconds) |
| 2022-01-18 16:28:50 +0100 | geekosaur | (~geekosaur@xmonad/geekosaur) (Remote host closed the connection) |
| 2022-01-18 16:29:01 +0100 | alx741 | (~alx741@157.100.93.160) |
| 2022-01-18 16:30:46 +0100 | geekosaur | (~geekosaur@xmonad/geekosaur) |
| 2022-01-18 16:37:26 +0100 | zmt01 | (~zmt00@user/zmt00) (Quit: Leaving) |
| 2022-01-18 16:37:33 +0100 | max22- | (~maxime@2a01cb0883359800e30a3abeb76df7a4.ipv6.abo.wanadoo.fr) |
| 2022-01-18 16:37:35 +0100 | shapr | (~user@98-159-193-131.scottsboro.org) |
| 2022-01-18 16:38:26 +0100 | zmt00 | (~zmt00@user/zmt00) |
| 2022-01-18 16:38:57 +0100 | alp | (~alp@user/alp) (Ping timeout: 268 seconds) |
| 2022-01-18 16:39:21 +0100 | laslmtdbm^ | (~laslmtdbm@wsip-98-188-242-61.mc.at.cox.net) |
| 2022-01-18 16:47:39 +0100 | alx741 | (~alx741@157.100.93.160) (Read error: Connection reset by peer) |
| 2022-01-18 16:47:40 +0100 | eggplantade | (~Eggplanta@2600:1700:bef1:5e10:81c9:f67f:1443:f972) |
| 2022-01-18 16:47:54 +0100 | sm2n | (ae95cb1267@user/sm2n) (Remote host closed the connection) |
| 2022-01-18 16:47:54 +0100 | filwisher | (2e6936c793@2604:bf00:561:2000::170) (Remote host closed the connection) |
| 2022-01-18 16:47:54 +0100 | tdmm | (1c9b9145fc@2604:bf00:561:2000::1c8) (Remote host closed the connection) |
| 2022-01-18 16:47:54 +0100 | jkoshy | (99b9359beb@2604:bf00:561:2000::10f) (Remote host closed the connection) |
| 2022-01-18 16:47:54 +0100 | jakzale | (6291399afa@user/jakzale) (Remote host closed the connection) |
| 2022-01-18 16:47:54 +0100 | samhh | (7569f027cf@2604:bf00:561:2000::e4) (Remote host closed the connection) |
| 2022-01-18 16:47:54 +0100 | evanrelf | (3addc196af@2604:bf00:561:2000::f0) (Remote host closed the connection) |
| 2022-01-18 16:47:54 +0100 | bsima1 | (9d7e39c8ad@2604:bf00:561:2000::dd) (Remote host closed the connection) |
| 2022-01-18 16:47:54 +0100 | Ankhers | (e99e97ef8e@2604:bf00:561:2000::2a2) (Remote host closed the connection) |
| 2022-01-18 16:47:54 +0100 | raghavgururajan | (ea769b8000@user/raghavgururajan) (Remote host closed the connection) |
| 2022-01-18 16:47:54 +0100 | lukec | (9dfd4d094e@2604:bf00:561:2000::10e) (Remote host closed the connection) |
| 2022-01-18 16:47:54 +0100 | fluffyballoon | (45ce440a48@2604:bf00:561:2000::e2) (Remote host closed the connection) |
| 2022-01-18 16:48:26 +0100 | filwisher | (2e6936c793@2604:bf00:561:2000::170) |
| 2022-01-18 16:48:27 +0100 | bsima1 | (9d7e39c8ad@2604:bf00:561:2000::dd) |
| 2022-01-18 16:48:27 +0100 | lukec | (9dfd4d094e@2604:bf00:561:2000::10e) |
| 2022-01-18 16:48:28 +0100 | samhh | (7569f027cf@2604:bf00:561:2000::e4) |
| 2022-01-18 16:48:37 +0100 | jakzale | (6291399afa@user/jakzale) |
| 2022-01-18 16:48:37 +0100 | Ankhers | (e99e97ef8e@2604:bf00:561:2000::2a2) |
| 2022-01-18 16:48:42 +0100 | evanrelf | (3addc196af@2604:bf00:561:2000::f0) |
| 2022-01-18 16:48:42 +0100 | fluffyballoon | (45ce440a48@2604:bf00:561:2000::e2) |
| 2022-01-18 16:48:42 +0100 | tdmm | (1c9b9145fc@2604:bf00:561:2000::1c8) |
| 2022-01-18 16:48:42 +0100 | jkoshy | (99b9359beb@2604:bf00:561:2000::10f) |
| 2022-01-18 16:48:45 +0100 | sm2n | (ae95cb1267@user/sm2n) |
| 2022-01-18 16:48:49 +0100 | raghavgururajan | (ea769b8000@user/raghavgururajan) |
| 2022-01-18 16:49:06 +0100 | n3rdy1 | (~n3rdy1@2600:1700:4570:3480::41) |
| 2022-01-18 16:49:43 +0100 | myShoggoth | (~myShoggot@97-120-67-120.ptld.qwest.net) |
| 2022-01-18 16:52:02 +0100 | eggplantade | (~Eggplanta@2600:1700:bef1:5e10:81c9:f67f:1443:f972) (Ping timeout: 250 seconds) |
| 2022-01-18 16:52:16 +0100 | ec | (~ec@gateway/tor-sasl/ec) |
| 2022-01-18 16:53:51 +0100 | jlamothe | (~jlamothe@198.251.61.229) (Quit: leaving) |
| 2022-01-18 16:53:55 +0100 | stiell | (~stiell@gateway/tor-sasl/stiell) |
| 2022-01-18 16:54:28 +0100 | cosimone | (~user@93-47-230-83.ip115.fastwebnet.it) |
| 2022-01-18 16:55:45 +0100 | ProfSimm | (~ProfSimm@176-12-60-137.pon.spectrumnet.bg) |
| 2022-01-18 16:55:48 +0100 | <sclv> | rust’s model can lead to both compile time and runtime failures https://doc.rust-lang.org/cargo/reference/resolver.html#version-incompatibility-hazards |
| 2022-01-18 16:55:55 +0100 | SummerSonw | (~The_viole@203.77.49.232) (Ping timeout: 256 seconds) |
| 2022-01-18 16:56:23 +0100 | <sclv> | haskellers are just less forgiving of such things and so the safer more restrictive choice is made |
| 2022-01-18 16:57:36 +0100 | jakalx | (~jakalx@base.jakalx.net) (Error from remote client) |
| 2022-01-18 16:58:24 +0100 | stiell_ | (~stiell@gateway/tor-sasl/stiell) (Ping timeout: 276 seconds) |
| 2022-01-18 16:59:38 +0100 | ProfSimm | (~ProfSimm@176-12-60-137.pon.spectrumnet.bg) (Remote host closed the connection) |
| 2022-01-18 16:59:57 +0100 | ProfSimm | (~ProfSimm@176-12-60-137.pon.spectrumnet.bg) |
| 2022-01-18 17:00:02 +0100 | jakalx | (~jakalx@base.jakalx.net) |
| 2022-01-18 17:02:21 +0100 | Hildegunst | (~luc@80.248.12.109.rev.sfr.net) |
| 2022-01-18 17:04:04 +0100 | alx741 | (~alx741@157.100.93.160) |
| 2022-01-18 17:06:05 +0100 | ProfSimm | (~ProfSimm@176-12-60-137.pon.spectrumnet.bg) (Remote host closed the connection) |
| 2022-01-18 17:06:24 +0100 | ProfSimm | (~ProfSimm@176-12-60-137.pon.spectrumnet.bg) |
| 2022-01-18 17:07:38 +0100 | alx741 | (~alx741@157.100.93.160) (Read error: Connection reset by peer) |
| 2022-01-18 17:07:51 +0100 | newsham | (~newsham@2603-800c-2d00-e994-c564-1d76-1f18-c3ec.res6.spectrum.com) |
| 2022-01-18 17:08:10 +0100 | jlamothe | (~jlamothe@198.251.61.229) |
| 2022-01-18 17:08:32 +0100 | laslmtdbm^ | (~laslmtdbm@wsip-98-188-242-61.mc.at.cox.net) (Ping timeout: 240 seconds) |
| 2022-01-18 17:10:15 +0100 | merijn | (~merijn@c-001-001-018.client.esciencecenter.eduvpn.nl) (Ping timeout: 256 seconds) |
| 2022-01-18 17:16:44 +0100 | lortabac | (~lortabac@2a01:e0a:541:b8f0:8c5a:efae:38ab:4ad2) (Quit: WeeChat 2.8) |
| 2022-01-18 17:17:32 +0100 | shapr | (~user@98-159-193-131.scottsboro.org) (Ping timeout: 240 seconds) |
| 2022-01-18 17:17:52 +0100 | lavaman | (~lavaman@98.38.249.169) |
| 2022-01-18 17:18:00 +0100 | burnsidesLlama | (~burnsides@dhcp168-015.wadham.ox.ac.uk) (Remote host closed the connection) |
| 2022-01-18 17:19:20 +0100 | laslmtdbm^ | (~laslmtdbm@wsip-98-188-242-61.mc.at.cox.net) |
| 2022-01-18 17:20:37 +0100 | myShoggoth | (~myShoggot@97-120-67-120.ptld.qwest.net) (Ping timeout: 240 seconds) |
| 2022-01-18 17:22:33 +0100 | lavaman | (~lavaman@98.38.249.169) (Ping timeout: 256 seconds) |
| 2022-01-18 17:24:05 +0100 | alx741 | (~alx741@157.100.93.160) |
| 2022-01-18 17:25:12 +0100 | ksqsf | (~user@134.209.106.31) (Ping timeout: 268 seconds) |
| 2022-01-18 17:26:05 +0100 | ksqsf | (~user@134.209.106.31) |
| 2022-01-18 17:27:03 +0100 | alx741 | (~alx741@157.100.93.160) (Read error: Connection reset by peer) |
| 2022-01-18 17:28:40 +0100 | Henson | (~kvirc@107-179-133-201.cpe.teksavvy.com) |
| 2022-01-18 17:29:33 +0100 | yauhsien | (~yauhsien@61-231-62-246.dynamic-ip.hinet.net) |
| 2022-01-18 17:31:52 +0100 | myShoggoth | (~myShoggot@97-120-67-120.ptld.qwest.net) |
| 2022-01-18 17:32:16 +0100 | tromp | (~textual@dhcp-077-249-230-040.chello.nl) |
| 2022-01-18 17:33:53 +0100 | yauhsien | (~yauhsien@61-231-62-246.dynamic-ip.hinet.net) (Ping timeout: 256 seconds) |
| 2022-01-18 17:34:57 +0100 | <Henson> | Hi everyone, I'm trying to understand this performance confusion I'm encountering with the following Haskell code https://paste.tomsmeding.com/U6K7rBaM. It's just a simple benchmark to crunch a quadratic curve fit 1 million times. On my (old) laptop this runs in 0.02 seconds. However, if I change line 8 from "!pVal" to "pVal" then it runs in 2.0 seconds. Why is there such an enormous performance boost for this simple strict evaluation? |
| 2022-01-18 17:35:57 +0100 | <Henson> | I'm trying to understand this as I have much more complicated code that does something similar, and I'm wondering if I can make the performance much greater with a few simple bang patterns in the right spot. |
| 2022-01-18 17:35:57 +0100 | perrierjouet | (~perrier-j@modemcable012.251-130-66.mc.videotron.ca) (Quit: WeeChat 3.4) |
| 2022-01-18 17:36:22 +0100 | <Henson> | well, similar code embedded in a much more complicated program. |
| 2022-01-18 17:36:49 +0100 | <sm> | it's laziness at work. Accumulators in tight loops are something you want to be evaluated eagerly |
| 2022-01-18 17:36:55 +0100 | perrierjouet | (~perrier-j@modemcable012.251-130-66.mc.videotron.ca) |
| 2022-01-18 17:37:43 +0100 | <Henson> | sm: is there a way I can profile my code to determine what parts are being held up by laziness and where I should add eager evaluations? |
| 2022-01-18 17:37:53 +0100 | <sm> | Debug.Trace can be useful for seeing when things are being evaluated |
| 2022-01-18 17:38:03 +0100 | cfricke | (~cfricke@user/cfricke) (Quit: WeeChat 3.3) |
| 2022-01-18 17:38:06 +0100 | Jing | (~hedgehog@240e:390:7c53:a7e1:a9:59ba:3231:6160) (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 2022-01-18 17:38:58 +0100 | <sm> | there's no magic tool alas, it's one of the skills a haskeller needs to develop. Though in practice, I find it doesn't come up that often in real code |
| 2022-01-18 17:39:08 +0100 | wroathe | (~wroathe@206-55-188-8.fttp.usinternet.com) |
| 2022-01-18 17:39:08 +0100 | wroathe | (~wroathe@206-55-188-8.fttp.usinternet.com) (Changing host) |
| 2022-01-18 17:39:08 +0100 | wroathe | (~wroathe@user/wroathe) |
| 2022-01-18 17:39:21 +0100 | <sm> | I don't think a profile helps here... |
| 2022-01-18 17:39:23 +0100 | <Henson> | sm: but the pVal isn't even an accumulator, it's just an index to prevent Haskell from reusing the previously calculated inputs and outputs |
| 2022-01-18 17:39:50 +0100 | <c_wraith> | I keep thinking about this. There is a simple set of rules to follow to prevent space use problems. It should be possible to write some sort of assistance to validate that you're following those rules. |
| 2022-01-18 17:40:27 +0100 | [itchyjunk] | (~itchyjunk@user/itchyjunk/x-7353470) |
| 2022-01-18 17:41:58 +0100 | <sm> | c_wraith++ |
| 2022-01-18 17:42:17 +0100 | Pickchea | (~private@user/pickchea) |
| 2022-01-18 17:43:04 +0100 | <sm> | Henson: I hear you. I can't see the exact mechanism myself, but I would guess the tuple is the problem, maybe the strict pval helps force it ? |
| 2022-01-18 17:43:33 +0100 | <c_wraith> | the problem comes from going "this set of rules is simple" to actually writing the rules down. Because they aren't actually quite so simple when you deal with all the extra cases |
| 2022-01-18 17:43:51 +0100 | <Henson> | sm: in the more complex production code there's a simple "p2 = sum $ map (\(t,p) -> p*t) (zip times positions)" where times :: [Double] and positions :: [Double] that takes up a big chunk of the time when profiling. It's a pretty simple operation, but gets done a lot. If the times and positions lists need to be evaluated to calculate p3, does the evaluation of those lists count towards the... |
| 2022-01-18 17:43:59 +0100 | <sm> | tuples always cause thunk leaks so should not be used as an accumulator |
| 2022-01-18 17:44:09 +0100 | <shane> | You know the way the `time` library has `UTCTime` and `NominalDiffTime`, where `NominalDiffTime` is a number, and can be added to and subtracted from `UTCTime`, and `UTCTime` can be subtracted from itself to produce a `NominalDiffTime`, but `UTCTime` is not itself a number? And there's a related thing going on with the `.+^`, `.-^` and `.-.` operators from `Linear.Affine`. What I want to ask is, is there a |
| 2022-01-18 17:44:15 +0100 | <shane> | general name for this type of thing in abstract algebra, and are there any Haskell packages that try to implement it? |
| 2022-01-18 17:44:15 +0100 | <Henson> | sm: calculation time of p3, or does it get attributed to the functions that went into producing the times and positions lists? |
| 2022-01-18 17:44:31 +0100 | <c_wraith> | You can use a tuple in an accumulator as long as your function producing them seqs the elements first. |
| 2022-01-18 17:44:53 +0100 | <c_wraith> | Strictness isn't about the data structures you use, it's about when things get evaluated. |
| 2022-01-18 17:45:19 +0100 | <sm> | c_wraith: if we could at least write them down such that a human could evaluate/check them relatively easily, that would still be a big help |
| 2022-01-18 17:45:42 +0100 | alx741 | (~alx741@157.100.93.160) |
| 2022-01-18 17:45:55 +0100 | <c_wraith> | remember that a strict pair type doesn't do anything you couldn't do by writing seq twice by hand. :) |
| 2022-01-18 17:46:02 +0100 | xff0x | (~xff0x@2001:1a81:5209:df00:5e7c:4acd:2a77:4d24) (Ping timeout: 240 seconds) |
| 2022-01-18 17:46:31 +0100 | <Henson> | c_wraith: how do I seq the elements first? just seq the list, or figure out how to deepseq them? |
| 2022-01-18 17:46:52 +0100 | <c_wraith> | deepseq is more of a debugging tool. It'll never show up in optimized code. |
| 2022-01-18 17:46:55 +0100 | wroathe | (~wroathe@user/wroathe) (Ping timeout: 256 seconds) |
| 2022-01-18 17:46:59 +0100 | xff0x | (~xff0x@2001:1a81:5209:df00:b3fa:3a32:fd8e:f809) |
| 2022-01-18 17:47:00 +0100 | <c_wraith> | It's not efficient at all |
| 2022-01-18 17:47:16 +0100 | pfurla | (~pfurla@2804:d41:4331:4800:2caa:3e9f:9236:25d4) (Quit: gone to sleep. ZZZzzz…) |
| 2022-01-18 17:47:59 +0100 | <Henson> | also, the performance problems of laziness comes up all the time for me in my reading, and the difficulty in reasoning about performance and space issues. Was it a good idea to make Haskell a lazy language, given that so few others are? Not to derail my own conversation here, but what are the benefits of laziness in practice, as I mostly hear about the downsides of it. |
| 2022-01-18 17:47:59 +0100 | <sm> | Henson: I don't know the answer to your profiling q, seeing the profile and code might help. I have found profiles hard and sometimes misleading to read |
| 2022-01-18 17:48:01 +0100 | alx741 | (~alx741@157.100.93.160) (Read error: Connection reset by peer) |
| 2022-01-18 17:48:12 +0100 | <c_wraith> | Henson: that line you're talking about doesn't look like a problem. I mean, you probably want to use zipWith instead of zip + map, but that's for clarity rather than performance |
| 2022-01-18 17:48:51 +0100 | <c_wraith> | Henson: if that line is being credited with a performance problem, it's in the generation of one of those lists. not that line itself |
| 2022-01-18 17:49:07 +0100 | <c_wraith> | and laziness is wonderful. |
| 2022-01-18 17:49:18 +0100 | <c_wraith> | It lets you write code that's actually efficiently composable |
| 2022-01-18 17:49:40 +0100 | burnsidesLlama | (~burnsides@dhcp168-015.wadham.ox.ac.uk) |
| 2022-01-18 17:49:45 +0100 | <sm> | Henson: it's generally considered worthwhile for forcing purity and supporting greater abstraction, although people always wonder what a "strict haskell" would be like |
| 2022-01-18 17:50:19 +0100 | <Henson> | c_wraith: do you have any suggestions as to avenues and techniques I could investigate to try to get the lists to be evaluated eagerly? Should I target the sites where they are produced for eager evaluation, or where they're consumed, or (hopefully not) somewhere in-between? |
| 2022-01-18 17:50:24 +0100 | <sm> | it's also not as much of a problem in practice as it may sound - for most people |
| 2022-01-18 17:50:35 +0100 | <maerwald> | Henson: forcing evaluation of 'a' in quadFit seems to have the same effect |
| 2022-01-18 17:50:55 +0100 | xb0o2 | (~xb0o2@user/xb0o2) (Quit: Client closed) |
| 2022-01-18 17:50:59 +0100 | Henson | tests |
| 2022-01-18 17:51:42 +0100 | <c_wraith> | Henson: that question is... not going to lead you anywhere useful. If you're producing lists, you don't want to do it strictly. What you want to be doing is making sure that consuming the spine of the list doesn't generate nested thunks. |
| 2022-01-18 17:51:47 +0100 | coot | (~coot@89-64-85-93.dynamic.chello.pl) (Quit: coot) |
| 2022-01-18 17:53:08 +0100 | n3rdy1 | (~n3rdy1@2600:1700:4570:3480::41) (Ping timeout: 250 seconds) |
| 2022-01-18 17:53:12 +0100 | <maerwald> | sm: until it is and then you're in big trouble |
| 2022-01-18 17:53:14 +0100 | <maerwald> | :) |
| 2022-01-18 17:53:18 +0100 | <c_wraith> | Henson: a lot of the trouble people have is that not realizing that producing lazy data structures must be done with as much care as consuming them. |
| 2022-01-18 17:53:20 +0100 | <Henson> | c_wraith: can you explain that more? I know what thunks are, but don't really understand what you're suggesting or how I would make sure I'm not doing that. |
| 2022-01-18 17:53:34 +0100 | MajorBiscuit | (~MajorBisc@c-001-025-054.client.tudelft.eduvpn.nl) (Ping timeout: 268 seconds) |
| 2022-01-18 17:53:57 +0100 | zebrag | (~chris@user/zebrag) |
| 2022-01-18 17:53:59 +0100 | <sm> | we should have a reading list for this topic |
| 2022-01-18 17:54:02 +0100 | burnsidesLlama | (~burnsides@dhcp168-015.wadham.ox.ac.uk) (Ping timeout: 240 seconds) |
| 2022-01-18 17:54:09 +0100 | <sm> | @where laziness |
| 2022-01-18 17:54:09 +0100 | <lambdabot> | I know nothing about laziness. |
| 2022-01-18 17:54:19 +0100 | <maerwald> | sm: it's a constantly moving target |
| 2022-01-18 17:54:32 +0100 | <c_wraith> | maerwald: it really isn't. If you get it right, you've got it right. |
| 2022-01-18 17:54:42 +0100 | lbseale | (~ep1ctetus@user/ep1ctetus) |
| 2022-01-18 17:54:44 +0100 | <maerwald> | c_wraith: unless inlining is involved |
| 2022-01-18 17:54:55 +0100 | <c_wraith> | things only move if you get it wrong and depend on the compiler to rescue you |
| 2022-01-18 17:55:26 +0100 | <maerwald> | there's no right or wrong in terms of optimization tricks for the inliner |
| 2022-01-18 17:56:39 +0100 | <Henson> | maerwald: how did you force it? I put a bang on a in quadFit and it made it about twice as fast, but the bang on pVal makes it 70 times faster. |
| 2022-01-18 17:57:25 +0100 | <maerwald> | Henson: in seq a (accA + a, accB + b, accC + c) |
| 2022-01-18 17:57:49 +0100 | <Henson> | c_wraith: I'm also interested in learning more about how to carefully produce and consume lazy data structures |
| 2022-01-18 17:57:59 +0100 | <maerwald> | I also played a little with using a lambda as argument to foldl' |
| 2022-01-18 17:58:09 +0100 | <maerwald> | which also seemed to make some difference in some circumstance |
| 2022-01-18 17:58:27 +0100 | Danishman | (~Danishman@2-104-144-110-cable.dk.customer.tdc.net) |
| 2022-01-18 17:59:30 +0100 | <Henson> | maerwald: interesting! seq'ing any of a,b,c or pVal (at least) cause the performance increase |
| 2022-01-18 17:59:44 +0100 | vglfr | (~vglfr@46.96.165.111) (Ping timeout: 268 seconds) |
| 2022-01-18 18:00:41 +0100 | whatif | (~user@123.123.223.41) |
| 2022-01-18 18:00:52 +0100 | <Henson> | maerwald: how is it that "seq a" makes a difference, but putting a bang on (!a,b,c) doesn't make a difference? Don't they do the same thing? |
| 2022-01-18 18:00:53 +0100 | <whatif> | why there's so many String in haskell? |
| 2022-01-18 18:01:37 +0100 | <whatif> | Data.ByteString, Data.ByteString.Lazy.Internal.ByteString, [Word 8], Data.Text, Lazy blabla |
| 2022-01-18 18:01:42 +0100 | <razetime> | https://mmhaskell.com/blog/2017/5/15/untangling-haskells-strings |
| 2022-01-18 18:01:45 +0100 | <whatif> | what's wrong with string |
| 2022-01-18 18:01:47 +0100 | <c_wraith> | Henson: it's a somewhat big topic, and I don't have anything prepared. The best I can do right now is say that I finally started understanding how to think about this after reading https://apfelmus.nfshost.com/blog/2013/08/21-space-invariants.html |
| 2022-01-18 18:01:56 +0100 | <maerwald> | Henson: also check out this: https://paste.tomsmeding.com/P3xMdKX9 |
| 2022-01-18 18:01:59 +0100 | deadmarshal | (~deadmarsh@95.38.228.70) |
| 2022-01-18 18:02:15 +0100 | <maerwald> | there I force inside quadFit... but it only works if using the lambda-form above or so |
| 2022-01-18 18:02:28 +0100 | <geekosaur> | whatif: everything? one string type does not actually cover all use cases, and most programmers do stupid things with them |
| 2022-01-18 18:02:39 +0100 | <whatif> | I need Data.ByteString.Lazy.Internal.ByteString to write to file, there's no writeFile implement, only Data.ByteString has writeFile |
| 2022-01-18 18:02:45 +0100 | <ksqsf> | whatif: String is a linked list of characters, which is unreasonable in practice |
| 2022-01-18 18:02:57 +0100 | <c_wraith> | whatif: String has always been underspecified. Some languages just let you ignore that. Look at Rust if you want to see what being *really* careful about strings looks like |
| 2022-01-18 18:03:17 +0100 | Hildegunst | (~luc@80.248.12.109.rev.sfr.net) (Ping timeout: 240 seconds) |
| 2022-01-18 18:03:18 +0100 | <c_wraith> | ksqsf: String is fine when its semantics are correct. But often they aren't. |
| 2022-01-18 18:03:50 +0100 | <geekosaur> | https://hackage.haskell.org/package/bytestring-0.11.2.0/docs/Data-ByteString-Lazy.html#v:writeFile |
| 2022-01-18 18:04:38 +0100 | <whatif> | geekosaur: what's the 'Internal' here mean? |
| 2022-01-18 18:04:48 +0100 | <c_wraith> | nothing. |
| 2022-01-18 18:04:49 +0100 | alx741 | (~alx741@157.100.93.160) |
| 2022-01-18 18:04:52 +0100 | <shane> | If anyone was wondering, I found the answer to my question above: torsors |
| 2022-01-18 18:04:52 +0100 | <c_wraith> | literally ignore it. |
| 2022-01-18 18:05:02 +0100 | <c_wraith> | Internal means that the normal name wasn't imported |
| 2022-01-18 18:05:04 +0100 | <ksqsf> | c_wraith: sure, if you only consider the semantics; but my point is that String is slow, and if you use String as a store format, it can take much RAM |
| 2022-01-18 18:05:05 +0100 | <whatif> | c_wraith: then why people don't remove it? |
| 2022-01-18 18:05:06 +0100 | <geekosaur> | that you didn't import Data.ByteString.Lazy so it hunted it down to its source, which is the core implementation in the Internal module |
| 2022-01-18 18:05:28 +0100 | <sm> | @where+ spaceleaks https://apfelmus.nfshost.com/blog/2013/08/21-space-invariants.html |
| 2022-01-18 18:05:28 +0100 | <lambdabot> | Good to know. |
| 2022-01-18 18:05:31 +0100 | <geekosaur> | you almost never care. just import Data.ByteString.Lazy and get on with life |
| 2022-01-18 18:05:37 +0100 | vglfr | (~vglfr@46.96.165.111) |
| 2022-01-18 18:06:06 +0100 | n3rdy1 | (~n3rdy1@2600:1700:4570:3480:1b88:50f:dae0:9293) |
| 2022-01-18 18:06:07 +0100 | Hildegunst | (~luc@80.248.12.109.rev.sfr.net) |
| 2022-01-18 18:06:09 +0100 | sm | wonders why is lambdabot so slow |
| 2022-01-18 18:06:17 +0100 | <geekosaur> | as to why Strict vs. Lazy, Strict is faster but you probably don't want to suck a 10GB file into memeory to operate on it, so we have Lazy as well |
| 2022-01-18 18:06:26 +0100 | Hildegunst | (~luc@80.248.12.109.rev.sfr.net) (Client Quit) |
| 2022-01-18 18:06:31 +0100 | deadmarshal | (~deadmarsh@95.38.228.70) (Ping timeout: 268 seconds) |
| 2022-01-18 18:06:57 +0100 | <maerwald> | lazy bytestring is poor man's streaming |
| 2022-01-18 18:07:30 +0100 | econo | (uid147250@user/econo) |
| 2022-01-18 18:08:08 +0100 | alx741 | (~alx741@157.100.93.160) (Read error: Connection reset by peer) |
| 2022-01-18 18:08:49 +0100 | fendor | (~fendor@178.115.55.2.wireless.dyn.drei.com) |
| 2022-01-18 18:09:23 +0100 | <Henson> | c_wraith: thank you for the help and suggestions on the literature. I'll take a look at that |
| 2022-01-18 18:09:52 +0100 | <Henson> | maerwald: thanks for tinkering around with the code and suggesting improvments. I'll see what I'm able to do with the production code. |
| 2022-01-18 18:10:05 +0100 | <whatif> | how I can turn Data.ByteString.Lazy.Internal.String to String? |
| 2022-01-18 18:10:20 +0100 | <ksqsf> | unpack |
| 2022-01-18 18:10:29 +0100 | <whatif> | ksqsf: unpack get [Word8] |
| 2022-01-18 18:10:32 +0100 | mikoto-chan | (~mikoto-ch@213.177.151.239) (Ping timeout: 240 seconds) |
| 2022-01-18 18:10:38 +0100 | <whatif> | and what the heck Word8 is? |
| 2022-01-18 18:10:50 +0100 | CiaoSen | (~Jura@p200300c95737a2002a3a4dfffe84dbd5.dip0.t-ipconnect.de) (Ping timeout: 268 seconds) |
| 2022-01-18 18:11:12 +0100 | <ksqsf> | @hoogle Word8 -> Char |
| 2022-01-18 18:11:12 +0100 | <lambdabot> | Data.ByteString.Internal w2c :: Word8 -> Char |
| 2022-01-18 18:11:13 +0100 | <lambdabot> | Data.Text.Internal.Unsafe.Char unsafeChr8 :: Word8 -> Char |
| 2022-01-18 18:11:13 +0100 | <lambdabot> | Data.Bits.Utils w82c :: Word8 -> Char |
| 2022-01-18 18:11:35 +0100 | <maerwald> | uhm |
| 2022-01-18 18:12:09 +0100 | <maerwald> | that might not be what you want |
| 2022-01-18 18:12:20 +0100 | <ksqsf> | actually Word8-version ByteString is not intended to be directly used as String |
| 2022-01-18 18:12:24 +0100 | <whatif> | there's no w2c in Data.ByteString.Lazy |
| 2022-01-18 18:12:34 +0100 | <maerwald> | whatif: what's the data? UTF-8? |
| 2022-01-18 18:12:37 +0100 | <geekosaur> | no, it's an internal function |
| 2022-01-18 18:12:38 +0100 | mikoto-chan | (~mikoto-ch@213.177.151.239) |
| 2022-01-18 18:12:45 +0100 | <ksqsf> | you probably want decodeUtf8, or Char8-version ByteString if you only care about ASCII |
| 2022-01-18 18:13:03 +0100 | <whatif> | ksqsf: then why unpack Data.ByteString.Lazy get Word8 |
| 2022-01-18 18:13:29 +0100 | <ksqsf> | whatif: it's a byte array. |
| 2022-01-18 18:13:37 +0100 | <maerwald> | https://hackage.haskell.org/package/text-2.0/docs/Data-Text-Lazy-Encoding.html#v:decodeUtf8With |
| 2022-01-18 18:13:57 +0100 | <maerwald> | then T.unpack |
| 2022-01-18 18:14:03 +0100 | <whatif> | ksqsf: does Data.ByteString.Encoding come with ghc? |
| 2022-01-18 18:14:37 +0100 | <whatif> | @hoogle ByteString -> String |
| 2022-01-18 18:14:37 +0100 | <lambdabot> | Control.Lens.Internal.ByteString unpackStrict8 :: ByteString -> String |
| 2022-01-18 18:14:37 +0100 | <lambdabot> | Control.Lens.Internal.ByteString unpackLazy8 :: ByteString -> String |
| 2022-01-18 18:14:37 +0100 | <lambdabot> | Data.ByteString.Lazy.UTF8 toString :: ByteString -> String |
| 2022-01-18 18:14:43 +0100 | tromp | (~textual@dhcp-077-249-230-040.chello.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2022-01-18 18:18:33 +0100 | chele | (~chele@user/chele) (Remote host closed the connection) |
| 2022-01-18 18:18:42 +0100 | razetime | (~quassel@49.207.203.87) (Ping timeout: 250 seconds) |
| 2022-01-18 18:19:02 +0100 | <whatif> | Data.ByteString.Lazy.UTF8.toString can't work on Data.ByteString.Internal.ByteString, what? |
| 2022-01-18 18:19:13 +0100 | mikoto-chan | (~mikoto-ch@213.177.151.239) (Ping timeout: 256 seconds) |
| 2022-01-18 18:19:26 +0100 | eggplantade | (~Eggplanta@2600:1700:bef1:5e10:81c9:f67f:1443:f972) |
| 2022-01-18 18:19:43 +0100 | <whatif> | is there twenty kinds of String in Haskell? |
| 2022-01-18 18:20:10 +0100 | <monochrom> | 2 |
| 2022-01-18 18:20:19 +0100 | <maerwald> | whatif: yes |
| 2022-01-18 18:20:21 +0100 | tzh | (~tzh@c-24-21-73-154.hsd1.or.comcast.net) |
| 2022-01-18 18:20:22 +0100 | <monochrom> | String and Text. |
| 2022-01-18 18:20:36 +0100 | <whatif> | monochrom: and Char and Word8 |
| 2022-01-18 18:20:39 +0100 | <monochrom> | That's right, ByteString doesn't count. |
| 2022-01-18 18:20:48 +0100 | <whatif> | and a bunch of Lazy or Internel |
| 2022-01-18 18:20:54 +0100 | mikoto-chan | (~mikoto-ch@213.177.151.239) |
| 2022-01-18 18:20:58 +0100 | <whatif> | monochrom: what a pain in the ass |
| 2022-01-18 18:21:12 +0100 | <maerwald> | whatif: https://mmhaskell.com/blog/2017/5/15/untangling-haskells-strings |
| 2022-01-18 18:21:25 +0100 | <monochrom> | Unless your "string" means the C kind of string, i.e., bytes. In that case, 1, ByteString. That's right, String and Text don't count. |
| 2022-01-18 18:21:56 +0100 | <polyphem_> | whatif: https://gist.github.com/dino-/28b09c465c756c44b2c91d777408e166 |
| 2022-01-18 18:21:56 +0100 | <ksqsf> | string, text (strict + lazy), bytestring (strict + lazy) * (char8 + word8) |
| 2022-01-18 18:22:07 +0100 | <ksqsf> | only 7 you need to know ;) |
| 2022-01-18 18:22:30 +0100 | <whatif> | why the Lazy thing can't work on Internal thing? |
| 2022-01-18 18:22:36 +0100 | <whatif> | or the verse |
| 2022-01-18 18:22:52 +0100 | <ksqsf> | you're using a strict bytestring |
| 2022-01-18 18:23:31 +0100 | <ksqsf> | @hoogle fromStrict |
| 2022-01-18 18:23:31 +0100 | <lambdabot> | Data.ByteString.Lazy fromStrict :: ByteString -> ByteString |
| 2022-01-18 18:23:31 +0100 | <lambdabot> | Data.ByteString.Lazy.Char8 fromStrict :: ByteString -> ByteString |
| 2022-01-18 18:23:32 +0100 | <lambdabot> | Data.Text.Lazy fromStrict :: Text -> Text |
| 2022-01-18 18:24:12 +0100 | polyphem_ | polyphem |
| 2022-01-18 18:24:13 +0100 | <maerwald> | whatif: they're different data types |
| 2022-01-18 18:24:25 +0100 | <maerwald> | for performance reasons |
| 2022-01-18 18:24:49 +0100 | <maerwald> | so yes, it's a mess |
| 2022-01-18 18:24:50 +0100 | alx741 | (~alx741@157.100.93.160) |
| 2022-01-18 18:25:01 +0100 | <whatif> | how I turn a Internal.ByteString to a String? |
| 2022-01-18 18:25:13 +0100 | <whatif> | I need a FilePath |
| 2022-01-18 18:25:29 +0100 | <maerwald> | whatif: on what platform? |
| 2022-01-18 18:25:31 +0100 | <whatif> | scotty give me a Internal.ByteString |
| 2022-01-18 18:25:37 +0100 | <whatif> | maerwald scotty |
| 2022-01-18 18:25:43 +0100 | <whatif> | maerwald debian |
| 2022-01-18 18:25:45 +0100 | <monochrom> | Yeah, that's actually platform-dependent territory. |
| 2022-01-18 18:25:45 +0100 | <slack1256> | Is this correct syntax for setting SCC and get info at call sites? https://pastebin.com/AWiRncm5 |
| 2022-01-18 18:26:01 +0100 | <maerwald> | whatif: where did scotty obtain that filepath from? |
| 2022-01-18 18:26:21 +0100 | <whatif> | maerwald FileInfo |
| 2022-01-18 18:27:15 +0100 | <maerwald> | whatif: on unix, a filepath can have arbitrary encoding |
| 2022-01-18 18:27:32 +0100 | burnsidesLlama | (~burnsides@dhcp168-015.wadham.ox.ac.uk) |
| 2022-01-18 18:27:37 +0100 | <maerwald> | most people assume utf-8 |
| 2022-01-18 18:28:43 +0100 | tromp | (~textual@dhcp-077-249-230-040.chello.nl) |
| 2022-01-18 18:28:43 +0100 | alx741 | (~alx741@157.100.93.160) (Read error: Connection reset by peer) |
| 2022-01-18 18:29:44 +0100 | <whatif> | maerwald found it, Data.ByteString.Char8.unpack |
| 2022-01-18 18:29:51 +0100 | <maerwald> | whatif: that will truncate |
| 2022-01-18 18:31:38 +0100 | <monochrom> | It's only good for ASCII. |
| 2022-01-18 18:31:59 +0100 | <whatif> | what's the proper way, assume utf-8 |
| 2022-01-18 18:32:14 +0100 | <maerwald> | whatif: that depends where the filepath is from |
| 2022-01-18 18:32:30 +0100 | <whatif> | maerwald debian linux |
| 2022-01-18 18:32:37 +0100 | qeqeqw1 | (~qeqeqw3@2001:861:3a04:e320:31ea:a59b:1c06:51f4) |
| 2022-01-18 18:32:48 +0100 | <maerwald> | I mean... can you know what's the encoding... is it on your machine? Is it sent to you? |
| 2022-01-18 18:32:55 +0100 | <whatif> | utf-8 |
| 2022-01-18 18:33:00 +0100 | <monochrom> | A lot of people assume ASCII to head-in-sand so they don't have to answer those tough questions. |
| 2022-01-18 18:33:18 +0100 | <ksqsf> | https://paste.tomsmeding.com/ArEYKick if it's utf8, using 'text' is pretty easy |
| 2022-01-18 18:33:32 +0100 | <maerwald> | whatif: there's https://hackage.haskell.org/package/base-4.16.0.0/docs/GHC-IO-Encoding.html#v:getFileSystemEncoding |
| 2022-01-18 18:36:12 +0100 | <maerwald> | whatif: https://github.com/hasufell/abstract-filepath/blob/a913d715d8971224b45ef22a7b9ceaa263a77601/abstra… |
| 2022-01-18 18:36:24 +0100 | <maerwald> | that's an example of using current filesystem encoding to turn bytestring into String |
| 2022-01-18 18:37:13 +0100 | deadmarshal | (~deadmarsh@95.38.228.70) |
| 2022-01-18 18:38:09 +0100 | <sclv> | shane those things are usually called torsors? you can also just view it as an affine space i guess |
| 2022-01-18 18:39:06 +0100 | mbuf | (~Shakthi@136.185.86.67) (Quit: Leaving) |
| 2022-01-18 18:40:00 +0100 | hippoid | (~hippoid@184.105.6.88) |
| 2022-01-18 18:40:52 +0100 | <slack1256> | It seems that call-site SCC do not appear when reporting exceptions via +RTS -xc . Does somebody know how to track who threw an exceptions? |
| 2022-01-18 18:41:48 +0100 | Akiva | (~Akiva@user/Akiva) |
| 2022-01-18 18:42:36 +0100 | turlando | (~turlando@93-42-250-112.ip89.fastwebnet.it) |
| 2022-01-18 18:42:36 +0100 | turlando | (~turlando@93-42-250-112.ip89.fastwebnet.it) (Changing host) |
| 2022-01-18 18:42:36 +0100 | turlando | (~turlando@user/turlando) |
| 2022-01-18 18:43:52 +0100 | Hildegunst | (~luc@80.248.12.109.rev.sfr.net) |
| 2022-01-18 18:43:53 +0100 | CiaoSen | (~Jura@p200300c95737a2002a3a4dfffe84dbd5.dip0.t-ipconnect.de) |
| 2022-01-18 18:44:52 +0100 | alx741 | (~alx741@157.100.93.160) |
| 2022-01-18 18:46:28 +0100 | alx741 | (~alx741@157.100.93.160) (Read error: Connection reset by peer) |
| 2022-01-18 18:47:48 +0100 | <slack1256> | Nevermind, they seem to do. The exception was not thrown from where I excepted. |
| 2022-01-18 18:48:27 +0100 | Hildegunst | (~luc@80.248.12.109.rev.sfr.net) (Ping timeout: 268 seconds) |
| 2022-01-18 18:53:18 +0100 | ProfSimm | (~ProfSimm@176-12-60-137.pon.spectrumnet.bg) (Remote host closed the connection) |
| 2022-01-18 18:53:38 +0100 | ProfSimm | (~ProfSimm@176-12-60-137.pon.spectrumnet.bg) |
| 2022-01-18 18:53:51 +0100 | alp | (~alp@user/alp) |
| 2022-01-18 18:53:58 +0100 | <shane> | sclv: I figured it out eventually, but I appreciate you getting back to me! |
| 2022-01-18 18:56:28 +0100 | ksqsf | (~user@134.209.106.31) (Ping timeout: 268 seconds) |
| 2022-01-18 18:57:48 +0100 | whatif | (~user@123.123.223.41) (Quit: ERC (IRC client for Emacs 26.3)) |
| 2022-01-18 18:58:19 +0100 | ProfSimm | (~ProfSimm@176-12-60-137.pon.spectrumnet.bg) (Ping timeout: 256 seconds) |
| 2022-01-18 19:01:32 +0100 | coot | (~coot@89-64-85-93.dynamic.chello.pl) |
| 2022-01-18 19:02:51 +0100 | alx741 | (~alx741@157.100.93.160) |
| 2022-01-18 19:03:13 +0100 | yauhsien | (~yauhsien@61-231-62-246.dynamic-ip.hinet.net) |
| 2022-01-18 19:03:26 +0100 | kritzefitz | (~kritzefit@debian/kritzefitz) |
| 2022-01-18 19:05:02 +0100 | jkaye | (~jkaye@2601:281:200:1958:8e74:ef22:c471:c2e) (Ping timeout: 240 seconds) |
| 2022-01-18 19:05:46 +0100 | tromp | (~textual@dhcp-077-249-230-040.chello.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2022-01-18 19:05:56 +0100 | xb0o2 | (~xb0o2@user/xb0o2) |
| 2022-01-18 19:06:18 +0100 | alx741 | (~alx741@157.100.93.160) (Read error: Connection reset by peer) |
| 2022-01-18 19:08:14 +0100 | fef | (~thedawn@user/thedawn) |
| 2022-01-18 19:11:25 +0100 | <zzz> | why should we avoid GADTs if we don't need them? |
| 2022-01-18 19:13:59 +0100 | <geekosaur> | did something tell you that? |
| 2022-01-18 19:14:25 +0100 | <geekosaur> | I mean, there are those who prefer GADT syntax even for non-GADTs |
| 2022-01-18 19:14:33 +0100 | <slack1256> | Anybody has used the `mold` linker with ghc? |
| 2022-01-18 19:14:38 +0100 | <geekosaur> | (and GADTSyntax is a language option) |
| 2022-01-18 19:14:52 +0100 | <geekosaur> | slack1256, it's been tried in #ghc, ask there but they had problems with it |
| 2022-01-18 19:16:15 +0100 | coot | (~coot@89-64-85-93.dynamic.chello.pl) (Quit: coot) |
| 2022-01-18 19:16:55 +0100 | whatsupdoc | (uid509081@id-509081.hampstead.irccloud.com) |
| 2022-01-18 19:17:54 +0100 | Pickchea | (~private@user/pickchea) (Quit: Leaving) |
| 2022-01-18 19:19:47 +0100 | perrierjouet | (~perrier-j@modemcable012.251-130-66.mc.videotron.ca) (Quit: WeeChat 3.4) |
| 2022-01-18 19:20:01 +0100 | ksqsf | (~user@134.209.106.31) |
| 2022-01-18 19:20:37 +0100 | <geekosaur> | zzz, beyond that, there are those who believe existentials (the main purpose of GADTs) are often an anti-pattern. |
| 2022-01-18 19:20:59 +0100 | gdd | (~gdd@129.199.146.230) (Ping timeout: 256 seconds) |
| 2022-01-18 19:21:28 +0100 | <geekosaur> | you should probably read the arguments in both directions and make your own decision; the fact that they are still around and used suggests it's not a clear-cut "this is bad" |
| 2022-01-18 19:21:31 +0100 | yauhsien | (~yauhsien@61-231-62-246.dynamic-ip.hinet.net) (Remote host closed the connection) |
| 2022-01-18 19:21:42 +0100 | kspalaiologos | (~kspalaiol@user/kspalaiologos) |
| 2022-01-18 19:22:31 +0100 | perrierjouet | (~perrier-j@modemcable012.251-130-66.mc.videotron.ca) |
| 2022-01-18 19:22:52 +0100 | alx741 | (~alx741@157.100.93.160) |
| 2022-01-18 19:23:00 +0100 | ub | (~Thunderbi@141.98.252.232) |
| 2022-01-18 19:23:12 +0100 | <zzz> | oh i remember someone saying we should avoid it but never understood why. thanks |
| 2022-01-18 19:23:15 +0100 | ubert | (~Thunderbi@141.98.252.232) (Ping timeout: 256 seconds) |
| 2022-01-18 19:23:15 +0100 | ub | ubert |
| 2022-01-18 19:23:24 +0100 | <EvanR> | GADTs are awesome |
| 2022-01-18 19:23:29 +0100 | <EvanR> | totally rad, even |
| 2022-01-18 19:24:32 +0100 | ksqsf | (~user@134.209.106.31) (Ping timeout: 240 seconds) |
| 2022-01-18 19:24:42 +0100 | tromp | (~textual@dhcp-077-249-230-040.chello.nl) |
| 2022-01-18 19:27:52 +0100 | hippoid | (~hippoid@184.105.6.88) () |
| 2022-01-18 19:27:56 +0100 | kspalaiologos | (~kspalaiol@user/kspalaiologos) (Quit: Leaving) |
| 2022-01-18 19:28:43 +0100 | ksqsf | (~user@134.209.106.31) |
| 2022-01-18 19:30:23 +0100 | <zzz> | agree |
| 2022-01-18 19:30:54 +0100 | <zzz> | i even prefer GADT syntax for non-GADTs |
| 2022-01-18 19:31:06 +0100 | yauhsien | (~yauhsien@61-231-62-246.dynamic-ip.hinet.net) |
| 2022-01-18 19:31:06 +0100 | alx741 | (~alx741@157.100.93.160) (Read error: Connection reset by peer) |
| 2022-01-18 19:32:31 +0100 | <zzz> | and we can now use it in newtype decls, nice |
| 2022-01-18 19:34:05 +0100 | ksqsf | (~user@134.209.106.31) (Ping timeout: 268 seconds) |
| 2022-01-18 19:35:20 +0100 | <EvanR> | really |
| 2022-01-18 19:35:32 +0100 | yauhsien | (~yauhsien@61-231-62-246.dynamic-ip.hinet.net) (Ping timeout: 240 seconds) |
| 2022-01-18 19:35:33 +0100 | <EvanR> | does that mean you can have existential newtype |
| 2022-01-18 19:36:47 +0100 | ksqsf | (~user@134.209.106.31) |
| 2022-01-18 19:38:32 +0100 | troydm | (~troydm@host-176-37-124-197.b025.la.net.ua) (Ping timeout: 240 seconds) |
| 2022-01-18 19:39:16 +0100 | eggplantade | (~Eggplanta@2600:1700:bef1:5e10:81c9:f67f:1443:f972) (Remote host closed the connection) |
| 2022-01-18 19:40:56 +0100 | gentauro | (~gentauro@user/gentauro) (Quit: leaving) |
| 2022-01-18 19:40:57 +0100 | wombat875 | (~neilfulwi@pool-72-89-24-154.nycmny.fios.verizon.net) |
| 2022-01-18 19:41:11 +0100 | gentauro | (~gentauro@user/gentauro) |
| 2022-01-18 19:41:26 +0100 | gentauro | (~gentauro@user/gentauro) (Client Quit) |
| 2022-01-18 19:42:36 +0100 | gentauro | (~gentauro@user/gentauro) |
| 2022-01-18 19:45:08 +0100 | tromp | (~textual@dhcp-077-249-230-040.chello.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2022-01-18 19:45:24 +0100 | ksqsf | (~user@134.209.106.31) (Remote host closed the connection) |
| 2022-01-18 19:45:45 +0100 | ksqsf | (~user@134.209.106.31) |
| 2022-01-18 19:47:44 +0100 | <geekosaur> | existential newtype seems unlikely since it'd have at least two fields (the value and its dictionary)? |
| 2022-01-18 19:47:54 +0100 | alx741 | (~alx741@157.100.93.160) |
| 2022-01-18 19:48:16 +0100 | <EvanR> | that assumes you put a constraint |
| 2022-01-18 19:48:34 +0100 | <EvanR> | which I guess is often implied by using existential types |
| 2022-01-18 19:48:53 +0100 | <EvanR> | and I guess that is the anti-pattern you were talking about |
| 2022-01-18 19:48:59 +0100 | <geekosaur> | they're kinda useless without? |
| 2022-01-18 19:49:45 +0100 | <geekosaur> | "great, I have a value but no clue what I can do with it" |
| 2022-01-18 19:50:19 +0100 | <EvanR> | in tricky code where internally you have external information on how to unwrap the unknown value, and you just want something like old GHC.Any |
| 2022-01-18 19:50:30 +0100 | <EvanR> | and you don't want an extra wrapper |
| 2022-01-18 19:50:37 +0100 | ksqsf | (~user@134.209.106.31) (Ping timeout: 256 seconds) |
| 2022-01-18 19:50:47 +0100 | <EvanR> | er, internally, you have tricky extra information |
| 2022-01-18 19:50:47 +0100 | <awpr> | contrived as this is, it demonstrates why that's not completely true: `data Thing where Thing :: Dict (Show a) -> a -> Thing` |
| 2022-01-18 19:51:14 +0100 | alx741 | (~alx741@157.100.93.160) (Read error: Connection reset by peer) |
| 2022-01-18 19:51:22 +0100 | <EvanR> | yes geekosaur is probably thinking, either a constraint or a paired thing that uses a |
| 2022-01-18 19:51:57 +0100 | ProfSimm | (~ProfSimm@87.227.196.109) |
| 2022-01-18 19:52:05 +0100 | merijn | (~merijn@c-001-001-018.client.esciencecenter.eduvpn.nl) |
| 2022-01-18 19:52:27 +0100 | <awpr> | yeah, you can obtain "things to do with" the existentials by their relation to other fields, like `data Generator a where Generator :: b -> (b -> (a, b)) -> Generator a` |
| 2022-01-18 19:52:33 +0100 | tromp | (~textual@dhcp-077-249-230-040.chello.nl) |
| 2022-01-18 19:52:52 +0100 | <EvanR> | which is besides the point of newtypes, which have only 1 field |
| 2022-01-18 19:53:08 +0100 | jinsun__ | jinsun |
| 2022-01-18 19:53:20 +0100 | geekosaur | (~geekosaur@xmonad/geekosaur) (Remote host closed the connection) |
| 2022-01-18 19:53:46 +0100 | <awpr> | could have a newtype over a tuple, or a newtype over any type that mentions the existential twice |
| 2022-01-18 19:54:32 +0100 | <EvanR> | if they wrapped type has fields, then it could have used its own existential |
| 2022-01-18 19:54:36 +0100 | <monochrom> | geekosaur: As the user's guide says, as you observed, a useful existential type is not going to be a semantic newtype; a syntactic newtype (that the compiler secretly s/newtype/data/ under the hood) is no problem but the GHC devs are too lazy to do it until they hear enough requests. |
| 2022-01-18 19:55:07 +0100 | geekosaur | (~geekosaur@xmonad/geekosaur) |
| 2022-01-18 19:55:25 +0100 | <maerwald> | awpr: you don't need GADT syntax for that though |
| 2022-01-18 19:55:25 +0100 | <awpr> | but even without other fields, you can get interesting things: `data Colimit f where Colimit :: f a -> Colimit f`, s.t. `Colimit (Int,)` is isomorphic to `Int` |
| 2022-01-18 19:56:09 +0100 | <EvanR> | ok so that looks like a good time for a newtype |
| 2022-01-18 19:56:18 +0100 | <EvanR> | but it's illegal |
| 2022-01-18 19:56:36 +0100 | <maerwald> | that just makes it more exciting |
| 2022-01-18 19:57:19 +0100 | <awpr> | maerwald: hmm? you mean the Generator example being expressible with just ExistentialTypes? needing GADT syntax wasn't the point, it was doing something useful with unconstrained existentials |
| 2022-01-18 19:57:58 +0100 | <monochrom> | I had to decode the GADT syntax to recognize the existential type... |
| 2022-01-18 19:58:47 +0100 | <maerwald> | awpr: ExistentialQuantification |
| 2022-01-18 19:58:51 +0100 | <monochrom> | I recognize that there is now a school of thought of using only GADT syntax to write existential types. |
| 2022-01-18 20:00:12 +0100 | <EvanR> | it seems like since you can use GADT to write newtypes, there's gotta be special case there to see if you used existentials and tell you no xD |
| 2022-01-18 20:00:26 +0100 | <EvanR> | why not just make it work |
| 2022-01-18 20:03:03 +0100 | val-host | (~val-host@2a02:2f0f:9108:b00:6891:37fc:a7bd:3738) |
| 2022-01-18 20:03:23 +0100 | Erutuon | (~Erutuon@user/erutuon) |
| 2022-01-18 20:03:40 +0100 | ksqsf | (~user@134.209.106.31) |
| 2022-01-18 20:05:09 +0100 | <awpr> | oh right, I forgot the name since I never end up enabling it explicitly |
| 2022-01-18 20:06:12 +0100 | val-host | (~val-host@2a02:2f0f:9108:b00:6891:37fc:a7bd:3738) (Client Quit) |
| 2022-01-18 20:06:32 +0100 | deadmarshal | (~deadmarsh@95.38.228.70) (Ping timeout: 240 seconds) |
| 2022-01-18 20:07:39 +0100 | tromp | (~textual@dhcp-077-249-230-040.chello.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2022-01-18 20:07:55 +0100 | alx741 | (~alx741@157.100.93.160) |
| 2022-01-18 20:08:35 +0100 | ksqsf | (~user@134.209.106.31) (Ping timeout: 256 seconds) |
| 2022-01-18 20:10:35 +0100 | alx741 | (~alx741@157.100.93.160) (Read error: Connection reset by peer) |
| 2022-01-18 20:12:47 +0100 | zwro[m] | (~zwromatri@2001:470:69fc:105::1d4) |
| 2022-01-18 20:15:24 +0100 | michalz | (~michalz@185.246.204.122) (Ping timeout: 268 seconds) |
| 2022-01-18 20:17:03 +0100 | dhouthoo | (~dhouthoo@178-117-36-167.access.telenet.be) (Quit: WeeChat 3.4) |
| 2022-01-18 20:18:54 +0100 | tromp | (~textual@dhcp-077-249-230-040.chello.nl) |
| 2022-01-18 20:21:03 +0100 | merijn | (~merijn@c-001-001-018.client.esciencecenter.eduvpn.nl) (Ping timeout: 256 seconds) |
| 2022-01-18 20:21:26 +0100 | ksqsf | (~user@134.209.106.31) |
| 2022-01-18 20:22:45 +0100 | DNH | (~DNH@2a02:8108:1100:16d8:edf9:3833:cff9:92b3) (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 2022-01-18 20:26:30 +0100 | ksqsf | (~user@134.209.106.31) (Ping timeout: 268 seconds) |
| 2022-01-18 20:28:52 +0100 | alx741 | (~alx741@157.100.93.160) |
| 2022-01-18 20:29:49 +0100 | tromp | (~textual@dhcp-077-249-230-040.chello.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2022-01-18 20:32:58 +0100 | alx741 | (~alx741@157.100.93.160) (Read error: Connection reset by peer) |
| 2022-01-18 20:33:26 +0100 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) (Killed (NickServ (Forcing logout FinnElija -> finn_elija))) |
| 2022-01-18 20:33:26 +0100 | finn_elija | (~finn_elij@user/finn-elija/x-0085643) |
| 2022-01-18 20:33:26 +0100 | finn_elija | FinnElija |
| 2022-01-18 20:34:21 +0100 | tromp | (~textual@dhcp-077-249-230-040.chello.nl) |
| 2022-01-18 20:36:32 +0100 | troydm | (~troydm@host-176-37-124-197.b025.la.net.ua) |
| 2022-01-18 20:37:39 +0100 | ksqsf | (~user@134.209.106.31) |
| 2022-01-18 20:39:05 +0100 | DNH | (~DNH@2a02:8108:1100:16d8:edf9:3833:cff9:92b3) |
| 2022-01-18 20:39:40 +0100 | eggplantade | (~Eggplanta@2600:1700:bef1:5e10:81c9:f67f:1443:f972) |
| 2022-01-18 20:39:59 +0100 | fef | (~thedawn@user/thedawn) (Quit: Leaving) |
| 2022-01-18 20:40:30 +0100 | <EvanR> | are instances based on Generics inherently less efficient than handcoded ones for a given type |
| 2022-01-18 20:40:33 +0100 | eron | (~eron@2804:431:c7c2:3848:71e8:6fbf:96e2:3117) |
| 2022-01-18 20:40:45 +0100 | <EvanR> | or is there some GHC magic |
| 2022-01-18 20:41:01 +0100 | <awpr> | not inherently less efficient, but sometimes they are |
| 2022-01-18 20:41:41 +0100 | <awpr> | the hope is that GHC will be able to inline from/to, do some optimization, and annihilate them against each other so that the result is the same as if it never went through generics |
| 2022-01-18 20:41:55 +0100 | <EvanR> | oh, nice |
| 2022-01-18 20:41:59 +0100 | <monochrom> | GHC does not have magic. However, efficiency depends on the actual class and methods. |
| 2022-01-18 20:42:03 +0100 | <[exa]> | there are "pretty good chances" that it inlines to a form that is more less equivalent to what you'd get by writing the instances by hand |
| 2022-01-18 20:42:22 +0100 | eggplantade | (~Eggplanta@2600:1700:bef1:5e10:81c9:f67f:1443:f972) (Remote host closed the connection) |
| 2022-01-18 20:42:28 +0100 | <awpr> | but if the particular instance has something that prevents that from working, or if the type is big enough that GHC doesn't want to inline it, then it's likely to become a disaster |
| 2022-01-18 20:42:32 +0100 | ksqsf | (~user@134.209.106.31) (Ping timeout: 268 seconds) |
| 2022-01-18 20:42:32 +0100 | eggplantade | (~Eggplanta@2600:1700:bef1:5e10:81c9:f67f:1443:f972) |
| 2022-01-18 20:42:53 +0100 | <monochrom> | I don't see myself handwriting a more efficient Show than the usual Generics solution, for example. |
| 2022-01-18 20:43:02 +0100 | ksqsf | (~user@134.209.106.31) |
| 2022-01-18 20:43:09 +0100 | <monochrom> | It's the same structural recursion. |
| 2022-01-18 20:43:26 +0100 | <awpr> | (disaster: ) because actually executing to/from at runtime involves allocating/scrutinizing a _ton_ of data constructors |
| 2022-01-18 20:43:28 +0100 | <EvanR> | yes but this business of first converting to a generic rep, then coming back |
| 2022-01-18 20:43:39 +0100 | <EvanR> | at each element of the structure |
| 2022-01-18 20:43:58 +0100 | bliminse | (~bliminse@host86-188-36-178.range86-188.btcentralplus.com) (Quit: leaving) |
| 2022-01-18 20:43:58 +0100 | <EvanR> | e.g. if it's a 4 field record, it'll become a (a :*: b) :*: (c :*: d) |
| 2022-01-18 20:44:04 +0100 | <monochrom> | Ah, OK yeah. |
| 2022-01-18 20:44:36 +0100 | Hildegunst | (~luc@80.248.12.109.rev.sfr.net) |
| 2022-01-18 20:44:36 +0100 | <awpr> | `case (case x of Left a -> L1 a; Right b -> R1 b) of L1 a -> showString "Left" ... ; R1 b -> showString "Right" ...` |
| 2022-01-18 20:45:13 +0100 | <awpr> | this can be optimized easily enough to `case x of Left a -> showString "Left" ... ; Right b -> showString "Right" ...` |
| 2022-01-18 20:45:13 +0100 | Hildegun1t | (~luc@80.248.12.109.rev.sfr.net) |
| 2022-01-18 20:45:38 +0100 | <monochrom> | Damn, the world is more magical than I thought. |
| 2022-01-18 20:45:42 +0100 | Hildegun1t | (~luc@80.248.12.109.rev.sfr.net) (Client Quit) |
| 2022-01-18 20:46:00 +0100 | <EvanR> | so from-tos can be fused? |
| 2022-01-18 20:46:23 +0100 | <awpr> | effectively yeah, in good cases they get inlined and eventually vanish |
| 2022-01-18 20:46:29 +0100 | <EvanR> | that is amazing |
| 2022-01-18 20:47:32 +0100 | ksqsf | (~user@134.209.106.31) (Ping timeout: 240 seconds) |
| 2022-01-18 20:48:14 +0100 | perrierjouet | (~perrier-j@modemcable012.251-130-66.mc.videotron.ca) (Quit: WeeChat 3.4) |
| 2022-01-18 20:48:21 +0100 | <awpr> | unfortunately it's a bit brittle in that there's some cutoff point where GHC stops thinking it's worth it to inline from/to, compile times skyrocket, runtime performance gets slow, and there's not really anything you can do about it as a library author |
| 2022-01-18 20:48:30 +0100 | perrierjouet | (~perrier-j@modemcable012.251-130-66.mc.videotron.ca) |
| 2022-01-18 20:49:02 +0100 | Hildegunst | (~luc@80.248.12.109.rev.sfr.net) (Ping timeout: 240 seconds) |
| 2022-01-18 20:49:02 +0100 | <awpr> | cutoff point in terms of the size (number of constructors/fields) of the type whose Generic instance is being used |
| 2022-01-18 20:49:09 +0100 | <EvanR> | as a user though, you can write an offending instance by hand |
| 2022-01-18 20:49:31 +0100 | <awpr> | yeah, that's true |
| 2022-01-18 20:49:31 +0100 | <EvanR> | and remove deriving Generic |
| 2022-01-18 20:49:48 +0100 | alx741 | (~alx741@157.100.93.160) |
| 2022-01-18 20:50:05 +0100 | <awpr> | but then you have to notice that's happening, which is rarely obvious unless you're already looking at Core |
| 2022-01-18 20:50:09 +0100 | eron | (~eron@2804:431:c7c2:3848:71e8:6fbf:96e2:3117) (Quit: Client closed) |
| 2022-01-18 20:50:21 +0100 | <EvanR> | if no one notices it's slow, then it's fast! |
| 2022-01-18 20:51:02 +0100 | Midjak | (~Midjak@may53-1-78-226-116-92.fbx.proxad.net) (Ping timeout: 240 seconds) |
| 2022-01-18 20:51:17 +0100 | <awpr> | alternatively if no one notices your Generic instance is slow due to inlining failure, then it's an ambient performance tax that just gets lumped into a vague cultural belief that Haskell is slow |
| 2022-01-18 20:52:20 +0100 | <monochrom> | This is why I look at Core all the time. |
| 2022-01-18 20:52:57 +0100 | <monochrom> | My ratio of looking at Core to looking at profiling graphs is 99:1. |
| 2022-01-18 20:52:58 +0100 | alx741 | (~alx741@157.100.93.160) (Read error: Connection reset by peer) |
| 2022-01-18 20:54:00 +0100 | <EvanR> | I don't even see Core anymore, just blonde, brunette, redhead |
| 2022-01-18 20:54:37 +0100 | <EvanR> | (a reference to this really old movie The Matrix) |
| 2022-01-18 20:54:58 +0100 | <Rembane> | EvanR: Good reference. Good movie. |
| 2022-01-18 20:55:11 +0100 | <sm> | truthfully ? that's interesting then |
| 2022-01-18 20:55:27 +0100 | <sm> | (monochrom) |
| 2022-01-18 20:55:49 +0100 | <awpr> | profiling graph is just a hint about what Core to look at :) |
| 2022-01-18 20:56:06 +0100 | <EvanR> | getting a core output and looking at it seems somewhat more ergonomic than profiling graph |
| 2022-01-18 20:56:21 +0100 | mjs2600 | (~mjs2600@c-24-91-3-49.hsd1.vt.comcast.net) (Ping timeout: 256 seconds) |
| 2022-01-18 20:56:23 +0100 | <EvanR> | since it's text |
| 2022-01-18 20:56:24 +0100 | sm | resolves to read more core in 2022 |
| 2022-01-18 20:57:38 +0100 | <sm> | but which reveals relevant insights more l efficiently |
| 2022-01-18 20:58:06 +0100 | bliminse | (~bliminse@host86-188-36-178.range86-188.btcentralplus.com) |
| 2022-01-18 20:58:26 +0100 | sm | doesn't get as far as charts, but does read textual profile output from time to time |
| 2022-01-18 20:58:45 +0100 | geekosaur | (~geekosaur@xmonad/geekosaur) (Remote host closed the connection) |
| 2022-01-18 20:59:21 +0100 | <monochrom> | I am an extreme. But awpr is at the truth in the middle. A profiling graph can only tell you where to dig. It still doesn't dig for you. |
| 2022-01-18 21:00:29 +0100 | geekosaur | (~geekosaur@xmonad/geekosaur) |
| 2022-01-18 21:01:31 +0100 | <sm> | gtoolkit.com advocates "moldable development": casually whipping up just the custom tools and visualizations you need at any point. I want this |
| 2022-01-18 21:02:39 +0100 | ubert | (~Thunderbi@141.98.252.232) (Quit: ubert) |
| 2022-01-18 21:05:25 +0100 | juhp | (~juhp@128.106.188.82) (Ping timeout: 256 seconds) |
| 2022-01-18 21:05:52 +0100 | <EvanR> | that's some ironman sh*t |
| 2022-01-18 21:06:04 +0100 | <EvanR> | jarvis, show me something |
| 2022-01-18 21:06:28 +0100 | <sm> | :) |
| 2022-01-18 21:06:41 +0100 | <monochrom> | "I'm going to send you to the MIT student lab" |
| 2022-01-18 21:06:45 +0100 | juhp | (~juhp@128.106.188.82) |
| 2022-01-18 21:08:07 +0100 | <sm> | could be a point of contact between the smalltalk and haskell worlds. (needs a haskell parser added) |
| 2022-01-18 21:08:16 +0100 | gehmehgeh | (~user@user/gehmehgeh) (Remote host closed the connection) |
| 2022-01-18 21:09:00 +0100 | gehmehgeh | (~user@user/gehmehgeh) |
| 2022-01-18 21:11:15 +0100 | ec | (~ec@gateway/tor-sasl/ec) (Ping timeout: 276 seconds) |
| 2022-01-18 21:13:00 +0100 | ec | (~ec@gateway/tor-sasl/ec) |
| 2022-01-18 21:17:53 +0100 | geranim0 | (~geranim0@modemcable242.171-178-173.mc.videotron.ca) (Ping timeout: 256 seconds) |
| 2022-01-18 21:18:51 +0100 | xkuru | (~xkuru@user/xkuru) |
| 2022-01-18 21:19:17 +0100 | lavaman | (~lavaman@98.38.249.169) |
| 2022-01-18 21:21:09 +0100 | [itchyjunk] | (~itchyjunk@user/itchyjunk/x-7353470) (Remote host closed the connection) |
| 2022-01-18 21:21:32 +0100 | [itchyjunk] | (~itchyjunk@user/itchyjunk/x-7353470) |
| 2022-01-18 21:23:51 +0100 | lavaman | (~lavaman@98.38.249.169) (Ping timeout: 268 seconds) |
| 2022-01-18 21:24:47 +0100 | ProfSimm | (~ProfSimm@87.227.196.109) (Remote host closed the connection) |
| 2022-01-18 21:25:06 +0100 | ProfSimm | (~ProfSimm@87.227.196.109) |
| 2022-01-18 21:25:42 +0100 | mjs2600 | (~mjs2600@c-24-91-3-49.hsd1.vt.comcast.net) |
| 2022-01-18 21:25:49 +0100 | travv0 | (sid293381@user/travv0) |
| 2022-01-18 21:31:02 +0100 | Tuplanolla | (~Tuplanoll@91-159-68-166.elisa-laajakaista.fi) |
| 2022-01-18 21:32:15 +0100 | ksqsf | (~user@134.209.106.31) |
| 2022-01-18 21:33:11 +0100 | kmein | (~weechat@user/kmein) (Quit: ciao kakao) |
| 2022-01-18 21:33:31 +0100 | kmein | (~weechat@user/kmein) |
| 2022-01-18 21:37:02 +0100 | ksqsf | (~user@134.209.106.31) (Ping timeout: 240 seconds) |
| 2022-01-18 21:39:23 +0100 | ubert | (~Thunderbi@p200300ecdf09949e91b35a252eb85141.dip0.t-ipconnect.de) |
| 2022-01-18 21:39:26 +0100 | ubert | (~Thunderbi@p200300ecdf09949e91b35a252eb85141.dip0.t-ipconnect.de) (Client Quit) |
| 2022-01-18 21:41:02 +0100 | qeqeqw1 | (~qeqeqw3@2001:861:3a04:e320:31ea:a59b:1c06:51f4) (Ping timeout: 240 seconds) |
| 2022-01-18 21:41:19 +0100 | jkaye | (~jkaye@2601:281:200:1958:2b64:9a7d:6899:8349) |
| 2022-01-18 21:41:29 +0100 | pfurla | (~pfurla@2804:d41:4331:4800:31ef:1aaf:1e7:47d) |
| 2022-01-18 21:46:58 +0100 | tromp | (~textual@dhcp-077-249-230-040.chello.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2022-01-18 21:48:15 +0100 | kuribas | (~user@ptr-25vy0ia11vvy5vw4h88.18120a2.ip6.access.telenet.be) (Quit: ERC (IRC client for Emacs 26.3)) |
| 2022-01-18 21:49:13 +0100 | hololeap_ | (~hololeap@user/hololeap) |
| 2022-01-18 21:49:14 +0100 | kojo5551 | (~kojo5551@fep.grid.pub.ro) (Remote host closed the connection) |
| 2022-01-18 21:49:18 +0100 | Midjak | (~Midjak@may53-1-78-226-116-92.fbx.proxad.net) |
| 2022-01-18 21:50:49 +0100 | val-host | (~val-host@2a02:2f0f:9108:b00:6891:37fc:a7bd:3738) |
| 2022-01-18 21:50:59 +0100 | notzmv | (~zmv@user/notzmv) (Ping timeout: 268 seconds) |
| 2022-01-18 21:51:35 +0100 | kojo5551 | (~kojo5551@fep.grid.pub.ro) |
| 2022-01-18 21:52:12 +0100 | hololeap | (~hololeap@user/hololeap) (Ping timeout: 276 seconds) |
| 2022-01-18 21:52:31 +0100 | val-host | (~val-host@2a02:2f0f:9108:b00:6891:37fc:a7bd:3738) (Client Quit) |
| 2022-01-18 21:55:28 +0100 | slac52114 | (~slack1256@191.125.99.76) |
| 2022-01-18 21:57:09 +0100 | dut | (~dut@user/dut) (Quit: Leaving) |
| 2022-01-18 21:57:32 +0100 | slack1256 | (~slack1256@186.11.99.46) (Ping timeout: 240 seconds) |
| 2022-01-18 22:00:13 +0100 | mikoto-chan | (~mikoto-ch@213.177.151.239) (Ping timeout: 256 seconds) |
| 2022-01-18 22:01:36 +0100 | ubert | (~Thunderbi@p200300ecdf09949e91b35a252eb85141.dip0.t-ipconnect.de) |
| 2022-01-18 22:02:15 +0100 | mikoto-chan | (~mikoto-ch@213.177.151.239) |
| 2022-01-18 22:03:03 +0100 | pavonia | (~user@user/siracusa) |
| 2022-01-18 22:03:10 +0100 | vysn | (~vysn@user/vysn) (Ping timeout: 250 seconds) |
| 2022-01-18 22:10:32 +0100 | mikoto-chan | (~mikoto-ch@213.177.151.239) (Ping timeout: 240 seconds) |
| 2022-01-18 22:10:38 +0100 | ec | (~ec@gateway/tor-sasl/ec) (Remote host closed the connection) |
| 2022-01-18 22:11:10 +0100 | ec | (~ec@gateway/tor-sasl/ec) |
| 2022-01-18 22:12:08 +0100 | slack1256 | (~slack1256@186.11.27.197) |
| 2022-01-18 22:14:10 +0100 | Pickchea | (~private@user/pickchea) |
| 2022-01-18 22:14:33 +0100 | slac52114 | (~slack1256@191.125.99.76) (Ping timeout: 256 seconds) |
| 2022-01-18 22:16:34 +0100 | _ht | (~quassel@2a02:a468:b619:1:c1f2:a735:3541:23f8) (Remote host closed the connection) |
| 2022-01-18 22:18:01 +0100 | merijn | (~merijn@c-001-001-018.client.esciencecenter.eduvpn.nl) |
| 2022-01-18 22:23:19 +0100 | tromp | (~textual@dhcp-077-249-230-040.chello.nl) |
| 2022-01-18 22:25:21 +0100 | wyrd | (~wyrd@gateway/tor-sasl/wyrd) (Ping timeout: 276 seconds) |
| 2022-01-18 22:26:26 +0100 | ksqsf | (~user@134.209.106.31) |
| 2022-01-18 22:31:41 +0100 | ksqsf | (~user@134.209.106.31) (Ping timeout: 268 seconds) |
| 2022-01-18 22:32:05 +0100 | mc47 | (~mc47@xmonad/TheMC47) (Remote host closed the connection) |
| 2022-01-18 22:33:24 +0100 | dut | (~dut@user/dut) |
| 2022-01-18 22:36:43 +0100 | gehmehgeh | (~user@user/gehmehgeh) (Quit: Leaving) |
| 2022-01-18 22:37:57 +0100 | jgeerds | (~jgeerds@55d4090e.access.ecotel.net) |
| 2022-01-18 22:41:03 +0100 | xlei_ | (~akans@pool-71-125-19-142.nycmny.fios.verizon.net) (Quit: ZNC 1.9.x-git-167-81df4dec - https://znc.in) |
| 2022-01-18 22:43:48 +0100 | Zugul | (~Zugul@52.173.255.131) |
| 2022-01-18 22:43:55 +0100 | MajorBiscuit | (~MajorBisc@2a02:a461:129d:1:6d4c:38a4:18b7:4b48) |
| 2022-01-18 22:44:10 +0100 | <Zugul> | !help |
| 2022-01-18 22:44:24 +0100 | <Zugul> | ?? |
| 2022-01-18 22:52:21 +0100 | merijn | (~merijn@c-001-001-018.client.esciencecenter.eduvpn.nl) (Ping timeout: 256 seconds) |
| 2022-01-18 22:52:51 +0100 | <geekosaur> | yes? |
| 2022-01-18 22:54:04 +0100 | <monochrom> | We have not bots here. |
| 2022-01-18 22:54:15 +0100 | <monochrom> | err I can't type. We have no bots here. |
| 2022-01-18 22:54:32 +0100 | jle` | (~jle`@cpe-23-240-75-236.socal.res.rr.com) (Ping timeout: 240 seconds) |
| 2022-01-18 22:55:05 +0100 | sm | whispers /msg lambdabot @help |
| 2022-01-18 22:56:29 +0100 | jle` | (~jle`@cpe-23-240-75-236.socal.res.rr.com) |
| 2022-01-18 22:57:17 +0100 | <monochrom> | Ugh I just rediscovered that "@quote monochrom monad" is full of past wisdom I forgot. :) |
| 2022-01-18 22:58:14 +0100 | geekosaur | sends monochrom a burrito |
| 2022-01-18 23:02:43 +0100 | MajorBiscuit | (~MajorBisc@2a02:a461:129d:1:6d4c:38a4:18b7:4b48) (Quit: WeeChat 3.3) |
| 2022-01-18 23:05:11 +0100 | <monochrom> | I had a quote that's way more general than burrito! |
| 2022-01-18 23:05:18 +0100 | <monochrom> | @quote monochrom monad.*dinner |
| 2022-01-18 23:05:18 +0100 | <lambdabot> | monochrom says: We the haskell community should henceforth use "what is a monad" as our secret code for "dinner time!" |
| 2022-01-18 23:06:22 +0100 | <Rembane> | That's a very good quote. |
| 2022-01-18 23:06:28 +0100 | <monochrom> | :) |
| 2022-01-18 23:07:17 +0100 | <wombat875> | kl |
| 2022-01-18 23:07:25 +0100 | wombat875 | (~neilfulwi@pool-72-89-24-154.nycmny.fios.verizon.net) (Quit: WeeChat 2.2-dev) |
| 2022-01-18 23:07:44 +0100 | wombat875 | (~neilfulwi@pool-72-89-24-154.nycmny.fios.verizon.net) |
| 2022-01-18 23:08:06 +0100 | <wombat875> | lol sorry still trying to figure out weechat shortcuts |
| 2022-01-18 23:10:00 +0100 | Vajb | (~Vajb@hag-jnsbng11-58c3a8-176.dhcp.inet.fi) (Read error: Connection reset by peer) |
| 2022-01-18 23:11:15 +0100 | Vajb | (~Vajb@hag-jnsbng11-58c3a8-176.dhcp.inet.fi) |
| 2022-01-18 23:12:08 +0100 | fendor | (~fendor@178.115.55.2.wireless.dyn.drei.com) (Remote host closed the connection) |
| 2022-01-18 23:13:37 +0100 | ystael | (~ystael@user/ystael) (Ping timeout: 268 seconds) |
| 2022-01-18 23:14:02 +0100 | wombat875 | (~neilfulwi@pool-72-89-24-154.nycmny.fios.verizon.net) (Ping timeout: 240 seconds) |
| 2022-01-18 23:15:00 +0100 | wombat875 | (~neilfulwi@pool-72-89-24-154.nycmny.fios.verizon.net) |
| 2022-01-18 23:15:01 +0100 | ystael | (~ystael@user/ystael) |
| 2022-01-18 23:17:17 +0100 | ystael | (~ystael@user/ystael) (Read error: Connection reset by peer) |
| 2022-01-18 23:17:28 +0100 | ystael | (~ystael@user/ystael) |
| 2022-01-18 23:20:33 +0100 | ksqsf | (~user@134.209.106.31) |
| 2022-01-18 23:23:30 +0100 | ksqsf | (~user@134.209.106.31) (Remote host closed the connection) |
| 2022-01-18 23:24:01 +0100 | <d34df00d> | Is there anything in quickcheck that'll give me a random partition of a list? |
| 2022-01-18 23:24:16 +0100 | <d34df00d> | (that is, a list of sublists such that their concatenation is equal to the original list) |
| 2022-01-18 23:25:17 +0100 | xb0o2 | (~xb0o2@user/xb0o2) (Quit: Client closed) |
| 2022-01-18 23:27:38 +0100 | werneta | (~werneta@70-142-214-115.lightspeed.irvnca.sbcglobal.net) |
| 2022-01-18 23:27:39 +0100 | wmacmil | (~wmacmil@83-233-165-97.cust.bredband2.com) (Ping timeout: 256 seconds) |
| 2022-01-18 23:27:41 +0100 | <d34df00d> | Ok, I think it's a three-liner and not worth a library. |
| 2022-01-18 23:28:32 +0100 | `2jt | (~jtomas@10.red-83-58-228.dynamicip.rima-tde.net) (Ping timeout: 240 seconds) |
| 2022-01-18 23:28:39 +0100 | <hpc> | it's worth a library if you write javascript^W^Wbelieve in yourself :D |
| 2022-01-18 23:28:45 +0100 | <Rembane> | d34df00d: How did you solve it? :) |
| 2022-01-18 23:29:42 +0100 | <d34df00d> | Rembane: for an empty or singleton list, return the list containing of that list. Otherwise, pick a number between (1; length xs), `take` that many off the list, recur on the `drop`, append the result of the `take` to the recursive call result. |
| 2022-01-18 23:29:59 +0100 | <d34df00d> | Not proven to give statistically meaningful results, but OK for my purposes. |
| 2022-01-18 23:30:09 +0100 | <monochrom> | A library would need to parametrize a lot of things, e.g., the distribution of how many splittings, the distribution of each actual splitting point, etc etc... |
| 2022-01-18 23:30:55 +0100 | <Rembane> | d34df00d: Nice solution! You can use splitAt if you want to have take and drop in the same function. |
| 2022-01-18 23:31:13 +0100 | <d34df00d> | Yep, that's in fact what I'm doing :] |
| 2022-01-18 23:31:16 +0100 | <hpc> | i wonder how many quick checks haven't been written because writing that partitioning code yourself is too annoying |
| 2022-01-18 23:31:40 +0100 | <d34df00d> | splitAt is nice and handy! |
| 2022-01-18 23:31:47 +0100 | <Rembane> | d34df00d: Sweet! :) You can also use partitionM and feed it a Bool generator, but I don't know if it's worth that extra library. |
| 2022-01-18 23:31:57 +0100 | <Rembane> | hpc: Seven! At least! |
| 2022-01-18 23:32:07 +0100 | <d34df00d> | Rembane: that'll mess up the ordering of the elements, I think? |
| 2022-01-18 23:32:09 +0100 | ksqsf | (~user@134.209.106.31) |
| 2022-01-18 23:32:23 +0100 | <hpc> | maybe even eight! |
| 2022-01-18 23:32:33 +0100 | <monochrom> | Hrm, what does partitionM do again? |
| 2022-01-18 23:32:38 +0100 | <Rembane> | d34df00d: Yup, I totally missed that you wanted the ordering to be the same. |
| 2022-01-18 23:33:03 +0100 | <Rembane> | monochrom: partition but with monads! https://hackage.haskell.org/package/extra-1.7.10/docs/Control-Monad-Extra.html#v:partitionM |
| 2022-01-18 23:33:11 +0100 | Danishman | (~Danishman@2-104-144-110-cable.dk.customer.tdc.net) (Quit: Leaving) |
| 2022-01-18 23:33:38 +0100 | <monochrom> | Thanks. |
| 2022-01-18 23:34:22 +0100 | <Rembane> | np! |
| 2022-01-18 23:37:03 +0100 | ksqsf | (~user@134.209.106.31) (Ping timeout: 268 seconds) |
| 2022-01-18 23:39:24 +0100 | ksqsf | (~user@134.209.106.31) |
| 2022-01-18 23:41:22 +0100 | CiaoSen | (~Jura@p200300c95737a2002a3a4dfffe84dbd5.dip0.t-ipconnect.de) (Ping timeout: 268 seconds) |
| 2022-01-18 23:42:46 +0100 | Swahili | (~Swahili@a95-94-208-187.cpe.netcabo.pt) |
| 2022-01-18 23:43:14 +0100 | <Swahili> | Q: In ghci, the commands :l or :r, what are these called? Can I say utility commands? |
| 2022-01-18 23:43:26 +0100 | <Swahili> | or is there a name for it? |
| 2022-01-18 23:43:59 +0100 | Sindai | (~Sindai@2a01cb0583e8cd008d228a3c88136061.ipv6.abo.wanadoo.fr) |
| 2022-01-18 23:44:05 +0100 | perrierjouet | (~perrier-j@modemcable012.251-130-66.mc.videotron.ca) (Quit: WeeChat 3.4) |
| 2022-01-18 23:44:50 +0100 | <hpc> | ghci's :help just calls them commands |
| 2022-01-18 23:44:56 +0100 | perrierjouet | (~perrier-j@modemcable012.251-130-66.mc.videotron.ca) |
| 2022-01-18 23:45:05 +0100 | <hpc> | unless you mean those specifically? |
| 2022-01-18 23:45:24 +0100 | <geekosaur> | the user's guide doesn't distinguish either |
| 2022-01-18 23:45:39 +0100 | <geekosaur> | the only commands it treats specially are :set and :seti |
| 2022-01-18 23:48:12 +0100 | <monochrom> | You can safely say "command". If you really like "utility command", I think it is also clear. |
| 2022-01-18 23:49:17 +0100 | <Swahili> | hpc: thank you! |
| 2022-01-18 23:49:36 +0100 | <Swahili> | geekosaur: monochrom thank you! |
| 2022-01-18 23:50:00 +0100 | alp | (~alp@user/alp) (Ping timeout: 268 seconds) |
| 2022-01-18 23:50:47 +0100 | laslmtdbm^ | (~laslmtdbm@wsip-98-188-242-61.mc.at.cox.net) (Remote host closed the connection) |
| 2022-01-18 23:54:36 +0100 | ubert | (~Thunderbi@p200300ecdf09949e91b35a252eb85141.dip0.t-ipconnect.de) (Remote host closed the connection) |
| 2022-01-18 23:57:08 +0100 | ksqsf | (~user@134.209.106.31) (Ping timeout: 250 seconds) |
| 2022-01-18 23:57:15 +0100 | burnsidesLlama | (~burnsides@dhcp168-015.wadham.ox.ac.uk) (Remote host closed the connection) |
| 2022-01-18 23:58:37 +0100 | wroathe | (~wroathe@206-55-188-8.fttp.usinternet.com) |
| 2022-01-18 23:58:37 +0100 | wroathe | (~wroathe@206-55-188-8.fttp.usinternet.com) (Changing host) |
| 2022-01-18 23:58:37 +0100 | wroathe | (~wroathe@user/wroathe) |