Newest at the top
| 2025-02-10 16:36:44 +0100 | misterfish | (~misterfis@84.53.85.146) (Ping timeout: 252 seconds) |
| 2025-02-10 16:29:55 +0100 | misterfish | (~misterfis@84.53.85.146) misterfish |
| 2025-02-10 16:28:17 +0100 | Square2 | (~Square4@user/square) (Ping timeout: 252 seconds) |
| 2025-02-10 16:27:28 +0100 | Square3 | (~Square@user/square) Square |
| 2025-02-10 16:23:01 +0100 | hellwolf | (~user@92b0-6982-e317-36c1-0f00-4d40-07d0-2001.sta.estpak.ee) hellwolf |
| 2025-02-10 16:22:33 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 246 seconds) |
| 2025-02-10 16:21:23 +0100 | sawilagar | (~sawilagar@user/sawilagar) sawilagar |
| 2025-02-10 16:20:22 +0100 | hellwolf | (~user@262a-8508-ab6e-9670-0f00-4d40-07d0-2001.sta.estpak.ee) (Ping timeout: 272 seconds) |
| 2025-02-10 16:18:16 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
| 2025-02-10 16:18:04 +0100 | __monty__ | (~toonn@user/toonn) toonn |
| 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 } |