Logs: freenode/#haskell
| 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.