Logs: freenode/#haskell
| 2021-03-13 19:00:18 | <tomsmeding> | being able to evaluate function-typed values to WHNF is actually very useful |
| 2021-03-13 19:01:07 | <tomsmeding> | to give a very concrete example: this function 'run1' takes a function in the Accelerate embedded language, and returns a Haskell function that evaluates it https://hackage.haskell.org/package/accelerate-llvm-native-1.3.0.0/docs/Data-Array-Accelerate-LLVM-Native.html#v:run1 |
| 2021-03-13 19:01:18 | × | Guest16306 quits (~textual@zrcout.mskcc.org) (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 2021-03-13 19:01:22 | <siers> | Are there any implementations of mutable sets in hackage? |
| 2021-03-13 19:01:33 | <koz_> | siers: HashSet too slow for you? |
| 2021-03-13 19:01:43 | <koz_> | Or rather, why is mutability important? |
| 2021-03-13 19:01:47 | <tomsmeding> | the Accelerate compiler implementation is written in such a way that forcing that 'a -> b' function to WHNF evaluates the full compilation of the Accelerate function |
| 2021-03-13 19:02:02 | × | Vra quits (8077cab5@natp-128-119-202-181.wireless.umass.edu) (Ping timeout: 240 seconds) |
| 2021-03-13 19:02:11 | <tomsmeding> | which is useful to be able to do explicitly, e.g. for benchmarking purposes |
| 2021-03-13 19:03:06 | <siers> | koz_, I'm just looking for it. I don't think I'll end up needing it. |
| 2021-03-13 19:03:08 | <int-e> | dmj`: One case where ghc *will* exchange bottoms is when you have a complex function that is strict in its arguments but evaluates them in different orders depending on the precise inputs... and ghc decides to unbox the arguments. It seems hard to come up with a small, reliable example for that. |
| 2021-03-13 19:03:27 | <c_wraith> | siers: it's hard to imagine one being better than IORef (Set a) or MVar (Set a) |
| 2021-03-13 19:03:34 | → | berberman_ joins (~berberman@unaffiliated/berberman) |
| 2021-03-13 19:03:43 | → | ddellacosta joins (~ddellacos@86.106.143.213) |
| 2021-03-13 19:03:44 | → | geekosaur joins (82650c7a@130.101.12.122) |
| 2021-03-13 19:03:53 | <c_wraith> | siers: it *could* happen, but you'd need a ridiculous amount of concurrent access |
| 2021-03-13 19:04:10 | × | jb55 quits (~jb55@gateway/tor-sasl/jb55) (Remote host closed the connection) |
| 2021-03-13 19:04:21 | × | berberman quits (~berberman@unaffiliated/berberman) (Ping timeout: 272 seconds) |
| 2021-03-13 19:04:32 | <koz_> | c_wraith: In all honesty, given how badly HashMap clocks anything in hashtables in practice? HashSet is probably fast enough for whatever you wanna do, zero mutability required. |
| 2021-03-13 19:04:37 | → | jb55 joins (~jb55@gateway/tor-sasl/jb55) |
| 2021-03-13 19:04:53 | <c_wraith> | koz_: mutability matters for concurrent modifications, not performance |
| 2021-03-13 19:05:00 | → | monadmatt joins (~user@119-17-128-101.771180.mel.nbn.aussiebb.net) |
| 2021-03-13 19:05:51 | <koz_> | c_wraith: Fair point. |
| 2021-03-13 19:08:21 | × | ddellacosta quits (~ddellacos@86.106.143.213) (Ping timeout: 264 seconds) |
| 2021-03-13 19:08:40 | → | _jogo_ joins (~jogo@ip5b42a696.dynamic.kabel-deutschland.de) |
| 2021-03-13 19:08:55 | <dmj`> | tomsmeding: I don't disagree Func (b -> b) should be semantically equivalent to (b -> b), but I think they might desugar differently. |
| 2021-03-13 19:09:41 | <tomsmeding> | dmj`: ghc very well might, but if the effect is observable, that's a deviation from the haskell standard |
| 2021-03-13 19:09:47 | <c_wraith> | I remember some benchmarking of concurrent data structures a while back, and there was a note at the end saying just using a standard immutable data structure in an MVar trounced all of them for performance up until something like 12 cores were making frequent updates. |
| 2021-03-13 19:10:09 | × | monadmatt quits (~user@119-17-128-101.771180.mel.nbn.aussiebb.net) (Ping timeout: 264 seconds) |
| 2021-03-13 19:10:50 | <tomsmeding> | dmj`: haskell isn't defined in terms of desugarings, it's defined in terms of how stuff should behave semantically |
| 2021-03-13 19:11:13 | <tomsmeding> | ghc mostly adheres to the definitions, but sometimes deviates, for example with the eta-expansion I linked; but it doesn't always do that |
| 2021-03-13 19:11:33 | → | tromp joins (~tromp@dhcp-077-249-230-040.chello.nl) |
| 2021-03-13 19:12:44 | × | raehik1 quits (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) (Ping timeout: 256 seconds) |
| 2021-03-13 19:13:02 | × | son0p quits (~son0p@181.58.39.182) (Quit: Lost terminal) |
| 2021-03-13 19:17:10 | → | merijn joins (~merijn@83-160-49-249.ip.xs4all.nl) |
| 2021-03-13 19:17:28 | → | Alleria joins (~textual@2603-7000-3040-0000-90f8-4e28-a385-635a.res6.spectrum.com) |
| 2021-03-13 19:17:32 | <dmj`> | tomsmeding: it's pretty unintuitive behavior, I agree. Representation will change semantics though, the more you unbox, the stricter things have to be. |
| 2021-03-13 19:17:51 | Alleria | is now known as Guest34685 |
| 2021-03-13 19:18:09 | <tomsmeding> | dmj`: that's certainly true: if you start unboxing, you change semantics |
| 2021-03-13 19:18:39 | <tomsmeding> | I think we're arguing from different perspectives: you're seeing the implementation (ghc) as truth, I'm seeing the specification (the haskell report) as truth, and the implementation something that mostly adheres to spec |
| 2021-03-13 19:19:05 | <tomsmeding> | so when I say that eta-expansion "should" not change semantics, you say "but it does" -- true, but that was not my point :p |
| 2021-03-13 19:19:11 | × | fendor quits (~fendor@178.115.131.242.wireless.dyn.drei.com) (Remote host closed the connection) |
| 2021-03-13 19:19:20 | <tomsmeding> | correction: eta-expansion of course changes semantics |
| 2021-03-13 19:19:31 | × | _jogo_ quits (~jogo@ip5b42a696.dynamic.kabel-deutschland.de) (Quit: _jogo_) |
| 2021-03-13 19:19:35 | <tomsmeding> | I should have said: ghc should not eta-expand in an observable way |
| 2021-03-13 19:20:04 | <tomsmeding> | two ways to reason about behaviour :) |
| 2021-03-13 19:20:17 | <int-e> | tomsmeding: which is why they list this as a known bug or infelicity |
| 2021-03-13 19:20:25 | <tomsmeding> | precisely |
| 2021-03-13 19:20:32 | <tomsmeding> | :) |
| 2021-03-13 19:20:36 | <int-e> | in contrast, exchanging one bottom for another is perfectly legitimate |
| 2021-03-13 19:20:42 | <tomsmeding> | ghc developers are ever diligent |
| 2021-03-13 19:21:05 | <int-e> | just very annoying (especially when a meaningful error gets replaced by another error or by nontermination) |
| 2021-03-13 19:21:26 | × | joebobjoe quits (~joebobjoe@unaffiliated/joebobjoe) (Quit: Lost terminal) |
| 2021-03-13 19:22:47 | × | jb55 quits (~jb55@gateway/tor-sasl/jb55) (Remote host closed the connection) |
| 2021-03-13 19:23:08 | → | jb55 joins (~jb55@gateway/tor-sasl/jb55) |
| 2021-03-13 19:24:35 | <dmj`> | tomsmeding: maybe "desugaring" was the wrong word, but the representation of data types in GHC Haskell Core is different than functions (hence why this isn't an apples-to-apples comparison), I think data types could be desugared to lambdas in Core, but they're not (correct me if I'm wrong), so that might have something to do with the fact that Func (b->b) than b->b |
| 2021-03-13 19:24:41 | <dmj`> | is different than* |
| 2021-03-13 19:25:09 | → | makergrl joins (~ident@212.65.4.46.bc.googleusercontent.com) |
| 2021-03-13 19:25:12 | <dmj`> | and its probably most definitely the reason eta-expansion isn't happening for Func |
| 2021-03-13 19:26:01 | <siers> | How do I run an IO effect in "StateT IO a b"? |
| 2021-03-13 19:26:17 | <dmj`> | liftIO |
| 2021-03-13 19:26:46 | → | ddellacosta joins (~ddellacos@86.106.143.70) |
| 2021-03-13 19:26:56 | <siers> | if it was some other monad, then could I not lift it? |
| 2021-03-13 19:27:12 | <dmj`> | siers: can only liftIO if its an instance of MonadIO |
| 2021-03-13 19:27:29 | <dmj`> | siers: true for all transformers, not true for all monads |
| 2021-03-13 19:27:38 | <enikar> | there is also lift. |
| 2021-03-13 19:27:42 | → | unyu joins (~pyon@unaffiliated/pyon) |
| 2021-03-13 19:28:32 | <siers> | dmj`, "not true for all monads" ah |
| 2021-03-13 19:28:50 | → | fendor joins (~fendor@178.115.131.242.wireless.dyn.drei.com) |
| 2021-03-13 19:29:58 | <tomsmeding> | true for all transformers -- if, of course, the next monad (transformer) in the stack also implements MonadIO |
| 2021-03-13 19:30:01 | → | heatsink joins (~heatsink@2600:1700:bef1:5e10:c79:3d13:d977:c947) |
| 2021-03-13 19:30:14 | <tomsmeding> | 'StateT Maybe a' does not implement MonadIO |
| 2021-03-13 19:30:47 | <siers> | how do I write [] type unapplied? |
| 2021-03-13 19:30:49 | <siers> | the* |
| 2021-03-13 19:31:02 | <siers> | forall? |
| 2021-03-13 19:31:14 | <siers> | I just wanted to plug it into StateT to see what that even would mean |
| 2021-03-13 19:31:25 | <hpc> | it's just [] |
| 2021-03-13 19:31:42 | <hpc> | StateT m [] a |
| 2021-03-13 19:31:43 | <siers> | > [1] :: [] Int |
| 2021-03-13 19:31:45 | <lambdabot> | [1] |
| 2021-03-13 19:31:54 | <siers> | hm, that did not work in ghci |
| 2021-03-13 19:32:05 | <siers> | ah, never mind |
| 2021-03-13 19:32:22 | <unyu> | “:k [] Int” works just fine in GHCi. |
| 2021-03-13 19:32:29 | <siers> | yes, yes :) |
| 2021-03-13 19:33:09 | <unyu> | Do sequences represented as finger trees efficiently support the following operation? Find an element x in the sequence AxB, and replace it with another sequence C, getting ACB. If so, is the intermediate state of the zipper focused at x the same as if were merely going to replace x with another element y? |
| 2021-03-13 19:34:15 | × | heatsink quits (~heatsink@2600:1700:bef1:5e10:c79:3d13:d977:c947) (Ping timeout: 240 seconds) |
| 2021-03-13 19:34:18 | × | tromp quits (~tromp@dhcp-077-249-230-040.chello.nl) (Remote host closed the connection) |
| 2021-03-13 19:35:38 | <peutri> | how many points per subquestion? |
| 2021-03-13 19:35:48 | × | Mrbuck quits (~Mrbuck@gateway/tor-sasl/mrbuck) (Quit: WeeChat 1.9.1) |
| 2021-03-13 19:36:09 | → | jamm_ joins (~jamm@unaffiliated/jamm) |
| 2021-03-13 19:36:48 | <tomsmeding> | unyu: the replacing can be implemented using splitAt and ><, both of which are logarithmic |
| 2021-03-13 19:37:26 | <tomsmeding> | but they do restructure the tree |
| 2021-03-13 19:37:43 | × | ddellacosta quits (~ddellacos@86.106.143.70) (Remote host closed the connection) |
| 2021-03-13 19:39:39 | → | tromp joins (~tromp@dhcp-077-249-230-040.chello.nl) |
| 2021-03-13 19:43:12 | × | mirrorbird quits (dwsjeid911@gateway/vpn/mullvad/dwsjeid911) (Ping timeout: 246 seconds) |
| 2021-03-13 19:44:03 | <unyu> | Thanks! I guess restructuring is inevitable for arbitrary C. But, for small enough C (say, 2 elements), it should be possible to insert C into the hole A_B, without splitting the latter into A and B first, right? |
| 2021-03-13 19:45:02 | × | arrowsvc_ quits (~arr@2.93.163.35) (Ping timeout: 256 seconds) |
| 2021-03-13 19:46:46 | × | takuan quits (~takuan@178-116-218-225.access.telenet.be) (Ping timeout: 276 seconds) |
| 2021-03-13 19:47:04 | → | frozenErebus joins (~frozenEre@94.128.82.20) |
| 2021-03-13 19:47:26 | <tomsmeding> | unyu: that depends on how the finger tree is currently structured; it might be true, but it might also not be |
All times are in UTC.