Logs: liberachat/#haskell
| 2021-07-29 12:30:16 | <maerwald> | but in practice, PVP failed |
| 2021-07-29 12:30:32 | <merijn> | sshine: I have an RSS feed that notifies me when my direct dependencies release out-of-bounds version, so I just bump and test when that happens |
| 2021-07-29 12:31:03 | <sshine> | merijn, ok. |
| 2021-07-29 12:31:59 | <sshine> | maerwald, because people don't follow the PVP? |
| 2021-07-29 12:32:02 | <merijn> | sshine: https://packdeps.haskellers.com/feed?needle=microlens for example |
| 2021-07-29 12:32:26 | <merijn> | you can just take that as RSS feed to keep track |
| 2021-07-29 12:32:29 | <maerwald> | sshine: hm... maybe. I'm not sure the idea is a good one to begin with. PVP assumes ppl backport bugfixes and security patches. But most don't. |
| 2021-07-29 12:33:20 | <maerwald> | In fact, I believe you can do fine without PVP. If you rewrite your entire API, go write a new package. That's what many ecosystem do. Even if it's called foo2 |
| 2021-07-29 12:33:50 | <maerwald> | But haskellers tend to constantly experiment with their API |
| 2021-07-29 12:34:06 | <sshine> | first-class modules! |
| 2021-07-29 12:34:15 | <sshine> | then version can be derived! |
| 2021-07-29 12:34:17 | <merijn> | People can get a stable API from me when they pay me >.< |
| 2021-07-29 12:38:09 | × | azeem quits (~azeem@dynamic-adsl-94-34-48-122.clienti.tiscali.it) (Read error: Connection reset by peer) |
| 2021-07-29 12:38:26 | <Drew[m]> | I mean recently I encountered a package on Hackage that something appeared to require as a dependency (which actually didn't need it), and the package had no dependency bounds and it failed while building because of an ambiguous occurence error... |
| 2021-07-29 12:38:28 | <Drew[m]> | I presume there was a particular set of dependencies the package was originally built under. I have no idea how I discover what they are. |
| 2021-07-29 12:38:52 | <merijn> | Drew[m]: Brute force and guess work |
| 2021-07-29 12:38:57 | → | azeem joins (~azeem@dynamic-adsl-94-34-48-122.clienti.tiscali.it) |
| 2021-07-29 12:39:36 | <merijn> | Drew[m]: There is a contigent of "never specify upperbounds" people on Hackage (with significant overlap with the "you should use stackage to ensure things work!" people) |
| 2021-07-29 12:39:49 | → | lavaman joins (~lavaman@98.38.249.169) |
| 2021-07-29 12:40:00 | <Drew[m]> | I know |
| 2021-07-29 12:40:08 | <Drew[m]> | I've been thinking about it |
| 2021-07-29 12:40:28 | <Drew[m]> | I feel like different people are trying to communicate different things through the bounds |
| 2021-07-29 12:40:55 | <merijn> | Drew[m]: This is part of the reason cabal has the new ^>= bounds and allow-newer support |
| 2021-07-29 12:41:22 | <Drew[m]> | yeah |
| 2021-07-29 12:41:37 | <Drew[m]> | Has it fixed the contention though? |
| 2021-07-29 12:42:05 | <merijn> | Can't force people to do the right thing, sadly >.> |
| 2021-07-29 12:43:41 | × | lortabac quits (~lortabac@2a01:e0a:541:b8f0:d518:334f:85c4:8d2d) (Quit: WeeChat 2.8) |
| 2021-07-29 12:43:59 | <yushyin> | cargo (rust) has done it right. If you specify "1.2.3" as the version, it is implicitly "^1.2.3" which is similar to our ^>=. |
| 2021-07-29 12:44:17 | × | lavaman quits (~lavaman@98.38.249.169) (Ping timeout: 252 seconds) |
| 2021-07-29 12:44:55 | → | fendor_ joins (~fendor@178.165.162.84.wireless.dyn.drei.com) |
| 2021-07-29 12:45:10 | <merijn> | yushyin: Yeah, but that's benefit of hindsight |
| 2021-07-29 12:45:15 | → | Cajun joins (~Cajun@ip98-163-211-112.no.no.cox.net) |
| 2021-07-29 12:45:36 | <viluon> | merijn: it is, but it's still a way of forcing people to do the right thing |
| 2021-07-29 12:45:53 | <merijn> | viluon: Maybe in cabal-version 4.0 we can make that the new default :p |
| 2021-07-29 12:46:04 | <merijn> | And then 20 years from now we can rely on it :p |
| 2021-07-29 12:46:09 | <yushyin> | :D |
| 2021-07-29 12:46:10 | × | fossdd quits (~fossdd@sourcehut/user/fossdd) (Ping timeout: 240 seconds) |
| 2021-07-29 12:46:43 | <merijn> | At least we have our forwards-compat story sorted in cabal files now |
| 2021-07-29 12:46:44 | → | fossdd joins (~fossdd@sourcehut/user/fossdd) |
| 2021-07-29 12:46:55 | <merijn> | That's more than many other tools can say :p |
| 2021-07-29 12:47:22 | × | fendor quits (~fendor@178.165.161.179.wireless.dyn.drei.com) (Ping timeout: 240 seconds) |
| 2021-07-29 12:47:25 | <viluon> | the Unison language does it even better in my opinion, content-addressable code means that the issue of naming is essentially trivial. The issue of updating, i.e. replacing one definition with another, persists, but there's no ad-hoc versioning scheme / package manager / build system you have to rely on in order to specify what your code depends on. |
| 2021-07-29 12:53:55 | → | Obo joins (~roberto@94.191.137.235.mobile.tre.se) |
| 2021-07-29 12:56:08 | → | oxide joins (~lambda@user/oxide) |
| 2021-07-29 12:56:34 | × | fossdd quits (~fossdd@sourcehut/user/fossdd) (Ping timeout: 240 seconds) |
| 2021-07-29 12:57:06 | → | fossdd joins (~fossdd@sourcehut/user/fossdd) |
| 2021-07-29 12:59:05 | × | chris_ quits (~chris@81.96.113.213) (Remote host closed the connection) |
| 2021-07-29 13:00:17 | → | chris_ joins (~chris@81.96.113.213) |
| 2021-07-29 13:00:20 | × | __monty__ quits (~toonn@user/toonn) (Quit: leaving) |
| 2021-07-29 13:00:40 | fendor_ | is now known as fendor |
| 2021-07-29 13:01:05 | → | alx741 joins (~alx741@181.196.69.4) |
| 2021-07-29 13:02:48 | × | jneira quits (~jneira@212.8.115.226) (Quit: Client closed) |
| 2021-07-29 13:03:04 | <maerwald> | what does "1.2.3" being implicitly "^1.2.3" get you when the dependency doesn't actually follow semver |
| 2021-07-29 13:03:33 | × | merijn quits (~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 276 seconds) |
| 2021-07-29 13:05:29 | → | Sgeo joins (~Sgeo@user/sgeo) |
| 2021-07-29 13:09:04 | × | jumper149 quits (~jumper149@80.240.31.34) (Quit: WeeChat 3.2) |
| 2021-07-29 13:09:35 | × | jolly quits (~jolly@208.180.97.158) (Quit: Connection closed) |
| 2021-07-29 13:14:10 | × | fossdd quits (~fossdd@sourcehut/user/fossdd) (Ping timeout: 240 seconds) |
| 2021-07-29 13:14:28 | → | fossdd joins (~fossdd@sourcehut/user/fossdd) |
| 2021-07-29 13:15:15 | → | Null_A joins (~null_a@2601:645:8700:2290:44f7:81a6:341:7abe) |
| 2021-07-29 13:16:42 | → | eggplantade joins (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) |
| 2021-07-29 13:19:52 | × | Null_A quits (~null_a@2601:645:8700:2290:44f7:81a6:341:7abe) (Ping timeout: 256 seconds) |
| 2021-07-29 13:20:13 | × | img quits (~img@user/img) (Quit: ZNC 1.8.2 - https://znc.in) |
| 2021-07-29 13:21:18 | → | Lycurgus joins (~juan@cpe-45-46-140-49.buffalo.res.rr.com) |
| 2021-07-29 13:21:22 | × | eggplantade quits (~Eggplanta@108-201-191-115.lightspeed.sntcca.sbcglobal.net) (Ping timeout: 265 seconds) |
| 2021-07-29 13:21:33 | → | img joins (~img@user/img) |
| 2021-07-29 13:22:46 | <zzz> | i just found out there's a function called zipLazy which is the same as zip "but lazy on the second list". isn't zip lazy by default? |
| 2021-07-29 13:23:27 | <Lycurgus> | extra |
| 2021-07-29 13:24:10 | × | fossdd quits (~fossdd@sourcehut/user/fossdd) (Ping timeout: 240 seconds) |
| 2021-07-29 13:24:22 | → | fossdd joins (~fossdd@sourcehut/user/fossdd) |
| 2021-07-29 13:25:35 | <zzz> | it seems to me that it'a not lazy, it's irrefutable on the pattern match for the second list, throwing an error if the first list's length is greater |
| 2021-07-29 13:25:59 | <zzz> | how is this useful? |
| 2021-07-29 13:26:50 | <boxscape> | zzz: FWIW base docs say `zip is right-lazy: zip [] _|_ = [] |
| 2021-07-29 13:26:51 | <boxscape> | which sounds very much like the description of zipLazy |
| 2021-07-29 13:27:01 | <boxscape> | I inserted the / accidentally |
| 2021-07-29 13:27:02 | <boxscape> | wait |
| 2021-07-29 13:27:11 | <boxscape> | I don't know if matrix is displaying this correctly |
| 2021-07-29 13:27:23 | <boxscape> | it's supposed to be `zip [] undefined = []`, basically |
| 2021-07-29 13:27:54 | <zzz> | so my question is, how is zipLazy different from zip in a useful way? |
| 2021-07-29 13:28:37 | <boxscape> | (Oh.. matrix displays | as a | in italic, not a slash, I see) |
| 2021-07-29 13:28:56 | <boxscape> | s/matrix/element |
| 2021-07-29 13:29:21 | <Drew[m]> | zzz: Say you have two lists and the second one is infinite. With zip you have to somewhat evaluate the second list to get the first element of the zipped list. I believe with this zipLazy you could access all the first elements without evaluating any of the second list |
| 2021-07-29 13:30:35 | <zzz> | > map fst $ zip [0..7] [9..] |
| 2021-07-29 13:30:37 | <lambdabot> | [0,1,2,3,4,5,6,7] |
| 2021-07-29 13:31:19 | <Drew[m]> | I "first element" but I meant "fst value of the first element" |
| 2021-07-29 13:31:33 | <Drew[m]> | I said* |
| 2021-07-29 13:31:36 | <zzz> | > map fst $ zip [0..7] (undefined : [9..]) |
| 2021-07-29 13:31:37 | <lambdabot> | [0,1,2,3,4,5,6,7] |
| 2021-07-29 13:31:57 | → | merijn joins (~merijn@83-160-49-249.ip.xs4all.nl) |
| 2021-07-29 13:32:14 | <Drew[m]> | That could save some work in some circumstances |
| 2021-07-29 13:32:37 | <zzz> | maybe i'm not understanding your point, but zip seems to work just fine for that |
| 2021-07-29 13:33:00 | → | peterhil joins (~peterhil@dsl-hkibng32-54fb52-57.dhcp.inet.fi) |
| 2021-07-29 13:33:16 | <Drew[m]> | Probably because I'm wrong |
| 2021-07-29 13:33:20 | × | Obo quits (~roberto@94.191.137.235.mobile.tre.se) (Ping timeout: 252 seconds) |
| 2021-07-29 13:34:39 | <Drew[m]> | Oh wait |
| 2021-07-29 13:34:48 | <Drew[m]> | Your example still requires evaluating some of the second list |
| 2021-07-29 13:34:57 | <Drew[m]> | Namely the `:` constructor |
| 2021-07-29 13:35:20 | <zzz> | yes |
| 2021-07-29 13:35:31 | <zzz> | when would it be useful not to? |
| 2021-07-29 13:36:09 | <zzz> | > map fst $ zip [0..7] undefined |
All times are in UTC.