Newest at the top
2024-05-14 07:16:28 +0200 | <glguy> | oh, no |
2024-05-14 07:15:37 +0200 | <cheater> | so you're basically the "haskell is unreadable" person |
2024-05-14 07:15:20 +0200 | <glguy> | I would avoid using such a language, but I don't think it exists |
2024-05-14 07:13:53 +0200 | <cheater> | have you used the language i'm describing? |
2024-05-14 07:13:34 +0200 | remmie | (ianremsen@tilde.team) |
2024-05-14 07:13:03 +0200 | mei | (~mei@user/mei) |
2024-05-14 07:12:55 +0200 | <glguy> | no, that's not a common take on people who've actually used it |
2024-05-14 07:12:51 +0200 | <cheater> | if you lose track of that then your code is too messy anyways |
2024-05-14 07:12:42 +0200 | <cheater> | yeah you know that one usually when reading code |
2024-05-14 07:12:30 +0200 | <cheater> | idk that it would be, people say haskell's syntax is a complete disaster for readability too |
2024-05-14 07:12:17 +0200 | <glguy> | now to know what: f x y means, you have to work out the types of f, x, and y before you can know which thing is which |
2024-05-14 07:11:59 +0200 | <glguy> | beyond it simply not working with the way types in Haskell work, it'd be a complete disaster for readability |
2024-05-14 07:11:31 +0200 | michalz | (~michalz@185.246.207.193) |
2024-05-14 07:10:38 +0200 | mei | (~mei@user/mei) (Remote host closed the connection) |
2024-05-14 07:10:34 +0200 | <cheater> | but i don't think that's an issue |
2024-05-14 07:10:29 +0200 | <glguy> | all functions have one argument; no functions have two |
2024-05-14 07:10:29 +0200 | <cheater> | i see where you're coming from |
2024-05-14 07:10:21 +0200 | <cheater> | ok ok |
2024-05-14 07:10:18 +0200 | <glguy> | but that doesn't mean you can't apply the result as a function |
2024-05-14 07:10:08 +0200 | <glguy> | function in haskell *only* have one argument |
2024-05-14 07:10:08 +0200 | <cheater> | id only has one argument |
2024-05-14 07:10:00 +0200 | <glguy> | You need to know the order of application to even attempt to type-check an expression |
2024-05-14 07:09:38 +0200 | <lambdabot> | a -> a |
2024-05-14 07:09:37 +0200 | <glguy> | :t id |
2024-05-14 07:09:35 +0200 | <lambdabot> | 11 |
2024-05-14 07:09:34 +0200 | <glguy> | > id succ 10 |
2024-05-14 07:09:31 +0200 | <cheater> | why |
2024-05-14 07:09:14 +0200 | <glguy> | cheater: that would only make sense in a vary narrow subset of Haskell |
2024-05-14 07:00:59 +0200 | <cheater> | like what languages are you thinking of |
2024-05-14 06:46:16 +0200 | <danza> | other languages that support out-of-order arguments end up with a syntax similar to { arg = val } like one would easily achieve with a product type |
2024-05-14 06:44:29 +0200 | <cheater> | whatever's useful |
2024-05-14 06:44:17 +0200 | <cheater> | so what if we had a type constructor that's like (->) but binds less tightly than (->) and doesn't care about order. say (&). You could write f :: X & A -> B -> C & Y & Z -> Out, and then you could go like f a b c x y z, or f a x b y c z, or f x y z a b c |
2024-05-14 06:42:23 +0200 | <cheater> | if you look at type sigs, f :: A -> B -> C is basically a tuple. the only reason it's not exactly the same thing as (A, B, C) is currying. |
2024-05-14 06:41:56 +0200 | <cheater> | idk what you're saying |
2024-05-14 06:40:39 +0200 | <danza> | make a product type for that? |
2024-05-14 06:40:14 +0200 | <cheater> | rarely do functions have the same type multiple times, and when they do it's usually like a binary or ternary function and then you can explicitly order them with a tuple |
2024-05-14 06:39:49 +0200 | <cheater> | i feel like haskell would be better if arguments were non-positional, i.e. you could supply them in any order |
2024-05-14 06:37:46 +0200 | remmie | (ianremsen@tilde.team) (Ping timeout: 256 seconds) |
2024-05-14 06:23:41 +0200 | ChaiTRex | (~ChaiTRex@user/chaitrex) |
2024-05-14 06:22:51 +0200 | ChaiTRex | (~ChaiTRex@user/chaitrex) (Remote host closed the connection) |
2024-05-14 06:21:18 +0200 | rosco | (~rosco@yp-146-6.tm.net.my) |
2024-05-14 06:16:28 +0200 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Remote host closed the connection) |
2024-05-14 06:08:46 +0200 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) |
2024-05-14 06:06:26 +0200 | yin | (~yin@user/zero) |
2024-05-14 06:06:15 +0200 | ec | (~ec@gateway/tor-sasl/ec) |
2024-05-14 06:05:35 +0200 | ec | (~ec@gateway/tor-sasl/ec) (Remote host closed the connection) |
2024-05-14 06:04:48 +0200 | yin | (~yin@user/zero) (Ping timeout: 255 seconds) |
2024-05-14 06:00:56 +0200 | rekahsoft | (~rekahsoft@184.148.6.204) (Ping timeout: 256 seconds) |
2024-05-14 05:56:22 +0200 | aforemny | (~aforemny@i59F516F4.versanet.de) (Ping timeout: 246 seconds) |
2024-05-14 05:55:47 +0200 | aforemny_ | (~aforemny@i59F516F1.versanet.de) |