IRCBrowse

2023/11/07

2023-11-07 00:00:36 +0100tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…)
2023-11-07 00:02:20 +0100pixelmonk(~pixelmonk@173.46.79.26)
2023-11-07 00:02:27 +0100drdo(~drdo@bl14-14-49.dsl.telepac.pt) (Quit: Ping timeout (120 seconds))
2023-11-07 00:03:01 +0100tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl)
2023-11-07 00:03:11 +0100drdo(~drdo@bl14-14-49.dsl.telepac.pt)
2023-11-07 00:05:46 +0100qeef(~qeef@138-169-143-94.cust.centrio.cz) (Quit: Lost terminal)
2023-11-07 00:06:10 +0100bcksl(end@envs.net)
2023-11-07 00:11:00 +0100bcksl(end@envs.net) (Changing host)
2023-11-07 00:11:00 +0100bcksl(end@user/bcksl)
2023-11-07 00:11:17 +0100davetapley(sid666@id-666.uxbridge.irccloud.com) (Server closed connection)
2023-11-07 00:11:27 +0100davetapley(sid666@id-666.uxbridge.irccloud.com)
2023-11-07 00:11:48 +0100[itchyjunk](~itchyjunk@user/itchyjunk/x-7353470)
2023-11-07 00:14:47 +0100end`end
2023-11-07 00:17:41 +0100tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…)
2023-11-07 00:22:31 +0100michalz(~michalz@185.246.207.221) (Remote host closed the connection)
2023-11-07 00:23:27 +0100hpc(~juzz@ip98-169-35-163.dc.dc.cox.net)
2023-11-07 00:25:34 +0100thegman(~thegman@072-239-207-086.res.spectrum.com) (Read error: Connection reset by peer)
2023-11-07 00:27:48 +0100thegman(~thegman@072-239-207-086.res.spectrum.com)
2023-11-07 00:32:46 +0100idgaen(~idgaen@2a01:e0a:498:fd50:fcc6:bb5d:489a:ce8c) (Quit: WeeChat 4.1.1)
2023-11-07 00:34:52 +0100wroathe(~wroathe@50.205.197.50)
2023-11-07 00:34:52 +0100wroathe(~wroathe@50.205.197.50) (Changing host)
2023-11-07 00:34:52 +0100wroathe(~wroathe@user/wroathe)
2023-11-07 00:37:07 +0100Square(~Square@user/square)
2023-11-07 00:37:26 +0100newsham(~newsham@2603-800c-2c01-6825-1540-4c8c-dd9a-bb11.res6.spectrum.com)
2023-11-07 00:37:58 +0100 <newsham> How can I do something like this?
2023-11-07 00:37:58 +0100 <newsham> class ShowAnyway a where
2023-11-07 00:37:59 +0100 <newsham>   showAnyway :: a -> String
2023-11-07 00:37:59 +0100 <newsham> instance {-# OVERLAPPABLE #-} ShowAnyway a where
2023-11-07 00:38:00 +0100 <newsham>   showAnyway _ = "<<unshowable>>"
2023-11-07 00:38:00 +0100 <newsham> instance {-# OVERLAPS #-} Show a => ShowAnyway a where
2023-11-07 00:38:01 +0100 <newsham>   showAnyway a = show a
2023-11-07 00:42:39 +0100ddellacosta(~ddellacos@ool-44c738de.dyn.optonline.net) (Ping timeout: 240 seconds)
2023-11-07 00:43:32 +0100 <c_wraith> You can't do that usefully.
2023-11-07 00:43:54 +0100ddellacosta(~ddellacos@ool-44c738de.dyn.optonline.net)
2023-11-07 00:44:02 +0100 <c_wraith> Here's the thing: instances don't magically exist when requested for polymorphic types
2023-11-07 00:44:07 +0100misterfish(~misterfis@84-53-85-146.bbserv.nl) (Ping timeout: 255 seconds)
2023-11-07 00:47:05 +0100talismanick(~user@2601:204:ef00:bb0::f34e) (Ping timeout: 240 seconds)
2023-11-07 00:48:13 +0100 <c_wraith> Types are erased at compile time. If you want to have an instance available, then the instance must be made available some other way. GHC uses dictionary-passing, where the constraints in the signature is turned into actual arguments. If it hasn't passed a dictionary around, it can't invent one out of nowhere.
2023-11-07 00:49:02 +0100 <c_wraith> And really, this is a good sanity check. If you don't declare that something depends on an instance for a polymorphic type, it can't depend on it.
2023-11-07 00:49:37 +0100 <c_wraith> Enforcing parametric polymorphism makes it much easier to reason about code.
2023-11-07 00:49:53 +0100nrr______(sid20938@id-20938.lymington.irccloud.com) (Server closed connection)
2023-11-07 00:49:57 +0100 <glguy> Independent of whether you should want to do this or not there is https://github.com/sheaf/if-instance and https://github.com/mikeizbicki/ifcxt
2023-11-07 00:50:10 +0100nrr______(sid20938@id-20938.lymington.irccloud.com)
2023-11-07 00:50:13 +0100 <glguy> You probably won't be happy with either, but for completeness ^
2023-11-07 00:50:43 +0100 <c_wraith> They definitely won't result in happiness.
2023-11-07 00:50:53 +0100 <newsham> I assume there's no negation for a type constraint.  i would think that would be something the compiler could statically verify (though maybe its not constructive)
2023-11-07 00:51:09 +0100 <glguy> There'd be no way to reasonably implement it
2023-11-07 00:51:13 +0100 <geekosaur> negation requires a runtime type witness
2023-11-07 00:51:53 +0100ubert1(~Thunderbi@77.119.202.170.wireless.dyn.drei.com)
2023-11-07 00:51:54 +0100 <newsham> doesnt the type constraint mean that statically the compiler passes along the type class as a dictionary?
2023-11-07 00:52:13 +0100 <newsham> if it can statically determine the type class dictionary, couldnt it statically determine if no type class dictionary existed?
2023-11-07 00:52:37 +0100 <geekosaur> but what does it pass in that case?
2023-11-07 00:52:49 +0100 <c_wraith> Sort of. You can use polymorphic recursion to demonstrate that the type is unknown at runtime
2023-11-07 00:52:51 +0100 <newsham> (btw, I worked aorund my problem, now i'm just asking out of curiosity)
2023-11-07 00:53:01 +0100ubert(~Thunderbi@91.141.42.10.wireless.dyn.drei.com) (Ping timeout: 240 seconds)
2023-11-07 00:53:02 +0100ubert1ubert
2023-11-07 00:53:49 +0100wroathe(~wroathe@user/wroathe) (Ping timeout: 245 seconds)
2023-11-07 00:55:03 +0100Sgeo(~Sgeo@user/sgeo)
2023-11-07 00:55:45 +0100notzmv(~zmv@user/notzmv)
2023-11-07 00:56:08 +0100masterbuilder(uid626153@user/masterbuilder)
2023-11-07 00:57:03 +0100xff0x(~xff0x@2405:6580:b080:900:1034:83b0:f1e0:db5e) (Ping timeout: 240 seconds)
2023-11-07 00:57:27 +0100xff0x(~xff0x@178.255.149.135)
2023-11-07 00:58:44 +0100bcksl(end@user/bcksl) (Quit: \)
2023-11-07 01:12:41 +0100xff0x(~xff0x@178.255.149.135) (Ping timeout: 240 seconds)
2023-11-07 01:13:38 +0100 <EvanR> newsham, there's an open world assumption. Code should still work if future code is introduced which adds instances. So deciding to do something on "no such instance now" would be wrong in the face of that
2023-11-07 01:14:50 +0100 <EvanR> deciding statically
2023-11-07 01:14:53 +0100xff0x(~xff0x@2405:6580:b080:900:1034:83b0:f1e0:db5e)
2023-11-07 01:14:59 +0100bcksl(end@user/bcksl)
2023-11-07 01:15:23 +0100 <EvanR> and deciding dynamically at runtime like those crazy things linked, sounds like asking for pain xD
2023-11-07 01:15:30 +0100Athas(athas@2a01:7c8:aaac:1cf:d300:623e:69e4:545f) (Quit: ZNC 1.8.2 - https://znc.in)
2023-11-07 01:15:40 +0100Athas(athas@2a01:7c8:aaac:1cf:d300:623e:69e4:545f)
2023-11-07 01:18:30 +0100 <newsham> yah, I see the point about not doing this dynamically.  but I'm still not following the "open world" assumption reasoning.  in my mind, when the code is compiling something like `Show a => a -> String` it has to make a static decision to provide the "Show a" at compile time, or provide an error.  So in my mind it should be possible to implement
2023-11-07 01:18:31 +0100 <newsham> a `~(Show a) => a -> String`, making the same choice based on the non-existance of (Show a) dictionary.  Perhaps not with that same syntax, but, say for example, defining a `class ~(Show a) => Unshowable a` dictionary.
2023-11-07 01:18:49 +0100 <newsham> so there's some ignorance in my model somewhere about why this cant work.
2023-11-07 01:18:50 +0100diagprov(sid348783@user/diagprov) (Server closed connection)
2023-11-07 01:19:03 +0100diagprov(sid348783@user/diagprov)
2023-11-07 01:19:23 +0100 <EvanR> if you write a function with type Show a => a -> String, and there's no other information, no it doesn't statically determine anything, yet it still works if linked into other projects
2023-11-07 01:19:53 +0100 <EvanR> it's waiting for a dictionary
2023-11-07 01:20:05 +0100 <newsham> but at the call site, it must decide statically.
2023-11-07 01:20:10 +0100 <EvanR> not necessarily
2023-11-07 01:20:25 +0100 <EvanR> it could be called from yet another parametric function
2023-11-07 01:20:28 +0100 <newsham> how is that implemented under the covers?
2023-11-07 01:20:40 +0100 <EvanR> dictionary passing
2023-11-07 01:20:53 +0100 <geekosaur> Show is in fact a good example of that because many Show instances defer to other Show instances
2023-11-07 01:21:07 +0100 <EvanR> you could think of Show a => a -> String as taking 2 arguments, the dictionary and the thing to be shown
2023-11-07 01:21:22 +0100 <newsham> but the compiler will tell you at compile (or link?) time that it couldnt construct a dictionary for the purpose.
2023-11-07 01:21:33 +0100 <newsham> *nod*
2023-11-07 01:21:58 +0100 <EvanR> yeah if you try to show the ord function it will complain
2023-11-07 01:22:03 +0100 <EvanR> > show ord
2023-11-07 01:22:05 +0100 <lambdabot> "<Char -> Int>"
2023-11-07 01:22:11 +0100 <EvanR> WOW
2023-11-07 01:22:17 +0100 <newsham> `show x` desugars to `show x.showdictionary x` or something akin to it.
2023-11-07 01:22:46 +0100 <EvanR> show instances for everything makes this issue hard demonstrate xD
2023-11-07 01:22:57 +0100 <EvanR> > ord + ord
2023-11-07 01:22:59 +0100 <lambdabot> error:
2023-11-07 01:22:59 +0100 <lambdabot> • No instance for (Num (Char -> Int)) arising from a use of ‘+’
2023-11-07 01:22:59 +0100 <lambdabot> (maybe you haven't applied a function to enough arguments?)
2023-11-07 01:23:12 +0100 <newsham> dont worry, I will not overgeneralize by lambdabot's hacks :)
2023-11-07 01:23:21 +0100 <EvanR> so it won't compile, but that's different from "does compile but is broken now"
2023-11-07 01:24:50 +0100 <EvanR> (because someone down the line could provide the requisite Num instance, but we based our decision on the fact that it doesn't and never will exist)
2023-11-07 01:27:18 +0100 <newsham> right, but, doesnt ghc statically determine at compile+link time which objects have the right type to meet the required type constraints and generate dictionaries for each applicable type that can be used at the call sites?   there's never a case where ghc will compile code and determine at runtime if an object is `Show a` or not, right?
2023-11-07 01:27:41 +0100 <EvanR> the other thing is separate compilation
2023-11-07 01:28:12 +0100 <EvanR> so even if call site is in module A and polymorphic code is in module B, they need to be able to compile separately without knowing about each other yet
2023-11-07 01:28:30 +0100 <newsham> understood that at the point of compiling a single .sh into something like an .o, it might not have the full information.  but by the time it is linked, it does, right?  (maybe you're talking about dynamic linking here?  or the `Dyn` type handling?)
2023-11-07 01:28:44 +0100 <newsham> single .hs (not .sh)
2023-11-07 01:28:57 +0100 <EvanR> so it should do what at link time
2023-11-07 01:29:07 +0100 <geekosaur> but that cannot go back and modify something that was compiled 6 months ago, which it would have to do
2023-11-07 01:29:44 +0100 <newsham> so at link time it could resolve a `class ~(Show a) => Unshowable a where ...` to construct an `Unshowable` dictionary.
2023-11-07 01:29:53 +0100 <newsham> if the language designers chose to
2023-11-07 01:30:18 +0100 <geekosaur> with a custom linker that understood how to write Haskell code and hotpatch a library written 6 months ago?
2023-11-07 01:30:31 +0100 <geekosaur> you're welcome to try to write such a linker
2023-11-07 01:30:43 +0100 <newsham> ok, I see where you're going with this.
2023-11-07 01:30:51 +0100 <newsham> its possible, but perhaps not practical
2023-11-07 01:31:31 +0100 <geekosaur> also said linker needs to deal with C++ templates, Rust, Go, etc. that might be linked into Haskell
2023-11-07 01:31:39 +0100 <EvanR> I have a feeling even if that were possible it would cause other problems
2023-11-07 01:31:42 +0100 <newsham> given that the compiler would like to build these class dictionaries in the object files where the class and instances were defined.
2023-11-07 01:31:42 +0100jackdk(sid373013@cssa/jackdk) (Server closed connection)
2023-11-07 01:31:51 +0100jackdk(sid373013@cssa/jackdk)
2023-11-07 01:31:52 +0100 <geekosaur> right now everyone uses the C linker, and nobody wants to change that
2023-11-07 01:32:17 +0100 <geekosaur> C++ has a bunch of template restrictions specifically so they don't have to do this either
2023-11-07 01:32:39 +0100 <EvanR> maybe a sane way to approach your feature would be a global "this type cannot possibly have an instance of class X" and this is communicated globally
2023-11-07 01:33:13 +0100 <geekosaur> but now it's not truly an open typeclass any more. (and indeed one way proposed for this is closed typeclasses)
2023-11-07 01:33:20 +0100 <newsham> i think I have a handle on the reasoning now.  I'm not trying to propose this so much as understand the whys.
2023-11-07 01:33:22 +0100 <EvanR> but by itself it kind of sounds like "private" in oop
2023-11-07 01:33:42 +0100 <EvanR> a feature about lack of features
2023-11-07 01:34:23 +0100 <newsham> I guess to add to the reasoning, as types get more expressive, it might be easy to demonstrate that type P is inhabited, but not always possible to know if ~P.
2023-11-07 01:34:54 +0100 <geekosaur> it's doable but you need type witnesses at runtime, as I said earlier
2023-11-07 01:35:02 +0100 <EvanR> well data types are closed, the author designed it to serve a specific purpose and not to be appended to. Doing so could break invariants guaranteed by the type
2023-11-07 01:35:34 +0100acidjnk(~acidjnk@p200300d6e72b9352bd047a176d81e23c.dip0.t-ipconnect.de)
2023-11-07 01:35:54 +0100 <geekosaur> and it's a different kind of type witness than instance dictionaries
2023-11-07 01:36:07 +0100 <geekosaur> I've seen it but all I recall now is that it involved Refl
2023-11-07 01:36:23 +0100 <geekosaur> which … is useless for looking it up 🙂
2023-11-07 01:38:06 +0100 <EvanR> newsham, have you seen the typeclasses vs the world video, I'd see which is the 4 or 5 cool things about type classes break if you manage to depend on the non-instance of something
2023-11-07 01:38:06 +0100falafel(~falafel@62.175.113.194.dyn.user.ono.com)
2023-11-07 01:38:08 +0100ProofTechnique_(sid79547@id-79547.ilkley.irccloud.com) (Server closed connection)
2023-11-07 01:38:15 +0100 <EvanR> which of the*
2023-11-07 01:38:23 +0100ProofTechnique_(sid79547@id-79547.ilkley.irccloud.com)
2023-11-07 01:38:27 +0100 <newsham> i havent
2023-11-07 01:38:35 +0100 <geekosaur> but that then raises another problem: since it can't be done with a class dictionary, either we now need two extra parameters only one of which is inhabited at runtime, or we need one that is somehow two types at the same time
2023-11-07 01:38:54 +0100 <EvanR> like the diamond dependency "problem" from multiple inheritance actually being not a problem and working perfectly in the type class world
2023-11-07 01:39:40 +0100 <newsham> geekosaur I dont buy that argument.  if you're willing to let the compiler decide if a class exists or not, you could use it to construct a class/dictionary as a witness of it not existing.
2023-11-07 01:40:06 +0100 <EvanR> how do you witness the non-existence of something in haskell
2023-11-07 01:40:10 +0100 <geekosaur> so you've ignored the past 15 or so minutes?
2023-11-07 01:40:37 +0100 <newsham> no.  i'm just saying I think this is something that could be implemented if it was something that compiler decided was worth implementing.
2023-11-07 01:41:17 +0100bcksl(end@user/bcksl) (Quit: \)
2023-11-07 01:41:35 +0100 <newsham> anyway, I think this argument is becoming unproductive, and I think I have found out what I was curious about.  thank you for helping me along.
2023-11-07 01:42:15 +0100motherfsck(~motherfsc@user/motherfsck)
2023-11-07 01:42:16 +0100 <geekosaur> [07 00:35:54] <geekosaur> and it's a different kind of type witness than instance dictionaries
2023-11-07 01:42:39 +0100newsham(~newsham@2603-800c-2c01-6825-1540-4c8c-dd9a-bb11.res6.spectrum.com) (Quit: Client closed)
2023-11-07 01:43:06 +0100 <geekosaur> the typeclass dictionary approach only works if there are no "doesn't exist" constraints
2023-11-07 01:43:15 +0100Lycurgus(~georg@user/Lycurgus) (Quit: Lost terminal)
2023-11-07 01:43:52 +0100 <geekosaur> I don't know enough to say if some other approach would be possible, but I'm pretty sure it would come at a very high price relative to typeclass dictionaries
2023-11-07 01:43:58 +0100eggplantade(~Eggplanta@2600:1700:38c5:d800:6dde:4903:7d59:6a8d) (Ping timeout: 272 seconds)
2023-11-07 01:44:23 +0100 <EvanR> maybe it would be productive to have an example use case
2023-11-07 01:44:59 +0100 <EvanR> if it's "default implementation for every type" it seems like there's a more straight forward way
2023-11-07 01:45:01 +0100bcksl(end@user/bcksl)
2023-11-07 01:45:13 +0100 <EvanR> other languages have that
2023-11-07 01:45:39 +0100 <monochrom> My view: "I have only 100 modules. Is it not possible for the compiler to check all 100 modules, see for itself that Int is not made a Foo instance, therefore it can safely support a way to say 'if Int is not Foo then here is how to make Int a Bar instance'?" Answer: Yes, you have just defeated separate compilation.
2023-11-07 01:45:49 +0100bcksl(end@user/bcksl) (Remote host closed the connection)
2023-11-07 01:46:05 +0100bliminse(~bliminse@user/bliminse) (Ping timeout: 240 seconds)
2023-11-07 01:46:08 +0100 <monochrom> The class system is open because it helps with separate compilation.
2023-11-07 01:46:40 +0100 <monochrom> With an open world, then Prolog's negation-as-failure cannot be relied on.
2023-11-07 01:48:20 +0100bliminse(~bliminse@user/bliminse)
2023-11-07 01:49:08 +0100 <monochrom> But hey! Separate compilation is also standing in the way of mutually import-each-other modules. Perhaps there is a venture for writing a Haskell compiler that has a NoSeparateCompilation extension, by which you can support both CWA and recursive modules.
2023-11-07 01:49:14 +0100 <geekosaur> he's already rejected that because the linker could be taught to rewrite code on the fly
2023-11-07 01:49:32 +0100bcksl(~bcksl@user/bcksl)
2023-11-07 01:49:37 +0100 <monochrom> Well yeah I wouldn't mind that.
2023-11-07 01:49:51 +0100 <monochrom> Now, who wrote that linker again? >:)
2023-11-07 01:50:42 +0100 <geekosaur> and how does that go if everyone writes their own linker to support all these pie-in-the-sky extensions (I already mentioned C++ template restrictions that come from the linker)
2023-11-07 01:50:53 +0100 <c_wraith> GHC's separate compilation leads to a few different cases where it technically violates the spec.
2023-11-07 01:51:33 +0100 <monochrom> In that case, we are saved by the brutal economic reality that everyone waits for someone else to do it, therefore nothing happens and no harm done. >:)
2023-11-07 01:51:36 +0100 <c_wraith> the lack of mutual imports is one. You can actually violate typeclass coherence without an error too.
2023-11-07 01:51:57 +0100John_Ivan(~John_Ivan@user/john-ivan/x-1515935) (Quit: Disrupting the dragon's slumber one time too often shall eventually bestow upon all an empirical and indiscriminate conflagration that will last for all goddamn eternity.)
2023-11-07 01:52:05 +0100 <monochrom> Corollary: This is why every real language is harmful. >:)
2023-11-07 01:52:52 +0100 <geekosaur> technically .hs-boot files make ghc spec-conformant there
2023-11-07 01:53:08 +0100 <geekosaur> it says they have to be supported somehow, possibly with extra information
2023-11-07 01:53:20 +0100 <geekosaur> it says nothing about sanity
2023-11-07 01:54:02 +0100 <c_wraith> well... those sure aren't sane!
2023-11-07 01:54:10 +0100 <monochrom> Also, a crazy Haskell compiler that says "put all modules in the same file" is compliant, too. >:)
2023-11-07 01:54:50 +0100 <EvanR> that strategy is viable over in C apparently
2023-11-07 01:55:02 +0100 <EvanR> but is somehow wildly less popular than put all code in one .h file
2023-11-07 01:55:53 +0100 <c_wraith> don't forget "put all your code in one .h file that you #include wherever you want to know about he library, and then define a special macro in one file to tell it to put all the definitions in that file."
2023-11-07 01:56:21 +0100 <monochrom> hehe
2023-11-07 01:57:07 +0100clxt(~cl_xt@2a09:bac5:9de2:1791::259:c1)
2023-11-07 01:57:49 +0100 <EvanR> separate compilation is a dead end goal
2023-11-07 01:58:14 +0100 <geekosaur> oh god I've seen code like that
2023-11-07 01:58:43 +0100 <c_wraith> one of my friends was telling me a library she was using did that. flecs, maybe?
2023-11-07 02:00:16 +0100pretty_dumm_guy(trottel@gateway/vpn/protonvpn/prettydummguy/x-88029655) (Quit: WeeChat 3.5)
2023-11-07 02:04:41 +0100falafel(~falafel@62.175.113.194.dyn.user.ono.com) (Ping timeout: 240 seconds)
2023-11-07 02:09:21 +0100Lord_of_Life(~Lord@user/lord-of-life/x-2819915) (Ping timeout: 240 seconds)
2023-11-07 02:10:31 +0100Lord_of_Life(~Lord@user/lord-of-life/x-2819915)
2023-11-07 02:16:24 +0100newsham(~newsham@2603-800c-2c01-6825-1540-4c8c-dd9a-bb11.res6.spectrum.com)
2023-11-07 02:17:02 +0100hpc(~juzz@ip98-169-35-163.dc.dc.cox.net) (Quit: Lost terminal)
2023-11-07 02:17:03 +0100 <newsham> " In the many cases in which monomorphization does succeed, it has the additional benefit of leading to very efficient code.
2023-11-07 02:17:03 +0100 <newsham> For instance, all dictionaries (used to implement type classes) are statically eliminated by partial evaluation"
2023-11-07 02:17:36 +0100 <newsham> so the knowledge of "x :: P" can be lost at this stage of compilation.
2023-11-07 02:18:41 +0100Natch(~natch@c-9e07225c.038-60-73746f7.bbcust.telenor.se) (Ping timeout: 240 seconds)
2023-11-07 02:19:57 +0100JSharp(sid4580@id-4580.lymington.irccloud.com) (Server closed connection)
2023-11-07 02:20:15 +0100JSharp(sid4580@id-4580.lymington.irccloud.com)
2023-11-07 02:21:09 +0100clxt(~cl_xt@2a09:bac5:9de2:1791::259:c1) ()
2023-11-07 02:23:27 +0100Natch(~natch@c-9e07225c.038-60-73746f7.bbcust.telenor.se)
2023-11-07 02:25:40 +0100 <geekosaur> or not known in the first place. `show (Just x) = "Just " ++ show x` — `x` is polymorphic and the dictionary can't be eliminated. (this isn't actually how `Show` works but is simplified)
2023-11-07 02:26:29 +0100 <geekosaur> I left out the showsPrec stuff that uses a dlist rather than append, and deals with inserting parentheses for precedence
2023-11-07 02:26:48 +0100Tuplanolla(~Tuplanoll@91-159-68-236.elisa-laajakaista.fi) (Ping timeout: 260 seconds)
2023-11-07 02:30:27 +0100Axman6(~Axman6@user/axman6) (Server closed connection)
2023-11-07 02:34:35 +0100 <newsham> my point above is that it is convenient in separate compilation to perform optimizations on a per-file basis that removes knowledge that "x :: P".  it could in theory be preserved and kept til linking time.
2023-11-07 02:35:45 +0100 <EvanR> there are link time optimizations, cross module inlining at least
2023-11-07 02:36:04 +0100 <newsham> ghc knows "x :: P" for all the "x" in the program at some point, but forgets some of it during separate compilation.  for any decidable "P" (ghc supprots undecidable types), it could in theory preserve knowledge of all "x :: P" until link time, and compute any "x :: ~P" at link time.
2023-11-07 02:36:37 +0100 <newsham> but it doesnt do that
2023-11-07 02:36:59 +0100 <geekosaur> and never will because a haskell-only linker is no-go
2023-11-07 02:37:38 +0100 <geekosaur> in a world where people expect to link haskell, C, Rust, Go, etc. together, custom per-language linkers are not and cannot be a thing
2023-11-07 02:37:54 +0100 <geekosaur> it's bad enough that ghc needs hacks to allow linking with C++
2023-11-07 02:39:03 +0100 <geekosaur> hacks which don't scale once you want to link Rust into it
2023-11-07 02:39:15 +0100degraafk(sid71464@id-71464.lymington.irccloud.com) (Server closed connection)
2023-11-07 02:39:24 +0100degraafk(sid71464@id-71464.lymington.irccloud.com)
2023-11-07 02:40:19 +0100 <newsham> "and never will" is probably right.  "cannot be a thing" is not correct.  but off topic.
2023-11-07 02:41:07 +0100 <geekosaur> cannot viablybe a thing
2023-11-07 02:41:32 +0100 <geekosaur> can be a thing if Haskell is to play only with itself, including a severly crippled FFI
2023-11-07 02:41:53 +0100 <geekosaur> this is not a world anyone wants, so it will never happen
2023-11-07 02:42:03 +0100Athas(athas@2a01:7c8:aaac:1cf:d300:623e:69e4:545f) (Quit: ZNC 1.8.2 - https://znc.in)
2023-11-07 02:42:12 +0100Athas(athas@2a01:7c8:aaac:1cf:d300:623e:69e4:545f)
2023-11-07 02:42:17 +0100 <newsham> there is a world of things that are possible to do but will not likely be done.
2023-11-07 02:42:27 +0100 <geekosaur> one way or another, you need a closed world. either a closed typeclass, or a closed Haskell
2023-11-07 02:42:46 +0100 <monochrom> OK Copenhagen vs Multiple World, anyone? >:)
2023-11-07 02:43:06 +0100 <geekosaur> like there's an actual difference?
2023-11-07 02:43:16 +0100 <geekosaur> one's the other in a mirror
2023-11-07 02:44:10 +0100 <EvanR> still wondering what the not constraint is for
2023-11-07 02:44:48 +0100 <geekosaur> uh, he's said multiple times, he wants ~(Show x)
2023-11-07 02:45:03 +0100 <EvanR> if there's a convincing use case we can just use a kennedy speech to argue that it should be done even if it's ridiculously hard
2023-11-07 02:45:08 +0100 <newsham> that was the motivation behind the musing.
2023-11-07 02:45:12 +0100 <EvanR> yeah but why
2023-11-07 02:45:39 +0100 <EvanR> is it a default implementation of show or something
2023-11-07 02:45:41 +0100 <monochrom> Wait, I thought Kennedy argued that there was no use case. >:)
2023-11-07 02:45:45 +0100 <newsham> *sigh* I was just trying to understand the practical reasons why it is not supported and/or not easily supported.  my questions are already answered.  i'm still musing.
2023-11-07 02:46:05 +0100 <EvanR> because we have existing shenanigans to force default Show
2023-11-07 02:46:25 +0100 <newsham> there exists use cases.  whether they are worthwhile is a value judgement and an engineering judgement.
2023-11-07 02:46:38 +0100 <EvanR> is this a classical existence? xD
2023-11-07 02:46:47 +0100 <EvanR> use cases exist, trust me
2023-11-07 02:47:28 +0100 <newsham> constructively one use case would be to implement show for non-showables without other hackery.
2023-11-07 02:48:00 +0100 <EvanR> you're negating the show constraint as well as all other ways of doing that
2023-11-07 02:48:32 +0100 <EvanR> I have a positive version: use idris where everything can be shown without any code at all, it's built in
2023-11-07 02:48:39 +0100 <EvanR> it's nice
2023-11-07 02:48:58 +0100 <EvanR> I 3/4 seriously wish haskell had this
2023-11-07 02:49:09 +0100 <newsham> "use cases exist -- here is one, which might not be very motivating, but it does exist"
2023-11-07 02:49:23 +0100 <EvanR> yeah I already guessed that on
2023-11-07 02:49:59 +0100 <newsham> excludedMiddle :: Either P ~P
2023-11-07 02:50:08 +0100 <newsham> now i classic logic much?
2023-11-07 02:50:26 +0100 <EvanR> yeah I don't think ghc can do that
2023-11-07 02:50:53 +0100 <newsham> and around we go
2023-11-07 02:51:07 +0100 <newsham> I guess it keeps the conversation going
2023-11-07 02:51:18 +0100 <EvanR> solve the collatz conjecture please ghc
2023-11-07 02:52:57 +0100 <newsham> Decidable P =>
2023-11-07 02:59:55 +0100xff0x(~xff0x@2405:6580:b080:900:1034:83b0:f1e0:db5e) (Ping timeout: 258 seconds)
2023-11-07 03:00:18 +0100FinnElija(~finn_elij@user/finn-elija/x-0085643) (Remote host closed the connection)
2023-11-07 03:00:46 +0100FinnElija(~finn_elij@user/finn-elija/x-0085643)
2023-11-07 03:04:38 +0100paddymahoney(~paddymaho@cpe883d24bcf597-cmbc4dfb741f80.cpe.net.cable.rogers.com)
2023-11-07 03:09:17 +0100dispater(~dispater@mail.brprice.uk) (Server closed connection)
2023-11-07 03:09:37 +0100dispater(~dispater@mail.brprice.uk)
2023-11-07 03:15:54 +0100 <dibblego> data Blah a = Blah -- remind me again that name of this data type please
2023-11-07 03:16:27 +0100 <geekosaur> Proxy?
2023-11-07 03:18:04 +0100 <monochrom> Yeah, Proxy :)
2023-11-07 03:18:26 +0100 <monochrom> The unit functor, applicative, monad. >:)
2023-11-07 03:19:40 +0100 <monochrom> I do not like the following argument, it feels disingenious to me, but the type can be used to refute "monad wraps/contains value to be extracted". :)
2023-11-07 03:20:00 +0100 <monochrom> where "can" = some people buy that argument
2023-11-07 03:22:21 +0100otto_s(~user@p5de2ff30.dip0.t-ipconnect.de) (Ping timeout: 240 seconds)
2023-11-07 03:22:55 +0100 <monochrom> Another trivia pursuit: Moggi's monad papers add a technical definition on top of monads. It's rather long, but an easy corollary is that pure is injective. So Proxy does not satisfy the extra definition. This is reasonable in the papers, the focus is on monads that stand for non-trivial program semantics.
2023-11-07 03:24:17 +0100otto_s(~user@p4ff276b4.dip0.t-ipconnect.de)
2023-11-07 03:30:39 +0100newsham(~newsham@2603-800c-2c01-6825-1540-4c8c-dd9a-bb11.res6.spectrum.com) (Ping timeout: 248 seconds)
2023-11-07 03:30:57 +0100 <hammond> cd 4
2023-11-07 03:36:05 +0100mrmr15537(~mrmr@user/mrmr)
2023-11-07 03:36:55 +0100mrmr1553(~mrmr@user/mrmr) (Ping timeout: 255 seconds)
2023-11-07 03:36:55 +0100mrmr15537mrmr1553
2023-11-07 03:37:21 +0100ddellacosta(~ddellacos@ool-44c738de.dyn.optonline.net) (Ping timeout: 240 seconds)
2023-11-07 03:39:21 +0100ddellacosta(~ddellacos@ool-44c738de.dyn.optonline.net)
2023-11-07 03:40:44 +0100eggplantade(~Eggplanta@2600:1700:38c5:d800:6dde:4903:7d59:6a8d)
2023-11-07 03:45:30 +0100Athas(athas@2a01:7c8:aaac:1cf:d300:623e:69e4:545f) (Quit: ZNC 1.8.2 - https://znc.in)
2023-11-07 03:45:39 +0100Athas(athas@sigkill.dk)
2023-11-07 03:49:05 +0100Unicorn_Princess(~Unicorn_P@user/Unicorn-Princess/x-3540542) (Remote host closed the connection)
2023-11-07 03:49:46 +0100Inst(~Inst@120.244.192.250)
2023-11-07 03:51:16 +0100eggplantade(~Eggplanta@2600:1700:38c5:d800:6dde:4903:7d59:6a8d) (Ping timeout: 272 seconds)
2023-11-07 03:53:04 +0100xff0x(~xff0x@125x103x176x34.ap125.ftth.ucom.ne.jp)
2023-11-07 03:53:16 +0100 <dibblego> thank ya
2023-11-07 03:53:37 +0100[itchyjunk](~itchyjunk@user/itchyjunk/x-7353470) (Remote host closed the connection)
2023-11-07 04:00:18 +0100Axman6(~Axman6@user/axman6)
2023-11-07 04:05:59 +0100edr(~edr@user/edr) (Quit: Leaving)
2023-11-07 04:06:38 +0100finn_elija(~finn_elij@user/finn-elija/x-0085643)
2023-11-07 04:06:38 +0100FinnElija(~finn_elij@user/finn-elija/x-0085643) (Killed (NickServ (Forcing logout FinnElija -> finn_elija)))
2023-11-07 04:06:38 +0100finn_elijaFinnElija
2023-11-07 04:09:48 +0100bitdex(~bitdex@gateway/tor-sasl/bitdex) (Ping timeout: 256 seconds)
2023-11-07 04:11:19 +0100machinedgod(~machinedg@d198-53-218-113.abhsia.telus.net) (Ping timeout: 264 seconds)
2023-11-07 04:13:01 +0100 <lockywolf> Is it possible to use Cabal to install a different version of GHC locally?
2023-11-07 04:13:19 +0100pixelmonk(~pixelmonk@173.46.79.26) (Quit: WeeChat 4.1.0)
2023-11-07 04:14:14 +0100 <monochrom> No.
2023-11-07 04:17:36 +0100 <dibblego> ghcup
2023-11-07 04:19:01 +0100bitdex(~bitdex@gateway/tor-sasl/bitdex)
2023-11-07 04:19:39 +0100FinnElija(~finn_elij@user/finn-elija/x-0085643) (Remote host closed the connection)
2023-11-07 04:20:03 +0100FinnElija(~finn_elij@user/finn-elija/x-0085643)
2023-11-07 04:22:11 +0100AndreasK(sid320732@id-320732.uxbridge.irccloud.com) (Server closed connection)
2023-11-07 04:22:20 +0100AndreasK(sid320732@id-320732.uxbridge.irccloud.com)
2023-11-07 04:33:31 +0100isekaijin(~user@user/isekaijin) (Quit: brb)
2023-11-07 04:38:15 +0100Pozyomka(~pyon@user/pyon)
2023-11-07 04:48:41 +0100td_(~td@i53870926.versanet.de) (Ping timeout: 240 seconds)
2023-11-07 04:50:45 +0100td_(~td@i5387090C.versanet.de)
2023-11-07 04:51:00 +0100ec(~ec@gateway/tor-sasl/ec) (Remote host closed the connection)
2023-11-07 05:01:12 +0100qhong(~qhong@rescomp-21-400677.stanford.edu) (Read error: Connection reset by peer)
2023-11-07 05:01:16 +0100qhong_(~qhong@DN160vrd000d6kpg009l6c0000fj.stanford.edu)
2023-11-07 05:33:52 +0100lisbeths(uid135845@id-135845.lymington.irccloud.com)
2023-11-07 05:35:01 +0100eggplantade(~Eggplanta@104-55-37-220.lightspeed.sntcca.sbcglobal.net)
2023-11-07 05:41:28 +0100waleee(~waleee@h-176-10-144-38.na.cust.bahnhof.se) (Ping timeout: 272 seconds)
2023-11-07 05:42:09 +0100chiselfuse(~chiselfus@user/chiselfuse) (Remote host closed the connection)
2023-11-07 05:42:40 +0100chiselfuse(~chiselfus@user/chiselfuse)
2023-11-07 05:45:30 +0100aforemny(~aforemny@i59F516D1.versanet.de)
2023-11-07 05:45:54 +0100aforemny_(~aforemny@2001:9e8:6cd9:8900:f44b:90af:4c17:1875) (Ping timeout: 258 seconds)
2023-11-07 05:46:54 +0100natto(~natto@129.154.243.159) (Server closed connection)
2023-11-07 05:48:48 +0100natto(~natto@129.154.243.159)
2023-11-07 05:51:01 +0100qqq(~qqq@92.43.167.61)
2023-11-07 06:02:56 +0100sudden(~cat@user/sudden) (Quit: leaving)
2023-11-07 06:03:17 +0100trev(~trev@user/trev)
2023-11-07 06:03:32 +0100sudden(~cat@user/sudden)
2023-11-07 06:04:26 +0100_ht(~Thunderbi@28-52-174-82.ftth.glasoperator.nl)
2023-11-07 06:21:18 +0100Inst(~Inst@120.244.192.250) (Ping timeout: 255 seconds)
2023-11-07 06:27:58 +0100FinnElija(~finn_elij@user/finn-elija/x-0085643) (Remote host closed the connection)
2023-11-07 06:27:58 +0100stiell_(~stiell@gateway/tor-sasl/stiell) (Remote host closed the connection)
2023-11-07 06:28:23 +0100FinnElija(~finn_elij@user/finn-elija/x-0085643)
2023-11-07 06:28:24 +0100stiell_(~stiell@gateway/tor-sasl/stiell)
2023-11-07 06:28:32 +0100Inst(~Inst@120.244.192.250)
2023-11-07 06:40:34 +0100jmdaemon(~jmdaemon@user/jmdaemon)
2023-11-07 06:46:46 +0100 <lockywolf> Can somebody have a look at this pull request and tell me what is wrong with it? https://github.com/haskell/hackage-server/pull/1262
2023-11-07 06:55:16 +0100nate2(~nate@c-98-45-169-16.hsd1.ca.comcast.net)
2023-11-07 06:59:53 +0100nate2(~nate@c-98-45-169-16.hsd1.ca.comcast.net) (Ping timeout: 258 seconds)
2023-11-07 07:04:49 +0100Lycurgus(~georg@li1192-118.members.linode.com)
2023-11-07 07:04:49 +0100Lycurgus(~georg@li1192-118.members.linode.com) (Changing host)
2023-11-07 07:04:49 +0100Lycurgus(~georg@user/Lycurgus)
2023-11-07 07:06:21 +0100Square(~Square@user/square) (Ping timeout: 240 seconds)
2023-11-07 07:08:31 +0100thegman(~thegman@072-239-207-086.res.spectrum.com) (Quit: leaving)
2023-11-07 07:15:53 +0100Fangs(sid141280@2a03:5180:f:4::2:27e0) (Server closed connection)
2023-11-07 07:16:05 +0100Fangs(sid141280@id-141280.hampstead.irccloud.com)
2023-11-07 07:24:41 +0100ACuriousMoose(~ACuriousM@142.166.18.53) (Ping timeout: 240 seconds)
2023-11-07 07:26:37 +0100cjay(cjay@nerdbox.nerd2nerd.org) (Server closed connection)
2023-11-07 07:26:45 +0100cjay(cjay@nerdbox.nerd2nerd.org)
2023-11-07 07:27:27 +0100takuan(~takuan@178-116-218-225.access.telenet.be)
2023-11-07 07:29:01 +0100harveypwca(~harveypwc@2601:246:c280:7940:585a:99af:3e4c:209b)
2023-11-07 07:32:24 +0100 <Inst> quick question about the m word, is it right to have an intuition that the identity laws are primarily about pure / return, not bind?
2023-11-07 07:32:29 +0100 <Inst> yes, bind / join has to be part of it
2023-11-07 07:32:34 +0100michalz(~michalz@185.246.207.201)
2023-11-07 07:32:47 +0100 <Inst> but it's basically saying that there has to be an identity configuration of the type
2023-11-07 07:33:07 +0100tcard(~tcard@2400:4051:5801:7500:cf17:befc:ff82:5303) (Remote host closed the connection)
2023-11-07 07:33:25 +0100tcard(~tcard@2400:4051:5801:7500:cf17:befc:ff82:5303)
2023-11-07 07:34:47 +0100FinnElija(~finn_elij@user/finn-elija/x-0085643) (Remote host closed the connection)
2023-11-07 07:35:23 +0100FinnElija(~finn_elij@user/finn-elija/x-0085643)
2023-11-07 07:36:21 +0100_ht(~Thunderbi@28-52-174-82.ftth.glasoperator.nl) (Quit: _ht)
2023-11-07 08:00:11 +0100Square2(~Square4@user/square)
2023-11-07 08:00:55 +0100ysh____(sid6017@id-6017.ilkley.irccloud.com) (Server closed connection)
2023-11-07 08:01:05 +0100ysh____(sid6017@id-6017.ilkley.irccloud.com)
2023-11-07 08:01:43 +0100coot(~coot@89-69-206-216.dynamic.chello.pl)
2023-11-07 08:05:36 +0100gdown(~gavin@h69-11-149-109.kndrid.broadband.dynamic.tds.net) (Remote host closed the connection)
2023-11-07 08:07:46 +0100tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl)
2023-11-07 08:13:16 +0100Lycurgus(~georg@user/Lycurgus) (Quit: leaving)
2023-11-07 08:26:39 +0100lightandlight(sid135476@id-135476.helmsley.irccloud.com) (Server closed connection)
2023-11-07 08:26:48 +0100lightandlight(sid135476@id-135476.helmsley.irccloud.com)
2023-11-07 08:33:33 +0100chele(~chele@user/chele)
2023-11-07 08:34:53 +0100gmg(~user@user/gehmehgeh)
2023-11-07 08:35:17 +0100misterfish(~misterfis@84-53-85-146.bbserv.nl)
2023-11-07 08:41:51 +0100lortabac(~lorenzo@2a01:e0a:541:b8f0:8e88:94cf:6ada:183f)
2023-11-07 08:54:01 +0100catac(~Adium@121.145.15.50)
2023-11-07 08:57:20 +0100fendor(~fendor@2a02:8388:1640:be00:cb6e:46f6:2fe6:1728)
2023-11-07 08:59:06 +0100misterfish(~misterfis@84-53-85-146.bbserv.nl) (Ping timeout: 258 seconds)
2023-11-07 09:02:02 +0100lexi-lambda(sid92601@id-92601.hampstead.irccloud.com) (Server closed connection)
2023-11-07 09:02:11 +0100lexi-lambda(sid92601@id-92601.hampstead.irccloud.com)
2023-11-07 09:05:15 +0100dsal(sid13060@id-13060.lymington.irccloud.com) (Server closed connection)
2023-11-07 09:05:24 +0100dsal(sid13060@id-13060.lymington.irccloud.com)
2023-11-07 09:07:00 +0100fendor(~fendor@2a02:8388:1640:be00:cb6e:46f6:2fe6:1728) (Remote host closed the connection)
2023-11-07 09:08:00 +0100ec_(~ec@gateway/tor-sasl/ec)
2023-11-07 09:08:08 +0100fendor(~fendor@2a02:8388:1640:be00:cb6e:46f6:2fe6:1728)
2023-11-07 09:09:20 +0100sord937(~sord937@gateway/tor-sasl/sord937)
2023-11-07 09:11:12 +0100EvanR_(~EvanR@user/evanr)
2023-11-07 09:11:44 +0100EvanR(~EvanR@user/evanr) (Ping timeout: 272 seconds)
2023-11-07 09:13:26 +0100lisbeths(uid135845@id-135845.lymington.irccloud.com) (Quit: Connection closed for inactivity)
2023-11-07 09:19:53 +0100tzh(~tzh@c-71-193-181-0.hsd1.or.comcast.net) (Quit: zzz)
2023-11-07 09:21:20 +0100yandere(sid467876@id-467876.ilkley.irccloud.com) (Server closed connection)
2023-11-07 09:21:30 +0100yandere(sid467876@id-467876.ilkley.irccloud.com)
2023-11-07 09:24:33 +0100mustafa(sid502723@rockylinux/releng/mustafa) (Server closed connection)
2023-11-07 09:24:45 +0100mustafa(sid502723@rockylinux/releng/mustafa)
2023-11-07 09:25:15 +0100misterfish(~misterfis@84-53-85-146.bbserv.nl)
2023-11-07 09:26:07 +0100adanwan_(~adanwan@gateway/tor-sasl/adanwan) (Remote host closed the connection)
2023-11-07 09:26:35 +0100adanwan(~adanwan@gateway/tor-sasl/adanwan)
2023-11-07 09:30:41 +0100Inst(~Inst@120.244.192.250) (Ping timeout: 240 seconds)
2023-11-07 09:33:10 +0100harveypwca(~harveypwc@2601:246:c280:7940:585a:99af:3e4c:209b) (Quit: Leaving)
2023-11-07 09:34:44 +0100eggplantade(~Eggplanta@104-55-37-220.lightspeed.sntcca.sbcglobal.net) (Remote host closed the connection)
2023-11-07 09:34:52 +0100pretty_dumm_guy(trottel@gateway/vpn/protonvpn/prettydummguy/x-88029655)
2023-11-07 09:38:17 +0100oo_miguel(~Thunderbi@78-11-179-96.static.ip.netia.com.pl)
2023-11-07 09:40:37 +0100Jackneill_(~Jackneill@20014C4E1E058A00193351DCDA9024FA.dsl.pool.telekom.hu)
2023-11-07 09:48:10 +0100catac(~Adium@121.145.15.50) ()
2023-11-07 09:51:05 +0100alp(~alp@2001:861:5e02:eff0:7717:48d8:8dae:8ad2)
2023-11-07 09:51:24 +0100alp(~alp@2001:861:5e02:eff0:7717:48d8:8dae:8ad2) (Changing host)
2023-11-07 09:51:24 +0100alp(~alp@user/alp)
2023-11-07 09:53:54 +0100machinedgod(~machinedg@d198-53-218-113.abhsia.telus.net)
2023-11-07 09:54:35 +0100hughjfchen(~hughjfche@vmi556545.contaboserver.net) (Server closed connection)
2023-11-07 09:54:59 +0100hughjfchen(~hughjfche@vmi556545.contaboserver.net)
2023-11-07 09:56:21 +0100Guest|52(~Guest|52@1-36-218-010.ptr.netvigator.com)
2023-11-07 10:04:14 +0100andjjj23(~irc@107.170.228.47) (Server closed connection)
2023-11-07 10:04:32 +0100andjjj23(~irc@107.170.228.47)
2023-11-07 10:04:38 +0100 <tomsmeding> @tell Inst are the identity laws of a Monoid, i.e. mempty <> x = x = x <> mempty, primarily about mempty?
2023-11-07 10:04:38 +0100 <lambdabot> Consider it noted.
2023-11-07 10:07:33 +0100econo_(uid147250@id-147250.tinside.irccloud.com) (Quit: Connection closed for inactivity)
2023-11-07 10:09:40 +0100eggplantade(~Eggplanta@2600:1700:38c5:d800:6dde:4903:7d59:6a8d)
2023-11-07 10:10:40 +0100s4msung(pcWAavz3xz@user/s4msung) (Server closed connection)
2023-11-07 10:10:59 +0100s4msung(RZuYfCKc6a@user/s4msung)
2023-11-07 10:16:01 +0100chessai(sid225296@id-225296.lymington.irccloud.com) (Server closed connection)
2023-11-07 10:16:11 +0100chessai(sid225296@id-225296.lymington.irccloud.com)
2023-11-07 10:16:35 +0100eso(a0662dfd5e@2604:bf00:561:2000::1266)
2023-11-07 10:18:23 +0100eggplant_(~Eggplanta@104-55-37-220.lightspeed.sntcca.sbcglobal.net)
2023-11-07 10:19:35 +0100Guest|52(~Guest|52@1-36-218-010.ptr.netvigator.com) (Ping timeout: 252 seconds)
2023-11-07 10:20:08 +0100eggplantade(~Eggplanta@2600:1700:38c5:d800:6dde:4903:7d59:6a8d) (Ping timeout: 252 seconds)
2023-11-07 10:29:17 +0100Sgeo(~Sgeo@user/sgeo) (Read error: Connection reset by peer)
2023-11-07 10:43:55 +0100Inst(~Inst@120.244.192.250)
2023-11-07 10:49:00 +0100 <Inst> That's interesting @tomsmeding
2023-11-07 10:49:28 +0100 <Inst> I guess there's probably also a semigroup equivalent of monad, no?
2023-11-07 10:52:12 +0100danse-nr3(~danse@151.47.127.210)
2023-11-07 10:52:36 +0100 <ncf> Bind
2023-11-07 10:53:57 +0100 <Inst> i mean associative without an identity element, but pure / eta is identity if you see monads as a monoid in the category of endofunctor
2023-11-07 10:54:10 +0100 <Inst> in other words, no pure / return / eta, only bind / join / map
2023-11-07 10:54:53 +0100 <ncf> yes, that's Bind from semigroupoids
2023-11-07 10:56:15 +0100nate2(~nate@c-98-45-169-16.hsd1.ca.comcast.net)
2023-11-07 10:57:20 +0100kuribas(~user@ip-188-118-57-242.reverse.destiny.be)
2023-11-07 11:01:23 +0100nate2(~nate@c-98-45-169-16.hsd1.ca.comcast.net) (Ping timeout: 252 seconds)
2023-11-07 11:02:05 +0100ubert(~Thunderbi@77.119.202.170.wireless.dyn.drei.com) (Ping timeout: 240 seconds)
2023-11-07 11:05:27 +0100ubert(~Thunderbi@77.119.214.97.wireless.dyn.drei.com)
2023-11-07 11:07:43 +0100xff0x(~xff0x@125x103x176x34.ap125.ftth.ucom.ne.jp) (Ping timeout: 264 seconds)
2023-11-07 11:13:40 +0100stiell_(~stiell@gateway/tor-sasl/stiell) (Ping timeout: 256 seconds)
2023-11-07 11:14:48 +0100bitdex(~bitdex@gateway/tor-sasl/bitdex) (Ping timeout: 256 seconds)
2023-11-07 11:20:01 +0100mc47(~mc47@xmonad/TheMC47)
2023-11-07 11:21:01 +0100stiell_(~stiell@gateway/tor-sasl/stiell)
2023-11-07 11:23:17 +0100bitdex(~bitdex@gateway/tor-sasl/bitdex)
2023-11-07 11:28:04 +0100arahael(~arahael@1.145.70.153)
2023-11-07 11:31:37 +0100 <Inst> https://hackage.haskell.org/package/semigroupoids-6.0.0.1/docs/Data-Functor-Bind.html#t:Bind
2023-11-07 11:34:06 +0100raehik(~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net)
2023-11-07 11:40:44 +0100robertm(robertm@lattice.rojoma.com) (Server closed connection)
2023-11-07 11:41:06 +0100robertm(robertm@lattice.rojoma.com)
2023-11-07 11:41:21 +0100arahael(~arahael@1.145.70.153) (Ping timeout: 240 seconds)
2023-11-07 11:58:49 +0100lg188(~lg188@82.18.98.230)
2023-11-07 11:59:53 +0100_0xa_(~user@2001:19f0:5001:2ba8:5400:1ff:feda:88fc) (Quit: ZNC 1.7.5+deb4 - https://znc.in)
2023-11-07 12:01:26 +0100_0xa(~user@2001:19f0:5001:2ba8:5400:1ff:feda:88fc)
2023-11-07 12:01:26 +0100_0xa(~user@2001:19f0:5001:2ba8:5400:1ff:feda:88fc) (Changing host)
2023-11-07 12:01:26 +0100_0xa(~user@user/0xa/x-3134607)
2023-11-07 12:02:10 +0100shawwwn(sid6132@id-6132.helmsley.irccloud.com) (Server closed connection)
2023-11-07 12:02:19 +0100shawwwn(sid6132@id-6132.helmsley.irccloud.com)
2023-11-07 12:12:21 +0100Inst(~Inst@120.244.192.250) (Ping timeout: 240 seconds)
2023-11-07 12:13:17 +0100ft(~ft@p4fc2a529.dip0.t-ipconnect.de) (Quit: leaving)
2023-11-07 12:14:06 +0100mmhat(~mmh@p200300f1c7445e14ee086bfffe095315.dip0.t-ipconnect.de)
2023-11-07 12:14:36 +0100xff0x(~xff0x@2405:6580:b080:900:c499:902e:6f70:c890)
2023-11-07 12:15:45 +0100mmhat(~mmh@p200300f1c7445e14ee086bfffe095315.dip0.t-ipconnect.de) (Client Quit)
2023-11-07 12:19:58 +0100stiell_(~stiell@gateway/tor-sasl/stiell) (Ping timeout: 256 seconds)
2023-11-07 12:21:46 +0100_0xa(~user@user/0xa/x-3134607) (Quit: ZNC 1.7.5+deb4 - https://znc.in)
2023-11-07 12:22:52 +0100_0xa(~user@2001:19f0:5001:2ba8:5400:1ff:feda:88fc)
2023-11-07 12:22:52 +0100_0xa(~user@2001:19f0:5001:2ba8:5400:1ff:feda:88fc) (Changing host)
2023-11-07 12:22:52 +0100_0xa(~user@user/0xa/x-3134607)
2023-11-07 12:23:01 +0100pretty_dumm_guy(trottel@gateway/vpn/protonvpn/prettydummguy/x-88029655) (Ping timeout: 240 seconds)
2023-11-07 12:25:19 +0100pretty_dumm_guy(trottel@gateway/vpn/protonvpn/prettydummguy/x-88029655)
2023-11-07 12:28:28 +0100__monty__(~toonn@user/toonn)
2023-11-07 12:31:07 +0100dmj`(sid72307@id-72307.hampstead.irccloud.com) (Server closed connection)
2023-11-07 12:31:34 +0100dmj`(sid72307@id-72307.hampstead.irccloud.com)
2023-11-07 12:32:49 +0100Inst(~Inst@120.244.192.250)
2023-11-07 12:43:24 +0100stiell_(~stiell@gateway/tor-sasl/stiell)
2023-11-07 12:47:05 +0100idgaen(~idgaen@2a01:e0a:498:fd50:fcc6:bb5d:489a:ce8c)
2023-11-07 13:05:49 +0100steew(~steew@user/steew)
2023-11-07 13:07:35 +0100tomku(~tomku@user/tomku) (Server closed connection)
2023-11-07 13:07:49 +0100tomku(~tomku@user/tomku)
2023-11-07 13:17:07 +0100Lycurgus(~georg@user/Lycurgus)
2023-11-07 13:24:08 +0100alp(~alp@user/alp) (Quit: Leaving)
2023-11-07 13:24:23 +0100alp(~alp@2001:861:5e02:eff0:7717:48d8:8dae:8ad2)
2023-11-07 13:25:48 +0100Boarders___(sid425905@id-425905.lymington.irccloud.com) (Server closed connection)
2023-11-07 13:26:11 +0100Boarders___(sid425905@id-425905.lymington.irccloud.com)
2023-11-07 13:26:25 +0100ddellacosta(~ddellacos@ool-44c738de.dyn.optonline.net) (Ping timeout: 255 seconds)
2023-11-07 13:28:57 +0100Lycurgus(~georg@user/Lycurgus) (Quit: leaving)
2023-11-07 13:31:29 +0100pavonia(~user@user/siracusa) (Quit: Bye!)
2023-11-07 13:40:46 +0100ddellacosta(~ddellacos@2607:fb90:df95:5632:ce76:6ed1:85ad:5fc9)
2023-11-07 13:40:54 +0100edr(~edr@user/edr)
2023-11-07 13:41:15 +0100chomwitt(~chomwitt@94.66.63.70)
2023-11-07 13:41:53 +0100SanchayanMaity(sid478177@id-478177.hampstead.irccloud.com) (Server closed connection)
2023-11-07 13:42:03 +0100SanchayanMaity(sid478177@id-478177.hampstead.irccloud.com)
2023-11-07 13:50:26 +0100danse-nr3(~danse@151.47.127.210) (Ping timeout: 258 seconds)
2023-11-07 14:01:33 +0100alp(~alp@2001:861:5e02:eff0:7717:48d8:8dae:8ad2) (Ping timeout: 260 seconds)
2023-11-07 14:04:43 +0100ddellacosta(~ddellacos@2607:fb90:df95:5632:ce76:6ed1:85ad:5fc9) (Ping timeout: 264 seconds)
2023-11-07 14:07:37 +0100lally(sid388228@id-388228.uxbridge.irccloud.com) (Server closed connection)
2023-11-07 14:07:46 +0100lally(sid388228@id-388228.uxbridge.irccloud.com)
2023-11-07 14:17:16 +0100NiKaN(sid385034@id-385034.helmsley.irccloud.com) (Server closed connection)
2023-11-07 14:17:26 +0100danse-nr3(~danse@151.35.103.37)
2023-11-07 14:17:56 +0100NiKaN(sid385034@id-385034.helmsley.irccloud.com)
2023-11-07 14:21:05 +0100img(~img@user/img) (Quit: ZNC 1.8.2 - https://znc.in)
2023-11-07 14:21:58 +0100img(~img@user/img)
2023-11-07 14:24:47 +0100nshepperd2(nshepperd@2600:3c03::f03c:92ff:fe28:92c9) (Server closed connection)
2023-11-07 14:25:02 +0100nshepperd2(nshepperd@2600:3c03::f03c:92ff:fe28:92c9)
2023-11-07 14:26:55 +0100doyougnu-(~doyougnu@45.46.170.68) (Ping timeout: 264 seconds)
2023-11-07 14:33:37 +0100takuan(~takuan@178-116-218-225.access.telenet.be) (Remote host closed the connection)
2023-11-07 14:34:54 +0100takuan(~takuan@178-116-218-225.access.telenet.be)
2023-11-07 14:36:47 +0100fendor(~fendor@2a02:8388:1640:be00:cb6e:46f6:2fe6:1728) (Remote host closed the connection)
2023-11-07 14:37:43 +0100chomwitt(~chomwitt@94.66.63.70) (Ping timeout: 264 seconds)
2023-11-07 14:37:49 +0100aliosablack(~chomwitt@ppp-94-67-201-151.home.otenet.gr)
2023-11-07 14:38:20 +0100fendor(~fendor@2a02:8388:1640:be00:cb6e:46f6:2fe6:1728)
2023-11-07 14:42:57 +0100aliosablack(~chomwitt@ppp-94-67-201-151.home.otenet.gr) (Ping timeout: 258 seconds)
2023-11-07 14:47:55 +0100notzmv(~zmv@user/notzmv) (Ping timeout: 264 seconds)
2023-11-07 14:57:32 +0100sefidel(~sefidel@user/sefidel) (Remote host closed the connection)
2023-11-07 14:57:47 +0100nate2(~nate@c-98-45-169-16.hsd1.ca.comcast.net)
2023-11-07 14:59:47 +0100gooba_(~gooba@90-231-13-185-no3430.tbcn.telia.com) (Quit: Leaving)
2023-11-07 15:00:02 +0100gooba(~gooba@90-231-13-185-no3430.tbcn.telia.com)
2023-11-07 15:00:13 +0100sefidel(~sefidel@user/sefidel)
2023-11-07 15:02:43 +0100nate2(~nate@c-98-45-169-16.hsd1.ca.comcast.net) (Ping timeout: 255 seconds)
2023-11-07 15:05:11 +0100gooba(~gooba@90-231-13-185-no3430.tbcn.telia.com) (Remote host closed the connection)
2023-11-07 15:05:33 +0100gooba(~gooba@90-231-13-185-no3430.tbcn.telia.com)
2023-11-07 15:08:58 +0100Unicorn_Princess(~Unicorn_P@user/Unicorn-Princess/x-3540542)
2023-11-07 15:13:29 +0100tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…)
2023-11-07 15:14:20 +0100notzmv(~zmv@user/notzmv)
2023-11-07 15:24:49 +0100caasih(sid13241@id-13241.ilkley.irccloud.com) (Server closed connection)
2023-11-07 15:24:59 +0100caasih(sid13241@id-13241.ilkley.irccloud.com)
2023-11-07 15:26:11 +0100zetef(~quassel@95.77.17.251)
2023-11-07 15:26:45 +0100aliosablack(~chomwitt@2a02:587:7a05:2c00:1ac0:4dff:fedb:a3f1)
2023-11-07 15:30:51 +0100lhpitn(~tn@mail.lebenshilfe-pi.de)
2023-11-07 15:31:07 +0100lhpitn(~tn@mail.lebenshilfe-pi.de) (Remote host closed the connection)
2023-11-07 15:31:26 +0100aliosablack(~chomwitt@2a02:587:7a05:2c00:1ac0:4dff:fedb:a3f1) (Ping timeout: 252 seconds)
2023-11-07 15:31:29 +0100lhpitn(~tn@31.172.106.163.static-pppoe.dt.ipv4.wtnet.de)
2023-11-07 15:36:31 +0100notzmv(~zmv@user/notzmv) (Ping timeout: 264 seconds)
2023-11-07 15:49:42 +0100notzmv(~zmv@user/notzmv)
2023-11-07 15:50:31 +0100Lycurgus(~georg@user/Lycurgus)
2023-11-07 15:53:32 +0100elevenkb(elevenkb@thunix.net) (ERC 5.5.0.29.1 (IRC client for GNU Emacs 29.1))
2023-11-07 16:04:48 +0100billchenchina(~billchenc@2a0d:2580:ff0c:1:e3c9:c52b:a429:5bfe)
2023-11-07 16:07:43 +0100ddellacosta(~ddellacos@146.70.165.106)
2023-11-07 16:17:04 +0100rosco(~rosco@yp-150-69.tm.net.my)
2023-11-07 16:18:11 +0100ddellacosta(~ddellacos@146.70.165.106) (Ping timeout: 252 seconds)
2023-11-07 16:19:43 +0100rosco(~rosco@yp-150-69.tm.net.my) (Remote host closed the connection)
2023-11-07 16:20:11 +0100Lycurgus(~georg@user/Lycurgus) (Quit: leaving)
2023-11-07 16:22:58 +0100tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl)
2023-11-07 16:23:07 +0100fweht(uid404746@id-404746.lymington.irccloud.com)
2023-11-07 16:31:57 +0100Square2(~Square4@user/square) (Remote host closed the connection)
2023-11-07 16:36:56 +0100waleee(~waleee@h-176-10-144-38.NA.cust.bahnhof.se)
2023-11-07 16:43:30 +0100Pozyomka(~pyon@user/pyon) (Quit: brb)
2023-11-07 16:43:39 +0100ChaiTRex(~ChaiTRex@user/chaitrex) (Quit: ChaiTRex)
2023-11-07 16:44:12 +0100Pozyomka(~pyon@user/pyon)
2023-11-07 16:48:47 +0100tzh(~tzh@c-71-193-181-0.hsd1.or.comcast.net)
2023-11-07 17:00:22 +0100Pozyomka(~pyon@user/pyon) (Quit: brb)
2023-11-07 17:00:50 +0100Pozyomka(~pyon@user/pyon)
2023-11-07 17:09:20 +0100misterfish(~misterfis@84-53-85-146.bbserv.nl) (Ping timeout: 252 seconds)
2023-11-07 17:13:10 +0100aliosablack(~chomwitt@2a02:587:7a05:2c00:1ac0:4dff:fedb:a3f1)
2023-11-07 17:19:22 +0100misterfish(~misterfis@84-53-85-146.bbserv.nl)
2023-11-07 17:20:41 +0100zetef(~quassel@95.77.17.251) (Remote host closed the connection)
2023-11-07 17:21:05 +0100aliosablack(~chomwitt@2a02:587:7a05:2c00:1ac0:4dff:fedb:a3f1) (Ping timeout: 240 seconds)
2023-11-07 17:23:41 +0100danse-nr3(~danse@151.35.103.37) (Ping timeout: 240 seconds)
2023-11-07 17:25:51 +0100waleee(~waleee@h-176-10-144-38.NA.cust.bahnhof.se) (Quit: WeeChat 4.1.0)
2023-11-07 17:27:24 +0100lortabac(~lorenzo@2a01:e0a:541:b8f0:8e88:94cf:6ada:183f) (Ping timeout: 258 seconds)
2023-11-07 17:30:01 +0100danse-nr3(~danse@151.35.103.37)
2023-11-07 17:41:26 +0100econo_(uid147250@id-147250.tinside.irccloud.com)
2023-11-07 17:41:50 +0100 <Inst> https://media.discordapp.net/attachments/531640671149359108/1171489169416134716/image.png?ex=655cd…
2023-11-07 17:41:57 +0100 <Inst> hmmm, it's impossible to get a random type, right?
2023-11-07 17:42:48 +0100todi(~todi@p4fd1a3e6.dip0.t-ipconnect.de)
2023-11-07 17:43:06 +0100 <Inst> since types don't exist at runtime (unless you're using typeable / dynamic, iirc)
2023-11-07 17:44:45 +0100todi(~todi@p4fd1a3e6.dip0.t-ipconnect.de) (Read error: Connection reset by peer)
2023-11-07 17:46:12 +0100zetef(~quassel@5.2.182.98)
2023-11-07 17:47:16 +0100alp(~alp@2001:861:5e02:eff0:40fb:3515:43ea:e419)
2023-11-07 17:49:57 +0100todi(~todi@p4fd1a3e6.dip0.t-ipconnect.de)
2023-11-07 17:49:57 +0100todi(~todi@p4fd1a3e6.dip0.t-ipconnect.de) (Read error: Connection reset by peer)
2023-11-07 17:53:08 +0100eggplant_(~Eggplanta@104-55-37-220.lightspeed.sntcca.sbcglobal.net) (Remote host closed the connection)
2023-11-07 17:53:24 +0100eggplantade(~Eggplanta@2600:1700:38c5:d800:6d7a:4eb0:231d:253f)
2023-11-07 17:53:25 +0100 <danse-nr3> but values exist at runtime, and they might belong to different types
2023-11-07 17:53:47 +0100 <EvanR_> types as such still don't exist at runtime even with typeable dynamic, but their value level representatives do
2023-11-07 17:54:44 +0100 <EvanR_> it appears you're trying to get a random value of type Int not a random type
2023-11-07 17:54:49 +0100EvanR_EvanR
2023-11-07 17:56:22 +0100 <exarkun> It's not really clear what the image has to do with the question, really
2023-11-07 17:56:41 +0100todi(~todi@p4fd1a3e6.dip0.t-ipconnect.de)
2023-11-07 17:57:08 +0100 <exarkun> And it is certainly possible to get a random type - here you go, GHC.Cmm.Expr.Area
2023-11-07 17:59:04 +0100 <EvanR> xkcd certified random
2023-11-07 18:00:48 +0100todi(~todi@p4fd1a3e6.dip0.t-ipconnect.de) (Read error: Connection reset by peer)
2023-11-07 18:00:54 +0100 <monochrom> :)
2023-11-07 18:01:33 +0100 <monochrom> Probably XY problem too.
2023-11-07 18:04:04 +0100todi(~todi@p4fd1a3e6.dip0.t-ipconnect.de)
2023-11-07 18:05:44 +0100AlexNoo_(~AlexNoo@94.233.241.129)
2023-11-07 18:06:08 +0100billchenchina(~billchenc@2a0d:2580:ff0c:1:e3c9:c52b:a429:5bfe) (Remote host closed the connection)
2023-11-07 18:07:56 +0100ChaiTRex(~ChaiTRex@user/chaitrex)
2023-11-07 18:08:40 +0100_ht(~Thunderbi@28-52-174-82.ftth.glasoperator.nl)
2023-11-07 18:09:03 +0100AlexZenon(~alzenon@178.34.161.199) (Ping timeout: 240 seconds)
2023-11-07 18:09:11 +0100AlexNoo(~AlexNoo@178.34.161.199) (Ping timeout: 258 seconds)
2023-11-07 18:10:19 +0100todi(~todi@p4fd1a3e6.dip0.t-ipconnect.de) (Remote host closed the connection)
2023-11-07 18:10:57 +0100zetef(~quassel@5.2.182.98) (Ping timeout: 255 seconds)
2023-11-07 18:13:31 +0100danse-nr3(~danse@151.35.103.37) (Ping timeout: 255 seconds)
2023-11-07 18:13:45 +0100danse-nr3(~danse@151.43.104.61)
2023-11-07 18:16:25 +0100todi(~todi@p4fd1a3e6.dip0.t-ipconnect.de)
2023-11-07 18:17:37 +0100AlexZenon(~alzenon@94.233.241.129)
2023-11-07 18:22:44 +0100chele(~chele@user/chele) (Remote host closed the connection)
2023-11-07 18:27:23 +0100kuribas(~user@ip-188-118-57-242.reverse.destiny.be) (Remote host closed the connection)
2023-11-07 18:29:05 +0100jjhoo(jahakala@user/jjhoo) (Remote host closed the connection)
2023-11-07 18:30:24 +0100euleritian(~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de)
2023-11-07 18:31:10 +0100todi(~todi@p4fd1a3e6.dip0.t-ipconnect.de) (Read error: Connection reset by peer)
2023-11-07 18:33:32 +0100AlexNoo_AlexNoo
2023-11-07 18:34:56 +0100califax(~califax@user/califx) (Remote host closed the connection)
2023-11-07 18:35:18 +0100califax(~califax@user/califx)
2023-11-07 18:35:27 +0100todi(~todi@p4fd1a3e6.dip0.t-ipconnect.de)
2023-11-07 18:36:02 +0100aliosablack(~chomwitt@2a02:587:7a05:2c00:1ac0:4dff:fedb:a3f1)
2023-11-07 18:36:09 +0100coot(~coot@89-69-206-216.dynamic.chello.pl) (Quit: coot)
2023-11-07 18:36:38 +0100todi(~todi@p4fd1a3e6.dip0.t-ipconnect.de) (Read error: Connection reset by peer)
2023-11-07 18:37:01 +0100jjhoo(~jahakala@user/jjhoo)
2023-11-07 18:39:01 +0100machinedgod(~machinedg@d198-53-218-113.abhsia.telus.net) (Ping timeout: 240 seconds)
2023-11-07 18:40:14 +0100todi(~todi@p4fd1a3e6.dip0.t-ipconnect.de)
2023-11-07 18:41:13 +0100todi(~todi@p4fd1a3e6.dip0.t-ipconnect.de) (Remote host closed the connection)
2023-11-07 18:43:41 +0100Inst(~Inst@120.244.192.250) (Ping timeout: 240 seconds)
2023-11-07 18:44:18 +0100todi(~todi@p4fd1a3e6.dip0.t-ipconnect.de)
2023-11-07 18:44:39 +0100todi(~todi@p4fd1a3e6.dip0.t-ipconnect.de) (Read error: Connection reset by peer)
2023-11-07 18:45:35 +0100raehik(~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) (Ping timeout: 252 seconds)
2023-11-07 18:46:01 +0100euleritian(~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Ping timeout: 240 seconds)
2023-11-07 18:47:02 +0100euleritian(~euleritia@dynamic-046-114-204-198.46.114.pool.telefonica.de)
2023-11-07 18:47:45 +0100 <EvanR> lets talk about parsers and laziness. In a bog standard parser you have something like ByteString -> Either ParseError a, internally using parsec or something. Let's say you're parsing a big sequence of things. You can't start to process any of the things until this thing resolves to a Left or Right. Since the last item could be borked. Meanwhile you use a lot of memory storing up a big list of things
2023-11-07 18:48:40 +0100 <EvanR> Otoh if you know the parse won't fail, you could make a lazy ByteString -> [Thing] and use less memory
2023-11-07 18:49:10 +0100ski(~ski@88.131.7.247)
2023-11-07 18:49:16 +0100 <geekosaur> isn't the popint of a parser that you process as you go and throw it out on error?
2023-11-07 18:49:20 +0100 <EvanR> so dumb idea, first run a "would parse" pass which doesn't yield anything except yes or no, then start over, reopen the file, regenerate the bytestring, and parse lazily
2023-11-07 18:49:53 +0100todi(~todi@p4fd1a3e6.dip0.t-ipconnect.de)
2023-11-07 18:49:58 +0100 <geekosaur> race condition ahoy!
2023-11-07 18:50:09 +0100 <EvanR> both steps presumably run without using much memory
2023-11-07 18:50:35 +0100 <EvanR> oh yeah, if someone edits the file between the two steps
2023-11-07 18:52:09 +0100 <ski> ("popint" ?)
2023-11-07 18:52:10 +0100gmg(~user@user/gehmehgeh) (Quit: Leaving)
2023-11-07 18:52:24 +0100geekosaurcan't type
2023-11-07 18:52:28 +0100 <geekosaur> "point"
2023-11-07 18:52:34 +0100 <EvanR> it was a type error
2023-11-07 18:52:54 +0100skiwas confused
2023-11-07 18:53:05 +0100euleritian(~euleritia@dynamic-046-114-204-198.46.114.pool.telefonica.de) (Read error: Connection reset by peer)
2023-11-07 18:53:23 +0100euleritian(~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de)
2023-11-07 18:54:05 +0100todi(~todi@p4fd1a3e6.dip0.t-ipconnect.de) (Read error: Connection reset by peer)
2023-11-07 18:54:19 +0100 <danse-nr3> not sure which train of thoughts you are following, but that leading to "do the parse, then open the file again" sounds not promising
2023-11-07 18:54:32 +0100 <EvanR> or seek back to the beginning
2023-11-07 18:54:52 +0100 <geekosaur> anyway how does this situation differ from any compiler, which has to build the AST first and then modify it. especially relevant to GHC which has to e.g. apply fixity in a post-processing pass
2023-11-07 18:55:31 +0100 <EvanR> that depends on what the next step of processing would have been, if it can't be lazy it can't be lazy anyway
2023-11-07 18:56:22 +0100todi(~todi@p4fd1a3e6.dip0.t-ipconnect.de)
2023-11-07 18:56:22 +0100 <geekosaur> if you're relying on the last thing in the file parsing, arguably you can't really be lazy
2023-11-07 18:56:55 +0100 <EvanR> if you know the last thing in file would parse, somehow, you can!
2023-11-07 18:57:19 +0100todi(~todi@p4fd1a3e6.dip0.t-ipconnect.de) (Read error: Connection reset by peer)
2023-11-07 18:59:14 +0100drewjose(~drewjose@129.154.40.88) (Ping timeout: 245 seconds)
2023-11-07 18:59:19 +0100nate2(~nate@c-98-45-169-16.hsd1.ca.comcast.net)
2023-11-07 19:01:39 +0100todi(~todi@p4fd1a3e6.dip0.t-ipconnect.de)
2023-11-07 19:01:44 +0100 <ski> EvanR : you want some kind of `foldParse' ?
2023-11-07 19:02:23 +0100 <EvanR> :t foldMap
2023-11-07 19:02:24 +0100 <lambdabot> (Foldable t, Monoid m) => (a -> m) -> t a -> m
2023-11-07 19:02:35 +0100yinzzz
2023-11-07 19:04:22 +0100nate2(~nate@c-98-45-169-16.hsd1.ca.comcast.net) (Ping timeout: 255 seconds)
2023-11-07 19:04:44 +0100 <ski> something like `foldParse :: (o -> a -> o) -> o -> Parser a -> ByteString -> Either ParseError o', maybe ?
2023-11-07 19:05:07 +0100 <monochrom> It is true that Parsec etc are not lazy (or rather, are not streaming). They were invented for compiler-like use cases where for the rest of the computation, it is acceptable, even necessary, to hold in memory the entirety of some data structure equivalent to the whole input, so there is no point trying to stream (unless you really need to cut down memory footprint from 2n to n, say).
2023-11-07 19:05:09 +0100todi(~todi@p4fd1a3e6.dip0.t-ipconnect.de) (Remote host closed the connection)
2023-11-07 19:05:34 +0100 <monochrom> However, since then, attoparsec etc have already offered streaming options.
2023-11-07 19:06:22 +0100todi(~todi@p4fd1a3e6.dip0.t-ipconnect.de)
2023-11-07 19:06:43 +0100 <EvanR> attoparsec can incrementally be fed input, but there is still no partial results, for a programming language you'd return a whole AST, or if it's a simple list of input items, you'd construct a big list
2023-11-07 19:06:50 +0100 <EvanR> so streaming in but not out
2023-11-07 19:07:22 +0100 <EvanR> grokking foldParse
2023-11-07 19:08:11 +0100 <monochrom> It's also pretty easy to roll your own poor person's streaming for a simple list of items. You run Parsec once per item, not the whole list.
2023-11-07 19:08:32 +0100gmg(~user@user/gehmehgeh)
2023-11-07 19:08:44 +0100 <monochrom> Then couple that with I/O streaming, e.g., fmap lines getContents or pipes or conduit or...
2023-11-07 19:08:58 +0100 <ski> EvanR : basically `foldl'ing your list of results, except doing it upfront, internally, as each successive item is available, rather than at the end, after getting the whole list
2023-11-07 19:09:09 +0100 <EvanR> now given the thesis that you know it would parse, parsec would work, but now it's doing a bunch of expensive stuff for nothing
2023-11-07 19:09:24 +0100 <danse-nr3> "no partial result", but isn't this the goal of non-strict parsing in the first place? I thought you wanted strict parsing
2023-11-07 19:10:01 +0100 <ski> (what does "strict" vs. "non-strict" mean in this context ?)
2023-11-07 19:10:11 +0100 <monochrom> hee hee
2023-11-07 19:10:55 +0100tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…)
2023-11-07 19:10:58 +0100 <EvanR> strict doesn't apply because nothing is crashing everything is terminating
2023-11-07 19:11:10 +0100 <monochrom> 3 most overused jargons in Haskell: isomorphic, strict, non-strict. >:)
2023-11-07 19:11:49 +0100todi(~todi@p4fd1a3e6.dip0.t-ipconnect.de) (Remote host closed the connection)
2023-11-07 19:11:51 +0100 <EvanR> ski, so move more of the task into the parser
2023-11-07 19:12:21 +0100 <ski> yea, since the parser has that sequence of "parsed results so far", presumably
2023-11-07 19:12:23 +0100 <danse-nr3> you were talking about lazy and i talked about strict, does not sound that mysterious
2023-11-07 19:12:32 +0100fendor(~fendor@2a02:8388:1640:be00:cb6e:46f6:2fe6:1728) (Ping timeout: 252 seconds)
2023-11-07 19:12:51 +0100 <EvanR> yeah this lazy and that strict are from different departments
2023-11-07 19:13:01 +0100 <ski> i'm not sure whether this would work for parsing another structure than left-associated sequences, though
2023-11-07 19:13:17 +0100 <monochrom> I actually also have a weird trick to get very close to streaming or laziness in the case of eg "many foo" so that it does not wait until the end of the output list.
2023-11-07 19:13:59 +0100 <monochrom> But it requires exposing the Parser type and writing one more combinator.
2023-11-07 19:14:26 +0100 <EvanR> ski, yes generalizations beyond "list" would be cool
2023-11-07 19:14:31 +0100 <ski> (e.g. some syntax tree with inherited and synthesized attributes associated with the grammar productions .. to what extend could we fire those rules, during the parser process, with, let's say, some kind of parser-combinator like parser)
2023-11-07 19:15:01 +0100 <ski> monochrom : which one ?
2023-11-07 19:16:57 +0100ski's been thinking about ordered logic lately .. which is related to parsing
2023-11-07 19:18:07 +0100 <monochrom> Suppose the Parser type goes like "newtype P a = MkP{unP :: String -> [] (String, a)}". Define pledge :: P a -> P a; pledge (MkP p) = MkP (\s -> let (s2, a) : tl = p s in (s2, a) : tl)
2023-11-07 19:18:07 +0100 <ski> (also .. i'm reminded i should try to get my application of composable continuations to precedence parsing working ..)
2023-11-07 19:18:33 +0100todi(~todi@p4fd1a3e6.dip0.t-ipconnect.de)
2023-11-07 19:19:22 +0100 <monochrom> "pledge foo" is unsafe in general, but safe if you know that foo doesn't fail. In particular, many p = pledge (some p <|> pure []) makes sense.
2023-11-07 19:20:41 +0100 <ski> right. looks similar to `promiseHead :: Eq a => a -> [a] -> [a]; promiseHead x0 ~(x:xs) = x0 : case x0 == x of True -> xs', which i defined for some tying-the-knot stuff
2023-11-07 19:20:49 +0100 <monochrom> Yeah.
2023-11-07 19:20:50 +0100 <EvanR> is this a noop that introduces a thing that would crash if the assumption of not failing failed
2023-11-07 19:21:04 +0100 <monochrom> Yes.
2023-11-07 19:21:45 +0100 <EvanR> how does it improve memory usage xD
2023-11-07 19:22:16 +0100 <ski> it pulls success earlier in time
2023-11-07 19:22:24 +0100 <monochrom> I also have a version for if the Parser type uses the Leijen-Meijer method of tracking consumedness for disabling backtracking.
2023-11-07 19:22:38 +0100 <EvanR> oh
2023-11-07 19:22:46 +0100 <ski> hm, not sure i know what that is
2023-11-07 19:22:49 +0100 <monochrom> Here is an elementary narrative.
2023-11-07 19:23:09 +0100todi(~todi@p4fd1a3e6.dip0.t-ipconnect.de) (Read error: Connection reset by peer)
2023-11-07 19:24:54 +0100 <monochrom> Suppose I give you "m :: Maybe [Int]". But m could be a thunk that will take huge memory and time before it even resolves to Just (another thunk for the list).
2023-11-07 19:25:26 +0100 <monochrom> But for some reason we already know that it will resolve to Just. (Say, because it came from many foo? :) )
2023-11-07 19:26:56 +0100 <monochrom> So I write a function "pledge m = let Just xs = m in Just xs". Now within O(1) time you see a "Just" and can move on without waiting.
2023-11-07 19:27:14 +0100 <monochrom> Equivalently use an irrefutable pattern. :)
2023-11-07 19:27:50 +0100todi(~todi@p4fd1a3e6.dip0.t-ipconnect.de)
2023-11-07 19:28:06 +0100 <monochrom> It is like unsafeInterleaveIO but for parsers :)
2023-11-07 19:28:56 +0100 <EvanR> so it uses huge memory and time sooner, so it can be reclaimed sooner
2023-11-07 19:29:13 +0100 <ski> what's that Leijen-Meijer method, then ?
2023-11-07 19:29:19 +0100misterfish(~misterfis@84-53-85-146.bbserv.nl) (Ping timeout: 264 seconds)
2023-11-07 19:29:29 +0100 <monochrom> This trick is distilled from Wadler's trick in «Monads for Functional Programming» section 5.11.
2023-11-07 19:29:59 +0100 <monochrom> That would be the paper Parsec: Direct-Style Monadic Parser Combinators For The Real World
2023-11-07 19:30:21 +0100tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl)
2023-11-07 19:30:26 +0100 <monochrom> Today's parsec probably CPS that, ironically. :)
2023-11-07 19:30:47 +0100tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Client Quit)
2023-11-07 19:31:21 +0100tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl)
2023-11-07 19:31:35 +0100stiell_(~stiell@gateway/tor-sasl/stiell) (Remote host closed the connection)
2023-11-07 19:32:11 +0100todi(~todi@p4fd1a3e6.dip0.t-ipconnect.de) (Read error: Connection reset by peer)
2023-11-07 19:32:12 +0100stiell_(~stiell@gateway/tor-sasl/stiell)
2023-11-07 19:32:30 +0100 <monochrom> The history, probably revisionist, may be: a long time ago there was a CPS solution, then Leijen and Meijer were like "but we can defunctionalize it to a simpler ADT", but then people were like "but ADT is too slow we need to CPS it again" >:)
2023-11-07 19:33:26 +0100 <danse-nr3> CPS continuation passing style and ADT algebraic data types?
2023-11-07 19:33:34 +0100 <monochrom> yeah
2023-11-07 19:34:23 +0100neceve(~neceve@user/neceve)
2023-11-07 19:34:25 +0100 <danse-nr3> i did not know there was a tradeoff between the two
2023-11-07 19:34:29 +0100 <ncf> adjoint dunctor theorem
2023-11-07 19:35:19 +0100 <EvanR> the tradeoff that CPS is better in every way? xD
2023-11-07 19:35:22 +0100 <monochrom> yeah readable code vs performant code >:)
2023-11-07 19:35:30 +0100todi(~todi@p4fd1a3e6.dip0.t-ipconnect.de)
2023-11-07 19:35:56 +0100 <monochrom> I think "CPS is better" is incidental on GHC.
2023-11-07 19:36:04 +0100 <monochrom> or rather, "CPS is faster".
2023-11-07 19:36:32 +0100 <EvanR> also, readable vs faster is a terrible choice right
2023-11-07 19:36:54 +0100 <EvanR> how has haskell engineers not revolted against that and figured out a fix
2023-11-07 19:36:58 +0100 <danse-nr3> found ncatlab.org/nlab/show/adjoint+functor+theorem but of course it would take me a while to see the connection with continuation passing style. The other day here we were saying that continuation passing was not easy to model mathematically
2023-11-07 19:36:58 +0100 <monochrom> Then again it's probably just "jump table is faster than if-then-else".
2023-11-07 19:37:36 +0100 <monochrom> Well, GHC figured out pointer tagging to make ADTs faster.
2023-11-07 19:38:11 +0100todi(~todi@p4fd1a3e6.dip0.t-ipconnect.de) (Read error: Connection reset by peer)
2023-11-07 19:38:16 +0100 <monochrom> A long time ago Appel was also like "the compiler should auto-CPS everything so the user doesn't have to".
2023-11-07 19:38:16 +0100 <int-e> monochrom: I feel the same but with a different mental model... I think the continuation closures have a better chance of getting inlined than a function that is called with a constructor that starts with a case expression taking that value apart.
2023-11-07 19:39:07 +0100 <int-e> simplified maybe, since each case becomes a separate function, those functions look smaller.
2023-11-07 19:39:54 +0100 <EvanR> so what happened to Appel
2023-11-07 19:40:11 +0100 <monochrom> Yeah, but GHC also has got an insane rewriter for that, and is an important part of the "from vector to stream to nothing" thing.
2023-11-07 19:40:27 +0100 <int-e> (Is this model accurate? Probably not really... ghc is a complex beast.)
2023-11-07 19:41:04 +0100 <monochrom> To be sure, empirically, there are still many cases when human CPSing still beats GHC.
2023-11-07 19:41:25 +0100 <monochrom> But you would be surprised how many other cases GHC works smart.
2023-11-07 19:41:29 +0100todi(~todi@p4fd1a3e6.dip0.t-ipconnect.de)
2023-11-07 19:41:41 +0100 <monochrom> I know because I was. :)
2023-11-07 19:42:27 +0100 <monochrom> This: https://mail.haskell.org/pipermail/haskell-cafe/2013-April/107775.html
2023-11-07 19:43:24 +0100todi(~todi@p4fd1a3e6.dip0.t-ipconnect.de) (Read error: Connection reset by peer)
2023-11-07 19:44:32 +0100 <monochrom> EvanR: I think most FP compilers follow what Appel says. GHC is the exception actually.
2023-11-07 19:44:41 +0100 <EvanR> that's... those isVal tests use pattern matching xD
2023-11-07 19:45:29 +0100 <monochrom> Yeah, but my point is eg isVal-then-fromVal repeats the same pattern matching, and GHC catches that.
2023-11-07 19:45:57 +0100 <EvanR> thank bob for that
2023-11-07 19:46:06 +0100 <monochrom> I think the redundancy can be restored with -O0.
2023-11-07 19:46:25 +0100 <EvanR> style decisions should stay out of performance considerations
2023-11-07 19:46:59 +0100 <monochrom> Well, this is one of those few happy cases when bad style is also slow code >:)
2023-11-07 19:47:26 +0100 <EvanR> yeah it's usually the other way around
2023-11-07 19:48:04 +0100todi(~todi@p4fd1a3e6.dip0.t-ipconnect.de)
2023-11-07 19:48:14 +0100 <monochrom> It is not everyday that everything aligns and there is a win-win winner and therefore, human nature being what it is, the human applies a not-gate and chooses the losing solution. >:)
2023-11-07 19:50:54 +0100 <exarkun> always a shame to break a streak
2023-11-07 19:51:36 +0100 <int-e> GHC is smart with redundant cases when it sees them (your code is small enough that everything gets inlined)
2023-11-07 19:52:53 +0100 <monochrom> Yeah, I think the vector library has to manually tell GHC "inline this" much more often.
2023-11-07 19:53:30 +0100 <monochrom> It is why it takes forever to compile. :)
2023-11-07 19:53:55 +0100 <monochrom> good style, fast code, fast build --- pick two. >:)
2023-11-07 19:54:07 +0100matijja(~matijja@193.77.181.201) (Quit: ZNC 1.8.2 - https://znc.in)
2023-11-07 19:54:11 +0100 <exarkun> *at most
2023-11-07 19:54:18 +0100 <int-e> And hmm, with CPS it would be harder to do that. (you have someCPSMaybe nothingCB1 justCB1 followed by someCPSMaybe nothingCB2 justCB2... now teach the compiler that if the first call returns nothingCB1 then the second call returns nothingCB2 :-P
2023-11-07 19:54:21 +0100 <danse-nr3> good style and fast code forever
2023-11-07 19:54:50 +0100 <int-e> There is no free lunch.
2023-11-07 19:54:58 +0100matijja(~matijja@193.77.181.201)
2023-11-07 19:55:04 +0100 <monochrom> Then I guess thank God for https://xkcd.com/303/ ? >:)
2023-11-07 19:55:11 +0100danse-nr3should probably offer lunch to GHC devs
2023-11-07 19:55:24 +0100matijja(~matijja@193.77.181.201) (Client Quit)
2023-11-07 19:55:32 +0100 <int-e> monochrom: I don't like eating swords
2023-11-07 19:55:44 +0100 <EvanR> until chat-gpt is asked to write a compiler that can compete with GHC. And it freaks out and produces professor moriarty
2023-11-07 19:55:55 +0100matijja(~matijja@193.77.181.201)
2023-11-07 19:56:22 +0100 <int-e> It's a bit sad that all the non-ghc compilers more or less died.
2023-11-07 19:57:06 +0100 <danse-nr3> it is a bit the culture we live in. At some point a "best" is chosen and all bubbles point to that
2023-11-07 19:58:58 +0100coot(~coot@89-69-206-216.dynamic.chello.pl)
2023-11-07 19:59:04 +0100 <int-e> (jhc was particularly exciting because it was so different in many regards, in particular its treatment of type classes.)
2023-11-07 19:59:22 +0100 <exarkun> danse-nr3: is that culture or natural selection
2023-11-07 19:59:26 +0100 <danse-nr3> j standing for?
2023-11-07 19:59:33 +0100 <EvanR> john's
2023-11-07 19:59:41 +0100 <ski> jmeacham
2023-11-07 19:59:41 +0100 <monochrom> natural selection and economics >:)
2023-11-07 19:59:42 +0100 <geekosaur> john meacham?
2023-11-07 19:59:53 +0100 <danse-nr3> nah, natural selection leaves way more room for the existing to survive
2023-11-07 20:00:09 +0100 <monochrom> then again perhaps selection + economics = culture
2023-11-07 20:00:22 +0100 <exarkun> danse-nr3: on the contrary! it is still much easier to revive hugs than, say, a dinosaur.
2023-11-07 20:00:41 +0100 <ski> obligatory : "The story of jhc" <http://repetae.net/computer/jhc/jhc.shtml#the-story-of-jhc>
2023-11-07 20:00:52 +0100 <danse-nr3> add propaganda to the equation monochrom
2023-11-07 20:00:54 +0100 <int-e> maybe the comparison *is* apt. natural selection really isn't very good in the short term
2023-11-07 20:01:11 +0100 <monochrom> dinosaur got an unfair shock.
2023-11-07 20:02:20 +0100 <danse-nr3> except this comparison does not explain why our culture leads to the production of more dinosaurs
2023-11-07 20:02:34 +0100 <Rembane> Network effects?
2023-11-07 20:03:03 +0100 <danse-nr3> which slips out of the natural selection comparison...
2023-11-07 20:03:47 +0100 <monochrom> Dinosaurs got a meteor shock. We will get a nuclear shock or pandemic shock, then most compilers won't survive either. >:)
2023-11-07 20:04:22 +0100 <danse-nr3> glasgow is not that distributed after all
2023-11-07 20:04:41 +0100 <monochrom> Also I think "natural selection leaves way more room for the existing to survive" manifests not in more Haskell compilers but more scripting languages.
2023-11-07 20:04:43 +0100 <int-e> . o O ( yet )
2023-11-07 20:05:01 +0100 <int-e> . o O ( nothing a big enough explosion can't fix )
2023-11-07 20:05:15 +0100 <int-e> (re: "not distributed")
2023-11-07 20:06:16 +0100 <danse-nr3> just less mortality for diversity in general monochrom, it can be observed also outside haskell-land
2023-11-07 20:06:26 +0100 <monochrom> Haskell compilers are complex, you should compare that to elephants and whales and see no surprise that they are fewer and rarer. The biosphere and the programsphere both favour low-cost things such as insects and scripting languages.
2023-11-07 20:07:15 +0100alp(~alp@2001:861:5e02:eff0:40fb:3515:43ea:e419) (Ping timeout: 258 seconds)
2023-11-07 20:07:19 +0100 <danse-nr3> john apparently managed to build a whale all by himself at some point
2023-11-07 20:07:25 +0100 <monochrom> (Yes, I have done the impossibly ridiculous: comparing scripting languages to insects. Ha!)
2023-11-07 20:07:45 +0100 <monochrom> He hasn't added GC, has he? >:)
2023-11-07 20:08:35 +0100 <int-e> who's out there hunting compilers to extinction though
2023-11-07 20:08:46 +0100 <int-e> maybe it's time to move to -offtopic
2023-11-07 20:09:17 +0100 <EvanR> the references section on the story of JHC doesn't seem to have anything on the type classes
2023-11-07 20:09:17 +0100 <monochrom> That would be when we start counting Java compilers >:)
2023-11-07 20:09:36 +0100 <EvanR> how are they different
2023-11-07 20:10:14 +0100kraftwerk28(~kraftwerk@164.92.219.160) (Quit: *disconnects*)
2023-11-07 20:11:19 +0100 <int-e> EvanR: IIRC JHC had explicit type witnesses (imagine an ADT representing the type structure of each value), and type classes were implemented by pattern matching on that witness. It was a whole program compiler, so this approach was possible. And hopefully, due to aggressive inlining, most of the type witnesses would not actually be manifested at runtime.
2023-11-07 20:11:22 +0100kraftwerk28(~kraftwerk@164.92.219.160)
2023-11-07 20:11:57 +0100AlexNoo_(~AlexNoo@94.233.241.129)
2023-11-07 20:14:03 +0100trev(~trev@user/trev) (Quit: trev)
2023-11-07 20:14:27 +0100todi(~todi@p4fd1a3e6.dip0.t-ipconnect.de) (Read error: Connection reset by peer)
2023-11-07 20:14:58 +0100 <ski> .. Mercury passes around type-infos at run-time .. and has type classes
2023-11-07 20:15:01 +0100AlexNoo(~AlexNoo@94.233.241.129) (Ping timeout: 240 seconds)
2023-11-07 20:17:01 +0100 <ski> (unfortunately, it also breaks parametricity .. i think if they'd been aiming for it, they could have avoided that)
2023-11-07 20:18:03 +0100 <mauke> reminds me of https://okmij.org/ftp/Computation/typeclass.html#Kaes
2023-11-07 20:19:16 +0100 <ski> oh, shiny, ty ! :)
2023-11-07 20:19:59 +0100 <monochrom> Oh, so Wadler didn't get that first...
2023-11-07 20:21:01 +0100todi(~todi@p4fd1a3e6.dip0.t-ipconnect.de)
2023-11-07 20:21:30 +0100ThePenguin(~ThePengui@cust-95-80-24-166.csbnet.se) (Quit: ThePenguin)
2023-11-07 20:23:55 +0100 <mauke> actually, https://okmij.org/ftp/Computation/typeclass.html#intensional is probably a better link
2023-11-07 20:24:09 +0100todi(~todi@p4fd1a3e6.dip0.t-ipconnect.de) (Read error: Connection reset by peer)
2023-11-07 20:24:38 +0100accord(uid568320@id-568320.hampstead.irccloud.com)
2023-11-07 20:25:06 +0100todi(~todi@p4fd1a3e6.dip0.t-ipconnect.de)
2023-11-07 20:26:45 +0100todi(~todi@p4fd1a3e6.dip0.t-ipconnect.de) (Read error: Connection reset by peer)
2023-11-07 20:30:40 +0100 <dolio> monochrom: The irony is that those types of languages get much more complicated type systems bolted onto them.
2023-11-07 20:32:09 +0100todi(~todi@p4fd1a3e6.dip0.t-ipconnect.de)
2023-11-07 20:34:49 +0100 <EvanR> elixir's currently desired type system https://arxiv.org/abs/2306.06391 "a polymorphic type system with set-theoretic types and semantic subtyping"
2023-11-07 20:36:36 +0100 <dolio> Yeah, I saw someone asking about a similar paper for erlang recently.
2023-11-07 20:37:07 +0100 <dolio> According to the paper it was taking ~1 minute to check a 6 line function.
2023-11-07 20:38:52 +0100ft(~ft@p4fc2a529.dip0.t-ipconnect.de)
2023-11-07 20:41:26 +0100todi(~todi@p4fd1a3e6.dip0.t-ipconnect.de) (Read error: Connection reset by peer)
2023-11-07 20:42:23 +0100eggplantade(~Eggplanta@2600:1700:38c5:d800:6d7a:4eb0:231d:253f) (Remote host closed the connection)
2023-11-07 20:42:39 +0100tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…)
2023-11-07 20:43:40 +0100mik3d(~mik3d@pool-173-61-131-199.cmdnnj.fios.verizon.net)
2023-11-07 20:45:10 +0100 <EvanR> Stefan Kaes eh...
2023-11-07 20:45:58 +0100 <int-e> school must have been hell
2023-11-07 20:48:26 +0100mik3d(~mik3d@pool-173-61-131-199.cmdnnj.fios.verizon.net) (Client Quit)
2023-11-07 20:51:49 +0100alp(~alp@2001:861:5e02:eff0:c4b6:a2a:56cf:4df4)
2023-11-07 20:52:37 +0100AlexNoo_AlexNoo
2023-11-07 20:59:00 +0100tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl)
2023-11-07 21:03:01 +0100todi(~todi@p4fd1a3e6.dip0.t-ipconnect.de)
2023-11-07 21:05:43 +0100kiriakos(~kiriakos@p5b03e4f0.dip0.t-ipconnect.de) (Quit: kiriakos)
2023-11-07 21:06:35 +0100asivitz(uid178348@id-178348.tinside.irccloud.com) (Quit: Connection closed for inactivity)
2023-11-07 21:07:18 +0100Tuplanolla(~Tuplanoll@91-159-68-236.elisa-laajakaista.fi)
2023-11-07 21:09:50 +0100todi(~todi@p4fd1a3e6.dip0.t-ipconnect.de) (Read error: Connection reset by peer)
2023-11-07 21:11:40 +0100dcoutts(~duncan@cpc69402-oxfd27-2-0-cust903.4-3.cable.virginm.net) (Remote host closed the connection)
2023-11-07 21:12:02 +0100dcoutts(~duncan@cpc69402-oxfd27-2-0-cust903.4-3.cable.virginm.net)
2023-11-07 21:12:32 +0100mvk(~mvk@2607:fea8:5c9a:a600::900d)
2023-11-07 21:12:33 +0100mvk(~mvk@2607:fea8:5c9a:a600::900d) (Client Quit)
2023-11-07 21:13:14 +0100todi(~todi@p4fd1a3e6.dip0.t-ipconnect.de)
2023-11-07 21:13:32 +0100todi(~todi@p4fd1a3e6.dip0.t-ipconnect.de) (Read error: Connection reset by peer)
2023-11-07 21:15:46 +0100euleritian(~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Ping timeout: 255 seconds)
2023-11-07 21:16:02 +0100euleritian(~euleritia@dynamic-046-114-207-195.46.114.pool.telefonica.de)
2023-11-07 21:16:52 +0100todi(~todi@p4fd1a3e6.dip0.t-ipconnect.de)
2023-11-07 21:18:30 +0100eggplantade(~Eggplanta@2600:1700:38c5:d800:6d7a:4eb0:231d:253f)
2023-11-07 21:20:01 +0100todi(~todi@p4fd1a3e6.dip0.t-ipconnect.de) (Remote host closed the connection)
2023-11-07 21:21:41 +0100todi(~todi@p4fd1a3e6.dip0.t-ipconnect.de)
2023-11-07 21:22:35 +0100eggplantade(~Eggplanta@2600:1700:38c5:d800:6d7a:4eb0:231d:253f) (Ping timeout: 240 seconds)
2023-11-07 21:23:09 +0100todi(~todi@p4fd1a3e6.dip0.t-ipconnect.de) (Read error: Connection reset by peer)
2023-11-07 21:24:39 +0100waleee(~waleee@h-176-10-144-38.NA.cust.bahnhof.se)
2023-11-07 21:25:45 +0100tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Read error: Connection reset by peer)
2023-11-07 21:27:48 +0100coot(~coot@89-69-206-216.dynamic.chello.pl) (Quit: coot)
2023-11-07 21:27:50 +0100Pixi(~Pixi@user/pixi) (Quit: Leaving)
2023-11-07 21:29:04 +0100todi(~todi@p4fd1a3e6.dip0.t-ipconnect.de)
2023-11-07 21:29:31 +0100todi(~todi@p4fd1a3e6.dip0.t-ipconnect.de) (Remote host closed the connection)
2023-11-07 21:31:31 +0100pixelmonk(~pixelmonk@50.205.76.66)
2023-11-07 21:35:55 +0100danse-nr3(~danse@151.43.104.61) (Ping timeout: 264 seconds)
2023-11-07 21:38:50 +0100machinedgod(~machinedg@d198-53-218-113.abhsia.telus.net)
2023-11-07 21:45:19 +0100Pixi(~Pixi@user/pixi)
2023-11-07 21:54:10 +0100ski(~ski@88.131.7.247) (Ping timeout: 255 seconds)
2023-11-07 22:00:39 +0100lortabac(~lorenzo@2a01:e0a:541:b8f0:9856:bce6:702c:92bf)
2023-11-07 22:01:44 +0100_ht(~Thunderbi@28-52-174-82.ftth.glasoperator.nl) (Quit: _ht)
2023-11-07 22:05:20 +0100danza(~francesco@151.43.104.61)
2023-11-07 22:07:20 +0100eggplantade(~Eggplanta@2600:1700:38c5:d800:6d7a:4eb0:231d:253f)
2023-11-07 22:09:30 +0100ciiur^(~cd@70-88-177-118-Atlanta.hfc.comcastbusiness.net)
2023-11-07 22:10:35 +0100danza(~francesco@151.43.104.61) (Read error: Connection reset by peer)
2023-11-07 22:13:18 +0100CrunchyFlakes_(~CrunchyFl@ip92348280.dynamic.kabel-deutschland.de) (Quit: ZNC 1.8.2 - https://znc.in)
2023-11-07 22:13:55 +0100CrunchyFlakes(~CrunchyFl@ip92348280.dynamic.kabel-deutschland.de)
2023-11-07 22:16:50 +0100sord937(~sord937@gateway/tor-sasl/sord937) (Remote host closed the connection)
2023-11-07 22:17:13 +0100sord937(~sord937@gateway/tor-sasl/sord937)
2023-11-07 22:17:45 +0100migas9(~migas@static.140.65.63.178.clients.your-server.de) (Remote host closed the connection)
2023-11-07 22:18:02 +0100migas9(~migas@static.140.65.63.178.clients.your-server.de)
2023-11-07 22:18:32 +0100ubert1(~Thunderbi@77.119.168.33.wireless.dyn.drei.com)
2023-11-07 22:18:59 +0100alp(~alp@2001:861:5e02:eff0:c4b6:a2a:56cf:4df4) (Ping timeout: 252 seconds)
2023-11-07 22:18:59 +0100ubert(~Thunderbi@77.119.214.97.wireless.dyn.drei.com) (Ping timeout: 252 seconds)
2023-11-07 22:19:00 +0100ubert1ubert
2023-11-07 22:20:54 +0100todi(~todi@p4fd1a3e6.dip0.t-ipconnect.de)
2023-11-07 22:21:28 +0100lortabac(~lorenzo@2a01:e0a:541:b8f0:9856:bce6:702c:92bf) (Quit: WeeChat 3.5)
2023-11-07 22:23:29 +0100todi(~todi@p4fd1a3e6.dip0.t-ipconnect.de) (Remote host closed the connection)
2023-11-07 22:23:44 +0100lortabac(~lorenzo@2a01:e0a:541:b8f0:9856:bce6:702c:92bf)
2023-11-07 22:25:37 +0100todi(~todi@p4fd1a3e6.dip0.t-ipconnect.de)
2023-11-07 22:26:12 +0100danza(~francesco@ge-19-117-186.service.infuturo.it)
2023-11-07 22:26:37 +0100todi(~todi@p4fd1a3e6.dip0.t-ipconnect.de) (Read error: Connection reset by peer)
2023-11-07 22:28:20 +0100ciiur^(~cd@70-88-177-118-Atlanta.hfc.comcastbusiness.net) (Ping timeout: 252 seconds)
2023-11-07 22:29:01 +0100ciiur^(~cd@70-88-177-118-Atlanta.hfc.comcastbusiness.net)
2023-11-07 22:29:19 +0100noscript(~james@user/earldouglas)
2023-11-07 22:29:47 +0100lortabac(~lorenzo@2a01:e0a:541:b8f0:9856:bce6:702c:92bf) (Quit: WeeChat 3.5)
2023-11-07 22:29:51 +0100noscript(~james@user/earldouglas) ()
2023-11-07 22:30:01 +0100earldouglas(~james@user/earldouglas)
2023-11-07 22:30:04 +0100todi(~todi@p4fd1a3e6.dip0.t-ipconnect.de)
2023-11-07 22:32:32 +0100earldouglas(~james@user/earldouglas) ()
2023-11-07 22:33:19 +0100ciiur^(~cd@70-88-177-118-Atlanta.hfc.comcastbusiness.net) (Ping timeout: 255 seconds)
2023-11-07 22:33:50 +0100ciiur^(~cd@70-88-177-118-Atlanta.hfc.comcastbusiness.net)
2023-11-07 22:33:53 +0100todi(~todi@p4fd1a3e6.dip0.t-ipconnect.de) (Remote host closed the connection)
2023-11-07 22:36:41 +0100todi(~todi@p4fd1a3e6.dip0.t-ipconnect.de)
2023-11-07 22:37:33 +0100todi(~todi@p4fd1a3e6.dip0.t-ipconnect.de) (Read error: Connection reset by peer)
2023-11-07 22:40:06 +0100kiriakos(~kiriakos@p5b03e4f0.dip0.t-ipconnect.de)
2023-11-07 22:40:20 +0100ACuriousMoose(~ACuriousM@142.166.18.53)
2023-11-07 22:40:50 +0100takuan(~takuan@178-116-218-225.access.telenet.be) (Remote host closed the connection)
2023-11-07 22:40:54 +0100todi(~todi@p4fd1a3e6.dip0.t-ipconnect.de)
2023-11-07 22:43:08 +0100todi(~todi@p4fd1a3e6.dip0.t-ipconnect.de) (Read error: Connection reset by peer)
2023-11-07 22:46:17 +0100todi(~todi@p4fd1a3e6.dip0.t-ipconnect.de)
2023-11-07 22:49:44 +0100todi(~todi@p4fd1a3e6.dip0.t-ipconnect.de) (Read error: Connection reset by peer)
2023-11-07 22:50:05 +0100elkcl(~elkcl@broadband-95-84-226-240.ip.moscow.rt.ru) (Ping timeout: 240 seconds)
2023-11-07 22:50:10 +0100neceve(~neceve@user/neceve) (Ping timeout: 258 seconds)
2023-11-07 22:56:38 +0100alp(~alp@2001:861:5e02:eff0:152f:3894:dff9:5483)
2023-11-07 22:58:36 +0100todi(~todi@p4fd1a3e6.dip0.t-ipconnect.de)
2023-11-07 23:00:52 +0100nate2(~nate@c-98-45-169-16.hsd1.ca.comcast.net)
2023-11-07 23:01:39 +0100jinsun(~jinsun@user/jinsun) (Read error: Connection reset by peer)
2023-11-07 23:01:54 +0100jinsun(~jinsun@user/jinsun)
2023-11-07 23:02:12 +0100todi(~todi@p4fd1a3e6.dip0.t-ipconnect.de) (Read error: Connection reset by peer)
2023-11-07 23:03:22 +0100elkcl(~elkcl@broadband-95-84-226-240.ip.moscow.rt.ru)
2023-11-07 23:05:18 +0100todi(~todi@p4fd1a3e6.dip0.t-ipconnect.de)
2023-11-07 23:05:21 +0100nate2(~nate@c-98-45-169-16.hsd1.ca.comcast.net) (Ping timeout: 240 seconds)
2023-11-07 23:06:12 +0100mechap(~mechap@user/mechap)
2023-11-07 23:06:14 +0100misterfish(~misterfis@84-53-85-146.bbserv.nl)
2023-11-07 23:11:14 +0100dagit(~dagit@2001:558:6025:38:71c6:9d58:7252:8976) (Server closed connection)
2023-11-07 23:16:09 +0100fendor(~fendor@2a02:8388:1640:be00:cb6e:46f6:2fe6:1728)
2023-11-07 23:16:39 +0100zetef(~quassel@5.2.182.98)
2023-11-07 23:16:54 +0100zetef(~quassel@5.2.182.98) (Remote host closed the connection)
2023-11-07 23:20:37 +0100fendor(~fendor@2a02:8388:1640:be00:cb6e:46f6:2fe6:1728) (Remote host closed the connection)
2023-11-07 23:23:20 +0100pointlessslippe1(~pointless@212.82.82.3) (Ping timeout: 255 seconds)
2023-11-07 23:23:51 +0100michalz(~michalz@185.246.207.201) (Remote host closed the connection)
2023-11-07 23:24:39 +0100sord937(~sord937@gateway/tor-sasl/sord937) (Quit: sord937)
2023-11-07 23:34:43 +0100misterfish(~misterfis@84-53-85-146.bbserv.nl) (Ping timeout: 264 seconds)
2023-11-07 23:35:21 +0100kraftwerk28(~kraftwerk@164.92.219.160) (Quit: *disconnects*)
2023-11-07 23:35:25 +0100ciiur^(~cd@70-88-177-118-Atlanta.hfc.comcastbusiness.net) (Ping timeout: 255 seconds)
2023-11-07 23:36:17 +0100ciiur^(~cd@70-88-177-118-Atlanta.hfc.comcastbusiness.net)
2023-11-07 23:36:46 +0100kraftwerk28(~kraftwerk@164.92.219.160)
2023-11-07 23:40:02 +0100emmanuelux(~emmanuelu@user/emmanuelux)
2023-11-07 23:41:02 +0100pavonia(~user@user/siracusa)
2023-11-07 23:41:41 +0100todi(~todi@p4fd1a3e6.dip0.t-ipconnect.de) (Read error: Connection reset by peer)
2023-11-07 23:42:53 +0100ciiur^(~cd@70-88-177-118-Atlanta.hfc.comcastbusiness.net) (Remote host closed the connection)
2023-11-07 23:44:55 +0100aliosablack(~chomwitt@2a02:587:7a05:2c00:1ac0:4dff:fedb:a3f1) (Ping timeout: 264 seconds)
2023-11-07 23:45:33 +0100todi(~todi@p4fd1a3e6.dip0.t-ipconnect.de)
2023-11-07 23:46:21 +0100mechap(~mechap@user/mechap) (Ping timeout: 240 seconds)
2023-11-07 23:51:21 +0100todi(~todi@p4fd1a3e6.dip0.t-ipconnect.de) (Read error: Connection reset by peer)
2023-11-07 23:55:03 +0100todi(~todi@p4fd1a3e6.dip0.t-ipconnect.de)
2023-11-07 23:55:14 +0100alp(~alp@2001:861:5e02:eff0:152f:3894:dff9:5483) (Ping timeout: 252 seconds)
2023-11-07 23:56:19 +0100__monty__(~toonn@user/toonn) (Quit: leaving)
2023-11-07 23:57:30 +0100kraftwerk28(~kraftwerk@164.92.219.160) (Quit: *disconnects*)
2023-11-07 23:58:40 +0100gmg(~user@user/gehmehgeh) (Quit: Leaving)
2023-11-07 23:58:46 +0100kraftwerk28(~kraftwerk@164.92.219.160)