Home freenode/#haskell: Logs Calendar

Logs: freenode/#haskell

←Prev  Next→ 502,152 events total
2021-02-28 03:23:14 × bergey quits (~user@pool-74-108-99-127.nycmny.fios.verizon.net) (Ping timeout: 260 seconds)
2021-02-28 03:23:21 × redmp_ quits (~redmp@172.58.35.206) (Ping timeout: 264 seconds)
2021-02-28 03:23:30 darjeeling_ joins (~darjeelin@122.245.218.150)
2021-02-28 03:23:40 <minoru_shiraeesh> I answered that it would make sense to provide each module with its own State s a, and then create a bridge between those states somehow, I don't know how
2021-02-28 03:23:51 <koz_> That is the bridge.
2021-02-28 03:23:53 <kw> Right, but the lookups will be through individual calls in IO. I don't want each call to make a new empty cache.
2021-02-28 03:23:57 <koz_> You define a thing that 'forgets' its focus.
2021-02-28 03:24:09 <koz_> If your calls are in IO, your cache can be in IO as well.
2021-02-28 03:24:25 <koz_> You can just have 'cache :: IORef whatever'.
2021-02-28 03:25:17 <kw> :t newIORef
2021-02-28 03:25:18 <lambdabot> error:
2021-02-28 03:25:18 <lambdabot> • Variable not in scope: newIORef
2021-02-28 03:25:18 <lambdabot> • Perhaps you meant ‘newSTRef’ (imported from Data.STRef)
2021-02-28 03:25:25 <zq> koz_: you're right about substituting then reducing
2021-02-28 03:25:26 <koz_> % :t newIORef
2021-02-28 03:25:26 <yahb> koz_: a -> IO (IORef a)
2021-02-28 03:25:35 <zq> i grok it now
2021-02-28 03:25:46 <koz_> zq: It's just like solving an equation.
2021-02-28 03:26:01 <koz_> This at least helps you see some similarities if nothing else.
2021-02-28 03:26:10 <kw> :t Data.IORef.newIORef
2021-02-28 03:26:11 <lambdabot> a -> IO (GHC.IORef.IORef a)
2021-02-28 03:27:44 <koz_> So you create your cache in main (hence in IO), bind that, then pass the resulting IORef as an extra parameter where needed.
2021-02-28 03:27:52 <koz_> If you want this to be 'seamless', use ReaderT.
2021-02-28 03:29:48 <kw> This is library code, not app code. If possible I'd like to avoid forcing users to put 'initializeCache' in their `main` . At that point I'd probably just give up on caching and just suck up the performance hit.
2021-02-28 03:30:22 <koz_> If it's a library, just assume they did it for you.
2021-02-28 03:30:27 <koz_> Just take an extra parameter.
2021-02-28 03:30:58 jacks2 joins (~bc8134e3@217.29.117.252)
2021-02-28 03:31:01 <koz_> Or make a monad involving ReaderT myCacheType IO or whatever in a newtype, and write everything in that.
2021-02-28 03:31:17 <kw> So, getting back to my original question, why are we trying so hard to avoid `unsafePerformIO` ?
2021-02-28 03:31:22 <koz_> And provide a 'runMyMonad :: MyMonad a -> cacheType -> IO a'
2021-02-28 03:31:44 <koz_> There's a reason for the 'unsafe' in that name.
2021-02-28 03:31:51 <koz_> Other folks in here can tell you what gore to anticipate.
2021-02-28 03:32:14 <kw> In this case it should be transparent to the user: The caller of the function will get the same value regardless of whether it's in the cache.
2021-02-28 03:32:32 <koz_> Yeah, but the functions are in IO, correct?
2021-02-28 03:32:54 <koz_> So your users can already assume funky stuff will happen, and you have to say if not.
2021-02-28 03:33:16 <koz_> Honestly, just carry around an extra argument for the IORef cacheType.
2021-02-28 03:33:20 <koz_> It's not that onerous.
2021-02-28 03:33:32 <koz_> You can provide a function that gives back an initialized cache for convenience.
2021-02-28 03:33:38 <koz_> And then your users can wrap it or w/e.
2021-02-28 03:34:15 <jacks2> top level IORef is not unheard of, random uses it for randomIO to update seed
2021-02-28 03:34:40 <koz_> jacks2: But it's not initialized with unsafePerformIO right?
2021-02-28 03:34:43 <kw> I'm not going to create a shitty API for performance reasons. As I said, forcing folks to thread an extra cache parameter is not going to happen.
2021-02-28 03:34:49 ddellacosta joins (ddellacost@gateway/vpn/mullvad/ddellacosta)
2021-02-28 03:35:01 <koz_> kw: Why do you consider it that bad?
2021-02-28 03:35:02 <jacks2> koz_, I did not check the source, but I'm not sure how else it would be created
2021-02-28 03:35:11 <kw> If it's 10 to 50 times slower, OK. Haskell is still reasonably fast.
2021-02-28 03:35:33 <koz_> jacks2: Then how do you know about the top level IORef and what it updates?
2021-02-28 03:35:35 <jacks2> yep, they are using unsafePerformIO
2021-02-28 03:35:37 <kw> I consider it bad because the cache is an implementation artifact, not a part of the semantics of the function.
2021-02-28 03:35:38 <jacks2> theStdGen = unsafePerformIO $ SM.initSMGen >>= newIORef . StdGen
2021-02-28 03:35:49 <jacks2> koz_, because that is the only way to do it
2021-02-28 03:35:49 <infinisil> zq: Just dug up this proof of `reverse (xs ++ reverse ys) == ys ++ reverse xs` from my university notes. Should be relatively self-explanatory, and will be very similar to what you want to prove: https://paste.infinisil.com/_FAwpWitJg.txt
2021-02-28 03:35:50 <koz_> OK, well, there you go kw, go right ahead.
2021-02-28 03:36:29 <jacks2> {-# NOINLINE theStdGen #-} is also the important part of
2021-02-28 03:37:23 <kw> Oh, yeah. Forgot about NOINLINE. It actually wouldn't be terrible to have multiple caches floating around, but it would be a lot less useful.
2021-02-28 03:37:29 × viluon quits (uid453725@gateway/web/irccloud.com/x-ignoxmynamzxzkoi) (Quit: Connection closed for inactivity)
2021-02-28 03:38:31 pfurla joins (~pfurla@ool-182ed2e2.dyn.optonline.net)
2021-02-28 03:39:13 × ddellacosta quits (ddellacost@gateway/vpn/mullvad/ddellacosta) (Ping timeout: 245 seconds)
2021-02-28 03:39:28 POGtastic joins (~POGtastic@2601:1c0:6000:fe1:6f92:35eb:b863:d90a)
2021-02-28 03:39:58 <POGtastic> > pl \x -> map (x:) [[]]
2021-02-28 03:39:59 <lambdabot> error:
2021-02-28 03:39:59 <lambdabot> Unexpected lambda expression in function application:
2021-02-28 03:39:59 <lambdabot> \ x -> map (x :) [[]]
2021-02-28 03:40:29 <minoru_shiraeesh> kw: you can take a look at lambdabot, the approach you described is used there
2021-02-28 03:42:34 <infinisil> POGtastic: It's `@pl <expr>` or the , but don't do it in the channel unless you have a relevant question, PM lambdabot instead
2021-02-28 03:42:43 <infinisil> s/or the //
2021-02-28 03:42:50 <jacks2> kw, see this for all the things you should watch out for if you're going that route. http://hackage.haskell.org/package/base-4.14.1.0/docs/System-IO-Unsafe.html
2021-02-28 03:43:59 <POGtastic> infinisil: gotcha, thanks!
2021-02-28 03:44:46 × POGtastic quits (~POGtastic@2601:1c0:6000:fe1:6f92:35eb:b863:d90a) (Quit: WeeChat 2.9)
2021-02-28 03:46:02 <kw> jacks2: thanks.
2021-02-28 03:47:57 × theDon quits (~td@94.134.91.67) (Ping timeout: 264 seconds)
2021-02-28 03:49:19 theDon joins (~td@muedsl-82-207-238-016.citykom.de)
2021-02-28 03:49:36 × falafel quits (~falafel@pool-96-255-70-50.washdc.fios.verizon.net) (Ping timeout: 240 seconds)
2021-02-28 03:52:19 bergey joins (~user@pool-74-108-99-127.nycmny.fios.verizon.net)
2021-02-28 03:52:46 × HarveyPwca quits (~HarveyPwc@2601:246:c180:a570:29df:3b00:ad0e:3a06) (Quit: Leaving)
2021-02-28 03:54:16 × Narinas quits (~Narinas@187-178-93-112.dynamic.axtel.net) (Read error: Connection reset by peer)
2021-02-28 03:55:55 Narinas joins (~Narinas@187-178-93-112.dynamic.axtel.net)
2021-02-28 03:57:10 falafel joins (~falafel@pool-96-255-70-50.washdc.fios.verizon.net)
2021-02-28 03:57:36 × bergey quits (~user@pool-74-108-99-127.nycmny.fios.verizon.net) (Ping timeout: 240 seconds)
2021-02-28 03:57:42 × soft-warm quits (44695313@ip68-105-83-19.sd.sd.cox.net) (Ping timeout: 240 seconds)
2021-02-28 04:00:28 Rudd0 joins (~Rudd0@185.189.115.108)
2021-02-28 04:00:54 merijn joins (~merijn@83-160-49-249.ip.xs4all.nl)
2021-02-28 04:01:17 × jacks2 quits (~bc8134e3@217.29.117.252) (Quit: http://www.okay.uz/)
2021-02-28 04:02:35 myShoggoth joins (~myShoggot@75.164.81.55)
2021-02-28 04:02:39 × hendursaga quits (~weechat@gateway/tor-sasl/hendursaga) (Remote host closed the connection)
2021-02-28 04:05:01 hendursaga joins (~weechat@gateway/tor-sasl/hendursaga)
2021-02-28 04:07:42 × andreas303 quits (~andreas@gateway/tor-sasl/andreas303) (Ping timeout: 268 seconds)
2021-02-28 04:09:06 andreas303 joins (~andreas@gateway/tor-sasl/andreas303)
2021-02-28 04:11:19 ddellacosta joins (~ddellacos@86.106.143.10)
2021-02-28 04:15:58 × ddellacosta quits (~ddellacos@86.106.143.10) (Ping timeout: 276 seconds)
2021-02-28 04:21:46 × da39a3ee5e6b4b0d quits (~da39a3ee5@184.22.157.95) (Quit: My MacBook has gone to sleep. ZZZzzz…)
2021-02-28 04:27:17 × banyanRob quits (49f11cfb@c-73-241-28-251.hsd1.ca.comcast.net) (Quit: Connection closed)
2021-02-28 04:27:42 nineonine joins (~nineonine@2604:3d08:7785:9600:8c3e:8d1a:de68:76d3)
2021-02-28 04:30:21 × nbloomf quits (~nbloomf@2600:1700:ad14:3020:b84a:c23b:9840:733b) (Quit: My MacBook has gone to sleep. ZZZzzz…)
2021-02-28 04:32:32 × supercoven quits (~Supercove@dsl-hkibng31-54fabd-233.dhcp.inet.fi) (Read error: Connection reset by peer)
2021-02-28 04:32:49 supercoven joins (~Supercove@dsl-hkibng31-54fabd-233.dhcp.inet.fi)
2021-02-28 04:32:50 × supercoven quits (~Supercove@dsl-hkibng31-54fabd-233.dhcp.inet.fi) (Max SendQ exceeded)
2021-02-28 04:33:04 supercoven joins (~Supercove@dsl-hkibng31-54fabd-233.dhcp.inet.fi)
2021-02-28 04:33:05 × supercoven quits (~Supercove@dsl-hkibng31-54fabd-233.dhcp.inet.fi) (Max SendQ exceeded)
2021-02-28 04:33:19 supercoven joins (~Supercove@dsl-hkibng31-54fabd-233.dhcp.inet.fi)

All times are in UTC.