Logs: liberachat/#haskell
| 2021-06-25 13:53:52 | <lyxia> | compared to the fiasco that some discussions about blockarguments or typeapplications become, patternsynonyms is quite popular. |
| 2021-06-25 13:55:08 | <chisui> | What's the issue with typeapplications? the ambiguity they can produce? |
| 2021-06-25 13:55:46 | <merijn> | chisui: The fact that you're making something that is widely *not* considered part of the public API part of the API you depend on |
| 2021-06-25 13:56:24 | <merijn> | chisui: The order of type variables becomes important with TypeApplications, but 99% (if not more) of Hackage maintainers do not consider that part of their public API |
| 2021-06-25 13:56:51 | → | duckonomy joins (~duckonomy@177.ip-144-217-84.net) |
| 2021-06-25 13:56:56 | <merijn> | chisui: If I refactor code and enable ScopedTypeVariables on a function: Whoops, order of type variables changed, TypeApplications code breaks! |
| 2021-06-25 13:57:24 | × | elcaro quits (~anonymous@45.32.191.75) (Quit: leaving) |
| 2021-06-25 13:57:34 | <merijn> | chisui: It's actually worse, because GHC makes no guarantees about the order in which implicitly forall'ed arguments (i.e. every function with type variables and no forall) are inferred |
| 2021-06-25 13:57:55 | <chisui> | Ah, got it. The order of type parameters on class functions always trips me up. |
| 2021-06-25 13:58:11 | <merijn> | chisui: Changes in GHC's inference algorithm have already resulted in breaking changes on inferred type variables in 9.0 |
| 2021-06-25 13:58:19 | <merijn> | So this isn't merely hypothetical |
| 2021-06-25 13:58:49 | <boxscape> | merijn: Is that true? In practice specified (but not inferred, there must be some sort of type signature) type arguments are implicitly forall'd i order of occurence |
| 2021-06-25 13:59:05 | → | elcaro joins (~anonymous@45.32.191.75) |
| 2021-06-25 13:59:21 | <merijn> | boxscape: There was a GHC release that explicitly noted a change that broke the order in which they were inferred and that change broke existing code |
| 2021-06-25 13:59:30 | <boxscape> | hm, interesting |
| 2021-06-25 14:00:21 | <merijn> | boxscape: https://downloads.haskell.org/ghc/9.0.1/docs/html/users_guide/9.0.1-notes.html#language |
| 2021-06-25 14:00:32 | <merijn> | "In certain situations, this will constitute a breaking change as this can affect TypeApplications." |
| 2021-06-25 14:01:36 | <boxscape> | ah, so it doesn't affect the order but the specificity, interesting |
| 2021-06-25 14:01:50 | <boxscape> | oh no |
| 2021-06-25 14:01:52 | <boxscape> | it affects both |
| 2021-06-25 14:01:57 | <merijn> | Personally, I think the proxy solution is superior to TypeApplications in that it doesn't require any extensions and is more robust to change |
| 2021-06-25 14:02:26 | × | warnz quits (~warnz@2600:1700:77c0:5610:350e:4738:7a75:35e) (Remote host closed the connection) |
| 2021-06-25 14:03:19 | <boxscape> | I think using visible dependent quantification in APIs should make things a lot better since you need an explicit forall (though of course it doesn't help if you don't like extensions) |
| 2021-06-25 14:04:14 | <merijn> | boxscape: But how does that improve over the simple proxy solution? |
| 2021-06-25 14:04:27 | × | lavaman quits (~lavaman@98.38.249.169) (Ping timeout: 250 seconds) |
| 2021-06-25 14:04:43 | × | nschoe quits (~quassel@2a01:e0a:8e:a190:94e8:ee7c:bab7:2086) (Ping timeout: 272 seconds) |
| 2021-06-25 14:04:50 | <boxscape> | Yes, it's somewhat easier to read and write, and you don't need to resort to Proxy# to get rid of rumtime overhead |
| 2021-06-25 14:04:51 | <boxscape> | s/rum/run |
| 2021-06-25 14:05:03 | <boxscape> | s/Yes// |
| 2021-06-25 14:05:31 | <merijn> | I don't think the readability improvement is enough to justify the mental overhead of yet another bleeding edge extension |
| 2021-06-25 14:07:06 | <boxscape> | merijn: well, tbh I think the main motivation for introducing it is that it's a step on the road to dependent types |
| 2021-06-25 14:07:30 | → | eggplantade joins (~Eggplanta@2600:1700:bef1:5e10:c4e3:f231:bc2a:37da) |
| 2021-06-25 14:07:59 | <merijn> | I think Dependent Haskell is a mistake anyway, so excuse me for not finding that a convincing argument ;) |
| 2021-06-25 14:08:12 | <delYsid> | +1 |
| 2021-06-25 14:08:56 | <boxscape> | Yeah I think without DH it probably wouldn't be worth introducing |
| 2021-06-25 14:09:23 | × | acid quits (~acid@user/acid) (Ping timeout: 268 seconds) |
| 2021-06-25 14:09:49 | → | Guest33 joins (~textual@c-107-4-204-12.hsd1.mn.comcast.net) |
| 2021-06-25 14:09:51 | <merijn> | Rather than inventing Dependent Haskell and just making Haskell worse, why not invest all that effort in getting a backend/compiler IR that Idris and Haskell can share instead >.> |
| 2021-06-25 14:10:18 | → | acid joins (~acid@user/acid) |
| 2021-06-25 14:10:56 | <merijn> | imo, Haskell with LinearHaskell and DependentHaskell crammed in is just gonna end up like C++ a bloated confusing mess that no one understands |
| 2021-06-25 14:11:06 | × | acidjnk quits (~acidjnk@p200300d0c72b9558f908228849627247.dip0.t-ipconnect.de) (Ping timeout: 240 seconds) |
| 2021-06-25 14:11:50 | × | eggplantade quits (~Eggplanta@2600:1700:bef1:5e10:c4e3:f231:bc2a:37da) (Ping timeout: 244 seconds) |
| 2021-06-25 14:12:03 | → | fendor_ joins (~fendor@91.141.57.241.wireless.dyn.drei.com) |
| 2021-06-25 14:13:14 | → | nschoe joins (~quassel@2a01:e0a:8e:a190:20c6:146b:d647:f6d9) |
| 2021-06-25 14:13:43 | × | bitdex quits (~bitdex@gateway/tor-sasl/bitdex) (Quit: = "") |
| 2021-06-25 14:14:20 | <delYsid> | Its a learning curve thing. For beginners, normal haskell already feels that way maybe, with partial functions everywhere and three string types and such. C++ does get better if you persist to learn about it as well... |
| 2021-06-25 14:14:39 | × | fendor quits (~fendor@77.119.207.179.wireless.dyn.drei.com) (Ping timeout: 258 seconds) |
| 2021-06-25 14:15:19 | <merijn> | C++ only gets worse >.> |
| 2021-06-25 14:15:40 | <delYsid> | C++ was a total mystery to me for a decade. But when C++11 came out, I had a phase of finding it extremely interesting which led to me feeling actually quite confident with it, despite its bad reputation. |
| 2021-06-25 14:16:04 | <merijn> | delYsid: It's *possible* to write nice code using C++11, sure |
| 2021-06-25 14:16:09 | × | lbseale quits (~lbseale@user/ep1ctetus) (Ping timeout: 250 seconds) |
| 2021-06-25 14:16:25 | <merijn> | delYsid: My point is there's too much "bloat" in terms of feature interactions |
| 2021-06-25 14:16:34 | <delYsid> | How long did it take to get fail out of Monad I ask :-) |
| 2021-06-25 14:16:46 | <merijn> | There's literally not a single person on this planet that knows all of C++ >.> |
| 2021-06-25 14:17:03 | <merijn> | hell |
| 2021-06-25 14:17:17 | → | slac14737 joins (~slack1256@191.125.49.104) |
| 2021-06-25 14:17:20 | <merijn> | I'm willing to bet there isn't a single person on this planet that knows even 50% of C++ |
| 2021-06-25 14:17:30 | <delYsid> | I feel every language which is older then a few years somehow has to deal with its legacy. Heck, even rust :-) |
| 2021-06-25 14:17:56 | <nitrix> | Seems only possible for Forth. |
| 2021-06-25 14:18:29 | <janus> | is there a person on the planet that knows 50% of the firmware running on a modern computer? ;) |
| 2021-06-25 14:18:56 | <merijn> | Entirely unrelatedly and slightly off topic |
| 2021-06-25 14:19:07 | <janus> | no: all abstractions are useful even if you know only some of them... |
| 2021-06-25 14:19:15 | <merijn> | Is there a way to read YAML/JSON and convert it to dhall instead of the other way around? |
| 2021-06-25 14:19:24 | <janus> | why is c++ on topic and firmware is not? |
| 2021-06-25 14:19:33 | <merijn> | I meant my question |
| 2021-06-25 14:19:38 | × | slack1256 quits (~slack1256@181.203.79.103) (Ping timeout: 265 seconds) |
| 2021-06-25 14:20:05 | <delYsid> | merijn: Wouldn't that need to infer types? |
| 2021-06-25 14:20:18 | <adamse> | merijn: https://hackage.haskell.org/package/dhall-yaml-1.2.7/docs/Dhall-YamlToDhall.html |
| 2021-06-25 14:20:24 | <merijn> | delYsid: Why would it? |
| 2021-06-25 14:20:29 | <merijn> | adamse: Ah, cool |
| 2021-06-25 14:20:48 | <delYsid> | merijn: Maybe I am misunderstanding your question. |
| 2021-06-25 14:21:29 | → | lbseale joins (~lbseale@user/ep1ctetus) |
| 2021-06-25 14:21:45 | <adamse> | delYsid: you can parse it as something like the Value type from aeson which fits all json/yaml |
| 2021-06-25 14:22:17 | × | slac14737 quits (~slack1256@191.125.49.104) (Remote host closed the connection) |
| 2021-06-25 14:23:52 | <boxscape> | merijn: btw is your gripe with Type :: Type that it's unsound? |
| 2021-06-25 14:24:08 | <merijn> | boxscape: No, my gripe is that it's confusing as hell |
| 2021-06-25 14:24:14 | <boxscape> | I see |
| 2021-06-25 14:24:27 | <boxscape> | that makes more sense :) |
| 2021-06-25 14:24:39 | <merijn> | You lose the ability to know whether something is a type, kind, etc. |
| 2021-06-25 14:24:57 | → | chomwitt joins (~Pitsikoko@athedsl-16082.home.otenet.gr) |
| 2021-06-25 14:24:59 | × | MQ-17J quits (~MQ-17J@8.21.10.15) (Ping timeout: 272 seconds) |
| 2021-06-25 14:25:07 | <merijn> | Unsoundness isn't something that is practically relevant while programming |
| 2021-06-25 14:25:13 | <boxscape> | right |
| 2021-06-25 14:25:16 | → | MQ-17J joins (~MQ-17J@8.21.10.15) |
| 2021-06-25 14:25:23 | <merijn> | The fact that the same things are sometimes types and sometimes kinds, otoh, makes reading code super confusing |
| 2021-06-25 14:25:40 | <boxscape> | fair |
| 2021-06-25 14:26:16 | <boxscape> | merijn: would you say the same thing applies to DataKinds? |
| 2021-06-25 14:26:24 | <merijn> | To some extent |
| 2021-06-25 14:26:32 | <boxscape> | okay |
| 2021-06-25 14:26:34 | <merijn> | I'm not thrilled about the need for ' to disambiguate |
| 2021-06-25 14:26:40 | → | Gurkenglas joins (~Gurkengla@dslb-002-203-144-156.002.203.pools.vodafone-ip.de) |
| 2021-06-25 14:26:52 | <merijn> | But DataKinds has more practical uses for me and I *can* explicitly disambiguate using ' |
| 2021-06-25 14:27:06 | <boxscape> | I see |
| 2021-06-25 14:27:23 | <Gurkenglas> | Can I run a debugger on GHC to investigate a compiler error? |
| 2021-06-25 14:27:43 | <merijn> | Gurkenglas: Yes, but whether that does something useful for you...depends :p |
| 2021-06-25 14:27:52 | <merijn> | Gurkenglas: What kinda error are you trying to debug? |
| 2021-06-25 14:28:00 | <Gurkenglas> | I don't have one in mind right now :( |
| 2021-06-25 14:28:35 | <Gurkenglas> | I've been noticing that lots of nonhaskellers don't use debuggers and then I boost their productivity a lot by showing them debuggers and I thought maybe Haskell's missing something. |
| 2021-06-25 14:28:38 | <merijn> | Gurkenglas: Recent GHCs support generating DWARF debug symbols, but they're not as accurate as the ones from C compilers |
| 2021-06-25 14:28:54 | <merijn> | Gurkenglas: Debuggers are slightly less useful for non-strict code |
All times are in UTC.