| 2024-02-07 00:01:13 +0100 | dibblego | (~dibblego@haskell/developer/dibblego) |
| 2024-02-07 00:02:40 +0100 | mobivme | (~mobivme@130.105.162.31) |
| 2024-02-07 00:03:07 +0100 | average | (uid473595@user/average) |
| 2024-02-07 00:12:21 +0100 | jargon | (~jargon@123.sub-174-205-225.myvzw.com) |
| 2024-02-07 00:20:37 +0100 | tri | (~tri@ool-18bbef1a.static.optonline.net) |
| 2024-02-07 00:20:51 +0100 | tri | (~tri@ool-18bbef1a.static.optonline.net) (Remote host closed the connection) |
| 2024-02-07 00:23:21 +0100 | alexherbo2 | (~alexherbo@2a02-8440-3440-d7d5-14d1-65d1-7cb0-0517.rev.sfr.net) (Remote host closed the connection) |
| 2024-02-07 00:27:55 +0100 | berberman | (~berberman@user/berberman) (Quit: ZNC 1.8.2 - https://znc.in) |
| 2024-02-07 00:28:07 +0100 | berberman | (~berberman@user/berberman) |
| 2024-02-07 00:28:14 +0100 | justsomeguy | (~justsomeg@user/justsomeguy) (Quit: WeeChat 3.6) |
| 2024-02-07 00:29:30 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2024-02-07 00:32:24 +0100 | Unode | (~Unode@fg-ext-220.embl.de) (Ping timeout: 256 seconds) |
| 2024-02-07 00:34:35 +0100 | JordiGH | (~jordi@user/jordigh) |
| 2024-02-07 00:36:49 +0100 | azimut | (~azimut@gateway/tor-sasl/azimut) |
| 2024-02-07 00:43:47 +0100 | mobivme | (~mobivme@130.105.162.31) (Ping timeout: 264 seconds) |
| 2024-02-07 00:44:54 +0100 | mobivme | (~mobivme@130.105.162.31) |
| 2024-02-07 00:47:54 +0100 | gehmehgeh | (~user@user/gehmehgeh) (Quit: Leaving) |
| 2024-02-07 00:51:11 +0100 | mobivme | (~mobivme@130.105.162.31) (Changing host) |
| 2024-02-07 00:51:11 +0100 | mobivme | (~mobivme@user/mobivme) |
| 2024-02-07 00:51:34 +0100 | <Axman6> | sm: <3 |
| 2024-02-07 00:57:11 +0100 | mechap | (~mechap@user/mechap) (Ping timeout: 252 seconds) |
| 2024-02-07 00:59:13 +0100 | mechap | (~mechap@user/mechap) |
| 2024-02-07 01:01:24 +0100 | peterbecich | (~Thunderbi@047-229-123-186.res.spectrum.com) |
| 2024-02-07 01:04:13 +0100 | xigua | (~xigua@user/xigua) (Read error: Connection reset by peer) |
| 2024-02-07 01:04:19 +0100 | Sgeo | (~Sgeo@user/sgeo) |
| 2024-02-07 01:04:28 +0100 | xigua | (~xigua@user/xigua) |
| 2024-02-07 01:05:23 +0100 | rvalue | (~rvalue@user/rvalue) (Ping timeout: 264 seconds) |
| 2024-02-07 01:05:47 +0100 | mobivme | (~mobivme@user/mobivme) (Ping timeout: 260 seconds) |
| 2024-02-07 01:11:25 +0100 | jmdaemon | (~jmdaemon@user/jmdaemon) |
| 2024-02-07 01:15:21 +0100 | rvalue | (~rvalue@user/rvalue) |
| 2024-02-07 01:24:37 +0100 | peterbecich | (~Thunderbi@047-229-123-186.res.spectrum.com) (Ping timeout: 260 seconds) |
| 2024-02-07 01:45:41 +0100 | Lycurgus | (~georg@user/Lycurgus) |
| 2024-02-07 01:50:08 +0100 | peterbecich | (~Thunderbi@047-229-123-186.res.spectrum.com) |
| 2024-02-07 01:55:24 +0100 | Erutuon | (~Erutuon@user/erutuon) |
| 2024-02-07 02:05:33 +0100 | Tuplanolla | (~Tuplanoll@91-159-68-95.elisa-laajakaista.fi) (Quit: Leaving.) |
| 2024-02-07 02:09:01 +0100 | xff0x | (~xff0x@2405:6580:b080:900:5fca:dd8c:766e:9634) (Ping timeout: 272 seconds) |
| 2024-02-07 02:10:53 +0100 | mmhat | (~mmh@p200300f1c7032843ee086bfffe095315.dip0.t-ipconnect.de) (Quit: WeeChat 4.2.1) |
| 2024-02-07 02:12:09 +0100 | santiagopim | (~user@90.167.66.131) (Ping timeout: 268 seconds) |
| 2024-02-07 02:41:57 +0100 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) (Ping timeout: 272 seconds) |
| 2024-02-07 02:43:02 +0100 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) |
| 2024-02-07 02:47:17 +0100 | Katarushisu1 | (~Katarushi@finc-20-b2-v4wan-169598-cust1799.vm7.cable.virginm.net) (Ping timeout: 240 seconds) |
| 2024-02-07 02:55:27 +0100 | evj | (~evj@user/evj) (Ping timeout: 260 seconds) |
| 2024-02-07 02:56:01 +0100 | Unicorn_Princess | (~Unicorn_P@user/Unicorn-Princess/x-3540542) (Quit: Leaving) |
| 2024-02-07 02:56:57 +0100 | xff0x | (~xff0x@125x103x176x34.ap125.ftth.ucom.ne.jp) |
| 2024-02-07 03:00:47 +0100 | Katarushisu1 | (~Katarushi@finc-20-b2-v4wan-169598-cust1799.vm7.cable.virginm.net) |
| 2024-02-07 03:03:57 +0100 | pointlessslippe1 | (~pointless@212.82.82.3) (Ping timeout: 268 seconds) |
| 2024-02-07 03:08:16 +0100 | jmdaemon | (~jmdaemon@user/jmdaemon) (Ping timeout: 255 seconds) |
| 2024-02-07 03:10:01 +0100 | mima | (~mmh@aftr-62-216-211-178.dynamic.mnet-online.de) (Ping timeout: 256 seconds) |
| 2024-02-07 03:17:20 +0100 | Unode | (~Unode@fg-ext-220.embl.de) |
| 2024-02-07 03:17:55 +0100 | jmdaemon | (~jmdaemon@user/jmdaemon) |
| 2024-02-07 03:19:38 +0100 | machinedgod | (~machinedg@d173-183-246-216.abhsia.telus.net) (Ping timeout: 252 seconds) |
| 2024-02-07 03:23:45 +0100 | otto_s | (~user@p5b044c4b.dip0.t-ipconnect.de) (Ping timeout: 272 seconds) |
| 2024-02-07 03:24:23 +0100 | Unode | (~Unode@fg-ext-220.embl.de) (Ping timeout: 260 seconds) |
| 2024-02-07 03:25:19 +0100 | otto_s | (~user@p5b04467e.dip0.t-ipconnect.de) |
| 2024-02-07 03:28:39 +0100 | Unode | (~Unode@fg-ext-220.embl.de) |
| 2024-02-07 03:30:13 +0100 | jmdaemon | (~jmdaemon@user/jmdaemon) (Quit: ZNC 1.8.2 - https://znc.in) |
| 2024-02-07 03:30:33 +0100 | jmdaemon | (~jmdaemon@user/jmdaemon) |
| 2024-02-07 03:34:07 +0100 | TonyStone | (~TonyStone@074-076-057-186.res.spectrum.com) |
| 2024-02-07 03:37:41 +0100 | jmdaemon | (~jmdaemon@user/jmdaemon) (Ping timeout: 272 seconds) |
| 2024-02-07 03:54:47 +0100 | mechap | (~mechap@user/mechap) (Ping timeout: 272 seconds) |
| 2024-02-07 03:56:32 +0100 | mechap | (~mechap@user/mechap) |
| 2024-02-07 04:02:20 +0100 | petrichor | (~znc-user@user/petrichor) (Quit: ZNC 1.8.2 - https://znc.in) |
| 2024-02-07 04:03:15 +0100 | petrichor | (~znc-user@user/petrichor) |
| 2024-02-07 04:15:41 +0100 | waleee | (~waleee@h-176-10-144-38.NA.cust.bahnhof.se) (Ping timeout: 272 seconds) |
| 2024-02-07 04:16:42 +0100 | <energizer> | is there an absorber/annihilator for ++, i.e. an element z such that z ++ a == z for all a? |
| 2024-02-07 04:18:54 +0100 | <geekosaur> | no |
| 2024-02-07 04:19:38 +0100 | <jle`> | i guess depending on the type of value, you could have `repeat x`, if you define == as equational reasoning based equality instead of haskell's (==) |
| 2024-02-07 04:20:16 +0100 | <jle`> | hm, maybe any infinite list counts? |
| 2024-02-07 04:21:20 +0100 | <jle`> | for any terminating function f, f (z ++ a) == f z, if z is an infinite list. |
| 2024-02-07 04:22:27 +0100 | bilegeek | (~bilegeek@2600:1008:b04f:fcf5:b540:c75e:140b:eceb) |
| 2024-02-07 04:22:42 +0100 | <energizer> | what about f = last |
| 2024-02-07 04:23:05 +0100 | <jle`> | in that case it wouldn't terminate |
| 2024-02-07 04:24:28 +0100 | <jle`> | for all f, if f z terminates, then f z == f (z ++ a) |
| 2024-02-07 04:25:08 +0100 | <jle`> | which is some type of extensional equality maybe? |
| 2024-02-07 04:27:18 +0100 | jargon | (~jargon@123.sub-174-205-225.myvzw.com) (Remote host closed the connection) |
| 2024-02-07 04:36:29 +0100 | waleee | (~waleee@h-176-10-144-38.NA.cust.bahnhof.se) |
| 2024-02-07 04:37:49 +0100 | td_ | (~td@i53870914.versanet.de) (Ping timeout: 255 seconds) |
| 2024-02-07 04:37:59 +0100 | fansly | (~fansly@2001:448a:2010:476e:5df1:ad02:fa1f:3df1) |
| 2024-02-07 04:39:25 +0100 | td_ | (~td@i53870927.versanet.de) |
| 2024-02-07 04:44:34 +0100 | peterbecich | (~Thunderbi@047-229-123-186.res.spectrum.com) (Ping timeout: 255 seconds) |
| 2024-02-07 04:51:13 +0100 | igemnace | (~ian@user/igemnace) |
| 2024-02-07 04:57:00 +0100 | <mauke> | if f z doesn't terminate, then neither does f (z ++ a) :-) |
| 2024-02-07 05:01:22 +0100 | <ski> | people shouldn't say `==', when they mean a semantic equality |
| 2024-02-07 05:02:40 +0100 | <monochrom> | Right. |
| 2024-02-07 05:03:32 +0100 | <monochrom> | But programmers know only programming languages, not the richer language of mathematical semantics. |
| 2024-02-07 05:03:47 +0100 | <monochrom> | Much less the even richer language of formal specifications. |
| 2024-02-07 05:05:38 +0100 | tri | (~tri@2607:fb90:b189:8360:6dd2:e988:8f60:bbe5) |
| 2024-02-07 05:07:01 +0100 | <energizer> | huh? |
| 2024-02-07 05:07:29 +0100 | <monochrom> | QED >:) |
| 2024-02-07 05:07:50 +0100 | <energizer> | no, in a programming forum == is the predicate; = is assignment |
| 2024-02-07 05:08:15 +0100 | <monochrom> | And what would you use for mathematical equality? |
| 2024-02-07 05:08:53 +0100 | <monochrom> | Or do you instead opine that there is no need, therefore more proof for my point? |
| 2024-02-07 05:08:59 +0100 | <energizer> | if i were in a forum that supports that concept, like math or #lean, then i would use = |
| 2024-02-07 05:09:25 +0100 | <monochrom> | This channel does support that concept. All the time. |
| 2024-02-07 05:09:28 +0100 | <ski> | saying `repeat x = x : repeat x' is an example of such an equality. if you specifcally do not mean "checking equality" (being `=='), then it'd be better to write `=', to avoid confusion with that (see the stuff about termination above). if you want to be more specific, like rewritability in an operational semantics; or perhaps observable equality based on that, quantifying over all possible contexts yielding |
| 2024-02-07 05:09:34 +0100 | <ski> | a result in an "observable type", or if you mean a denotational semantics, or axiomatic semantics, that's fine. but just distinguishing from "checking equality" would go a long way |
| 2024-02-07 05:09:46 +0100 | <ski> | energizer : there is no assignment in Haskell |
| 2024-02-07 05:10:37 +0100 | <mauke> | unless you're at uni |
| 2024-02-07 05:10:51 +0100 | <mauke> | then there are many assignments in haskell :-( |
| 2024-02-07 05:10:51 +0100 | fansly | (~fansly@2001:448a:2010:476e:5df1:ad02:fa1f:3df1) (Read error: Connection reset by peer) |
| 2024-02-07 05:11:07 +0100 | <monochrom> | Heh, in uni, assignments are denoted by the symbol "A", e.g., "A1", "A2". >:) |
| 2024-02-07 05:11:13 +0100 | <ski> | well, i'd agree with the plural, i guess |
| 2024-02-07 05:11:40 +0100 | <monochrom> | My colleague says "Exercise 2" instead. >:) |
| 2024-02-07 05:11:51 +0100 | <ski> | the gall |
| 2024-02-07 05:11:52 +0100 | <monochrom> | (I think it's for an unrelated reason.) |
| 2024-02-07 05:12:49 +0100 | <mauke> | execute assignment #66 |
| 2024-02-07 05:13:07 +0100 | ski | . o O ( "Off with her head!" ) |
| 2024-02-07 05:14:07 +0100 | rekahsoft | (~rekahsoft@70.51.99.248) (Ping timeout: 246 seconds) |
| 2024-02-07 05:15:51 +0100 | <ski> | energizer : "in a programming forum == is the predicate" -- the problem is, there's at least two different notions of "predicate" here. there's boolean-valued ("computable", iow decidable) predicate. and there's truth-valued (potentially provable) predicate |
| 2024-02-07 05:16:35 +0100 | <ski> | the first computes a bit. the second computes a proposition |
| 2024-02-07 05:16:57 +0100 | Lycurgus | (~georg@user/Lycurgus) (Quit: leaving) |
| 2024-02-07 05:17:58 +0100 | moixa | (~moixa@customer-178-16-208-85.stosn.net) (Ping timeout: 264 seconds) |
| 2024-02-07 05:20:36 +0100 | <monochrom> | But let's have even more fun. |
| 2024-02-07 05:21:15 +0100 | <monochrom> | Even within the computable, Java has == and equal(), and makes a point to warning beginners "== is not what you think". |
| 2024-02-07 05:21:54 +0100 | <monochrom> | Not to be undone, Lisp predates that by 40 years with eq?, eqv?, and equal? |
| 2024-02-07 05:21:54 +0100 | <jle`> | mauke: right, but that's the most boring case to think about :) |
| 2024-02-07 05:22:00 +0100 | <monochrom> | s/undone/outdone/ |
| 2024-02-07 05:24:32 +0100 | fansly | (~fansly@2001:448a:2010:476e:5df1:ad02:fa1f:3df1) |
| 2024-02-07 05:24:57 +0100 | tri_ | (~tri@2607:fb90:b189:8360:1450:cf3a:2c14:a8bb) |
| 2024-02-07 05:28:09 +0100 | tri | (~tri@2607:fb90:b189:8360:6dd2:e988:8f60:bbe5) (Ping timeout: 256 seconds) |
| 2024-02-07 05:28:30 +0100 | <mauke> | common lisp: eq, eql, equal, equalp, =, string=, string-equal, char=, char-equal |
| 2024-02-07 05:29:58 +0100 | <ski> | yea, that's Scheme. CL and ELisp don't quite use those names |
| 2024-02-07 05:30:05 +0100 | waleee | (~waleee@h-176-10-144-38.NA.cust.bahnhof.se) (Ping timeout: 240 seconds) |
| 2024-02-07 05:30:11 +0100 | <mauke> | oops, forgot about tree-equal |
| 2024-02-07 05:30:21 +0100 | <monochrom> | \∩/ |
| 2024-02-07 05:30:25 +0100 | JordiGH | (~jordi@user/jordigh) (Ping timeout: 272 seconds) |
| 2024-02-07 05:30:40 +0100 | <ski> | (i guess it does use `string=') |
| 2024-02-07 05:32:50 +0100 | <mauke> | this is why I like perl. it supports both kinds of equality, == and eq |
| 2024-02-07 05:34:12 +0100 | <energizer> | i always liked pyret's equal-now and equal-always predicates https://pyret.org/docs/latest/equality.html |
| 2024-02-07 05:34:37 +0100 | ski | . o O ( `equal-eventually' ) |
| 2024-02-07 05:35:12 +0100 | <energizer> | equal-with-probability-1 |
| 2024-02-07 05:36:18 +0100 | <ski> | (.. define an equivalence relation over infinite sequences, expressing that they eventually agree forever) |
| 2024-02-07 05:37:25 +0100 | TonyStone | (~TonyStone@074-076-057-186.res.spectrum.com) (Quit: Leaving) |
| 2024-02-07 05:40:13 +0100 | <monochrom> | At that point, you may be interested in parametrizing equality by a general LTL formula :) |
| 2024-02-07 05:42:45 +0100 | <ski> | or CTL, i guess .. |
| 2024-02-07 05:43:27 +0100 | <tri_> | hi, im looking into event-driven programming in haskell. My idea is to have the main thread runs forever, meanwhile there is a thread that listens for event, say from AWS SQS. On receiving an event, depending on a value, say a string property, i will pattern match on a handler. |
| 2024-02-07 05:44:09 +0100 | <tri_> | i saw the library reactive-banana is an event handler, is that the go-to library for event-drivent programming? |
| 2024-02-07 05:47:15 +0100 | <tri_> | in C#, there is the event handler concept, but im not sure it exist in Haskell. I feel like in Haskell, i should use the pipe and conduit library to stream event, which is similar to the Reactive libraries in other langauges, like RxJava, Rx.NET, RxJS,... |
| 2024-02-07 05:47:20 +0100 | <tri_> | is my thought correct? |
| 2024-02-07 05:48:11 +0100 | <tri_> | i gotta go grab a drink, so i may not be able to get back to any answer in a bit |
| 2024-02-07 05:48:13 +0100 | <tri_> | thank you |
| 2024-02-07 05:49:54 +0100 | igemnace | (~ian@user/igemnace) (Read error: Connection reset by peer) |
| 2024-02-07 05:53:12 +0100 | aforemny_ | (~aforemny@2001:9e8:6cca:5a00:54df:9782:a471:5c99) |
| 2024-02-07 05:54:29 +0100 | aforemny | (~aforemny@2001:9e8:6ce5:8100:8057:709d:76c5:eec) (Ping timeout: 272 seconds) |
| 2024-02-07 06:11:26 +0100 | chexum | (~quassel@gateway/tor-sasl/chexum) (Remote host closed the connection) |
| 2024-02-07 06:11:58 +0100 | chexum | (~quassel@gateway/tor-sasl/chexum) |
| 2024-02-07 06:16:01 +0100 | tomku | (~tomku@user/tomku) (Quit: Lost terminal) |
| 2024-02-07 06:19:49 +0100 | fansly | (~fansly@2001:448a:2010:476e:5df1:ad02:fa1f:3df1) (Ping timeout: 272 seconds) |
| 2024-02-07 06:20:37 +0100 | Erutuon | (~Erutuon@user/erutuon) (Ping timeout: 246 seconds) |
| 2024-02-07 06:24:49 +0100 | fansly | (~fansly@103.3.221.233) |
| 2024-02-07 06:40:30 +0100 | peterbecich | (~Thunderbi@047-229-123-186.res.spectrum.com) |
| 2024-02-07 06:45:25 +0100 | fansly | (~fansly@103.3.221.233) (Read error: Connection reset by peer) |
| 2024-02-07 06:46:40 +0100 | fansly | (~fansly@103.3.221.233) |
| 2024-02-07 06:52:12 +0100 | igemnace | (~ian@user/igemnace) |
| 2024-02-07 06:53:27 +0100 | fansly | (~fansly@103.3.221.233) (Ping timeout: 260 seconds) |
| 2024-02-07 06:54:17 +0100 | fansly | (~fansly@2001:448a:2010:476e:5df1:ad02:fa1f:3df1) |
| 2024-02-07 07:00:17 +0100 | _ht | (~Thunderbi@28-52-174-82.ftth.glasoperator.nl) |
| 2024-02-07 07:05:59 +0100 | mei | (~mei@user/mei) (Remote host closed the connection) |
| 2024-02-07 07:06:06 +0100 | acidjnk_new | (~acidjnk@p200300d6e737e7149c5f494a93cffe4b.dip0.t-ipconnect.de) |
| 2024-02-07 07:06:28 +0100 | tomku | (~tomku@user/tomku) |
| 2024-02-07 07:12:07 +0100 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Ping timeout: 260 seconds) |
| 2024-02-07 07:12:45 +0100 | euleritian | (~euleritia@dynamic-176-006-192-146.176.6.pool.telefonica.de) |
| 2024-02-07 07:13:51 +0100 | mei | (~mei@user/mei) |
| 2024-02-07 07:15:47 +0100 | <jackdk> | tri_: I probably wouldn't go all the way to FRP to solve this problem. A library like `streaming` is probably all you need if you're just consuming messages from the queue as they come in. If you have many event sources in parallel you may need something fancier, or just running each consumer in its own thread may suffice. Hard to say, unless you say more about your problem |
| 2024-02-07 07:16:35 +0100 | <tri_> | https://paste.tomsmeding.com/MjXusC2w |
| 2024-02-07 07:16:56 +0100 | <tri_> | that's a pseudo code in C#, im trying to port that to Haskell |
| 2024-02-07 07:18:50 +0100 | <probie> | or even just listening on a `Chan` |
| 2024-02-07 07:19:07 +0100 | <jackdk> | If you have a single event source, I would consume an infinite stream probably, and eschew multithreading altogether |
| 2024-02-07 07:20:16 +0100 | <tri_> | probie: what is a chan? is that a library? |
| 2024-02-07 07:20:47 +0100 | <tri_> | im listening for message on AWS SQS/SNS |
| 2024-02-07 07:21:10 +0100 | <probie> | tri_: they're in base; https://hackage.haskell.org/package/base-4.19.0.0/docs/Control-Concurrent-Chan.html |
| 2024-02-07 07:21:38 +0100 | <tri_> | after a bit of thinking, my problem boils down to understand how haskell register a "callback", or in other word, an event handler, when an event is raised |
| 2024-02-07 07:22:08 +0100 | <tri_> | like in .NET (as in my pseudo code), i can register an event handler by using += |
| 2024-02-07 07:22:50 +0100 | <tri_> | idk what's an equiavlent in Haskell yet, i guess i have to read how Amazonka - an AWS sdk for Haskell - works |
| 2024-02-07 07:22:58 +0100 | <c_wraith> | "event handlers" are an uncommon special case in Haskell |
| 2024-02-07 07:23:21 +0100 | takuan | (~takuan@178-116-218-225.access.telenet.be) |
| 2024-02-07 07:23:52 +0100 | <tri_> | c_wraith: im not sure if we are thinking about the same thing, but event handler is a special thing for OOP, so im not sure if there is a 1-1 to FP |
| 2024-02-07 07:23:58 +0100 | <c_wraith> | mostly because the IO manager takes care of suspending threads that are blocked on IO, so event-driven IO doesn't mean much. |
| 2024-02-07 07:23:58 +0100 | <ski> | @kind Control.Concurrent.Chan |
| 2024-02-07 07:23:59 +0100 | <lambdabot> | * -> * |
| 2024-02-07 07:24:33 +0100 | <tri_> | c_wraith: from using RX.Net (or RxJava, RxJS) I feel the way Haskell would handle event is by |
| 2024-02-07 07:24:49 +0100 | evj | (~evj@user/evj) |
| 2024-02-07 07:25:23 +0100 | <tri_> | eventSource & mapFunctionMappingSomeValue & filterFuctionFilteringSomeValue & IOFunctionPrintingOutProcessedValue |
| 2024-02-07 07:25:54 +0100 | <tri_> | sorry for my half-baked pseudo-haskell code above, but i hope you get my point |
| 2024-02-07 07:27:48 +0100 | rosco | (~rosco@175.136.156.77) |
| 2024-02-07 07:27:57 +0100 | <tri_> | in F#, that is eventObservable |> List.map (fun event-> event.PropertyImInterestedIn |> List.map (fun data -> data > conditionOfBusinessLogic |> Observable.subscribe (fun processedData -> printfn "finally processed event is %s" processedData) |
| 2024-02-07 07:28:00 +0100 | <c_wraith> | my point is that you shouldn't be looking for event handlers. In Haskell, needing an "event" system more complex than a queue is rare. |
| 2024-02-07 07:28:26 +0100 | <c_wraith> | You're thinking in a solution space |
| 2024-02-07 07:28:44 +0100 | <c_wraith> | Think in the problem space, instead. What do you have? What do you need to do with it? |
| 2024-02-07 07:29:06 +0100 | <tri_> | ah, my problem is, I need to react to event. That's it |
| 2024-02-07 07:29:18 +0100 | <c_wraith> | See, you're assuming you're using an event system |
| 2024-02-07 07:29:22 +0100 | <c_wraith> | That's not a given |
| 2024-02-07 07:29:30 +0100 | <c_wraith> | In fact, it's very uncommon |
| 2024-02-07 07:29:39 +0100 | <c_wraith> | What do you actually have in the *problem* space? |
| 2024-02-07 07:29:50 +0100 | <tri_> | and depend on a certain property of each event (could be string, int,...) then i have a separate function handling them |
| 2024-02-07 07:30:18 +0100 | <tri_> | and my program has to be running constantly as a linux service, to continually listening for incoming event to react to them |
| 2024-02-07 07:30:45 +0100 | peterbecich | (~Thunderbi@047-229-123-186.res.spectrum.com) (Ping timeout: 272 seconds) |
| 2024-02-07 07:30:49 +0100 | <c_wraith> | You have credentials for subscribing to an AWS queue. You need to turn those credentials into a a process that listens to the queue and handles updates on it. |
| 2024-02-07 07:32:23 +0100 | <tri_> | c_wraith: you have some terms that I don't quite understand, e.g. why you mention credentials? and listening for queues and handling updating mean what i said earlier, i.e. reacting to the event? |
| 2024-02-07 07:33:13 +0100 | <tri_> | c_wraith: i guess you mean what i said, but you put in some new words that confused me, so im not sure if we are still talking about the same thing |
| 2024-02-07 07:36:13 +0100 | chomwitt | (~chomwitt@2a02:587:7a10:cd00:1ac0:4dff:fedb:a3f1) |
| 2024-02-07 07:38:35 +0100 | pruiz | (~user@user/pruiz) |
| 2024-02-07 07:39:36 +0100 | euleritian | (~euleritia@dynamic-176-006-192-146.176.6.pool.telefonica.de) (Read error: Connection reset by peer) |
| 2024-02-07 07:39:56 +0100 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) |
| 2024-02-07 07:43:09 +0100 | <c_wraith> | tri_: the fundamental model in amazonka is sending a request to the service and getting a response. A relevant example here would be ReceiveMessage value off to aws, and getting back a ReceiveMessageResponse that includes some number of new messages in the queue. |
| 2024-02-07 07:43:47 +0100 | <c_wraith> | tri_: This doesn't use event handlers. It's making a function call and examining its return value. |
| 2024-02-07 07:45:04 +0100 | <c_wraith> | For the use case you've described, that seems sufficient. Run it in a loop. Log errors. Handle expected messages. |
| 2024-02-07 07:45:58 +0100 | zetef | (~quassel@95.77.17.251) |
| 2024-02-07 07:50:26 +0100 | rosco | (~rosco@175.136.156.77) (Quit: Lost terminal) |
| 2024-02-07 07:54:18 +0100 | <Axman6> | [3;3~ |
| 2024-02-07 07:56:01 +0100 | <Axman6> | uh, sorry |
| 2024-02-07 07:56:34 +0100 | <Axman6> | That was not meant to be a beatnik cow emoji |
| 2024-02-07 07:57:49 +0100 | <monochrom> | You are so imaginative. I don't see a cow. :) |
| 2024-02-07 07:58:49 +0100 | <jackdk> | And remember to set a nice long waitTimeSeconds, and a longer timeout on your HTTP manager, so you don't rack up unnecessary costs |
| 2024-02-07 07:59:53 +0100 | <jackdk> | FWIW, I agree with everyone who says "just consume in a loop" as a way to get started. You can learn and apply more complicated libraries once you get the thing going |
| 2024-02-07 08:00:42 +0100 | <monochrom> | Is that how you keep the AWS bill low? By throttling "I take only 10 requests per second"? |
| 2024-02-07 08:01:19 +0100 | chomwitt | (~chomwitt@2a02:587:7a10:cd00:1ac0:4dff:fedb:a3f1) (Remote host closed the connection) |
| 2024-02-07 08:01:43 +0100 | chomwitt | (~chomwitt@2a02:587:7a10:cd00:1ac0:4dff:fedb:a3f1) |
| 2024-02-07 08:02:04 +0100 | michalz | (~michalz@185.246.207.215) |
| 2024-02-07 08:02:23 +0100 | <monochrom> | So all the "webscale" "10B requests per second" talks are hot air because in the real world no one can afford webscale AWS bills anyway? >:) |
| 2024-02-07 08:07:10 +0100 | <probie> | Autoscaling makes you just a DDOS away from being broke |
| 2024-02-07 08:08:37 +0100 | evj | (~evj@user/evj) (Quit: evj) |
| 2024-02-07 08:08:59 +0100 | <jackdk> | A common way to run up a SQS bill is to call receiveMessage in a loop, when you should set a waitTimeSeconds and long-poll |
| 2024-02-07 08:10:44 +0100 | <Axman6> | my whole job for 18 months was working on haskell systems build on Amazonka to process data in SQS queues... amazonka is excellent (and way more excellent today because jackdk is a deadset legend) |
| 2024-02-07 08:13:44 +0100 | <Axman6> | tri_: you really, truly, do not need a "event driven library" when working in Haskell. you could emulate things like but you'd be much better off using a functional approach. like probie said, just for a thread that uses amazonka to read data from, whatever AWS service you are about, and put them in a Chan. Then you can have a thread (or many!) which look messages in the Chan and process them. |
| 2024-02-07 08:13:45 +0100 | <c_wraith> | Huh. I thought it would long-poll by default, but that's a silly assumption. Yeah, you'd want that configurable. And to configure it for that case. |
| 2024-02-07 08:14:43 +0100 | <Axman6> | We actually ended up using SEEK's lambda library (I foret its name) which did all the right thigns to react to SQS messages |
| 2024-02-07 08:15:00 +0100 | mjs2600_ | (~mjs2600@c-174-169-225-239.hsd1.vt.comcast.net) |
| 2024-02-07 08:15:05 +0100 | mjs2600 | (~mjs2600@c-174-169-225-239.hsd1.vt.comcast.net) (Ping timeout: 272 seconds) |
| 2024-02-07 08:15:40 +0100 | <monochrom> | The time is ripe for me to tell the converse story. That a student insisted on porting a Haskell solution to Python. (You heard it right, the student did that direction!) |
| 2024-02-07 08:15:54 +0100 | <Axman6> | :( |
| 2024-02-07 08:16:03 +0100 | zetef | (~quassel@95.77.17.251) (Remote host closed the connection) |
| 2024-02-07 08:16:09 +0100 | <Axman6> | My first Haskell job was porting Ruby to Haskell, it was a delight |
| 2024-02-07 08:17:06 +0100 | <monochrom> | So in Haskell you would code up an expression evaluator like this. data Expr = Const Int | Add Expr Expr | Mul Expr Expr | ...; eval (Const n) = n; eval (Add e1 e2) = eval e1 + eval e2; ... |
| 2024-02-07 08:18:10 +0100 | <monochrom> | So the student said "I love Haskell" so their Python version was: defun eval(e): ... if isinstance(e, Const): ... else if isintance(e, Add): ... |
| 2024-02-07 08:18:18 +0100 | <Axman6> | tri_: you could also just use one of the streaming libraries, like streaming |
| 2024-02-07 08:18:55 +0100 | <sshine> | my first and only job that involved Haskell was maintaining a smart contract compiler that got axed the same month I started. |
| 2024-02-07 08:19:00 +0100 | <Axman6> | monochrom: :((( ... as someone who is now writing python for #work, I feel (what should be) their pain |
| 2024-02-07 08:19:22 +0100 | <Axman6> | sshine: ... did we work at the same place? |
| 2024-02-07 08:19:34 +0100 | <sshine> | Axman6, we didn't! I would've known :-D |
| 2024-02-07 08:19:49 +0100 | <sshine> | Axman6, this was eToro's crypto R&D dept. in Copenhagen. |
| 2024-02-07 08:19:56 +0100 | <Axman6> | I feel we need a zero knowledge proof to share the places we worked |
| 2024-02-07 08:20:24 +0100 | <Axman6> | Ah fair enough. I was at Digital Asset, I wish I was working on the DAML compiler, but technically I was only secconded to them |
| 2024-02-07 08:20:33 +0100 | <sshine> | yeah, build a big bloom filter with hashes of employer unique IDs |
| 2024-02-07 08:20:38 +0100 | michalz | (~michalz@185.246.207.215) (Quit: ZNC 1.8.2 - https://znc.in) |
| 2024-02-07 08:20:46 +0100 | <Axman6> | yeah that works |
| 2024-02-07 08:22:18 +0100 | <monochrom> | Well, Python may be a pain for some other problem domains. But AST evaluator is an easy one that fits OO nicely, just dually to FP. Having Const.eval(), Add.eval(), Mul.eval() is a no-brainer. |
| 2024-02-07 08:23:29 +0100 | michalz | (~michalz@185.246.207.217) |
| 2024-02-07 08:23:36 +0100 | <monochrom> | In fact I think the student did the worst of both worlds. They had Const/Add/Mul.evalmethod(), and its code was "eval(self);". |
| 2024-02-07 08:24:35 +0100 | <monochrom> | At which point it's completely self-defeating. (Pun!) |
| 2024-02-07 08:25:06 +0100 | <ski> | they could've used VisitorPattern ? |
| 2024-02-07 08:25:32 +0100 | tri_ | (~tri@2607:fb90:b189:8360:1450:cf3a:2c14:a8bb) (Remote host closed the connection) |
| 2024-02-07 08:26:35 +0100 | <monochrom> | They did have the Add/Mul classes having two fields for the two subexpressions, and Const having a field for the Int. We do not need the visitor pattern yet. |
| 2024-02-07 08:26:48 +0100 | todi | (~todi@p5dca5fa8.dip0.t-ipconnect.de) |
| 2024-02-07 08:28:31 +0100 | <monochrom> | (More broadly, we do not need multiple dispatch yet, and we haven't run into the OO version of the expression problem yet.) |
| 2024-02-07 08:30:17 +0100 | <monochrom> | But it is the composite pattern. |
| 2024-02-07 08:37:39 +0100 | <ski> | @where IndirectComposite |
| 2024-02-07 08:37:39 +0100 | <lambdabot> | <http://web.archive.org/web/20051126141834/http://haskell.org/hawiki/IndirectComposite> |
| 2024-02-07 08:37:46 +0100 | CiaoSen | (~Jura@2a05:5800:280:5c00:e6b9:7aff:fe80:3d03) |
| 2024-02-07 08:39:32 +0100 | <haskellbridge> | <Jade> is this also the pattern that TTG uses? |
| 2024-02-07 08:41:53 +0100 | <ski> | "TTG" ? |
| 2024-02-07 08:45:14 +0100 | <haskellbridge> | <Jade> Trees that grow |
| 2024-02-07 08:45:43 +0100 | <ski> | hm, dunno |
| 2024-02-07 08:47:03 +0100 | mobivme | (~mobivme@130.105.162.31) |
| 2024-02-07 08:53:57 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2024-02-07 08:54:15 +0100 | econo_ | (uid147250@id-147250.tinside.irccloud.com) (Quit: Connection closed for inactivity) |
| 2024-02-07 08:58:58 +0100 | Maxdaman1us | Maxdamantus |
| 2024-02-07 09:00:20 +0100 | pointlessslippe1 | (~pointless@212.82.82.3) |
| 2024-02-07 09:02:58 +0100 | bilegeek | (~bilegeek@2600:1008:b04f:fcf5:b540:c75e:140b:eceb) (Quit: Leaving) |
| 2024-02-07 09:03:09 +0100 | poscat | (~poscat@user/poscat) |
| 2024-02-07 09:03:48 +0100 | pruiz` | (~user@213.4.200.211) |
| 2024-02-07 09:03:49 +0100 | pruiz | (~user@user/pruiz) (Remote host closed the connection) |
| 2024-02-07 09:06:27 +0100 | mobivme | (~mobivme@130.105.162.31) (Ping timeout: 256 seconds) |
| 2024-02-07 09:08:01 +0100 | poscat | (~poscat@user/poscat) (Client Quit) |
| 2024-02-07 09:12:18 +0100 | fendor | (~fendor@2a02:8388:1605:d100:267b:1353:13d7:4f0c) |
| 2024-02-07 09:14:52 +0100 | poscat | (~poscat@user/poscat) |
| 2024-02-07 09:16:58 +0100 | Sgeo | (~Sgeo@user/sgeo) (Read error: Connection reset by peer) |
| 2024-02-07 09:17:34 +0100 | p3n_ | (~p3n@2a00:19a0:3:7c:0:d9c6:7cf6:1) (Quit: ZNC 1.8.2 - https://znc.in) |
| 2024-02-07 09:21:10 +0100 | p3n | (~p3n@217.198.124.246) |
| 2024-02-07 09:21:14 +0100 | mima | (~mmh@aftr-62-216-211-78.dynamic.mnet-online.de) |
| 2024-02-07 09:21:59 +0100 | coot | (~coot@89-69-206-216.dynamic.chello.pl) |
| 2024-02-07 09:22:57 +0100 | fansly | (~fansly@2001:448a:2010:476e:5df1:ad02:fa1f:3df1) (Remote host closed the connection) |
| 2024-02-07 09:33:25 +0100 | chele | (~chele@user/chele) |
| 2024-02-07 09:40:18 +0100 | danse-nr3 | (~danse@151.57.59.129) |
| 2024-02-07 09:43:09 +0100 | fansly | (~fansly@103.3.221.233) |
| 2024-02-07 09:53:30 +0100 | kuribas | (~user@ip-188-118-57-242.reverse.destiny.be) |
| 2024-02-07 09:54:07 +0100 | machinedgod | (~machinedg@d173-183-246-216.abhsia.telus.net) |
| 2024-02-07 09:54:41 +0100 | mobivme | (~mobivme@130.105.162.31) |
| 2024-02-07 09:59:20 +0100 | mobounce | (~mobivme@130.105.162.31) |
| 2024-02-07 10:00:17 +0100 | mobivme | (~mobivme@130.105.162.31) (Ping timeout: 256 seconds) |
| 2024-02-07 10:00:35 +0100 | danse-nr3 | (~danse@151.57.59.129) (Remote host closed the connection) |
| 2024-02-07 10:01:22 +0100 | danse-nr3 | (~danse@151.57.59.129) |
| 2024-02-07 10:02:28 +0100 | mobounce | (~mobivme@130.105.162.31) (Changing host) |
| 2024-02-07 10:02:28 +0100 | mobounce | (~mobivme@user/mobivme) |
| 2024-02-07 10:07:20 +0100 | mmhat | (~mmh@p200300f1c7032843ee086bfffe095315.dip0.t-ipconnect.de) |
| 2024-02-07 10:08:29 +0100 | gmg | (~user@user/gehmehgeh) |
| 2024-02-07 10:13:20 +0100 | gmg | (~user@user/gehmehgeh) (Remote host closed the connection) |
| 2024-02-07 10:14:11 +0100 | gmg | (~user@user/gehmehgeh) |
| 2024-02-07 10:15:37 +0100 | mobounce | (~mobivme@user/mobivme) (Ping timeout: 268 seconds) |
| 2024-02-07 10:16:05 +0100 | mmohammadi9812 | (~mohammad@85.185.34.54) |
| 2024-02-07 10:16:51 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2024-02-07 10:18:28 +0100 | mohammadi9812m | (~mohammad@85.185.35.157) |
| 2024-02-07 10:18:55 +0100 | fansly | (~fansly@103.3.221.233) (Remote host closed the connection) |
| 2024-02-07 10:20:06 +0100 | xdminsy | (~xdminsy@117.147.71.221) |
| 2024-02-07 10:21:41 +0100 | mmohammadi9812 | (~mohammad@85.185.34.54) (Ping timeout: 256 seconds) |
| 2024-02-07 10:24:54 +0100 | Square3 | (~Square4@user/square) |
| 2024-02-07 10:28:20 +0100 | fansly | (~fansly@103.3.221.233) |
| 2024-02-07 10:31:56 +0100 | bairyn | (~bairyn@50-250-232-19-static.hfc.comcastbusiness.net) (Ping timeout: 252 seconds) |
| 2024-02-07 10:32:41 +0100 | sord937 | (~sord937@gateway/tor-sasl/sord937) |
| 2024-02-07 10:33:09 +0100 | fansly | (~fansly@103.3.221.233) (Ping timeout: 272 seconds) |
| 2024-02-07 10:33:27 +0100 | fansly | (~fansly@2001:448a:2010:476e:5df1:ad02:fa1f:3df1) |
| 2024-02-07 10:37:39 +0100 | sord937 | (~sord937@gateway/tor-sasl/sord937) (Remote host closed the connection) |
| 2024-02-07 10:38:26 +0100 | sord937 | (~sord937@gateway/tor-sasl/sord937) |
| 2024-02-07 10:42:47 +0100 | califax | (~califax@user/califx) (Ping timeout: 255 seconds) |
| 2024-02-07 10:43:25 +0100 | califax | (~califax@user/califx) |
| 2024-02-07 10:44:35 +0100 | __monty__ | (~toonn@user/toonn) |
| 2024-02-07 10:44:57 +0100 | zetef | (~quassel@95.77.17.251) |
| 2024-02-07 10:45:49 +0100 | fansly | (~fansly@2001:448a:2010:476e:5df1:ad02:fa1f:3df1) (Ping timeout: 272 seconds) |
| 2024-02-07 10:46:03 +0100 | fansly | (~fansly@114.124.150.111) |
| 2024-02-07 10:49:32 +0100 | danse-nr3 | (~danse@151.57.59.129) (Ping timeout: 268 seconds) |
| 2024-02-07 10:49:32 +0100 | mohammadi9812m | (~mohammad@85.185.35.157) (Ping timeout: 252 seconds) |
| 2024-02-07 10:49:35 +0100 | zetef | (~quassel@95.77.17.251) (Remote host closed the connection) |
| 2024-02-07 10:54:12 +0100 | stiell | (~stiell@gateway/tor-sasl/stiell) (Remote host closed the connection) |
| 2024-02-07 10:54:48 +0100 | stiell | (~stiell@gateway/tor-sasl/stiell) |
| 2024-02-07 10:54:54 +0100 | adam-fuks | (~adam-fuks@public-gprs567556.centertel.pl) (Quit: Lost terminal) |
| 2024-02-07 10:57:03 +0100 | danse-nr3 | (~danse@151.57.59.129) |
| 2024-02-07 10:59:42 +0100 | mobivme | (~mobivme@130.105.162.31) |
| 2024-02-07 10:59:42 +0100 | mobivme | (~mobivme@130.105.162.31) (Changing host) |
| 2024-02-07 10:59:42 +0100 | mobivme | (~mobivme@user/mobivme) |
| 2024-02-07 11:02:27 +0100 | lambdaman | (~textual@d172-218-204-71.bchsia.telus.net) |
| 2024-02-07 11:07:59 +0100 | xff0x | (~xff0x@125x103x176x34.ap125.ftth.ucom.ne.jp) (Ping timeout: 272 seconds) |
| 2024-02-07 11:08:31 +0100 | tzh | (~tzh@c-71-193-181-0.hsd1.or.comcast.net) (Quit: zzz) |
| 2024-02-07 11:10:31 +0100 | mulk | (~mulk@pd9514313.dip0.t-ipconnect.de) (Ping timeout: 272 seconds) |
| 2024-02-07 11:11:36 +0100 | mulk | (~mulk@pd9514313.dip0.t-ipconnect.de) |
| 2024-02-07 11:12:33 +0100 | mreh | (~matthew@host86-160-168-73.range86-160.btcentralplus.com) |
| 2024-02-07 11:18:08 +0100 | fansly | (~fansly@114.124.150.111) (Read error: Connection reset by peer) |
| 2024-02-07 11:18:18 +0100 | fansly | (~fansly@2001:448a:2010:476e:5df1:ad02:fa1f:3df1) |
| 2024-02-07 11:19:23 +0100 | chomwitt | (~chomwitt@2a02:587:7a10:cd00:1ac0:4dff:fedb:a3f1) (Ping timeout: 272 seconds) |
| 2024-02-07 11:20:03 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2024-02-07 11:20:36 +0100 | lg188 | (~lg188@82.18.98.230) |
| 2024-02-07 11:41:19 +0100 | fansly | (~fansly@2001:448a:2010:476e:5df1:ad02:fa1f:3df1) (Remote host closed the connection) |
| 2024-02-07 11:48:56 +0100 | fansly | (~fansly@2001:448a:2010:476e:5df1:ad02:fa1f:3df1) |
| 2024-02-07 11:57:10 +0100 | tri | (~tri@ool-18bc2e74.dyn.optonline.net) |
| 2024-02-07 11:59:47 +0100 | xff0x | (~xff0x@ai099196.d.east.v6connect.net) |
| 2024-02-07 12:01:37 +0100 | tri | (~tri@ool-18bc2e74.dyn.optonline.net) (Ping timeout: 260 seconds) |
| 2024-02-07 12:13:24 +0100 | ubert | (~Thunderbi@2a02:8109:ab8a:5a00:c790:7857:9c1b:e11e) |
| 2024-02-07 12:14:37 +0100 | lambdaman | (~textual@d172-218-204-71.bchsia.telus.net) (Quit: My Mac has gone to sleep. ZZZzzz…) |
| 2024-02-07 12:18:44 +0100 | lambdaman | (~textual@d172-218-204-71.bchsia.telus.net) |
| 2024-02-07 12:28:37 +0100 | fansly | (~fansly@2001:448a:2010:476e:5df1:ad02:fa1f:3df1) (Ping timeout: 264 seconds) |
| 2024-02-07 12:28:42 +0100 | bairyn | (~bairyn@50.250.232.19) |
| 2024-02-07 12:29:39 +0100 | fansly | (~fansly@103.3.221.233) |
| 2024-02-07 12:33:08 +0100 | lortabac | (~lortabac@ip-185-104-138-55.ptr.icomera.net) |
| 2024-02-07 12:35:28 +0100 | Tuplanolla | (~Tuplanoll@91.159.68.95) |
| 2024-02-07 12:36:33 +0100 | causal | (~eric@50.35.85.7) (Quit: WeeChat 4.1.1) |
| 2024-02-07 12:40:37 +0100 | lortabac | (~lortabac@ip-185-104-138-55.ptr.icomera.net) (Quit: WeeChat 4.1.1) |
| 2024-02-07 12:42:48 +0100 | phma | (~phma@host-67-44-208-73.hnremote.net) (Read error: Connection reset by peer) |
| 2024-02-07 12:43:27 +0100 | lambdaman | (~textual@d172-218-204-71.bchsia.telus.net) (Quit: My Mac has gone to sleep. ZZZzzz…) |
| 2024-02-07 12:43:31 +0100 | phma | (phma@2001:5b0:210f:5128:aa71:bdfd:6827:7ed2) |
| 2024-02-07 12:43:41 +0100 | <haskellbridge> | <irregularsphere> Jade: by the way remember that IO issue you've ran into |
| 2024-02-07 12:43:50 +0100 | <haskellbridge> | <irregularsphere> i found something https://hackage.haskell.org/package/base-4.19.0.0/docs/Control-Exception.html#v:bracket |
| 2024-02-07 12:45:22 +0100 | chomwitt | (~chomwitt@2a02:587:7a10:cd00:1ac0:4dff:fedb:a3f1) |
| 2024-02-07 12:47:48 +0100 | <haskellbridge> | <irregularsphere> probably wouldn't help though but i guess it's worth looking into? |
| 2024-02-07 12:49:09 +0100 | szkl | (uid110435@id-110435.uxbridge.irccloud.com) (Quit: Connection closed for inactivity) |
| 2024-02-07 12:49:24 +0100 | lambdaman | (~textual@d172-218-204-71.bchsia.telus.net) |
| 2024-02-07 12:53:41 +0100 | pavonia | (~user@user/siracusa) (Quit: Bye!) |
| 2024-02-07 13:05:41 +0100 | lambdaman | (~textual@d172-218-204-71.bchsia.telus.net) (Quit: My Mac has gone to sleep. ZZZzzz…) |
| 2024-02-07 13:07:40 +0100 | danse-nr3 | (~danse@151.57.59.129) (Ping timeout: 268 seconds) |
| 2024-02-07 13:08:22 +0100 | foul_owl | (~kerry@174-21-148-34.tukw.qwest.net) (Ping timeout: 246 seconds) |
| 2024-02-07 13:09:09 +0100 | moixa | (~moixa@customer-178-16-208-85.stosn.net) |
| 2024-02-07 13:15:50 +0100 | fansly | (~fansly@103.3.221.233) (Ping timeout: 252 seconds) |
| 2024-02-07 13:16:31 +0100 | CiaoSen | (~Jura@2a05:5800:280:5c00:e6b9:7aff:fe80:3d03) (Ping timeout: 276 seconds) |
| 2024-02-07 13:16:53 +0100 | fansly | (~fansly@2001:448a:2010:476e:5df1:ad02:fa1f:3df1) |
| 2024-02-07 13:21:05 +0100 | foul_owl | (~kerry@157.97.134.164) |
| 2024-02-07 13:25:18 +0100 | mmohammadi9812 | (~mohammad@85.185.34.241) |
| 2024-02-07 13:35:43 +0100 | chele | (~chele@user/chele) (Ping timeout: 260 seconds) |
| 2024-02-07 13:36:29 +0100 | fansly | (~fansly@2001:448a:2010:476e:5df1:ad02:fa1f:3df1) (Ping timeout: 240 seconds) |
| 2024-02-07 13:36:50 +0100 | fansly | (~fansly@182.2.146.24) |
| 2024-02-07 13:37:11 +0100 | fansly | (~fansly@182.2.146.24) (Read error: Connection reset by peer) |
| 2024-02-07 13:38:59 +0100 | mmohammadi9812 | (~mohammad@85.185.34.241) (Ping timeout: 260 seconds) |
| 2024-02-07 13:40:05 +0100 | JordiGH | (~jordi@user/jordigh) |
| 2024-02-07 13:40:35 +0100 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Ping timeout: 252 seconds) |
| 2024-02-07 13:41:03 +0100 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) |
| 2024-02-07 13:43:36 +0100 | fansly | (~fansly@103.3.221.233) |
| 2024-02-07 13:46:45 +0100 | pretty_dumm_guy | (trottel@gateway/vpn/protonvpn/prettydummguy/x-88029655) |
| 2024-02-07 13:47:24 +0100 | igemnace | (~ian@user/igemnace) (Read error: Connection reset by peer) |
| 2024-02-07 13:48:14 +0100 | chele | (~chele@user/chele) |
| 2024-02-07 13:55:17 +0100 | JordiGH | (~jordi@user/jordigh) (Ping timeout: 240 seconds) |
| 2024-02-07 13:58:30 +0100 | danse-nr3 | (~danse@151.57.34.109) |
| 2024-02-07 14:01:02 +0100 | alexherbo2 | (~alexherbo@2a02-8440-3440-5654-4484-4a93-9fff-6f85.rev.sfr.net) |
| 2024-02-07 14:02:31 +0100 | fansly | (~fansly@103.3.221.233) (Remote host closed the connection) |
| 2024-02-07 14:02:49 +0100 | mechap | (~mechap@user/mechap) (Ping timeout: 256 seconds) |
| 2024-02-07 14:04:26 +0100 | igemnace | (~ian@user/igemnace) |
| 2024-02-07 14:04:51 +0100 | mechap | (~mechap@user/mechap) |
| 2024-02-07 14:12:54 +0100 | fansly | (~fansly@2001:448a:2010:476e:5df1:ad02:fa1f:3df1) |
| 2024-02-07 14:16:05 +0100 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Ping timeout: 272 seconds) |
| 2024-02-07 14:16:59 +0100 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) |
| 2024-02-07 14:23:03 +0100 | mmhat | (~mmh@p200300f1c7032843ee086bfffe095315.dip0.t-ipconnect.de) (Ping timeout: 272 seconds) |
| 2024-02-07 14:25:04 +0100 | destituion | (~destituio@2a02:2121:626:f551:7691:f531:69f8:5291) (Ping timeout: 268 seconds) |
| 2024-02-07 14:25:20 +0100 | destituion | (~destituio@85.221.111.174) |
| 2024-02-07 14:25:20 +0100 | fansly | (~fansly@2001:448a:2010:476e:5df1:ad02:fa1f:3df1) (Remote host closed the connection) |
| 2024-02-07 14:29:14 +0100 | fansly | (~fansly@2001:448a:2010:476e:5df1:ad02:fa1f:3df1) |
| 2024-02-07 14:35:14 +0100 | waleee | (~waleee@h-176-10-144-38.NA.cust.bahnhof.se) |
| 2024-02-07 14:40:07 +0100 | mmhat | (~mmh@p200300f1c70397f2ee086bfffe095315.dip0.t-ipconnect.de) |
| 2024-02-07 14:45:51 +0100 | fansly | (~fansly@2001:448a:2010:476e:5df1:ad02:fa1f:3df1) (Remote host closed the connection) |
| 2024-02-07 14:48:59 +0100 | chomwitt | (~chomwitt@2a02:587:7a10:cd00:1ac0:4dff:fedb:a3f1) (Quit: Leaving) |
| 2024-02-07 14:49:46 +0100 | <absence> | Is there anything in lens that works on [(key, value)]? If I don't care about order or duplicates, I can make an unlawful Iso that converts to/from "Map key value", and use "at someKey", but I'm curious if there are alternatives. |
| 2024-02-07 14:51:34 +0100 | <ncf> | absence: traversed.itraversed :: IndexedTraversal' k [(k, v)] v |
| 2024-02-07 14:51:55 +0100 | <ncf> | (but this won't let you add or remove entries) |
| 2024-02-07 14:53:51 +0100 | <absence> | ncf: That makes sense, but unfortunately I need to add... |
| 2024-02-07 14:54:34 +0100 | <absence> | Or well, look up a specific key, and add a value for it if it's missing. |
| 2024-02-07 14:54:53 +0100 | <ncf> | failover may be useful |
| 2024-02-07 14:57:00 +0100 | <dminuoso_> | absence: The closest thing would be At, but there isnt even a suitable Ixed+Index |
| 2024-02-07 14:57:31 +0100 | <hololeap> | so, I wrote this abomination to let me write prettyprinter lines with ApplicativeDo: https://bpa.st/QHOA |
| 2024-02-07 14:58:05 +0100 | <hololeap> | the funny thing is that it passes the Applicative laws |
| 2024-02-07 14:58:42 +0100 | <hololeap> | but I vaguely remember blaze having a Monad instance so that you could write do blocks with it. how did it achieve that? |
| 2024-02-07 15:00:08 +0100 | <ncf> | if you replace Writer [Doc ann] () with [Doc ann] then this is the standard applicative instance for Const |
| 2024-02-07 15:00:31 +0100 | mei | (~mei@user/mei) (Remote host closed the connection) |
| 2024-02-07 15:00:33 +0100 | <ncf> | well, for LinesBuilder ann = Const [Doc ann] |
| 2024-02-07 15:00:47 +0100 | fansly | (~fansly@2001:448a:2010:476e:5df1:ad02:fa1f:3df1) |
| 2024-02-07 15:00:54 +0100 | waleee | (~waleee@h-176-10-144-38.NA.cust.bahnhof.se) (Quit: oops) |
| 2024-02-07 15:01:51 +0100 | <ncf> | if you wanted a monad, you could just use Writer [Doc ann] |
| 2024-02-07 15:02:55 +0100 | mei | (~mei@user/mei) |
| 2024-02-07 15:03:51 +0100 | waleee | (~waleee@h-176-10-144-38.NA.cust.bahnhof.se) |
| 2024-02-07 15:03:58 +0100 | <hololeap> | well, having OverloadedStrings work as well was part of the point, and the compiler doesn't seem to like my original instance of IsString (Writer [Doc ann] ()) |
| 2024-02-07 15:04:00 +0100 | <int-e> | . o O ( Writer (Endo [Doc ann]) aka Writer (DList (Doc ann)) ) |
| 2024-02-07 15:04:41 +0100 | JordiGH | (~jordi@user/jordigh) |
| 2024-02-07 15:04:49 +0100 | <absence> | dminuoso_: Thanks, that makes me feel somewhat less bad about the unlawful Iso at least. :P |
| 2024-02-07 15:05:35 +0100 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Ping timeout: 256 seconds) |
| 2024-02-07 15:05:39 +0100 | <ncf> | fromString s = Writer ([fromString s], ()) ? |
| 2024-02-07 15:06:20 +0100 | euleritian | (~euleritia@dynamic-046-114-179-094.46.114.pool.telefonica.de) |
| 2024-02-07 15:06:27 +0100 | <ncf> | you might need some silliness like instance (a ~ ()) => IsString (Writer [Doc ann] a) |
| 2024-02-07 15:06:27 +0100 | <danse-nr3> | unlawfulness could be even nastier than type unsafety |
| 2024-02-07 15:12:30 +0100 | alexherbo2 | (~alexherbo@2a02-8440-3440-5654-4484-4a93-9fff-6f85.rev.sfr.net) (Remote host closed the connection) |
| 2024-02-07 15:13:25 +0100 | <hololeap> | ncf: yeah, when I went to use it, I would get ambiguous type errors unless I annotated every line specifying it was Writer [Doc ann] () |
| 2024-02-07 15:13:53 +0100 | <ncf> | right i think that's the problem a ~ () solves |
| 2024-02-07 15:15:11 +0100 | Lycurgus | (~georg@user/Lycurgus) |
| 2024-02-07 15:18:11 +0100 | <hololeap> | huh, yeah that does seem to work |
| 2024-02-07 15:18:27 +0100 | <hololeap> | well then |
| 2024-02-07 15:18:39 +0100 | <dminuoso_> | ApplicativeDo, now there's an annoying buggy extension Ive stopped using a while ago. |
| 2024-02-07 15:19:12 +0100 | <dminuoso_> | The number of times where some interaction with other extensions or lesser known features just silently degrades into Monad... |
| 2024-02-07 15:19:28 +0100 | <dminuoso_> | Especially when a Monad instance exists but you dont want to. |
| 2024-02-07 15:19:35 +0100 | <hololeap> | dminuoso_: yeah that's an annoying problem |
| 2024-02-07 15:19:46 +0100 | <hololeap> | I use it with optparse-applicative quite a bit just to make things more readable. I haven't had any issues with it there, since there's no Monad |
| 2024-02-07 15:20:03 +0100 | mima | (~mmh@aftr-62-216-211-78.dynamic.mnet-online.de) (Ping timeout: 272 seconds) |
| 2024-02-07 15:26:48 +0100 | <hololeap> | honestly a BindDo would be pretty cool (talking about Bind from semigroupoids) |
| 2024-02-07 15:27:23 +0100 | <dminuoso_> | Oh, do give us ApplyDo as well then. |
| 2024-02-07 15:27:37 +0100 | <dminuoso_> | And let all of them reuse `do` at the same time. |
| 2024-02-07 15:27:45 +0100 | <hololeap> | true |
| 2024-02-07 15:27:47 +0100 | <dminuoso_> | Will `do` degrade into... something? |
| 2024-02-07 15:28:06 +0100 | <hololeap> | I don't know why you can't at least get ApplicativeDo to give you a warning when it does that |
| 2024-02-07 15:28:49 +0100 | <hololeap> | I wonder if there's any GHC bugs for this |
| 2024-02-07 15:28:56 +0100 | <hololeap> | *issues |
| 2024-02-07 15:31:27 +0100 | euleritian | (~euleritia@dynamic-046-114-179-094.46.114.pool.telefonica.de) (Ping timeout: 272 seconds) |
| 2024-02-07 15:31:55 +0100 | euleritian | (~euleritia@dynamic-176-006-196-059.176.6.pool.telefonica.de) |
| 2024-02-07 15:34:01 +0100 | mmhat | (~mmh@p200300f1c70397f2ee086bfffe095315.dip0.t-ipconnect.de) (Ping timeout: 264 seconds) |
| 2024-02-07 15:34:23 +0100 | mmhat | (~mmh@p200300f1c7039776ee086bfffe095315.dip0.t-ipconnect.de) |
| 2024-02-07 15:36:16 +0100 | danse-nr3 | (~danse@151.57.34.109) (Ping timeout: 276 seconds) |
| 2024-02-07 15:41:35 +0100 | <hololeap> | https://gitlab.haskell.org/ghc/ghc/-/issues/24418 |
| 2024-02-07 15:41:36 +0100 | danse-nr3 | (~danse@151.57.34.109) |
| 2024-02-07 15:46:24 +0100 | <hololeap> | what would be ideal would be a proposal for being able to specify what 'do' you intend on using for any given block |
| 2024-02-07 15:51:29 +0100 | euleritian | (~euleritia@dynamic-176-006-196-059.176.6.pool.telefonica.de) (Ping timeout: 252 seconds) |
| 2024-02-07 15:51:47 +0100 | euleritian | (~euleritia@176.2.134.110) |
| 2024-02-07 15:55:23 +0100 | dcompoze | (~Thunderbi@cpc97610-walt24-2-0-cust190.13-2.cable.virginm.net) |
| 2024-02-07 15:55:55 +0100 | <[Leary]> | hololeap: QualifiedDo gives you that. Perhaps you could redefine bind with something that throws a compile-time error? An Unsatisfiable constraint, for example. |
| 2024-02-07 15:57:08 +0100 | <hololeap> | I didn't even know about QualifiedDo |
| 2024-02-07 15:58:00 +0100 | fansly | (~fansly@2001:448a:2010:476e:5df1:ad02:fa1f:3df1) (Remote host closed the connection) |
| 2024-02-07 16:00:17 +0100 | <hololeap> | I guess you could wrap a Monad in a newtype then derive up to Applicative with GeneralizedNewtypeDeriving, but that seems like such a hassle to get the behavior you're after |
| 2024-02-07 16:01:56 +0100 | fansly | (~fansly@2001:448a:2010:476e:5df1:ad02:fa1f:3df1) |
| 2024-02-07 16:04:10 +0100 | tri | (~tri@ool-18bbef1a.static.optonline.net) |
| 2024-02-07 16:08:05 +0100 | euleritian | (~euleritia@176.2.134.110) (Ping timeout: 240 seconds) |
| 2024-02-07 16:08:46 +0100 | tri | (~tri@ool-18bbef1a.static.optonline.net) (Ping timeout: 276 seconds) |
| 2024-02-07 16:11:17 +0100 | chiselfuse | (~chiselfus@user/chiselfuse) (Ping timeout: 255 seconds) |
| 2024-02-07 16:11:55 +0100 | dcompoze | (~Thunderbi@cpc97610-walt24-2-0-cust190.13-2.cable.virginm.net) (Remote host closed the connection) |
| 2024-02-07 16:12:14 +0100 | <hololeap> | int-e thanks for the Endo hint |
| 2024-02-07 16:12:29 +0100 | chiselfuse | (~chiselfus@user/chiselfuse) |
| 2024-02-07 16:13:11 +0100 | dibblego | (~dibblego@haskell/developer/dibblego) (Ping timeout: 264 seconds) |
| 2024-02-07 16:13:25 +0100 | <hololeap> | I still don't understand why that's more efficient than the built in list concatination |
| 2024-02-07 16:16:16 +0100 | euleritian | (~euleritia@dynamic-176-006-179-025.176.6.pool.telefonica.de) |
| 2024-02-07 16:19:02 +0100 | <ski> | left-nested uses of `++' (which e.g. results if you do recursion to the left of `++', repeatedly adding things to the end) will be unreasonably inefficient. a traversal of `((as ++ bs) ++ cs) ++ ds' will traverse `as', then traverse (a copy of) `as' as well as `bs', then treverse (copies of) `as',`bs' as well as `cs', then traverse (copies of) `as',`bs',`cs' as well as `ds' |
| 2024-02-07 16:19:35 +0100 | <ski> | using `Endo [...]' / `DList (...)' effectively transforms this into right-nested uses of `++' |
| 2024-02-07 16:20:15 +0100 | <hololeap> | ok, but how |
| 2024-02-07 16:21:11 +0100 | <hololeap> | also, does this matter for say 30 small lists |
| 2024-02-07 16:21:30 +0100 | <ncf> | (as ++) . (bs ++) . (cs ++) $ [] will be right-associated no matter how you associate the composition |
| 2024-02-07 16:22:20 +0100 | santiagopim | (~user@90.167.66.131) |
| 2024-02-07 16:22:28 +0100 | dibblego | (~dibblego@122-199-1-93.ip4.superloop.au) |
| 2024-02-07 16:22:28 +0100 | dibblego | (~dibblego@122-199-1-93.ip4.superloop.au) (Changing host) |
| 2024-02-07 16:22:28 +0100 | dibblego | (~dibblego@haskell/developer/dibblego) |
| 2024-02-07 16:22:54 +0100 | average | (uid473595@user/average) (Quit: Connection closed for inactivity) |
| 2024-02-07 16:23:58 +0100 | mima | (~mmh@138.246.3.248) |
| 2024-02-07 16:24:56 +0100 | fansly | (~fansly@2001:448a:2010:476e:5df1:ad02:fa1f:3df1) (Remote host closed the connection) |
| 2024-02-07 16:28:17 +0100 | <hololeap> | I see, so it's just due to how functions compose in haskell |
| 2024-02-07 16:28:37 +0100 | <ncf> | in math really, but yeah |
| 2024-02-07 16:28:58 +0100 | <hololeap> | it will still have to walk each individual list, though, won't it? |
| 2024-02-07 16:29:12 +0100 | <ncf> | yes, so it's O(n) |
| 2024-02-07 16:29:57 +0100 | <hololeap> | ok, which is why e.g. Sequence exists to get the O(1) concats |
| 2024-02-07 16:30:25 +0100 | <hololeap> | thanks for the simple explaination |
| 2024-02-07 16:30:56 +0100 | waleee | (~waleee@h-176-10-144-38.NA.cust.bahnhof.se) (Quit: WeeChat 4.1.2) |
| 2024-02-07 16:32:14 +0100 | fansly | (~fansly@2001:448a:2010:476e:5df1:ad02:fa1f:3df1) |
| 2024-02-07 16:32:45 +0100 | euleritian | (~euleritia@dynamic-176-006-179-025.176.6.pool.telefonica.de) (Ping timeout: 260 seconds) |
| 2024-02-07 16:33:19 +0100 | euleritian | (~euleritia@46.114.105.247) |
| 2024-02-07 16:35:38 +0100 | sp1ff | (~user@24.21.45.157) |
| 2024-02-07 16:38:17 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2024-02-07 16:38:31 +0100 | qqq | (~qqq@92.43.167.61) |
| 2024-02-07 16:42:13 +0100 | alexherbo2 | (~alexherbo@2a02-8440-3440-5654-4484-4a93-9fff-6f85.rev.sfr.net) |
| 2024-02-07 16:43:10 +0100 | fansly | (~fansly@2001:448a:2010:476e:5df1:ad02:fa1f:3df1) (Remote host closed the connection) |
| 2024-02-07 16:46:02 +0100 | sympt | (~sympt@user/sympt) (Quit: Ping timeout (120 seconds)) |
| 2024-02-07 16:49:04 +0100 | mobivme | (~mobivme@user/mobivme) (Remote host closed the connection) |
| 2024-02-07 16:49:13 +0100 | sympt | (~sympt@user/sympt) |
| 2024-02-07 16:49:23 +0100 | xff0x | (~xff0x@ai099196.d.east.v6connect.net) (Ping timeout: 260 seconds) |
| 2024-02-07 16:50:00 +0100 | xff0x | (~xff0x@2405:6580:b080:900:e061:c51:d1f0:45a8) |
| 2024-02-07 16:50:17 +0100 | euleritian | (~euleritia@46.114.105.247) (Ping timeout: 268 seconds) |
| 2024-02-07 16:50:54 +0100 | fansly | (~fansly@2001:448a:2010:476e:5df1:ad02:fa1f:3df1) |
| 2024-02-07 16:51:10 +0100 | euleritian | (~euleritia@dynamic-176-006-188-106.176.6.pool.telefonica.de) |
| 2024-02-07 16:55:06 +0100 | mobivme | (~mobivme@130.105.162.31) |
| 2024-02-07 16:55:06 +0100 | mobivme | (~mobivme@130.105.162.31) (Changing host) |
| 2024-02-07 16:55:06 +0100 | mobivme | (~mobivme@user/mobivme) |
| 2024-02-07 16:56:46 +0100 | xff0x | (~xff0x@2405:6580:b080:900:e061:c51:d1f0:45a8) (Ping timeout: 268 seconds) |
| 2024-02-07 16:56:49 +0100 | mmhat | (~mmh@p200300f1c7039776ee086bfffe095315.dip0.t-ipconnect.de) (Ping timeout: 264 seconds) |
| 2024-02-07 16:58:18 +0100 | xff0x | (~xff0x@ai099196.d.east.v6connect.net) |
| 2024-02-07 16:59:18 +0100 | tromp | (~textual@92.110.219.57) |
| 2024-02-07 17:02:22 +0100 | mobivme | (~mobivme@user/mobivme) (Remote host closed the connection) |
| 2024-02-07 17:04:16 +0100 | tri | (~tri@ool-18bbef1a.static.optonline.net) |
| 2024-02-07 17:08:59 +0100 | tri | (~tri@ool-18bbef1a.static.optonline.net) (Ping timeout: 272 seconds) |
| 2024-02-07 17:10:58 +0100 | Wstfgl0 | (~me-me@2602:ff16:3:0:1:dc:beef:d00d) |
| 2024-02-07 17:11:06 +0100 | Me-me | (~me-me@user/me-me) (Read error: Connection reset by peer) |
| 2024-02-07 17:12:21 +0100 | mmhat | (~mmh@p200300f1c7060369ee086bfffe095315.dip0.t-ipconnect.de) |
| 2024-02-07 17:14:29 +0100 | Unicorn_Princess | (~Unicorn_P@user/Unicorn-Princess/x-3540542) |
| 2024-02-07 17:15:22 +0100 | Achylles | (~Achylles_@45.182.57.94) |
| 2024-02-07 17:17:50 +0100 | mobivme | (~mobivme@130.105.162.31) |
| 2024-02-07 17:20:37 +0100 | pruiz` | (~user@213.4.200.211) (Remote host closed the connection) |
| 2024-02-07 17:21:47 +0100 | econo_ | (uid147250@2a03:5180:f::2:3f32) |
| 2024-02-07 17:25:44 +0100 | pruiz` | (~user@213.4.200.211) |
| 2024-02-07 17:29:06 +0100 | mobivme | (~mobivme@130.105.162.31) (Quit: ZNC 1.8.2+deb2build5 - https://znc.in) |
| 2024-02-07 17:30:55 +0100 | euleritian | (~euleritia@dynamic-176-006-188-106.176.6.pool.telefonica.de) (Ping timeout: 260 seconds) |
| 2024-02-07 17:30:59 +0100 | pruiz` | (~user@213.4.200.211) (Ping timeout: 268 seconds) |
| 2024-02-07 17:31:23 +0100 | euleritian | (~euleritia@dynamic-176-006-188-106.176.6.pool.telefonica.de) |
| 2024-02-07 17:32:08 +0100 | mobivme | (~mobivme@130.105.162.31) |
| 2024-02-07 17:32:23 +0100 | tri | (~tri@ool-18bbef1a.static.optonline.net) |
| 2024-02-07 17:36:53 +0100 | mobivme | (~mobivme@130.105.162.31) (Ping timeout: 256 seconds) |
| 2024-02-07 17:39:34 +0100 | dibblego | (~dibblego@haskell/developer/dibblego) (Ping timeout: 264 seconds) |
| 2024-02-07 17:41:48 +0100 | mobivme | (~mobivme@130.105.162.31) |
| 2024-02-07 17:45:01 +0100 | todi | (~todi@p5dca5fa8.dip0.t-ipconnect.de) (Quit: ZNC - https://znc.in) |
| 2024-02-07 17:48:29 +0100 | mmhat | (~mmh@p200300f1c7060369ee086bfffe095315.dip0.t-ipconnect.de) (Ping timeout: 240 seconds) |
| 2024-02-07 17:49:11 +0100 | mmohammadi9812 | (~mohammad@85.185.33.169) |
| 2024-02-07 17:51:02 +0100 | euleritian | (~euleritia@dynamic-176-006-188-106.176.6.pool.telefonica.de) (Ping timeout: 268 seconds) |
| 2024-02-07 17:52:11 +0100 | euleritian | (~euleritia@dynamic-176-003-154-098.176.3.pool.telefonica.de) |
| 2024-02-07 17:54:35 +0100 | mmohammadi9812 | (~mohammad@85.185.33.169) (Ping timeout: 264 seconds) |
| 2024-02-07 17:55:57 +0100 | mmohammadi9812 | (~mohammad@85.185.33.169) |
| 2024-02-07 17:56:22 +0100 | stevenxl | (uid133530@id-133530.uxbridge.irccloud.com) |
| 2024-02-07 17:58:27 +0100 | danse-nr3 | (~danse@151.57.34.109) (Read error: Connection reset by peer) |
| 2024-02-07 17:59:29 +0100 | danse-nr3 | (~danse@151.57.36.65) |
| 2024-02-07 18:00:11 +0100 | mmohammadi9812 | (~mohammad@85.185.33.169) (Ping timeout: 252 seconds) |
| 2024-02-07 18:01:19 +0100 | mmohammadi9812 | (~mohammad@85.185.33.169) |
| 2024-02-07 18:03:58 +0100 | <kuribas> | hololeap: DList basically makes a tree of thunks, which is then flattened using a depth first traversal. |
| 2024-02-07 18:04:10 +0100 | Nulldata11 | (~Nulldata@80.71.142.55) |
| 2024-02-07 18:04:15 +0100 | Nulldata11 | (~Nulldata@80.71.142.55) (Client Quit) |
| 2024-02-07 18:04:26 +0100 | Nulldatamap | (~Nulldatam@80.71.142.55) |
| 2024-02-07 18:05:19 +0100 | <kuribas> | Of closures actually, because they are lambdas, and lazyness doesn't matter here. |
| 2024-02-07 18:06:02 +0100 | azimut | (~azimut@gateway/tor-sasl/azimut) (Ping timeout: 255 seconds) |
| 2024-02-07 18:06:56 +0100 | califax | (~califax@user/califx) (Ping timeout: 255 seconds) |
| 2024-02-07 18:07:43 +0100 | mmohammadi9812 | (~mohammad@85.185.33.169) (Ping timeout: 276 seconds) |
| 2024-02-07 18:07:52 +0100 | mmhat | (~mmh@p200300f1c706b969ee086bfffe095315.dip0.t-ipconnect.de) |
| 2024-02-07 18:08:46 +0100 | califax | (~califax@user/califx) |
| 2024-02-07 18:08:54 +0100 | mmohammadi9812 | (~mohammad@85.185.33.169) |
| 2024-02-07 18:10:10 +0100 | mreh | (~matthew@host86-160-168-73.range86-160.btcentralplus.com) (Ping timeout: 264 seconds) |
| 2024-02-07 18:10:22 +0100 | dibblego | (~dibblego@122-199-1-93.ip4.superloop.au) |
| 2024-02-07 18:10:22 +0100 | dibblego | (~dibblego@122-199-1-93.ip4.superloop.au) (Changing host) |
| 2024-02-07 18:10:22 +0100 | dibblego | (~dibblego@haskell/developer/dibblego) |
| 2024-02-07 18:12:19 +0100 | rvalue | (~rvalue@user/rvalue) (Ping timeout: 272 seconds) |
| 2024-02-07 18:13:07 +0100 | mobounce | (~mobivme@104.28.226.106) |
| 2024-02-07 18:13:34 +0100 | rvalue | (~rvalue@user/rvalue) |
| 2024-02-07 18:14:22 +0100 | califax | (~califax@user/califx) (Remote host closed the connection) |
| 2024-02-07 18:14:51 +0100 | mobivme | (~mobivme@130.105.162.31) (Ping timeout: 272 seconds) |
| 2024-02-07 18:15:19 +0100 | califax | (~califax@user/califx) |
| 2024-02-07 18:16:40 +0100 | a51 | (a51@gateway/vpn/protonvpn/a51) (Quit: WeeChat 4.2.1) |
| 2024-02-07 18:17:23 +0100 | euleritian | (~euleritia@dynamic-176-003-154-098.176.3.pool.telefonica.de) (Ping timeout: 272 seconds) |
| 2024-02-07 18:17:32 +0100 | fendor | (~fendor@2a02:8388:1605:d100:267b:1353:13d7:4f0c) (Remote host closed the connection) |
| 2024-02-07 18:18:40 +0100 | euleritian | (~euleritia@dynamic-176-003-138-172.176.3.pool.telefonica.de) |
| 2024-02-07 18:20:42 +0100 | euleritian | (~euleritia@dynamic-176-003-138-172.176.3.pool.telefonica.de) (Read error: Connection reset by peer) |
| 2024-02-07 18:20:59 +0100 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) |
| 2024-02-07 18:22:16 +0100 | thaumavorio | (~thaumavor@thaumavor.io) (Quit: ZNC 1.8.2 - https://znc.in) |
| 2024-02-07 18:23:07 +0100 | thaumavorio | (~thaumavor@thaumavor.io) |
| 2024-02-07 18:23:58 +0100 | Hooloovoo | (~Hooloovoo@hax0rbana.org) (Ping timeout: 256 seconds) |
| 2024-02-07 18:25:34 +0100 | mobounce | (~mobivme@104.28.226.106) (Changing host) |
| 2024-02-07 18:25:34 +0100 | mobounce | (~mobivme@user/mobivme) |
| 2024-02-07 18:25:37 +0100 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Ping timeout: 264 seconds) |
| 2024-02-07 18:25:57 +0100 | euleritian | (~euleritia@dynamic-176-003-138-172.176.3.pool.telefonica.de) |
| 2024-02-07 18:26:28 +0100 | Hooloovoo | (~Hooloovoo@hax0rbana.org) |
| 2024-02-07 18:29:28 +0100 | kuribas | (~user@ip-188-118-57-242.reverse.destiny.be) (Remote host closed the connection) |
| 2024-02-07 18:30:32 +0100 | mmohammadi9812 | (~mohammad@85.185.33.169) (Remote host closed the connection) |
| 2024-02-07 18:32:06 +0100 | igemnace | (~ian@user/igemnace) (Quit: WeeChat 4.2.1) |
| 2024-02-07 18:32:49 +0100 | euleritian | (~euleritia@dynamic-176-003-138-172.176.3.pool.telefonica.de) (Ping timeout: 264 seconds) |
| 2024-02-07 18:33:28 +0100 | euleritian | (~euleritia@dynamic-176-003-153-193.176.3.pool.telefonica.de) |
| 2024-02-07 18:33:52 +0100 | <Nulldatamap> | Hello, I've got a question about generic functions (`Data.Data`/`Data.Generics`/`syb`): |
| 2024-02-07 18:33:53 +0100 | <Nulldatamap> | I'm trying to express a generic transformation over a parametric type like this: |
| 2024-02-07 18:33:53 +0100 | <Nulldatamap> | ``` |
| 2024-02-07 18:33:54 +0100 | <Nulldatamap> | data Wrapped a = Wrapped Int a |
| 2024-02-07 18:33:54 +0100 | <Nulldatamap> | -- type GenericT = forall a. Data a => a -> a |
| 2024-02-07 18:33:55 +0100 | <Nulldatamap> | -- everywhere :: |
| 2024-02-07 18:33:55 +0100 | <Nulldatamap> | -- extT :: (Typeable a, Typeable b) => (a -> a) -> (b -> b) -> a -> a |
| 2024-02-07 18:33:56 +0100 | <Nulldatamap> | incWrappedEverywhere :: GenericT -> GenericT |
| 2024-02-07 18:33:56 +0100 | <Nulldatamap> | incWrappedEverywhere f = everywhere $ f `extT` incWrapped |
| 2024-02-07 18:33:57 +0100 | <Nulldatamap> | where |
| 2024-02-07 18:33:57 +0100 | <Nulldatamap> | incWrapped :: forall a. Data a => Wrapped a -> Wrapped a |
| 2024-02-07 18:33:58 +0100 | <Nulldatamap> | incWrapped (Wrapped i x) = (Wrapped (i + 1) x) |
| 2024-02-07 18:33:58 +0100 | <Nulldatamap> | ``` |
| 2024-02-07 18:33:59 +0100 | <Nulldatamap> | But this fails with: |
| 2024-02-07 18:33:59 +0100 | <Nulldatamap> | `` |
| 2024-02-07 18:34:00 +0100 | <Nulldatamap> | Could not deduce (Data a0) arising from a use of `incWrapped' |
| 2024-02-07 18:34:00 +0100 | <Nulldatamap> | from the context: Data a |
| 2024-02-07 18:34:01 +0100 | <Nulldatamap> | ``` |
| 2024-02-07 18:34:10 +0100 | <danse-nr3> | are you crazy? |
| 2024-02-07 18:34:22 +0100 | <danse-nr3> | use a pastebin for goddess' sake |
| 2024-02-07 18:34:36 +0100 | danse-nr3 | calms down |
| 2024-02-07 18:34:39 +0100 | <danse-nr3> | err ... sorry |
| 2024-02-07 18:34:53 +0100 | <Nulldatamap> | My bad, I thought the snippet was small enough |
| 2024-02-07 18:35:14 +0100 | <geekosaur> | IRC's a very old protocol, you probably don't want to go over 3 lines |
| 2024-02-07 18:35:23 +0100 | <danse-nr3> | my bad as well ... have audio notifications on for this channel ... |
| 2024-02-07 18:37:39 +0100 | mei | (~mei@user/mei) (Ping timeout: 272 seconds) |
| 2024-02-07 18:37:52 +0100 | <Nulldatamap> | Here's the pastebin link for the sake of syntax highlighting if nothing else then: https://paste.tomsmeding.com/XRAL7oFs |
| 2024-02-07 18:40:09 +0100 | mmhat | (~mmh@p200300f1c706b969ee086bfffe095315.dip0.t-ipconnect.de) (Ping timeout: 260 seconds) |
| 2024-02-07 18:40:23 +0100 | euleritian | (~euleritia@dynamic-176-003-153-193.176.3.pool.telefonica.de) (Read error: Connection reset by peer) |
| 2024-02-07 18:40:36 +0100 | mobounce | (~mobivme@user/mobivme) (Remote host closed the connection) |
| 2024-02-07 18:40:40 +0100 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) |
| 2024-02-07 18:41:11 +0100 | tzh | (~tzh@c-71-193-181-0.hsd1.or.comcast.net) |
| 2024-02-07 18:45:01 +0100 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Ping timeout: 256 seconds) |
| 2024-02-07 18:45:54 +0100 | euleritian | (~euleritia@dynamic-176-003-153-193.176.3.pool.telefonica.de) |
| 2024-02-07 18:46:23 +0100 | rvalue | (~rvalue@user/rvalue) (Ping timeout: 252 seconds) |
| 2024-02-07 18:52:21 +0100 | tromp | (~textual@92.110.219.57) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2024-02-07 18:53:37 +0100 | mmhat | (~mmh@p200300f1c707a64cee086bfffe095315.dip0.t-ipconnect.de) |
| 2024-02-07 18:55:22 +0100 | rvalue | (~rvalue@user/rvalue) |
| 2024-02-07 18:56:26 +0100 | mobivme | (~mobivme@130.105.162.31) |
| 2024-02-07 18:57:56 +0100 | Square3 | (~Square4@user/square) (Ping timeout: 252 seconds) |
| 2024-02-07 19:01:14 +0100 | anpad | (~pandeyan@user/anpad) (Quit: ZNC 1.8.2 - https://znc.in) |
| 2024-02-07 19:02:11 +0100 | sord937 | (~sord937@gateway/tor-sasl/sord937) (Quit: sord937) |
| 2024-02-07 19:04:07 +0100 | anpad | (~pandeyan@user/anpad) |
| 2024-02-07 19:05:21 +0100 | danse-nr3 | (~danse@151.57.36.65) (Ping timeout: 260 seconds) |
| 2024-02-07 19:07:56 +0100 | athan | (~athan@173-042-095-241.biz.spectrum.com) (Quit: Konversation terminated!) |
| 2024-02-07 19:08:13 +0100 | dibblego | (~dibblego@haskell/developer/dibblego) (Ping timeout: 264 seconds) |
| 2024-02-07 19:08:54 +0100 | euleritian | (~euleritia@dynamic-176-003-153-193.176.3.pool.telefonica.de) (Read error: Connection reset by peer) |
| 2024-02-07 19:09:11 +0100 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) |
| 2024-02-07 19:10:39 +0100 | mobivme | (~mobivme@130.105.162.31) (Quit: ZNC 1.8.2+deb2build5 - https://znc.in) |
| 2024-02-07 19:10:57 +0100 | xdminsy | (~xdminsy@117.147.71.221) (Ping timeout: 256 seconds) |
| 2024-02-07 19:12:56 +0100 | mei | (~mei@user/mei) |
| 2024-02-07 19:13:10 +0100 | mobivme | (~mobivme@130.105.162.31) |
| 2024-02-07 19:15:55 +0100 | PHO`_ | (~pho@akari.cielonegro.org) (Ping timeout: 260 seconds) |
| 2024-02-07 19:16:15 +0100 | dibblego | (~dibblego@122-199-1-93.ip4.superloop.au) |
| 2024-02-07 19:16:15 +0100 | dibblego | (~dibblego@122-199-1-93.ip4.superloop.au) (Changing host) |
| 2024-02-07 19:16:15 +0100 | dibblego | (~dibblego@haskell/developer/dibblego) |
| 2024-02-07 19:16:34 +0100 | PHO`_ | (~pho@2406:da14:856:600:e03a:2c8f:39c:7838) |
| 2024-02-07 19:23:05 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2024-02-07 19:23:55 +0100 | lambdaman | (~textual@d172-218-204-71.bchsia.telus.net) |
| 2024-02-07 19:33:35 +0100 | mc47 | (~mc47@xmonad/TheMC47) |
| 2024-02-07 19:34:31 +0100 | mobivme | (~mobivme@130.105.162.31) (Quit: ZNC 1.8.2+deb2build5 - https://znc.in) |
| 2024-02-07 19:35:16 +0100 | Nulldatamap95 | (~Nulldatam@80.71.142.55) |
| 2024-02-07 19:35:44 +0100 | Nulldatamap95 | (~Nulldatam@80.71.142.55) (Client Quit) |
| 2024-02-07 19:36:33 +0100 | mobivme | (~mobivme@130.105.162.31) |
| 2024-02-07 19:38:23 +0100 | dibblego | (~dibblego@haskell/developer/dibblego) (Ping timeout: 264 seconds) |
| 2024-02-07 19:38:35 +0100 | alexherbo2 | (~alexherbo@2a02-8440-3440-5654-4484-4a93-9fff-6f85.rev.sfr.net) (Remote host closed the connection) |
| 2024-02-07 19:38:55 +0100 | alexherbo2 | (~alexherbo@2a02-8440-3440-5654-4484-4a93-9fff-6f85.rev.sfr.net) |
| 2024-02-07 19:40:54 +0100 | Square | (~Square@user/square) |
| 2024-02-07 19:42:59 +0100 | mobivme | (~mobivme@130.105.162.31) (Ping timeout: 260 seconds) |
| 2024-02-07 19:44:19 +0100 | lambdaman | (~textual@d172-218-204-71.bchsia.telus.net) (Quit: My Mac has gone to sleep. ZZZzzz…) |
| 2024-02-07 19:46:28 +0100 | mobivme | (~mobivme@130.105.162.31) |
| 2024-02-07 19:47:17 +0100 | gmg | (~user@user/gehmehgeh) (Ping timeout: 255 seconds) |
| 2024-02-07 19:47:37 +0100 | Nulldatamap | (~Nulldatam@80.71.142.55) (Quit: Client closed) |
| 2024-02-07 19:49:27 +0100 | pavonia | (~user@user/siracusa) |
| 2024-02-07 19:49:29 +0100 | gmg | (~user@user/gehmehgeh) |
| 2024-02-07 19:49:53 +0100 | lambdaman | (~textual@172.218.204.71) |
| 2024-02-07 19:51:50 +0100 | lambdaman | (~textual@172.218.204.71) (Client Quit) |
| 2024-02-07 19:58:04 +0100 | lambdaman | (~textual@d172-218-204-71.bchsia.telus.net) |
| 2024-02-07 19:59:05 +0100 | mreh | (~matthew@host86-160-168-73.range86-160.btcentralplus.com) |
| 2024-02-07 19:59:32 +0100 | athan | (~athan@173-042-095-241.biz.spectrum.com) |
| 2024-02-07 19:59:34 +0100 | mobivme | (~mobivme@130.105.162.31) (Changing host) |
| 2024-02-07 19:59:34 +0100 | mobivme | (~mobivme@user/mobivme) |
| 2024-02-07 20:00:23 +0100 | lambdaman | (~textual@d172-218-204-71.bchsia.telus.net) (Client Quit) |
| 2024-02-07 20:02:29 +0100 | L29Ah | (~L29Ah@wikipedia/L29Ah) (Read error: Connection reset by peer) |
| 2024-02-07 20:08:01 +0100 | Raspbelly | (~Raspbelly@host-213-235-142-6.ip.topnet.cz) |
| 2024-02-07 20:09:09 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Read error: Connection reset by peer) |
| 2024-02-07 20:16:46 +0100 | waleee | (~waleee@h-176-10-144-38.NA.cust.bahnhof.se) |
| 2024-02-07 20:18:11 +0100 | wootehfoot | (~wootehfoo@user/wootehfoot) |
| 2024-02-07 20:20:53 +0100 | destituion | (~destituio@85.221.111.174) (Ping timeout: 268 seconds) |
| 2024-02-07 20:25:30 +0100 | mima | (~mmh@138.246.3.248) (Ping timeout: 268 seconds) |
| 2024-02-07 20:31:57 +0100 | mei | (~mei@user/mei) (Quit: mei) |
| 2024-02-07 20:34:49 +0100 | mobounce | (~mobivme@104.28.226.106) |
| 2024-02-07 20:36:26 +0100 | tri | (~tri@ool-18bbef1a.static.optonline.net) (Remote host closed the connection) |
| 2024-02-07 20:37:16 +0100 | destituion | (~destituio@2a02:2121:626:f551:c95:8f81:98cb:9432) |
| 2024-02-07 20:37:52 +0100 | mobivme | (~mobivme@user/mobivme) (Ping timeout: 276 seconds) |
| 2024-02-07 20:38:00 +0100 | chele | (~chele@user/chele) (Remote host closed the connection) |
| 2024-02-07 20:43:37 +0100 | califax | (~califax@user/califx) (Remote host closed the connection) |
| 2024-02-07 20:45:26 +0100 | califax | (~califax@user/califx) |
| 2024-02-07 20:51:07 +0100 | mei | (~mei@user/mei) |
| 2024-02-07 20:54:16 +0100 | califax | (~califax@user/califx) (Remote host closed the connection) |
| 2024-02-07 20:54:20 +0100 | califax_ | (~califax@user/califx) |
| 2024-02-07 20:54:28 +0100 | __monty__ | (~toonn@user/toonn) (Quit: leaving) |
| 2024-02-07 20:55:23 +0100 | Wstfgl0 | Me-me |
| 2024-02-07 20:55:25 +0100 | califax_ | califax |
| 2024-02-07 20:55:27 +0100 | Me-me | (~me-me@2602:ff16:3:0:1:dc:beef:d00d) (Changing host) |
| 2024-02-07 20:55:27 +0100 | Me-me | (~me-me@user/me-me) |
| 2024-02-07 20:57:19 +0100 | mobounce | (~mobivme@104.28.226.106) (Changing host) |
| 2024-02-07 20:57:20 +0100 | mobounce | (~mobivme@user/mobivme) |
| 2024-02-07 21:00:38 +0100 | <tomsmeding> | it's quite annoying that when using -XLinearTypes, if you have code that doesn't typecheck for mundane reasons, you more often than not get a multiplicity error and _nothing else_ |
| 2024-02-07 21:00:38 +0100 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Read error: Connection reset by peer) |
| 2024-02-07 21:00:49 +0100 | <tomsmeding> | like, I get it, forgetting an argument to a function makes the linearity fail |
| 2024-02-07 21:00:59 +0100 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) |
| 2024-02-07 21:01:03 +0100 | JordiGH | (~jordi@user/jordigh) (Remote host closed the connection) |
| 2024-02-07 21:01:20 +0100 | <tomsmeding> | but especially given that the multiplicity error is "cannot match Many with One on this thing all the way at the top of my function", which is utterly useless |
| 2024-02-07 21:01:22 +0100 | JordiGH | (~jordi@user/jordigh) |
| 2024-02-07 21:01:38 +0100 | <tomsmeding> | I cannot help but wish that GHC would check the mundane typing first, and linearity after :p |
| 2024-02-07 21:01:43 +0100 | <dminuoso_> | tomsmeding: Fits right into the mindset of the Haskell developer. We gave up on good type errors when we wanted a generalized good type inference long time ago. |
| 2024-02-07 21:01:54 +0100 | <tomsmeding> | or, even better, don't stop looking when you get a multiplicity error, and continue typechecking! |
| 2024-02-07 21:02:10 +0100 | L29Ah | (~L29Ah@wikipedia/L29Ah) |
| 2024-02-07 21:02:25 +0100 | mmhat | (~mmh@p200300f1c707a64cee086bfffe095315.dip0.t-ipconnect.de) (Quit: WeeChat 4.2.1) |
| 2024-02-07 21:02:39 +0100 | <dminuoso_> | Haskell developers will just cope with the horrible type errors that require you to know how GHC implements type checking in your head to figure out what any given type erorr means. |
| 2024-02-07 21:02:41 +0100 | <tomsmeding> | similar to how it's annoying that GHC completely throws its hands in the air when a parse error is raised -- this taught me to always add "in _" when I'm writing a let block |
| 2024-02-07 21:03:02 +0100 | <dminuoso_> | Cannot match `a0` with `a0` |
| 2024-02-07 21:03:04 +0100 | <dminuoso_> | Comes to mind. |
| 2024-02-07 21:03:13 +0100 | <dminuoso_> | "You had one job!" |
| 2024-02-07 21:03:17 +0100 | <tomsmeding> | I haven't had that one in quite a while, fortunately! :D |
| 2024-02-07 21:03:46 +0100 | <EvanR> | at least non-checking code doesn't make it through |
| 2024-02-07 21:04:05 +0100 | <dminuoso_> | See, thats what we keep telling ourselves why we accept that garbage. |
| 2024-02-07 21:04:16 +0100 | <EvanR> | which is the apparent objective of many languages these days that weren't originally designed to be type safe but are doing lip service to type safety after the fact |
| 2024-02-07 21:04:17 +0100 | <tomsmeding> | surely there are people trying to make ghc able to barrel through when an earlier pass raised an error, right? |
| 2024-02-07 21:04:24 +0100 | <tomsmeding> | this situation is painfully obvious with HLS |
| 2024-02-07 21:04:46 +0100 | <dminuoso_> | tomsmeding: Im not aware of any attempts of building type error slicing into GHC. |
| 2024-02-07 21:04:58 +0100 | tomsmeding | . o O ( "slicing?" ) |
| 2024-02-07 21:05:03 +0100 | <dminuoso_> | Which is what you would need to get enough context to figure out virtually any `cannot match...` type error. |
| 2024-02-07 21:05:08 +0100 | <tomsmeding> | ah |
| 2024-02-07 21:05:33 +0100 | <tomsmeding> | I would already be happy enough if GHC could continue with type checking even in the presence of a parse error in a completely unrelated part of the file! |
| 2024-02-07 21:05:47 +0100 | <dolio> | Doesn't seem like the linearity thing requires anything as extensive as type error slicing. |
| 2024-02-07 21:05:52 +0100 | <tomsmeding> | I'm fine with GHC giving up on that subexpression or something and replacing it with "undefined" for the duration of type checking |
| 2024-02-07 21:06:03 +0100 | <tomsmeding> | and similarly for linearity checking |
| 2024-02-07 21:06:05 +0100 | <tomsmeding> | yeah |
| 2024-02-07 21:06:35 +0100 | <tomsmeding> | well I'm not sure how hard it would be to make the multiplicity errors themselves less atrocious |
| 2024-02-07 21:06:44 +0100 | <tomsmeding> | so I'm not asking for that |
| 2024-02-07 21:06:59 +0100 | <tomsmeding> | just make it less obvious that these are separate passes in an error monad :p |
| 2024-02-07 21:07:11 +0100 | <dminuoso_> | dolio: Sorry, I wasnt trying to give an impression a type error slicer would help with linearity. |
| 2024-02-07 21:07:23 +0100 | <dolio> | I know. |
| 2024-02-07 21:07:29 +0100 | peterbecich | (~Thunderbi@047-229-123-186.res.spectrum.com) |
| 2024-02-07 21:08:35 +0100 | <tomsmeding> | my office in Utrecht has a small library (2-3 shelves) of a variety of PL-related books that past occupants have accumulated |
| 2024-02-07 21:09:00 +0100 | <tomsmeding> | one of those is "Top Quality Type Error Messages", the PhD thesis of someone who studied in Utrecht |
| 2024-02-07 21:09:30 +0100 | <tomsmeding> | perhaps the thing should be propaganda'd a bit more |
| 2024-02-07 21:09:42 +0100 | <dolio> | You probably don't need slicing to do better than GHC for normal type errors, either. |
| 2024-02-07 21:09:49 +0100 | lambdaman | (~textual@207.102.20.146) |
| 2024-02-07 21:09:57 +0100 | <tomsmeding> | probably not, but it's probably a lot of engineering work |
| 2024-02-07 21:10:01 +0100 | <dolio> | Yeah. |
| 2024-02-07 21:10:25 +0100 | bliminse | (~bliminse@user/bliminse) (Quit: leaving) |
| 2024-02-07 21:12:28 +0100 | bliminse | (~bliminse@user/bliminse) |
| 2024-02-07 21:12:45 +0100 | lambdaman | (~textual@207.102.20.146) (Read error: Connection reset by peer) |
| 2024-02-07 21:14:42 +0100 | <monochrom> | I use -fdefer-type-errors at early stages. That should be pretty close to "replace by undefined". |
| 2024-02-07 21:14:44 +0100 | tomsmeding | . o O ( parse >=> linearityCheck >=> typeCheck >=> (inferTypeClasses | unusedNamesCheck) ) |
| 2024-02-07 21:15:01 +0100 | <mauke> | no, we'd need -fdefer-parse-errors |
| 2024-02-07 21:15:03 +0100 | waleee | (~waleee@h-176-10-144-38.NA.cust.bahnhof.se) (Quit: updating system) |
| 2024-02-07 21:15:11 +0100 | <monochrom> | Oh, hahaha, yeah. |
| 2024-02-07 21:15:43 +0100 | <tomsmeding> | apparently a multiplicity mismatch is not a deferrable type error! |
| 2024-02-07 21:15:52 +0100 | <monochrom> | :( |
| 2024-02-07 21:15:55 +0100 | <tomsmeding> | so we need -fdefer-parse-errors _and_ -fdefer-multiplicity-errors! |
| 2024-02-07 21:16:06 +0100 | <tomsmeding> | owait |
| 2024-02-07 21:16:09 +0100 | <tomsmeding> | it's HLS! |
| 2024-02-07 21:16:10 +0100 | <mauke> | which I think is provided by some INTERCAL implemnetation (just-too-late compilation?) |
| 2024-02-07 21:16:13 +0100 | <dolio> | I wonder if that's not surprising, actually. |
| 2024-02-07 21:16:19 +0100 | peterbecich | (~Thunderbi@047-229-123-186.res.spectrum.com) (Ping timeout: 256 seconds) |
| 2024-02-07 21:16:22 +0100 | <monochrom> | I don't use HLS. Good riddance. :) |
| 2024-02-07 21:16:23 +0100 | <EvanR> | defer all errors until after the program runs successfully |
| 2024-02-07 21:16:28 +0100 | <tomsmeding> | GHC gives multiplicity errors and type errors all together, it's HLS that just shows the multiplicity error and nothing else |
| 2024-02-07 21:16:30 +0100 | dibblego | (~dibblego@122.199.1.93) |
| 2024-02-07 21:16:30 +0100 | dibblego | (~dibblego@122.199.1.93) (Changing host) |
| 2024-02-07 21:16:30 +0100 | dibblego | (~dibblego@haskell/developer/dibblego) |
| 2024-02-07 21:16:30 +0100 | <EvanR> | accomplishing the actual mission |
| 2024-02-07 21:16:34 +0100 | <EvanR> | then error all you want |
| 2024-02-07 21:16:45 +0100 | waleee | (~waleee@h-176-10-144-38.NA.cust.bahnhof.se) |
| 2024-02-07 21:16:52 +0100 | <dolio> | Like, can inserting `error` into code violate multiplicity requirements? |
| 2024-02-07 21:16:58 +0100 | <monochrom> | @quote monochrom hugs |
| 2024-02-07 21:16:59 +0100 | <lambdabot> | No quotes match. Maybe if you used more than just two fingers... |
| 2024-02-07 21:17:03 +0100 | <monochrom> | :( |
| 2024-02-07 21:17:14 +0100 | <tomsmeding> | lambdabot's reprimands are funny sometimes |
| 2024-02-07 21:17:20 +0100 | <tomsmeding> | would this be worth an HLS bug report |
| 2024-02-07 21:17:21 +0100 | <monochrom> | I had a saying "hugs turns compile-time errors to run-time errors" >:) |
| 2024-02-07 21:17:33 +0100 | <tomsmeding> | hugs is kinder to the programmer |
| 2024-02-07 21:17:43 +0100 | <dolio> | Because you're throwing away a value. |
| 2024-02-07 21:17:49 +0100 | <tomsmeding> | it's in the name |
| 2024-02-07 21:17:52 +0100 | <monochrom> | :) |
| 2024-02-07 21:18:19 +0100 | <tomsmeding> | dolio: my intuition says that you should be able to strategically insert 'error', yes |
| 2024-02-07 21:18:38 +0100 | waleee | (~waleee@h-176-10-144-38.NA.cust.bahnhof.se) (Client Quit) |
| 2024-02-07 21:18:46 +0100 | <dolio> | Hmm. |
| 2024-02-07 21:18:51 +0100 | <tomsmeding> | but that's intuition |
| 2024-02-07 21:18:56 +0100 | waleee | (~waleee@h-176-10-144-38.NA.cust.bahnhof.se) |
| 2024-02-07 21:19:28 +0100 | <monochrom> | Perhaps insert one of "error (show x)", "error (show x ++ show x)", "error (show x ++ show x ++ show x)" etc to match multiplicity >:) |
| 2024-02-07 21:19:49 +0100 | <tomsmeding> | oh |
| 2024-02-07 21:20:09 +0100 | <tomsmeding> | hm, you can break linearity guarantees with asynchronous exceptions anyway |
| 2024-02-07 21:20:13 +0100 | <dolio> | I was worried more that all of those are technically 0 uses of `x` or something. |
| 2024-02-07 21:20:18 +0100 | <tomsmeding> | so does error have anything to uphold? >:D |
| 2024-02-07 21:21:08 +0100 | <tomsmeding> | adding x'es in the argument to 'error' won't fix the multiplicities anyway, because some of those x'es should be returned from the error as well |
| 2024-02-07 21:21:22 +0100 | <tomsmeding> | but the point would be that fuck that, we're crashing anyway |
| 2024-02-07 21:21:27 +0100 | <monochrom> | Yeah I was just joking. :) |
| 2024-02-07 21:21:45 +0100 | <tomsmeding> | proof obligation would be that the error is indeed evaluated whenever you would run code that could depend on the linear computation completing |
| 2024-02-07 21:21:50 +0100 | <tomsmeding> | or something |
| 2024-02-07 21:21:53 +0100 | tomsmeding | waves hands |
| 2024-02-07 21:22:22 +0100 | <dolio> | Also, I seem to recall the asynchronous thing is a flawed argument. |
| 2024-02-07 21:23:22 +0100 | <dolio> | The checker is supposed to ensure that actually running the code results in linear behavior. Not that the behavior is ensured by interrupting it at an arbitrary point. |
| 2024-02-07 21:24:50 +0100 | <tomsmeding> | you're probably right, but can't I have a linear File or something that I can open and do something with, but then before closing I crash with an asynchronous exception |
| 2024-02-07 21:25:02 +0100 | <tomsmeding> | which I catch in IO, after which I happily continue, but now I've leaked a file descriptor |
| 2024-02-07 21:25:12 +0100 | <tomsmeding> | which was against the contract of the linearity |
| 2024-02-07 21:25:20 +0100 | <dolio> | Yes. |
| 2024-02-07 21:25:39 +0100 | mobounce | (~mobivme@user/mobivme) (Ping timeout: 260 seconds) |
| 2024-02-07 21:27:39 +0100 | <dolio> | That doesn't mean that code that throws away values counts as linear, though. |
| 2024-02-07 21:28:39 +0100 | <dolio> | It means that for linear code to ensure what you want, you can't interrupt it in the middle, or something. |
| 2024-02-07 21:28:47 +0100 | dibblego | (~dibblego@haskell/developer/dibblego) (Ping timeout: 264 seconds) |
| 2024-02-07 21:29:09 +0100 | mima | (~mmh@aftr-62-216-211-118.dynamic.mnet-online.de) |
| 2024-02-07 21:30:06 +0100 | wootehfoot | (~wootehfoo@user/wootehfoot) (Read error: Connection reset by peer) |
| 2024-02-07 21:30:59 +0100 | <tomsmeding> | right |
| 2024-02-07 21:31:13 +0100 | <tomsmeding> | I guess you can always kill the process from outside :p |
| 2024-02-07 21:31:28 +0100 | <tomsmeding> | makes your error idea even more likely to work |
| 2024-02-07 21:31:47 +0100 | <tomsmeding> | "work" meaning "doesn't introduce new breakage of linearity invariants" |
| 2024-02-07 21:36:44 +0100 | <dolio> | The async thing leads me to believe you can't just insert `error` for ill-formed subexpressions, though. At least, it'd have to have some particular linear type. |
| 2024-02-07 21:37:23 +0100 | <tomsmeding> | to make the linearity checker happy, you mean? |
| 2024-02-07 21:37:28 +0100 | <dolio> | Like, whichever type has the rule that lets you deduce `Γ ⊢ t : T` from no premises. |
| 2024-02-07 21:37:36 +0100 | <dolio> | Yeah. |
| 2024-02-07 21:38:02 +0100 | <dolio> | Whichever 'unit' lets you eat as many premises as you want. |
| 2024-02-07 21:38:04 +0100 | <tomsmeding> | wasn't the idea that we were implementing -fdefer-multiplicity-errors and hence we already gave up making the checker happy, we're just inserting errors wherever the checks failed? |
| 2024-02-07 21:39:48 +0100 | <dolio> | I don't know. That isn't how -fdefer-type-errors works, is it? The latter is based on the premise that you can automatically improve ill-typed code to well-typed code by inserting ⊥ in places, right? |
| 2024-02-07 21:40:04 +0100 | <tomsmeding> | hm, I guess |
| 2024-02-07 21:40:27 +0100 | <tomsmeding> | that fundamentally isn't going to fly for linearity errors |
| 2024-02-07 21:40:44 +0100 | slackwear | (~slackwear@137.220.66.70) |
| 2024-02-07 21:41:05 +0100 | <tomsmeding> | the question is, then, if we can at least make the computation raise an error whenever it would have relied on linearity of the incorrect code |
| 2024-02-07 21:41:18 +0100 | alexherbo2 | (~alexherbo@2a02-8440-3440-5654-4484-4a93-9fff-6f85.rev.sfr.net) (Remote host closed the connection) |
| 2024-02-07 21:41:31 +0100 | mc47 | (~mc47@xmonad/TheMC47) (Remote host closed the connection) |
| 2024-02-07 21:41:38 +0100 | alexherbo2 | (~alexherbo@2a02-8440-3440-5654-4484-4a93-9fff-6f85.rev.sfr.net) |
| 2024-02-07 21:54:03 +0100 | forell | (~forell@user/forell) (Quit: ZNC - https://znc.in) |
| 2024-02-07 21:54:34 +0100 | mreh | (~matthew@host86-160-168-73.range86-160.btcentralplus.com) (Ping timeout: 264 seconds) |
| 2024-02-07 21:54:57 +0100 | forell | (~forell@user/forell) |
| 2024-02-07 21:56:07 +0100 | Square3 | (~Square4@user/square) |
| 2024-02-07 21:56:38 +0100 | manwithluck | (manwithluc@gateway/vpn/protonvpn/manwithluck) |
| 2024-02-07 21:57:09 +0100 | michalz | (~michalz@185.246.207.217) (Ping timeout: 272 seconds) |
| 2024-02-07 21:57:51 +0100 | Square | (~Square@user/square) (Ping timeout: 260 seconds) |
| 2024-02-07 21:58:59 +0100 | michalz | (~michalz@185.246.207.193) |
| 2024-02-07 22:03:37 +0100 | JordiGH | (~jordi@user/jordigh) (Ping timeout: 260 seconds) |
| 2024-02-07 22:05:47 +0100 | fansly | (~fansly@2001:448a:2010:476e:5df1:ad02:fa1f:3df1) (Remote host closed the connection) |
| 2024-02-07 22:07:32 +0100 | _ht | (~Thunderbi@28-52-174-82.ftth.glasoperator.nl) (Remote host closed the connection) |
| 2024-02-07 22:08:47 +0100 | alexherbo2 | (~alexherbo@2a02-8440-3440-5654-4484-4a93-9fff-6f85.rev.sfr.net) (Remote host closed the connection) |
| 2024-02-07 22:09:07 +0100 | alexherbo2 | (~alexherbo@2a02-8440-3440-5654-4484-4a93-9fff-6f85.rev.sfr.net) |
| 2024-02-07 22:11:09 +0100 | mechap | (~mechap@user/mechap) (Ping timeout: 256 seconds) |
| 2024-02-07 22:11:12 +0100 | <ski> | tomsmeding : "Skalpel: A Type Error Slicer for SML" (also see <https://web.archive.org/web/20220617202754/http://www.macs.hw.ac.uk/ultra/skalpel/>,<https://github.com/ultra-group/skalpel>) by Vincent Rahli,Joe Wells,John Pirie,Fairouz Kamareddine in 2014 at <https://www.macs.hw.ac.uk/~fairouz/forest/papers/conference-publications/lsfa14.pdf> |
| 2024-02-07 22:11:54 +0100 | mreh | (~matthew@host86-160-168-73.range86-160.btcentralplus.com) |
| 2024-02-07 22:12:06 +0100 | manwithluck | (manwithluc@gateway/vpn/protonvpn/manwithluck) (Quit: THE END) |
| 2024-02-07 22:12:23 +0100 | <ski> | tomsmeding : type error slicing finds all and only the locations that contribute to a type error (rather than just the one where the error was noticed). at least one of these locations must be changed (and perhaps then others, in chain-reaction) in order to resolve the issue |
| 2024-02-07 22:12:26 +0100 | manwithluck | (manwithluc@gateway/vpn/protonvpn/manwithluck) |
| 2024-02-07 22:13:04 +0100 | <ski> | dolio : the additive conjunction unit |
| 2024-02-07 22:13:10 +0100 | mechap | (~mechap@user/mechap) |
| 2024-02-07 22:13:21 +0100 | <ski> | (aka `erase', in Lolli) |
| 2024-02-07 22:13:58 +0100 | <tomsmeding> | ski: right -- I've seen the term before, I wasn't quite sure about the details any more |
| 2024-02-07 22:14:37 +0100 | <tomsmeding> | but as I was trying to say, GHC need not do any type error slicing and there would still be a lot to improve :p |
| 2024-02-07 22:14:49 +0100 | Raspbelly | (~Raspbelly@host-213-235-142-6.ip.topnet.cz) (Ping timeout: 264 seconds) |
| 2024-02-07 22:14:50 +0100 | <tomsmeding> | though apparently some of the blame lies with HLS here |
| 2024-02-07 22:16:00 +0100 | <ski> | do you know in which way ? |
| 2024-02-07 22:16:34 +0100 | <dolio> | ski: Is that ⊤? |
| 2024-02-07 22:17:17 +0100 | <ski> | @where+ skalpel "Skalpel: A Type Error Slicer for SML" by Vincent Rahli,Joe Wells,John Pirie,Fairouz Kamareddine in 2014 at <https://www.macs.hw.ac.uk/~fairouz/forest/papers/conference-publications/lsfa14.pdf>, also see <https://web.archive.org/web/20220617202754/http://www.macs.hw.ac.uk/ultra/skalpel/>,<https://github.com/ultra-group/skalpel> |
| 2024-02-07 22:17:18 +0100 | <lambdabot> | It is stored. |
| 2024-02-07 22:17:51 +0100 | <ski> | dolio : yes, that's the traditional (Girard) symbol for it |
| 2024-02-07 22:17:56 +0100 | mobivme | (~mobivme@104.28.226.106) |
| 2024-02-07 22:18:54 +0100 | <dolio> | Okay, and ⊤ is dual to 0? |
| 2024-02-07 22:18:54 +0100 | <ski> | (i, in personal notes, swap the symbols for additive and multiplicative conjunctive neutral element, though .. as well as changing some of the other symbols. also istr Blass or someone else using some other variant notation) |
| 2024-02-07 22:19:17 +0100 | <ski> | to additive disjunction neutral element, aka "void", yes |
| 2024-02-07 22:19:56 +0100 | moixa | (~moixa@customer-178-16-208-85.stosn.net) (Quit: leaving) |
| 2024-02-07 22:20:15 +0100 | <tomsmeding> | ski: "do you know in which way" -- what blame lies with HLS, you mean? |
| 2024-02-07 22:20:23 +0100 | <ski> | yep |
| 2024-02-07 22:20:58 +0100 | <tomsmeding> | when GHC gives multiplicity errors as well as some other type errors, HLS only reports the multiplicity errors |
| 2024-02-07 22:21:09 +0100 | fansly | (~fansly@2001:448a:2010:476e:5df1:ad02:fa1f:3df1) |
| 2024-02-07 22:21:20 +0100 | <tomsmeding> | easy reproducer is `{-# LANGUAGE LinearTypes #-} foo :: Int %1-> Int ; foo _ = id` |
| 2024-02-07 22:21:31 +0100 | <tomsmeding> | 'ghc -c that.hs' gives 2 diagnostics, HLS gives only one |
| 2024-02-07 22:22:07 +0100 | <tomsmeding> | I reported that in #haskell-language-server about an hour ago, I'll see if someone bites |
| 2024-02-07 22:22:41 +0100 | <ski> | tomsmeding : "Top Quality Error Messages" by Bastiaan J. Heeren in 2005-09-20 at <https://dspace.library.uu.nl/handle/1874/7297> ? |
| 2024-02-07 22:22:47 +0100 | <tomsmeding> | yes :) |
| 2024-02-07 22:22:54 +0100 | <tomsmeding> | though there is a Type in there as well |
| 2024-02-07 22:23:03 +0100 | <ski> | ah, right |
| 2024-02-07 22:23:29 +0100 | <tomsmeding> | disclaimer, I haven't read the thing at all -- I just have a vague idea what's in there because I have an idea of what Jurriaan Hage was working on around that time with Helium |
| 2024-02-07 22:25:06 +0100 | <ski> | ah, i remember reading about Helium |
| 2024-02-07 22:25:15 +0100 | fansly | (~fansly@2001:448a:2010:476e:5df1:ad02:fa1f:3df1) (Remote host closed the connection) |
| 2024-02-07 22:25:19 +0100 | <ski> | @where helium |
| 2024-02-07 22:25:19 +0100 | <lambdabot> | Haskell subset for beginners, improved diagnostics (incl. eDSLs). See <https://github.com/Helium4Haskell/helium>,<https://hackage.haskell.org/package/helium>,<https://web.archive.org/web/2016062422224 |
| 2024-02-07 22:25:19 +0100 | <lambdabot> | 0/http://foswiki.cs.uu.nl/foswiki/Helium/WebHome>,<https://web.archive.org/web/20210907032911/http://www.cs.uu.nl/research/projects/helium/>,<https://www.open.ou.nl/bhr/HeliumCompiler.html> |
| 2024-02-07 22:25:42 +0100 | <tomsmeding> | uu clearly doesn't care about stable links :( |
| 2024-02-07 22:26:10 +0100 | mud | (~mud@user/kadoban) |
| 2024-02-07 22:32:13 +0100 | dibblego | (~dibblego@haskell/developer/dibblego) |
| 2024-02-07 22:33:05 +0100 | Erutuon | (~Erutuon@user/erutuon) |
| 2024-02-07 22:36:46 +0100 | Achylles | (~Achylles_@45.182.57.94) (Remote host closed the connection) |
| 2024-02-07 22:37:09 +0100 | fansly | (~fansly@2001:448a:2010:476e:5df1:ad02:fa1f:3df1) |
| 2024-02-07 22:49:01 +0100 | fansly | (~fansly@2001:448a:2010:476e:5df1:ad02:fa1f:3df1) (Ping timeout: 264 seconds) |
| 2024-02-07 22:49:29 +0100 | turlando | (~turlando@user/turlando) (Remote host closed the connection) |
| 2024-02-07 22:50:43 +0100 | turlando | (~turlando@user/turlando) |
| 2024-02-07 22:52:25 +0100 | mreh | (~matthew@host86-160-168-73.range86-160.btcentralplus.com) (Ping timeout: 276 seconds) |
| 2024-02-07 22:52:33 +0100 | manwithluck | (manwithluc@gateway/vpn/protonvpn/manwithluck) (Read error: Connection reset by peer) |
| 2024-02-07 22:52:56 +0100 | manwithluck | (manwithluc@gateway/vpn/protonvpn/manwithluck) |
| 2024-02-07 22:53:43 +0100 | fansly | (~fansly@103.3.221.233) |
| 2024-02-07 23:00:12 +0100 | sp1ff | (~user@24.21.45.157) (Remote host closed the connection) |
| 2024-02-07 23:01:29 +0100 | rscastilho2024 | (~rscastilh@189.61.140.215) |
| 2024-02-07 23:02:23 +0100 | rscastilho2024 | (~rscastilh@189.61.140.215) (Remote host closed the connection) |
| 2024-02-07 23:03:56 +0100 | kadobanana | (~mud@user/kadoban) |
| 2024-02-07 23:04:17 +0100 | mud | (~mud@user/kadoban) (Ping timeout: 272 seconds) |
| 2024-02-07 23:15:41 +0100 | takuan | (~takuan@178-116-218-225.access.telenet.be) (Remote host closed the connection) |
| 2024-02-07 23:22:29 +0100 | mobivme | (~mobivme@104.28.226.106) (Ping timeout: 252 seconds) |
| 2024-02-07 23:26:36 +0100 | JordiGH | (~jordi@user/jordigh) |
| 2024-02-07 23:26:42 +0100 | coot | (~coot@89-69-206-216.dynamic.chello.pl) (Quit: coot) |
| 2024-02-07 23:28:36 +0100 | mobivme | (~mobivme@104.28.194.106) |
| 2024-02-07 23:38:31 +0100 | [itchyjunk] | (~itchyjunk@user/itchyjunk/x-7353470) |
| 2024-02-07 23:51:48 +0100 | mei | (~mei@user/mei) (Remote host closed the connection) |
| 2024-02-07 23:51:52 +0100 | azimut | (~azimut@gateway/tor-sasl/azimut) |
| 2024-02-07 23:56:48 +0100 | analognoise | (~analognoi@ip98-176-154-48.sd.sd.cox.net) |
| 2024-02-07 23:57:14 +0100 | analognoise | (~analognoi@ip98-176-154-48.sd.sd.cox.net) (Remote host closed the connection) |
| 2024-02-07 23:59:21 +0100 | mei | (~mei@user/mei) |