2025/02/10

Newest at the top

2025-02-10 15:53:08 +0100CiaoSen(~Jura@ip-037-201-241-067.um10.pools.vodafone-ip.de) (Ping timeout: 272 seconds)
2025-02-10 15:48:41 +0100 <euouae> I just know that I've looked in the past to understand view/span better and it reminded me of them
2025-02-10 15:48:08 +0100 <euouae> They're very much like view/span because in both cases templates are involved & their wonderful error messages :P
2025-02-10 15:47:50 +0100 <mauke> first-class, composable member pointers
2025-02-10 15:47:29 +0100 <mauke> [...] Like view/span of C++ <- I always thought they were a bit like C++ member pointers, at least in the trivial case
2025-02-10 15:45:34 +0100 <dminuoso> `optics` does not break in non-trivial cases, b
2025-02-10 15:45:30 +0100 <euouae> could've chosen something else like x`name or x@name
2025-02-10 15:45:22 +0100 <dminuoso> In my eyes RecordDotSyntax feels very unpolished and it breaks in plenty of non-trivial cases.
2025-02-10 15:44:59 +0100 <dminuoso> But hey, some people seem to like it?
2025-02-10 15:44:51 +0100 <euouae> got it
2025-02-10 15:44:45 +0100 <dminuoso> Like I said, I find them confusing due to interactions with other extensions.
2025-02-10 15:44:23 +0100 <euouae> I think RecordDotSyntax lets you do x.name instead
2025-02-10 15:44:04 +0100 <dminuoso> That's all there is to it.
2025-02-10 15:43:55 +0100 <dminuoso> Right.
2025-02-10 15:43:49 +0100 <euouae> it would be a `HasName x => Lens' x String` right?
2025-02-10 15:43:49 +0100 <dminuoso> So you might have:
2025-02-10 15:43:33 +0100 <dminuoso> Which you can use to read *or* modify (if its a lens)
2025-02-10 15:43:25 +0100 <dminuoso> euouae: With lens/optics rather than extracting the name, you can just produce some kind of optic instead
2025-02-10 15:43:06 +0100 <dminuoso> euouae: This is the idea in essence. Now you can have many things and using `name :: HasName a => a -> String` you can get the name of anything that HasName.
2025-02-10 15:43:00 +0100 <euouae> ah right, and you let polymorphicity deal with it
2025-02-10 15:42:35 +0100 <yahb2> <no output>
2025-02-10 15:42:35 +0100 <dminuoso> % instance HasName Person where name = pName
2025-02-10 15:42:28 +0100 <yahb2> <no output>
2025-02-10 15:42:28 +0100 <dminuoso> % data Person = Person { pName :: String, pAge :: Int }
2025-02-10 15:42:25 +0100 <yahb2> <interactive>:137:39: error: [GHC-58481] parse error on input ‘;’
2025-02-10 15:42:25 +0100 <dminuoso> % data Person = Person { pName :: String; pAge :: Int }
2025-02-10 15:42:12 +0100 <yahb2> <no output>
2025-02-10 15:42:12 +0100 <dminuoso> % class HasName a where name :: a -> String
2025-02-10 15:42:04 +0100 <dminuoso> Very roughly you could just say
2025-02-10 15:41:54 +0100 <dminuoso> euouae: Oh that's quite easy.
2025-02-10 15:41:39 +0100 <dminuoso> But I find them all confusing.
2025-02-10 15:41:30 +0100 <dminuoso> I know there's a *bunch* of extensions that try and give you ways to not do that..
2025-02-10 15:41:29 +0100 <euouae> But I also read that lenses deal with this problem, not sure how.
2025-02-10 15:41:22 +0100 <euouae> I read that there's some new GHC extension that solves this, or maybe a proposal: <https://ghc-proposals.readthedocs.io/en/latest/proposals/0282-record-dot-syntax.html>
2025-02-10 15:41:00 +0100 <dminuoso> I just do what most others do: data X = X { xName :: String } and data Y = Y { yName :: String }
2025-02-10 15:40:36 +0100 <euouae> well, data X = X {name :: String} and then data Y = Y {name :: String}
2025-02-10 15:40:19 +0100 <dminuoso> What namespace problem?
2025-02-10 15:40:11 +0100 <euouae> field accesosrs
2025-02-10 15:40:08 +0100 <euouae> One thing that I didn't understand, and maybe that's some GHC extension, is, how to beat the namespace problem for the record accessors?
2025-02-10 15:39:54 +0100 <dminuoso> If its not, I would refrain.
2025-02-10 15:39:39 +0100 <dminuoso> euouae: In general lens/optics is best when your data is deeply nested.
2025-02-10 15:39:36 +0100 <euouae> It might not be of serious use to me but the book does teach me some haskell too in between
2025-02-10 15:39:19 +0100 <euouae> Hmm... neat.
2025-02-10 15:39:01 +0100 <dminuoso> And `optics` gives us a tool to concisely manipulate that large structure in passes.
2025-02-10 15:38:58 +0100 <euouae> There's ways around the wackyness of the operators, one on top of my head is to color-code them
2025-02-10 15:38:45 +0100 <dminuoso> We have one big use case, which is a networking compiler. In our intermediate representation we have deeply nested data types (around 10 layers deep), with lists/maps, most have plenty of fields..
2025-02-10 15:37:45 +0100 <euouae> they do remind me also of lisp's SETF, which I also always liked but it is limited
2025-02-10 15:37:44 +0100 <dminuoso> But the DSL (especially all the operators) can look confusing, there's only so much %~~.! and ?!~..! that my eyes can tolerate.
2025-02-10 15:37:32 +0100 <euouae> maybe it's a style thing, but I like them personally
2025-02-10 15:36:53 +0100 <dminuoso> Execution performance is in general really good.