Logs: freenode/#haskell
| 2021-02-28 22:16:05 | → | nrh^ joins (nrh@ip98-184-89-2.mc.at.cox.net) |
| 2021-02-28 22:16:06 | <dolio> | So, either you muck about with lacks predicates for `e`, or you say that `e` is properly abstract, and you cannot catch `Exn1` from `e` even if it's there. But that is equivalent to being able to push on a duplicate `Exn1` field that gets caught by your handler. |
| 2021-02-28 22:16:29 | × | coot_ quits (~coot@37.30.55.141.nat.umts.dynamic.t-mobile.pl) (Remote host closed the connection) |
| 2021-02-28 22:16:36 | <rednaZ[m]> | But I think you can even track "real exceptions" if you had row types. |
| 2021-02-28 22:16:39 | × | catt quits (~r@31.127.31.99) (Ping timeout: 260 seconds) |
| 2021-02-28 22:16:41 | <dolio> | The duplicate fields is how Koka does this for algebraic effects. |
| 2021-02-28 22:16:52 | <edwardk> | rednaZ[m]: i get angry when i pay asymptotically more garbage because of administrative details in my language, the extra garbage then becomes additional heap walks slowly my program asymptotically. |
| 2021-02-28 22:17:05 | <edwardk> | er slowing |
| 2021-02-28 22:17:47 | <dolio> | It automatically had duplicate effects because it was written by Daan Liejen, and he just reused his records stuff. |
| 2021-02-28 22:18:36 | <dolio> | So early papers say things like, "we haven't come up with a good use for this." But it turns out to be a way of solving a problem. |
| 2021-02-28 22:18:51 | <rednaZ[m]> | edwardk: "asymptotically" in which argument? |
| 2021-02-28 22:19:24 | × | orion quits (~orion@unaffiliated/orion) (Quit: "") |
| 2021-02-28 22:20:19 | <dolio> | This is apparently called "tunnelling" when people were just talking about exceptions. |
| 2021-02-28 22:20:25 | → | alx741 joins (~alx741@181.196.68.52) |
| 2021-02-28 22:20:28 | × | tanuki quits (~quassel@173.168.154.189) (Ping timeout: 245 seconds) |
| 2021-02-28 22:20:33 | × | vicfred quits (~vicfred@unaffiliated/vicfred) (Quit: Leaving) |
| 2021-02-28 22:20:58 | <edwardk> | rednaZ[m]: i do a bunch of state operations, especially abstract ones using MonadState s m, and i shed the carcasses of discarded (a, s) tuples all throughout my program, growing my heap. now i pay proportional to the size of my youngest generation (plus some occasional large collections) to clean up after myself. |
| 2021-02-28 22:21:47 | <edwardk> | rednaZ[m]: its why i get annoyed at times working in haskekl. e.g. if i build a queue and put things in and take them off the other end of the job queue because of gc i have to pay proportional to the size of the queue, rather than the churn in the queue. (there's some tricks i keep playing with with compact regions to mitigate that) |
| 2021-02-28 22:21:47 | → | tanuki joins (~quassel@173.168.154.189) |
| 2021-02-28 22:21:52 | <edwardk> | er haskell |
| 2021-02-28 22:22:28 | → | SatanX joins (~SatanX@185.204.1.185) |
| 2021-02-28 22:22:29 | <edwardk> | with epoch based memory reclamation i can usually pay 'gc' overhead proportional to the churn, but i can't use that here directly. |
| 2021-02-28 22:22:49 | SatanX | is now known as Guest68145 |
| 2021-02-28 22:22:58 | <rednaZ[m]> | I agree. |
| 2021-02-28 22:23:24 | × | __minoru__shirae quits (~shiraeesh@5.101.59.4) (Ping timeout: 245 seconds) |
| 2021-02-28 22:23:36 | <edwardk> | the win in the ReaderT case is that its not constantly shedding tuple carcasses to the heap. you pay to deref when you access it. |
| 2021-02-28 22:24:27 | <edwardk> | it annoys me that this is the path to the fastest haskell code i can write =) |
| 2021-02-28 22:25:04 | <dolio> | I guess if I were pressed, I'd say that set-like records are always the wrong semantics. Deduplication and reordering of fields are convenience features for local interaction of a particular presentation of a row, but expecting abstract rows to deduplicate and reorder gets you in a lot of trouble. |
| 2021-02-28 22:25:28 | × | svet_ quits (~svet@90.200.185.163) (Ping timeout: 245 seconds) |
| 2021-02-28 22:25:38 | → | xlei joins (znc@unaffiliated/xlei) |
| 2021-02-28 22:25:58 | <rednaZ[m]> | edwardk: But what is the problem with `ReaderT (IORef s) IO`? |
| 2021-02-28 22:26:21 | × | merijn quits (~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 264 seconds) |
| 2021-02-28 22:27:22 | <edwardk> | rednaZ[m]: honestly not much other than you get stuck with the IO on the bottom driving the computation forward unlike the lazier state monad which has super powers |
| 2021-02-28 22:27:48 | <edwardk> | on the plus side this fixes the fail issues with state |
| 2021-02-28 22:28:08 | <edwardk> | on the minus side all the cool brain bending state tricks fall away like they do in everyone's effect systems |
| 2021-02-28 22:28:10 | <nshepperd> | is there a continuation based StateT which doesn't make any tuples? |
| 2021-02-28 22:28:21 | → | __minoru__shirae joins (~shiraeesh@5.101.59.4) |
| 2021-02-28 22:28:22 | <edwardk> | nshepperd: yes |
| 2021-02-28 22:28:43 | <edwardk> | still has the exception safety problems that the "ReaderT IO" pattern advocates complain about |
| 2021-02-28 22:29:03 | <edwardk> | and ghc is not always great about seeing through the cps to optimize it |
| 2021-02-28 22:29:05 | <nshepperd> | oh, sure |
| 2021-02-28 22:29:09 | <edwardk> | especially when abstract |
| 2021-02-28 22:29:18 | <nshepperd> | exception safety is futile :) |
| 2021-02-28 22:29:38 | <edwardk> | nshepperd: you never write any code that needs to use more than one core do you? =) |
| 2021-02-28 22:32:16 | → | curiousgay joins (~AdminUser@178.217.208.8) |
| 2021-02-28 22:32:37 | × | Franciman quits (~francesco@host-82-49-79-189.retail.telecomitalia.it) (Quit: Leaving) |
| 2021-02-28 22:35:46 | <nshepperd> | sometimes i do |
| 2021-02-28 22:35:59 | <rednaZ[m]> | dolio: I do not understand your point with the `throws e` example. |
| 2021-02-28 22:36:09 | <edwardk> | fair, i was being mildly facetious |
| 2021-02-28 22:36:40 | <nshepperd> | speaking of, is there any ghc flag to make my program default to +RTS -N |
| 2021-02-28 22:36:44 | <rednaZ[m]> | dolio: Surely, you should not be able to write a function `f` that catches all possible exceptions. |
| 2021-02-28 22:36:59 | <dolio> | f catches a single exception. |
| 2021-02-28 22:37:19 | → | kupi joins (uid212005@gateway/web/irccloud.com/x-qxtkrwfdkyjvofwt) |
| 2021-02-28 22:37:21 | <edwardk> | you meam like -threaded -rtsopts -with-rtsopts=-N ? |
| 2021-02-28 22:37:37 | <nshepperd> | that sounds like what i want |
| 2021-02-28 22:37:48 | <rednaZ[m]> | dolio: `f : (a -> b throws e) -> b` would have to catch all, would it not? |
| 2021-02-28 22:37:48 | <dolio> | Oh, I actually wrote a misleading signature, I guess. It should be: `f : (a -> b throw e) -> c throw e` |
| 2021-02-28 22:38:21 | × | danvet quits (~Daniel@2a02:168:57f4:0:efd0:b9e5:5ae6:c2fa) (Ping timeout: 272 seconds) |
| 2021-02-28 22:39:18 | <dolio> | The point is that abstraction is broken, because the details of the exceptions used in the implementation of `f` leak into the type of its argument. |
| 2021-02-28 22:39:31 | <rednaZ[m]> | You can write `f : (a -> b throws {Exn1 | r}) -> b throws r`, can you not? |
| 2021-02-28 22:39:35 | <dolio> | Or the type is imprecise/unsound. |
| 2021-02-28 22:39:38 | <nshepperd> | i wrote a gloss application that seems to be poorly responsive without -N (which i didn't think was meant to happen and maybe means some ffi call is "unsafe" that shouldn't be?) |
| 2021-02-28 22:40:15 | × | __minoru__shirae quits (~shiraeesh@5.101.59.4) (Ping timeout: 240 seconds) |
| 2021-02-28 22:41:08 | <nshepperd> | playing with writing a gui toolkit in gloss and reactive-banana |
| 2021-02-28 22:41:10 | <dolio> | You can do that if you want your checked exceptions to be anti-modular. |
| 2021-02-28 22:41:40 | → | wroathe joins (~wroathe@c-68-54-25-135.hsd1.mn.comcast.net) |
| 2021-02-28 22:44:15 | <rednaZ[m]> | Why is that anti-modular? |
| 2021-02-28 22:44:33 | <rednaZ[m]> | Because "the details of the exceptions used in the implementation of `f` leak into the type of its argument"? |
| 2021-02-28 22:45:14 | <dolio> | Because the implementation details of `f` affect how it behaves on a parameter that would otherwise have an abstract type. |
| 2021-02-28 22:45:26 | → | merijn joins (~merijn@83-160-49-249.ip.xs4all.nl) |
| 2021-02-28 22:46:00 | <dolio> | It means that `g` can't throw Exn1 exceptions without them accidentally getting handled by `f`, which uses them for its own purposes. |
| 2021-02-28 22:47:09 | × | vchlup_ quits (~vchlup@nat.brnet.cz) (Ping timeout: 245 seconds) |
| 2021-02-28 22:50:06 | → | usr25_tm joins (~usr25@unaffiliated/usr25) |
| 2021-02-28 22:50:09 | <dolio> | Another way of explaining the problem is that exception handlers are usually dynamically scoped, and dynamic scoping is anti-modular. |
| 2021-02-28 22:50:28 | <dolio> | For perhaps more obvious reasons. |
| 2021-02-28 22:51:13 | <dolio> | And the answer in that presentation is to make handlers statically scoped. |
| 2021-02-28 22:51:14 | <rednaZ[m]> | Either g's or f's module defines and owns the Exn1 type. The Exn1 type becomes part of that modules specification. |
| 2021-02-28 22:51:23 | <rednaZ[m]> | If the other module acts in a way that causes problems it is violating what the first modules specification is asking from a user. |
| 2021-02-28 22:51:37 | <rednaZ[m]> | ...of that module. |
| 2021-02-28 22:52:00 | <rednaZ[m]> | All specifications are expecting some preconditions. |
| 2021-02-28 22:52:21 | <rednaZ[m]> | That is normal, is it not? |
| 2021-02-28 22:52:35 | → | cole-h joins (~cole-h@c-73-48-197-220.hsd1.ca.comcast.net) |
| 2021-02-28 22:53:49 | × | usr25 quits (~usr25@unaffiliated/usr25) (Ping timeout: 245 seconds) |
| 2021-02-28 22:54:20 | → | aarvar joins (~foewfoiew@2601:602:a080:fa0:d4c5:1ad7:b189:949e) |
| 2021-02-28 22:56:28 | <dolio> | Well, that probably isn't a good assumption. But even if f's implementation 'owns' the exception, its type is cluttered with implementation details. |
| 2021-02-28 22:57:08 | <dolio> | And those implementation details will build more and more clutter in the types that are just saying details that aren't supposed to matter about the implementations. |
| 2021-02-28 22:57:29 | <slack1256> | Is there an update for https://www.slideshare.net/tibbe/highperformance-haskell ? |
| 2021-02-28 22:57:43 | <NieDzejkob> | Is there a shorter way of writing r { field = f (field r) }? |
| 2021-02-28 22:57:59 | <dibblego> | over f |
| 2021-02-28 22:58:22 | <slack1256> | I was thinking on how to approach a project from the ground up with performance in mind (I have to show numbers :P ). This is an alternative to first writing it and then make it performant. |
| 2021-02-28 22:59:18 | → | __minoru__shirae joins (~shiraeesh@5.101.59.4) |
| 2021-02-28 22:59:20 | <dolio> | If you represent checked exceptions with `Either`, for instance, it's not possible for `f :: (a -> Either e b) -> Either e c` to accidentally catch the exceptions from the argument, via parametricity. |
| 2021-02-28 22:59:22 | <rednaZ[m]> | NieDzejkob: `over #field f` if you are using https://hackage.haskell.org/package/optics or https://hackage.haskell.org/package/lens. |
| 2021-02-28 22:59:54 | <NieDzejkob> | I don't use either yet, any opinions on optics vs lens vs microlens? |
| 2021-02-28 23:00:01 | × | __monty__ quits (~toonn@unaffiliated/toonn) (Quit: leaving) |
| 2021-02-28 23:00:19 | <dolio> | And correspondingly, no detail needs to be specified about `e` in the type that is incidentally revealing information about the implementation of `f`. |
| 2021-02-28 23:01:59 | <rednaZ[m]> | NieDzejkob: Whatever you use, I recommend the # labels. |
| 2021-02-28 23:02:08 | ← | mynickisrandom parts (uid148779@gateway/web/irccloud.com/x-rsvsinemprsbzqpy) () |
| 2021-02-28 23:02:24 | <rednaZ[m]> | ...overloaded labels. |
| 2021-02-28 23:03:01 | <rednaZ[m]> | and NoFieldSelectors |
All times are in UTC.