Home freenode/#haskell: Logs Calendar

Logs: freenode/#haskell

←Prev  Next→ 502,152 events total
2020-11-08 13:19:19 Codaraxis joins (~Codaraxis@ip68-5-90-227.oc.oc.cox.net)
2020-11-08 13:19:47 <Ariakenom> avdb, there performance is great afaik. what do u mean?
2020-11-08 13:22:00 × machinedgod quits (~machinedg@207.253.244.210) (Ping timeout: 256 seconds)
2020-11-08 13:23:08 × Cthalupa quits (~cthulhu@47.186.47.75) (Ping timeout: 256 seconds)
2020-11-08 13:24:38 Cthalupa joins (~cthulhu@47.186.47.75)
2020-11-08 13:25:42 × mputz quits (~Thunderbi@dslb-084-058-211-084.084.058.pools.vodafone-ip.de) (Quit: mputz)
2020-11-08 13:25:55 mputz joins (~Thunderbi@dslb-084-058-211-084.084.058.pools.vodafone-ip.de)
2020-11-08 13:29:03 jamm_ joins (~jamm@unaffiliated/jamm)
2020-11-08 13:32:33 ensyde joins (~ensyde@99-185-235-117.lightspeed.chrlnc.sbcglobal.net)
2020-11-08 13:32:46 Achylles joins (~Achylles@187.34.14.187)
2020-11-08 13:33:54 thir joins (~thir@p200300f27f0b7e00f4e9381c2bf90854.dip0.t-ipconnect.de)
2020-11-08 13:33:57 × Achylles quits (~Achylles@187.34.14.187) (Max SendQ exceeded)
2020-11-08 13:34:30 Achylles joins (~Achylles@187.34.14.187)
2020-11-08 13:35:26 × bliminse quits (~bliminse@host109-156-197-211.range109-156.btcentralplus.com) (Ping timeout: 264 seconds)
2020-11-08 13:36:07 bliminse joins (~bliminse@host109-156-197-211.range109-156.btcentralplus.com)
2020-11-08 13:36:53 × ensyde quits (~ensyde@99-185-235-117.lightspeed.chrlnc.sbcglobal.net) (Ping timeout: 260 seconds)
2020-11-08 13:38:11 × thir quits (~thir@p200300f27f0b7e00f4e9381c2bf90854.dip0.t-ipconnect.de) (Ping timeout: 244 seconds)
2020-11-08 13:44:21 texasmynsted joins (~texasmyns@64.44.55.100)
2020-11-08 13:44:54 × knupfer quits (~Thunderbi@200116b82ca873008cc39c41af455969.dip.versatel-1u1.de) (Ping timeout: 244 seconds)
2020-11-08 13:45:13 × drbean quits (~drbean@TC210-63-209-151.static.apol.com.tw) (Ping timeout: 264 seconds)
2020-11-08 13:46:19 <maerwald> Ariakenom: it isn't, that's why free monads are slow too and applicative has more ways for the compiler to optimise
2020-11-08 13:46:22 × shatriff quits (~vitaliish@176.52.219.10) (Read error: Connection reset by peer)
2020-11-08 13:46:48 <maerwald> this is a basic problem for effects systems as well
2020-11-08 13:46:51 shatriff joins (~vitaliish@176.52.219.10)
2020-11-08 13:47:38 × p-core quits (~Thunderbi@2001:718:1e03:5128:2ab7:7f35:48a1:8515) (Quit: p-core)
2020-11-08 13:48:04 dansho joins (~dansho@ip68-108-167-185.lv.lv.cox.net)
2020-11-08 13:48:13 <Ariakenom> free monads yes. but normal concrete ones are not
2020-11-08 13:48:47 <maerwald> yes they are, because tho next effect depends on the valuee
2020-11-08 13:49:28 × Achylles quits (~Achylles@187.34.14.187) (Remote host closed the connection)
2020-11-08 13:50:30 <maerwald> also relevant https://www.vidarholen.net/contents/blog/?p=859 wrt transformers slowing down your program by 10%
2020-11-08 13:51:25 <maerwald> it's also true intuitevely, because it's the most expressive tool, where effects depend on values
2020-11-08 13:51:33 × Kaiepi quits (~Kaiepi@nwcsnbsc03w-47-55-225-82.dhcp-dynamic.fibreop.nb.bellaliant.net) (Remote host closed the connection)
2020-11-08 13:51:46 Kaiepi joins (~Kaiepi@nwcsnbsc03w-47-55-225-82.dhcp-dynamic.fibreop.nb.bellaliant.net)
2020-11-08 13:52:42 <maerwald> that limits statical analysis too as described in Neils blog post
2020-11-08 13:54:51 Achylles joins (~Achylles@187.34.14.187)
2020-11-08 13:54:58 <Ariakenom> the relevant comparison here,, I would think, would be between side effects and IO. And I've never seen any claim that IO is slow. (not that side effects would work in haskell but still)
2020-11-08 13:55:15 <maerwald> for it to perform well at all, you need to rely on GHC to do a lot of nice optimisations. If they break, for esoteric reasons, you're left with bad performance
2020-11-08 13:55:42 <merijn> maerwald: that's only for polymorphic do blocks/monadic actions
2020-11-08 13:55:44 <geekosaur> IO is known to have slow cases. they're usually hidden by ghc optimizations and by I/O itself being slow
2020-11-08 13:56:13 <merijn> There's too many wish-washy words and descriptions in this discussion for it to be remotely useful, though
2020-11-08 13:56:59 <merijn> For one, I call BS on the claim that "Applicative gets better optimised than Monad" beyond "some people have implemented more efficient Applicative instances"
2020-11-08 13:57:29 <merijn> The amount of optimisation GHC does, doesn't make use of class laws, afaik, so that can't matter
2020-11-08 13:58:39 × geekosaur quits (ac3a5366@172.58.83.102) (Remote host closed the connection)
2020-11-08 13:58:40 <merijn> "transformers is 10% slower" is also impossibly general. 10% slow than what? What's your baseline? What's the code? Without precision about what performance/numbers we're tracking, what we're comparing against, this is just some IRC masturbation about our favourite/unfavourite abstractions
2020-11-08 13:58:52 <maerwald> merijn: see the link
2020-11-08 13:59:15 <maerwald> I was very specific
2020-11-08 13:59:20 <merijn> I see 0 mentions of "transformers" when searching that page
2020-11-08 13:59:28 <maerwald> then you didn't read it properly
2020-11-08 13:59:32 × Kaiepi quits (~Kaiepi@nwcsnbsc03w-47-55-225-82.dhcp-dynamic.fibreop.nb.bellaliant.net) (Remote host closed the connection)
2020-11-08 13:59:48 <merijn> I didn't read, I searched
2020-11-08 13:59:50 Kaiepi joins (~Kaiepi@nwcsnbsc03w-47-55-225-82.dhcp-dynamic.fibreop.nb.bellaliant.net)
2020-11-08 13:59:52 <maerwald> "Converting them to a cleaner ReaderT led to a 10% total run time regression, so I had to revert it."
2020-11-08 13:59:54 <Ariakenom> search 10% or readert
2020-11-08 13:59:55 <merijn> Anyway, I found it
2020-11-08 14:00:33 <merijn> "10% between functions and ReaderT" <- was that using polymorphic mtl style code or using transformers? Do you have a sample? 10% regression in what? wallclock time? memory?
2020-11-08 14:00:55 <maerwald> run time regression
2020-11-08 14:02:20 <maerwald> ReaderT is a transformer, not mtl
2020-11-08 14:02:36 <maerwald> I didn't look at the PR though
2020-11-08 14:02:51 <merijn> Yes, but you can use ReaderT in a stack and still write intermediate code using mtl
2020-11-08 14:03:01 <merijn> In fact, lots of people do
2020-11-08 14:05:28 cosimone joins (~cosimone@2001:b07:ae5:db26:d849:743b:370b:b3cd)
2020-11-08 14:07:24 elfets joins (~elfets@ip-37-201-23-96.hsi13.unitymediagroup.de)
2020-11-08 14:08:45 <maerwald> "instances can perform analysis of computations before they are executed, and thus produce shared optimizations." :)
2020-11-08 14:09:08 plakband joins (~plakband@softbank126126238105.bbtec.net)
2020-11-08 14:10:28 × Kaiepi quits (~Kaiepi@nwcsnbsc03w-47-55-225-82.dhcp-dynamic.fibreop.nb.bellaliant.net) (Read error: Connection reset by peer)
2020-11-08 14:11:24 × raehik quits (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) (Ping timeout: 260 seconds)
2020-11-08 14:12:45 × olligobber quits (~olligobbe@unaffiliated/olligobber) (Ping timeout: 240 seconds)
2020-11-08 14:13:17 machinedgod joins (~machinedg@24.105.81.50)
2020-11-08 14:13:30 Kaiepi joins (~Kaiepi@nwcsnbsc03w-47-55-225-82.dhcp-dynamic.fibreop.nb.bellaliant.net)
2020-11-08 14:14:45 <merijn> My point is that that's just a matter of "<*>" is a different function than >>=
2020-11-08 14:15:27 <merijn> There's no reason you couldn't do the same thing transformers IFF users restrict themselves to <*>
2020-11-08 14:16:00 <merijn> And if they can't restrict themselves to <*> the entire discussion is moot, since that means they can't implement it without using Monad anyway
2020-11-08 14:17:04 <merijn> So "Applicatives are faster than monads" is true in the same vacuous sense that "return 42" is faster than "doing actual computation", which is great if returning 42 is all you need, but utterly pointless if you need something else
2020-11-08 14:17:53 <maerwald> And I've read a lot that <*> often outperform `ap`
2020-11-08 14:19:52 <merijn> That's an artifact of ap not being a class method and predating AMP, being implemented using >>=
2020-11-08 14:20:39 <merijn> We could easily make it either a class method or change it to be <*>, but then everyone who defined Applicative using `ap` has their code break
2020-11-08 14:20:50 <merijn> There's also literally no reason to use "ap" ever
2020-11-08 14:22:36 <[exa]> hm, what's the easiest way/package/function to convert string-ish numbers to unixtime? (even ignoring the about the amount of ambiguity hidden in that task)
2020-11-08 14:23:01 <maerwald> [exa]: there are a few fuzzy time parsers
2020-11-08 14:23:17 <[exa]> in particular, I just found that `Data.UnixTime.parseUnixTime "%Y-%m-%d" "2020-10-32"` is the same as for "2020-10-0" with no error reported
2020-11-08 14:23:36 <maerwald> @hackage fuzzy-dates
2020-11-08 14:23:36 <lambdabot> https://hackage.haskell.org/package/fuzzy-dates
2020-11-08 14:23:37 <[exa]> at least the errors would be cool
2020-11-08 14:23:54 <merijn> [exa]: Where is Data.UnixTime from?
2020-11-08 14:24:00 <merijn> And why are you not using Data.Time?
2020-11-08 14:24:04 × lep-delete quits (~lep@94.31.83.149) (Read error: Connection reset by peer)
2020-11-08 14:24:34 <[exa]> package `unix-time`
2020-11-08 14:24:53 <[exa]> it was here in the project, expected no shenanigans
2020-11-08 14:25:17 lep-delete joins (~lep@94.31.83.149)
2020-11-08 14:25:25 × yinfeng quits (~yinfeng@114.212.87.131) (Ping timeout: 264 seconds)
2020-11-08 14:25:45 <merijn> [exa]: Seems easiest to just parse a UTCTime using "time" and then use utcTimeToPOSIXSeconds ?
2020-11-08 14:25:51 lep-delete is now known as test
2020-11-08 14:26:20 test is now known as Guest67212
2020-11-08 14:26:50 <[exa]> merijn: will try, thanks
2020-11-08 14:31:40 Achylles_ joins (~Achylles@191.205.18.155)
2020-11-08 14:32:03 <__monty__> Isn't Data.Time anything but lax/fuzzy?
2020-11-08 14:33:33 <[exa]> oh that at least knows how to fail on Oct 32th
2020-11-08 14:34:04 <merijn> __monty__: Hence my suggestion to use that, rather than unix-time?
2020-11-08 14:35:06 × Achylles quits (~Achylles@187.34.14.187) (Ping timeout: 256 seconds)
2020-11-08 14:35:56 erisco joins (~erisco@d24-57-249-233.home.cgocable.net)

All times are in UTC.