Newest at the top
| 2026-02-27 15:00:57 +0100 | tydes | (~tydes@user/ttydes) ttydes |
| 2026-02-27 14:57:44 +0100 | bggd_ | (~bgg@2a01:e0a:fd5:f510:f2e9:bf08:81c5:a9a2) |
| 2026-02-27 14:48:30 +0100 | rekahsoft | (~rekahsoft@76.67.111.168) rekahsoft |
| 2026-02-27 14:41:45 +0100 | lbseale | (~quassel@user/ep1ctetus) (Client Quit) |
| 2026-02-27 14:37:59 +0100 | lbseale | (~quassel@user/ep1ctetus) ep1ctetus |
| 2026-02-27 14:30:58 +0100 | tales | (~tales@149.167.1.176) (Ping timeout: 248 seconds) |
| 2026-02-27 14:26:38 +0100 | tales | (~tales@149.167.1.176) |
| 2026-02-27 14:11:30 +0100 | haritz | (~hrtz@user/haritz) haritz |
| 2026-02-27 14:11:30 +0100 | haritz | (~hrtz@140.228.70.141) (Changing host) |
| 2026-02-27 14:11:30 +0100 | haritz | (~hrtz@140.228.70.141) |
| 2026-02-27 14:09:20 +0100 | housemate | (~housemate@202.7.248.67) housemate |
| 2026-02-27 13:45:30 +0100 | causal | (~eric@50.46.156.145) (Quit: WeeChat 4.8.1) |
| 2026-02-27 13:41:40 +0100 | natto17 | (~natto@129.154.243.159) natto |
| 2026-02-27 13:41:32 +0100 | divya | (divya@140.238.251.170) divya |
| 2026-02-27 13:39:38 +0100 | gmg | (~user@user/gehmehgeh) gehmehgeh |
| 2026-02-27 13:39:24 +0100 | Enrico63 | (~Enrico63@host-80-104-109-187.retail.telecomitalia.it) Enrico63 |
| 2026-02-27 13:39:21 +0100 | misterfish | (~misterfis@84.53.85.146) misterfish |
| 2026-02-27 13:38:13 +0100 | Vajb | (~Vajb@2001:999:38:a1b6:95aa:8c38:ae41:ec93) |
| 2026-02-27 13:37:24 +0100 | gmg | (~user@user/gehmehgeh) (Ping timeout: 258 seconds) |
| 2026-02-27 13:36:39 +0100 | p3n | (~p3n@2a00:19a0:3:7c:0:d9c6:7cf6:1) p3n |
| 2026-02-27 13:34:02 +0100 | p3n | (~p3n@2a00:19a0:3:7c:0:d9c6:7cf6:1) (Quit: ZNC 1.10.1 - https://znc.in) |
| 2026-02-27 13:23:14 +0100 | misterfish | (~misterfis@046044172198.static.ipv4.heldenvannu.net) (Ping timeout: 245 seconds) |
| 2026-02-27 13:22:30 +0100 | natto17 | (~natto@129.154.243.159) (Ping timeout: 246 seconds) |
| 2026-02-27 13:21:59 +0100 | divya | (divya@140.238.251.170) (Ping timeout: 265 seconds) |
| 2026-02-27 13:13:45 +0100 | xff0x | (~xff0x@2405:6580:b080:900:3713:5717:d067:11de) |
| 2026-02-27 13:08:51 +0100 | tales | (~tales@149.167.1.176) (Ping timeout: 246 seconds) |
| 2026-02-27 13:02:50 +0100 | kuribas | (~user@2a02-1810-2825-6000-1a76-6371-2ebf-5f1e.ip6.access.telenet.be) kuribas |
| 2026-02-27 13:00:29 +0100 | tales | (~tales@149.167.1.176) |
| 2026-02-27 12:53:54 +0100 | causal | (~eric@50.46.156.145) causal |
| 2026-02-27 12:43:29 +0100 | <ski> | np |
| 2026-02-27 12:43:24 +0100 | wootehfoot | (~wootehfoo@user/wootehfoot) wootehfoot |
| 2026-02-27 12:42:10 +0100 | tales | (~tales@149.167.1.176) (Ping timeout: 248 seconds) |
| 2026-02-27 12:41:25 +0100 | <gentauro> | ski: I think I got. Thx |
| 2026-02-27 12:37:41 +0100 | tales | (~tales@149.167.1.176) |
| 2026-02-27 12:36:14 +0100 | <ski> | or the difference between `forall a. ([a] -> Int)' (caller picks `a', passes as input some list of `a's) and (the rank-2 type) `(forall a. [a]) -> Int' (callee picks which type `a' to use, caller must pass a polymorphic parameter .. which in this case means only the empty list, if we discount partial values) |
| 2026-02-27 12:34:30 +0100 | <ski> | it's the same kind of difference as between `T -> (U -> V)' (`T' and `U' are input, `V' is output) and `(T -> U) -> V' (`T' is output, back to the callback, which produces the input `U', and `V' is output) |
| 2026-02-27 12:32:49 +0100 | <ski> | gentauro : in any case, `Cxt => (... -> ...)' is very different from `(Cxt => ...) -> ...'. in the former, evidence for `Cxt' is provided by the caller/user/consumer of the value (of this type); while in the latter, evidence for `Cxt' is provided by the callee/implementor/producer of the value |
| 2026-02-27 12:30:28 +0100 | <ski> | while, the second `foobar' is : caller picks two types `a' and `b', and passes two callbackss working on them. *caller* also will pick and provide instances `Foo a' and `Bar b' (which should then be easier, given that caller picked `a' and `b', presumably knows more about them) |
| 2026-02-27 12:28:57 +0100 | <ski> | occurs in `FooBar'), so that by learning more about `a' and `b', `foobar' can manage to provide the `Foo' and `Bar' instances to the callbacks) |
| 2026-02-27 12:28:51 +0100 | <ski> | (which seems to only make sense if either (a) those two callbacks will never be used; or (b) both `Foo' and `Bar' have a generic instance, working for all types; or (c) `FooBar' actually mentions `a' and `b', including being provided evidence for some instance(s) relating to `a' and `b', from which `Foo a' and `Bar b' can be derived; or (d) there's some GADT-matching going on (still asssuming `a' and `b' |
| 2026-02-27 12:27:15 +0100 | tales | (~tales@149.167.1.176) (Ping timeout: 245 seconds) |
| 2026-02-27 12:27:04 +0100 | rainbyte | (~rainbyte@186.22.19.214) rainbyte |
| 2026-02-27 12:26:40 +0100 | rainbyte | (~rainbyte@186.22.19.214) (Remote host closed the connection) |
| 2026-02-27 12:24:02 +0100 | <ski> | the first `foobar' is : caller picks two types `a' and `b', and passes two callbacks working on them. callee will pick instances `Foo a' and `Bar b' for those caller-chosen types |
| 2026-02-27 12:20:06 +0100 | APic | (apic@apic.name) APic |
| 2026-02-27 12:19:14 +0100 | APic | (apic@apic.name) (Ping timeout: 248 seconds) |
| 2026-02-27 12:18:58 +0100 | Enrico63 | (~Enrico63@host-80-104-109-187.retail.telecomitalia.it) (Ping timeout: 240 seconds) |
| 2026-02-27 12:18:45 +0100 | <lambdabot> | 2 |
| 2026-02-27 12:18:44 +0100 | <ski> | > let foo :: (Ord a => a -> a -> Bool) -> (Num a => a -> a) -> (Integral a => a -> a -> a); foo f g x y = if f x y then g x else y `mod` x in foo (>=) negate 3 8 |
| 2026-02-27 12:18:11 +0100 | <mauke> | depends on whether you want to apply those callbacks at different types |