Logs: freenode/#haskell
| 2020-11-05 15:37:17 | <ski> | @quote world's.best |
| 2020-11-05 15:37:17 | <lambdabot> | _pizza_ says: i think Haskell is undoubtedly the world's best programming language for discovering the first few dozen numbers in the Fibonacci sequence over IRC |
| 2020-11-05 15:37:45 | <ski> | @quote SPJ world's.best |
| 2020-11-05 15:37:45 | <lambdabot> | SPJ says: Haskell is the world's best imperative language. |
| 2020-11-05 15:38:00 | hackage | domain-optics 0.1 - Integration of domain with optics https://hackage.haskell.org/package/domain-optics-0.1 (NikitaVolkov) |
| 2020-11-05 15:39:02 | <ski> | part of the point of that quip is the first-classness. but another part, i'd argue, is that, because there's no side-effects, we can employ equational reasoning everywhere, commuting, duplicating and discarding, which wouldn't be valid in the presence of side-effects |
| 2020-11-05 15:39:59 | × | toorevitimirp quits (~tooreviti@117.182.183.132) (Remote host closed the connection) |
| 2020-11-05 15:40:23 | × | mmohammadi9812 quits (~mmohammad@188.210.113.223) (Ping timeout: 258 seconds) |
| 2020-11-05 15:42:11 | <ski> | re their point about already knowing what side-effects a procedure performs, if one knows what it's intended to do, i'd disagree. you could easily use a library-function that depends on some mutable state being set up to an appropriate, or some thread/process/service being started, and people do add such things to implementations without noting it in the interface |
| 2020-11-05 15:42:21 | → | Sgeo joins (~Sgeo@ool-18b982ad.dyn.optonline.net) |
| 2020-11-05 15:42:56 | <akegalj> | ski: haha, I love quote thing :D Didn't know about that |
| 2020-11-05 15:43:55 | → | wroathe joins (~wroathe@c-68-54-25-135.hsd1.mn.comcast.net) |
| 2020-11-05 15:44:22 | → | heatsink joins (~heatsink@107-136-5-69.lightspeed.sntcca.sbcglobal.net) |
| 2020-11-05 15:44:38 | <ski> | so a compiler-enforced checking of what effects an operation could possibly do could be useful then. and having a tool (like compiler ior IDE) infer effects would sometimes not be enough, since we'd want to check expectations (at some interface level, the effects are private, can't leak, say) |
| 2020-11-05 15:45:15 | → | thir joins (~thir@p200300f27f0b7e00f4e9381c2bf90854.dip0.t-ipconnect.de) |
| 2020-11-05 15:45:40 | × | mimi_vx quits (~mimi@tulipan.habr.nat.praha12.net) (Ping timeout: 246 seconds) |
| 2020-11-05 15:46:08 | <ski> | (still, `IO' is a very crude sort of tracking. all-or-nothing. no ability to dicern more specifically what kind of effects can occur. that can sometimes be a problem, yes) |
| 2020-11-05 15:46:48 | → | cr3 joins (~cr3@192-222-143-195.qc.cable.ebox.net) |
| 2020-11-05 15:47:32 | <ski> | also, i'd take issue with their "Effect-Tracked Java™", that it doesn't provide the same (reasoning) convenience as with the Haskell situation .. unless one adds some syntactic salt not only annotating the interfaces of operations, but also requiring each call to a side-effectful operation to be annotated in a way to highlight this |
| 2020-11-05 15:48:49 | × | heatsink quits (~heatsink@107-136-5-69.lightspeed.sntcca.sbcglobal.net) (Ping timeout: 246 seconds) |
| 2020-11-05 15:49:13 | <ski> | (Mercury is a language that has such a purity system, where impure (and semipure) calls must be annotated with syntactic salt `impure' and `semipure'. note that the purity system is primarily intended for FFI stuff, though. there's a separate `io' system, which is similar to the `World' that is uniquely passed around in Clean, and still also somewhat (albeit less) similar to `IO' in Haskell) |
| 2020-11-05 15:50:06 | <ski> | the point is that, without some such syntactic salt, you'll have to look up the interface of called operations, to check whether they may have side-effects. rather than seeing it directly there, in the source |
| 2020-11-05 15:50:52 | <ski> | (with IDE support, this could be less of an issue. but then there's a separate argument that perhaps it's a good thing to not have to rely on an IDE .. this can be discussed forward and back) |
| 2020-11-05 15:51:55 | <ski> | with such syntactic salt, you'll be alerted when you're interchanging the order of two side-effecting operations, or duplicating/factoring one, or discarding one, that the effects expressed might not be the same |
| 2020-11-05 15:52:09 | × | berberman quits (~berberman@unaffiliated/berberman) (Quit: ZNC 1.7.5 - https://znc.in) |
| 2020-11-05 15:52:21 | → | mmohammadi9812 joins (~mmohammad@188.210.99.150) |
| 2020-11-05 15:52:39 | → | berberman joins (~berberman@unaffiliated/berberman) |
| 2020-11-05 15:52:52 | <ski> | btw, note that Java does track exceptions (in a fine-grained manner). exceptions are another kind of side-effect |
| 2020-11-05 15:53:41 | <akegalj> | how does java track exceptions? |
| 2020-11-05 15:53:45 | <ski> | (it's also debatable whether the fine-grained tracking is good or not. note that the `IO' exceptions in Haskell are not tracked in fine-grained way) |
| 2020-11-05 15:53:57 | <ski> | `throws' clause attached to method signatures |
| 2020-11-05 15:53:58 | <merijn> | ski: Which was a massive mistake >.> |
| 2020-11-05 15:54:05 | <ski> | merijn : which ? |
| 2020-11-05 15:54:13 | <merijn> | unchecked exceptions in Haskell |
| 2020-11-05 15:54:54 | veverak | is now known as [[[]]] |
| 2020-11-05 15:55:29 | → | wltjr1 joins (~wltjr@84.39.116.180) |
| 2020-11-05 15:55:32 | <ski> | in Haskell, the `<$>' in e.g. `reverse <$> getLine' is comparable to the aforementioned syntactic salt |
| 2020-11-05 15:55:48 | → | ahmr88 joins (~ahmr88@cpc85006-haye22-2-0-cust131.17-4.cable.virginm.net) |
| 2020-11-05 15:57:00 | <ski> | (here, one can argue, that it would be better to annotate just the specific effectful calls, rather than the path down to them in the AST. i have experimented a little with some ideas for a "effect reflection syntax" that would address this) |
| 2020-11-05 15:57:18 | → | nbloomf joins (~nbloomf@2600:1700:ad14:3020:b093:9754:189c:f0eb) |
| 2020-11-05 15:58:37 | <akegalj> | ski: you are right, I forgot that java tracks exceptions https://docs.oracle.com/javase/tutorial/essential/exceptions/declaring.html |
| 2020-11-05 15:58:49 | → | kaychaks joins (sid236345@gateway/web/irccloud.com/x-tofmstsbickuunjr) |
| 2020-11-05 15:59:28 | <ski> | akegalj : still, interesting, thought-provoking, blag |
| 2020-11-05 16:00:04 | <akegalj> | ski: yes, thanks for your input. It was interesting read |
| 2020-11-05 16:00:06 | × | GuillaumeChrel[m quits (guillaumec@gateway/shell/matrix.org/x-yyvevfplzzioqnuc) (Quit: Idle for 30+ days) |
| 2020-11-05 16:00:06 | × | tttom[m] quits (tttommatri@gateway/shell/matrix.org/x-odejmlhnpwjjtcrh) (Quit: Idle for 30+ days) |
| 2020-11-05 16:00:06 | × | jiribenes1 quits (jbjiribene@gateway/shell/matrix.org/x-bgfmaawtdxevtslk) (Quit: Idle for 30+ days) |
| 2020-11-05 16:00:06 | × | ethercrow[m] quits (ethercrowm@gateway/shell/matrix.org/x-fwdkmrqysffhdlhg) (Quit: Idle for 30+ days) |
| 2020-11-05 16:00:06 | × | albestro[m] quits (albestroma@gateway/shell/matrix.org/x-qdbcqirfearydihj) (Quit: Idle for 30+ days) |
| 2020-11-05 16:00:44 | → | Rudd0 joins (~Rudd0@185.189.115.103) |
| 2020-11-05 16:01:32 | × | cosimone quits (~cosimone@2001:b07:ae5:db26:d849:743b:370b:b3cd) (Quit: cosimone) |
| 2020-11-05 16:01:53 | <ski> | akegalj : anyway .. to repeat, the author doesn't appear to make the distinction between "effect" and "side-effect". it's this distinction (present in the implementation code, not just in interfaces) that enables one to tell that one can use powerful equational reasoning & refactoring in the former case, and less powerful such in the latter case |
| 2020-11-05 16:04:08 | × | thir quits (~thir@p200300f27f0b7e00f4e9381c2bf90854.dip0.t-ipconnect.de) (Remote host closed the connection) |
| 2020-11-05 16:04:10 | × | nbloomf quits (~nbloomf@2600:1700:ad14:3020:b093:9754:189c:f0eb) (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 2020-11-05 16:04:13 | <ski> | if you have `do x <- foo; y <- bar; frob x y', in `ST s', say, and you happen to know that the state that `foo' interacts with is independent of the state that `bar' interacts with, then you can of course refactor this to `do y <- bar; x <- foo; frob x y'. but this independence is not tracked (no fine-grained state tracking) |
| 2020-11-05 16:04:15 | → | thir joins (~thir@p200300f27f0b7e00f4e9381c2bf90854.dip0.t-ipconnect.de) |
| 2020-11-05 16:04:22 | × | twopoint718 quits (~cjw@fsf/member/twopoint718) (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 2020-11-05 16:04:50 | × | wroathe quits (~wroathe@c-68-54-25-135.hsd1.mn.comcast.net) (Ping timeout: 260 seconds) |
| 2020-11-05 16:06:07 | <ski> | in some monads or idioms, you may know that their effects are discardable, so that if you don't use the result of an action, then the action may be omitted. or perhaps you know that all effects commute, or possibly that they're duplicable (presumably some caching is going on, then) |
| 2020-11-05 16:07:21 | → | wroathe joins (~wroathe@c-73-24-27-54.hsd1.mn.comcast.net) |
| 2020-11-05 16:08:12 | <ski> | in Mercury, semipure predicate calls commutes with each other (and are also discardable and duplicable, iirc), but doesn't commute with impure ones. semipure ones may e.g. read some mutable state, but may not change it |
| 2020-11-05 16:10:11 | <akegalj> | goes to look at Mercury... |
| 2020-11-05 16:10:45 | × | o1lo01ol1o quits (~o1lo01ol1@bl8-213-81.dsl.telepac.pt) (Remote host closed the connection) |
| 2020-11-05 16:11:25 | <akegalj> | ski: hm, thats interesting distinction between pure and semipure |
| 2020-11-05 16:11:38 | <ski> | (<https://www.mercurylang.org/information/doc-latest/mercury_ref/Impurity.html> is the relevant manual section on that. also see " Using impurity to create declarative interfaces in Mercury" by Tyson Dowd,Peter Schachte,Fergus Henderson,Zoltan Somogyi in 2000-04 at <https://www.mercurylang.org/documentation/papers.html#purity>) |
| 2020-11-05 16:12:02 | → | mimi_vx joins (~mimi@2a01:490:16:1026:9892:f269:767a:6ad7) |
| 2020-11-05 16:13:55 | → | mimi1vx joins (~mimi@tulipan.habr.nat.praha12.net) |
| 2020-11-05 16:14:01 | × | machinedgod quits (~machinedg@142.169.78.227) (Ping timeout: 246 seconds) |
| 2020-11-05 16:15:13 | → | o1lo01ol1o joins (~o1lo01ol1@bl8-213-81.dsl.telepac.pt) |
| 2020-11-05 16:15:30 | → | nbloomf joins (~nbloomf@2600:1700:ad14:3020:b093:9754:189c:f0eb) |
| 2020-11-05 16:16:10 | <akegalj> | ski: that's enough info atm. I have to groak this info and think about it for a while to form some opinion. Thanks a lot for references and all input <3 . *akegalj* Goes for a walk to reflect |
| 2020-11-05 16:16:12 | → | machinedgod joins (~machinedg@207.253.244.210) |
| 2020-11-05 16:16:16 | → | hnOsmium0001 joins (uid453710@gateway/web/irccloud.com/x-yyqyliwcbydyqmwb) |
| 2020-11-05 16:16:53 | × | mimi_vx quits (~mimi@2a01:490:16:1026:9892:f269:767a:6ad7) (Ping timeout: 272 seconds) |
| 2020-11-05 16:17:31 | hackage | generic-data 0.9.2.0 - Deriving instances with GHC.Generics and related utilities https://hackage.haskell.org/package/generic-data-0.9.2.0 (lyxia) |
| 2020-11-05 16:18:00 | <hololeap> | is there a way to merge two `ConduitT () o m ()` streams, so that they will yield `o`s in the same temporal order that they are produced in both streams? |
| 2020-11-05 16:18:36 | <hololeap> | e.g. writing stdout and stderr to the same file, in the order that each meassage is produced |
| 2020-11-05 16:18:47 | <hololeap> | s/message/line of text/ |
| 2020-11-05 16:18:48 | × | ClaudiusMaximus quits (~claude@unaffiliated/claudiusmaximus) (Read error: Connection reset by peer) |
| 2020-11-05 16:19:32 | → | u0_a298 joins (~user@47.206.148.226) |
| 2020-11-05 16:19:41 | <merijn> | hololeap: That...is not a sensical question :) |
| 2020-11-05 16:19:55 | × | ahmr88 quits (~ahmr88@cpc85006-haye22-2-0-cust131.17-4.cable.virginm.net) (Remote host closed the connection) |
| 2020-11-05 16:20:02 | <merijn> | hololeap: because conduit produces a sequential loop |
| 2020-11-05 16:20:16 | <merijn> | hololeap: There is no "temporal order" |
| 2020-11-05 16:20:32 | <hololeap> | ok, that's kind of what i was afraid of |
| 2020-11-05 16:20:33 | → | heatsink joins (~heatsink@107-136-5-69.lightspeed.sntcca.sbcglobal.net) |
| 2020-11-05 16:20:55 | <merijn> | hololeap: If you run the two conduits and dump them into a channel, then you can have another conduit reading from the channel |
| 2020-11-05 16:21:41 | × | britva quits (~britva@31-10-157-156.cgn.dynamic.upc.ch) (Quit: This computer has gone to sleep) |
| 2020-11-05 16:21:52 | <merijn> | hololeap: What are the original streams? |
| 2020-11-05 16:22:11 | → | justsomeguy joins (~justsomeg@unaffiliated/--/x-3805311) |
| 2020-11-05 16:22:24 | → | enva2712 joins (~enva2712@cpe-75-86-42-2.wi.res.rr.com) |
| 2020-11-05 16:22:43 | → | twopoint718 joins (~cjw@fsf/member/twopoint718) |
| 2020-11-05 16:22:49 | <hololeap> | the stdout and stderr streams shown here: https://hackage.haskell.org/package/conduit-extra-1.3.5/docs/Data-Conduit-Process.html#v:sourceProcessWithStreams |
| 2020-11-05 16:22:58 | → | stef204 joins (~stef204@unaffiliated/stef-204/x-384198) |
| 2020-11-05 16:23:23 | <merijn> | Yeah, you'll have to handle those in separate threads |
| 2020-11-05 16:24:18 | <hololeap> | (yeah my original question was messed up) |
| 2020-11-05 16:24:31 | × | nbloomf quits (~nbloomf@2600:1700:ad14:3020:b093:9754:189c:f0eb) (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 2020-11-05 16:24:35 | <hololeap> | but, that's a good idea merijn, and i should be able to make it work |
| 2020-11-05 16:27:15 | → | ahmr88 joins (~ahmr88@cpc85006-haye22-2-0-cust131.17-4.cable.virginm.net) |
| 2020-11-05 16:27:38 | × | ahmr88 quits (~ahmr88@cpc85006-haye22-2-0-cust131.17-4.cable.virginm.net) (Client Quit) |
All times are in UTC.