Newest at the top
| 2024-05-14 11:52:01 +0200 | <lortabac> | I think it would be nice to have this feature as an IDE action, but not baked in the language |
| 2024-05-14 11:51:52 +0200 | <danse-nr3> | one can also have f (default'{ arg = type }) |
| 2024-05-14 11:51:26 +0200 | <danse-nr3> | dunno, i just use product types and that gives me 99% of the functionality |
| 2024-05-14 11:51:21 +0200 | <ski> | danse-nr3 : <https://en.wikipedia.org/wiki/Hanlon's_razor> |
| 2024-05-14 11:51:10 +0200 | <lortabac> | you can select a record field by type if there is no ambiguity |
| 2024-05-14 11:50:54 +0200 | <lortabac> | IIRC generic-lens does something similar to what cheater is proposing |
| 2024-05-14 11:50:45 +0200 | <ski> | danse-nr3 : yea, that's basically that one |
| 2024-05-14 11:50:23 +0200 | <ski> | perhaps i'd understand it better, cheater, if you made a simple prototype type checker (and maybe parser, if you wish) |
| 2024-05-14 11:49:59 +0200 | <danse-nr3> | i remember occam's as "the simplest explanation is also the most likely" ... but it is lost in the mists of time. Maybe that was misreferenced |
| 2024-05-14 11:49:14 +0200 | <ski> | "Don't attribute to malice, what can be adequately explained by ignorance/stupidity." |
| 2024-05-14 11:48:51 +0200 | <danse-nr3> | v |
| 2024-05-14 11:48:46 +0200 | <ski> | no, it's not the same thing |
| 2024-05-14 11:48:39 +0200 | <danse-nr3> | huh i knew it as occam's razor... or is it different? |
| 2024-05-14 11:48:24 +0200 | <ski> | i genuienly don't know how you are envisioning this to work |
| 2024-05-14 11:48:02 +0200 | <cheater> | no |
| 2024-05-14 11:47:56 +0200 | <ski> | Hanlon's razor |
| 2024-05-14 11:47:39 +0200 | <cheater> | stop being confused on purpose |
| 2024-05-14 11:47:23 +0200 | <ski> | `x',`y',`z',`a',`b',`c' here are meta-variables, standing for arbitrary expressions. there's no a-priori associatiation of these, to the types `X',`Y',`Z',`A',`B',`C' .. if you mean just actual variable names `x',`y',`z',`a',`b',`c' .. then that's very limited, doesn't scale, isn't really composable |
| 2024-05-14 11:46:27 +0200 | <cheater> | it was all part of the same example |
| 2024-05-14 11:46:10 +0200 | <cheater> | it was an example in the context of what i said before about the type signature |
| 2024-05-14 11:45:53 +0200 | <ski> | not in the application, you did not |
| 2024-05-14 11:45:42 +0200 | <cheater> | i specifically typed out their types ski |
| 2024-05-14 11:45:35 +0200 | <danse-nr3> | still with this stuff? What is wrong with my suggestion to use a product type? |
| 2024-05-14 11:45:23 +0200 | <ski> | what if the types of `x',`y',`z' are the same as the types of `a',`b',`c' (respectively) ? |
| 2024-05-14 11:45:23 +0200 | <cheater> | at that point it's easy to figure out which piece goes in which hole |
| 2024-05-14 11:45:04 +0200 | <cheater> | i'm talking about the fact that most often with functions in haskell you either have arguments that all have different types, or just a small amount amount of arguments of equal types, which can be represented as a tuple (or, uncurried, with -> ) |
| 2024-05-14 11:44:48 +0200 | <cheater> | i'll disagree with that last one |
| 2024-05-14 11:44:25 +0200 | <ski> | (at least not, if you want the language to be sane) |
| 2024-05-14 11:44:05 +0200 | <ski> | (can't reaally provide them, out of order, without labelling them) |
| 2024-05-14 11:43:49 +0200 | <cheater> | yes. not what i'm talking about |
| 2024-05-14 11:43:41 +0200 | <ski> | it's labelled arguments, which you can provide out of order |
| 2024-05-14 11:43:16 +0200 | <cheater> | yeah that's not really what i'm talking about |
| 2024-05-14 11:40:46 +0200 | <ski> | cheater : <https://ocaml.org/manual/5.2/lablexamples.html> |
| 2024-05-14 11:38:23 +0200 | deriamis | (deriamis@ec2-54-187-167-69.us-west-2.compute.amazonaws.com) |
| 2024-05-14 11:38:08 +0200 | deriamis | (deriamis@ec2-54-187-167-69.us-west-2.compute.amazonaws.com) (Quit: ZNC - https://znc.in) |
| 2024-05-14 11:36:04 +0200 | __monty__ | (~toonn@user/toonn) |
| 2024-05-14 11:32:55 +0200 | danse-nr3 | (~danse-nr3@151.43.144.199) |
| 2024-05-14 11:31:50 +0200 | danse-nr3 | (~danse-nr3@151.57.194.120) (Read error: Connection reset by peer) |
| 2024-05-14 11:28:50 +0200 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) |
| 2024-05-14 11:28:33 +0200 | euleritian | (~euleritia@dynamic-176-004-151-001.176.4.pool.telefonica.de) (Read error: Connection reset by peer) |
| 2024-05-14 11:22:01 +0200 | euleritian | (~euleritia@dynamic-176-004-151-001.176.4.pool.telefonica.de) |
| 2024-05-14 11:21:45 +0200 | <hseg> | ah, I assume you mean https://sbuild.org |
| 2024-05-14 11:21:06 +0200 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Ping timeout: 268 seconds) |
| 2024-05-14 11:20:16 +0200 | <hseg> | btw, checking cabal-built ghcid shows such references to build dir |
| 2024-05-14 11:17:57 +0200 | <hseg> | sbuild? |
| 2024-05-14 11:17:33 +0200 | <hseg> | wasn't expecting to get fully reproducible builds in one shot, more trying to get closer to reproducibility |
| 2024-05-14 11:16:39 +0200 | <[exa]> | actually `sbuild` can build haskelly stacky stuff already so might be the case that reuse is easy there |
| 2024-05-14 11:16:18 +0200 | <hseg> | oh, definitely |
| 2024-05-14 11:16:03 +0200 | <[exa]> | hseg: anyway for replroducible builds you might want to have a complete separate clean environment for them, like what debians do with sbuild or so |
| 2024-05-14 11:15:37 +0200 | <[exa]> | hseg: not sure with stack, but I checked a few executables from cabal here and there doesn't seem to be any reference to any local directories |