Home freenode/#haskell: Logs Calendar

Logs: freenode/#haskell

←Prev  Next→
Page 1 .. 440 441 442 443 444 445 446 447 448 449 450 .. 5022
— 502,152 events total
2020-10-05 20:11:28 → jespada joins (~jespada@90.254.246.48)
2020-10-05 20:11:34 <int-e> ski: Hmm, you don't need an IVar for that. You can achieve the same thing, more cheaply, with an IORef: data Node a = Node !(IORef a) a; instance Eq (Node a) where Node r1 _ == Node r2 _ = r1 == r2; newNode a = Node <$> newIORef a <*> pure a. Note also, that the allocated IORef is responsible for the identity of the node...
2020-10-05 20:11:38 <tomsmeding> so if you think evaluation strategy is important, then you should recurse on both parameters at the same time :p
2020-10-05 20:11:49 <ski> (and then you can flip the parameter orders, if you want. and yes, you could have variants where you induct on both parameters, in different ways)
2020-10-05 20:11:55 × Super_Feeling quits (~Super_Fee@103.92.43.209) (Remote host closed the connection)
2020-10-05 20:12:25 <int-e> ski: Or is the point that the IVar can resolve cycles, hmm.
2020-10-05 20:12:27 × st8less quits (~st8less@2603:a060:11fd:0:101c:4882:6a23:1c57) (Ping timeout: 240 seconds)
2020-10-05 20:12:35 <tomsmeding> and of course the proposal that meant to (re-)add a ghci command for expanding type synonyms got stranded due to inactivity :D https://github.com/ghc-proposals/ghc-proposals/pull/79
2020-10-05 20:12:49 <monochrom> But I can see that "add Z n = n; add m Z = Z; add (S m) (S n) = S (S (add m n))" is very much nicer, like zip.
2020-10-05 20:13:23 <int-e> ski: (which the IORef version can do as well, but it'll be more prone to undetected bugs that set a node value more than once)
2020-10-05 20:13:38 <tomsmeding> monochrom: I very much like that one indeed :p
2020-10-05 20:14:17 <int-e> ski: Anyway, it's certainly a use I've never ever considered before.
2020-10-05 20:14:31 → st8less joins (~st8less@inet-167-224-197-181.isp.ozarksgo.net)
2020-10-05 20:14:39 <int-e> So thanks for that :)
2020-10-05 20:15:09 <int-e> The lack of an Ord instance will hurt eventually, I suppose.
2020-10-05 20:15:15 × knupfer quits (~Thunderbi@200116b82cef8300610dc462ddae2e63.dip.versatel-1u1.de) (Read error: Connection reset by peer)
2020-10-05 20:15:19 → knupfer1 joins (~Thunderbi@200116b82cef83003844d391b8848e28.dip.versatel-1u1.de)
2020-10-05 20:15:35 × knupfer1 quits (~Thunderbi@200116b82cef83003844d391b8848e28.dip.versatel-1u1.de) (Client Quit)
2020-10-05 20:15:36 <ski> int-e : yea, one could do that. but you'd need a way to generate an uninstantiated `IVar', and to instantiate it, after the fact (getting blocking read if it's not instantiated yet). and perhaps think about whether there'll be any problem with threads, due to using simple `IORef's
2020-10-05 20:15:47 → knupfer joins (~Thunderbi@200116b82cef8300f037b40504d258ce.dip.versatel-1u1.de)
2020-10-05 20:15:53 × knupfer quits (~Thunderbi@200116b82cef8300f037b40504d258ce.dip.versatel-1u1.de) (Client Quit)
2020-10-05 20:16:06 → knupfer joins (~Thunderbi@200116b82cef8300b5c936f19440c318.dip.versatel-1u1.de)
2020-10-05 20:16:07 <ski> @type newCyclicIORef
2020-10-05 20:16:09 <lambdabot> (IORef a -> a) -> IO (IORef a)
2020-10-05 20:16:18 × knupfer quits (~Thunderbi@200116b82cef8300b5c936f19440c318.dip.versatel-1u1.de) (Read error: Connection reset by peer)
2020-10-05 20:16:26 → knupfer joins (~Thunderbi@200116b82cef830070386856bf96007c.dip.versatel-1u1.de)
2020-10-05 20:16:28 × knupfer quits (~Thunderbi@200116b82cef830070386856bf96007c.dip.versatel-1u1.de) (Client Quit)
2020-10-05 20:16:40 <ski> what's a nice way to do that, but generating multiple `IORef's ?
2020-10-05 20:16:48 <dolio> Most refs aren't orderable, because that's not stable under GC.
2020-10-05 20:16:50 → knupfer joins (~Thunderbi@200116b82cef83001cef98ca424016ba.dip.versatel-1u1.de)
2020-10-05 20:16:51 × knupfer quits (~Thunderbi@200116b82cef83001cef98ca424016ba.dip.versatel-1u1.de) (Client Quit)
2020-10-05 20:16:52 <ski> @type newCyclicIORefT
2020-10-05 20:16:54 <lambdabot> Traversable f => f (f (IORef a) -> a) -> IO (f (IORef a))
2020-10-05 20:16:58 × GyroW quits (~GyroW@unaffiliated/gyrow) (Quit: Someone ate my pie)
2020-10-05 20:17:04 → alp joins (~alp@2a01:e0a:58b:4920:e03a:3413:fb91:53fc)
2020-10-05 20:17:05 <ski> still requires all of them to be `IORef a' ..
2020-10-05 20:17:08 → GyroW joins (~GyroW@d54C03E98.access.telenet.be)
2020-10-05 20:17:09 × GyroW quits (~GyroW@d54C03E98.access.telenet.be) (Changing host)
2020-10-05 20:17:09 → GyroW joins (~GyroW@unaffiliated/gyrow)
2020-10-05 20:17:11 <dolio> So it's more expensive to be ordered.
2020-10-05 20:17:33 → knupfer joins (~Thunderbi@200116b82cef8300dd7c73b5b438b1fa.dip.versatel-1u1.de)
2020-10-05 20:17:35 × knupfer quits (~Thunderbi@200116b82cef8300dd7c73b5b438b1fa.dip.versatel-1u1.de) (Client Quit)
2020-10-05 20:17:46 → L29Ah joins (~L29Ah@unaffiliated/l29ah)
2020-10-05 20:18:10 <int-e> dolio: Sure, I know why :) But for the purpose of detecting sharing, having just Eq results in a scalability problem.
2020-10-05 20:18:11 → incognito9999_ joins (~incognito@hwsrv-648981.hostwindsdns.com)
2020-10-05 20:18:43 <ski> monochrom : except it's not really that much like `zip', you get two `S's out, for one `S' in, in each parameter ?
2020-10-05 20:18:49 → knupfer joins (~Thunderbi@200116b82cef8300e49e64b009df27a7.dip.versatel-1u1.de)
2020-10-05 20:19:02 <int-e> dolio: Which is not really the intended purpose of those references (Eq instance notwithstanding) so that's fine.
2020-10-05 20:19:02 <dolio> That's why the well-ordering principle is false. :)
2020-10-05 20:19:18 × knupfer quits (~Thunderbi@200116b82cef8300e49e64b009df27a7.dip.versatel-1u1.de) (Client Quit)
2020-10-05 20:19:23 <ski> (and you still have the (lack of) parallel-or problem, that `add undefined (S n)' isn't equal to `S (add undefined n)')
2020-10-05 20:19:34 → knupfer joins (~Thunderbi@200116b82cef8300a895f9e57b9e84bd.dip.versatel-1u1.de)
2020-10-05 20:19:45 × knupfer quits (~Thunderbi@200116b82cef8300a895f9e57b9e84bd.dip.versatel-1u1.de) (Client Quit)
2020-10-05 20:19:52 → knupfer joins (~Thunderbi@200116b82cef8300a895f9e57b9e84bd.dip.versatel-1u1.de)
2020-10-05 20:20:14 → knupfer1 joins (~Thunderbi@200116b82cef83009da320cc3b7d023e.dip.versatel-1u1.de)
2020-10-05 20:20:21 × knupfer quits (~Thunderbi@200116b82cef8300a895f9e57b9e84bd.dip.versatel-1u1.de) (Client Quit)
2020-10-05 20:20:22 knupfer1 is now known as knupfer
2020-10-05 20:20:26 → J_Arcane_ joins (sid119274@gateway/web/irccloud.com/x-okfghrpejlzoualp)
2020-10-05 20:20:27 → m-renaud_ joins (sid333785@gateway/web/irccloud.com/x-wdhdpnuntagzspud)
2020-10-05 20:20:27 → alanz_ joins (sid110616@gateway/web/irccloud.com/x-rotyfkerxdfrgsjt)
2020-10-05 20:20:27 → jlpeters_ joins (sid25606@gateway/web/irccloud.com/x-xkxchtjwumvvoplq)
2020-10-05 20:20:28 → drbrule_ joins (sid395654@gateway/web/irccloud.com/x-qzclcwgouytxdizk)
2020-10-05 20:20:28 → scav_ joins (sid309693@gateway/web/irccloud.com/x-bpvpcjgxpjzjedad)
2020-10-05 20:20:29 × knupfer quits (~Thunderbi@200116b82cef83009da320cc3b7d023e.dip.versatel-1u1.de) (Client Quit)
2020-10-05 20:20:30 → banjiewen_ joins (sid115913@gateway/web/irccloud.com/x-dxltzkvalxmnuugq)
2020-10-05 20:20:31 → fiadliel_ joins (sid399568@gateway/web/irccloud.com/x-rcssxagrxaenrwkf)
2020-10-05 20:20:38 → albethere_ joins (sid457088@gateway/web/irccloud.com/x-fnvfojoflynertwf)
2020-10-05 20:20:38 → knupfer joins (~Thunderbi@200116b82cef8300c06758e924f2c41e.dip.versatel-1u1.de)
2020-10-05 20:20:39 → rusua_ joins (uid124537@gateway/web/irccloud.com/x-mpizelreyaaubxup)
2020-10-05 20:20:42 → JSharp_ joins (sid4580@wikia/JSharp)
2020-10-05 20:20:43 → bitonic_ joins (sid61915@gateway/web/irccloud.com/x-evaxaxrhylqawuas)
2020-10-05 20:20:47 <tomsmeding> ski: but that one you can't solve in general: you got to inspect _an_ argument first :p
2020-10-05 20:20:51 → SrPx_ joins (sid108780@gateway/web/irccloud.com/x-czvvabmhqaigtsgp)
2020-10-05 20:20:55 <ski> int-e : it was the `read :: IVar a -> a' together with `instance Eq (IVar a)' (and also, of course, the ability to fill it in, independently, some time after creation time), that made it catch my attention (years ago)
2020-10-05 20:20:58 → xarian_ joins (~xarian@104.236.81.162)
2020-10-05 20:21:07 <ski> tomsmeding : except if you race threads :)
2020-10-05 20:21:15 → eruditass_ joins (uid248673@gateway/web/irccloud.com/x-ubxwbqgbcybasbta)
2020-10-05 20:21:38 <tomsmeding> that went very quickly from total language land to ugly haskell land :p
2020-10-05 20:21:44 <int-e> ski: I still think this particular IVar is cute. However, personally, I never found a convincing use for it. :)
2020-10-05 20:21:58 → Forkk_ joins (forkk@2600:3c00::f03c:91ff:fe84:de4d)
2020-10-05 20:22:42 → lucas8 joins (~luc@2001:41d0:8:109c::1)
2020-10-05 20:22:45 → megaTherion_ joins (~therion@unix.io)
2020-10-05 20:23:12 → mystfox joins (~myst@focks.pw)
2020-10-05 20:23:19 → atomi__ joins (~atomi@35.71.197.35.bc.googleusercontent.com)
2020-10-05 20:23:43 <ski> tomsmeding : anyway, to continue, i think the "direct" version is suerior to the "accumulating" version (comparing just those two), since the former is incremental, while the latter is bulky. and, with dependent types, this manifests as if you have `m0 + n' in your type, and you learn that `m0 = S m', then it can rewrite `S m + n' to `S (m + n)', and so you get an outer `S' to "match" on, rather than an
2020-10-05 20:23:49 <ski> opaque call to `+'
2020-10-05 20:24:24 → Stanley00 joins (~stanley00@unaffiliated/stanley00)
2020-10-05 20:24:24 → cheers- joins (user@unaffiliated/cheers)
2020-10-05 20:24:29 <tomsmeding> yes making progress early by putting an S on the outside is nice
2020-10-05 20:24:48 <ski> (obviously i'm not talking about a strict representation of naturals here, where accumulation can make more sense, since you don't get incrementality anyway)
2020-10-05 20:25:25 <int-e> ski: Having a pure `read` is the essence of the whole package; everything else is designed to make that possible, including all limitations.
2020-10-05 20:25:41 <ski> int-e : ah, i see :)
2020-10-05 20:25:52 × SrPx quits (sid108780@gateway/web/irccloud.com/x-xulqbpplkjjfywzr) (Ping timeout: 244 seconds)
2020-10-05 20:25:52 × jlpeters quits (sid25606@gateway/web/irccloud.com/x-oxflbpvsmgilmdyy) (Ping timeout: 244 seconds)
2020-10-05 20:25:52 × alanz quits (sid110616@gateway/web/irccloud.com/x-bplzytauuzaqtdwm) (Ping timeout: 244 seconds)
2020-10-05 20:25:52 × xarian quits (~xarian@104.236.81.162) (Ping timeout: 244 seconds)
2020-10-05 20:25:52 × rawles quits (~r@unaffiliated/rawles) (Ping timeout: 244 seconds)
2020-10-05 20:25:52 × eruditass quits (uid248673@gateway/web/irccloud.com/x-iuzbfjvdrultjkys) (Ping timeout: 244 seconds)
2020-10-05 20:25:52 × m-renaud quits (sid333785@gateway/web/irccloud.com/x-tkucctivkfyvgvtj) (Ping timeout: 244 seconds)
2020-10-05 20:25:52 × J_Arcane quits (sid119274@gateway/web/irccloud.com/x-woiwotxdlskjwxcj) (Ping timeout: 244 seconds)
←Prev  Next→
Page 1 .. 440 441 442 443 444 445 446 447 448 449 450 .. 5022

All times are in UTC.