Newest at the top
| 2025-10-20 19:47:33 +0200 | wbrawner | (~wbrawner@static.56.224.132.142.clients.your-server.de) wbrawner |
| 2025-10-20 19:47:25 +0200 | wbrawner | (~wbrawner@static.56.224.132.142.clients.your-server.de) (Ping timeout: 264 seconds) |
| 2025-10-20 19:47:20 +0200 | <monochrom> | Could be! |
| 2025-10-20 19:44:30 +0200 | <dolio> | Is that a pun? |
| 2025-10-20 19:43:57 +0200 | <monochrom> | Not sure what you read, but generally "could" could (pun!) be highly hypothetical as in "in another parallel universe" and/or "if I were World Dictator". |
| 2025-10-20 19:43:55 +0200 | <mastarija> | Yeah. Thanks. I somehow misremembered stuff and got stuck thinking my thinking is correct xD |
| 2025-10-20 19:43:15 +0200 | <tomsmeding> | if you want to recurse into a field, then yes |
| 2025-10-20 19:43:11 +0200 | <mastarija> | Now it's coming back to me... |
| 2025-10-20 19:43:03 +0200 | <mastarija> | Yeah. I guess on Rec0 we are supposed to manually call Rep if we want to go deeper, right? |
| 2025-10-20 19:42:53 +0200 | <tomsmeding> | dcpagan: well you can always define (>>=) in terms of join yourself |
| 2025-10-20 19:42:50 +0200 | <monochrom> | I don't think join was ever a method. |
| 2025-10-20 19:42:39 +0200 | <mastarija> | I don't know what I was thinking. |
| 2025-10-20 19:42:35 +0200 | <dcpagan> | Did "join" used to be a class method that one could optionally define for a Monad instance? I could have sworn that I read somewhere that you could define a Monad instance by defining join instead of defining bind, since m >>= k = join $ fmap k m |
| 2025-10-20 19:42:32 +0200 | <mastarija> | Huh. It does. |
| 2025-10-20 19:42:28 +0200 | <tomsmeding> | what do you mean? Do you have a simple example type? |
| 2025-10-20 19:41:39 +0200 | <mastarija> | But will that work for a field that's another product? I just want to go one level deep. |
| 2025-10-20 19:41:05 +0200 | <tomsmeding> | I don't even see any string forms anywhere |
| 2025-10-20 19:40:53 +0200 | <tomsmeding> | note the Int and Bool in there |
| 2025-10-20 19:40:43 +0200 | <yahb2> | https://paste.tomsmeding.com/UQWaOWBa |
| 2025-10-20 19:40:43 +0200 | <tomsmeding> | %% :k! Rep A |
| 2025-10-20 19:40:43 +0200 | <geekosaur> | yes |
| 2025-10-20 19:40:40 +0200 | <yahb2> | <no output> |
| 2025-10-20 19:40:40 +0200 | <tomsmeding> | % data A = A Int Bool deriving (Generic) |
| 2025-10-20 19:40:39 +0200 | ljdarj | (~Thunderbi@user/ljdarj) ljdarj |
| 2025-10-20 19:40:37 +0200 | <yahb2> | <no output> |
| 2025-10-20 19:40:37 +0200 | <tomsmeding> | % import GHC.Generics |
| 2025-10-20 19:40:32 +0200 | <yahb2> | <interactive>:63:31: error: [GHC-76037] ; Not in scope: type constructor or class ‘Generic’ |
| 2025-10-20 19:40:32 +0200 | <tomsmeding> | % data A = A Int Bool deriving (Generic) |
| 2025-10-20 19:40:26 +0200 | <yahb2> | <no output> |
| 2025-10-20 19:40:26 +0200 | <tomsmeding> | % :seti -XDeriveGeneric |
| 2025-10-20 19:40:21 +0200 | <mastarija> | Wait, really? |
| 2025-10-20 19:40:16 +0200 | <mastarija> | When using `Rep` I unfortunatelly do not get that. |
| 2025-10-20 19:39:58 +0200 | <tomsmeding> | the field types are simply there inside the Rec0 constructors |
| 2025-10-20 19:39:51 +0200 | <mastarija> | But yes. Type of a field is what I'm looking for. |
| 2025-10-20 19:39:35 +0200 | <mastarija> | Like, my ultimate goal is to be able to make a `toTuple` / `fromTuple` instances where I could generically convert any product type into a tuple. |
| 2025-10-20 19:39:07 +0200 | <tomsmeding> | mastarija: which type exactly are you looking for? The type of a field? |
| 2025-10-20 19:39:00 +0200 | <geekosaur> | it's not; like I said, it's not strong enough |
| 2025-10-20 19:38:42 +0200 | <mastarija> | I think Typeable is not what I want. |
| 2025-10-20 19:38:41 +0200 | <tomsmeding> | Data.Data is untyped, and GHC.Generics is quite typed |
| 2025-10-20 19:38:33 +0200 | <tomsmeding> | I'm fairly sure Data.Data is not involved here |
| 2025-10-20 19:38:32 +0200 | <mastarija> | Yeah. They mention something about that. |
| 2025-10-20 19:38:17 +0200 | <geekosaur> | that said, it's entirely possible I remember wrong and Data.Data is the basis for a different generics implementation (SYB seems most likely in that case) |
| 2025-10-20 19:37:47 +0200 | <geekosaur> | my recollection is Generics <- Data.Data <- Typeable, but while Typeable has the type available in some sense it's not powerful enough to make it directly available; the best you can do is its `cast` which produces a `Maybe targetType` |
| 2025-10-20 19:36:09 +0200 | <mastarija> | Hm... interesting. I did not know that. |
| 2025-10-20 19:35:27 +0200 | <geekosaur> | I think the actual type is available, but not that way. Generics are built on Data.Data iirc, which should allow getting the actual type I think? |
| 2025-10-20 19:34:37 +0200 | <mastarija> | But that will only work on product types that have field names (if it's even possible to use HasField like that). |
| 2025-10-20 19:33:59 +0200 | <mastarija> | I'm thinking it might be possible to hack a HasField + type family to get the fields since there's a functional dependency between the parent type, type level field name and the type of the field. |
| 2025-10-20 19:32:31 +0200 | <mastarija> | I'd like to construct a type level list of all the field types of a product type. |
| 2025-10-20 19:32:12 +0200 | <mastarija> | Is there a way to recover the actual type from generics? The type names are written out as a type level string, but I'd like to somehow recover the original type. |
| 2025-10-20 19:31:22 +0200 | tromp | (~textual@2001:1c00:3487:1b00:242b:79a0:e1f9:7ea5) |