Logs: liberachat/#haskell
| 2025-10-28 09:10:19 | × | Alex_test_ quits (~al_test@85.174.182.61) (Quit: ;-) |
| 2025-10-28 09:10:33 | × | Googulator57 quits (~Googulato@2a01-036d-0106-03fa-d161-d36f-e0e5-1b0a.pool6.digikabel.hu) (Quit: Client closed) |
| 2025-10-28 09:10:39 | → | Googulator53 joins (~Googulato@2a01-036d-0106-03fa-d161-d36f-e0e5-1b0a.pool6.digikabel.hu) |
| 2025-10-28 09:11:32 | → | jcarpenter2 joins (~lol@96.78.87.197) |
| 2025-10-28 09:18:01 | × | trickard_ quits (~trickard@cpe-55-98-47-163.wireline.com.au) (Read error: Connection reset by peer) |
| 2025-10-28 09:18:14 | → | trickard_ joins (~trickard@cpe-55-98-47-163.wireline.com.au) |
| 2025-10-28 09:21:08 | × | humasect quits (~humasect@dyn-192-249-132-90.nexicom.net) (Remote host closed the connection) |
| 2025-10-28 09:24:53 | → | nerdychip_ joins (~nerdychip@212.129.73.90) |
| 2025-10-28 09:26:12 | × | nerdychip quits (~nerdychip@user/nerdychip) (Ping timeout: 265 seconds) |
| 2025-10-28 09:27:32 | × | kritzefitz quits (~kritzefit@debian/kritzefitz) (Ping timeout: 256 seconds) |
| 2025-10-28 09:29:34 | → | kritzefitz joins (~kritzefit@debian/kritzefitz) |
| 2025-10-28 09:30:39 | → | Googulator70 joins (~Googulato@2a01-036d-0106-03fa-d161-d36f-e0e5-1b0a.pool6.digikabel.hu) |
| 2025-10-28 09:31:24 | × | Googulator53 quits (~Googulato@2a01-036d-0106-03fa-d161-d36f-e0e5-1b0a.pool6.digikabel.hu) (Quit: Client closed) |
| 2025-10-28 09:35:06 | <Square2> | Is it just me or is this definition of https://en.wikipedia.org/wiki/Currying the opposite of haskells curry/uncurry. I suspect the error lies with me. |
| 2025-10-28 09:39:39 | <Square2> | Oh nvm, the haskell wiki explained it to me. |
| 2025-10-28 09:40:25 | <sprout> | yah, it's consistent with the wikipedia page |
| 2025-10-28 09:40:42 | <sprout> | from axb->c to a->b->c |
| 2025-10-28 09:49:06 | → | kuribas joins (~user@ip-188-118-57-242.reverse.destiny.be) |
| 2025-10-28 09:50:40 | → | Googulator34 joins (~Googulato@2a01-036d-0106-03fa-d161-d36f-e0e5-1b0a.pool6.digikabel.hu) |
| 2025-10-28 09:50:43 | × | Googulator70 quits (~Googulato@2a01-036d-0106-03fa-d161-d36f-e0e5-1b0a.pool6.digikabel.hu) (Quit: Client closed) |
| 2025-10-28 10:07:28 | trickard_ | is now known as trickard |
| 2025-10-28 10:10:44 | → | Googulator20 joins (~Googulato@2a01-036d-0106-03fa-d161-d36f-e0e5-1b0a.pool6.digikabel.hu) |
| 2025-10-28 10:10:44 | × | Googulator34 quits (~Googulato@2a01-036d-0106-03fa-d161-d36f-e0e5-1b0a.pool6.digikabel.hu) (Quit: Client closed) |
| 2025-10-28 10:19:56 | <tomsmeding> | is there a way to tell ghc to don't raise an unused binding warning for one specific function? |
| 2025-10-28 10:20:05 | <tomsmeding> | perhaps some "unused" pragma? |
| 2025-10-28 10:21:08 | <sshine> | tomsmeding, it seems there's only CLI params |
| 2025-10-28 10:21:24 | <haskellbridge> | <Morj> Ah yes, rust pragmas have also spoilt me |
| 2025-10-28 10:21:33 | <sshine> | no #[allow(...)] equivalent |
| 2025-10-28 10:21:58 | <haskellbridge> | <Morj> For unused variables, can't you just use it vacuously? Like in a "const" somewhere ekse |
| 2025-10-28 10:22:24 | <srazkvt> | that's kind of ugly though |
| 2025-10-28 10:22:59 | <haskellbridge> | <Morj> Back in C++ we would "(void*)the_var" that shit |
| 2025-10-28 10:25:19 | <mauke> | named it with an underscore? |
| 2025-10-28 10:25:31 | <mauke> | s/d\b// |
| 2025-10-28 10:25:52 | <kuribas> | tomsmeding: use underscore? |
| 2025-10-28 10:26:07 | <kuribas> | _foo |
| 2025-10-28 10:26:07 | <tomsmeding> | oooh |
| 2025-10-28 10:26:09 | <tomsmeding> | that works! |
| 2025-10-28 10:26:14 | <tomsmeding> | thank you mauke kuribas |
| 2025-10-28 10:26:19 | <srazkvt> | Morj: void* ? you sure not just void ? at least in c we just do void |
| 2025-10-28 10:26:29 | <tomsmeding> | definitely (void) |
| 2025-10-28 10:27:03 | <tomsmeding> | though with modern (?) compilers you can __attribute__((unused)) |
| 2025-10-28 10:27:10 | <tomsmeding> | which IMO is neater than (void)'ing it somewhere |
| 2025-10-28 10:27:16 | <mauke> | s/modern/gcc/ |
| 2025-10-28 10:27:20 | <tomsmeding> | clang does that finew |
| 2025-10-28 10:27:23 | <kuribas> | (void*) is unsafecast |
| 2025-10-28 10:27:24 | <tomsmeding> | s/w// |
| 2025-10-28 10:27:34 | <mauke> | s/gcc/gcc and imitators/ |
| 2025-10-28 10:27:45 | <tomsmeding> | kuribas: yes which makes no sense and may well be rejected by the compiler if the thing is not a scalar in the first place, such as a struct |
| 2025-10-28 10:27:47 | <tomsmeding> | mauke: ah |
| 2025-10-28 10:28:27 | <tomsmeding> | mauke: is __attribute__ in general syntax that is parsed by other compilers, even if not this particular 'unused' attribute? |
| 2025-10-28 10:28:39 | <kuribas> | tomsmeding: does C distinguis between scalar and compound? I thought it's just all addresses for C. |
| 2025-10-28 10:28:40 | <tomsmeding> | because if this is just warning management, I wouldn't care so much about proper cross-compiler compatibility |
| 2025-10-28 10:28:50 | <mauke> | AFAIK __attribute__ is a GNU invention |
| 2025-10-28 10:28:54 | <tomsmeding> | kuribas: C distinguishes very much between values and pointers |
| 2025-10-28 10:29:05 | <tomsmeding> | pointers are just scalars, but structs are not scalars |
| 2025-10-28 10:29:20 | <mauke> | because they didn't like #pragma because you can't generate it from a macro |
| 2025-10-28 10:29:39 | <kuribas> | tomsmeding: you can convert pointer to int, no? |
| 2025-10-28 10:29:40 | <tomsmeding> | kuribas: `error: cannot convert to a pointer type` |
| 2025-10-28 10:29:48 | <tomsmeding> | yes but you cannot convert a struct to an int |
| 2025-10-28 10:30:11 | <kuribas> | tomsmeding: what if you cast the pointer, then back? |
| 2025-10-28 10:30:15 | <tomsmeding> | mauke: ah I see -- a viewpoint that I agree with, by the way, though that's beside the point here |
| 2025-10-28 10:30:47 | <mauke> | tomsmeding: maybe intel cc (is that still a thing?) might support it |
| 2025-10-28 10:30:48 | <kuribas> | (int *(int*)(&my_struct)) or something... |
| 2025-10-28 10:31:08 | <tomsmeding> | lol ok yeah |
| 2025-10-28 10:31:14 | <srazkvt> | icc is still a thing, but i don't know of anyone who uses it |
| 2025-10-28 10:31:24 | <tomsmeding> | you can just &my_struct; if you want |
| 2025-10-28 10:31:47 | <tomsmeding> | I guess (void)&my_struct; |
| 2025-10-28 10:32:01 | <haskellbridge> | <Morj> srazkvt: Yeah you're right, I was misremembering. In any case, for the last how many years of C++ for me it was Q_UNUSED(thevar) |
| 2025-10-28 10:32:29 | <srazkvt> | yea i usually make it a macro too |
| 2025-10-28 10:34:05 | → | Frostillicus joins (~Frostilli@pool-71-174-119-69.bstnma.fios.verizon.net) |
| 2025-10-28 10:35:44 | → | Googulator70 joins (~Googulato@2a01-036d-0106-03fa-d161-d36f-e0e5-1b0a.pool6.digikabel.hu) |
| 2025-10-28 10:35:45 | × | Googulator20 quits (~Googulato@2a01-036d-0106-03fa-d161-d36f-e0e5-1b0a.pool6.digikabel.hu) (Quit: Client closed) |
| 2025-10-28 10:37:39 | AlexNoo_ | is now known as AlexNoo |
| 2025-10-28 10:38:33 | → | humasect joins (~humasect@dyn-192-249-132-90.nexicom.net) |
| 2025-10-28 10:43:07 | × | humasect quits (~humasect@dyn-192-249-132-90.nexicom.net) (Ping timeout: 246 seconds) |
| 2025-10-28 10:43:15 | → | __monty__ joins (~toonn@user/toonn) |
| 2025-10-28 10:46:02 | → | Googulator49 joins (~Googulato@2a01-036d-0106-03fa-d161-d36f-e0e5-1b0a.pool6.digikabel.hu) |
| 2025-10-28 10:46:16 | × | Googulator70 quits (~Googulato@2a01-036d-0106-03fa-d161-d36f-e0e5-1b0a.pool6.digikabel.hu) (Quit: Client closed) |
| 2025-10-28 10:47:34 | <kuribas> | Why does always the argument that you can implement the wrong business logic comes up when talking about formal languages? In my experience, the majority of bugs (in those languages) or not business logic related. |
| 2025-10-28 10:48:35 | <kuribas> | Also, if the code reflects the business logic cleanly, it's easier to change when required, rather than have an dynamic, spagetty mess of imperative side-effects. |
| 2025-10-28 10:48:55 | × | xff0x quits (~xff0x@fsb6a9491c.tkyc517.ap.nuro.jp) (Ping timeout: 264 seconds) |
| 2025-10-28 10:49:18 | <kuribas> | Of course, full on formal verification can be a huge time wast if you implement the wrong business logic. |
| 2025-10-28 10:49:59 | <kuribas> | But I find static types a nice middle ground, usually not a huge extra effort. |
| 2025-10-28 10:51:02 | <__monty__> | I do think it's fair to say the most impactful bugs are ones in the logic as implemented. The if statement that didn't actually guard its body comes to mind, was that Apple or Heartbleed? |
| 2025-10-28 10:52:01 | <__monty__> | That doesn't mean that I'm willing to waste time tracing through a dynamic OOP codebase to figure out where a number is being passed rather than a string. |
| 2025-10-28 10:52:32 | <mauke> | that was "goto fail" |
| 2025-10-28 10:52:33 | <__monty__> | But for some changing code and the type feels like too big a waste of time, I suppose. |
| 2025-10-28 10:54:59 | → | Pixi` joins (~Pixi@user/pixi) |
| 2025-10-28 10:58:13 | × | Pixi quits (~Pixi@user/pixi) (Ping timeout: 264 seconds) |
| 2025-10-28 11:00:17 | × | srazkvt quits (~sarah@user/srazkvt) (Read error: Connection reset by peer) |
| 2025-10-28 11:11:58 | <kuribas> | __monty__: word |
| 2025-10-28 11:13:06 | <kuribas> | IMO types also help greatly with understanding a codebase better. |
| 2025-10-28 11:13:12 | <kuribas> | Especially if you have a good IDE. |
| 2025-10-28 11:16:22 | × | Frostillicus quits (~Frostilli@pool-71-174-119-69.bstnma.fios.verizon.net) (Ping timeout: 246 seconds) |
| 2025-10-28 11:18:14 | → | Frostillicus joins (~Frostilli@pool-71-174-119-69.bstnma.fios.verizon.net) |
| 2025-10-28 11:23:44 | × | trickard quits (~trickard@cpe-55-98-47-163.wireline.com.au) (Read error: Connection reset by peer) |
| 2025-10-28 11:23:57 | → | trickard_ joins (~trickard@cpe-55-98-47-163.wireline.com.au) |
| 2025-10-28 11:25:53 | × | poscat0x04 quits (~poscat@user/poscat) (Remote host closed the connection) |
| 2025-10-28 11:26:59 | → | Zemy_ joins (~Zemy@2600:100c:b0a5:5276:b418:b7ff:fead:8324) |
| 2025-10-28 11:26:59 | × | Zemy quits (~Zemy@72.178.108.235) (Read error: Connection reset by peer) |
All times are in UTC.