Logs: liberachat/#haskell
| 2021-06-28 09:29:21 | <merijn> | I think it's a stupid mistake that will set us back in the future, the same way C++'s backwards compat is setting it back |
| 2021-06-28 09:29:33 | <delYsid> | merijn: When I saw PureScript for the first time, I was sad for months, because I wanted that, instead of Num and other haskell legacies... |
| 2021-06-28 09:29:46 | <merijn> | It's trading "convenience now" for "how sane this will be 30 years from now" |
| 2021-06-28 09:30:00 | <boxscape_> | Fixing Num is comparatively easy, you only need a new Prelude, not a new language |
| 2021-06-28 09:30:22 | <Lycurgus> | rio |
| 2021-06-28 09:30:25 | <merijn> | Designing a fixed Num is hard, though |
| 2021-06-28 09:30:34 | <delYsid> | Totally easy, so which of the alternative Preludes has managed to gain significant market share? :-) |
| 2021-06-28 09:30:40 | <merijn> | I'm not convinced PureScript's is practically better |
| 2021-06-28 09:30:59 | <boxscape_> | delYsid just because it's comparatively easy doesn't mean it's easy :P |
| 2021-06-28 09:31:10 | <merijn> | delYsid: Most Prelude don't provide enough benefit to justify the cost |
| 2021-06-28 09:31:34 | <tdammers> | at this point, I would like to mention Python 3 |
| 2021-06-28 09:32:44 | <kuribas> | Are GADTs worth it for serialized expressions? You are just shifting the type checking from evaluation time to (de)serialisation time... |
| 2021-06-28 09:33:48 | <merijn> | tdammers: Python 3 was mistake for different reasons |
| 2021-06-28 09:34:05 | <merijn> | tdammers: It didn't change enough to be a new language, but *also* didn't provide forward compat |
| 2021-06-28 09:34:26 | <merijn> | Python3 wouldn't have been such a huge clusterfuck if they had provided a way to write 2.7 code that was *also* valid 3.x |
| 2021-06-28 09:34:36 | <tdammers> | merijn: yes, my point is that it paid the cost of breaking changes without enough benefit |
| 2021-06-28 09:34:44 | <merijn> | kuribas: It Depends |
| 2021-06-28 09:34:59 | <tdammers> | merijn: and I believe that "fixing Num" would be a similar breaking change |
| 2021-06-28 09:35:00 | <merijn> | tdammers: Right, but I fear that's the lot of LinearHaskell and DependentHaskell too, tbh |
| 2021-06-28 09:35:11 | <merijn> | tdammers: I think fixing Num is nice in theory |
| 2021-06-28 09:35:30 | <merijn> | tdammers: But I haven't seen any proposals for a fixed Num that's practical enough to justify any changes |
| 2021-06-28 09:35:46 | <tdammers> | exactly. fixing Num is one thing, fixing it without ruining everything for everyone is another |
| 2021-06-28 09:35:54 | <merijn> | We could start by extending Num with bounds checked conversion |
| 2021-06-28 09:36:19 | <tdammers> | I'm thinking maybe a better approach would be introducing a separate, parallel typeclass hierarchy |
| 2021-06-28 09:36:21 | <merijn> | tdammers: I am not even convinced any of the proposed fixes I've seen are actually fixes |
| 2021-06-28 09:36:31 | <Profpatsch> | merijn: You have to keep in mind that it took us 20 years to get to the current state of HAskell |
| 2021-06-28 09:36:31 | → | peterhil joins (~peterhil@dsl-hkibng32-54f849-252.dhcp.inet.fi) |
| 2021-06-28 09:36:34 | <Profpatsch> | GHC haskell |
| 2021-06-28 09:36:35 | <tdammers> | well, the question is of course where you draw the line |
| 2021-06-28 09:36:55 | <tdammers> | Num is arguably too large, and instance Num Double is useful but wrong |
| 2021-06-28 09:37:00 | <tdammers> | but how far do you take it |
| 2021-06-28 09:37:12 | <merijn> | Profpatsch: Eh, you mean 30ish :p |
| 2021-06-28 09:37:45 | <Profpatsch> | so what makes you think the next lang won’t take 30 |
| 2021-06-28 09:37:46 | <merijn> | tdammers: "Num Double is wrong" <- see, I don't even necessarily agree with the people whining about that |
| 2021-06-28 09:37:53 | <merijn> | Profpatsch: I'm not saying it wont' |
| 2021-06-28 09:38:05 | <merijn> | Profpatsch: So better start 10 years ago |
| 2021-06-28 09:38:40 | <Profpatsch> | merijn: but that’s after my work life |
| 2021-06-28 09:38:40 | × | Lycurgus quits (~juan@cpe-45-46-140-49.buffalo.res.rr.com) (Quit: Exeunt) |
| 2021-06-28 09:38:44 | <merijn> | But, if not 10 years ago, *now* is as good a time at any |
| 2021-06-28 09:38:55 | <Profpatsch> | Idris, Agda etc |
| 2021-06-28 09:39:07 | <merijn> | Agda isn't a programming language, imo |
| 2021-06-28 09:39:09 | <tdammers> | merijn: of course, whether it's "wrong" depends on which semantics and laws you subscribe to in the first place |
| 2021-06-28 09:39:13 | <merijn> | Idris is interesting enough :) |
| 2021-06-28 09:39:26 | <merijn> | tdammers: The real mistake is imagining "lawful math" for Num |
| 2021-06-28 09:39:36 | <merijn> | tdammers: Lawful math is rarely useful on computers, imo |
| 2021-06-28 09:39:39 | <boxscape_> | is IEEE754 + associative? |
| 2021-06-28 09:39:45 | <merijn> | boxscape_: No |
| 2021-06-28 09:39:48 | <boxscape_> | nice |
| 2021-06-28 09:40:02 | <tdammers> | merijn: the "laws" need not be the same as in Math, mind you. |
| 2021-06-28 09:40:47 | <merijn> | boxscape_: IEEE754 guarantees that for any pair of "x `op` y" the result is "the closest representible value to the mathematical ideal result" |
| 2021-06-28 09:40:54 | <boxscape_> | I see |
| 2021-06-28 09:41:22 | <merijn> | boxscape_: But the difference between actual and "mathematical ideal" can be different for 2 pairs of numbers, obviously |
| 2021-06-28 09:41:44 | <boxscape_> | right |
| 2021-06-28 09:42:01 | <merijn> | so "a + (b + c)" first rounds "b + c" to closest representible, then adds 'a', then rounds again. Which may be different from (a + b) + c |
| 2021-06-28 09:42:11 | <boxscape_> | okay, that makes sense |
| 2021-06-28 09:43:14 | → | __monty__ joins (~toonn@user/toonn) |
| 2021-06-28 09:43:16 | <merijn> | Contrary to popular opinion on the internet IEEE754 itself is actually well thought out to make it deterministic and possible to reason about accuracy, so there is a coherent system, it just doesn't quite conform to reals |
| 2021-06-28 09:43:26 | <merijn> | So you just gotta abandon the idea of floats being reals |
| 2021-06-28 09:44:39 | <merijn> | boxscape_: For example, associativity and stuff all hold for "integer values below 2^53" (since those are all perfectly representible) |
| 2021-06-28 09:45:09 | <boxscape_> | oka |
| 2021-06-28 09:45:10 | <boxscape_> | y |
| 2021-06-28 09:46:09 | <merijn> | (in general, all laws on the reals hold for any values that are representible, it's only irrepresentible values that introduce errors) |
| 2021-06-28 09:46:52 | <nshepperd2> | which are unfortunately most of them |
| 2021-06-28 09:46:55 | <kuribas> | and then there is rounding modes, how much the implementation adheres to the standard... |
| 2021-06-28 09:47:25 | <kuribas> | It's *very difficult* to make a completely standard complient implementation. |
| 2021-06-28 09:47:28 | <merijn> | kuribas: All languages use the hardware anyway, so that's a moot issue 99% of the time |
| 2021-06-28 09:47:54 | <merijn> | nshepperd2: I mean, most numbers are problematic anyway :p |
| 2021-06-28 09:48:10 | × | mastarija quits (~mastarija@31.217.22.187) (Ping timeout: 272 seconds) |
| 2021-06-28 09:48:20 | <merijn> | nshepperd2: Once you move past the rationals they're all terrible |
| 2021-06-28 09:48:54 | <nshepperd2> | the worst numbers you will ever meet |
| 2021-06-28 09:49:15 | <nshepperd2> | imo the real problem with Num is the inclusion of signum, abs |
| 2021-06-28 09:49:48 | <nshepperd2> | i have written abs = undefined far too many times |
| 2021-06-28 09:50:08 | <merijn> | nshepperd2: Sounds like you should make less Num instances >.> |
| 2021-06-28 09:50:37 | <kuribas> | merijn: rounding modes matter for hardware also. |
| 2021-06-28 09:50:40 | <merijn> | In fact, as a rule of thumb, if you're name isn't edwardk, probably best not be making any Num instances |
| 2021-06-28 09:50:58 | <merijn> | kuribas: Fortunately the OS sets the rounding mode to default when a thread is created |
| 2021-06-28 09:51:00 | <kuribas> | merijn: especially if you want calculations to be reproducable. |
| 2021-06-28 09:51:07 | <merijn> | kuribas: So unless you are explicitly fucking it up, it's fine |
| 2021-06-28 09:51:43 | <kuribas> | merijn: or a library you call? |
| 2021-06-28 09:51:51 | <merijn> | kuribas: That sounds more like you're getting bitten by gcc and it's tendency to use x87 extended precision registers, rather than float rounding |
| 2021-06-28 09:52:02 | <merijn> | kuribas: I've never encountered any libraries that touch rounding mode |
| 2021-06-28 09:52:11 | <kuribas> | right :) |
| 2021-06-28 09:52:22 | <merijn> | So, I dunno, get less shit dependencies if they are touching that? :p |
| 2021-06-28 09:52:48 | <kuribas> | I don't know why floating point gets so much hate. You just have to know how to use it... |
| 2021-06-28 09:55:11 | <kuribas> | obviously don't use it for monitary calculations. |
| 2021-06-28 09:56:18 | <Rembane> | Maybe it's because people are ignorant fools? |
| 2021-06-28 09:56:42 | <merijn> | Rembane: This holds true for most problems :p |
| 2021-06-28 09:57:02 | <Profpatsch> | I never understood why people do number things with haskell |
| 2021-06-28 09:57:19 | <Profpatsch> | Like, everything is working against you. |
| 2021-06-28 09:57:38 | <Profpatsch> | Num, Boxed by default, strange conversion primitives |
| 2021-06-28 09:58:04 | <Rembane> | merijn: Yup. :D |
| 2021-06-28 09:58:14 | <Rembane> | Profpatsch: Maybe they like pain? |
| 2021-06-28 09:58:22 | <kuribas> | Profpatsch: the one advantage is that you can abstract low level primitives, and still get good performance. |
| 2021-06-28 09:58:24 | → | nschoe joins (~quassel@178.251.84.79) |
| 2021-06-28 09:59:14 | → | notzmv joins (~zmv@user/notzmv) |
| 2021-06-28 09:59:37 | <Rembane> | You don't have to fall back to C |
| 2021-06-28 09:59:51 | <Profpatsch> | I wouldn’t do number things in C either |
| 2021-06-28 09:59:51 | <kuribas> | Working over Vector instead of doing indexed loops. |
| 2021-06-28 10:00:15 | <boxscape_> | what would you use for number things |
| 2021-06-28 10:00:23 | <Profpatsch> | idk, not a number thing person |
All times are in UTC.