Logs: liberachat/#haskell
| 2021-06-25 19:40:23 | <dminuoso> | Profpatsch: The pinnacle of naming is the qualified identifier of Data.Kind.Type |
| 2021-06-25 19:40:30 | <dminuoso> | That one is just *chef kiss* |
| 2021-06-25 19:40:34 | <Profpatsch> | It is SomeTypeRep in Data.Typeable |
| 2021-06-25 19:40:58 | <Profpatsch> | dminuoso: you mean type Type = Type |
| 2021-06-25 19:41:15 | → | raehik joins (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) |
| 2021-06-25 19:42:40 | → | turlando joins (~turlando@93-42-250-112.ip89.fastwebnet.it) |
| 2021-06-25 19:42:40 | × | turlando quits (~turlando@93-42-250-112.ip89.fastwebnet.it) (Changing host) |
| 2021-06-25 19:42:40 | → | turlando joins (~turlando@user/turlando) |
| 2021-06-25 19:45:23 | → | derelict joins (~derelict@user/derelict) |
| 2021-06-25 19:47:17 | <dminuoso> | Profpatsch: Rather, the identifier Type itself comes from Data.Kind, so if you refer to it qualified by module name, then the whole thing becomes Data.Kind.Type |
| 2021-06-25 19:47:46 | <adamse> | "Data.Typeable provides type representations which are qualified over this index", I'm wondering what qualified is supposed to mean there? is it supposed to be quantified? |
| 2021-06-25 19:47:49 | <dminuoso> | What is it now. Data? Kind? Type? What's with this scoping. |
| 2021-06-25 19:50:53 | → | wroathe joins (~wroathe@c-68-54-25-135.hsd1.mn.comcast.net) |
| 2021-06-25 19:52:37 | <Profpatsch> | > unwrapError $ (parseFromName "evelopment" :: Either Error ServerEnv) |
| 2021-06-25 19:52:39 | <lambdabot> | error: |
| 2021-06-25 19:52:39 | <lambdabot> | Not in scope: type constructor or class ‘Error’error: |
| 2021-06-25 19:52:39 | <lambdabot> | Not in scope: type constructor or class ‘ServerEnv’ |
| 2021-06-25 19:52:40 | <Profpatsch> | *** Exception: ServerEnv can only be one of "Development", "Production" |
| 2021-06-25 19:52:42 | <Profpatsch> | whoo |
| 2021-06-25 19:53:10 | <Profpatsch> | Though now the deriving clauses are longer than the parsing function … |
| 2021-06-25 19:53:29 | → | tromp joins (~textual@dhcp-077-249-230-040.chello.nl) |
| 2021-06-25 19:53:32 | <Profpatsch> | deriving stock (Generic, Read, Enum, Bounded, Show) |
| 2021-06-25 19:53:35 | <Profpatsch> | deriving (ParseValue) via (ParseEnum ServerEnv) |
| 2021-06-25 19:53:43 | <Profpatsch> | the Generic is for ToJSON |
| 2021-06-25 19:53:46 | <Profpatsch> | nothing to see here |
| 2021-06-25 19:54:56 | <dminuoso> | Profpatsch: You should see how this gets with deriving-aeson :) |
| 2021-06-25 19:55:08 | <dminuoso> | (A library Im a really big fan of, if you ever want to use deriving based instances) |
| 2021-06-25 19:55:28 | <Profpatsch> | Ah |
| 2021-06-25 19:55:35 | <Profpatsch> | I’m a fan of just writing parser functions |
| 2021-06-25 19:55:45 | <Profpatsch> | those are a lot easier to wrestle with |
| 2021-06-25 19:56:07 | <dminuoso> | Sure, but when you have a hundred data types with mostly boilerplate, then handwritten instances quickly introduce typos. |
| 2021-06-25 19:56:17 | <Profpatsch> | hrm, maybe |
| 2021-06-25 19:56:23 | <Profpatsch> | what kind of typoes? |
| 2021-06-25 19:56:30 | <Profpatsch> | field names? |
| 2021-06-25 19:56:53 | <dminuoso> | Sure |
| 2021-06-25 19:57:14 | <dminuoso> | Or stuff like not checking for extra/unused attribute names |
| 2021-06-25 19:57:36 | <Profpatsch> | somehow go has the most pragmatic approach with their blursed comment syntax |
| 2021-06-25 19:57:42 | → | MorrowM joins (~MorrowM_@147.161.9.135) |
| 2021-06-25 19:57:43 | <dminuoso> | I like refusing input that doesnt exactly match the schema because it reveals errors much quicker. |
| 2021-06-25 19:57:59 | <Profpatsch> | there’s a tradeoff |
| 2021-06-25 19:58:20 | <Profpatsch> | open records can be good if you want forward-compatibility |
| 2021-06-25 20:01:17 | × | Morrow quits (~MorrowM_@147.161.13.193) (Ping timeout: 272 seconds) |
| 2021-06-25 20:01:18 | <dminuoso> | forward-compatibility is tough, if you dont even know the distance. If people start talking you to in a protocol that you dont adequately understand, and you just ignore fields that have semantic meaning, then this introduces subtle bugs. |
| 2021-06-25 20:01:40 | <dminuoso> | I'd rather have protocol versioned schemas, and then for each protocol version I supply different parsers for things |
| 2021-06-25 20:01:50 | <dminuoso> | There I can do all the massaging needed |
| 2021-06-25 20:02:40 | → | mc47 joins (~mc47@xmonad/TheMC47) |
| 2021-06-25 20:03:09 | <dminuoso> | Imagine if at some point you added a field "simulate :: Request -> Bool", if former versions simply ignore this field, then this will misbehave in disastrous ways. And it's difficult to even know you are never going to introduce such a field |
| 2021-06-25 20:03:17 | <dminuoso> | But it all depends on the use case I guess. |
| 2021-06-25 20:05:07 | <Profpatsch> | Well, you need to support all old semantics indefinitely |
| 2021-06-25 20:05:16 | × | derelict quits (~derelict@user/derelict) (Quit: WeeChat 3.2) |
| 2021-06-25 20:05:18 | <Profpatsch> | And introduce new symbols when you change semantics |
| 2021-06-25 20:05:24 | × | juhp quits (~juhp@128.106.188.66) (Ping timeout: 256 seconds) |
| 2021-06-25 20:05:37 | <Profpatsch> | instead of changing old ones. Which you can guarantee by having a more-or-less exhaustive test suite |
| 2021-06-25 20:05:45 | × | kuribas quits (~user@ptr-25vy0iacbcxiwpnsjuf.18120a2.ip6.access.telenet.be) (Quit: ERC (IRC client for Emacs 26.3)) |
| 2021-06-25 20:05:52 | <Profpatsch> | ofc there is always a trade-off |
| 2021-06-25 20:05:54 | fendor_ | is now known as fendor |
| 2021-06-25 20:06:12 | <dminuoso> | This is why everybody should version JSON stuff, perhaps even in a PVP/semver compatible way. |
| 2021-06-25 20:06:44 | → | juhp joins (~juhp@128.106.188.66) |
| 2021-06-25 20:07:29 | → | trcc joins (~trcc@2-104-60-169-cable.dk.customer.tdc.net) |
| 2021-06-25 20:07:42 | <Profpatsch> | I find https://stripe.com/blog/api-versioning intriguing |
| 2021-06-25 20:07:54 | <dminuoso> | Not versioning JSON content *inside* the same JSON is usually regretted |
| 2021-06-25 20:07:58 | <dminuoso> | Quickly |
| 2021-06-25 20:08:08 | <Profpatsch> | tl;dr they guarantee indefinite API stability for every client, and they render *backwards* from their current API to the old versions |
| 2021-06-25 20:08:27 | <Profpatsch> | on-the-fly backwards migration so to say |
| 2021-06-25 20:08:57 | <Profpatsch> | And since they must always write these backwards migrations for every change to the api, it keeps them honest about semantics I’d wager. |
| 2021-06-25 20:09:22 | <Profpatsch> | i.e. you can only add fields to records or remove cases from sum types |
| 2021-06-25 20:11:10 | × | raehik quits (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) (Ping timeout: 272 seconds) |
| 2021-06-25 20:11:19 | <dminuoso> | Profpatsch: I see. So each version gets data-migrations attached to them, such that if a client is pinned to an older version, that data is migrated upwards per-request? |
| 2021-06-25 20:11:35 | <dminuoso> | *i.e. that clients request data is migrated upwards. |
| 2021-06-25 20:11:57 | × | trcc quits (~trcc@2-104-60-169-cable.dk.customer.tdc.net) (Ping timeout: 244 seconds) |
| 2021-06-25 20:12:06 | × | _ht quits (~quassel@82-169-194-8.biz.kpn.net) (Remote host closed the connection) |
| 2021-06-25 20:12:26 | <dminuoso> | Profpatsch: So this is an interesting bit. Perhaps the question of "should unparsed fields be rejected" depends on the party. |
| 2021-06-25 20:12:46 | × | tromp quits (~textual@dhcp-077-249-230-040.chello.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2021-06-25 20:13:23 | <dminuoso> | If you control the API, then you should by all means reject unparsed fields for inbound requests. If you parse requests from someone elses API, then ignoring unparsed fields could less friction every time an API change is made. |
| 2021-06-25 20:14:12 | <dminuoso> | The former is important just to ensure you get exact semantics. Common mistake is when people prototype their libraries, and they make typos in field names. If this happened in an optional fields, then Id rather it error out than silently do ignore the typo'd field |
| 2021-06-25 20:14:40 | <Profpatsch> | dminuoso: right, client requests have to be forwards-migrated and responses backwards |
| 2021-06-25 20:14:51 | <dminuoso> | Sort of how nixos modules error out when setting an option that doesnt exist. It's way better than silently not activating the desired service. |
| 2021-06-25 20:14:53 | <Profpatsch> | but not the dual |
| 2021-06-25 20:15:02 | <dminuoso> | Right |
| 2021-06-25 20:15:39 | <Profpatsch> | dminuoso: regarding ignoring unknown fields, rich hickey has a good talk on how that benefits composability |
| 2021-06-25 20:16:08 | <dminuoso> | Do you have a name of the talk? |
| 2021-06-25 20:17:13 | <Profpatsch> | https://www.youtube.com/watch?v=2V1FtfBDsLU& |
| 2021-06-25 20:17:20 | <Profpatsch> | I *think* it was this one? |
| 2021-06-25 20:17:23 | <Profpatsch> | It |
| 2021-06-25 20:17:29 | <Profpatsch> | makes Haskell devs shudder :) |
| 2021-06-25 20:18:01 | → | raehik joins (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) |
| 2021-06-25 20:18:20 | → | teaSlurper joins (~chris@81.96.113.213) |
| 2021-06-25 20:18:52 | <dminuoso> | Yes. The amount of static white noise makes me shudder. |
| 2021-06-25 20:19:32 | <Profpatsch> | dminuoso: from here as far as I can see https://www.youtube.com/watch?v=2V1FtfBDsLU&t=2267s |
| 2021-06-25 20:19:32 | × | azeem quits (~azeem@dynamic-adsl-94-34-50-190.clienti.tiscali.it) (Read error: Connection reset by peer) |
| 2021-06-25 20:19:37 | → | ajb joins (~ajb@cupid.whatbox.ca) |
| 2021-06-25 20:20:32 | × | dunkeln_ quits (~dunkeln@188.71.193.140) (Ping timeout: 268 seconds) |
| 2021-06-25 20:20:46 | × | xff0x quits (~xff0x@2001:1a81:52c9:c400:8a43:254c:24d1:74a5) (Ping timeout: 246 seconds) |
| 2021-06-25 20:20:48 | → | azeem joins (~azeem@dynamic-adsl-94-34-50-190.clienti.tiscali.it) |
| 2021-06-25 20:21:43 | → | xff0x joins (~xff0x@2001:1a81:52c9:c400:7297:5fed:23fc:a105) |
| 2021-06-25 20:23:50 | × | machinedgod quits (~machinedg@135-23-192-217.cpe.pppoe.ca) (Ping timeout: 244 seconds) |
| 2021-06-25 20:25:50 | × | GIANTWORLDKEEPER quits (~pjetcetal@2.95.227.207) (Remote host closed the connection) |
| 2021-06-25 20:31:58 | <c_wraith> | Is there any common type that's equivalent to Maybe but with the connotation that a value being present is a failure? |
| 2021-06-25 20:33:57 | <maerwald> | Either |
| 2021-06-25 20:34:06 | <c_wraith> | Either is too big |
All times are in UTC.