Newest at the top
| 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 |
| 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.. |