| 2023-07-15 00:00:19 +0200 | <ski> | so, if you see `mystery :: Int -> [a] -> [a]' in a library, you *know* that its behaviour can't depend on the actual type you use for `a', nor can it depend on the actual values of that type that you pass in the list. and the only way for it to get `a' values is from that list, so all elements in the result list must come from the argument list |
| 2023-07-15 00:01:31 +0200 | <ski> | if you see `someHOF :: (a -> Maybe a) -> (a -> a -> Bool) -> [a] -> [a]', you know that the only way the function can inspect the list elements, is *via* those two callback functions (which it can only call on elements of the input list) |
| 2023-07-15 00:01:43 +0200 | califax | (~califax@user/califx) (Remote host closed the connection) |
| 2023-07-15 00:02:06 +0200 | califax | (~califax@user/califx) |
| 2023-07-15 00:03:39 +0200 | hpc | (~juzz@ip98-169-35-163.dc.dc.cox.net) (Ping timeout: 246 seconds) |
| 2023-07-15 00:04:32 +0200 | alexbiehl | (~alexbiehl@2a02:8108:323f:ca14:adeb:5d31:3c95:b332) (Ping timeout: 245 seconds) |
| 2023-07-15 00:04:54 +0200 | gmg | (~user@user/gehmehgeh) (Quit: Leaving) |
| 2023-07-15 00:05:00 +0200 | <ski> | if you want to be able to do something, depending on the type, you must explicitly opt-in to that, by adding a `Typeable' constraint, like `foo :: Typeable a => [a] -> [a]' can check what type `a' the caller picked, and if it knows that type, it can look inside the input elements, and can also construct unrelated output elements |
| 2023-07-15 00:05:21 +0200 | <segfaultfizzbuzz> | wow this seems very important,... but i am doing a double take, if the function is "generic" in my neanderthalic vocabulary, then it does not work with the values of that generic parameter? the function signature must specialize in order to introspect? |
| 2023-07-15 00:05:32 +0200 | hpc | (~juzz@ip98-169-35-163.dc.dc.cox.net) |
| 2023-07-15 00:06:04 +0200 | <segfaultfizzbuzz> | that fact makes haskell code a lot more readable, ha |
| 2023-07-15 00:06:33 +0200 | alexbiehl | (~alexbiehl@2a02:8108:323f:ca14:adeb:5d31:3c95:b332) |
| 2023-07-15 00:07:26 +0200 | titibandit | (~titibandi@user/titibandit) (Remote host closed the connection) |
| 2023-07-15 00:08:00 +0200 | <ski> | it can "handle" the values, by passing them around. but it can't look inside them, nor conjure up new values of that type from scratch (barring a few special cases like `error :: String -> a',`(let x = x in x) :: a') |
| 2023-07-15 00:08:14 +0200 | alexbiehl | (~alexbiehl@2a02:8108:323f:ca14:adeb:5d31:3c95:b332) (Remote host closed the connection) |
| 2023-07-15 00:08:26 +0200 | alexbiehl | (~alexbiehl@2a02:8108:323f:ca14:adeb:5d31:3c95:b332) |
| 2023-07-15 00:08:33 +0200 | <segfaultfizzbuzz> | right, introspect, that's like totally awesome |
| 2023-07-15 00:09:28 +0200 | ezzieyguywuf | (~Unknown@user/ezzieyguywuf) (Read error: Connection reset by peer) |
| 2023-07-15 00:09:50 +0200 | ezzieyguywuf | (~Unknown@user/ezzieyguywuf) |
| 2023-07-15 00:10:26 +0200 | alexbiehl | (~alexbiehl@2a02:8108:323f:ca14:adeb:5d31:3c95:b332) (Remote host closed the connection) |
| 2023-07-15 00:10:58 +0200 | alexbiehl | (~alexbiehl@2a02:8108:323f:ca14:adeb:5d31:3c95:b332) |
| 2023-07-15 00:11:00 +0200 | <ski> | anyway, as you can imagine, this property, "parametricity", can be quite handy, at times, when trying to figure out what some random library function *can't* do, in order to better understand code, or in order to be able to refactor it without changing observable behaviour (e.g. changing `map f (mystery n (map g xs))' to `map f (map g (mystery n xs))' so that you can further refactor it to `map (f . g) |
| 2023-07-15 00:11:04 +0200 | arahael_ | (~arahael@124-149-31-4.dyn.iinet.net.au) |
| 2023-07-15 00:11:06 +0200 | <ski> | (mystery n xs)' merging two traversals into a single one) |
| 2023-07-15 00:11:21 +0200 | dibblego | (~dibblego@haskell/developer/dibblego) (Ping timeout: 246 seconds) |
| 2023-07-15 00:11:31 +0200 | <segfaultfizzbuzz> | yeah i love it, totally changes the readability |
| 2023-07-15 00:11:44 +0200 | <ski> | not every language which has generics / parametric polymorphism has this "parametricity" property. e.g. Java doesn't, because there is `instanceof' and downcasts |
| 2023-07-15 00:14:30 +0200 | <ski> | parametricity tends to help better understanding the possible behaviour of (polymorphic) higher-order functions (like `someHOF' above), in that you know that the *only* `a' values it passes to the callbacks (apart from the special exceptions for "bottom" elements (aborting computation, infinite loop) that i mentioned) comes in some way from the inputs you pass to the HOF (the input list, here), and also that |
| 2023-07-15 00:14:36 +0200 | <ski> | that's the *only* way the HOF has of inspecting (and possibly producing more) of those `a' values |
| 2023-07-15 00:15:07 +0200 | <ski> | @free mystery :: Int -> [a] -> [a] |
| 2023-07-15 00:15:07 +0200 | <lambdabot> | $map f . mystery x = mystery x . $map f |
| 2023-07-15 00:15:19 +0200 | bilegeek | (~bilegeek@2600:1008:b05a:b7e5:c4f0:94df:26fd:4b15) |
| 2023-07-15 00:15:54 +0200 | <ski> | that law (which we can claim, solely by knowing the *type* of `mystery') is what i used above, to refactor `mystery n (map g xs)' to `map g (mystery n xs)' |
| 2023-07-15 00:15:58 +0200 | alexbiehl | (~alexbiehl@2a02:8108:323f:ca14:adeb:5d31:3c95:b332) (Ping timeout: 272 seconds) |
| 2023-07-15 00:16:30 +0200 | <ski> | (there's a paper, by wadler, about "free theorems", which is about this) |
| 2023-07-15 00:16:36 +0200 | arahael_ | (~arahael@124-149-31-4.dyn.iinet.net.au) (Ping timeout: 272 seconds) |
| 2023-07-15 00:18:23 +0200 | <ski> | "Theorems for free!" by Philip Wadler in 1989-09 at <https://homepages.inf.ed.ac.uk/wadler/topics/parametricity.html#free> |
| 2023-07-15 00:18:27 +0200 | <segfaultfizzbuzz> | i don't know $map |
| 2023-07-15 00:18:36 +0200 | <hpc> | it's just @free's way of saying map |
| 2023-07-15 00:18:44 +0200 | <hpc> | @free map :: x -> y -> z |
| 2023-07-15 00:18:45 +0200 | <lambdabot> | h . map x = map (f x) . g |
| 2023-07-15 00:18:54 +0200 | <hpc> | so you don't get confused if you do ^ that |
| 2023-07-15 00:18:54 +0200 | <int-e> | the natural fmap |
| 2023-07-15 00:18:57 +0200 | <ski> | that's just the notation used by that `free' command, to distinguish from any random function that might be named `map' |
| 2023-07-15 00:19:10 +0200 | <ski> | @free map :: Int -> [a] -> [a] |
| 2023-07-15 00:19:10 +0200 | <lambdabot> | $map f . map x = map x . $map f |
| 2023-07-15 00:19:30 +0200 | <ski> | @free catMaybes :: [Maybe a] -> [a] |
| 2023-07-15 00:19:30 +0200 | <lambdabot> | $map f . catMaybes = catMaybes . $map ($map_Maybe f) |
| 2023-07-15 00:19:46 +0200 | acidjnk | (~acidjnk@p200300d6e7072f846d698869e9f24b6e.dip0.t-ipconnect.de) (Ping timeout: 272 seconds) |
| 2023-07-15 00:20:02 +0200 | <ski> | `$map' is for `[]' (lists), `$map_F' is for general type constructors (like `Maybe') |
| 2023-07-15 00:20:32 +0200 | <ski> | @free swap :: (a,b) -> (b,a) |
| 2023-07-15 00:20:32 +0200 | <lambdabot> | $map_Pair g f . swap = swap . $map_Pair f g |
| 2023-07-15 00:22:03 +0200 | <ski> | that's assuming a (bifunctor) `bimap :: (a0 -> a1) -> (b0 -> b1) -> ((a0,b0) -> (a1,b1))' (which it called `$map_Pair' above) (or `bimap :: Bifunctor t => (a0 -> a1) -> (b0 -> b1) -> (t a0 b0 -> t a1 b1)' in general) |
| 2023-07-15 00:22:23 +0200 | <ski> | @free mirror :: Either a b -> Either b a |
| 2023-07-15 00:22:23 +0200 | <lambdabot> | $map_Either g f . mirror = mirror . $map_Either f g |
| 2023-07-15 00:22:34 +0200 | <ski> | @free length :: [a] -> Int |
| 2023-07-15 00:22:35 +0200 | <lambdabot> | length = length . $map f |
| 2023-07-15 00:25:33 +0200 | <segfaultfizzbuzz> | @free 1 + 1 |
| 2023-07-15 00:25:33 +0200 | <lambdabot> | Try `free <ident>` or `free <ident> :: <type>` |
| 2023-07-15 00:25:38 +0200 | dibblego | (~dibblego@116-255-1-157.ip4.superloop.au) |
| 2023-07-15 00:25:38 +0200 | dibblego | (~dibblego@116-255-1-157.ip4.superloop.au) (Changing host) |
| 2023-07-15 00:25:38 +0200 | dibblego | (~dibblego@haskell/developer/dibblego) |
| 2023-07-15 00:25:52 +0200 | <segfaultfizzbuzz> | ok so free is computing something on the command you are providing it? |
| 2023-07-15 00:26:48 +0200 | <segfaultfizzbuzz> | i don't think i have ever typed something like what you have provided into ghci and gotten a response like what @free is providing, looks like you are saying "show me the type of this" or some similar thing...? |
| 2023-07-15 00:27:16 +0200 | <ski> | it's computing the law, from the shape of the type signature of the polymorphim operation you're suggesting to it (it doesn't look up in any library whether there's actually an operation of that type) |
| 2023-07-15 00:27:26 +0200 | ub | (~Thunderbi@178.165.175.35.wireless.dyn.drei.com) |
| 2023-07-15 00:28:01 +0200 | alexbiehl | (~alexbiehl@2a02:8108:323f:ca14:adeb:5d31:3c95:b332) |
| 2023-07-15 00:28:03 +0200 | <ski> | `free' is a lambdabot plugin. iirc, it may be possibly to use from the interactor, though. (istr you can use lambdabot from the interactor. never tried, though) |
| 2023-07-15 00:28:36 +0200 | <geekosaur> | I think goa's bitrotted |
| 2023-07-15 00:28:44 +0200 | <geekosaur> | @hackage goa |
| 2023-07-15 00:28:44 +0200 | <lambdabot> | https://hackage.haskell.org/package/goa |
| 2023-07-15 00:29:27 +0200 | buckwheat | (~buckwheat@209.122.211.192) |
| 2023-07-15 00:29:38 +0200 | <segfaultfizzbuzz> | "the law" is new to me |
| 2023-07-15 00:29:49 +0200 | segfaultfizzbuzz | makes a gangsta symbol and pulls pants down to ankles |
| 2023-07-15 00:30:52 +0200 | fweht | (uid404746@id-404746.lymington.irccloud.com) |
| 2023-07-15 00:30:58 +0200 | thegeekinside | (~thegeekin@189.217.90.138) (Read error: Connection reset by peer) |
| 2023-07-15 00:31:04 +0200 | <ski> | "it's computing the law" -- the "free law" (in the sense that you get it "for free", from just knowing the type of the operation, thanks to the parametricity property of Haskell's generics / parametric polymorphism) |
| 2023-07-15 00:31:19 +0200 | <ski> | a few other papers which might be interesting to check out : |
| 2023-07-15 00:31:24 +0200 | <ski> | @where polymorphic-type-inference |
| 2023-07-15 00:31:25 +0200 | <lambdabot> | "Polymorphic Type Inference" by Michael I. Schwartzbach in 1995-03 at <https://cs.au.dk/~mis/typeinf.p(s|df)>,<http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.57.1493> |
| 2023-07-15 00:31:28 +0200 | <ski> | @where on-understanding |
| 2023-07-15 00:31:28 +0200 | <lambdabot> | "On Understanding Types, Data Abstraction, and Polymorphism" by Luca Cardelli,Peter Wegner in 1985-12 at <http://lucacardelli.name/Papers/OnUnderstanding.A4.pdf> |
| 2023-07-15 00:31:31 +0200 | <ski> | @where on-understanding-revisited |
| 2023-07-15 00:31:31 +0200 | <lambdabot> | "On Understanding Data Abstraction, Revisited" by William R. Cook in 2009-10 at <http://www.cs.utexas.edu/~wcook/Drafts/2009/essay.pdf> |
| 2023-07-15 00:31:40 +0200 | arahael_ | (~arahael@124-149-31-4.dyn.iinet.net.au) |
| 2023-07-15 00:32:26 +0200 | <segfaultfizzbuzz> | tbh when i look at papers i am lucky to understand anything more than a couple of paragraphs |
| 2023-07-15 00:32:34 +0200 | alexbiehl | (~alexbiehl@2a02:8108:323f:ca14:adeb:5d31:3c95:b332) (Ping timeout: 260 seconds) |
| 2023-07-15 00:33:05 +0200 | <segfaultfizzbuzz> | quite often i hit something like those type inference diagrams and i get buffer overflow from the definitions |
| 2023-07-15 00:33:20 +0200 | <ski> | some authors are better at writing accessibly, than others |
| 2023-07-15 00:33:27 +0200 | alexbiehl | (~alexbiehl@2a02:8108:323f:ca14:adeb:5d31:3c95:b332) |
| 2023-07-15 00:33:30 +0200 | <ski> | Wadler's usually pretty great |
| 2023-07-15 00:34:16 +0200 | <ski> | also, i'd suggest the Schwartzbach paper above as an intro to type systems and polymorphism. it explains quite a bit explicitly that most other papers on type systems takes for granted |
| 2023-07-15 00:35:30 +0200 | nyc | (~nyc@user/nyc) (Ping timeout: 246 seconds) |
| 2023-07-15 00:35:41 +0200 | <segfaultfizzbuzz> | i have a simpler question which might be better and on point (??): i came across ben lynn's excellent macguyver talk, i think i understood and retained more than half of it, and it got me wondering whether there is such thing as a typed combinator? |
| 2023-07-15 00:36:07 +0200 | <ski> | hm, i'm not familiar with that talk (link ?) |
| 2023-07-15 00:36:16 +0200 | <segfaultfizzbuzz> | https://www.youtube.com/watch?v=3kMvXXGXaws&list=PLOvRW_utVPVmzDGGOJ2amgVBK168Vemke&index=7 |
| 2023-07-15 00:36:20 +0200 | <ski> | what is meant by "combinator", in this context ? |
| 2023-07-15 00:37:01 +0200 | <segfaultfizzbuzz> | you can skip to ten minutes into the video to cut to the most important part i think,... basically he says S &K combinators taken together are turing complete |
| 2023-07-15 00:38:10 +0200 | alexbiehl | (~alexbiehl@2a02:8108:323f:ca14:adeb:5d31:3c95:b332) (Ping timeout: 260 seconds) |
| 2023-07-15 00:38:24 +0200 | <ski> | oh, combinatory logic |
| 2023-07-15 00:38:52 +0200 | <ski> | sure, you can type those combinators, like |
| 2023-07-15 00:39:13 +0200 | <ski> | S : (a -> b -> c) -> (a -> b) -> (a -> c) |
| 2023-07-15 00:39:21 +0200 | <ski> | K : a -> b -> a |
| 2023-07-15 00:39:27 +0200 | <ski> | I : a -> a |
| 2023-07-15 00:40:40 +0200 | <ski> | also other combinators, like |
| 2023-07-15 00:40:51 +0200 | <segfaultfizzbuzz> | ...are the results of reduction of SK evaluation order dependent? no right? |
| 2023-07-15 00:40:57 +0200 | <ski> | B : (b -> c) -> (a -> b) -> (a -> c) |
| 2023-07-15 00:40:59 +0200 | dcoutts | (~duncan@212.187.244.53) |
| 2023-07-15 00:41:22 +0200 | <ski> | C : (a -> b -> c) -> (b -> a -> c) |
| 2023-07-15 00:41:32 +0200 | <ski> | W : (a -> a -> b) -> (a -> b) |
| 2023-07-15 00:44:05 +0200 | <ski> | segfaultfizzbuzz : depends on whether you have types or not (simplifying slightly). with no types, you can easily make an infinite loop, and then whether you go into it or ignore it can depend on which evaluation order you use. with a simple type system (and no recursion, and no explicit combinator for encoding it either), everything terminates, and so you always get to an answer, and then what answer you |
| 2023-07-15 00:44:11 +0200 | <ski> | get doesn't depend on which path (evaluation order) you take to get there (this is "confluence") |
| 2023-07-15 00:44:47 +0200 | wroathe | (~wroathe@user/wroathe) |
| 2023-07-15 00:45:15 +0200 | nick3 | (~nick@2600:8807:9084:7800:8973:eff0:2771:c97b) (Ping timeout: 246 seconds) |
| 2023-07-15 00:45:27 +0200 | takuan | (~takuan@178-116-218-225.access.telenet.be) (Remote host closed the connection) |
| 2023-07-15 00:46:17 +0200 | dcoutts | (~duncan@212.187.244.53) (Ping timeout: 246 seconds) |
| 2023-07-15 00:46:22 +0200 | dibblego | (~dibblego@haskell/developer/dibblego) (Ping timeout: 272 seconds) |
| 2023-07-15 00:46:45 +0200 | <segfaultfizzbuzz> | interesting |
| 2023-07-15 00:47:20 +0200 | <ski> | you might perhaps also enjoy reading |
| 2023-07-15 00:47:23 +0200 | <ski> | @where mockingbird |
| 2023-07-15 00:47:23 +0200 | <lambdabot> | "To mock a mockingbird : and other logic puzzles including an amazing adventure in combinatory logic" by R. M. Smullyan, "To Dissect a Mockingbird: A Graphical Notation for the Lambda Calculus with |
| 2023-07-15 00:47:24 +0200 | <lambdabot> | Animated Reduction" at <http://dkeenan.com/Lambda/> by David C. Keenan. Also see `smullyan' |
| 2023-07-15 00:47:38 +0200 | <segfaultfizzbuzz> | fine so i could selectively exclude infinite recursion (e.g. the evaluator can suspend at will) then it is evaluation order independent? |
| 2023-07-15 00:47:43 +0200 | <ski> | it talks about the combinators, from a playful bird analogy |
| 2023-07-15 00:48:40 +0200 | <ski> | suspend, how ? |
| 2023-07-15 00:48:50 +0200 | <zero> | oooh do i hear chirping? |
| 2023-07-15 00:48:52 +0200 | <probie> | Is confluence tied to termination? I was taught that it's the "diamond property" of a rewrite system (i.e if B and C can be reached from A by some rewrites, then there is a D which is reachable from both B and C) |
| 2023-07-15 00:49:07 +0200 | neuroevolutus | (~neuroevol@2001:ac8:9a:76::1e) |
| 2023-07-15 00:49:26 +0200 | dhil | (~dhil@78.45.150.83.ewm.ftth.as8758.net) (Ping timeout: 250 seconds) |
| 2023-07-15 00:49:37 +0200 | <ski> | if you use one evaluation order, then the computation might terminate quickly, but if you use another, it might take a long time, and so you might get a time-out .. doesn't sound like independent of evaluation order (depending on how you define that, i guess) |
| 2023-07-15 00:50:43 +0200 | alexbiehl | (~alexbiehl@2a02:8108:323f:ca14:adeb:5d31:3c95:b332) |
| 2023-07-15 00:50:46 +0200 | dibblego | (~dibblego@116-255-1-157.ip4.superloop.au) |
| 2023-07-15 00:50:46 +0200 | dibblego | (~dibblego@116-255-1-157.ip4.superloop.au) (Changing host) |
| 2023-07-15 00:50:46 +0200 | dibblego | (~dibblego@haskell/developer/dibblego) |
| 2023-07-15 00:51:00 +0200 | <ski> | probie : not directly. i was remarking that if you have termination, then because you also have confluence, you get to the same result, regardless of which path you take. but if you only have confluence, but not termination, then some evaluations orders may terminate (necessarily with the same result), while others can diverge |
| 2023-07-15 00:51:28 +0200 | __monty__ | (~toonn@user/toonn) (Quit: leaving) |
| 2023-07-15 00:51:31 +0200 | <ski> | (and if you only have termination, but not confluence, then you have a non-deterministic computation, you might end up with different end results, depending on which evaluation order you use) |
| 2023-07-15 00:53:24 +0200 | <ski> | (hm, seems "Programming with Visual Expressions" by Wayne Citrin,Richard Hall,Benjamin Zorn at <https://web.archive.org/web/20220607041104/http://users.encs.concordia.ca/~haarslev/vl95www/html-p…> expired, so that you need to access it via the Web Archive) |
| 2023-07-15 00:54:57 +0200 | alexbiehl | (~alexbiehl@2a02:8108:323f:ca14:adeb:5d31:3c95:b332) (Ping timeout: 245 seconds) |
| 2023-07-15 00:54:57 +0200 | <segfaultfizzbuzz> | oh interesting, it becomes nondeterministic if it is nonterminating? |
| 2023-07-15 00:55:05 +0200 | <segfaultfizzbuzz> | that's very interesting |
| 2023-07-15 00:55:22 +0200 | dibblego | (~dibblego@haskell/developer/dibblego) (Ping timeout: 245 seconds) |
| 2023-07-15 00:55:30 +0200 | arahael_ | (~arahael@124-149-31-4.dyn.iinet.net.au) (Ping timeout: 250 seconds) |
| 2023-07-15 00:55:33 +0200 | <ski> | (also, i don't believe i've seen "lambda-calculus-visualizations: Catalog of visual lambda calculi" <https://github.com/prathyvsh/lambda-calculus-visualizations> before, although i've seen some of the (other) entries, like "Lambda Diagrams","Alligator Eggs") |
| 2023-07-15 00:56:05 +0200 | <ski> | segfaultfizzbuzz : `const () (fix id)' |
| 2023-07-15 00:56:34 +0200 | dsrt^ | (~cd@24.125.210.85) |
| 2023-07-15 00:56:42 +0200 | <hpc> | segfaultfizzbuzz: it's a pretty intuitive result, even if you think in terms of a language like C |
| 2023-07-15 00:56:51 +0200 | <hpc> | consider short-circuiting and/or |
| 2023-07-15 00:56:55 +0200 | <ski> | (nondeterministic, up to choosing the evaluation order, that is. if you've picked an evaluation order, and it doesn't involve making arbitrary choices, then within that evaluation order, it'd still be deterministic) |
| 2023-07-15 00:57:09 +0200 | <hpc> | 0 || loop() |
| 2023-07-15 00:57:10 +0200 | <segfaultfizzbuzz> | short circuiting... a program? lol you folks are on another level ;-) |
| 2023-07-15 00:57:43 +0200 | <hpc> | a program and a function are basically the same thing - try writing a bash script without that idea in mind sometime :D |
| 2023-07-15 00:57:45 +0200 | <ski> | `y != 0 && foo(x / y)' |
| 2023-07-15 00:58:09 +0200 | <hpc> | but yeah, with short-circuiting logic, there's no reason why it has to be left-to-right |
| 2023-07-15 00:58:12 +0200 | <sm> | @where+ learnxinyminutes https://learnxinyminutes.com/docs/haskell |
| 2023-07-15 00:58:12 +0200 | <lambdabot> | Done. |
| 2023-07-15 00:58:47 +0200 | <hpc> | so you have confluence, of a sort |
| 2023-07-15 00:59:00 +0200 | <hpc> | but you don't have termination, because loop() is possible to write at all |
| 2023-07-15 00:59:17 +0200 | <hpc> | so depending on the evaluation order, you get either 0 or you don't terminate |
| 2023-07-15 00:59:52 +0200 | <ski> | hm .. very large letters on that page .. i can only see 51 width at a time, without scrolling sideways |
| 2023-07-15 01:01:20 +0200 | <ski> | "there's no reason why it has to be left-to-right" -- well, with dependent conjunction and implication, there could be, i guess |
| 2023-07-15 01:02:34 +0200 | <segfaultfizzbuzz> | this is a bit off topic but i have been curious about "smart" evaluation rather than always left to right or always right to left |
| 2023-07-15 01:02:50 +0200 | falafel | (~falafel@2603-7000-a700-8710-e3d6-964f-e7e9-177a.res6.spectrum.com) (Ping timeout: 272 seconds) |
| 2023-07-15 01:02:51 +0200 | <ski> | `(x : sigma) /\ tau', is well-formed (type-correct), when `sigma' is, and when `tau' is (where `x' of type `sigma') is in scope in `tau'. and similarly for the dependent implication `(x : sigma) -> tau' |
| 2023-07-15 01:02:57 +0200 | <segfaultfizzbuzz> | but that concept really only makes sense if your computation is not order dependent,... |
| 2023-07-15 01:03:19 +0200 | <segfaultfizzbuzz> | or if you can accept nondeterminism (maybe nondeterminism is inevitable and you should plan to accomodate it...?) |
| 2023-07-15 01:03:20 +0200 | alexbiehl | (~alexbiehl@2a02:8108:323f:ca14:adeb:5d31:3c95:b332) |
| 2023-07-15 01:03:48 +0200 | dibblego | (~dibblego@116-255-1-157.ip4.superloop.au) |
| 2023-07-15 01:03:48 +0200 | dibblego | (~dibblego@116-255-1-157.ip4.superloop.au) (Changing host) |
| 2023-07-15 01:03:48 +0200 | dibblego | (~dibblego@haskell/developer/dibblego) |
| 2023-07-15 01:04:18 +0200 | APic | (~apic@apic.name) (Ping timeout: 260 seconds) |
| 2023-07-15 01:04:20 +0200 | <ski> | the special cases `(_ : sigma) /\ tau' and `(_ : sigma) -> tau' where `x' is not used in `tau', could still have the well-formedness (including well-typedness) of `tau' depending on `sigma' being *inhabited* (from a logical perspective : depending on `sigma' holding / being the case) |
| 2023-07-15 01:05:44 +0200 | <ski> | so, you can argue that `x =/= 0 /\ f(1/x) > 0' is well-formed, even though `1/x' is not defined when `x' is zero, because you're allowed to assume, when checking the well-formedness of the right conjunct, that the left conjunct is *true* ! |
| 2023-07-15 01:06:53 +0200 | <ski> | (this is an example of a "presupposition". the formula `f(1/x)' being wellformed presupposes that `x' is non-zero. this presupposition is discharged by the left conjunct in this conjunction, so that it's no longer a presupposition (/ dependency) of the whole conjunction) |
| 2023-07-15 01:07:16 +0200 | <segfaultfizzbuzz> | interesting |
| 2023-07-15 01:07:54 +0200 | alexbiehl | (~alexbiehl@2a02:8108:323f:ca14:adeb:5d31:3c95:b332) (Ping timeout: 272 seconds) |
| 2023-07-15 01:08:28 +0200 | zero | thinks of https://esolangs.org/wiki/Whenever |
| 2023-07-15 01:09:01 +0200 | segfaultfizzbuzz | thinks of https://www.youtube.com/watch?v=weRHyjj34ZE |
| 2023-07-15 01:11:14 +0200 | <ski> | (a more mundane example would be "Have you stopped beating your wife yet ?" (it's a traditiona one, on this topic) -- a presupposition of this question is "You did beat your wife at some point.". if that presupposition is false, then you can (truthfully) answer neither "yes" nor "no". strictly speaking, the question is malformed, "type incorrect", "inadmissible", doesn't make sense. you could answer "mu" |
| 2023-07-15 01:11:20 +0200 | <ski> | (see <https://en.wikipedia.org/wiki/Mu_(negative)>,<http://www.catb.org/jargon/html/M/mu.html>), though, to "unask" the question) |
| 2023-07-15 01:11:35 +0200 | <segfaultfizzbuzz> | ay maybe we could use a different example |
| 2023-07-15 01:11:57 +0200 | dcoutts | (~duncan@79.137.104.194) |
| 2023-07-15 01:12:24 +0200 | arahael_ | (~arahael@124-149-31-4.dyn.iinet.net.au) |
| 2023-07-15 01:12:24 +0200 | segfaultfizzbuzz | thinks of https://chrono.fandom.com/wiki/Nu |
| 2023-07-15 01:12:26 +0200 | <ski> | (<https://en.wikipedia.org/wiki/Definite_description> is also related to this) |
| 2023-07-15 01:12:52 +0200 | <ski> | heh, i remember those, segfaultfizzbuzz :p |
| 2023-07-15 01:13:09 +0200 | sm[i] | (~sm@024-165-041-186.res.spectrum.com) (Quit: sm[i]) |
| 2023-07-15 01:13:38 +0200 | <segfaultfizzbuzz> | haha a programming language with no sense of urgency lol |
| 2023-07-15 01:13:59 +0200 | <segfaultfizzbuzz> | wait wow what, no control flow or variables? wow |
| 2023-07-15 01:16:12 +0200 | dcoutts | (~duncan@79.137.104.194) (Ping timeout: 245 seconds) |
| 2023-07-15 01:17:02 +0200 | arahael_ | (~arahael@124-149-31-4.dyn.iinet.net.au) (Ping timeout: 245 seconds) |
| 2023-07-15 01:17:08 +0200 | andydude | (~andrewr@151.200.15.152) |
| 2023-07-15 01:18:42 +0200 | bilegeek | (~bilegeek@2600:1008:b05a:b7e5:c4f0:94df:26fd:4b15) (Ping timeout: 245 seconds) |
| 2023-07-15 01:22:07 +0200 | APic | (apic@apic.name) |
| 2023-07-15 01:22:13 +0200 | nate2 | (~nate@c-98-45-169-16.hsd1.ca.comcast.net) |
| 2023-07-15 01:24:53 +0200 | sm[i] | (~sm@024-165-041-186.res.spectrum.com) |
| 2023-07-15 01:27:08 +0200 | nate2 | (~nate@c-98-45-169-16.hsd1.ca.comcast.net) (Ping timeout: 250 seconds) |
| 2023-07-15 01:27:26 +0200 | waleee | (~waleee@2001:9b0:21c:4000:5bf9:6515:c030:57b7) (Ping timeout: 246 seconds) |
| 2023-07-15 01:36:00 +0200 | Tuplanolla | (~Tuplanoll@91-159-68-236.elisa-laajakaista.fi) (Quit: Leaving.) |
| 2023-07-15 01:37:11 +0200 | mechap | (~mechap@user/mechap) (Ping timeout: 264 seconds) |
| 2023-07-15 01:37:37 +0200 | mechap | (~mechap@user/mechap) |
| 2023-07-15 01:41:49 +0200 | nick3 | (~nick@2600:8807:9084:7800:8973:eff0:2771:c97b) |
| 2023-07-15 01:42:40 +0200 | mauke_ | (~mauke@user/mauke) |
| 2023-07-15 01:44:12 +0200 | mauke | (~mauke@user/mauke) (Ping timeout: 252 seconds) |
| 2023-07-15 01:44:12 +0200 | mauke_ | mauke |
| 2023-07-15 01:49:35 +0200 | alexbiehl | (~alexbiehl@2a02:8108:323f:ca14:adeb:5d31:3c95:b332) |
| 2023-07-15 01:49:38 +0200 | wroathe | (~wroathe@user/wroathe) (Ping timeout: 246 seconds) |
| 2023-07-15 01:53:42 +0200 | alexbiehl | (~alexbiehl@2a02:8108:323f:ca14:adeb:5d31:3c95:b332) (Ping timeout: 245 seconds) |
| 2023-07-15 01:55:06 +0200 | arahael_ | (~arahael@124-149-31-4.dyn.iinet.net.au) |
| 2023-07-15 01:55:21 +0200 | falafel | (~falafel@2603-7000-a700-8710-6966-48e1-9920-70bf.res6.spectrum.com) |
| 2023-07-15 01:56:45 +0200 | falafel | (~falafel@2603-7000-a700-8710-6966-48e1-9920-70bf.res6.spectrum.com) (Remote host closed the connection) |
| 2023-07-15 01:57:18 +0200 | oo_miguel | (~Thunderbi@78-11-179-96.static.ip.netia.com.pl) (Ping timeout: 272 seconds) |
| 2023-07-15 01:57:27 +0200 | APic | (apic@apic.name) (Ping timeout: 245 seconds) |
| 2023-07-15 02:00:01 +0200 | arahael_ | (~arahael@124-149-31-4.dyn.iinet.net.au) (Ping timeout: 245 seconds) |
| 2023-07-15 02:04:44 +0200 | andydude | (~andrewr@151.200.15.152) (Quit: Leaving.) |
| 2023-07-15 02:08:17 +0200 | falafel | (~falafel@2603-7000-a700-8710-9f29-d133-dde2-555f.res6.spectrum.com) |
| 2023-07-15 02:13:21 +0200 | <segfaultfizzbuzz> | so when you read a paper inevitably there are a bunch of definitions,... do you read and retain those definitions? do you skim them looking for specific things? can you recall the definitions from a week ago? a year ago? ten years ago? |
| 2023-07-15 02:16:08 +0200 | <geekosaur> | many definitions are per paper |
| 2023-07-15 02:16:58 +0200 | <geekosaur> | unfortunately you can't always tell which are which |
| 2023-07-15 02:17:14 +0200 | <segfaultfizzbuzz> | i am asking what your retention is like |
| 2023-07-15 02:17:29 +0200 | <segfaultfizzbuzz> | i am stuck in a cycle where i hear about a paper and i try to read it |
| 2023-07-15 02:17:35 +0200 | <geekosaur> | my retention is … not others' retention 🙂 |
| 2023-07-15 02:17:41 +0200 | <segfaultfizzbuzz> | i think my attention falls of roughly like exponentially with number of definitions |
| 2023-07-15 02:18:17 +0200 | <ski> | it can help to skip things you don't quite get, and possibly later return (or perhaps try to look up more in-depth or newbie intro info on it, like tutorial, survey, or (more) seminal or summary papers, perhaps looking for suggestions in the references/bibliography section) |
| 2023-07-15 02:18:19 +0200 | <segfaultfizzbuzz> | i think if somehow i am persuaded that it is one of the most important concepts (i don't know, shannon entropy or something) then i can really read at a more constant comprehension |
| 2023-07-15 02:18:42 +0200 | <segfaultfizzbuzz> | but otherwise reading is basically denial of service, because so many things are constantly claiming to be important and i am let down so incredibly often |
| 2023-07-15 02:18:59 +0200 | alexbiehl | (~alexbiehl@2a02:8108:323f:ca14:adeb:5d31:3c95:b332) |
| 2023-07-15 02:19:45 +0200 | <segfaultfizzbuzz> | technical papers are mostly but not strictly cumulative order in their uh dependency graph |
| 2023-07-15 02:23:17 +0200 | alexbiehl | (~alexbiehl@2a02:8108:323f:ca14:adeb:5d31:3c95:b332) (Ping timeout: 245 seconds) |
| 2023-07-15 02:24:29 +0200 | alexbiehl | (~alexbiehl@2a02:8108:323f:ca14::ac08) |
| 2023-07-15 02:28:50 +0200 | alexbiehl | (~alexbiehl@2a02:8108:323f:ca14::ac08) (Ping timeout: 246 seconds) |
| 2023-07-15 02:30:38 +0200 | gurkenglas | (~gurkengla@dynamic-046-114-181-072.46.114.pool.telefonica.de) (Read error: Connection reset by peer) |
| 2023-07-15 02:33:27 +0200 | sm[i] | (~sm@024-165-041-186.res.spectrum.com) (Quit: sm[i]) |
| 2023-07-15 02:34:44 +0200 | nyc | (~nyc@2603-7000-a106-2fb5-0000-0000-0000-1f21.res6.spectrum.com) |
| 2023-07-15 02:39:04 +0200 | buckwheatsuperpo | (~buckwheat@209.122.211.192) |
| 2023-07-15 02:39:15 +0200 | pickleju1ce | (~root@c-73-196-164-60.hsd1.nj.comcast.net) |
| 2023-07-15 02:39:17 +0200 | picklejuice | (~root@172.56.219.136) (Read error: Connection reset by peer) |
| 2023-07-15 02:41:40 +0200 | buckwheat | (~buckwheat@209.122.211.192) (Ping timeout: 250 seconds) |
| 2023-07-15 02:41:43 +0200 | alexbiehl | (~alexbiehl@77.20.253.164) |
| 2023-07-15 02:42:58 +0200 | segfaultfizzbuzz | (~segfaultf@23-93-74-212.fiber.dynamic.sonic.net) (Ping timeout: 250 seconds) |
| 2023-07-15 02:45:59 +0200 | alexbiehl | (~alexbiehl@77.20.253.164) (Ping timeout: 246 seconds) |
| 2023-07-15 02:54:18 +0200 | hugo | (znc@verdigris.lysator.liu.se) (Ping timeout: 272 seconds) |
| 2023-07-15 02:54:36 +0200 | mei | (~mei@user/mei) (Ping timeout: 252 seconds) |
| 2023-07-15 02:57:31 +0200 | arahael_ | (~arahael@1.145.21.117) |
| 2023-07-15 02:58:39 +0200 | mei | (~mei@user/mei) |
| 2023-07-15 02:59:07 +0200 | alexbiehl | (~alexbiehl@2a02:8108:323f:ca14:adeb:5d31:3c95:b332) |
| 2023-07-15 03:00:11 +0200 | falafel | (~falafel@2603-7000-a700-8710-9f29-d133-dde2-555f.res6.spectrum.com) (Ping timeout: 246 seconds) |
| 2023-07-15 03:01:57 +0200 | andydude | (~andrewr@151.200.15.152) |
| 2023-07-15 03:02:34 +0200 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) |
| 2023-07-15 03:03:48 +0200 | alexbiehl | (~alexbiehl@2a02:8108:323f:ca14:adeb:5d31:3c95:b332) (Ping timeout: 272 seconds) |
| 2023-07-15 03:07:06 +0200 | hugo | (znc@verdigris.lysator.liu.se) |
| 2023-07-15 03:10:04 +0200 | Midjak | (~Midjak@82.66.147.146) (Quit: This computer has gone to sleep) |
| 2023-07-15 03:10:51 +0200 | albet70 | (~xxx@2400:8902::f03c:92ff:fe60:98d8) (Remote host closed the connection) |
| 2023-07-15 03:16:58 +0200 | albet70 | (~xxx@2400:8902::f03c:92ff:fe60:98d8) |
| 2023-07-15 03:17:26 +0200 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Remote host closed the connection) |
| 2023-07-15 03:18:39 +0200 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) |
| 2023-07-15 03:22:58 +0200 | gnalzo | (~gnalzo@2a01:e0a:498:fd50:fcc6:bb5d:489a:ce8c) (Quit: WeeChat 4.0.1) |
| 2023-07-15 03:25:58 +0200 | [itchyjunk] | (~itchyjunk@user/itchyjunk/x-7353470) (Ping timeout: 272 seconds) |
| 2023-07-15 03:27:52 +0200 | machinedgod | (~machinedg@d198-53-218-113.abhsia.telus.net) (Ping timeout: 272 seconds) |
| 2023-07-15 03:28:53 +0200 | wroathe | (~wroathe@207-153-38-140.fttp.usinternet.com) |
| 2023-07-15 03:28:53 +0200 | wroathe | (~wroathe@207-153-38-140.fttp.usinternet.com) (Changing host) |
| 2023-07-15 03:28:53 +0200 | wroathe | (~wroathe@user/wroathe) |
| 2023-07-15 03:29:14 +0200 | aforemny | (~aforemny@2001:9e8:6ced:8a00:6429:b02a:8db7:75db) |
| 2023-07-15 03:29:46 +0200 | aforemny_ | (~aforemny@2001:9e8:6cd3:fb00:3e3b:718b:2209:2cf8) (Ping timeout: 272 seconds) |
| 2023-07-15 03:33:34 +0200 | machinedgod | (~machinedg@d198-53-218-113.abhsia.telus.net) |
| 2023-07-15 03:36:26 +0200 | [itchyjunk] | (~itchyjunk@user/itchyjunk/x-7353470) |
| 2023-07-15 03:37:00 +0200 | neuroevolutus | (~neuroevol@2001:ac8:9a:76::1e) (Quit: Client closed) |
| 2023-07-15 03:44:32 +0200 | <arahael_> | What does this mean? |
| 2023-07-15 03:44:54 +0200 | <arahael_> | class (Monad m) => MonadError e m | m -> e where... |
| 2023-07-15 03:44:55 +0200 | alexbiehl | (~alexbiehl@2a02:8108:323f:ca14:adeb:5d31:3c95:b332) |
| 2023-07-15 03:45:18 +0200 | <arahael_> | Specifically what does the `| m -> e` bit mean? |
| 2023-07-15 03:45:18 +0200 | <ski> | the FD ? ` | m -> e' ? |
| 2023-07-15 03:45:29 +0200 | <ski> | it's a functional dependency (FD) |
| 2023-07-15 03:46:00 +0200 | <ski> | it claims that `m' (functionally) determines `e' (in the context of `MonadError e m') |
| 2023-07-15 03:46:27 +0200 | <ski> | this means that there can't be two different instances, with different `e's, for the same `m' |
| 2023-07-15 03:46:31 +0200 | <arahael_> | Ah, interesting. What does that mean? :D |
| 2023-07-15 03:46:52 +0200 | <arahael_> | Why is it worth specifying? |
| 2023-07-15 03:47:01 +0200 | <ski> | for each type `m', there can be at most one `e', such that there is an instance `MonadError m e' |
| 2023-07-15 03:47:14 +0200 | <c_wraith> | mostly, it lets GHC unify e types when it only knows m types |
| 2023-07-15 03:47:36 +0200 | <arahael_> | Intriguing, so it's giving more information to the type system? |
| 2023-07-15 03:47:48 +0200 | <arahael_> | (I mean, it's giving more info to the type system so that the type system can tell you if you've made a mistake giving more than one instance when it doesn't make sense to do so?) |
| 2023-07-15 03:47:54 +0200 | <c_wraith> | well, and placing a restriction on the kind of instances you can make |
| 2023-07-15 03:48:03 +0200 | <arahael_> | Neat. |
| 2023-07-15 03:48:10 +0200 | <ski> | logically, you could phrase that as `forall m. unique e. MonadError m e'. this is logically equivalent to `forall m e0 e1. (MonadError m e0,MonadError m e1) => e0 = e1'. if there's two instances with the same `m', then that means the `e's must already be the same (so that it's the same instance, in this particular case) |
| 2023-07-15 03:49:01 +0200 | <ski> | the effect is in two parts : (a) forbidding you having both `MonadError MyM MyE0' and `MonadError MyM MyE1' in scope in the same module (for `MyE0' different from `MyE1') |
| 2023-07-15 03:50:02 +0200 | alexbiehl | (~alexbiehl@2a02:8108:323f:ca14:adeb:5d31:3c95:b332) (Ping timeout: 272 seconds) |
| 2023-07-15 03:50:56 +0200 | <arahael_> | Cool, ,I think that's enough for me for the moment - it sounds good. |
| 2023-07-15 03:51:48 +0200 | <ski> | and (b) this means that if type inference infers two constraints `MonadError m e0' and `MonadError m e1' (for the same `m'), because it knows there can't be two instances, it can just assert that `e0' must be the same as `e1' (unifying those type, in the type inference), and replacing those two constraints with a single constraint `MonadError m e' (so, in terms of dictionary-passing, you'll just pass one |
| 2023-07-15 03:51:54 +0200 | <ski> | dictionary (unless the constraint gets pinned down exactly, like say `MonadError (ExceptT MyError m) MyError', in which case there needs to be no implicit dictionary passing there to the operation you're defining) |
| 2023-07-15 03:52:46 +0200 | <arahael_> | So it's also an optimisation. |
| 2023-07-15 03:53:08 +0200 | <ski> | this (b) part can really help with avoiding getting ambiguous types (since if `e0' is not pinned down by something in your code, but `e1' is, then that avoids ambiguity for `e0'. so that avoids you having to place an explicit type signature or ascription, or looking into using a more specialized (equivalent) operation, to avoid ambiguity) |
| 2023-07-15 03:53:44 +0200 | <arahael_> | Oh nice, so it makes specifying your explicit types more convenient also. |
| 2023-07-15 03:53:55 +0200 | <arahael_> | (Since there's less you have to explicitly state) |
| 2023-07-15 03:54:50 +0200 | <ski> | i'd say the main theoretical part is accurately modelling the domain. if what you're trying to model implies there ought to be these "functional dependency" constraints, then it helps being able to get that checked (when declaring and importing instances), and also exploited (when using operations that have constraints) |
| 2023-07-15 03:55:02 +0200 | <ski> | the main practical part is avoiding ambiguity |
| 2023-07-15 03:55:37 +0200 | <arahael_> | Makes sense. |
| 2023-07-15 03:56:03 +0200 | <ski> | in case you know anything about relational databases, you should note that the concept of "functional dependency" there (in terms of keys, and normalization of relations/tables) is basically the same concept, just in a different application domain |
| 2023-07-15 03:57:06 +0200 | <arahael_> | That's a good analogy, actually. I do know relational databases.] |
| 2023-07-15 03:58:29 +0200 | <arahael_> | I'm just working through the 'all about monads' wiki page. It's slightly annoying having to define Applicative and Functional instances in addition to each monad we play with, I guess that's relatively new. |
| 2023-07-15 03:58:54 +0200 | <ski> | btw, often you can use associated types instead of functional dependencies. like instead of `class Monad m => MonadError e m | m -> e where ..m..e..' you could have said `class Monad m => MonadError m where type ErrorOfMonad m; ..m..(ErrorOfMonad m)..', where `e's replaced by `ErrorOfMonad m' |
| 2023-07-15 04:00:16 +0200 | <arahael_> | I think I'll focus on that a bit later. |
| 2023-07-15 04:00:35 +0200 | <ski> | however, say you have `class Foo a b | a -> b , b -> a' or `class Bar a b c d | a b -> c , a d -> b , c d -> a' (i'm not sure if there's any redundant FDs there (implied by others), i just made up the example on the spot), it's not as clear always which parameter to turn into an associated type |
| 2023-07-15 04:01:21 +0200 | <arahael_> | How woul that work, you're saying there that a and b can derive each other? |
| 2023-07-15 04:02:36 +0200 | <ski> | (there's also a notion of "injectivity constraints" for type families (which are more general than associated types, since they can occur outside of `class' declarations), that's related) |
| 2023-07-15 04:02:44 +0200 | <ski> | yes |
| 2023-07-15 04:05:41 +0200 | APic | (apic@apic.name) |
| 2023-07-15 04:06:33 +0200 | <ski> | (historically, associated types, and type families (and the closely related associated data types, and data families), came years later, than the easier to imagine multi-parameter type classes, and functional dependencies. basically, as soon as people started experimenting with MPTCs, they noticed ambiguity problems with some of the stuff they wanted to model, and so FDs were born) |
| 2023-07-15 04:06:50 +0200 | zero | yin |
| 2023-07-15 04:07:15 +0200 | <ski> | oh, btw, i guess i should give one example of the logical meaning, when you have more parameters, but you don't use all of them in an FD |
| 2023-07-15 04:08:44 +0200 | <ski> | consider `class Baz a b c d | a b -> c where ...'. the FD here logically expresses `forall a b. unique c. exists d. Baz a b c d'. which amounts to `forall a b c0 c1 d0 d1. (Baz a b c0 d0,Baz a b c1 d1) => c0 = c1' |
| 2023-07-15 04:09:02 +0200 | td_ | (~td@i5387091B.versanet.de) (Ping timeout: 272 seconds) |
| 2023-07-15 04:09:13 +0200 | <ski> | in words : if you have two instances, with the `a's and the `b's the same, then the `c's also have to be the same (and we don't care about the `d's) |
| 2023-07-15 04:10:23 +0200 | td_ | (~td@i5387091F.versanet.de) |
| 2023-07-15 04:11:31 +0200 | <ski> | (generally speaking, `unique x. ..x..' is equivalent to `forall x0 x1. (..x0..,..x1..) => x0 = x1'. then i also used the logical equivalence between `(exists x. ..x..) => ...' and `forall x. (..x.. => ...)' above) |
| 2023-07-15 04:14:19 +0200 | <andydude> | I miss Haskell |
| 2023-07-15 04:15:25 +0200 | nate2 | (~nate@c-98-45-169-16.hsd1.ca.comcast.net) |
| 2023-07-15 04:16:54 +0200 | <andydude> | a stupid YT about Rust reminded me of Haskell |
| 2023-07-15 04:16:55 +0200 | razetime | (~quassel@117.193.0.33) |
| 2023-07-15 04:18:28 +0200 | <arahael_> | Rust does have a number of fairly nice similarities in an arguably more mainstream language package. |
| 2023-07-15 04:20:32 +0200 | <ski> | (hm .. mode declarations in Mercury (and i think in some Prologs, too), are also related to (although more general, and in general more operational, than FDs). e.g. there's a relation/predicate `append(Xs,Ys,Zs)' which corresponds to `xs ++ ys = zs' in Haskell terms. there are mode declarations, one stating that if `Xs' and `Ys' are known, then there exists a unique correspond `Zs' (obviously), but also that |
| 2023-07-15 04:20:36 +0200 | <andydude> | https://youtu.be/TGfQu0bQTKc |
| 2023-07-15 04:20:38 +0200 | <ski> | given known `Xs',`Zs', there can be at most one `Ys' (which the same source code will compute for you, giving you both `(++)' and `stripPrefix' (and some more, too) in one single (declaratively/logically coherent) operation) |
| 2023-07-15 04:20:45 +0200 | justsomeguy | (~justsomeg@user/justsomeguy) |
| 2023-07-15 04:21:32 +0200 | <andydude> | Aside from types and pattern matching, I'm having trouble seeing why there's such a connection between Rust and Haskell... |
| 2023-07-15 04:22:30 +0200 | <glguy> | There's commonality between traits and typeclasses |
| 2023-07-15 04:22:48 +0200 | <andydude> | perhaps it's the std library's proclivity towards functional style? |
| 2023-07-15 04:24:20 +0200 | buckwheatsuperpo | (~buckwheat@209.122.211.192) (Ping timeout: 246 seconds) |
| 2023-07-15 04:24:53 +0200 | buckwheatsuperpo | (~buckwheat@209.122.211.192) |
| 2023-07-15 04:25:11 +0200 | <yin> | ADTs, people |
| 2023-07-15 04:25:27 +0200 | <ski> | hm, last i checked, you can't do full existentials in Rust, iow you can't express stuff like `exists a. Frob a *> Map Key a', but only `exists a. Frob a *> a', associating the "trait" with a single value of the unknown/abstract/opaque/forgotten/skolem type. so you can't share a single dictionary for multiple of them, simultaneously ensuring that they're all of the same (unknown) type |
| 2023-07-15 04:25:51 +0200 | alexbiehl | (~alexbiehl@2a02:8108:323f:ca14:adeb:5d31:3c95:b332) |
| 2023-07-15 04:26:22 +0200 | codaraxis | (~codaraxis@user/codaraxis) (Quit: Leaving) |
| 2023-07-15 04:30:01 +0200 | thegeekinside | (~thegeekin@189.217.90.138) |
| 2023-07-15 04:30:34 +0200 | alexbiehl | (~alexbiehl@2a02:8108:323f:ca14:adeb:5d31:3c95:b332) (Ping timeout: 272 seconds) |
| 2023-07-15 04:33:48 +0200 | segfaultfizzbuzz | (~segfaultf@23-93-74-212.fiber.dynamic.sonic.net) |
| 2023-07-15 04:35:16 +0200 | justsomeguy | (~justsomeg@user/justsomeguy) (Quit: WeeChat 3.6) |
| 2023-07-15 04:36:32 +0200 | thegeekinside | (~thegeekin@189.217.90.138) (Remote host closed the connection) |
| 2023-07-15 04:39:28 +0200 | <glguy> | Other than cargo.toml, anyone have any favorite toml file consumers they can think of? |
| 2023-07-15 04:40:26 +0200 | <andydude> | You mean like how JSON is used everywhere? |
| 2023-07-15 04:41:23 +0200 | <glguy> | Yeah, "what things do you use that consume JSON?" would have a lot of answers :) |
| 2023-07-15 04:43:00 +0200 | alexbiehl | (~alexbiehl@2a02:8108:323f:ca14:adeb:5d31:3c95:b332) |
| 2023-07-15 04:43:06 +0200 | <segfaultfizzbuzz> | what lol i had to do a double take what room i was in,... you can find a list of places toml is used on its wikipedia entry,... are you looking for test cases for a parser or what? |
| 2023-07-15 04:43:14 +0200 | AkechiShiro | (~licht@user/akechishiro) (Quit: WeeChat 4.0.2) |
| 2023-07-15 04:43:14 +0200 | ft | (~ft@p508db7ce.dip0.t-ipconnect.de) (Ping timeout: 246 seconds) |
| 2023-07-15 04:43:37 +0200 | machinedgod | (~machinedg@d198-53-218-113.abhsia.telus.net) (Quit: Lost terminal) |
| 2023-07-15 04:45:06 +0200 | <glguy> | I'm looking for variety of schemas that get used to inform a module I'm working on |
| 2023-07-15 04:45:13 +0200 | ft | (~ft@p3e9bc647.dip0.t-ipconnect.de) |
| 2023-07-15 04:45:17 +0200 | <glguy> | but yes, I've heard of wikipedia |
| 2023-07-15 04:47:25 +0200 | alexbiehl | (~alexbiehl@2a02:8108:323f:ca14:adeb:5d31:3c95:b332) (Ping timeout: 240 seconds) |
| 2023-07-15 04:48:46 +0200 | buckwheatsuperpo | (~buckwheat@209.122.211.192) (Ping timeout: 260 seconds) |
| 2023-07-15 04:48:59 +0200 | machinedgod | (~machinedg@d198-53-218-113.abhsia.telus.net) |
| 2023-07-15 04:52:38 +0200 | chexum | (~quassel@gateway/tor-sasl/chexum) (Ping timeout: 240 seconds) |
| 2023-07-15 04:54:11 +0200 | segfaultfizzbuzz | (~segfaultf@23-93-74-212.fiber.dynamic.sonic.net) (Ping timeout: 245 seconds) |
| 2023-07-15 04:54:21 +0200 | alexbiehl | (~alexbiehl@2a02:8108:323f:ca14:adeb:5d31:3c95:b332) |
| 2023-07-15 04:56:28 +0200 | FinnElija | (~finn_elij@user/finn-elija/x-0085643) (Killed (NickServ (Forcing logout FinnElija -> finn_elija))) |
| 2023-07-15 04:56:28 +0200 | finn_elija | (~finn_elij@user/finn-elija/x-0085643) |
| 2023-07-15 04:56:29 +0200 | finn_elija | FinnElija |
| 2023-07-15 04:58:38 +0200 | alexbiehl | (~alexbiehl@2a02:8108:323f:ca14:adeb:5d31:3c95:b332) (Ping timeout: 246 seconds) |
| 2023-07-15 05:03:41 +0200 | buckwheatsuperpo | (~buckwheat@209.122.211.192) |
| 2023-07-15 05:03:54 +0200 | harveypwca | (~harveypwc@2601:246:c180:a570:3828:d8:e523:3f67) |
| 2023-07-15 05:05:12 +0200 | aforemny_ | (~aforemny@2001:9e8:6cf7:a100:5893:6a08:1072:daeb) |
| 2023-07-15 05:05:22 +0200 | aforemny | (~aforemny@2001:9e8:6ced:8a00:6429:b02a:8db7:75db) (Ping timeout: 245 seconds) |
| 2023-07-15 05:07:52 +0200 | buckwheatsuperpo | (~buckwheat@209.122.211.192) (Ping timeout: 245 seconds) |
| 2023-07-15 05:15:55 +0200 | chexum | (~quassel@gateway/tor-sasl/chexum) |
| 2023-07-15 05:16:16 +0200 | Fischmiep | (~Fischmiep@user/Fischmiep) |
| 2023-07-15 05:19:06 +0200 | nate2 | (~nate@c-98-45-169-16.hsd1.ca.comcast.net) (Ping timeout: 260 seconds) |
| 2023-07-15 05:19:24 +0200 | arahael_ | (~arahael@1.145.21.117) (Ping timeout: 250 seconds) |
| 2023-07-15 05:35:05 +0200 | alexbiehl | (~alexbiehl@2a02:8108:323f:ca14:adeb:5d31:3c95:b332) |
| 2023-07-15 05:41:56 +0200 | azimut | (~azimut@gateway/tor-sasl/azimut) (Remote host closed the connection) |
| 2023-07-15 05:45:18 +0200 | alexbiehl | (~alexbiehl@2a02:8108:323f:ca14:adeb:5d31:3c95:b332) (Ping timeout: 272 seconds) |
| 2023-07-15 05:46:16 +0200 | segfaultfizzbuzz | (~segfaultf@23-93-74-212.fiber.dynamic.sonic.net) |
| 2023-07-15 05:47:50 +0200 | razetime | (~quassel@117.193.0.33) (Ping timeout: 272 seconds) |
| 2023-07-15 05:53:35 +0200 | falafel | (~falafel@2603-7000-a700-8710-d0d8-372c-d9a9-7a6e.res6.spectrum.com) |
| 2023-07-15 05:55:19 +0200 | azimut | (~azimut@gateway/tor-sasl/azimut) |
| 2023-07-15 05:57:02 +0200 | wroathe | (~wroathe@user/wroathe) (Ping timeout: 245 seconds) |
| 2023-07-15 05:57:41 +0200 | alexbiehl | (~alexbiehl@2a02:8108:323f:ca14:adeb:5d31:3c95:b332) |
| 2023-07-15 06:02:23 +0200 | alexbiehl | (~alexbiehl@2a02:8108:323f:ca14:adeb:5d31:3c95:b332) (Ping timeout: 264 seconds) |
| 2023-07-15 06:04:05 +0200 | alexbiehl | (~alexbiehl@2a02:8108:323f:ca14:adeb:5d31:3c95:b332) |
| 2023-07-15 06:08:44 +0200 | alexbiehl | (~alexbiehl@2a02:8108:323f:ca14:adeb:5d31:3c95:b332) (Ping timeout: 272 seconds) |
| 2023-07-15 06:10:46 +0200 | Inst_ | (~Inst@2601:6c4:4081:2fc0:d47a:e985:6970:4dd5) |
| 2023-07-15 06:11:54 +0200 | ddellacosta | (~ddellacos@146.70.166.140) (Ping timeout: 272 seconds) |
| 2023-07-15 06:12:48 +0200 | <segfaultfizzbuzz> | what aspects of a function make it more difficult to prove equivalence to another function and roughly speaking what do the scaling laws look like |
| 2023-07-15 06:13:10 +0200 | <segfaultfizzbuzz> | for example maybe as a function has another step of recursion it becomes twice as difficult to prove equivalence to another function |
| 2023-07-15 06:21:08 +0200 | alexbiehl | (~alexbiehl@2a02:8108:323f:ca14:adeb:5d31:3c95:b332) |
| 2023-07-15 06:25:50 +0200 | alexbiehl | (~alexbiehl@2a02:8108:323f:ca14:adeb:5d31:3c95:b332) (Ping timeout: 272 seconds) |
| 2023-07-15 06:27:19 +0200 | Inst_ | (~Inst@2601:6c4:4081:2fc0:d47a:e985:6970:4dd5) (Remote host closed the connection) |
| 2023-07-15 06:27:41 +0200 | Inst_ | (~Inst@2601:6c4:4081:2fc0:d47a:e985:6970:4dd5) |
| 2023-07-15 06:33:47 +0200 | notzmv | (~zmv@user/notzmv) |
| 2023-07-15 06:34:01 +0200 | ddellacosta | (~ddellacos@143.244.47.68) |
| 2023-07-15 06:36:15 +0200 | razetime | (~quassel@117.193.0.33) |
| 2023-07-15 06:42:06 +0200 | razetime | (~quassel@117.193.0.33) (Ping timeout: 245 seconds) |
| 2023-07-15 06:44:27 +0200 | alexbiehl | (~alexbiehl@2a02:8108:323f:ca14:adeb:5d31:3c95:b332) |
| 2023-07-15 06:45:04 +0200 | <monochrom> | Gödel incompleteness and the halting problem are why proving function equality is difficult. |
| 2023-07-15 06:46:04 +0200 | segfaultfizzbuzz | (~segfaultf@23-93-74-212.fiber.dynamic.sonic.net) (Ping timeout: 250 seconds) |
| 2023-07-15 06:48:53 +0200 | alexbiehl | (~alexbiehl@2a02:8108:323f:ca14:adeb:5d31:3c95:b332) (Ping timeout: 246 seconds) |
| 2023-07-15 06:50:22 +0200 | Unicorn_Princess | (~Unicorn_P@user/Unicorn-Princess/x-3540542) (Quit: Leaving) |
| 2023-07-15 06:52:27 +0200 | dtman34 | (~dtman34@c-76-156-89-180.hsd1.mn.comcast.net) (Quit: ZNC 1.8.2+deb2+b1 - https://znc.in) |
| 2023-07-15 06:52:56 +0200 | shapr | (~user@2600:1700:c640:3100:cde4:ca2f:725:21b4) (Ping timeout: 246 seconds) |
| 2023-07-15 06:53:06 +0200 | dtman34 | (~dtman34@2601:447:d000:93c9:ef2b:8d31:cda1:73ec) |
| 2023-07-15 06:53:47 +0200 | machinedgod | (~machinedg@d198-53-218-113.abhsia.telus.net) (Ping timeout: 246 seconds) |
| 2023-07-15 06:56:21 +0200 | alexbiehl | (~alexbiehl@2a02:8108:323f:ca14:adeb:5d31:3c95:b332) |
| 2023-07-15 06:57:30 +0200 | pickleju1ce | (~root@c-73-196-164-60.hsd1.nj.comcast.net) (Ping timeout: 272 seconds) |
| 2023-07-15 07:01:04 +0200 | segfaultfizzbuzz | (~segfaultf@23-93-74-212.fiber.dynamic.sonic.net) |
| 2023-07-15 07:01:25 +0200 | sm[i] | (~sm@024-165-041-186.res.spectrum.com) |
| 2023-07-15 07:01:56 +0200 | alexbiehl | (~alexbiehl@2a02:8108:323f:ca14:adeb:5d31:3c95:b332) (Ping timeout: 272 seconds) |
| 2023-07-15 07:02:16 +0200 | <sm> | In time for Rust 1.71: Interview With Senior Rust Developer in 2023 https://www.youtube.com/watch?v=TGfQu0bQTKc |
| 2023-07-15 07:02:34 +0200 | <sm> | includes some nice shouts to Haskell |
| 2023-07-15 07:02:43 +0200 | actioninja63 | (~actioninj@user/actioninja) |
| 2023-07-15 07:06:33 +0200 | dtman34_ | (~dtman34@c-76-156-89-180.hsd1.mn.comcast.net) |
| 2023-07-15 07:07:38 +0200 | dtman34 | (~dtman34@2601:447:d000:93c9:ef2b:8d31:cda1:73ec) (Ping timeout: 272 seconds) |
| 2023-07-15 07:09:22 +0200 | azimut_ | (~azimut@gateway/tor-sasl/azimut) |
| 2023-07-15 07:09:44 +0200 | alexbiehl | (~alexbiehl@2a02:8108:323f:ca14:adeb:5d31:3c95:b332) |
| 2023-07-15 07:10:25 +0200 | dtman34_ | (~dtman34@c-76-156-89-180.hsd1.mn.comcast.net) (Client Quit) |
| 2023-07-15 07:10:52 +0200 | dtman34 | (~dtman34@c-76-156-89-180.hsd1.mn.comcast.net) |
| 2023-07-15 07:12:18 +0200 | azimut | (~azimut@gateway/tor-sasl/azimut) (Ping timeout: 240 seconds) |
| 2023-07-15 07:12:50 +0200 | dtman34 | (~dtman34@c-76-156-89-180.hsd1.mn.comcast.net) (Remote host closed the connection) |
| 2023-07-15 07:13:06 +0200 | segfaultfizzbuzz | (~segfaultf@23-93-74-212.fiber.dynamic.sonic.net) (Ping timeout: 252 seconds) |
| 2023-07-15 07:13:36 +0200 | dtman34 | (~dtman34@c-76-156-89-180.hsd1.mn.comcast.net) |
| 2023-07-15 07:14:22 +0200 | alexbiehl | (~alexbiehl@2a02:8108:323f:ca14:adeb:5d31:3c95:b332) (Ping timeout: 260 seconds) |
| 2023-07-15 07:15:57 +0200 | nate2 | (~nate@c-98-45-169-16.hsd1.ca.comcast.net) |
| 2023-07-15 07:16:30 +0200 | segfaultfizzbuzz | (~segfaultf@23-93-74-212.fiber.dynamic.sonic.net) |
| 2023-07-15 07:20:18 +0200 | nate2 | (~nate@c-98-45-169-16.hsd1.ca.comcast.net) (Ping timeout: 250 seconds) |
| 2023-07-15 07:20:51 +0200 | segfaultfizzbuzz | (~segfaultf@23-93-74-212.fiber.dynamic.sonic.net) (Ping timeout: 245 seconds) |
| 2023-07-15 07:21:06 +0200 | alexbiehl | (~alexbiehl@2a02:8108:323f:ca14:adeb:5d31:3c95:b332) |
| 2023-07-15 07:24:58 +0200 | segfaultfizzbuzz | (~segfaultf@23-93-74-212.fiber.dynamic.sonic.net) |
| 2023-07-15 07:25:25 +0200 | alexbiehl | (~alexbiehl@2a02:8108:323f:ca14:adeb:5d31:3c95:b332) (Ping timeout: 240 seconds) |
| 2023-07-15 07:25:50 +0200 | dcoutts | (~duncan@212.187.244.66) |
| 2023-07-15 07:30:26 +0200 | dcoutts | (~duncan@212.187.244.66) (Ping timeout: 245 seconds) |
| 2023-07-15 07:30:37 +0200 | fweht | (uid404746@id-404746.lymington.irccloud.com) (Quit: Connection closed for inactivity) |
| 2023-07-15 07:32:28 +0200 | alexbiehl | (~alexbiehl@2a02:8108:323f:ca14:adeb:5d31:3c95:b332) |
| 2023-07-15 07:33:22 +0200 | mbuf | (~Shakthi@49.207.178.186) |
| 2023-07-15 07:34:32 +0200 | falafel | (~falafel@2603-7000-a700-8710-d0d8-372c-d9a9-7a6e.res6.spectrum.com) (Ping timeout: 245 seconds) |
| 2023-07-15 07:36:29 +0200 | lav | (~pi@wikipedia/maddy-from-celeste) (Ping timeout: 246 seconds) |
| 2023-07-15 07:36:37 +0200 | nick3 | (~nick@2600:8807:9084:7800:8973:eff0:2771:c97b) (Ping timeout: 245 seconds) |
| 2023-07-15 07:36:50 +0200 | alexbiehl | (~alexbiehl@2a02:8108:323f:ca14:adeb:5d31:3c95:b332) (Ping timeout: 246 seconds) |
| 2023-07-15 07:36:52 +0200 | lav | (~pi@wikipedia/maddy-from-celeste) |
| 2023-07-15 07:38:06 +0200 | nick3 | (~nick@2600:8807:9084:7800:8973:eff0:2771:c97b) |
| 2023-07-15 07:43:20 +0200 | nick3 | (~nick@2600:8807:9084:7800:8973:eff0:2771:c97b) (Ping timeout: 246 seconds) |
| 2023-07-15 07:44:24 +0200 | alexbiehl | (~alexbiehl@2a02:8108:323f:ca14:adeb:5d31:3c95:b332) |
| 2023-07-15 07:46:51 +0200 | gurkenglas | (~gurkengla@dynamic-046-114-182-179.46.114.pool.telefonica.de) |
| 2023-07-15 07:47:03 +0200 | trev | (~trev@user/trev) |
| 2023-07-15 07:48:44 +0200 | alexbiehl | (~alexbiehl@2a02:8108:323f:ca14:adeb:5d31:3c95:b332) (Ping timeout: 246 seconds) |
| 2023-07-15 07:53:55 +0200 | YoungFrog | (~youngfrog@2a02:a03f:ca07:f900:f0ec:6c5a:a5bd:1b2) |
| 2023-07-15 07:56:24 +0200 | segfaultfizzbuzz | (~segfaultf@23-93-74-212.fiber.dynamic.sonic.net) (Ping timeout: 272 seconds) |
| 2023-07-15 08:00:21 +0200 | nick3 | (~nick@2600:8807:9084:7800:8973:eff0:2771:c97b) |
| 2023-07-15 08:01:12 +0200 | alexbiehl | (~alexbiehl@2a02:8108:323f:ca14:adeb:5d31:3c95:b332) |
| 2023-07-15 08:04:38 +0200 | bontaq | (~user@ool-45779b84.dyn.optonline.net) (Ping timeout: 272 seconds) |
| 2023-07-15 08:05:22 +0200 | alexbiehl | (~alexbiehl@2a02:8108:323f:ca14:adeb:5d31:3c95:b332) (Ping timeout: 245 seconds) |
| 2023-07-15 08:07:35 +0200 | alexbiehl | (~alexbiehl@2a02:8108:323f:ca14:adeb:5d31:3c95:b332) |
| 2023-07-15 08:08:42 +0200 | neuroevolutus | (~neuroevol@2001:ac8:9a:76::1e) |
| 2023-07-15 08:08:43 +0200 | dcoutts | (~duncan@185.201.60.220) |
| 2023-07-15 08:11:55 +0200 | alexbiehl | (~alexbiehl@2a02:8108:323f:ca14:adeb:5d31:3c95:b332) (Ping timeout: 240 seconds) |
| 2023-07-15 08:12:35 +0200 | myme | (~myme@2a01:799:d60:e400:a779:7b8:869:aeae) (Ping timeout: 264 seconds) |
| 2023-07-15 08:13:03 +0200 | neuroevolutus | (~neuroevol@2001:ac8:9a:76::1e) (Client Quit) |
| 2023-07-15 08:13:34 +0200 | myme | (~myme@2a01:799:d60:e400:6b55:76d2:6f55:56c) |
| 2023-07-15 08:13:48 +0200 | curby | (~curby@cpe-76-183-125-175.tx.res.rr.com) (Read error: Connection reset by peer) |
| 2023-07-15 08:18:45 +0200 | misterfish | (~misterfis@84-53-85-146.bbserv.nl) |
| 2023-07-15 08:18:56 +0200 | alexbiehl | (~alexbiehl@2a02:8108:323f:ca14:adeb:5d31:3c95:b332) |
| 2023-07-15 08:21:04 +0200 | fweht | (uid404746@id-404746.lymington.irccloud.com) |
| 2023-07-15 08:21:55 +0200 | harveypwca | (~harveypwc@2601:246:c180:a570:3828:d8:e523:3f67) (Quit: Leaving) |
| 2023-07-15 08:23:38 +0200 | alexbiehl | (~alexbiehl@2a02:8108:323f:ca14:adeb:5d31:3c95:b332) (Ping timeout: 272 seconds) |
| 2023-07-15 08:29:14 +0200 | acidjnk | (~acidjnk@p200300d6e7072f973457f07d23c910df.dip0.t-ipconnect.de) |
| 2023-07-15 08:36:15 +0200 | alexbiehl | (~alexbiehl@2a02:8108:323f:ca14::ac08) |
| 2023-07-15 08:37:27 +0200 | dcoutts | (~duncan@185.201.60.220) (Ping timeout: 245 seconds) |
| 2023-07-15 08:40:24 +0200 | rainbyte | (~rainbyte@181.31.239.226) |
| 2023-07-15 08:40:42 +0200 | alexbiehl | (~alexbiehl@2a02:8108:323f:ca14::ac08) (Ping timeout: 260 seconds) |
| 2023-07-15 08:41:34 +0200 | gmg | (~user@user/gehmehgeh) |
| 2023-07-15 08:46:45 +0200 | gurkenglas | (~gurkengla@dynamic-046-114-182-179.46.114.pool.telefonica.de) (Read error: Connection reset by peer) |
| 2023-07-15 08:47:37 +0200 | alexbiehl | (~alexbiehl@2a02:8108:323f:ca14:adeb:5d31:3c95:b332) |
| 2023-07-15 08:48:48 +0200 | bliminse | (~bliminse@user/bliminse) (Quit: leaving) |
| 2023-07-15 08:52:46 +0200 | alexbiehl | (~alexbiehl@2a02:8108:323f:ca14:adeb:5d31:3c95:b332) (Ping timeout: 272 seconds) |
| 2023-07-15 09:00:32 +0200 | alexbiehl | (~alexbiehl@2a02:8108:323f:ca14:adeb:5d31:3c95:b332) |
| 2023-07-15 09:03:38 +0200 | mechap | (~mechap@user/mechap) (Ping timeout: 246 seconds) |
| 2023-07-15 09:04:25 +0200 | nick3 | (~nick@2600:8807:9084:7800:8973:eff0:2771:c97b) (Ping timeout: 240 seconds) |
| 2023-07-15 09:04:55 +0200 | mechap | (~mechap@user/mechap) |
| 2023-07-15 09:05:00 +0200 | takuan | (~takuan@178-116-218-225.access.telenet.be) |
| 2023-07-15 09:11:46 +0200 | segfaultfizzbuzz | (~segfaultf@23-93-74-212.fiber.dynamic.sonic.net) |
| 2023-07-15 09:13:32 +0200 | andydude | (~andrewr@151.200.15.152) () |
| 2023-07-15 09:15:21 +0200 | gurkenglas | (~gurkengla@dynamic-046-114-182-179.46.114.pool.telefonica.de) |
| 2023-07-15 09:16:49 +0200 | nick3 | (~nick@2600:8807:9084:7800:8973:eff0:2771:c97b) |
| 2023-07-15 09:17:00 +0200 | jrm | (~jrm@user/jrm) (Quit: ciao) |
| 2023-07-15 09:17:20 +0200 | jrm | (~jrm@user/jrm) |
| 2023-07-15 09:17:50 +0200 | alexbiehl | (~alexbiehl@2a02:8108:323f:ca14:adeb:5d31:3c95:b332) (Ping timeout: 246 seconds) |
| 2023-07-15 09:20:17 +0200 | alexbiehl | (~alexbiehl@2a02:8108:323f:ca14:adeb:5d31:3c95:b332) |
| 2023-07-15 09:21:08 +0200 | nick3 | (~nick@2600:8807:9084:7800:8973:eff0:2771:c97b) (Ping timeout: 246 seconds) |
| 2023-07-15 09:32:11 +0200 | alexbiehl | (~alexbiehl@2a02:8108:323f:ca14:adeb:5d31:3c95:b332) (Ping timeout: 246 seconds) |
| 2023-07-15 09:33:48 +0200 | nick3 | (~nick@2600:8807:9084:7800:8973:eff0:2771:c97b) |
| 2023-07-15 09:35:59 +0200 | misterfish | (~misterfis@84-53-85-146.bbserv.nl) (Ping timeout: 264 seconds) |
| 2023-07-15 09:36:16 +0200 | euandreh | (~Thunderbi@189.6.18.7) (Ping timeout: 245 seconds) |
| 2023-07-15 09:39:11 +0200 | segfaultfizzbuzz | (~segfaultf@23-93-74-212.fiber.dynamic.sonic.net) (Ping timeout: 245 seconds) |
| 2023-07-15 09:44:04 +0200 | ddellacosta | (~ddellacos@143.244.47.68) (Ping timeout: 272 seconds) |
| 2023-07-15 09:47:21 +0200 | econo_ | (uid147250@id-147250.tinside.irccloud.com) (Quit: Connection closed for inactivity) |
| 2023-07-15 09:47:52 +0200 | elkcl | (~elkcl@broadband-95-84-180-37.ip.moscow.rt.ru) (Ping timeout: 272 seconds) |
| 2023-07-15 09:48:34 +0200 | alexbiehl | (~alexbiehl@2a02:8108:323f:ca14:adeb:5d31:3c95:b332) |
| 2023-07-15 09:50:13 +0200 | <claro> | λ |
| 2023-07-15 09:50:16 +0200 | <claro> | oop |
| 2023-07-15 09:52:04 +0200 | dhil | (~dhil@78.45.150.83.ewm.ftth.as8758.net) |
| 2023-07-15 09:53:34 +0200 | alexbiehl | (~alexbiehl@2a02:8108:323f:ca14:adeb:5d31:3c95:b332) (Ping timeout: 272 seconds) |
| 2023-07-15 09:55:30 +0200 | alexbiehl | (~alexbiehl@2a02:8108:323f:ca14:adeb:5d31:3c95:b332) |
| 2023-07-15 09:55:47 +0200 | elkcl | (~elkcl@broadband-95-84-180-37.ip.moscow.rt.ru) |
| 2023-07-15 09:57:08 +0200 | euandreh | (~Thunderbi@189.6.18.7) |
| 2023-07-15 09:58:08 +0200 | <jade[m]> | lambda indeed |
| 2023-07-15 10:04:06 +0200 | alexbiehl | (~alexbiehl@2a02:8108:323f:ca14:adeb:5d31:3c95:b332) (Remote host closed the connection) |
| 2023-07-15 10:04:21 +0200 | alexbiehl | (~alexbiehl@2a02:8108:323f:ca14:adeb:5d31:3c95:b332) |
| 2023-07-15 10:13:29 +0200 | oo_miguel | (~Thunderbi@78-11-179-96.static.ip.netia.com.pl) |
| 2023-07-15 10:15:24 +0200 | _ht | (~Thunderbi@28-52-174-82.ftth.glasoperator.nl) |
| 2023-07-15 10:20:28 +0200 | Tuplanolla | (~Tuplanoll@91-159-68-236.elisa-laajakaista.fi) |
| 2023-07-15 10:21:29 +0200 | misterfish | (~misterfis@84-53-85-146.bbserv.nl) |
| 2023-07-15 10:24:38 +0200 | bliminse | (~bliminse@user/bliminse) |
| 2023-07-15 10:30:25 +0200 | tzh | (~tzh@c-24-21-73-154.hsd1.wa.comcast.net) (Quit: zzz) |
| 2023-07-15 10:30:37 +0200 | fweht | (uid404746@id-404746.lymington.irccloud.com) (Quit: Connection closed for inactivity) |
| 2023-07-15 10:34:26 +0200 | hackyhacker | (~hackyhack@2a05:f480:1400:24b2:5400:4ff:fe76:a8f3) |
| 2023-07-15 10:37:16 +0200 | nick3 | (~nick@2600:8807:9084:7800:8973:eff0:2771:c97b) (Ping timeout: 272 seconds) |
| 2023-07-15 10:40:35 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2023-07-15 10:42:58 +0200 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Ping timeout: 240 seconds) |
| 2023-07-15 10:45:12 +0200 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:6cd6:b2b2:8eef:d429) (Remote host closed the connection) |
| 2023-07-15 10:45:59 +0200 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) |
| 2023-07-15 10:49:10 +0200 | nick3 | (~nick@2600:8807:9084:7800:8973:eff0:2771:c97b) |
| 2023-07-15 10:49:32 +0200 | <claro> | ;> |
| 2023-07-15 10:53:42 +0200 | nick3 | (~nick@2600:8807:9084:7800:8973:eff0:2771:c97b) (Ping timeout: 260 seconds) |
| 2023-07-15 10:55:56 +0200 | claro_ | (~claro@45.84.139.156) |
| 2023-07-15 10:56:34 +0200 | claro_ | (~claro@45.84.139.156) (Client Quit) |
| 2023-07-15 10:57:21 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2023-07-15 10:58:00 +0200 | claro_ | (~claro@user/Claro) |
| 2023-07-15 10:58:08 +0200 | claro_ | (~claro@user/Claro) (Client Quit) |
| 2023-07-15 10:59:26 +0200 | dibblego | (~dibblego@haskell/developer/dibblego) (Ping timeout: 272 seconds) |
| 2023-07-15 11:00:11 +0200 | ft | (~ft@p3e9bc647.dip0.t-ipconnect.de) (Ping timeout: 246 seconds) |
| 2023-07-15 11:00:13 +0200 | nick3 | (~nick@2600:8807:9084:7800:8973:eff0:2771:c97b) |
| 2023-07-15 11:00:30 +0200 | claro_ | (~claro@user/Claro) |
| 2023-07-15 11:01:01 +0200 | ft | (~ft@p4fc2a1e5.dip0.t-ipconnect.de) |
| 2023-07-15 11:04:53 +0200 | claro_ | (~claro@user/Claro) (Client Quit) |
| 2023-07-15 11:05:08 +0200 | nick3 | (~nick@2600:8807:9084:7800:8973:eff0:2771:c97b) (Ping timeout: 272 seconds) |
| 2023-07-15 11:05:20 +0200 | dibblego | (~dibblego@116-255-1-157.ip4.superloop.au) |
| 2023-07-15 11:05:20 +0200 | dibblego | (~dibblego@116-255-1-157.ip4.superloop.au) (Changing host) |
| 2023-07-15 11:05:20 +0200 | dibblego | (~dibblego@haskell/developer/dibblego) |
| 2023-07-15 11:08:52 +0200 | misterfish | (~misterfis@84-53-85-146.bbserv.nl) (Ping timeout: 252 seconds) |
| 2023-07-15 11:10:01 +0200 | alexbiehl | (~alexbiehl@2a02:8108:323f:ca14:adeb:5d31:3c95:b332) (Remote host closed the connection) |
| 2023-07-15 11:10:34 +0200 | alexbiehl | (~alexbiehl@2a02:8108:323f:ca14:adeb:5d31:3c95:b332) |
| 2023-07-15 11:11:31 +0200 | wootehfoot | (~wootehfoo@user/wootehfoot) |
| 2023-07-15 11:11:43 +0200 | nick3 | (~nick@2600:8807:9084:7800:8973:eff0:2771:c97b) |
| 2023-07-15 11:17:00 +0200 | nate2 | (~nate@c-98-45-169-16.hsd1.ca.comcast.net) |
| 2023-07-15 11:17:24 +0200 | alexbiehl | (~alexbiehl@2a02:8108:323f:ca14:adeb:5d31:3c95:b332) (Ping timeout: 246 seconds) |
| 2023-07-15 11:21:42 +0200 | nate2 | (~nate@c-98-45-169-16.hsd1.ca.comcast.net) (Ping timeout: 252 seconds) |
| 2023-07-15 11:23:49 +0200 | alexbiehl | (~alexbiehl@2a02:8108:323f:ca14:adeb:5d31:3c95:b332) |
| 2023-07-15 11:28:17 +0200 | alexbiehl | (~alexbiehl@2a02:8108:323f:ca14:adeb:5d31:3c95:b332) (Ping timeout: 245 seconds) |
| 2023-07-15 11:31:17 +0200 | alexbiehl | (~alexbiehl@2a02:8108:323f:ca14:adeb:5d31:3c95:b332) |
| 2023-07-15 11:33:00 +0200 | titibandit | (~titibandi@user/titibandit) |
| 2023-07-15 11:33:46 +0200 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) (Ping timeout: 245 seconds) |
| 2023-07-15 11:33:48 +0200 | dibblego | (~dibblego@haskell/developer/dibblego) (Ping timeout: 250 seconds) |
| 2023-07-15 11:35:09 +0200 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) |
| 2023-07-15 11:35:32 +0200 | alexbiehl | (~alexbiehl@2a02:8108:323f:ca14:adeb:5d31:3c95:b332) (Ping timeout: 246 seconds) |
| 2023-07-15 11:38:24 +0200 | alexbiehl | (~alexbiehl@2a02:8108:323f:ca14:adeb:5d31:3c95:b332) |
| 2023-07-15 11:39:28 +0200 | mei | (~mei@user/mei) (Quit: mei) |
| 2023-07-15 11:41:42 +0200 | mei | (~mei@user/mei) |
| 2023-07-15 11:41:59 +0200 | [itchyjunk] | (~itchyjunk@user/itchyjunk/x-7353470) (Read error: Connection reset by peer) |
| 2023-07-15 11:42:59 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2023-07-15 11:45:43 +0200 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:708b:7aa2:8b48:d8a9) |
| 2023-07-15 11:48:52 +0200 | Inst__ | (~Inst@2601:6c4:4081:2fc0:d87:979c:1a0c:2c8c) |
| 2023-07-15 11:49:55 +0200 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:708b:7aa2:8b48:d8a9) (Ping timeout: 240 seconds) |
| 2023-07-15 11:52:28 +0200 | Tlsx | (~rscastilh@187.40.124.54) |
| 2023-07-15 11:52:41 +0200 | Inst_ | (~Inst@2601:6c4:4081:2fc0:d47a:e985:6970:4dd5) (Ping timeout: 246 seconds) |
| 2023-07-15 11:56:55 +0200 | alexbiehl | (~alexbiehl@2a02:8108:323f:ca14:adeb:5d31:3c95:b332) (Ping timeout: 240 seconds) |
| 2023-07-15 11:57:39 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2023-07-15 11:58:39 +0200 | alexbiehl | (~alexbiehl@2a02:8108:323f:ca14:adeb:5d31:3c95:b332) |
| 2023-07-15 12:00:38 +0200 | gnalzo | (~gnalzo@2a01:e0a:498:fd50:fcc6:bb5d:489a:ce8c) |
| 2023-07-15 12:01:55 +0200 | Sgeo | (~Sgeo@user/sgeo) (Read error: Connection reset by peer) |
| 2023-07-15 12:04:14 +0200 | dhil | (~dhil@78.45.150.83.ewm.ftth.as8758.net) (Ping timeout: 246 seconds) |
| 2023-07-15 12:04:55 +0200 | mei | (~mei@user/mei) (Ping timeout: 240 seconds) |
| 2023-07-15 12:09:54 +0200 | jmdaemon | (~jmdaemon@user/jmdaemon) (Ping timeout: 246 seconds) |
| 2023-07-15 12:12:40 +0200 | __monty__ | (~toonn@user/toonn) |
| 2023-07-15 12:15:50 +0200 | dibblego | (~dibblego@116-255-1-157.ip4.superloop.au) |
| 2023-07-15 12:15:50 +0200 | dibblego | (~dibblego@116-255-1-157.ip4.superloop.au) (Changing host) |
| 2023-07-15 12:15:50 +0200 | dibblego | (~dibblego@haskell/developer/dibblego) |
| 2023-07-15 12:20:23 +0200 | nick3 | (~nick@2600:8807:9084:7800:8973:eff0:2771:c97b) (Ping timeout: 264 seconds) |
| 2023-07-15 12:22:53 +0200 | arahael_ | (~arahael@124-149-31-4.dyn.iinet.net.au) |
| 2023-07-15 12:26:28 +0200 | marea_ | (~francesco@151.43.229.234) |
| 2023-07-15 12:28:46 +0200 | sm[i] | (~sm@024-165-041-186.res.spectrum.com) (Quit: sm[i]) |
| 2023-07-15 12:29:27 +0200 | perrierjouet | (~perrierjo@modemcable048.127-56-74.mc.videotron.ca) |
| 2023-07-15 12:30:57 +0200 | alexbiehl | (~alexbiehl@2a02:8108:323f:ca14:adeb:5d31:3c95:b332) (Remote host closed the connection) |
| 2023-07-15 12:31:52 +0200 | alexbiehl | (~alexbiehl@2a02:8108:323f:ca14:adeb:5d31:3c95:b332) |
| 2023-07-15 12:32:13 +0200 | nick3 | (~nick@2600:8807:9084:7800:8973:eff0:2771:c97b) |
| 2023-07-15 12:33:05 +0200 | marea_ | (~francesco@151.43.229.234) (Remote host closed the connection) |
| 2023-07-15 12:33:37 +0200 | danza | (~francesco@151.43.229.234) |
| 2023-07-15 12:36:12 +0200 | alexbiehl | (~alexbiehl@2a02:8108:323f:ca14:adeb:5d31:3c95:b332) (Ping timeout: 245 seconds) |
| 2023-07-15 12:36:50 +0200 | pavonia | (~user@user/siracusa) (Read error: Connection reset by peer) |
| 2023-07-15 12:38:17 +0200 | danza | (~francesco@151.43.229.234) (Remote host closed the connection) |
| 2023-07-15 12:38:30 +0200 | danza | (~francesco@151.43.229.234) |
| 2023-07-15 12:39:33 +0200 | pavonia | (~user@user/siracusa) |
| 2023-07-15 12:42:48 +0200 | danza | (~francesco@151.43.229.234) (Ping timeout: 246 seconds) |
| 2023-07-15 12:43:23 +0200 | <arahael_> | So I'm working through the haskell wiki again for: https://wiki.haskell.org/All_About_Monads#The_State_monad and I'm wondering how does one implement that MonadState typeclass and instance without those language extensions? |
| 2023-07-15 12:43:34 +0200 | <arahael_> | It seems to require three language extensions.. |
| 2023-07-15 12:47:07 +0200 | picklejuice | (~root@c-73-196-164-60.hsd1.nj.comcast.net) |
| 2023-07-15 12:53:00 +0200 | shriekingnoise | (~shrieking@186.137.175.87) (Ping timeout: 252 seconds) |
| 2023-07-15 12:55:48 +0200 | <ncf> | you could monomorphise the state, i guess? |
| 2023-07-15 12:57:12 +0200 | <ncf> | or do dictionary passing |
| 2023-07-15 12:58:48 +0200 | <arahael_> | ncf: My haskell is still rather basic, do you have an article about that? |
| 2023-07-15 12:59:21 +0200 | <arahael_> | I guess in a way of speaking, I'm asking "how was this done in 2010?" |
| 2023-07-15 12:59:54 +0200 | <arahael_> | Not honestly trying to do the 2023 MonadState in 2010, more wondering how perhaps a simpler one was done instead. |
| 2023-07-15 13:00:19 +0200 | <ncf> | i don't think so |
| 2023-07-15 13:01:00 +0200 | <ncf> | re dictionary passing, i guess https://okmij.org/ftp/Computation/typeclass.html |
| 2023-07-15 13:01:29 +0200 | <ncf> | and by monomorphising the state i mean like class MonadStateFoo m where state :: (Foo -> (a, Foo)) -> m a |
| 2023-07-15 13:01:42 +0200 | <ncf> | a separate class for each state type |
| 2023-07-15 13:03:22 +0200 | <arahael_> | Ah, that makes sense. Was that how it was done in 2010, though? |
| 2023-07-15 13:04:46 +0200 | <ncf> | looks like mtl 1.0 already uses MultiParamTypeClasses, FunctionalDependencies |
| 2023-07-15 13:05:02 +0200 | <ncf> | so you would just not use mtl in haskell 2010 |
| 2023-07-15 13:06:34 +0200 | alexbiehl | (~alexbiehl@2a02:8108:323f:ca14:adeb:5d31:3c95:b332) |
| 2023-07-15 13:07:56 +0200 | tremon | (~tremon@83.80.159.219) |
| 2023-07-15 13:08:16 +0200 | <arahael_> | Yeah I'm implementing my own State monad, though, so no mtl at all. |
| 2023-07-15 13:11:10 +0200 | alexbiehl | (~alexbiehl@2a02:8108:323f:ca14:adeb:5d31:3c95:b332) (Ping timeout: 272 seconds) |
| 2023-07-15 13:12:50 +0200 | buckwheatsuperpo | (~buckwheat@209.122.211.192) |
| 2023-07-15 13:19:10 +0200 | marinelli[m] | (~marinelli@2001:470:69fc:105::2d8) |
| 2023-07-15 13:20:36 +0200 | L29Ah | (~L29Ah@wikipedia/L29Ah) () |
| 2023-07-15 13:22:45 +0200 | <arahael_> | Well, I'm off to bed. :) Take care, ncf! |
| 2023-07-15 13:23:05 +0200 | L29Ah | (~L29Ah@wikipedia/L29Ah) |
| 2023-07-15 13:25:05 +0200 | alexbiehl | (~alexbiehl@2a02:8108:323f:ca14:adeb:5d31:3c95:b332) |
| 2023-07-15 13:29:56 +0200 | gnalzo | (~gnalzo@2a01:e0a:498:fd50:fcc6:bb5d:489a:ce8c) (Quit: WeeChat 4.0.1) |
| 2023-07-15 13:35:52 +0200 | nick3 | (~nick@2600:8807:9084:7800:8973:eff0:2771:c97b) (Ping timeout: 272 seconds) |
| 2023-07-15 13:40:44 +0200 | Raito_Bezarius | (~Raito@wireguard/tunneler/raito-bezarius) |
| 2023-07-15 13:42:50 +0200 | alexbiehl | (~alexbiehl@2a02:8108:323f:ca14:adeb:5d31:3c95:b332) (Ping timeout: 272 seconds) |
| 2023-07-15 13:44:53 +0200 | alexbiehl | (~alexbiehl@2a02:8108:323f:ca14:adeb:5d31:3c95:b332) |
| 2023-07-15 13:47:54 +0200 | nick3 | (~nick@2600:8807:9084:7800:8973:eff0:2771:c97b) |
| 2023-07-15 13:49:07 +0200 | alexbiehl | (~alexbiehl@2a02:8108:323f:ca14:adeb:5d31:3c95:b332) (Ping timeout: 245 seconds) |
| 2023-07-15 13:49:36 +0200 | L29Ah | (~L29Ah@wikipedia/L29Ah) () |
| 2023-07-15 13:59:51 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2023-07-15 14:02:43 +0200 | fweht | (uid404746@id-404746.lymington.irccloud.com) |
| 2023-07-15 14:05:42 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2023-07-15 14:10:26 +0200 | arahael_ | (~arahael@124-149-31-4.dyn.iinet.net.au) (Ping timeout: 245 seconds) |
| 2023-07-15 14:16:12 +0200 | nick3 | (~nick@2600:8807:9084:7800:8973:eff0:2771:c97b) (Ping timeout: 245 seconds) |
| 2023-07-15 14:18:03 +0200 | misterfish | (~misterfis@84-53-85-146.bbserv.nl) |
| 2023-07-15 14:21:26 +0200 | nick3 | (~nick@2600:8807:9084:7800:8973:eff0:2771:c97b) |
| 2023-07-15 14:23:09 +0200 | alexbiehl | (~alexbiehl@2a02:8108:323f:ca14:adeb:5d31:3c95:b332) |
| 2023-07-15 14:25:26 +0200 | pavonia | (~user@user/siracusa) (Quit: Bye!) |
| 2023-07-15 14:29:36 +0200 | gurkenglas | (~gurkengla@dynamic-046-114-182-179.46.114.pool.telefonica.de) (Ping timeout: 245 seconds) |
| 2023-07-15 14:30:52 +0200 | waleee | (~waleee@2001:9b0:21c:4000:5bf9:6515:c030:57b7) |
| 2023-07-15 14:35:16 +0200 | ezzieyguywuf | (~Unknown@user/ezzieyguywuf) (Remote host closed the connection) |
| 2023-07-15 14:35:24 +0200 | misterfish | (~misterfis@84-53-85-146.bbserv.nl) (Ping timeout: 272 seconds) |
| 2023-07-15 14:36:34 +0200 | ezzieyguywuf | (~Unknown@user/ezzieyguywuf) |
| 2023-07-15 14:38:38 +0200 | notzmv | (~zmv@user/notzmv) (Ping timeout: 260 seconds) |
| 2023-07-15 14:39:50 +0200 | alexbiehl | (~alexbiehl@2a02:8108:323f:ca14:adeb:5d31:3c95:b332) (Ping timeout: 272 seconds) |
| 2023-07-15 14:41:44 +0200 | nick3 | (~nick@2600:8807:9084:7800:8973:eff0:2771:c97b) (Ping timeout: 246 seconds) |
| 2023-07-15 14:48:44 +0200 | gurkenglas | (~gurkengla@dynamic-046-114-182-179.46.114.pool.telefonica.de) |
| 2023-07-15 14:55:56 +0200 | gurkenglas | (~gurkengla@dynamic-046-114-182-179.46.114.pool.telefonica.de) (Ping timeout: 246 seconds) |
| 2023-07-15 15:03:40 +0200 | alexbiehl | (~alexbiehl@2a02:8108:323f:ca14:adeb:5d31:3c95:b332) |
| 2023-07-15 15:07:31 +0200 | connrs | (~connrs@user/connrs) (Read error: Connection reset by peer) |
| 2023-07-15 15:07:52 +0200 | alexbiehl | (~alexbiehl@2a02:8108:323f:ca14:adeb:5d31:3c95:b332) (Ping timeout: 245 seconds) |
| 2023-07-15 15:08:14 +0200 | connrs | (~connrs@user/connrs) |
| 2023-07-15 15:10:46 +0200 | alexbiehl | (~alexbiehl@2a02:8108:323f:ca14:adeb:5d31:3c95:b332) |
| 2023-07-15 15:15:59 +0200 | jrm | (~jrm@user/jrm) (Read error: Connection reset by peer) |
| 2023-07-15 15:16:04 +0200 | jrm2 | (~jrm@user/jrm) |
| 2023-07-15 15:17:21 +0200 | jrm2 | jrm |
| 2023-07-15 15:18:32 +0200 | nate2 | (~nate@c-98-45-169-16.hsd1.ca.comcast.net) |
| 2023-07-15 15:20:25 +0200 | waleee | (~waleee@2001:9b0:21c:4000:5bf9:6515:c030:57b7) (Ping timeout: 240 seconds) |
| 2023-07-15 15:23:32 +0200 | nate2 | (~nate@c-98-45-169-16.hsd1.ca.comcast.net) (Ping timeout: 272 seconds) |
| 2023-07-15 15:26:48 +0200 | segfaultfizzbuzz | (~segfaultf@23-93-74-212.fiber.dynamic.sonic.net) |
| 2023-07-15 15:28:36 +0200 | alexbiehl | (~alexbiehl@2a02:8108:323f:ca14:adeb:5d31:3c95:b332) (Ping timeout: 272 seconds) |
| 2023-07-15 15:39:51 +0200 | aslni0x | (uid601037@id-601037.hampstead.irccloud.com) |
| 2023-07-15 15:41:59 +0200 | ddellacosta | (~ddellacos@143.244.47.100) |
| 2023-07-15 15:44:17 +0200 | aslni0x | (uid601037@id-601037.hampstead.irccloud.com) () |
| 2023-07-15 15:46:29 +0200 | alexbiehl | (~alexbiehl@2a02:8108:323f:ca14:adeb:5d31:3c95:b332) |
| 2023-07-15 15:49:54 +0200 | L29Ah | (~L29Ah@wikipedia/L29Ah) |
| 2023-07-15 15:50:41 +0200 | alexbiehl | (~alexbiehl@2a02:8108:323f:ca14:adeb:5d31:3c95:b332) (Ping timeout: 246 seconds) |
| 2023-07-15 15:52:38 +0200 | gnalzo | (~gnalzo@2a01:e0a:498:fd50:fcc6:bb5d:489a:ce8c) |
| 2023-07-15 15:59:25 +0200 | sm[i] | (~sm@024-165-041-186.res.spectrum.com) |
| 2023-07-15 16:00:04 +0200 | sm[i] | (~sm@024-165-041-186.res.spectrum.com) (Client Quit) |
| 2023-07-15 16:00:36 +0200 | bontaq | (~user@ool-45779b84.dyn.optonline.net) |
| 2023-07-15 16:01:41 +0200 | segfaultfizzbuzz | (~segfaultf@23-93-74-212.fiber.dynamic.sonic.net) (Ping timeout: 245 seconds) |
| 2023-07-15 16:04:52 +0200 | alexbiehl | (~alexbiehl@2a02:8108:323f:ca14:adeb:5d31:3c95:b332) |
| 2023-07-15 16:07:12 +0200 | shapr | (~user@2600:1700:c640:3100:4f0f:f85d:8c2f:2e77) |
| 2023-07-15 16:08:11 +0200 | <ncf> | is there a better way to do parallel (map (timeout t) l) ? |
| 2023-07-15 16:08:37 +0200 | <ncf> | the goal being [IO a] -> IO [Maybe a] |
| 2023-07-15 16:08:50 +0200 | <ncf> | i feel like it's a shame to have `length l` timeouts when there's really just noe |
| 2023-07-15 16:08:51 +0200 | <ncf> | one* |
| 2023-07-15 16:21:06 +0200 | <jade[m]> | can't you just `timeout t >> parallel l`? what am I missing here? |
| 2023-07-15 16:21:35 +0200 | <jade[m]> | wait, bad types one sec |
| 2023-07-15 16:22:09 +0200 | <jade[m]> | ok I see the issue |
| 2023-07-15 16:22:16 +0200 | Pickchea | (~private@user/pickchea) |
| 2023-07-15 16:22:31 +0200 | titibandit | (~titibandi@user/titibandit) (Ping timeout: 245 seconds) |
| 2023-07-15 16:23:53 +0200 | Pickchea | (~private@user/pickchea) (Remote host closed the connection) |
| 2023-07-15 16:24:53 +0200 | marinelli[m] | (~marinelli@2001:470:69fc:105::2d8) (Remote host closed the connection) |
| 2023-07-15 16:25:15 +0200 | <jade[m]> | fmap sequence $ timeout t (parallel l) does this work? |
| 2023-07-15 16:25:48 +0200 | <jade[m]> | no that's backwards |
| 2023-07-15 16:27:35 +0200 | alexbiehl | (~alexbiehl@2a02:8108:323f:ca14:adeb:5d31:3c95:b332) (Ping timeout: 264 seconds) |
| 2023-07-15 16:31:38 +0200 | dhil | (~dhil@78.45.150.83.ewm.ftth.as8758.net) |
| 2023-07-15 16:31:56 +0200 | segfaultfizzbuzz | (~segfaultf@23-93-74-212.fiber.dynamic.sonic.net) |
| 2023-07-15 16:47:19 +0200 | alexbiehl | (~alexbiehl@2a02:8108:323f:ca14:adeb:5d31:3c95:b332) |
| 2023-07-15 16:51:35 +0200 | alexbiehl | (~alexbiehl@2a02:8108:323f:ca14:adeb:5d31:3c95:b332) (Ping timeout: 246 seconds) |
| 2023-07-15 16:53:47 +0200 | alexbiehl | (~alexbiehl@2a02:8108:323f:ca14:adeb:5d31:3c95:b332) |
| 2023-07-15 16:54:28 +0200 | machinedgod | (~machinedg@d198-53-218-113.abhsia.telus.net) |
| 2023-07-15 16:55:57 +0200 | razetime | (~quassel@117.193.0.33) |
| 2023-07-15 16:59:17 +0200 | alexbiehl | (~alexbiehl@2a02:8108:323f:ca14:adeb:5d31:3c95:b332) (Ping timeout: 246 seconds) |
| 2023-07-15 17:05:22 +0200 | waleee | (~waleee@2001:9b0:21c:4000:5bf9:6515:c030:57b7) |
| 2023-07-15 17:09:19 +0200 | <c_wraith> | ncf: if there's only one timeout, that type looks wrong. It should be [IO a] -> IO (Maybe [a]), if I'm understanding what you're asking for. |
| 2023-07-15 17:09:38 +0200 | segfaultfizzbuzz | (~segfaultf@23-93-74-212.fiber.dynamic.sonic.net) (Ping timeout: 250 seconds) |
| 2023-07-15 17:10:18 +0200 | <ncf> | when the timeout expires, i want to collect the threads that succeeded into Just and the ones that timed out into Nothing |
| 2023-07-15 17:13:08 +0200 | alexbiehl | (~alexbiehl@2a02:8108:323f:ca14:adeb:5d31:3c95:b332) |
| 2023-07-15 17:14:13 +0200 | ub1 | (~Thunderbi@91.141.79.172.wireless.dyn.drei.com) |
| 2023-07-15 17:14:39 +0200 | ubert1 | (~Thunderbi@91.141.79.172.wireless.dyn.drei.com) |
| 2023-07-15 17:14:41 +0200 | <c_wraith> | Oh. I guess you can do that with STM, but you'll sort of need to rewrite a bunch of stuff by hand |
| 2023-07-15 17:15:42 +0200 | ub | (~Thunderbi@178.165.175.35.wireless.dyn.drei.com) (Ping timeout: 250 seconds) |
| 2023-07-15 17:15:42 +0200 | <c_wraith> | Having a bunch of calls to timeout seems easier to deal with unless you really are seeing problems from the number of threads timeout is creating |
| 2023-07-15 17:16:30 +0200 | ub1 | ub |
| 2023-07-15 17:16:54 +0200 | ubert | (~Thunderbi@178.165.175.35.wireless.dyn.drei.com) (Ping timeout: 272 seconds) |
| 2023-07-15 17:16:54 +0200 | ub | ubert |
| 2023-07-15 17:17:24 +0200 | <ncf> | that's what i thought |
| 2023-07-15 17:20:18 +0200 | segfaultfizzbuzz | (~segfaultf@23-93-74-212.fiber.dynamic.sonic.net) |
| 2023-07-15 17:22:08 +0200 | Pickchea | (~private@user/pickchea) |
| 2023-07-15 17:25:42 +0200 | segfaultfizzbuzz | (~segfaultf@23-93-74-212.fiber.dynamic.sonic.net) (Ping timeout: 260 seconds) |
| 2023-07-15 17:30:17 +0200 | alexbiehl | (~alexbiehl@2a02:8108:323f:ca14:adeb:5d31:3c95:b332) (Ping timeout: 246 seconds) |
| 2023-07-15 17:30:59 +0200 | eggplantade | (~Eggplanta@2600:1700:38c5:d800:708b:7aa2:8b48:d8a9) |
| 2023-07-15 17:36:18 +0200 | Midjak | (~Midjak@82.66.147.146) |
| 2023-07-15 17:37:16 +0200 | CrunchyFlakes | (~pi4@ip5f5b4693.dynamic.kabel-deutschland.de) |
| 2023-07-15 17:39:06 +0200 | wootehfoot | (~wootehfoo@user/wootehfoot) (Ping timeout: 250 seconds) |
| 2023-07-15 17:43:19 +0200 | <glguy> | ncf: I don't know that it's better, but you could use the async package, make a bunch of asyncs, wait on a single timer, and then `traverse \a -> cancel a >> waitCatch a` |
| 2023-07-15 17:44:46 +0200 | son0p | (~ff@181.136.122.143) (Ping timeout: 272 seconds) |
| 2023-07-15 17:45:04 +0200 | segfaultfizzbuzz | (~segfaultf@23-93-74-212.fiber.dynamic.sonic.net) |
| 2023-07-15 17:45:20 +0200 | <ncf> | yeah |
| 2023-07-15 17:48:01 +0200 | <glguy> | actually, without being clever that would potentially make you wait the full time even when all the events are completed |
| 2023-07-15 17:48:09 +0200 | alexbiehl | (~alexbiehl@2a02:8108:323f:ca14:adeb:5d31:3c95:b332) |
| 2023-07-15 17:53:00 +0200 | alexbiehl | (~alexbiehl@2a02:8108:323f:ca14:adeb:5d31:3c95:b332) (Ping timeout: 272 seconds) |
| 2023-07-15 17:57:34 +0200 | yin | zzz |
| 2023-07-15 17:58:37 +0200 | rustisafungus | (~segfaultf@23-93-74-212.fiber.dynamic.sonic.net) |
| 2023-07-15 18:00:08 +0200 | Square | (~Square@user/square) |
| 2023-07-15 18:00:10 +0200 | <c_wraith> | I was just looking through the async package. It's a lot of work to be exception-safe if you use the low-level interface. |
| 2023-07-15 18:00:22 +0200 | alexbiehl | (~alexbiehl@2a02:8108:323f:ca14:adeb:5d31:3c95:b332) |
| 2023-07-15 18:01:12 +0200 | gnalzo | (~gnalzo@2a01:e0a:498:fd50:fcc6:bb5d:489a:ce8c) (Quit: WeeChat 4.0.1) |
| 2023-07-15 18:02:18 +0200 | wootehfoot | (~wootehfoo@user/wootehfoot) |
| 2023-07-15 18:03:08 +0200 | rustisafungus | (~segfaultf@23-93-74-212.fiber.dynamic.sonic.net) (Ping timeout: 272 seconds) |
| 2023-07-15 18:06:12 +0200 | waleee | (~waleee@2001:9b0:21c:4000:5bf9:6515:c030:57b7) (Ping timeout: 245 seconds) |
| 2023-07-15 18:13:16 +0200 | machinedgod | (~machinedg@d198-53-218-113.abhsia.telus.net) (Ping timeout: 272 seconds) |
| 2023-07-15 18:16:22 +0200 | Pickchea | (~private@user/pickchea) (Quit: Leaving) |
| 2023-07-15 18:17:24 +0200 | alexbiehl | (~alexbiehl@2a02:8108:323f:ca14:adeb:5d31:3c95:b332) (Ping timeout: 246 seconds) |
| 2023-07-15 18:18:39 +0200 | danza | (~francesco@151.47.224.47) |
| 2023-07-15 18:21:44 +0200 | danza | (~francesco@151.47.224.47) (Read error: Connection reset by peer) |
| 2023-07-15 18:26:47 +0200 | alexbiehl | (~alexbiehl@2a02:8108:323f:ca14:adeb:5d31:3c95:b332) |
| 2023-07-15 18:29:39 +0200 | falafel | (~falafel@2603-7000-a700-8710-60e1-6355-aaa7-4770.res6.spectrum.com) |
| 2023-07-15 18:31:38 +0200 | alexbiehl | (~alexbiehl@2a02:8108:323f:ca14:adeb:5d31:3c95:b332) (Ping timeout: 272 seconds) |
| 2023-07-15 18:37:16 +0200 | shriekingnoise | (~shrieking@186.137.175.87) |
| 2023-07-15 18:37:41 +0200 | pickleju1ce | (~root@172.56.217.200) |
| 2023-07-15 18:41:25 +0200 | picklejuice | (~root@c-73-196-164-60.hsd1.nj.comcast.net) (Ping timeout: 240 seconds) |
| 2023-07-15 18:49:45 +0200 | mbuf | (~Shakthi@49.207.178.186) (Quit: Leaving) |
| 2023-07-15 18:49:55 +0200 | rustisafungus | (~segfaultf@23-93-74-212.fiber.dynamic.sonic.net) |
| 2023-07-15 18:53:48 +0200 | kimiamania6 | (~681cf57f@user/kimiamania) (Ping timeout: 272 seconds) |
| 2023-07-15 18:54:10 +0200 | rustisafungus | (~segfaultf@23-93-74-212.fiber.dynamic.sonic.net) (Ping timeout: 252 seconds) |
| 2023-07-15 18:54:37 +0200 | kimiamania6 | (~681cf57f@user/kimiamania) |
| 2023-07-15 18:59:11 +0200 | alexbiehl | (~alexbiehl@2a02:8108:323f:ca14:adeb:5d31:3c95:b332) |
| 2023-07-15 19:02:11 +0200 | fweht | (uid404746@id-404746.lymington.irccloud.com) (Quit: Connection closed for inactivity) |
| 2023-07-15 19:02:14 +0200 | sm[i] | (~sm@024-165-041-186.res.spectrum.com) |
| 2023-07-15 19:04:04 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2023-07-15 19:04:25 +0200 | ss4 | (~wootehfoo@user/wootehfoot) |
| 2023-07-15 19:05:12 +0200 | ss4 | (~wootehfoo@user/wootehfoot) (Client Quit) |
| 2023-07-15 19:05:20 +0200 | wootehfoot | (~wootehfoo@user/wootehfoot) (Ping timeout: 250 seconds) |
| 2023-07-15 19:17:25 +0200 | bratwurst | (~dfadsva@2604:3d09:207f:f650::c680) |
| 2023-07-15 19:17:32 +0200 | alexbiehl | (~alexbiehl@2a02:8108:323f:ca14:adeb:5d31:3c95:b332) (Ping timeout: 246 seconds) |
| 2023-07-15 19:20:00 +0200 | tzh | (~tzh@c-24-21-73-154.hsd1.or.comcast.net) |
| 2023-07-15 19:20:04 +0200 | nate2 | (~nate@c-98-45-169-16.hsd1.ca.comcast.net) |
| 2023-07-15 19:20:23 +0200 | glider_ | glider |
| 2023-07-15 19:21:06 +0200 | econo_ | (uid147250@id-147250.tinside.irccloud.com) |
| 2023-07-15 19:22:12 +0200 | Natch | (~natch@c-9e07225c.038-60-73746f7.bbcust.telenor.se) (Remote host closed the connection) |
| 2023-07-15 19:23:15 +0200 | rustisafungus | (~segfaultf@23-93-74-212.fiber.dynamic.sonic.net) |
| 2023-07-15 19:23:15 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2023-07-15 19:24:42 +0200 | dcoutts | (~duncan@cpc69402-oxfd27-2-0-cust903.4-3.cable.virginm.net) |
| 2023-07-15 19:24:50 +0200 | nate2 | (~nate@c-98-45-169-16.hsd1.ca.comcast.net) (Ping timeout: 250 seconds) |
| 2023-07-15 19:27:26 +0200 | rustisafungus | (~segfaultf@23-93-74-212.fiber.dynamic.sonic.net) (Ping timeout: 250 seconds) |
| 2023-07-15 19:28:36 +0200 | gurkenglas | (~gurkengla@dynamic-046-114-182-179.46.114.pool.telefonica.de) |
| 2023-07-15 19:29:16 +0200 | dibblego | (~dibblego@haskell/developer/dibblego) (Ping timeout: 272 seconds) |
| 2023-07-15 19:33:27 +0200 | dibblego | (~dibblego@116-255-1-157.ip4.superloop.au) |
| 2023-07-15 19:33:27 +0200 | dibblego | (~dibblego@116-255-1-157.ip4.superloop.au) (Changing host) |
| 2023-07-15 19:33:28 +0200 | dibblego | (~dibblego@haskell/developer/dibblego) |
| 2023-07-15 19:33:46 +0200 | alexbiehl | (~alexbiehl@2a02:8108:323f:ca14:adeb:5d31:3c95:b332) |
| 2023-07-15 19:34:20 +0200 | euandreh | (~Thunderbi@189.6.18.7) (Ping timeout: 272 seconds) |
| 2023-07-15 19:38:14 +0200 | alexbiehl | (~alexbiehl@2a02:8108:323f:ca14:adeb:5d31:3c95:b332) (Ping timeout: 260 seconds) |
| 2023-07-15 19:38:30 +0200 | euandreh | (~Thunderbi@189.6.18.7) |
| 2023-07-15 19:39:39 +0200 | Inst__ | (~Inst@2601:6c4:4081:2fc0:d87:979c:1a0c:2c8c) (Ping timeout: 246 seconds) |
| 2023-07-15 19:39:55 +0200 | jmdaemon | (~jmdaemon@user/jmdaemon) |
| 2023-07-15 19:43:34 +0200 | harveypwca | (~harveypwc@2601:246:c180:a570:3828:d8:e523:3f67) |
| 2023-07-15 19:44:00 +0200 | ripspin | (~chatzilla@1.145.169.115) |
| 2023-07-15 19:44:36 +0200 | Unicorn_Princess | (~Unicorn_P@user/Unicorn-Princess/x-3540542) |
| 2023-07-15 19:45:10 +0200 | alexbiehl | (~alexbiehl@2a02:8108:323f:ca14:adeb:5d31:3c95:b332) |
| 2023-07-15 19:46:42 +0200 | azr4e1 | (~azr4e1@2a00:23c7:9cbc:3401:45fb:9c68:12fe:262b) |
| 2023-07-15 19:47:17 +0200 | wroathe | (~wroathe@50.205.197.50) |
| 2023-07-15 19:47:18 +0200 | wroathe | (~wroathe@50.205.197.50) (Changing host) |
| 2023-07-15 19:47:18 +0200 | wroathe | (~wroathe@user/wroathe) |
| 2023-07-15 19:52:32 +0200 | Natch | (~natch@c-9e07225c.038-60-73746f7.bbcust.telenor.se) |
| 2023-07-15 19:53:24 +0200 | pyooque | (~puke@user/puke) |
| 2023-07-15 19:53:24 +0200 | puke | Guest208 |
| 2023-07-15 19:53:24 +0200 | Guest208 | (~puke@user/puke) (Killed (zirconium.libera.chat (Nickname regained by services))) |
| 2023-07-15 19:53:24 +0200 | pyooque | puke |
| 2023-07-15 19:53:49 +0200 | son0p | (~ff@181.136.122.143) |
| 2023-07-15 19:54:16 +0200 | wootehfoot | (~wootehfoo@user/wootehfoot) |
| 2023-07-15 20:00:39 +0200 | anderson | (~anderson@user/anderson) (Quit: bye) |
| 2023-07-15 20:00:39 +0200 | glider | (~glider@user/glider) (Quit: ZNC - https://znc.in) |
| 2023-07-15 20:03:26 +0200 | alexbiehl | (~alexbiehl@2a02:8108:323f:ca14:adeb:5d31:3c95:b332) (Ping timeout: 260 seconds) |
| 2023-07-15 20:03:44 +0200 | mechap | (~mechap@user/mechap) (Ping timeout: 246 seconds) |
| 2023-07-15 20:04:31 +0200 | sm[i] | (~sm@024-165-041-186.res.spectrum.com) (Quit: sm[i]) |
| 2023-07-15 20:04:45 +0200 | mechap | (~mechap@user/mechap) |
| 2023-07-15 20:08:09 +0200 | titibandit | (~titibandi@user/titibandit) |
| 2023-07-15 20:09:10 +0200 | dcoutts | (~duncan@cpc69402-oxfd27-2-0-cust903.4-3.cable.virginm.net) (Ping timeout: 272 seconds) |
| 2023-07-15 20:13:42 +0200 | azr4e1 | (~azr4e1@2a00:23c7:9cbc:3401:45fb:9c68:12fe:262b) (Ping timeout: 260 seconds) |
| 2023-07-15 20:14:23 +0200 | anderson | (~anderson@user/anderson) |
| 2023-07-15 20:15:03 +0200 | ss4 | (~wootehfoo@user/wootehfoot) |
| 2023-07-15 20:16:16 +0200 | dhil | (~dhil@78.45.150.83.ewm.ftth.as8758.net) (Ping timeout: 245 seconds) |
| 2023-07-15 20:16:55 +0200 | wootehfoot | (~wootehfoo@user/wootehfoot) (Ping timeout: 240 seconds) |
| 2023-07-15 20:20:54 +0200 | alexbiehl | (~alexbiehl@2a02:8108:323f:ca14:adeb:5d31:3c95:b332) |
| 2023-07-15 20:21:46 +0200 | gnalzo | (~gnalzo@2a01:e0a:498:fd50:fcc6:bb5d:489a:ce8c) |
| 2023-07-15 20:23:30 +0200 | glider | (~glider@user/glider) |
| 2023-07-15 20:24:48 +0200 | razetime | (~quassel@117.193.0.33) (Remote host closed the connection) |
| 2023-07-15 20:25:22 +0200 | alexbiehl | (~alexbiehl@2a02:8108:323f:ca14:adeb:5d31:3c95:b332) (Ping timeout: 245 seconds) |
| 2023-07-15 20:25:35 +0200 | ripspin | (~chatzilla@1.145.169.115) (Remote host closed the connection) |
| 2023-07-15 20:27:09 +0200 | sm[i] | (~sm@024-165-041-186.res.spectrum.com) |
| 2023-07-15 20:32:16 +0200 | trev | (~trev@user/trev) (Quit: trev) |
| 2023-07-15 20:36:50 +0200 | ss4 | (~wootehfoo@user/wootehfoot) (Ping timeout: 252 seconds) |
| 2023-07-15 20:39:18 +0200 | alexbiehl | (~alexbiehl@77.20.253.164) |
| 2023-07-15 20:39:46 +0200 | [itchyjunk] | (~itchyjunk@user/itchyjunk/x-7353470) |
| 2023-07-15 20:40:50 +0200 | falafel | (~falafel@2603-7000-a700-8710-60e1-6355-aaa7-4770.res6.spectrum.com) (Ping timeout: 272 seconds) |
| 2023-07-15 20:45:19 +0200 | ss4 | (~wootehfoo@user/wootehfoot) |
| 2023-07-15 20:46:39 +0200 | falafel | (~falafel@2603-7000-a700-8710-210a-6c97-c559-5652.res6.spectrum.com) |
| 2023-07-15 20:49:47 +0200 | dibblego | (~dibblego@haskell/developer/dibblego) (Ping timeout: 264 seconds) |
| 2023-07-15 20:58:45 +0200 | alexbiehl | (~alexbiehl@77.20.253.164) (Ping timeout: 246 seconds) |
| 2023-07-15 20:59:30 +0200 | azr4e1 | (~azr4e1@host31-54-162-131.range31-54.btcentralplus.com) |
| 2023-07-15 21:03:53 +0200 | Ashkan | (~Ashkan@a119011.upc-a.chello.nl) |
| 2023-07-15 21:04:47 +0200 | Sgeo | (~Sgeo@user/sgeo) |
| 2023-07-15 21:07:17 +0200 | <Ashkan> | Hi people |
| 2023-07-15 21:07:17 +0200 | <Ashkan> | Looking for a c-like array in Haskell but got really confused by all the different Array types. If I'm understanding things correctly then closest is `UArray` but it supports only a handful of basic types. I'm looking for something that can hold a user defined type (a `data ... = ... | ... | ...` kind of type). |
| 2023-07-15 21:08:18 +0200 | <Clint> | what do you mean by c-like in this case? |
| 2023-07-15 21:08:43 +0200 | <Ashkan> | As I was typing this it occurred to me that perhaps I think Array because I'm coming from an imperative background. Perhaps better if I describe what I want and maybe something better comes to mind ... |
| 2023-07-15 21:09:23 +0200 | <jade[m]> | you may want Array Int |
| 2023-07-15 21:09:28 +0200 | <Ashkan> | Hi Clint :) I'm keeping the state of a grid-based game. Its a square matrix with all the cells having some value all the time |
| 2023-07-15 21:09:28 +0200 | <geekosaur> | you've also missed that Vector is more often used than Array these days, and supports user defined types including unboxed types via Storable |
| 2023-07-15 21:09:33 +0200 | <jade[m]> | it's an array indexed by integers |
| 2023-07-15 21:09:49 +0200 | <jade[m]> | Ashkan: ah then you might want `Array (Int, Int)` |
| 2023-07-15 21:09:55 +0200 | dibblego | (~dibblego@116-255-1-157.ip4.superloop.au) |
| 2023-07-15 21:09:55 +0200 | dibblego | (~dibblego@116-255-1-157.ip4.superloop.au) (Changing host) |
| 2023-07-15 21:09:56 +0200 | dibblego | (~dibblego@haskell/developer/dibblego) |
| 2023-07-15 21:10:02 +0200 | <Ashkan> | I need a way to draw it per frame so I need to be able to pass through all the elements (cover the whole grid) in order from 0 to last element pretty fast |
| 2023-07-15 21:10:43 +0200 | <geekosaur> | Array's big advantage is that anything you can define Ix for can be an index, whereas Vector only allows Ints |
| 2023-07-15 21:10:53 +0200 | <jade[m]> | another option for this kind of thing is `(Int, Int) -> a` |
| 2023-07-15 21:11:01 +0200 | <c_wraith> | I'm not sure a Storable Vector is going to be faster than a boxed vector. Storable sort of makes every field access indirect. |
| 2023-07-15 21:11:04 +0200 | <Ashkan> | And I need to be able to update it quite fast as well as in `update arr x y newVal` and also when mouse moves over a certain cell (an `x y`) I need the value in there , fast. |
| 2023-07-15 21:11:13 +0200 | <geekosaur> | true |
| 2023-07-15 21:12:20 +0200 | <c_wraith> | If you really need maximal speed, I'd be looking at an unboxed vector for each field, like in Struct of Arrays representation. |
| 2023-07-15 21:12:30 +0200 | <jade[m]> | jade[m]: this has the advantage that you can easily "mask" it, but a lot of changes would have stack space |
| 2023-07-15 21:12:53 +0200 | <jade[m]> | s/stack space/stack space buildup |
| 2023-07-15 21:13:58 +0200 | <Ashkan> | My understanding is that I need something that is : 1) strict and 2) keep values adjacent to each other in memory with a very basic relationship between their index in the "array" and their memory address --> exactly C-array. What is the closest thing in Haskell ? |
| 2023-07-15 21:14:13 +0200 | ss4 | (~wootehfoo@user/wootehfoot) (Quit: Leaving) |
| 2023-07-15 21:14:16 +0200 | <c_wraith> | an unboxed array/vector |
| 2023-07-15 21:14:31 +0200 | wootehfoot | (~wootehfoo@user/wootehfoot) |
| 2023-07-15 21:15:34 +0200 | <Ashkan> | Okay, though myself as well ... but ... does "unboxed" automatically means I'm then limited to `Int16` , `int32` etc ? not sure what's their proper name. Primitive types ? |
| 2023-07-15 21:15:52 +0200 | <c_wraith> | Well, that's where Struct of Arrays representation comes in |
| 2023-07-15 21:16:01 +0200 | <c_wraith> | It's a very common optimization in C |
| 2023-07-15 21:16:31 +0200 | <c_wraith> | (for this specific use case) |
| 2023-07-15 21:17:00 +0200 | <Ashkan> | (I really don't care much about indexing it via fancy custom types and such, performance characteristics are the key here). |
| 2023-07-15 21:17:21 +0200 | <c_wraith> | Ashkan: https://en.wikipedia.org/wiki/AoS_and_SoA |
| 2023-07-15 21:17:48 +0200 | azr4e1 | (~azr4e1@host31-54-162-131.range31-54.btcentralplus.com) (Quit: azr4e1) |
| 2023-07-15 21:17:56 +0200 | sm[i] | (~sm@024-165-041-186.res.spectrum.com) (Quit: sm[i]) |
| 2023-07-15 21:18:15 +0200 | gurkenglas | (~gurkengla@dynamic-046-114-182-179.46.114.pool.telefonica.de) (Read error: Connection reset by peer) |
| 2023-07-15 21:18:26 +0200 | michalz | (~michalz@185.246.207.218) |
| 2023-07-15 21:18:26 +0200 | alexbiehl | (~alexbiehl@2a02:8108:323f:ca14:adeb:5d31:3c95:b332) |
| 2023-07-15 21:19:18 +0200 | <c_wraith> | If you really want, you can create your own Unboxed Vector data instances - it's a data family after all. |
| 2023-07-15 21:20:12 +0200 | <monochrom> | As an example, as the doc points out, unboxed vector of complex numbers simply means two unboxed vectors of real numbers. |
| 2023-07-15 21:20:13 +0200 | dibblego | (~dibblego@haskell/developer/dibblego) (Quit: λ) |
| 2023-07-15 21:22:48 +0200 | <Ashkan> | Okay, let me ask this way: imagine you are model the Mine Sweeper game with a N x N board. Every single cell has a known state and you need to draw the whole field 30 times per second, be able to quickly tell what is in cell (C, R) and quickly update the cell in (C,R) with a new value. |
| 2023-07-15 21:22:48 +0200 | <Ashkan> | Each cell is either: uncovered, has a number (from 1 to 8 ) or flagged by the player as "mine". |
| 2023-07-15 21:22:49 +0200 | <Ashkan> | How do you model this in Haskell ? |
| 2023-07-15 21:23:14 +0200 | alexbiehl | (~alexbiehl@2a02:8108:323f:ca14:adeb:5d31:3c95:b332) (Ping timeout: 260 seconds) |
| 2023-07-15 21:23:39 +0200 | <c_wraith> | 30 times per second for a minesweeper board? |
| 2023-07-15 21:23:41 +0200 | misterfish | (~misterfis@84-53-85-146.bbserv.nl) |
| 2023-07-15 21:23:42 +0200 | <c_wraith> | I thought you said fast |
| 2023-07-15 21:24:10 +0200 | <c_wraith> | Immutable arrays of boxed values would be fast enough for a minesweeper game at 30Hz |
| 2023-07-15 21:24:17 +0200 | <monochrom> | Perhaps it's a 1600x1000 board :) |
| 2023-07-15 21:25:55 +0200 | <Ashkan> | Maybe I don't understand how boxing works. My understanding is then every cell is re-evaluated every single time it is accessed. No ? |
| 2023-07-15 21:26:16 +0200 | <[exa]> | Ashkan: no |
| 2023-07-15 21:26:29 +0200 | <[exa]> | Ashkan: do you know what are pointers? (in C, etc.) |
| 2023-07-15 21:26:30 +0200 | <Ashkan> | As if it was `IO Cell` instead of just `Cell` |
| 2023-07-15 21:26:37 +0200 | <jade[m]> | no |
| 2023-07-15 21:26:46 +0200 | <monochrom> | But it is not IO Cell. |
| 2023-07-15 21:26:59 +0200 | <Ashkan> | I know pointers, yes |
| 2023-07-15 21:28:06 +0200 | <[exa]> | Ashkan: very briefly boxing is just putting something in a structure that may act slighly polymorphic (it may contain something unevaluated or it may contain it already evaluated), and as the main performance "problem" this typically needs to be behind a pointer because the sizes of the things differ |
| 2023-07-15 21:28:20 +0200 | <[exa]> | Ashkan: despite of that the "unevaluated" thing gets only evaluated once |
| 2023-07-15 21:29:03 +0200 | <Ashkan> | Alright, so unless it "changes", once evaluated then there is no cost later |
| 2023-07-15 21:29:31 +0200 | <[exa]> | once evaluated it can't be changed, the greatest danger there is that you basically generate the unevaluated cell again |
| 2023-07-15 21:29:36 +0200 | dibblego | (~dibblego@116-255-1-157.ip4.superloop.au) |
| 2023-07-15 21:29:36 +0200 | dibblego | (~dibblego@116-255-1-157.ip4.superloop.au) (Changing host) |
| 2023-07-15 21:29:36 +0200 | dibblego | (~dibblego@haskell/developer/dibblego) |
| 2023-07-15 21:29:46 +0200 | <Ashkan> | But still holds these "pointers" to either the code or the computed value instead of storing the values directly and only. Correct ? |
| 2023-07-15 21:30:02 +0200 | TheCoffeMaker | (~TheCoffeM@user/thecoffemaker) (Ping timeout: 246 seconds) |
| 2023-07-15 21:30:32 +0200 | <[exa]> | yeah unless you go for Data.Vector or explicitly say that stuff needs to be unboxed, the default is to be very pointy |
| 2023-07-15 21:30:50 +0200 | <Ashkan> | The value can't be changed but the cell in the array can be updated. Putting another "pointer" in there. |
| 2023-07-15 21:31:04 +0200 | <[exa]> | no, all data is immutable |
| 2023-07-15 21:31:09 +0200 | <c_wraith> | but a minesweeper board is just not big enough for a couple levels of indirection to matter |
| 2023-07-15 21:31:28 +0200 | <[exa]> | Ashkan: check out Data.Vector.Mutable which allows serializing the updates |
| 2023-07-15 21:32:13 +0200 | <c_wraith> | I thought you meant like mesh vertices where you might have 50k in the view frustrum at once. |
| 2023-07-15 21:32:20 +0200 | <[exa]> | Ashkan: (updates in "pure" code do not make sense for several interesting reasons, and the inability to guess the "order" of updates is one of the less painful ones) |
| 2023-07-15 21:33:22 +0200 | <Ashkan> | I understand it is immutable but the update-y functions returning the modified version of the data should somehow make the update take effect. Best they can do is to make a (cheap) copy or whatever fucntional-data-structure black magic + the new value. Maybe I'm overthinking this ! |
| 2023-07-15 21:33:24 +0200 | ubert | (~Thunderbi@91.141.79.172.wireless.dyn.drei.com) (Quit: ubert) |
| 2023-07-15 21:33:24 +0200 | ubert1 | ubert |
| 2023-07-15 21:33:51 +0200 | <[exa]> | Ashkan: anyway to be honest, haskell pointy structs are still much less ugly than the typical stuff that you can find in python and javas; and there are funny tricks to maintain cache efficiency... I wouldn't be worried about performance until you go literally to hundreds of thousands of fields (or make it of lists) |
| 2023-07-15 21:34:10 +0200 | <[exa]> | Ashkan: yeah the update in Data.Vector does copy-on-write |
| 2023-07-15 21:34:34 +0200 | <[exa]> | Ashkan: which is pretty expensive if you do the updates manually by field but there are nice functions that can very easily pool multiple updates |
| 2023-07-15 21:34:46 +0200 | <[exa]> | Ashkan: for which reason the Data.Vector.Mutable is usually not required |
| 2023-07-15 21:35:02 +0200 | <monochrom> | I wonder if "minesweeper" is just a proxy example, and the real one is like "lattice QCD". |
| 2023-07-15 21:35:35 +0200 | <[exa]> | (Ashkan: interesting outcome of laziness: the "mass update" functions take lists of updates, but the lists of updates are typically never allocated because they act as "generators" and the thing gets pretty efficient) |
| 2023-07-15 21:35:39 +0200 | <monochrom> | "lattice QCD for modeling the next generation of hydrogen fusion" :) |
| 2023-07-15 21:35:45 +0200 | <Ashkan> | The actual project is a mine sweeper. I'm not sure you say boxing is no problem for this. Not that I disagree with you but rather I have zero clue/heuristics to make that observation. For all I know from the docs this boxing business could take anywhere from 0 to few hundred milli seconds |
| 2023-07-15 21:36:18 +0200 | <[exa]> | Ashkan: if you know C++, the shared_ptr typically has a higher overhead than the box :] |
| 2023-07-15 21:37:44 +0200 | <[exa]> | (even the unique_ptr is sometimes more expensive, because the corresponding malloc/free is often way slower than the haskell allocator) |
| 2023-07-15 21:37:48 +0200 | alexbiehl | (~alexbiehl@2a02:8108:323f:ca14:adeb:5d31:3c95:b332) |
| 2023-07-15 21:37:50 +0200 | dibblego | (~dibblego@haskell/developer/dibblego) (Ping timeout: 272 seconds) |
| 2023-07-15 21:38:09 +0200 | <Ashkan> | @monochrom hehe I wish. Honestly just a simple mine-sweeper |
| 2023-07-15 21:38:09 +0200 | <lambdabot> | Unknown command, try @list |
| 2023-07-15 21:38:27 +0200 | <[exa]> | Ashkan: what do you plan to use for the graphics drawing btw? |
| 2023-07-15 21:38:37 +0200 | Inst | (~Inst@2601:6c4:4081:2fc0:2cd7:faf6:2df3:acfa) |
| 2023-07-15 21:39:10 +0200 | <Ashkan> | Glad you asked ! tried every single !@#$ thing out there on Haskell. Turns out for my rather humble purposes of teaching myself Haskell, `gloss` is the best |
| 2023-07-15 21:39:40 +0200 | <[exa]> | ok good I just kinda wanted to recommend gloss in case you were not planning to do so. :D |
| 2023-07-15 21:39:41 +0200 | <jade[m]> | gloss is nice for small games and applications |
| 2023-07-15 21:39:57 +0200 | <jade[m]> | I tried some direct opengl stuff but it's really stupid most of the time |
| 2023-07-15 21:39:58 +0200 | <Ashkan> | I'm trying to teach myself to think functionally. Games are a very good combination of a few things I wish to learn to model functionally. |
| 2023-07-15 21:40:04 +0200 | <[exa]> | if you like terminals, try brick, it's similarly cool |
| 2023-07-15 21:40:43 +0200 | <[exa]> | Ashkan: feel free to paste the code here once it works, we love to nitpic^H^H^H^H^H^H improve people's code |
| 2023-07-15 21:40:52 +0200 | <Ashkan> | Atm I'm having the most difficulty convincing myself that an immutable model can actually keep up with a game ! |
| 2023-07-15 21:41:04 +0200 | <[exa]> | totally |
| 2023-07-15 21:41:13 +0200 | <[exa]> | also you're not going to update it every frame, right? |
| 2023-07-15 21:41:49 +0200 | <jade[m]> | Ashkan: it allows for so much magic in the background that you rarely realize it on the surface |
| 2023-07-15 21:41:56 +0200 | <Ashkan> | I can't see how that can be :-/ too much imperative thinking maybe. Like the mine sweeper for example. Can't understand how a boxed, immutable data structure can hold the game state |
| 2023-07-15 21:42:37 +0200 | <[exa]> | Ashkan: simply don't mutate it, just replace it with a new one |
| 2023-07-15 21:42:38 +0200 | <Ashkan> | maybe for a simple thing like minesweeper it can but you get the point. Imagine a more complicated game with millions of state elements |
| 2023-07-15 21:42:56 +0200 | <jade[m]> | Ashkan: from my own experience games are some of the hardest things to model functionally - I had a lot easier time learning FP thinking from mathy applications/things that did lots of computation but had a small Ui |
| 2023-07-15 21:43:10 +0200 | dcoutts | (~duncan@cpc69402-oxfd27-2-0-cust903.4-3.cable.virginm.net) |
| 2023-07-15 21:43:27 +0200 | <int-e> | Ashkan: Yes, at some point you have to worry about the cost of immutability. But not for Minesweeper. |
| 2023-07-15 21:43:31 +0200 | dibblego | (~dibblego@116-255-1-157.ip4.superloop.au) |
| 2023-07-15 21:43:32 +0200 | dibblego | (~dibblego@116-255-1-157.ip4.superloop.au) (Changing host) |
| 2023-07-15 21:43:32 +0200 | dibblego | (~dibblego@haskell/developer/dibblego) |
| 2023-07-15 21:44:32 +0200 | <Ashkan> | jade[m] Oh I did that trick on my mind already. Happy and all shiny until someone challenged me to a "real-world" problem then suddenly FP started to suck big time :D but I'm sure it's rather my incompetence. |
| 2023-07-15 21:44:44 +0200 | <[exa]> | Ashkan: btw I was giving this to students for starters, https://github.com/exaexa/hs19/tree/master/u1/ , might help. |
| 2023-07-15 21:45:17 +0200 | <geekosaur> | did anyone mention asking questions like this in #haskell-game? |
| 2023-07-15 21:45:18 +0200 | azimut_ | (~azimut@gateway/tor-sasl/azimut) (Ping timeout: 240 seconds) |
| 2023-07-15 21:45:48 +0200 | <jade[m]> | Ashkan: Oh yeah I had that period too, but it's moreso that real world applications (in all languages) require a lot more thought and planning than small toy examples |
| 2023-07-15 21:45:52 +0200 | <int-e> | Worrying about mutability seems generic enough. |
| 2023-07-15 21:46:16 +0200 | <jade[m]> | haskell is just as capable as any other languages when it comes to big real world projects (look at GHC for example) |
| 2023-07-15 21:46:19 +0200 | <Ashkan> | mutability + strictness |
| 2023-07-15 21:46:56 +0200 | <Ashkan> | I am indeed very impressed by GHC |
| 2023-07-15 21:47:24 +0200 | <Ashkan> | But to be fair, compilers are like *the* use case for FP |
| 2023-07-15 21:47:39 +0200 | <jade[m]> | oh yeah |
| 2023-07-15 21:47:46 +0200 | <jade[m]> | but haskell is truly general purpose |
| 2023-07-15 21:47:58 +0200 | <jade[m]> | it just takes a while to get good at it |
| 2023-07-15 21:48:04 +0200 | <jade[m]> | (im a far far way from that] |
| 2023-07-15 21:48:10 +0200 | <jade[m]> | s/]/) |
| 2023-07-15 21:48:11 +0200 | <Ashkan> | I would say a game, a word processor or an email server for example are where you can show if you got what it takes for industrial strength. You get my meaning. |
| 2023-07-15 21:48:17 +0200 | <claro> | what is a while? |
| 2023-07-15 21:48:25 +0200 | <[exa]> | Ashkan: re mutability in games I was usually doing it this way: I store everything in immutable vectors. Then if there's an algorithm that needs to do tiny updates on the vector multiple times (which would be inefficient), I thaw it to mutable vector, do it within some small contained "imperative" environment (ST monad etc), and then freeze it back to immutable to keep the program pure. Refs: |
| 2023-07-15 21:48:31 +0200 | <[exa]> | https://hackage.haskell.org/package/vector-0.13.0.0/docs/Data-Vector.html#v:freeze |
| 2023-07-15 21:48:34 +0200 | <jade[m]> | claro: many years |
| 2023-07-15 21:48:34 +0200 | Pickchea | (~private@user/pickchea) |
| 2023-07-15 21:48:40 +0200 | gurkenglas | (~gurkengla@dynamic-046-114-182-179.46.114.pool.telefonica.de) |
| 2023-07-15 21:48:44 +0200 | wootehfoot | (~wootehfoo@user/wootehfoot) (Read error: Connection reset by peer) |
| 2023-07-15 21:48:51 +0200 | <claro> | skill issue |
| 2023-07-15 21:49:28 +0200 | <jade[m]> | damn |
| 2023-07-15 21:49:51 +0200 | <Hecate> | you can replace the many years by day-to-day practice with other people |
| 2023-07-15 21:50:15 +0200 | <[exa]> | +1 ^ |
| 2023-07-15 21:50:34 +0200 | <int-e> | . o O ( as long as you keep it up for many years ) |
| 2023-07-15 21:50:36 +0200 | <[exa]> | skipping unsolvable issues by asking on #haskell: top. |
| 2023-07-15 21:50:36 +0200 | <Ashkan> | All right guys thank you all for your time and effort. I got a few links to read and I have a feeling I'm missing some subtle points about how functional data structures work. I'll be back with hopefully better questions. |
| 2023-07-15 21:50:58 +0200 | <[exa]> | Ashkan: btw I recommend thinking about how gloss draws the "scene structure" |
| 2023-07-15 21:51:16 +0200 | <[exa]> | Ashkan: spoiler: it typically never really gets allocated |
| 2023-07-15 21:51:17 +0200 | <monochrom> | The opposing view is that if C is great for email server then let email servers be written in C. "Industry" is diverse and there are other sectors for Haskell. |
| 2023-07-15 21:51:37 +0200 | bratwurst | (~dfadsva@2604:3d09:207f:f650::c680) (Remote host closed the connection) |
| 2023-07-15 21:51:43 +0200 | <davean> | Has C ever been good for email servers? It seems all the email servers in C are disasters |
| 2023-07-15 21:51:55 +0200 | bratwurst | (~dfadsva@2604:3d09:207f:f650::c680) |
| 2023-07-15 21:52:00 +0200 | <int-e> | ...better than Fortran or Pascal... |
| 2023-07-15 21:52:05 +0200 | <monochrom> | Yeah it's a hypothetical. While we're hypothetical. |
| 2023-07-15 21:52:11 +0200 | <[exa]> | yeah like, most email servers are in C somehow :D |
| 2023-07-15 21:52:33 +0200 | <int-e> | I mean, most email servers are old? |
| 2023-07-15 21:52:45 +0200 | <[exa]> | yeah that likely contributes |
| 2023-07-15 21:52:55 +0200 | <monochrom> | Most email servers still have vulnerabilities because of C. <duck> |
| 2023-07-15 21:53:04 +0200 | <[exa]> | "most OSS mail servers", that would be it. |
| 2023-07-15 21:53:06 +0200 | <davean> | monochrom: I mean thats half of what makes most of them terrible |
| 2023-07-15 21:53:25 +0200 | <davean> | Issues with config and handling config complexity without issues is the other half |
| 2023-07-15 21:53:25 +0200 | <[exa]> | but c'mon it could have been java |
| 2023-07-15 21:53:25 +0200 | <int-e> | . o O ( and Exchange ) |
| 2023-07-15 21:53:36 +0200 | <davean> | [exa]: what about Java? That would probably be fine? |
| 2023-07-15 21:53:43 +0200 | <davean> | Probably better than C |
| 2023-07-15 21:54:36 +0200 | <davean> | I feel like Haskell could maybe win on the config side, but really thats a programmer issue and C just makes that programming hard. |
| 2023-07-15 21:54:38 +0200 | <[exa]> | well I had the opportunity to administer one back in the old days like 2010 |
| 2023-07-15 21:54:41 +0200 | <davean> | The security side litterly anything else wins |
| 2023-07-15 21:54:45 +0200 | <monochrom> | Whenever my students make array-index-out-of-bound mistakes, they probably like C more than Java. |
| 2023-07-15 21:54:46 +0200 | misterfish | (~misterfis@84-53-85-146.bbserv.nl) (Ping timeout: 250 seconds) |
| 2023-07-15 21:54:53 +0200 | alexbiehl | (~alexbiehl@2a02:8108:323f:ca14:adeb:5d31:3c95:b332) (Ping timeout: 246 seconds) |
| 2023-07-15 21:54:56 +0200 | rainbyte | (~rainbyte@181.31.239.226) (Ping timeout: 272 seconds) |
| 2023-07-15 21:54:59 +0200 | <davean> | monochrom: oh? |
| 2023-07-15 21:55:01 +0200 | <[exa]> | lol. |
| 2023-07-15 21:55:24 +0200 | <monochrom> | Students always want to pretend that their programs run fine, right? |
| 2023-07-15 21:55:30 +0200 | <davean> | No? |
| 2023-07-15 21:55:35 +0200 | <monochrom> | yes? |
| 2023-07-15 21:55:39 +0200 | <davean> | Not my experience |
| 2023-07-15 21:55:45 +0200 | <probie> | C: maybe a segfault, maybe wrong data. Java: A big scary stack trace |
| 2023-07-15 21:56:24 +0200 | <davean> | monochrom: I have seen more want to knwo it will run right for grading. |
| 2023-07-15 21:56:48 +0200 | <[exa]> | java: OOM, grafecul shutdown, OOM again. |
| 2023-07-15 21:57:10 +0200 | machinedgod | (~machinedg@d198-53-218-113.abhsia.telus.net) |
| 2023-07-15 21:57:27 +0200 | dibblego | (~dibblego@haskell/developer/dibblego) (Ping timeout: 245 seconds) |
| 2023-07-15 21:57:43 +0200 | <mauke> | ArrayStoreException |
| 2023-07-15 21:57:53 +0200 | <monochrom> | You have more competent students. |
| 2023-07-15 21:58:16 +0200 | <probie> | davean: that's why you give them some example test cases, so they can satisfy themselves it works on those (and only those) and then fails for every real test case |
| 2023-07-15 21:58:20 +0200 | <monochrom> | My students operate more at the level of "my code works but it doesn't pass your test cases". |
| 2023-07-15 21:58:33 +0200 | <davean> | haha, interesting! |
| 2023-07-15 21:59:46 +0200 | alexbiehl | (~alexbiehl@2a02:8108:323f:ca14:adeb:5d31:3c95:b332) |
| 2023-07-15 22:01:00 +0200 | <davean> | monochrom: my brain hurts now. Thanks. |
| 2023-07-15 22:01:02 +0200 | misterfish | (~misterfis@84-53-85-146.bbserv.nl) |
| 2023-07-15 22:05:14 +0200 | alexbiehl | (~alexbiehl@2a02:8108:323f:ca14:adeb:5d31:3c95:b332) (Ping timeout: 260 seconds) |
| 2023-07-15 22:07:11 +0200 | alexbiehl | (~alexbiehl@2a02:8108:323f:ca14:adeb:5d31:3c95:b332) |
| 2023-07-15 22:10:46 +0200 | Pickchea | (~private@user/pickchea) (Quit: Leaving) |
| 2023-07-15 22:11:12 +0200 | alexbiehl | (~alexbiehl@2a02:8108:323f:ca14:adeb:5d31:3c95:b332) (Ping timeout: 240 seconds) |
| 2023-07-15 22:18:35 +0200 | alexbiehl | (~alexbiehl@2a02:8108:323f:ca14:adeb:5d31:3c95:b332) |
| 2023-07-15 22:21:37 +0200 | wroathe | (~wroathe@user/wroathe) (Quit: Lost terminal) |
| 2023-07-15 22:22:52 +0200 | alexbiehl | (~alexbiehl@2a02:8108:323f:ca14:adeb:5d31:3c95:b332) (Ping timeout: 240 seconds) |
| 2023-07-15 22:25:00 +0200 | alexbiehl | (~alexbiehl@2a02:8108:323f:ca14:adeb:5d31:3c95:b332) |
| 2023-07-15 22:26:35 +0200 | sm[i] | (~sm@024-165-041-186.res.spectrum.com) |
| 2023-07-15 22:27:51 +0200 | wroathe | (~wroathe@50.205.197.50) |
| 2023-07-15 22:27:51 +0200 | wroathe | (~wroathe@50.205.197.50) (Changing host) |
| 2023-07-15 22:27:51 +0200 | wroathe | (~wroathe@user/wroathe) |
| 2023-07-15 22:29:42 +0200 | dibblego | (~dibblego@116-255-1-157.ip4.superloop.au) |
| 2023-07-15 22:29:42 +0200 | dibblego | (~dibblego@116-255-1-157.ip4.superloop.au) (Changing host) |
| 2023-07-15 22:29:42 +0200 | dibblego | (~dibblego@haskell/developer/dibblego) |
| 2023-07-15 22:31:21 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2023-07-15 22:32:10 +0200 | zer0bitz_ | (~zer0bitz@user/zer0bitz) |
| 2023-07-15 22:34:50 +0200 | TheCoffeMaker | (~TheCoffeM@user/thecoffemaker) |
| 2023-07-15 22:35:59 +0200 | zer0bitz | (~zer0bitz@user/zer0bitz) (Ping timeout: 264 seconds) |
| 2023-07-15 22:39:07 +0200 | dibblego | (~dibblego@haskell/developer/dibblego) (Quit: λ) |
| 2023-07-15 22:43:20 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2023-07-15 22:43:42 +0200 | alexbiehl | (~alexbiehl@2a02:8108:323f:ca14:adeb:5d31:3c95:b332) (Ping timeout: 272 seconds) |
| 2023-07-15 22:45:22 +0200 | wroathe | (~wroathe@user/wroathe) (Ping timeout: 245 seconds) |
| 2023-07-15 22:45:59 +0200 | wootehfoot | (~wootehfoo@user/wootehfoot) |
| 2023-07-15 22:49:56 +0200 | dibblego | (~dibblego@116.255.1.157) |
| 2023-07-15 22:49:56 +0200 | dibblego | (~dibblego@116.255.1.157) (Changing host) |
| 2023-07-15 22:49:56 +0200 | dibblego | (~dibblego@haskell/developer/dibblego) |
| 2023-07-15 22:51:26 +0200 | nick3 | (~nick@ip98-170-224-49.pn.at.cox.net) |
| 2023-07-15 22:54:23 +0200 | Lycurgus | (~juan@user/Lycurgus) |
| 2023-07-15 22:59:41 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2023-07-15 23:00:48 +0200 | misterfish | (~misterfis@84-53-85-146.bbserv.nl) (Ping timeout: 272 seconds) |
| 2023-07-15 23:00:51 +0200 | dibblego | (~dibblego@haskell/developer/dibblego) (Ping timeout: 245 seconds) |
| 2023-07-15 23:01:59 +0200 | wroathe | (~wroathe@207-153-38-140.fttp.usinternet.com) |
| 2023-07-15 23:01:59 +0200 | wroathe | (~wroathe@207-153-38-140.fttp.usinternet.com) (Changing host) |
| 2023-07-15 23:01:59 +0200 | wroathe | (~wroathe@user/wroathe) |
| 2023-07-15 23:03:45 +0200 | harveypwca | (~harveypwc@2601:246:c180:a570:3828:d8:e523:3f67) (Quit: Leaving) |
| 2023-07-15 23:05:02 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2023-07-15 23:07:31 +0200 | nick3 | (~nick@ip98-170-224-49.pn.at.cox.net) (Ping timeout: 245 seconds) |
| 2023-07-15 23:13:28 +0200 | alexbiehl | (~alexbiehl@2a02:8108:323f:ca14:adeb:5d31:3c95:b332) |
| 2023-07-15 23:14:34 +0200 | dibblego | (~dibblego@116.255.1.157) |
| 2023-07-15 23:14:34 +0200 | dibblego | (~dibblego@116.255.1.157) (Changing host) |
| 2023-07-15 23:14:34 +0200 | dibblego | (~dibblego@haskell/developer/dibblego) |
| 2023-07-15 23:14:36 +0200 | Ashkan | (~Ashkan@a119011.upc-a.chello.nl) (Quit: Client closed) |
| 2023-07-15 23:17:38 +0200 | alexbiehl | (~alexbiehl@2a02:8108:323f:ca14:adeb:5d31:3c95:b332) (Ping timeout: 246 seconds) |
| 2023-07-15 23:18:39 +0200 | falafel | (~falafel@2603-7000-a700-8710-210a-6c97-c559-5652.res6.spectrum.com) (Remote host closed the connection) |
| 2023-07-15 23:21:34 +0200 | nate2 | (~nate@c-98-45-169-16.hsd1.ca.comcast.net) |
| 2023-07-15 23:22:33 +0200 | _ht | (~Thunderbi@28-52-174-82.ftth.glasoperator.nl) (Quit: _ht) |
| 2023-07-15 23:25:22 +0200 | falafel | (~falafel@2603-7000-a700-8710-cd1b-efe5-440f-7e43.res6.spectrum.com) |
| 2023-07-15 23:25:42 +0200 | adanwan | (~adanwan@gateway/tor-sasl/adanwan) (Remote host closed the connection) |
| 2023-07-15 23:25:57 +0200 | adanwan | (~adanwan@gateway/tor-sasl/adanwan) |
| 2023-07-15 23:26:23 +0200 | nate2 | (~nate@c-98-45-169-16.hsd1.ca.comcast.net) (Ping timeout: 246 seconds) |
| 2023-07-15 23:26:38 +0200 | gmg | (~user@user/gehmehgeh) (Ping timeout: 240 seconds) |
| 2023-07-15 23:27:46 +0200 | gmg | (~user@user/gehmehgeh) |
| 2023-07-15 23:31:14 +0200 | alexbiehl | (~alexbiehl@2a02:8108:323f:ca14:adeb:5d31:3c95:b332) |
| 2023-07-15 23:33:55 +0200 | lambdabot | (~lambdabot@haskell/bot/lambdabot) (Remote host closed the connection) |
| 2023-07-15 23:36:02 +0200 | lambdabot | (~lambdabot@silicon.int-e.eu) |
| 2023-07-15 23:36:02 +0200 | lambdabot | (~lambdabot@silicon.int-e.eu) (Changing host) |
| 2023-07-15 23:36:02 +0200 | lambdabot | (~lambdabot@haskell/bot/lambdabot) |
| 2023-07-15 23:36:52 +0200 | nick3 | (~nick@ip98-170-224-49.pn.at.cox.net) |
| 2023-07-15 23:37:33 +0200 | Lycurgus | (~juan@user/Lycurgus) (Quit: Exeunt: personae.ai-integration.biz) |
| 2023-07-15 23:38:57 +0200 | Guest6728 | (~finn@185.52.47.189) |
| 2023-07-15 23:40:18 +0200 | takuan | (~takuan@178-116-218-225.access.telenet.be) (Remote host closed the connection) |
| 2023-07-15 23:41:22 +0200 | nick3 | (~nick@ip98-170-224-49.pn.at.cox.net) (Ping timeout: 250 seconds) |
| 2023-07-15 23:43:33 +0200 | fr33domlover | (~fr33domlo@towards.vision) (Remote host closed the connection) |
| 2023-07-15 23:44:41 +0200 | kupi | (uid212005@id-212005.hampstead.irccloud.com) |
| 2023-07-15 23:47:40 +0200 | wroathe | (~wroathe@user/wroathe) (Ping timeout: 272 seconds) |
| 2023-07-15 23:53:53 +0200 | alexbiehl | (~alexbiehl@2a02:8108:323f:ca14:adeb:5d31:3c95:b332) (Ping timeout: 246 seconds) |
| 2023-07-15 23:54:19 +0200 | wroathe | (~wroathe@207-153-38-140.fttp.usinternet.com) |
| 2023-07-15 23:54:20 +0200 | wroathe | (~wroathe@207-153-38-140.fttp.usinternet.com) (Changing host) |
| 2023-07-15 23:54:20 +0200 | wroathe | (~wroathe@user/wroathe) |
| 2023-07-15 23:54:47 +0200 | __monty__ | (~toonn@user/toonn) (Quit: leaving) |