Home freenode/#haskell: Logs Calendar

Logs: freenode/#haskell

←Prev  Next→
Page 1 .. 919 920 921 922 923 924 925 926 927 928 929 .. 5022
502,152 events total
2020-10-28 19:18:54 akad_ joins (~akad@109107030050.radomsko.vectranet.pl)
2020-10-28 19:19:16 × akad quits (~akad@109107030050.radomsko.vectranet.pl) (Ping timeout: 246 seconds)
2020-10-28 19:19:20 <hyperisco> dminuoso, if the ergonomics were sufficient that you could largely ignore it when it is not needed then the cost of having it around would be near zero and I wouldn't complain :)
2020-10-28 19:19:32 × Tops21 quits (~Tobias@dyndsl-095-033-093-217.ewe-ip-backbone.de) (Quit: Leaving.)
2020-10-28 19:19:35 × conal quits (~conal@64.71.133.70) (Quit: Computer has gone to sleep.)
2020-10-28 19:19:40 × day quits (~Unknown@unaffiliated/day) (Ping timeout: 260 seconds)
2020-10-28 19:19:54 <dsal> I think most places there's a try block in java, nobody should be dealing with exceptions at all. A catch block does one of three things: 1. Rewraps an exception to satisfy the type system, 2. possibly does something sensible, 3. introduces a bug.
2020-10-28 19:19:59 <dsal> These are the things I'd want to avoid.
2020-10-28 19:20:39 mirrorbird joins (~psutcliff@2a00:801:42b:7891:16b1:e53f:55b2:15e1)
2020-10-28 19:21:02 <dsal> #2 there is OK. Most places there's a try block, we probably just want finally. That's easy to do in Haskell already. So the checked exceptions system needs to let me ignore exceptions where I need them. Then I'm happy with the compiler letting me know I introduced a new exception that I've not considered.
2020-10-28 19:21:06 <hyperisco> dminuoso, I think type inference demonstrates a strong antagonism to types
2020-10-28 19:21:08 <dsal> Hopefully I can also still do partial exception handler.
2020-10-28 19:21:19 <dminuoso> dsal: Interestingly, in Haskell we have related issues with recovery mechanisms in Control.Exception - a plain `catch f (\(e :: SomeException) -> ...)` will catch and recover from async exceptions.
2020-10-28 19:21:21 <dsal> Wait, what?
2020-10-28 19:21:53 <hyperisco> dminuoso, I think it says we want automatic analysis without the expense of explaining ourselves
2020-10-28 19:22:08 × rx_ quits (63f22acf@gateway/web/cgi-irc/kiwiirc.com/ip.99.242.42.207) (Quit: Connection closed)
2020-10-28 19:22:14 <dminuoso> hyperisco: I'd say type inference is a compromise.
2020-10-28 19:22:17 p8m joins (p8m@gateway/vpn/protonvpn/p8m)
2020-10-28 19:22:34 GyroW joins (~GyroW@ptr-48ujrfd1ztq5fjywfw3.18120a2.ip6.access.telenet.be)
2020-10-28 19:22:34 × GyroW quits (~GyroW@ptr-48ujrfd1ztq5fjywfw3.18120a2.ip6.access.telenet.be) (Changing host)
2020-10-28 19:22:34 GyroW joins (~GyroW@unaffiliated/gyrow)
2020-10-28 19:22:44 × GyroW_ quits (~GyroW@unaffiliated/gyrow) (Ping timeout: 240 seconds)
2020-10-28 19:22:51 <dsal> dminuoso: Yeah, I think it can be better. I'm going to go ahead and say your initial assessment of my opinion is probably right. Something hurt me, but that doesn't mean all things will.
2020-10-28 19:23:05 <hyperisco> and I'd admit that probably the worst annoyance of Java that C# fixed was type inference for variable declarations
2020-10-28 19:23:08 <dminuoso> So a system of checked exceptions should, ideally, have a similar model of type inference, where the type checker would automatically deduce what exceptions can be thrown, which exceptions are removed, and so forth.
2020-10-28 19:23:23 acidjnk_new joins (~acidjnk@p200300d0c7237897ad6a1cb47299ad15.dip0.t-ipconnect.de)
2020-10-28 19:23:35 <dsal> Type inference just prevents you from having to talk about types all over the place. You *need* to talk about your types in some place.
2020-10-28 19:23:41 <dminuoso> In a way where you can suddenly hop in and declare some fact, and then let the checker verify whether this leads to conflicts with all the inferred things
2020-10-28 19:24:00 <dminuoso> dsal: Right! The more you elaborate, the better type errors get.
2020-10-28 19:24:14 × sphalerite quits (~sphalerit@NixOS/user/lheckemann) (Quit: nixos 20.09, here I come!)
2020-10-28 19:24:36 <dminuoso> I mean we see this in multiple levels. It frequently happens that I encounter GHC errors in all the wrong places, because of the way type inference works.
2020-10-28 19:24:51 <hyperisco> even on TLDs is a burden
2020-10-28 19:25:02 <hyperisco> literally dozens of exception types build up
2020-10-28 19:25:29 <hyperisco> are you going to keep typing those all out? unlikely
2020-10-28 19:26:19 × dexterlb quits (~dexterlb@2a01:9e40:2:2::2) (Quit: Boing)
2020-10-28 19:26:50 conal joins (~conal@64.71.133.70)
2020-10-28 19:27:51 dexterlb joins (~dexterlb@2a01:9e40:2:2::2)
2020-10-28 19:28:12 <hyperisco> probably there is a type synonym at the top of the file for the union of all exceptions thrown by definitions in that file, because then it is much shorter and less noisy
2020-10-28 19:28:34 × nineonine quits (~textual@216.81.48.202) (Quit: My MacBook has gone to sleep. ZZZzzz…)
2020-10-28 19:29:11 <hyperisco> but then you're weakening all your definitions, and largely forgoing any purpose the feature had in the first place
2020-10-28 19:30:30 <hyperisco> I feel like some of you are in the "wouldn't it be great if" stage of the discussion, and I am in the "it wasn't so great" part of the discussion
2020-10-28 19:31:09 <hyperisco> but I haven't applied checked exceptions to every domain of programming… like I said, some use in file system APIs. Could be others.
2020-10-28 19:31:28 <dolio> Which one wasn't great?
2020-10-28 19:31:44 × p8m quits (p8m@gateway/vpn/protonvpn/p8m) (Ping timeout: 240 seconds)
2020-10-28 19:32:05 × conal quits (~conal@64.71.133.70) (Quit: Computer has gone to sleep.)
2020-10-28 19:32:05 p8m joins (p8m@gateway/vpn/protonvpn/p8m)
2020-10-28 19:32:37 acarrico joins (~acarrico@dhcp-68-142-39-249.greenmountainaccess.net)
2020-10-28 19:33:36 <hyperisco> checked exceptions as a type list / row type
2020-10-28 19:33:56 × mmohammadi9812 quits (~mmohammad@2.178.160.31) (Read error: Connection reset by peer)
2020-10-28 19:34:02 <dolio> In what context? Haskell?
2020-10-28 19:34:06 mmohammadi9812 joins (~mmohammad@2.178.160.31)
2020-10-28 19:34:17 <hyperisco> I was using PureScript but I don't see why the conclusions wouldn't port
2020-10-28 19:35:14 × jakob_ quits (~textual@p200300f49f1622000181680b896afdc3.dip0.t-ipconnect.de) (Quit: My Laptop has gone to sleep. ZZZzzz…)
2020-10-28 19:35:14 <hyperisco> related, that is a language that had a concept of effect rows and removed them, was a hugely breaking change
2020-10-28 19:35:51 raehik joins (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net)
2020-10-28 19:36:45 × britva quits (~britva@31-10-157-156.cgn.dynamic.upc.ch) (Quit: This computer has gone to sleep)
2020-10-28 19:36:54 user01_ joins (~user01@179.181.12.232)
2020-10-28 19:37:08 user01_ parts (~user01@179.181.12.232) ("Leaving")
2020-10-28 19:37:52 <dolio> Well, any judgment based on an expectation of GHC type programming doesn't sound relevant, for instance, because I would imagine the point would be to design an exception system with usability in mind, and complicated GHC type hackery is usually the antithesis of that.
2020-10-28 19:38:02 <davean> I've used it in a few Haskell projects.
2020-10-28 19:38:06 <davean> It wasn't terrible.
2020-10-28 19:38:18 jneira joins (501e64fa@gateway/web/cgi-irc/kiwiirc.com/ip.80.30.100.250)
2020-10-28 19:38:23 × shafox quits (~Srain@106.51.234.111) (Read error: Connection reset by peer)
2020-10-28 19:38:26 <davean> I didn't keep using it.
2020-10-28 19:38:53 geekosaur can't help but think "wasn't terrible" is not a usability milestone to reach for
2020-10-28 19:39:02 <hyperisco> there could be a more palatable system out there… but I think we can look at Java and see that isn't it either, though that seems contended. I'm not Java programmer
2020-10-28 19:39:23 <dolio> Anything concluded based on Java is also irrelevant.
2020-10-28 19:39:51 <davean> http://hackage.haskell.org/package/control-monad-exception is the one I used IIRC.
2020-10-28 19:40:03 <hyperisco> you should consider it relevant, because if you exclude yourself from tried examples then how do you avoid repeating them
2020-10-28 19:40:42 <hyperisco> your chance of success in designing a better system is lessened if you don't fill these potholes first
2020-10-28 19:40:53 <dolio> No, the point is to design a good system, so saying that Java's isn't good doesn't mean that there can't be a good one. This is just the argument that all type systems are bad because Java's is bad.
2020-10-28 19:41:08 <hyperisco> that wasn't my argument, but never mind
2020-10-28 19:41:29 <davean> Is this discussion going anywhere useful?
2020-10-28 19:41:36 × Zetagon quits (~leo@c151-177-52-233.bredband.comhem.se) (Remote host closed the connection)
2020-10-28 19:42:12 <dminuoso> And who knows, perhaps there's some cool ways to build a workable idea into the Haskell type system that either nobody has thought of before, or it hasn't risen to popularity yet.
2020-10-28 19:42:52 × Athas quits (athas@2a01:7c8:aaac:1cf:3df1:2652:30d1:76b7) (Quit: ZNC - http://znc.sourceforge.net)
2020-10-28 19:43:02 Athas joins (athas@2a01:7c8:aaac:1cf:a58f:f586:d8cf:e687)
2020-10-28 19:43:46 <dminuoso> I guess the real problem is type inference at the end, it seems like an almost trivial task to build checked exceptions without the backdoors Java has.
2020-10-28 19:44:15 <hyperisco> I think it starts with another look at exactly what the problem is and allowing new ideas to come in
2020-10-28 19:45:09 u0_a298 joins (~user@47.206.148.226)
2020-10-28 19:45:24 <dolio> If the other example is PureScript's Eff, then I think it also isn't a very good example. It was kind of the most bare bones step in that direction, missing a lot of stuff that could potentially make such a system useful. At least, if I recall correctly.
2020-10-28 19:45:51 <hyperisco> the need to throw multiple exception types, and now how do we analyse that with types or other static analysis, are the assumptions that need to be revisited
2020-10-28 19:46:21 <dminuoso> The last time I had this type of discussion, it was theorized that checked exceptions might perhaps best live in separate type system.
2020-10-28 19:46:42 <dminuoso> Id have to dig my logs to find the exact arguments for this
2020-10-28 19:46:44 × invaser quits (~Thunderbi@31.148.23.125) (Ping timeout: 240 seconds)
2020-10-28 19:46:51 <hyperisco> dolio, it was done away with because it was more work for the programmer without substantial (or I might argue any) payoff
2020-10-28 19:46:57 × mmohammadi9812 quits (~mmohammad@2.178.160.31) (Read error: Connection reset by peer)
2020-10-28 19:47:07 britva joins (~britva@31-10-157-156.cgn.dynamic.upc.ch)
2020-10-28 19:47:23 mmohammadi9812 joins (~mmohammad@2.178.160.31)
2020-10-28 19:47:24 × chkno quits (~chkno@75-7-2-127.lightspeed.sntcca.sbcglobal.net) (Read error: Connection reset by peer)
2020-10-28 19:47:45 chkno joins (~chkno@75-7-2-127.lightspeed.sntcca.sbcglobal.net)
2020-10-28 19:48:06 <hyperisco> and it relates because the symptoms are similar… it accumulated effects as a row type, there weren't interesting ways to discharge most of them, so all rows tended to be widened to the union of all effects
2020-10-28 19:48:08 thir joins (~thir@p200300f27f0b7e004c18ab60065ea01b.dip0.t-ipconnect.de)
2020-10-28 19:48:14 × thir quits (~thir@p200300f27f0b7e004c18ab60065ea01b.dip0.t-ipconnect.de) (Remote host closed the connection)
2020-10-28 19:48:16 <dolio> It was like, 'what if instead of IO there were a bunch of fine grained but still opaque monads, but that's it.' And it turns out that isn't super useful for browser stuff. Just keeping track of FileInput vs. FileOutput in a completely non-acionable way is not useful.
2020-10-28 19:48:36 <dolio> Non-actionable, even.
2020-10-28 19:48:40 thir joins (~thir@p200300f27f0b7e004c18ab60065ea01b.dip0.t-ipconnect.de)
2020-10-28 19:48:59 <hyperisco> this concept of effects was without the utility of interpretation, so it isn't to be compared to effect systems
2020-10-28 19:50:29 <hyperisco> dolio, no it was even sillier than that, it was more like you had a NOW effect if you called Date.getNow(), and a AJAX effect if you used XmlHttpRequest, and several other made up… lets say "tags"
2020-10-28 19:50:44 × nek0 quits (~nek0@mail.nek0.eu) (Quit: The Lounge - https://thelounge.chat)

All times are in UTC.