Logs: liberachat/#haskell
| 2021-06-13 19:12:45 | × | hseg quits (~gesh@185.120.126.41) (Quit: WeeChat 3.1) |
| 2021-06-13 19:12:55 | <shapr> | I need to update that example file for hls 1.1 |
| 2021-06-13 19:13:09 | × | waleee quits (~waleee@2001:9b0:216:8200:d457:9189:7843:1dbd) (Ping timeout: 268 seconds) |
| 2021-06-13 19:13:19 | <shapr> | cdsmith and I were pairing on something yesterday and I got to demonstrate some of the amazing wingman features. |
| 2021-06-13 19:13:31 | → | polyphem joins (~polyphem@2a02:810d:640:776c:12c4:e67d:3560:5ad7) |
| 2021-06-13 19:13:41 | <dminuoso> | jumper149: So GHC changed the RankNTypes type inference that this would not happen again (avoiding implicitly changing program semantics, and simplifying implementation) - but that means if you still want these things that automatically inferred, you have to do this eta-expansion explicitly (and thus there's no change in semantics anymore) |
| 2021-06-13 19:14:11 | <shapr> | anyway, I'm slowly working my way through the hls plugin tutorial, happily a code lens is the first example. |
| 2021-06-13 19:14:23 | × | sm2n quits (~sm2n@user/sm2n) (Ping timeout: 268 seconds) |
| 2021-06-13 19:14:28 | → | waleee joins (~waleee@h-98-128-228-119.NA.cust.bahnhof.se) |
| 2021-06-13 19:14:29 | <shapr> | my mvp is "show all enabled language pragmas" |
| 2021-06-13 19:14:53 | <dminuoso> | I admit, this is all very handwaving. |
| 2021-06-13 19:15:41 | <shapr> | I have a bunch of other plugin/feature ideas, like "rewrite all imports to implicit on load, rewrite all imports to explicit on save" |
| 2021-06-13 19:15:43 | <maerwald> | shapr: I wanted to do a code lens that shows function arity on hover (bc that is important for inlining and can be relevant for memory leaks as well)0000000 |
| 2021-06-13 19:15:55 | <shapr> | maerwald: oh that's a cool idea! |
| 2021-06-13 19:15:56 | <maerwald> | oops, my qmk config needs fixing |
| 2021-06-13 19:16:34 | <jumper149> | dminuoso: The `undefined` example and the fact that it's a change to the type inference with RankNTypes is already quite a bit eye-opening to me :) |
| 2021-06-13 19:17:57 | <dminuoso> | jumper149: type system wise, it was exactly 4 parts (covariante of function types, contravariance of function types, deep skolemisation and deep instanstation) that caused this implicit eta-extension. In the GHC proposal these things were just yanked without replacement. |
| 2021-06-13 19:18:11 | <shapr> | another idea I have is to use the "find references" feature to look only in the thisproject:test section to run tests that reference a function after the file is saved, and add some kind of syntax highlighting to show the test status. |
| 2021-06-13 19:18:20 | <dminuoso> | It's just that I cant match what these exactly mean or when GHC would use them. You'd have to read the paper I cited earlier. |
| 2021-06-13 19:19:16 | × | dispater quits (~dispater@mail.brprice.uk) (Quit: ZNC 1.8.1 - https://znc.in) |
| 2021-06-13 19:19:38 | × | kayprish quits (~kayprish@cable-188-2-229-172.dynamic.sbb.rs) (Quit: leaving) |
| 2021-06-13 19:19:39 | → | dispater joins (~dispater@user/brprice) |
| 2021-06-13 19:19:46 | <maerwald> | shapr: I'd want it for right-click->run-tests... "on save" might be a bit excessive, depending on the tests |
| 2021-06-13 19:19:53 | → | kayprish joins (~kayprish@cable-188-2-229-172.dynamic.sbb.rs) |
| 2021-06-13 19:20:09 | × | kayprish quits (~kayprish@cable-188-2-229-172.dynamic.sbb.rs) (Client Quit) |
| 2021-06-13 19:20:24 | → | kayprish joins (~kayprish@cable-188-2-229-172.dynamic.sbb.rs) |
| 2021-06-13 19:20:31 | <maerwald> | I think some IDEs have visual buttons for "you can run a test here" |
| 2021-06-13 19:20:36 | × | kayprish quits (~kayprish@cable-188-2-229-172.dynamic.sbb.rs) (Client Quit) |
| 2021-06-13 19:20:38 | <maerwald> | not sure if that's integratable with hls |
| 2021-06-13 19:21:08 | <dminuoso> | jumper149: Luckily, all of this means: Without contra/covariance of function types, deep skolemisation and instanation - you can still make all programs type check if you apply the eta-extension manually in the exact place that GHC would have done it implicitly. Because once you eta-expand, you dont need these 4 things anyhow. |
| 2021-06-13 19:21:19 | <maerwald> | first, you'd need *file locations* that can run tests, I guess |
| 2021-06-13 19:21:22 | × | dispater quits (~dispater@user/brprice) (Client Quit) |
| 2021-06-13 19:21:43 | → | dispater joins (~dispater@user/brprice) |
| 2021-06-13 19:21:43 | <maerwald> | and then a way to tell HLS: "run test for this file location" |
| 2021-06-13 19:22:18 | esclear | is now known as esclear[m] |
| 2021-06-13 19:22:36 | <maerwald> | this might very well be outside of LSP protocol scope... |
| 2021-06-13 19:22:45 | esclear[m] | is now known as esclear[i] |
| 2021-06-13 19:22:58 | <maerwald> | so clients would need to support it manually |
| 2021-06-13 19:23:36 | <janus> | when was (<>) added to prelude? i am having little log googling it |
| 2021-06-13 19:24:16 | <janus> | *luck |
| 2021-06-13 19:24:43 | <Clint> | was it part of AMP? |
| 2021-06-13 19:24:48 | <janus> | the ghc wiki says it was added to base in ghc 8, but that doesn't mean it went directly into the prelude, i imagine |
| 2021-06-13 19:24:50 | <davean> | https://hackage.haskell.org/package/base-4.15.0.0/changelog see? |
| 2021-06-13 19:25:00 | <davean> | Theres a changelog that lists this specificly |
| 2021-06-13 19:25:10 | <janus> | aaah right! i thought it would be older |
| 2021-06-13 19:25:30 | <janus> | wait, it says 4.11 from March 2018. so it is quite old |
| 2021-06-13 19:25:37 | × | dispater quits (~dispater@user/brprice) (Client Quit) |
| 2021-06-13 19:25:55 | → | kayprish joins (~kayprish@cable-188-2-229-172.dynamic.sbb.rs) |
| 2021-06-13 19:25:55 | <janus> | weird how i am just getting this error now with ghc 9 |
| 2021-06-13 19:26:07 | <maerwald> | means you're getting older as well |
| 2021-06-13 19:26:58 | → | dispater joins (~dispater@user/brprice) |
| 2021-06-13 19:29:13 | <shapr> | maerwald: it'd be interesting to try |
| 2021-06-13 19:29:21 | <shapr> | maerwald: certainly blog post worthy |
| 2021-06-13 19:29:32 | <shapr> | I still don't understand enough lsp details to know what might not work |
| 2021-06-13 19:29:55 | <maerwald> | there are many things where you need to go beyond lsp protocol |
| 2021-06-13 19:30:06 | <maerwald> | e.g. "type of expression" isn't currently supported by the protocol |
| 2021-06-13 19:30:11 | <maerwald> | but we really want it, right? |
| 2021-06-13 19:30:43 | → | lavaman joins (~lavaman@98.38.249.169) |
| 2021-06-13 19:31:10 | <maerwald> | https://github.com/microsoft/language-server-protocol/issues/377 |
| 2021-06-13 19:31:35 | × | xsperry quits (~as@user/xsperry) (Remote host closed the connection) |
| 2021-06-13 19:32:28 | → | xsperry joins (~as@user/xsperry) |
| 2021-06-13 19:33:03 | <maerwald> | I think the main thing would be: make it work in VSCode |
| 2021-06-13 19:33:43 | <shapr> | I would certainly want to be able to select part of my buffer and get the type of that selection |
| 2021-06-13 19:34:08 | <shapr> | I do that manually by factoring out that chunk to its own name and looking at that. |
| 2021-06-13 19:34:27 | <shapr> | but most people I've seen try to hover over the end parentheses to get the type of the parens. |
| 2021-06-13 19:34:38 | <maerwald> | right, because type computation is hard... I might know what `fmap` is, but not `fmap . fmap . fmap . fmap` :) |
| 2021-06-13 19:35:29 | <shapr> | yeah, I have that question often |
| 2021-06-13 19:36:57 | × | kayprish quits (~kayprish@cable-188-2-229-172.dynamic.sbb.rs) (Quit: Lost terminal) |
| 2021-06-13 19:37:27 | <shapr> | I like that so many things in Haskell are compositional, I just wish laziness weren't the big exception |
| 2021-06-13 19:39:32 | × | alanz__ quits (~user@host86-135-160-135.range86-135.btcentralplus.com) (Remote host closed the connection) |
| 2021-06-13 19:40:27 | <maerwald> | I haven't made up my mind... I think having Laziness on type level is interesting, but I can't say that I've tried enough Idris to judge the ergonomics |
| 2021-06-13 19:40:32 | × | unclechu quits (~unclechu@2001:470:69fc:105::354) (Quit: Reconnecting) |
| 2021-06-13 19:40:39 | <davean> | shapr: I'm confused by that statement - it seems laziness is the most compositional |
| 2021-06-13 19:40:47 | → | unclechu joins (~unclechu@2001:470:69fc:105::354) |
| 2021-06-13 19:40:49 | <maerwald> | davean: you never know when it breaks |
| 2021-06-13 19:41:34 | <maerwald> | oh, you accidentially kept a reference for later, now it doesn't fuse and blows up your ram |
| 2021-06-13 19:42:30 | <dminuoso> | Before I sketch it out, tyfam application disappear in generics right? |
| 2021-06-13 19:42:33 | <dmwit> | Is strict superior there? |
| 2021-06-13 19:42:36 | <shapr> | Haskell is still my favorite language by far, but it's good to be aware of the scary bits. |
| 2021-06-13 19:42:39 | × | mjs2600 quits (~mjs2600@c-24-91-3-49.hsd1.vt.comcast.net) (Ping timeout: 252 seconds) |
| 2021-06-13 19:42:49 | <maerwald> | dmwit: no, but what if you had proof of laziness? |
| 2021-06-13 19:43:04 | <davean> | maerwald: I think you just explained it as compositional to say it wasn't. I'm confused - what composition rule do you expect? |
| 2021-06-13 19:43:07 | <shapr> | I wish the type could somehow describe the laziness of a function. |
| 2021-06-13 19:43:28 | <janus> | shapr: did you see how it works in idris? |
| 2021-06-13 19:43:33 | <shapr> | janus: I have not! |
| 2021-06-13 19:43:45 | <shapr> | does idris express laziness or strictness on the type level? |
| 2021-06-13 19:43:46 | <Rembane> | Or that there was some part of compilation or some other static tooling that automatically helped with it. |
| 2021-06-13 19:43:49 | <davean> | shapr: the type does, the function is lazy. The question is what will be pulled through when you force it. |
| 2021-06-13 19:43:50 | <dminuoso> | shapr: `A -> B` with A having some fields as strict, others not. How would you expect this to be communicated? |
| 2021-06-13 19:43:53 | <janus> | shapr: http://docs.idris-lang.org/en/latest/tutorial/typesfuns.html#laziness |
| 2021-06-13 19:43:57 | → | P1RATEZ joins (piratez@user/p1ratez) |
| 2021-06-13 19:44:13 | <shapr> | hello P1RATEZ, are you learning Haskell? |
| 2021-06-13 19:44:23 | <maerwald> | davean: if you combine two lazy functions, they should *generally* fuse. That's not a very formal description, but is easily violated in haskell... very easily. |
| 2021-06-13 19:44:25 | <P1RATEZ> | i was a long time ago |
| 2021-06-13 19:44:37 | <davean> | maerwald: fusion and laziness are seperate |
| 2021-06-13 19:44:38 | <maerwald> | davean: depending on code and even GHC version |
| 2021-06-13 19:44:39 | <shapr> | P1RATEZ: aha! so you're back to try the lambda lifestyle again? |
| 2021-06-13 19:44:41 | <maerwald> | davean: yes |
| 2021-06-13 19:44:48 | <davean> | maerwald: so why are you talking about fusion? |
| 2021-06-13 19:44:58 | <maerwald> | davean: it's a way to describe when you broke laziness |
All times are in UTC.