Logs: freenode/#haskell
| 2020-11-10 13:45:06 | <dminuoso> | right |
| 2020-11-10 13:45:07 | → | kuribas joins (~user@ptr-25vy0i8gy1ukj7bjvez.18120a2.ip6.access.telenet.be) |
| 2020-11-10 13:45:30 | hackage | lorentz 0.7.1 - EDSL for the Michelson Language https://hackage.haskell.org/package/lorentz-0.7.1 (gromak) |
| 2020-11-10 13:45:34 | → | raehik joins (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) |
| 2020-11-10 13:46:50 | → | jonatanb joins (~jonatanb@83.24.9.26.ipv4.supernova.orange.pl) |
| 2020-11-10 13:47:26 | × | drbean quits (~drbean@TC210-63-209-46.static.apol.com.tw) (Ping timeout: 264 seconds) |
| 2020-11-10 13:47:39 | <maerwald> | well, start by telling me how I get a build plan with stack |
| 2020-11-10 13:48:00 | <maerwald> | I actually need that. One reason would be to compare its build-plan with a cabal generated one |
| 2020-11-10 13:50:47 | → | geekosaur74 joins (82659a09@host154-009.vpn.uakron.edu) |
| 2020-11-10 13:51:05 | × | jonatanb quits (~jonatanb@83.24.9.26.ipv4.supernova.orange.pl) (Ping timeout: 240 seconds) |
| 2020-11-10 13:51:08 | × | noctux quits (~noctux@unaffiliated/noctux) (Remote host closed the connection) |
| 2020-11-10 13:51:12 | → | avdb joins (~avdb@ip-213-49-61-163.dsl.scarlet.be) |
| 2020-11-10 13:51:28 | → | Stanley00 joins (~stanley00@unaffiliated/stanley00) |
| 2020-11-10 13:52:59 | × | geekosaur quits (82659a09@host154-009.vpn.uakron.edu) (Ping timeout: 245 seconds) |
| 2020-11-10 13:53:18 | <dminuoso> | maerwald: hekkaidekapus linked a tool above to do that |
| 2020-11-10 13:53:29 | <dminuoso> | or.. |
| 2020-11-10 13:53:31 | <dminuoso> | no mmm |
| 2020-11-10 13:55:34 | <maerwald> | dminuoso: yes, I maintain that. But you still have no guarantee that you have the exact same build plan |
| 2020-11-10 13:55:54 | <maerwald> | e.g. one problem is that cabal may treat git repos a little different |
| 2020-11-10 13:56:20 | × | Stanley00 quits (~stanley00@unaffiliated/stanley00) (Ping timeout: 265 seconds) |
| 2020-11-10 13:57:33 | × | britva quits (~britva@31-10-157-156.cgn.dynamic.upc.ch) (Quit: This computer has gone to sleep) |
| 2020-11-10 13:57:41 | <hekkaidekapus> | In short, it would be good if there were a stack-lib published somewhere. |
| 2020-11-10 13:58:01 | <maerwald> | that too |
| 2020-11-10 14:02:23 | → | britva joins (~britva@31-10-157-156.cgn.dynamic.upc.ch) |
| 2020-11-10 14:02:36 | → | hyperisco joins (~hyperisco@d192-186-117-226.static.comm.cgocable.net) |
| 2020-11-10 14:03:13 | → | geekosaur joins (82659a09@host154-009.vpn.uakron.edu) |
| 2020-11-10 14:03:18 | <maerwald> | and if stack and cabal can agree on an API :) |
| 2020-11-10 14:03:25 | <maerwald> | (lolo) |
| 2020-11-10 14:04:21 | → | xenon- joins (~bc8165ab@217.29.117.252) |
| 2020-11-10 14:05:20 | <tomsmeding> | microsoft attempted to make windows and linux agree on an API |
| 2020-11-10 14:05:30 | hackage | purescheme-wai-routing-core 0.1.1.0 - Simple Routing functions for Wai Applications https://hackage.haskell.org/package/purescheme-wai-routing-core-0.1.1.0 (frincon) |
| 2020-11-10 14:05:37 | <hekkaidekapus> | You mean, update the Cabal spec? |
| 2020-11-10 14:05:44 | <tomsmeding> | the thought may not be as ridiculous as it sounds |
| 2020-11-10 14:05:48 | <xenon-> | hi. I'm trying to use aeson to reason third party json file, and I'm getting key not present error, because fields start with upper case letter, unlike fields in haskell object. how can I get around this? |
| 2020-11-10 14:05:54 | × | geekosaur74 quits (82659a09@host154-009.vpn.uakron.edu) (Ping timeout: 245 seconds) |
| 2020-11-10 14:06:15 | <xenon-> | s/reason/read |
| 2020-11-10 14:06:17 | <dminuoso> | xenon-: write out the instance manually |
| 2020-11-10 14:06:33 | → | lawr3nce joins (~lawr3nce@gateway/tor-sasl/lawr3nce) |
| 2020-11-10 14:06:43 | <xenon-> | that is the only way? |
| 2020-11-10 14:07:18 | <dminuoso> | Its possible you can tweak the generic options |
| 2020-11-10 14:08:06 | <xenon-> | did some googling while asking the question.. this seems promising. http://hackage.haskell.org/package/aeson-casing-0.2.0.0/docs/Data-Aeson-Casing.html |
| 2020-11-10 14:08:12 | × | watt282 quits (~watt282@124.123.107.46) (Ping timeout: 256 seconds) |
| 2020-11-10 14:08:16 | <dminuoso> | xenon-: Refer to https://hackage.haskell.org/package/aeson-1.5.4.1/docs/Data-Aeson.html#t:Options |
| 2020-11-10 14:08:42 | <dminuoso> | xenon-: honestly, Id just write out the instance by hand |
| 2020-11-10 14:09:02 | <dminuoso> | It's doesnt take much effort, and it makes this contract explicit |
| 2020-11-10 14:09:25 | <dminuoso> | But, you can override fieldLabelModifier for the generic json parser options |
| 2020-11-10 14:09:27 | <dminuoso> | To do what you want |
| 2020-11-10 14:10:12 | <dminuoso> | There's a few reasons to do manual implementatoins |
| 2020-11-10 14:10:35 | <dminuoso> | 1) Multiple versions. You cant do this trivially with the typeclass+generics approach, without a lot of inelegance |
| 2020-11-10 14:11:10 | <dminuoso> | 2) It lets you decouple your haskell code from external representation (and codify this interface with Haskell, rather than implicit generics) |
| 2020-11-10 14:12:05 | → | elliott_ joins (~elliott_@pool-108-51-141-12.washdc.fios.verizon.net) |
| 2020-11-10 14:13:02 | <xenon-> | I'm using older aeson version, there's no Data.Aeson.Casing |
| 2020-11-10 14:13:03 | <dminuoso> | The latter can be done if you have separate data types for just the external representation, but this works better if you're the one defining the JSON API, rather than trying to conform to some outside format |
| 2020-11-10 14:13:15 | <xenon-> | I'll try that option, if that fails I'll just write manual instance |
| 2020-11-10 14:13:16 | → | jakob_ joins (~textual@p200300f49f162200cdda70bf42567477.dip0.t-ipconnect.de) |
| 2020-11-10 14:13:40 | → | heatsink joins (~heatsink@107-136-5-69.lightspeed.sntcca.sbcglobal.net) |
| 2020-11-10 14:14:09 | × | andreas31 quits (~andreas@gateway/tor-sasl/andreas303) (Remote host closed the connection) |
| 2020-11-10 14:14:14 | <tomsmeding> | xenon-: side note: "there's no Data.Aeson.Casing" might be because that's in a different package (aeson-casing)? |
| 2020-11-10 14:14:55 | × | jonathanx quits (~jonathan@dyn-8-sc.cdg.chalmers.se) (Remote host closed the connection) |
| 2020-11-10 14:15:12 | <lortabac> | dminuoso: IMHO both versioning and external representation should be dealt with by defining multiple data types |
| 2020-11-10 14:15:32 | <xenon-> | tomsmeding, oh |
| 2020-11-10 14:16:03 | <lortabac> | encoding any logic into the deserialization part means doing Python in Haskell (with worse syntax) |
| 2020-11-10 14:16:04 | <tomsmeding> | though please heed dminuoso's recommendations :p |
| 2020-11-10 14:17:01 | hackage | purescheme-wai-routing-core 0.1.2.0 - Simple Routing functions for Wai Applications https://hackage.haskell.org/package/purescheme-wai-routing-core-0.1.2.0 (frincon) |
| 2020-11-10 14:17:14 | <dminuoso> | lortabac: Im willing to argue that this is incorrect. In case of python style code, you usually implicitly decode into Python structures, but it's still not really de-serialized. |
| 2020-11-10 14:17:16 | → | andreas31 joins (~andreas@gateway/tor-sasl/andreas303) |
| 2020-11-10 14:17:38 | <dminuoso> | Either you have an additional layer where you transform your "jsonDeserializedIntoDict" data into some domain specific objects with error handling |
| 2020-11-10 14:17:57 | <dminuoso> | Or, which is more common and much worse, you just use this the basis of control flow |
| 2020-11-10 14:18:02 | <dminuoso> | Whatever the user specifies |
| 2020-11-10 14:18:15 | → | ensyde joins (~ensyde@99-185-235-117.lightspeed.chrlnc.sbcglobal.net) |
| 2020-11-10 14:18:24 | × | heatsink quits (~heatsink@107-136-5-69.lightspeed.sntcca.sbcglobal.net) (Ping timeout: 256 seconds) |
| 2020-11-10 14:18:34 | <dminuoso> | We're better off in Haskell because we can actually meaningfully parse the data into domain specific data types and have error handling. In Python you get "whatever" |
| 2020-11-10 14:18:55 | × | ensyde quits (~ensyde@99-185-235-117.lightspeed.chrlnc.sbcglobal.net) (Read error: Connection reset by peer) |
| 2020-11-10 14:19:26 | <lortabac> | dminuoso: what I meant is: it is better to keep the JSON instances straightforward and define one data type for each version (or each layer of the application) |
| 2020-11-10 14:19:39 | <dminuoso> | JSON is not a protocol format, the act of "destructuring the payload" needs to be done either way. With Python you just do it on dicts/lists/numbers/whatever, in Haskell you do it on `data Value = ...` |
| 2020-11-10 14:19:40 | → | elfets joins (~elfets@ip-37-201-23-96.hsi13.unitymediagroup.de) |
| 2020-11-10 14:19:41 | <lortabac> | rather than encoding versioning logic into the JSON instances |
| 2020-11-10 14:19:43 | <dminuoso> | Ah |
| 2020-11-10 14:19:48 | <cohn> | speaking of DSLs, does Haskell have a good tokenizer library? |
| 2020-11-10 14:19:57 | <dminuoso> | cohn: attoparsec/megaparsec? |
| 2020-11-10 14:20:37 | <dminuoso> | Do you need it streaming? |
| 2020-11-10 14:20:43 | <xenon-> | tomsmeding, thanks, that worked! I'll prolong learning how to write custom instance when I need it |
| 2020-11-10 14:21:30 | hackage | purescheme-wai-routing-core 0.1.3.0 - Simple Routing functions for Wai Applications https://hackage.haskell.org/package/purescheme-wai-routing-core-0.1.3.0 (frincon) |
| 2020-11-10 14:21:52 | → | coot joins (~coot@37.30.49.253.nat.umts.dynamic.t-mobile.pl) |
| 2020-11-10 14:22:54 | <lortabac> | dminuoso: I prefer implementing 'UserV1 -> UserV2' or 'DBUser -> APIUser' rather than 'Value -> Value' |
| 2020-11-10 14:23:17 | <dminuoso> | lortabac: Not quite sure what you mean by that |
| 2020-11-10 14:23:26 | <cohn> | dminuoso: nah, just curious |
| 2020-11-10 14:24:03 | <dminuoso> | cohn: also, there's alex if you want something like flex |
| 2020-11-10 14:24:44 | <cohn> | oh nice, thanks dminuoso! |
| 2020-11-10 14:26:01 | → | eliocrat joins (~feliocrat@95.70.185.239) |
| 2020-11-10 14:26:28 | → | Feuermagier joins (~Feuermagi@213.178.26.41) |
| 2020-11-10 14:30:21 | <lortabac> | dminuoso: you gave two reasons not to use aeson's generic helpers, I'm saying it doesn't matter because deserialization is not the best place to achieve versioning or decoupling |
| 2020-11-10 14:30:21 | × | knupfer quits (~Thunderbi@dynamic-046-114-147-079.46.114.pool.telefonica.de) (Read error: Connection reset by peer) |
| 2020-11-10 14:31:26 | <dminuoso> | lortabac: It depends on the details, I guess. If you have just represntation format changes, then this is better done in code than extra data types. |
| 2020-11-10 14:33:32 | <lortabac> | I don't know, generic aeson instances work in 95% of cases for me, if a field name changes I generally change it in the data type |
| 2020-11-10 14:35:45 | → | tanksgiving joins (b2eb9397@178235147151.dynamic-3-poz-k-0-1-0.vectranet.pl) |
| 2020-11-10 14:36:19 | × | sfvm quits (~sfvm@37.228.215.148) (Quit: off to the basement, mixing up the medicine) |
| 2020-11-10 14:36:35 | <tanksgiving> | hi |
| 2020-11-10 14:36:58 | <dminuoso> | Amusing nickname. :> |
| 2020-11-10 14:37:06 | <dminuoso> | Hi. |
All times are in UTC.