Newest at the top
| 2025-02-10 16:15:48 +0100 | <dminuoso> | The cool thing about lens/optics is not just that they are first class, but all their characteristics (does it target multiple things or not, is it a sum or product type, what is the larger thing and what is the smaller thing) do not just live in the type system, but the the the types change from composition is the result of some mathematics rather. |
| 2025-02-10 16:12:13 +0100 | sawilagar | (~sawilagar@user/sawilagar) (Ping timeout: 244 seconds) |
| 2025-02-10 16:10:25 +0100 | merijn | (~merijn@77.242.116.146) merijn |
| 2025-02-10 16:09:55 +0100 | prasad | (~Thunderbi@2601:243:c001:3f07::d1) (Remote host closed the connection) |
| 2025-02-10 16:09:42 +0100 | merijn | (~merijn@77.242.116.146) (Ping timeout: 268 seconds) |
| 2025-02-10 15:53:08 +0100 | CiaoSen | (~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 |