hpc 2017-02-05 04:45:35
so that's not "some wiki"
maerwald 2017-02-05 04:45:50
yeah, whatever
maerwald 2017-02-05 04:46:30
authority arguments incoming
phadej 2017-02-05 04:49:29
boccato: depends on what packages you look, "most" packages "I use" have upper bounds
nshepperd_ 2017-02-05 04:50:20
Isn't setting upper bounds kind of how to fix things as you go? When a new dependency version comes out, test it with that version, fix it then update the deps?
phadej 2017-02-05 04:50:46
maerwald: the distro argument is missleading, there the "release team" decides which and when packages go in
hpc 2017-02-05 04:50:49
you can't go back and add upper bounds after the fact
phadej 2017-02-05 04:50:59
Hackage is distributed system
maerwald 2017-02-05 04:51:02
phadej: most don't have a release team, so no
hpc 2017-02-05 04:51:07
a published version of a package (except in particularly exceptional cases) is immutable
michaelt 2017-02-05 04:51:26
even if one old version lacked upper bounds it can produce cabal chaos 3 years later
boccato 2017-02-05 04:51:31
phadej: wasn't an extensible search, was almost random
maerwald 2017-02-05 04:51:36
if you want a set of tested versions, use stackage
maerwald 2017-02-05 04:51:44
that's what it's for... hackage is rolling release
michaelt 2017-02-05 04:51:44
cabal goes through and says 'oh i see this one works ...'
phadej 2017-02-05 04:52:00
boccato: there are authors which omits them, and authors which dont
maerwald 2017-02-05 04:52:19
phadej: but yes... there's not enough communication/coordination on hackage
nshepperd_ 2017-02-05 04:52:21
Right, so if you didn't add deps in the first place, cabal will keep trying to use the broken package
maerwald 2017-02-05 04:52:21
it's just chaos
phadej 2017-02-05 04:52:38
maerwald: the versions bounds are the mechanism to communicate
hpc 2017-02-05 04:52:45
coordination is supposed to happen through version bounds and semantic versioning
maerwald 2017-02-05 04:52:49
phadej: that's not true most of the time
phadej 2017-02-05 04:52:51
hpc: :+1:
maerwald 2017-02-05 04:52:58
stuff just bitrots there and people forget to update deps
phadej 2017-02-05 04:53:06
maerwald: it doesn't
hpc 2017-02-05 04:53:10
it's not true when you blithely upload packages with no upper bounds and refuse to follow the policy
phadej 2017-02-05 04:53:10
provide evidence
maerwald 2017-02-05 04:53:17
phadej: erm?
Tuplanolla 2017-02-05 04:53:26
Wouldn't it be nice if we had automatic versioning based on changes?
phadej 2017-02-05 04:53:45
maerwald: e.g. stackage is an evidence that bounds get updates, as well as that packages break when there aren't upper bounds
hpc 2017-02-05 04:53:46
if package uploaders could do whatever they wanted, hackage would be like npm
maerwald 2017-02-05 04:54:05
phadej: ok, that's wrong when you look at the last upper bound change on base
hpc 2017-02-05 04:54:07
where a "package" consists of a url saying "download a bunch of stuff from some random github url"
maerwald 2017-02-05 04:54:15
most packages worked fine with the new GHC base version
phadej 2017-02-05 04:54:25
maerwald: but didn't with 4.8
maerwald 2017-02-05 04:54:25
and still everything needed to be "fixed" manually
phadej 2017-02-05 04:54:30
maerwald: how you can know?
Clint 2017-02-05 04:54:32
upper bounds are the devil
maerwald 2017-02-05 04:54:42
phadej: if you don't know, don't add upper bounds
maerwald 2017-02-05 04:54:50
Clint: exactly
phadej 2017-02-05 04:54:52
imho lazy maintainers is worse when there aren't upper bounds
phadej 2017-02-05 04:54:57
if they are lazy, they won't add them
phadej 2017-02-05 04:55:06
imho it's bigger "bad"
hpc 2017-02-05 04:55:27
upper bounds mean that package installs crap out on package versions instead of on "not in scope: Foo.Bar.baz"
maerwald 2017-02-05 04:55:36
Clint: most people don't understand the impact though... and now since we have cabal sandboxes and everything, things are a little less broken from the user perspective. But the depgraph is still just f'ed up
hpc 2017-02-05 04:55:40
or ridiculous and non-obvious type errors that are different every time
michaelt 2017-02-05 04:55:46
if you don't believe in upper bounds you can mechanize the process of bumping them for your packages.
Welkin 2017-02-05 04:55:56
maerwald: and stack and nix
maerwald 2017-02-05 04:56:06
Welkin: more random tools yeah :P
Clint 2017-02-05 04:56:06
michaelt: it's not my packages that i'm annoyed by
ertes 2017-02-05 04:56:16
i used to use bounds like: kan-extensions >= 5.0 && < 6
michaelt 2017-02-05 04:56:29
Clint: try --allow-newer if you are using cabal install
ertes 2017-02-05 04:56:36
it worked well enough, but also raised a concern about semantic changes
Welkin 2017-02-05 04:56:42
stackage is supposed to solve those issues
phadej 2017-02-05 04:56:48
ertes: but you rely on kmett's "extra semantics" on top of pvp. It's not wrong
Clint 2017-02-05 04:56:52
michaelt: i'm not
hpc 2017-02-05 04:56:55
stackage solves the issue by eliminating it entirely
maerwald 2017-02-05 04:57:01
michaelt: yeah, but now... you have the problem of not knowing "did he add an upper bound because he KNOWS it doesn't work or because he DOESNT KNOW"
maerwald 2017-02-05 04:57:03
see the problem?
hpc 2017-02-05 04:57:11
dependency solving ceases to exist and it's just "build with these exact versions of everything"
phadej 2017-02-05 04:57:24
except that stackage has to do solving in the first place
ertes 2017-02-05 04:57:31
phadej: the PVP does not specify that though… the issue was brought to my attention by the maintainer of the unix package
michaelt 2017-02-05 04:57:41
maerwald: yes, it speaks in favor of doing the work to have rational upper bounds, no?
ertes 2017-02-05 04:57:41
that's why i now go with stricter bounds
hpc 2017-02-05 04:58:24
maerwald: upper bounds in cabal, much like something not existing in a stackage LTS, mean the exact same thing
Welkin 2017-02-05 04:58:25
I've run into issues with too tightly restricted upper bounds that required a re-upload to hackage for packages I needed to use
hpc 2017-02-05 04:58:30
untested or non-functional
maerwald 2017-02-05 04:58:31
michaelt: yes, I want to ignore all "lalala, I don't know, so I just randomly add upper bounds everywhere", but I don't want to ignore the cases where an upper bound might safe me from unexpected runtime behavior
Tuplanolla 2017-02-05 04:58:34
Could we have a tool that looks through your code to see what parts of a package you use and then find the oldest version of that package where all those things have remained unchanged?
Welkin 2017-02-05 04:58:34
I had to contact the author for it
ertes 2017-02-05 04:59:12
i wish the PVP would specify explicitly that semantic *changes* can only happen in major-major jumps
maerwald 2017-02-05 04:59:13
michaelt: because the maintainer actually knows it
ertes 2017-02-05 04:59:32
no semantic changes allowed, only semantic additions: 5.0 -> 5.1
hpc 2017-02-05 04:59:35
Welkin: that's the system working as intended
Clint 2017-02-05 04:59:39
and if the author is bos you have to wait 18 months for a fix
ertes 2017-02-05 04:59:39
semantic changes allowed: 5.0 -> 6.0
maerwald 2017-02-05 04:59:43
if I want a perfectly safe set of packages... then I use stackage (or distro packages)
drostie 2017-02-05 04:59:43
Well that's why semver was being pushed so hard for... the major versions track breaking API changes so you always add upper bounds because you don't know whether it's gonna work or not.
phadej 2017-02-05 04:59:54
ertes: what you mean by semantic additions?
nshepperd_ 2017-02-05 04:59:56
Tuplanolla: we could have something that just builds the package and sees if it fails. That would detect practically all problems
ertes 2017-02-05 05:00:38
phadej: new functions or old functions with new functionality that doesn't interfere with the older API
Tuplanolla 2017-02-05 05:00:48
That seems really computationally expensive, nshepperd.
maerwald 2017-02-05 05:00:48
drostie: it's just laziness and impractical
phadej 2017-02-05 05:00:48
non breaking changes are allowed in the third digit
ertes 2017-02-05 05:00:48
personally i think the PVP is flawed in this respect
Welkin 2017-02-05 05:00:48
pvp?
hpc 2017-02-05 05:00:48
package versioing policy
ertes 2017-02-05 05:00:48
Package Versioning Policy
phadej 2017-02-05 05:00:48
e.g. adding function is ok to go from 1.2.5 -> 1.2.6
Welkin 2017-02-05 05:00:48
lol
Welkin 2017-02-05 05:00:53
I see pvp and think player vs player
maerwald 2017-02-05 05:01:00
haha
ertes 2017-02-05 05:01:05
hehe
Clint 2017-02-05 05:01:12
it's related
ertes 2017-02-05 05:01:15
it's *kind of* player vs. player =)
michaelt 2017-02-05 05:01:17
ha
boccato 2017-02-05 05:01:19
For a private project (not published) would it be bad to put the explicit version of the dependency?
ertes 2017-02-05 05:01:20
dev vs. dev
maerwald 2017-02-05 05:01:35
boccato: like you do in javascript?
hpc 2017-02-05 05:01:37
boccato: to specify version numbers exactly?
Welkin 2017-02-05 05:01:40
boccato: no, that is what stackage does already
hpc 2017-02-05 05:01:41
should be fine
ertes 2017-02-05 05:01:42
boccato: for private projects i don't bother using bounds at all =)
phadej 2017-02-05 05:01:45
boccato: I won't put any versions, and use stack or cabal freeze
ertes 2017-02-05 05:01:48
if it breaks, i'll just fix it
maerwald 2017-02-05 05:01:48
ertes: exactly
drostie 2017-02-05 05:01:50
phadej: the semver definition is that when you add functionality in a backwards compatible manner you increment the second number.
hpc 2017-02-05 05:01:53
stackage does that, and a number of packages that are tightly bound to each other do it too
Polarina 2017-02-05 05:01:57
boccato, I do that for my private projects. That way, I know which packages' ChangeLogs to read when they publish a new major version.
phadej 2017-02-05 05:02:05
drostie: don't mix up semver and pvp
drostie 2017-02-05 05:02:17
Oh, I see what you're saying then.
phadej 2017-02-05 05:02:19
https://pvp.haskell.org/faq/#how-does-the-pvp-relate-to-semantic-versioning-semver
hpc 2017-02-05 05:02:23
https://hackage.haskell.org/package/ghc-boot
Welkin 2017-02-05 05:02:27
so wait
hpc 2017-02-05 05:02:32
depends on ghc-boot-th exactly equal to the same version
Welkin 2017-02-05 05:02:42
what is with chrome and the ever-increasing versions?
ertes 2017-02-05 05:02:44
anyway, so far i've only run into one problem… i have to pay attention to stuff like: vector >= 0.11 && < 0.13
maerwald 2017-02-05 05:02:45
ertes: the problem with hackage though is... I know when I break my own package, but not when reverse deps break my package. That's simply a lack of functionality of the hackage platform.
ertes 2017-02-05 05:02:46
it's good enough
boccato 2017-02-05 05:02:47
Hmm... good to know.
Welkin 2017-02-05 05:02:49
it is definitely not semver
Welkin 2017-02-05 05:02:55
unless it break every time they make a release
maerwald 2017-02-05 05:02:56
but relatively easy to implement, if someone wanted to
hpc 2017-02-05 05:03:09
chrome's version numbering system is an advertising trick
hpc 2017-02-05 05:03:23
the idea was that chrome version 22 looks better than firefox version 3.5
ertes 2017-02-05 05:03:36
maerwald: not sure… i feel like every more expressive solution would come with an engineering cost
ertes 2017-02-05 05:03:45
not for hackage, but for package developers
hpc 2017-02-05 05:03:55
it could be a breaking change every time though
ertes 2017-02-05 05:04:02
my view is that hackage and the PVP are good enough
hpc 2017-02-05 05:04:11
(for something other than chrome)
ertes 2017-02-05 05:04:18
sometimes stuff breaks, and then you fix it
Welkin 2017-02-05 05:04:22
and wait
maerwald 2017-02-05 05:04:25
ertes: not really, you just need build servers testing stuff and could then rather easily propagate the results via e-mail (optionally) or on some website
Welkin 2017-02-05 05:04:36
version numbers don't seem to mean anything unless you follow a system like semver
hpc 2017-02-05 05:04:41
what do the build servers test?
drostie 2017-02-05 05:04:43
Welkin: yeah, Chrome and Firefox decided to have more aggressively pushed majors, Ubuntu decided to have majors be just dates of release.
ertes 2017-02-05 05:04:44
maerwald: you want to turn hackage into a CI platform?
phadej 2017-02-05 05:04:46
maerwald: the question is "who is the one who will build and maintain these servers"
maerwald 2017-02-05 05:04:46
"the new lens release just broke your package, we are sorry"...
hpc 2017-02-05 05:04:49
the powerset of every package version?
Welkin 2017-02-05 05:04:49
elm made breaking changes from version 0.16 to 0.17
phadej 2017-02-05 05:04:59
maerwald: you can do it yourself now
maerwald 2017-02-05 05:05:16
aha
michaelt 2017-02-05 05:05:23
it would be nice if hackage somehow informed me if my packages no longer build with the latest as stackage sort of does
ertes 2017-02-05 05:05:39
maerwald: i wouldn't mind it, but any concrete form of CI is going to upset *someone*
phadej 2017-02-05 05:05:43
michaelt: but Hackage isn't a CI, it's a repository
maerwald 2017-02-05 05:05:48
ertes: not really "turn into". It wouldn't even have to be related to the hackage site
Welkin 2017-02-05 05:05:54
of course another problem is that docs dont get generated all the time because it fails on the server
michaelt 2017-02-05 05:06:02
phadej: yes, but I would still like to know in advance when things are changing
Welkin 2017-02-05 05:06:20
documentation generation should be happening on the uploader's machine
drostie 2017-02-05 05:06:23
Welkin: breaking changes from 0.16 to 0.17 are allowed by both PVP and semver.
drostie 2017-02-05 05:06:30
(for different reasons.)
phadej 2017-02-05 05:06:37
michaelt: with proper bounds you can follow http://packdeps.haskellers.com rss
Tuplanolla 2017-02-05 05:06:42
Documentation generation happens upon installation for me.
maerwald 2017-02-05 05:06:47
well, I think the biggest obstacle here is not technologically, but just that maintainers are used to the semi-broken workflow on hackage and don't want to bother with more
Tuplanolla 2017-02-05 05:06:53
I don't see any other way making sense.
Welkin 2017-02-05 05:07:07
Tuplanolla: I am talking about the hosted docs on hackage
michaelt 2017-02-05 05:07:15
Tuplanolla: the docs on hackage?
phadej 2017-02-05 05:07:29
Welkin: you can upload the docs!
Tuplanolla 2017-02-05 05:07:33
Right. I don't use those.
phadej 2017-02-05 05:07:44
both cabal and stack (AFAIK) can do it
michaelt 2017-02-05 05:07:57
oh I thought Welkin knew that
Welkin 2017-02-05 05:08:53
I can?
Welkin 2017-02-05 05:09:13
it has been annoying me to no end that certain package fail to have docs
hpc 2017-02-05 05:09:17
anyway, the automation behind version upper bounds is what distros do manually with every release
Welkin 2017-02-05 05:09:25
like ghcjs-dom
michaelt 2017-02-05 05:09:30
Welkin: no doubt I'm out of date but i use this script https://raw.githubusercontent.com/michaelt/streaming/master/upload.sh
maerwald 2017-02-05 05:09:34
hpc: no
michaelt 2017-02-05 05:09:42
Welkin: which was floating around a year or so ago
phadej 2017-02-05 05:10:23
Welkin: https://github.com/haskell/cabal/issues/2080
maerwald 2017-02-05 05:10:58
releases are _consistent_, update process of upper bounds is inherently not... and it's not even proper rolling release... it's an ugly hybrid that doesn't work
phadej 2017-02-05 05:11:28
Welkin: the tooling UX is not easy, someone just needs to go thru designing and implementing it
michaelt 2017-02-05 05:11:39
Welkin: it's pretty straightforward, someone probably has a sexier script these days.
phadej 2017-02-05 05:11:47
maerwald: why you insist of seeing the Hackage as a whole, and not collection of releases per packages?
hpc 2017-02-05 05:11:51
upper bounds following semantic versioning are consistent
phadej 2017-02-05 05:11:54
in the same way ase.g. PyPi
phadej 2017-02-05 05:12:01
or maven
hpc 2017-02-05 05:12:14
the lifetime of a distro release defines the support period for the packages it contains
hpc 2017-02-05 05:12:27
on the next release, those previous versions become unsupported and new versions become supported
maerwald 2017-02-05 05:12:38
I know how distros work
hpc 2017-02-05 05:12:55
some packages drop off, those are the kind of thing Welkin mentioned where you have to get the package maintainer to update
maerwald 2017-02-05 05:12:59
and it's nowhere near similar to the upper bounds mess on hackage
maerwald 2017-02-05 05:13:21
phadej: because of the dependency graph
hpc 2017-02-05 05:13:22
upper bounds define the period of support for a package
hpc 2017-02-05 05:13:44
when the dependencies do new potentially-breaking releases, the support period for that version has ended
hpc 2017-02-05 05:14:00
and a new version has to be rolled (possibly a minor version bump) that updates the support period
hpc 2017-02-05 05:14:12
it's only a mess if you don't follow the PVP
phadej 2017-02-05 05:14:15
maerwald: so are you saying mavens or pypis approach is also wrong?
maerwald 2017-02-05 05:14:39
I'm tired of explaining the difference... but here we go: next GHC version with new base version will cause what? 30% of hackage working after 2 weeks. How's that anywhere near a consistent, tested debian release?
hpc 2017-02-05 05:14:39
you can't just ignore the thing that makes it work and then proclaim that it's broken
phadej 2017-02-05 05:14:40
imho they are in even worse situation, as they have no semantics in the version components
maerwald 2017-02-05 05:14:41
it's not
maerwald 2017-02-05 05:15:00
stop comparing things that are totally different
phadej 2017-02-05 05:15:01
maerwald: why it should work in the next 2 weeks?
maerwald 2017-02-05 05:15:16
hackage is rolling release
phadej 2017-02-05 05:15:18
it will work when authors have ability to test it
hpc 2017-02-05 05:15:23
maerwald: packages disappear between debian releases too
maerwald 2017-02-05 05:15:41
disappear...
michaelt 2017-02-05 05:15:45
Welkin: https://github.com/ekmett/lens/blob/67ac5db4ee24364c435e6e9fbe29fe429bce8d0c/scripts/hackage-docs.sh looks very modern
hpc 2017-02-05 05:16:02
and it's not a rolling release, it's distributed discrete releases
maerwald 2017-02-05 05:16:11
it's a broken hybrid yes
hpc 2017-02-05 05:16:18
it's a working hybrid if you follow the rules
maerwald 2017-02-05 05:16:24
I disagree
hpc 2017-02-05 05:16:27
okay?
nshepperd_ 2017-02-05 05:16:40
Ghc maintainers could fix everyone's packages for them, sure
maerwald 2017-02-05 05:16:48
but since you're barely responding to my arguments, I guess we are done
nshepperd_ 2017-02-05 05:16:57
Write everyone's Applicative instances
phadej 2017-02-05 05:17:05
nshepperd_: :)
hpc 2017-02-05 05:17:17
debian releases work by debian taking ownership of every package they publish
drostie 2017-02-05 05:17:31
This is why I wanted to write a metadata-based programming language where every function was hashable. It could have release tooling where it says "hey, you changed the public API for your package by adding this new function, based on this we want to bump the minor release number, is that OK with you?" and you can say "cancel out of all this, that function was supposed to be private!" or whatevs.
ongy 2017-02-05 05:17:37
nshepperd_: why didn't they? From how I understand it 'instance Monad a => Applicative a where' could be a thing (overlappable for saner definitions)
Tuplanolla 2017-02-05 05:18:01
Perhaps we are too fixated on the concept of packages.
hpc 2017-02-05 05:18:03
and the maintainers spend a crazy-stupid amount of effort doing what cabal version numbers do automatically
phadej 2017-02-05 05:18:17
ongy: oh, that won't work far
nshepperd_ 2017-02-05 05:18:35
ongy: dunno, probably some reason
ongy 2017-02-05 05:18:52
why though? shouldn't return and ap do the trick?
hpc 2017-02-05 05:19:05
when a new ghc comes out, it doesn't suddenly break the old ghc, is the end result
ongy 2017-02-05 05:19:12
I get that there's some more ideological reason not to, but is there a technical?
hpc 2017-02-05 05:19:26
the same version resolution just makes it work, without having to repoint your repos like with a new debian release
hpc 2017-02-05 05:19:34
or without having to always be upgrading like with arch
hpc 2017-02-05 05:19:46
where if you wait for a month or two, the upgrade path vanishes because they move so fast
hpc 2017-02-05 05:20:31
don't upgrade right away if you aren't prepared to do what debian does, really
nshepperd_ 2017-02-05 05:21:18
ongy: i suppose it's better not to need overlapping instances in base
hpc 2017-02-05 05:21:29
ongy: once you defined that, you can't write any other Applicative instances without OverlappingInstances
hpc 2017-02-05 05:21:34
because everything overlaps with 'a'
nshepperd_ 2017-02-05 05:21:51
Ah, that's why
ongy 2017-02-05 05:21:56
everything? or everything that's Monad?
hpc 2017-02-05 05:22:03
everything
phadej 2017-02-05 05:22:04
everything
hpc 2017-02-05 05:22:15
the constraint doesn't factor into it
thatguy 2017-02-05 05:22:20
is there some quick way to write functions that take n arguments and just return ()
ongy 2017-02-05 05:22:22
oh, that makes more sense
thatguy 2017-02-05 05:22:34
even quicker than (\a b c -> ())
hpc 2017-02-05 05:22:46
\_ _ _ -> ()
Tuplanolla 2017-02-05 05:22:53
Pile `const`, thatguy?
hpc 2017-02-05 05:23:01
:t const const const const
lambdabot 2017-02-05 05:23:02
b -> a -> b1 -> a
hpc 2017-02-05 05:23:08
:t const const const const const
lambdabot 2017-02-05 05:23:09
a -> b -> a
Welkin 2017-02-05 05:23:10
wtf?
Welkin 2017-02-05 05:23:15
how do you log out of your accoint on hackage?
hpc 2017-02-05 05:23:17
(const is weird)
phadej 2017-02-05 05:23:28
@pl \x y z -> ()
lambdabot 2017-02-05 05:23:28
const (const (const ()))
Tuplanolla 2017-02-05 05:23:44
> (const . const . const . const) () 1 2 3 4
lambdabot 2017-02-05 05:23:46
()
hpc 2017-02-05 05:23:57
thatguy: why do you need this?
phadej 2017-02-05 05:24:02
@pl \a x y z -> a
lambdabot 2017-02-05 05:24:02
const . const . const
thatguy 2017-02-05 05:24:30
Tuplanolla, thanks
thatguy 2017-02-05 05:24:54
hpc, and exercise in the CIS 194 course where I am doing a parser which parses either an int or an uppercase char
reactormonk 2017-02-05 05:25:17
How do I tell cabal which cabal file to use?
thatguy 2017-02-05 05:25:29
hpc, I am doing it as ((\a -> ()) <$> IntParser) <|> ((\a -> ()) UpperCharParser), is that ok?
phadej 2017-02-05 05:25:49
:t void
lambdabot 2017-02-05 05:25:50
Functor f => f a -> f ()
thatguy 2017-02-05 05:25:59
and I need that \a -> () so that the two parser are both of type Parser () and I can use <|> on them
phadej 2017-02-05 05:26:21
:t \f -> const () <$> f
lambdabot 2017-02-05 05:26:23
Functor f => f b -> f ()
phadej 2017-02-05 05:26:28
:t \f -> () <$ f
lambdabot 2017-02-05 05:26:29
Functor f => f b -> f ()
phadej 2017-02-05 05:26:34
:t \f -> void f
lambdabot 2017-02-05 05:26:36
Functor f => f a -> f ()
phadej 2017-02-05 05:26:42
pick yours
hpc 2017-02-05 05:26:49
void IntParser <|> void UpperCharParser?
thatguy 2017-02-05 05:27:14
phadej, thanks
phadej 2017-02-05 05:27:25
the <$ is useful when you have many parsers, e.g.
phadej 2017-02-05 05:27:42
\a b c -> () <$ a <* b <* c
phadej 2017-02-05 05:27:44
:t \a b c -> () <$ a <* b <* c
lambdabot 2017-02-05 05:27:46
Applicative f => f b2 -> f b1 -> f b -> f ()
phadej 2017-02-05 05:27:54
yet you can write
phadej 2017-02-05 05:28:07
:t \a b c -> void (a *> b *> c)
lambdabot 2017-02-05 05:28:09
Applicative f => f a2 -> f a1 -> f a -> f ()
phadej 2017-02-05 05:28:18
which might perform better
lyxia 2017-02-05 05:29:26
ongy: instance Monad f => Applicative f also requires UndecidableInstances
thatguy 2017-02-05 05:29:42
:t <$
lambdabot 2017-02-05 05:29:44
error: parse error on input '<$'
drostie 2017-02-05 05:29:48
maerwald: I just wanted to say that I benefitted a lot from rereading the chat history from your perspective.
phadej 2017-02-05 05:29:51
:t (<$)
lambdabot 2017-02-05 05:29:53
Functor f => a -> f b -> f a
ongy 2017-02-05 05:30:27
lyxia: From how I understand it, that would be required only in the file that defines this instance and should be ok here, but I'm not 100% on that
ongy 2017-02-05 05:30:34
but I also understand that it's not the cleanest solution either
thatguy 2017-02-05 05:31:32
phadej, thanks for the help and the nice examples
thatguy 2017-02-05 05:31:34
hpc, thank you too
lyxia 2017-02-05 05:33:00
ongy: If you want to provide custom specialized instances, you will need not only Overlapping, but also IncoherentInstances whenever you write code that just expects a Monad constraint while using Applicative.
lyxia 2017-02-05 05:33:27
ongy: and such code will not ever use the specialized instances
phadej 2017-02-05 05:33:33
thatguy: np
ongy 2017-02-05 05:34:15
it will not? I thought it's the smallest head or something? But thinking about that I see problems with a lot of instances
drostie 2017-02-05 05:34:32
ongy: remember that Monad f => Applicative f stores a dictionary for Applicative functions on every Monad type, so then if you custom-define your own Applicative you are providing two such functions for the computer to use and no guidance about which one it should actually select at runtime.
ongy 2017-02-05 05:35:31
afaik we have the {-# OVERLAPPABLE #-} macro for instance declarations in the new ghc versions, which I asumed lowers priority against any non-overlappable at least
drostie 2017-02-05 05:35:34
Then you get messy stuff like how CSS has a rule of "the more specific selector takes priority" which are huge nuisances in their own right, and like css you'll need to eventually implement the !important flag.
lyxia 2017-02-05 05:35:37
ongy: but when you are writing code over an abstract f (with only Monad f) there is no single most specific instance of Applicative that matches.
Welkin 2017-02-05 05:35:49
css is bullshit
Welkin 2017-02-05 05:36:01
inline styles are better
drostie 2017-02-05 05:36:22
right, like {-# OVERLAPPABLE #-}
ongy 2017-02-05 05:38:03
it worked well as far as I tried, but I only ever used it for type'd show instances (Show (Packet a)) and (Show (Packet Special))
drostie 2017-02-05 05:38:41
Whereas if you just had some functions inheritFmapFromMonad :: (a -> b) -> f a -> f b in your Monad class you would at least be able to reduce it to a one-liner. ^_^
lyxia 2017-02-05 05:38:56
ongy: it works when the type you are showing is concrete
drostie 2017-02-05 05:39:03
like Traversible does with foldMapDefault or whatever
lyxia 2017-02-05 05:39:03
I mean, not abstract
ongy 2017-02-05 05:40:55
oh, so if I have a function that's 'Monad m => m a' that's not specialised during compile that calls into another function 'Applicative a => a v'? Then I'd alwasy fall back? I hope I got it
lyxia 2017-02-05 05:43:08
Right.
lyxia 2017-02-05 05:43:18
ongy: http://lpaste.net/352109
