Logs: freenode/#haskell
| 2020-10-25 22:08:55 | <koz_> | Because when you derive Generic, you gain the ability to both _read_ the generic structure, but also create new ones and magic it into the type, provided it type checks. |
| 2020-10-25 22:09:05 | <koz_> | And you can't opt out of the latter in _any way whatsoever_. |
| 2020-10-25 22:09:23 | → | Varis joins (~Tadas@unaffiliated/varis) |
| 2020-10-25 22:09:23 | → | thir joins (~thir@p200300f27f2523003c23ef77843b8858.dip0.t-ipconnect.de) |
| 2020-10-25 22:09:58 | → | taurux joins (~taurux@net-93-144-108-10.cust.dsl.teletu.it) |
| 2020-10-25 22:10:20 | <ddellacosta> | koz_: okay, I think I'm starting to understand what you mean, but in the end isn't it a reasonable tradeoff to make if you're using it in an application context? Presumably you're able to understand if it would break any invariants you wish to avoid breaking |
| 2020-10-25 22:10:28 | × | shatriff quits (~vitaliish@176.52.219.10) (Remote host closed the connection) |
| 2020-10-25 22:10:29 | × | dbmikus quits (~dbmikus@cpe-76-167-86-219.natsow.res.rr.com) (Ping timeout: 260 seconds) |
| 2020-10-25 22:10:43 | <koz_> | Uhh, I don't get how that even makes sense. |
| 2020-10-25 22:11:00 | → | shatriff joins (~vitaliish@176.52.219.10) |
| 2020-10-25 22:11:02 | <ddellacosta> | well, maybe I don't understand your point yet then |
| 2020-10-25 22:11:16 | <koz_> | You have a self-balancing binary tree. Its invariants can only be preserved by hiding its representation and not allowing people to construct one arbitrarily. Generic _exposes_ that representation and allows _anyone_ to construct one arbitrarily. |
| 2020-10-25 22:11:21 | <koz_> | And there is _nothing_ you can do about it. |
| 2020-10-25 22:11:56 | <koz_> | Once you derive Generic, any invariant over your data structure that is _not_ imposed by the type system is gone, and _anyone_ can violate said invariants. |
| 2020-10-25 22:12:08 | <koz_> | It doesn't matter if it's 'an application context' or not. |
| 2020-10-25 22:12:29 | <koz_> | If I can import your type, I can get its Generic instance and your invariants are screwed if I want them to be, end of story. |
| 2020-10-25 22:13:17 | <koz_> | Not 'if I can import your type's data constructors'. Not 'if I can import your type's smart constructors'. If I can import your type _as such_. |
| 2020-10-25 22:13:35 | × | Katarushisu quits (~Katarushi@cpc149712-finc20-2-0-cust535.4-2.cable.virginm.net) (Ping timeout: 258 seconds) |
| 2020-10-25 22:13:58 | <jbox> | is stack or cabal the recommended tool? |
| 2020-10-25 22:14:10 | <koz_> | jbox: Do you _want_ to start a religious argument LOL? |
| 2020-10-25 22:14:17 | <koz_> | More seriously, it depends on who you ask. |
| 2020-10-25 22:14:17 | × | thir quits (~thir@p200300f27f2523003c23ef77843b8858.dip0.t-ipconnect.de) (Ping timeout: 260 seconds) |
| 2020-10-25 22:14:24 | <jbox> | oh, sorry, I didn't know that was a sensitive topic haha |
| 2020-10-25 22:14:26 | <koz_> | I certainly have an opinion, everyone else does too. |
| 2020-10-25 22:14:30 | <jbox> | Is it like npm vs yarn? |
| 2020-10-25 22:14:30 | → | geowiesnot joins (~user@87-89-181-157.abo.bbox.fr) |
| 2020-10-25 22:14:40 | <koz_> | jbox: I wouldn't know because I'm wilfully ignorant of anything JS. |
| 2020-10-25 22:14:47 | <jbox> | me too tbh haha |
| 2020-10-25 22:14:50 | <ddellacosta> | koz_: I suppose what I meant was, one could decide not to derive generic on a Map, for example |
| 2020-10-25 22:14:58 | <koz_> | ddellacosta: OK, sure, I agree. |
| 2020-10-25 22:15:10 | <koz_> | But if you want to use generic-lens for your type, you have to derive Generic. |
| 2020-10-25 22:15:20 | → | justanotheruser joins (~justanoth@unaffiliated/justanotheruser) |
| 2020-10-25 22:15:23 | <ddellacosta> | I guess I'm not sure if you're suggesting that Generics are generally bad, or just in certain contexts? |
| 2020-10-25 22:15:23 | <koz_> | Ditto for automagic Hashable, ditto automagic FromJSON/ToJSON, etc etc etc. |
| 2020-10-25 22:15:53 | <koz_> | I'm suggesting that once you derive Generic you can't have any invariants on that type that the type system itself does not enforce. |
| 2020-10-25 22:16:10 | <koz_> | Therefore, for any such type, anythign autoderivable via Generic basically becomes 'you give up your internal invariants lol'. |
| 2020-10-25 22:16:24 | <ddellacosta> | koz_: okay, I guess I have to think harder about the implications of that. I'm mostly considering my experience of using generics in various contexts and finding it pretty nice |
| 2020-10-25 22:16:41 | <koz_> | ddellacosta: YMMV. If the type already exposes its data constructors it makes no difference. |
| 2020-10-25 22:16:49 | <koz_> | If it _doesn't_, then it could be an issue. |
| 2020-10-25 22:17:29 | <ddellacosta> | in any case, I think I'm bailing on generic-lens for now lol |
| 2020-10-25 22:17:49 | <koz_> | The issues behind generic-lens are mostly 'its type errors are an ungodly slurry'. |
| 2020-10-25 22:18:16 | → | ahmr88 joins (~ahmr88@cpc85006-haye22-2-0-cust131.17-4.cable.virginm.net) |
| 2020-10-25 22:18:16 | <jbox> | I was told that vim (coc.nvim) wasn't detecting the XMonad library because it wasn't in my global environment. Should I have installed xmonad with ghcup or something? I installed it with pacman (the arch linux package manager) |
| 2020-10-25 22:18:21 | <koz_> | Speaking from having to understand them on numerous occasions, for a codebase I didn't write, when it was causing issues due to a _minor_ version lift of generic-lens. |
| 2020-10-25 22:18:25 | <ddellacosta> | yeah I can't really justify adding it to this project at this point, I'm just being lazy because I know I can do what I want trivially with a traversal |
| 2020-10-25 22:19:05 | × | ahmr88 quits (~ahmr88@cpc85006-haye22-2-0-cust131.17-4.cable.virginm.net) (Remote host closed the connection) |
| 2020-10-25 22:20:02 | → | gattytto joins (b33e397e@179.62.57.126) |
| 2020-10-25 22:20:10 | <koz_> | (I ended up just pinning to the lower version because otherwise it was impossible) |
| 2020-10-25 22:20:22 | <gattytto> | good evening :waves: |
| 2020-10-25 22:20:30 | <koz_> | gattytto: Sup? |
| 2020-10-25 22:20:34 | <ddellacosta> | seems reasonable |
| 2020-10-25 22:21:50 | <gattytto> | I came yesterday with questions about limiting memory to haskell builds. It seems like the following: cabal build -j1 --ghc-options=" +RTS -M3000M -RTS" ... works but the same using stack doesn't and triggers a "out of memory" error |
| 2020-10-25 22:21:54 | <gattytto> | is this expectable? |
| 2020-10-25 22:22:06 | × | Ariakenom quits (~Ariakenom@h-82-196-111-63.NA.cust.bahnhof.se) (Read error: Connection reset by peer) |
| 2020-10-25 22:22:23 | → | bitmapper joins (uid464869@gateway/web/irccloud.com/x-yancvgiiwbprfywu) |
| 2020-10-25 22:22:37 | <gattytto> | this is the project I'm testing with: github/gattytto/example-servant-minimal |
| 2020-10-25 22:23:13 | <gattytto> | my usecase is a web ide with a pre-packed dockerfile (based in official haskell's) that contains ghc 8.10.1 so I forked and touched the stack.yaml to add the extra-deps to it |
| 2020-10-25 22:23:25 | × | __monty__ quits (~toonn@unaffiliated/toonn) (Quit: leaving) |
| 2020-10-25 22:23:26 | <gattytto> | which are a lot and specifically aeson produces the out of memory |
| 2020-10-25 22:23:47 | <koz_> | aeson would, honestly. |
| 2020-10-25 22:24:21 | <koz_> | gattytto: You might be able to avoid most of the extra-deps if you use a nightly. |
| 2020-10-25 22:24:28 | <koz_> | I assume you're on an LTS snapshot? |
| 2020-10-25 22:24:56 | <gattytto> | I'm using ghc-8.10.1 as resolver and system-ghc is the same, using 8.10.1-buster as the base image for my env |
| 2020-10-25 22:25:13 | <koz_> | gattytto: ghc-8.10.1 is not a 'resolver' in the stack sense. |
| 2020-10-25 22:25:20 | <koz_> | What's the 'resolver' field in your stack.yaml say? |
| 2020-10-25 22:25:31 | <gattytto> | resolver: ghc-8.10.1 |
| 2020-10-25 22:25:39 | <koz_> | ... huh |
| 2020-10-25 22:25:45 | <koz_> | That's a thing? |
| 2020-10-25 22:25:58 | <gattytto> | yes it prevents it from re-downloading some other version of ghc to build |
| 2020-10-25 22:26:05 | × | mimi_vx quits (~mimi@tulipan.habr.nat.praha12.net) (Ping timeout: 240 seconds) |
| 2020-10-25 22:26:05 | → | olligobber joins (olligobber@gateway/vpn/privateinternetaccess/olligobber) |
| 2020-10-25 22:26:06 | <gattytto> | and uses system's one instead |
| 2020-10-25 22:26:23 | <koz_> | OK, well, then you might wanna wait for a stack expert. |
| 2020-10-25 22:26:32 | <gattytto> | first time I try to build the forked project (probably made with 8.6.x) it starts recommending extra-deps |
| 2020-10-25 22:26:51 | <gattytto> | so I add them all to extra-deps in stack.yaml, which ends up being around 98 of them xD |
| 2020-10-25 22:27:15 | <koz_> | Ah, so it's just 'FPComplete never update any of their templates', lol. |
| 2020-10-25 22:27:27 | × | geowiesnot quits (~user@87-89-181-157.abo.bbox.fr) (Ping timeout: 260 seconds) |
| 2020-10-25 22:27:46 | <gattytto> | after a while using the mentioned cabal build line, I get: "Linking /projects/src/github.com/gattytto/example-servant-minimal/dist-newstyle/build/x86_64-linux/ghc-8.10.1/example-servant-minimal-0.0.0/x/example-servant-minimal/build/example-servant-minimal/example-servant-minimal ..." |
| 2020-10-25 22:27:57 | <gattytto> | I'm guessing cabal made it |
| 2020-10-25 22:28:34 | <gattytto> | but issuing: stack build -j1 --ghc-options=" +RTS -M3000M -RTS" ... triggers the oom |
| 2020-10-25 22:28:41 | × | hyiltiz quits (~quassel@unaffiliated/hyiltiz) (Ping timeout: 260 seconds) |
| 2020-10-25 22:29:13 | <gattytto> | so my question is if either stack isn't passing the ghc options or ghc is doing stuff differently when called from cabal than when called from stack |
| 2020-10-25 22:31:24 | × | nbloomf quits (~nbloomf@2600:1700:ad14:3020:e9e0:8366:ee4d:bc13) (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 2020-10-25 22:32:37 | → | mimi_vx joins (~mimi@2a01:490:16:1026:c3:872f:6511:b2da) |
| 2020-10-25 22:37:22 | × | mimi_vx quits (~mimi@2a01:490:16:1026:c3:872f:6511:b2da) (Ping timeout: 260 seconds) |
| 2020-10-25 22:37:59 | × | johnw quits (~johnw@haskell/developer/johnw) (Quit: ZNC - http://znc.in) |
| 2020-10-25 22:38:27 | → | merijn joins (~merijn@83-160-49-249.ip.xs4all.nl) |
| 2020-10-25 22:38:45 | × | Lord_of_Life quits (~Lord@unaffiliated/lord-of-life/x-0885362) (Read error: Connection reset by peer) |
| 2020-10-25 22:39:49 | → | Lord_of_Life joins (~Lord@46.217.216.204) |
| 2020-10-25 22:39:50 | × | Lord_of_Life quits (~Lord@46.217.216.204) (Changing host) |
| 2020-10-25 22:39:50 | → | Lord_of_Life joins (~Lord@unaffiliated/lord-of-life/x-0885362) |
| 2020-10-25 22:41:44 | → | elfets joins (~elfets@ip-37-201-23-96.hsi13.unitymediagroup.de) |
| 2020-10-25 22:42:28 | hackage | persistent-test 2.0.3.3 - Tests for Persistent https://hackage.haskell.org/package/persistent-test-2.0.3.3 (MaxGabriel) |
| 2020-10-25 22:45:27 | × | alp quits (~alp@2a01:e0a:58b:4920:784c:efeb:64e7:4755) (Ping timeout: 272 seconds) |
| 2020-10-25 22:45:34 | × | acarrico quits (~acarrico@dhcp-68-142-39-249.greenmountainaccess.net) (Ping timeout: 265 seconds) |
| 2020-10-25 22:48:05 | × | p8m quits (p8m@gateway/vpn/protonvpn/p8m) (Ping timeout: 240 seconds) |
| 2020-10-25 22:50:38 | × | xerox_ quits (~xerox@unaffiliated/xerox) (Ping timeout: 272 seconds) |
| 2020-10-25 22:53:17 | <_deepfire> | What's the catch about mixing unlifted types with regular types -- like f.e. using unboxed tuples as values in Data.Map.Map's? |
| 2020-10-25 22:53:43 | <_deepfire> | Is it even possible? |
| 2020-10-25 22:53:52 | <monsterchrom> | \∩/ Larry Paulson's book "ML for the working programmer" contains this sentence "This sort of things is easier in Haskell" |
All times are in UTC.