2025/02/11

Newest at the top

2025-02-11 20:26:35 +0100JeremyB99(~JeremyB99@2607:ac80:407:7:faad:86de:6310:fa61)
2025-02-11 20:26:32 +0100 <euouae> right, makes sense
2025-02-11 20:26:07 +0100 <int-e> No, it was just the unqualified version of the same thing
2025-02-11 20:25:58 +0100 <euouae> I thought Endo might've been public but that base:...Internal thing might've been an optimization
2025-02-11 20:25:46 +0100 <euouae> Yeah but you said Endo a, and I thought maybe my type was different
2025-02-11 20:25:14 +0100 <int-e> euouae: note how my first answer was two modules that you can import it from, maybe you missed it
2025-02-11 20:25:05 +0100 <euouae> I just went with what :t told me
2025-02-11 20:24:55 +0100 <euouae> mauke, I didn't realize it was a public type!
2025-02-11 20:24:46 +0100 <euouae> Oh, I see...
2025-02-11 20:24:31 +0100 <int-e> (It's slightly unfortunate that ghci doesn't tell you where to import Endo from but that information is hard to track.)
2025-02-11 20:24:09 +0100 <mauke> but Data.Monoid re-exports it
2025-02-11 20:23:55 +0100 <mauke> it's just originally defined in GHC.Internal.Data.Semigroup.Internal
2025-02-11 20:23:49 +0100 <int-e> But yeah I think those two questions are not connected.
2025-02-11 20:23:41 +0100notzmv(~umar@user/notzmv) (Ping timeout: 268 seconds)
2025-02-11 20:23:26 +0100 <mauke> because https://hackage.haskell.org/package/base-4.21.0.0/docs/Data-Monoid.html#t:Endo is public
2025-02-11 20:23:07 +0100 <int-e> I'd be surprised if it didn't
2025-02-11 20:22:53 +0100 <mauke> wait, are you saying lens is using ghc internal modules?
2025-02-11 20:22:48 +0100merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn
2025-02-11 20:22:45 +0100 <int-e> GHC is the dominant implementation anyway.
2025-02-11 20:22:16 +0100 <euouae> I understand that there are be optimizations in lens that are GHC specific, but I hadn't seen anything before, maybe this is my first exposure
2025-02-11 20:21:40 +0100 <euouae> It's just that... I guess what I'm asking is, if you're a library writer (like lens here) and you dig into GHC internal modules, are you committing a sin? Perhaps GHC documentation says this is okay?
2025-02-11 20:21:06 +0100 <euouae> I guess that's the optimization
2025-02-11 20:20:59 +0100machinedgod(~machinedg@d108-173-18-100.abhsia.telus.net) machinedgod
2025-02-11 20:20:55 +0100 <euouae> Yeah this is a fold
2025-02-11 20:20:43 +0100 <int-e> Endo [a] is usually used as a difference list, to avoid a quadratic slowdown when concatenating many lists
2025-02-11 20:20:20 +0100 <mauke> you're allowed to depend on yourself
2025-02-11 20:20:11 +0100 <EvanR> wherever it came from
2025-02-11 20:20:09 +0100 <EvanR> well whatever is exported is by definition the public API
2025-02-11 20:20:07 +0100 <mauke> euouae: ?? it's your own implementation details
2025-02-11 20:20:00 +0100 <euouae> lol
2025-02-11 20:19:42 +0100 <EvanR> and you never would have known about it if it wasn't for that pesky verbose output and their dog!
2025-02-11 20:19:31 +0100 <euouae> But isn't it finnicky to re export internal stuff? You're tied to something that can blow up at any time
2025-02-11 20:19:09 +0100 <EvanR> modules can reexport stuff defined in an internal module
2025-02-11 20:18:46 +0100 <int-e> you get it from importing Data.Semigroup or Data.Monoid
2025-02-11 20:18:38 +0100 <EvanR> Endo a is a newtype to add Monoid support for a -> a
2025-02-11 20:18:36 +0100 <euouae> Oh I'm not worried about what this specific type means, just why would it be .Internal exposed to the user of the API
2025-02-11 20:18:10 +0100 <EvanR> just more specific
2025-02-11 20:18:09 +0100 <euouae> Is it just using GHC features?
2025-02-11 20:18:06 +0100 <euouae> I know it's some constriction of some kind placed on [a], but it seems private/implementation?
2025-02-11 20:18:01 +0100 <EvanR> Endo [a]
2025-02-11 20:17:29 +0100 <euouae> When I see something like `base:Data.Semigroup.Internal.Endo [a]` in the output of an exported type with `:t`, what exactly does it mean?
2025-02-11 20:11:52 +0100merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds)
2025-02-11 20:07:24 +0100merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn
2025-02-11 20:05:56 +0100notzmv(~umar@user/notzmv) notzmv
2025-02-11 20:04:06 +0100sprotte24(~sprotte24@p200300d16f05dc00448362a75cf21d07.dip0.t-ipconnect.de)
2025-02-11 19:59:09 +0100alfiee(~alfiee@user/alfiee) (Ping timeout: 265 seconds)
2025-02-11 19:56:34 +0100merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 260 seconds)
2025-02-11 19:55:03 +0100euphores(~SASL_euph@user/euphores) euphores
2025-02-11 19:54:43 +0100alfiee(~alfiee@user/alfiee) alfiee
2025-02-11 19:54:24 +0100akegalj(~akegalj@168-206.dsl.iskon.hr) (Quit: leaving)