Newest at the top
| 2025-03-13 13:32:08 +0100 | weary-traveler | (~user@user/user363627) (Remote host closed the connection) |
| 2025-03-13 13:27:04 +0100 | <dminuoso> | (Well, make it a newtype of course) |
| 2025-03-13 13:26:54 +0100 | <dminuoso> | Which you could even use in a pinch |
| 2025-03-13 13:26:35 +0100 | <dminuoso> | Though even if you cant find the API bits, you can just conjure some `data Decoder a = Decoder (Value -> Parser a)` (and equivalently for ToJSON) |
| 2025-03-13 13:23:26 +0100 | <dminuoso> | But sure |
| 2025-03-13 13:23:18 +0100 | <dminuoso> | (Or whether you have a performance constraint) |
| 2025-03-13 13:23:13 +0100 | <dminuoso> | Depends on what is more comfortable. |
| 2025-03-13 13:22:54 +0100 | <tomsmeding> | also I guess (from the docs) that one would rather use Encoding instead of Value? |
| 2025-03-13 13:22:39 +0100 | <dminuoso> | The API is there, just not easily found/documented. |
| 2025-03-13 13:22:31 +0100 | <dminuoso> | Oh yes, the documentation is not clear. Especially at the border where you need to turn this Value into a Text or vice versa. |
| 2025-03-13 13:22:26 +0100 | <tomsmeding> | and hence other libraries are going to expect you to have used the instance style |
| 2025-03-13 13:22:07 +0100 | <tomsmeding> | the documentation rather heavily steers you towards writing instances, though |
| 2025-03-13 13:21:48 +0100 | <tomsmeding> | right |
| 2025-03-13 13:21:40 +0100 | <dminuoso> | Or well, you can reroll them with minimal effort. |
| 2025-03-13 13:21:01 +0100 | <dminuoso> | Most of them are usable without typeclasses. |
| 2025-03-13 13:20:48 +0100 | <tomsmeding> | but then you miss out on the combinators that aeson provides in 'Parser' |
| 2025-03-13 13:20:30 +0100 | <dminuoso> | What do you mean by "manually"? |
| 2025-03-13 13:20:23 +0100 | <tomsmeding> | and manually parse it from a Value |
| 2025-03-13 13:20:20 +0100 | <tomsmeding> | right, you can manually turn the thing into a Value, of course |
| 2025-03-13 13:20:17 +0100 | <dminuoso> | I feel like this is a strange blindness issue. |
| 2025-03-13 13:20:04 +0100 | <dminuoso> | `turnMyThingToJSON :: Thing -> Value` |
| 2025-03-13 13:20:00 +0100 | <tomsmeding> | you can only use it on types that implement the class anyway? |
| 2025-03-13 13:19:51 +0100 | <dminuoso> | Yes, so? |
| 2025-03-13 13:19:41 +0100 | <tomsmeding> | dminuoso: toJSON is a method of ToJSON. |
| 2025-03-13 13:19:12 +0100 | <dminuoso> | tomsmeding: `toJSON :: YourThing -> Value` - you do not have to attach this to a typeclass for this to work. |
| 2025-03-13 13:19:10 +0100 | <tomsmeding> | you can even have only one newtype, and give it a phantom parameter that indicates the particular (de)serialisation you want ;) |
| 2025-03-13 13:18:50 +0100 | <tomsmeding> | especially if some external dependency requires you to use the classes, use newtype wrappers |
| 2025-03-13 13:18:18 +0100 | igemnace | (~igemnace@user/igemnace) igemnace |
| 2025-03-13 13:17:50 +0100 | __monty__ | (~toonn@user/toonn) toonn |
| 2025-03-13 13:17:47 +0100 | <Square2> | dminuoso, what do you suggest instead? I use the OpenApi dependency which seems to require me to use Aeson instances. |
| 2025-03-13 13:17:38 +0100 | <tomsmeding> | dminuoso: what to do instead? |
| 2025-03-13 13:17:17 +0100 | df | (~ben@justworks.xyz) |
| 2025-03-13 13:17:02 +0100 | <dminuoso> | They are a rather poor fit for de/-serialization precisely for reasons like you just encountered. |
| 2025-03-13 13:16:46 +0100 | <dminuoso> | Just dont use typeclass machinery. |
| 2025-03-13 13:16:44 +0100 | df | (~ben@justworks.xyz) (Ping timeout: 260 seconds) |
| 2025-03-13 13:16:38 +0100 | <dminuoso> | Square2: You are not forced to use FromJSON/ToJSON |
| 2025-03-13 13:16:35 +0100 | <tomsmeding> | this is what makes the Data.Set / Data.Map API work, for example: if you could pass the same Map between different modules with different Ord instances on the key in scope, you'll severly break the internal invariants of the Map data structure |
| 2025-03-13 13:16:21 +0100 | <Square2> | Ah ok. I thought it could work with careful arrangement of things, but I could see it becoming real troublesome |
| 2025-03-13 13:16:03 +0100 | <tomsmeding> | and furthermore it breaks the general assumption in haskell that typeclass instances are confluent, which is precisely the assumption that any particular class - type combination has at most _one_ instance |
| 2025-03-13 13:15:39 +0100 | unlucy | (sid572875@user/unlucy) unlucy |
| 2025-03-13 13:15:29 +0100 | jakesyl_____ | (sid56879@id-56879.hampstead.irccloud.com) |
| 2025-03-13 13:15:27 +0100 | <tomsmeding> | having two different instances of the same class for the same type in different modules is a recipe for trouble |
| 2025-03-13 13:15:23 +0100 | astra | (sid289983@id-289983.hampstead.irccloud.com) |
| 2025-03-13 13:15:19 +0100 | meinside | (uid24933@id-24933.helmsley.irccloud.com) meinside |
| 2025-03-13 13:15:14 +0100 | rune_ | (sid21167@id-21167.ilkley.irccloud.com) |
| 2025-03-13 13:15:11 +0100 | <tomsmeding> | (and also re-export them automatically) |
| 2025-03-13 13:15:08 +0100 | unlucy | (sid572875@user/unlucy) (Read error: Connection reset by peer) |
| 2025-03-13 13:15:08 +0100 | meinside | (uid24933@id-24933.helmsley.irccloud.com) (Read error: Connection reset by peer) |
| 2025-03-13 13:15:06 +0100 | astra | (sid289983@user/amish) (Read error: Connection reset by peer) |
| 2025-03-13 13:15:06 +0100 | rune_ | (sid21167@id-21167.ilkley.irccloud.com) (Read error: Connection reset by peer) |