Logs: freenode/#haskell
| 2021-03-09 13:45:56 | <Lycurgus> | wart: blows up on a simple task stupid langs handle with ease |
| 2021-03-09 13:46:00 | <geekosaur> | an infelicity |
| 2021-03-09 13:46:27 | × | astroanax quits (astroanax@gateway/shell/ircnow/x-mwsymdmfxopxcrbb) (Ping timeout: 246 seconds) |
| 2021-03-09 13:46:53 | <merijn> | mananamenos: warts are ugly/uncomfortable/unpleasant things :p |
| 2021-03-09 13:48:09 | <merijn> | mananamenos: Technically, a wart is a kind of skin infection that has all those attributes |
| 2021-03-09 13:48:13 | × | Mrbuck quits (~Mrbuck@gateway/tor-sasl/mrbuck) (Quit: WeeChat 1.9.1) |
| 2021-03-09 13:48:17 | <mananamenos> | :) |
| 2021-03-09 13:48:29 | → | Mrbuck joins (~Mrbuck@gateway/tor-sasl/mrbuck) |
| 2021-03-09 13:48:31 | × | Mrbuck quits (~Mrbuck@gateway/tor-sasl/mrbuck) (Client Quit) |
| 2021-03-09 13:48:47 | <mananamenos> | merijn, yeah, I skin thing came to me in google search, that's why I asked |
| 2021-03-09 13:48:50 | × | LKoen quits (~LKoen@194.250.88.92.rev.sfr.net) (Quit: “It’s only logical. First you learn to talk, then you learn to think. Too bad it’s not the other way round.”) |
| 2021-03-09 13:48:52 | <mananamenos> | Could you expand more about why: * synchronous exceptions being exceptions instead of ExceptT is a wart, but a hard one to fix *? |
| 2021-03-09 13:49:00 | × | mirrorbird quits (dwsjeid911@gateway/vpn/mullvad/dwsjeid911) (Ping timeout: 256 seconds) |
| 2021-03-09 13:49:16 | <merijn> | mananamenos: In Haskell exceptions (in the throw/throwIO sense) are treated as bottoms (non-termination, infinite recursion, etc.) |
| 2021-03-09 13:50:05 | <nshepperd> | frequently, warts are also harder to fix than bugs. if you have a bug on your skin you just shake it off :p |
| 2021-03-09 13:50:05 | <merijn> | mananamenos: I disagree with "exceptions should be ExceptT", tbh. That's a highly contentious and non-universal statemen by geekosaur |
| 2021-03-09 13:50:31 | <mananamenos> | xD |
| 2021-03-09 13:50:32 | <merijn> | unchecked exceptions are a mistake, but "ExceptT" is not the solution, imo |
| 2021-03-09 13:50:55 | <geekosaur> | what Haskell calls synchronous exceptions are out of band returns, not exceptions |
| 2021-03-09 13:51:29 | <merijn> | geekosaur: *Haskell* doesn't specify any form of exceptions, to my knowledge |
| 2021-03-09 13:51:29 | <nshepperd> | isn't that what exceptions are |
| 2021-03-09 13:51:41 | <geekosaur> | not in Haskell, in Haskell they're bottoms |
| 2021-03-09 13:51:49 | <merijn> | And, tbh, I don't even know for sure what you refer to by "synchronous exceptions" |
| 2021-03-09 13:51:59 | <geekosaur> | this isn't really a bottom, it's the kind of thing ExceptT is designed for |
| 2021-03-09 13:52:31 | <merijn> | geekosaur: ExceptT is a poor fit for many, if not most, exceptions of the Control.Exception variety |
| 2021-03-09 13:52:45 | <nshepperd> | that seems like mixing up the cart and the horse |
| 2021-03-09 13:53:21 | × | geowiesnot_bis quits (~user@i15-les02-ix2-87-89-181-157.sfr.lns.abo.bbox.fr) (Ping timeout: 264 seconds) |
| 2021-03-09 13:53:25 | <nshepperd> | are exceptions bottoms or are bottoms exceptions? |
| 2021-03-09 13:53:26 | <merijn> | geekosaur: Unless you are going to argue in favour of "div :: Int -> Int -> ExcepT ArithException m Int" |
| 2021-03-09 13:53:47 | <merijn> | nshepperd: Exceptions are bottoms |
| 2021-03-09 13:53:52 | → | astroanax joins (astroanax@gateway/shell/ircnow/x-nisypfklzoewoaqi) |
| 2021-03-09 13:53:58 | <merijn> | nshepperd: Currently, anyway |
| 2021-03-09 13:54:13 | <merijn> | They don't *have* to be, but that's how they're modelled in Haskell now |
| 2021-03-09 13:54:37 | <nshepperd> | are you sure it's not bottoms that are modelled as exceptions |
| 2021-03-09 13:54:48 | <Taneb> | > let f :: Integer -> Bool; f x = x `seq` f (x + 1) in f 0 |
| 2021-03-09 13:54:54 | <Taneb> | This is a bottom that is not an exception |
| 2021-03-09 13:54:54 | <lambdabot> | mueval-core: Time limit exceeded |
| 2021-03-09 13:55:19 | × | raym quits (~ray@45.64.220.113) (Quit: leaving) |
| 2021-03-09 13:55:41 | <merijn> | nshepperd: That doesn't make sense |
| 2021-03-09 13:55:50 | × | ddellaco_ quits (ddellacost@gateway/vpn/mullvad/ddellacosta) (Remote host closed the connection) |
| 2021-03-09 13:56:08 | <merijn> | nshepperd: bottom is the mathematical name for "non-termination" in the evaluation of lambda terms |
| 2021-03-09 13:56:18 | × | Lycurgus quits (~niemand@cpe-45-46-139-165.buffalo.res.rr.com) (Quit: Exeunt) |
| 2021-03-09 13:56:23 | <merijn> | So, infinite loops, crashes, etc. |
| 2021-03-09 13:56:52 | <merijn> | For the purpose of "what are the semantics of evaluating Haskell expressions", "throw" is a bottom |
| 2021-03-09 13:57:07 | <merijn> | Evaluation of the expression does not terminate |
| 2021-03-09 13:57:22 | <merijn> | It crashes/bails out/etc., however you'd like to call it |
| 2021-03-09 13:57:52 | <merijn> | nshepperd: You can't "model bottoms as exceptions", because at the meta-level (where you can talk about bottom) exceptions don't exist |
| 2021-03-09 13:59:00 | <nshepperd> | my question is really why this alleged fact means that 'exceptions' can't also be 'out of band returns' just because some exceptions are also bottoms |
| 2021-03-09 13:59:06 | → | mirrorbird joins (dwsjeid911@gateway/vpn/mullvad/dwsjeid911) |
| 2021-03-09 13:59:17 | × | average quits (uid473595@gateway/web/irccloud.com/x-esnsvhjcxsvlaxwu) (Quit: Connection closed for inactivity) |
| 2021-03-09 13:59:59 | <merijn> | nshepperd: It depends on how you define "exception" and how you model that definition in the language |
| 2021-03-09 14:00:32 | <merijn> | nshepperd: The definition of exception that is currently implemented in GHC says "exceptions are bottoms" |
| 2021-03-09 14:01:00 | <merijn> | Whether exceptions *have* to be bottoms depends on both how you define "exception" and the language you're working in |
| 2021-03-09 14:01:50 | <merijn> | nshepperd: If you want a definition of "non-bottom exceptions", you'll have to define it first and tell people what it is, because people are obviously going to default to "the definition that is actually implemented" |
| 2021-03-09 14:02:20 | → | maop joins (~maop@37.120.211.188) |
| 2021-03-09 14:03:29 | <merijn> | nshepperd: "just because some exceptions are also bottoms" <- in GHC *all* exceptions are, by definition, bottoms |
| 2021-03-09 14:03:45 | <mananamenos> | merijn, why is ExceptT a poor fit for many, if not most, exceptions of the Control.Exception? |
| 2021-03-09 14:04:14 | × | Psybur quits (~user@unaffiliated/psybur) (Ping timeout: 264 seconds) |
| 2021-03-09 14:04:43 | <nshepperd> | merijn: so is throwIO a |
| 2021-03-09 14:04:54 | <nshepperd> | bottom or a non exception? |
| 2021-03-09 14:05:02 | × | geekosaur quits (82650c7a@130.101.12.122) (Ping timeout: 240 seconds) |
| 2021-03-09 14:05:25 | <merijn> | mananamenos: A lot of the exception from Control.Exception are things that "shouldn't happen", and the only sensible way to handle them is to rollback a ton of stuff |
| 2021-03-09 14:05:28 | <merijn> | nshepperd: It's a bottom |
| 2021-03-09 14:06:10 | × | mayleesia quits (4d0db16a@dynamic-077-013-177-106.77.13.pool.telefonica.de) (Quit: mayleesia) |
| 2021-03-09 14:06:31 | <nshepperd> | geekasaur seems to disagree |
| 2021-03-09 14:07:09 | → | ep1ctetus joins (~epictetus@ip72-194-215-136.sb.sd.cox.net) |
| 2021-03-09 14:07:57 | × | MidAutumnHotaru quits (~MidAutumn@unaffiliated/midautumnhotaru) (Quit: Quit 啾) |
| 2021-03-09 14:08:03 | <mananamenos> | merijn, could you give a simple example? I don't understand * "shouldn't happen" * part |
| 2021-03-09 14:08:37 | → | MidAutumnHotaru joins (~MidAutumn@unaffiliated/midautumnhotaru) |
| 2021-03-09 14:08:59 | Arch-TK | is now known as atk |
| 2021-03-09 14:09:24 | → | zebrag joins (~inkbottle@aaubervilliers-654-1-112-176.w86-198.abo.wanadoo.fr) |
| 2021-03-09 14:18:24 | × | elliott_ quits (~elliott_@pool-108-51-101-42.washdc.fios.verizon.net) (Ping timeout: 245 seconds) |
| 2021-03-09 14:18:48 | → | bor0 joins (~boro@unaffiliated/boro/x-000000001) |
| 2021-03-09 14:18:51 | → | LKoen joins (~LKoen@194.250.88.92.rev.sfr.net) |
| 2021-03-09 14:20:06 | <bor0> | Wondering how/if lazy evaluation kicks in for https://paste.tomsmeding.com/8LQ6BNXP. For example, let's assume that generateCombinations l1 l2 produces a very large list. does `getPage (generateCombinations l1 l2) 200 20` only calculate those specific results (page 200, length 20) or does it actually calculate all of them? |
| 2021-03-09 14:21:46 | → | geekosaur joins (82650c7a@130.101.12.122) |
| 2021-03-09 14:21:47 | → | jamm_ joins (~jamm@unaffiliated/jamm) |
| 2021-03-09 14:23:25 | → | elliott_ joins (~elliott_@pool-108-51-101-42.washdc.fios.verizon.net) |
| 2021-03-09 14:24:04 | × | dsrt^ quits (dsrt@ip98-184-89-2.mc.at.cox.net) (Read error: Connection reset by peer) |
| 2021-03-09 14:26:24 | <geekosaur> | my primary contention is that things like "file not found" are synchronous and should not be modeled as bottoms. and yes, I'd argue div fits into the same category although a convenience function that converts it to a bottom could be provided |
| 2021-03-09 14:29:04 | <geekosaur> | in fact most of the "exceptions" openFile can produce are synchronous and should be dealt with via ExceptT. the actual async exceptions can happen later when the resulting Handle is read from, although even there there might be synchronous read ops (that's a harder case to argue) |
| 2021-03-09 14:30:30 | → | mouseghost joins (~draco@87-206-9-185.dynamic.chello.pl) |
| 2021-03-09 14:30:30 | × | mouseghost quits (~draco@87-206-9-185.dynamic.chello.pl) (Changing host) |
| 2021-03-09 14:30:30 | → | mouseghost joins (~draco@wikipedia/desperek) |
| 2021-03-09 14:30:38 | <maerwald> | ExceptT? :> |
| 2021-03-09 14:32:41 | <lyxia> | bor0: only those results |
| 2021-03-09 14:33:28 | <bor0> | lyxia, thanks, that's what my experiment showed but I wanted to confirm. This is magical. I had to do similar implementation in PHP (language without lazy evaluation) and the amount of manual work I had to do is ... calculate all those indices manually, do slicing of arrays, ugh |
| 2021-03-09 14:33:37 | <lyxia> | > drop 10 [if i == 0 then undefined else (i, j) | i <- [0,1], j <- [0..9]] |
| 2021-03-09 14:33:39 | <lambdabot> | [(1,0),(1,1),(1,2),(1,3),(1,4),(1,5),(1,6),(1,7),(1,8),(1,9)] |
| 2021-03-09 14:33:54 | <nshepperd> | what does "file not found should not be a bottom" actually mean specifically? is there something wrong with the throw/catch IO api? |
| 2021-03-09 14:34:02 | <nshepperd> | you want checked exceptions? |
| 2021-03-09 14:35:24 | → | hyperisco joins (~hyperisco@d192-186-117-226.static.comm.cgocable.net) |
| 2021-03-09 14:35:26 | → | kam1 joins (~kam1@83.123.154.198) |
| 2021-03-09 14:35:31 | <bor0> | ah, didn't think of trying undefined. I just tried it on two lists that'd produce over a million results |
| 2021-03-09 14:35:38 | <bor0> | Thanks! |
| 2021-03-09 14:36:55 | → | carlomagno joins (~cararell@148.87.23.7) |
| 2021-03-09 14:37:25 | × | carlomagno quits (~cararell@148.87.23.7) (Remote host closed the connection) |
| 2021-03-09 14:38:44 | × | caubert_ quits (~caubert@136.244.111.235) (Quit: WeeChat 3.0) |
| 2021-03-09 14:39:01 | → | caubert joins (~caubert@136.244.111.235) |
| 2021-03-09 14:39:20 | → | carlomagno joins (~cararell@148.87.23.7) |
All times are in UTC.