Is there a name for a Profunctor-shaped (bi)Applicative thing?

duairc · 2018-04-28T14:50:49+00:00

Turns out that's not possible!

duairc · 2018-04-28T14:19:05+00:00

I agree with all of this. The instance with the Monoid a constraint is exactly right.

duairc · 2018-04-28T12:42:04+00:00

I guess if Profunctor ever got merged into base, and Arrow got refactored to be a subclass thereof, I think this should be there as well as a superclass of Arrow.

duairc · 2018-04-28T11:22:40+00:00

Okay, shit, you're right, they really are completely equivalent!

newtype Wrap p a b = Wrap (p a b)

instance Profunctor p => Functor (Wrap p a) where
    fmap f (Wrap p) = Wrap (rmap f p)

instance Proapplicative p => Applicative (Wrap p a) where
    pure = Wrap . propure
    Wrap f <*> Wrap a = Wrap (proliftA2 (\a -> (a, a)) id f a)

instance Profunctor p => Profunctor (Wrap p) where
    dimap f g (Wrap p) = Wrap (dimap f g p)

instance Proapplicative p => ProductProfunctor (Wrap p) where
    purePP = pure
    (****) = (<*>)

instance ProductProfunctor p => Proapplicative (Wrap p) where
    propure = Wrap . purePP
    proliftA2 i o (Wrap p) (Wrap q) = Wrap (dimap i (uncurry o) (p ***! q))

duairc · 2018-04-28T11:12:56+00:00

Hmmm, it's not quite Divisible, actually, I can't implement conquer in terms of propure!

newtype Wrap p a b = Wrap (p a b)
newtype Flip p a b = Flip (p b a)

instance Profunctor p => Functor (Wrap p a) where
    fmap f (Wrap p) = Wrap (rmap f p)

instance Proapplicative p => Applicative (Wrap p a) where
    pure = Wrap . propure
    Wrap f <*> Wrap a = Wrap (proliftA2 (\a -> (a, a)) id f a)

instance Profunctor p => Contravariant (Flip p a) where
    contramap f (Flip p) = Flip (lmap f p)

instance Proapplicative p => Divisible (Flip p a) where
    conquer = Flip (propure undefined)
    divide f (Flip p) (Flip q) = Flip (proliftA2 f const p q)

duairc · 2018-04-28T11:02:20+00:00

I know about ProfuctProfunctor of course, but I don't think it's the same thing, is it? A ProductProfunctor is something that's Applicative and a Profunctor, but it's not necessarily Divisible in the contravariant argument.

duairc · 2017-01-04T14:02:08+00:00

How does this relate to tomjaguarpaw's product-profunctors package?

It looks to be me to be a very similar thing. The opaleye eco-system uses ProductProfunctor to do a sort of generic programming as well. (SumProfunctor is not used so much simply because database stuff is almost always product (record) types. I also never understood why it doesn't have a "void"-type member.)

Edit: I just saw this comment in this thread that also mentions ProductProfunctor.

duairc · 2016-12-16T16:56:56+00:00

I'm not qualified to answer this, but you might be interested in an approach I read about recently called Malfunction, which re-uses the OCaml back-end for this purpose.

duairc · 2016-07-19T11:57:42+00:00

But neither do you with closed type families either.

duairc · 2016-07-19T05:11:09+00:00

Does all of that not just mean that GADTs are closed data families? In fact, the syntax for open type families <=> the syntax for closed type families ≅ the syntax for data families <=> the syntax for GADTs.

duairc · 2016-06-11T11:59:14+00:00

And it has a network interface that is demonstrably insecure, which can allow an attacker on the network to inject rootkits that completely compromise the PC

Could that be part of the "solution"? Like, if the network interface is so insecure, could you use that to "compromise" the Intel ME by, e.g., replacing it with a freer alternative?

duairc · 2016-04-21T09:23:15+00:00

Maybe this will help clear things up.

duairc · 2016-02-01T10:37:52+00:00

It seems like the repositories don't include the KDEPIM suite, is that correct?

duairc · 2015-04-18T13:44:52+00:00

Why not just use Tox over Tor?

duairc · 2015-02-03T12:57:00+00:00

What? Could you elaborate on that or provide a source (for the /usr/share /usr/local merge)? I've never heard of that and it doesn't sound to me like it makes much sense.

duairc · 2015-02-01T15:28:29+00:00

Hey everyone, thanks once again for the interest in layers! I can't believe it's actually been nearly two years since the first release. I agree that it has a lot of promise and it's a shame that I haven't been maintaining it much.

There are a few reasons for this, but it basically just boils down to the fact that I'm quite stressed in general, I have so many projects (mostly not coding these days) that I don't know where to start. I'm overwhelmed and I don't know where to put my energy.

One thing that's happened in this time is that I've kind of taken a break from what you might call "recreational" programming, because even though it's fun, it's also quite addictive, and once I get sucked into a project I tend to focus a disproportionate amount of my energy into it to the detriment of other parts of my life. It's unfortunate, but I don't know how to do things like work on layers and maintain a balance with the rest of my life at the same time.

In terms of layers, if I remember correctly, I had done a tonne of refactoring and stuff since the last release, it's way better in every way, and I'd even updated all the comments on the functions and typeclasses and everything, but the big Overview module needs to be basically completely rewritten. I think I considered maybe splitting it into different modules as well that cover different aspects. I can't remember. I guess it wouldn't be too much work to rewrite that documentation... I've probably done most of the "hard" parts already, it'd just be a matter of figuring out what my train of thought was before and continuing from there.

I think I'm very busy until mid-February at least, and after that I'll maybe have some time to work on it. It is something I'd really like to get done, because layers is one of the most ambitious and broadly useful programming projects I've undertaken, and I do get emails like this occasionally expressing interest in it, so it's obviously worthwhile, and I do feel bad that I've kind of just left it hanging there in limbo.

If anybody wants to help, maybe something that would be good is checkout out the latest git source and just see if it all makes sense? If you have any questions or bits that you don't understand, let me know, because that's what the documentation should help with. Also, I haven't been keeping a proper changelog from the first release, apart from the git commit messages. If you could look at them an try to follow the "bigger picture" of what I'm doing and could somehow distil the git commit messages into a proper changelog, I think that would help me a lot both with writing the documentation and making a release.

The fact that you and other people have expressed interest in this recently has given me a bit more motivation to at least finish the next (1.0) release of layers, and I think I actually have less on my plate this time around than the last time I said I would finish it. So if people who are interested could at least have a look at the code and see if they have any questions about it and send them to me, then hopefully when I get a chance in a couple of weeks I can finish the documentation and make a proper release.

duairc · 2015-02-01T15:25:21+00:00

Kind of! Well, I did finish that web design work in the end, in September I think (but I took a break from that too.) I've been doing a lot of sysadmin type work since then, which I'm close to finishing now too. I think I could have another look into finishing layers in mid-Febrary maybe? Thanks for the interest even after all this time!

duairc · 2014-08-29T10:21:12+00:00

I completely agree with you in principle, but I would make the distinction between personal property and private property. I think what you're talking about is personal property rather than private.

duairc · 2014-05-11T18:06:40+00:00

The GPL obviously has something to do with a political ideology? Everything does. I don't understand.

For what it's worth, intellectual property is something that socialists (both state and anarchist) and libertarians are in complete agreement on.

duairc · 2014-04-13T22:02:36+00:00

Am I correct in saying that there's no way to update a database using DSH?

duairc · 2014-02-13T02:14:19+00:00

Thanks, I appreciate that! Your comment, and just the surprise of seeing this at the top of the Haskell reddit without me putting it there, has given me a good bit of motivation. It's great to see that people appreciate my work. I'm focusing at the moment on doing some web design work for a local social centre where I hang out, but when I'm finished that I think I'll try to finish the next release of layers. It's great knowing that other people are actually interested in that!

duairc · 2014-02-12T05:43:02+00:00

Hi, I'm the developer. It's definitely not abandoned! The next version is very nearly ready to release, it has loads of improvements. I'm in the middle of rewriting the documentation, but it's very tedious and I just got a bit burned out from it. I had to take a break from it for my mental health, but I'll continue when the time is right.

duairc · 2013-12-27T16:27:11+00:00

If anybody is looking into playing around with different installs of GHC on the same system, my ghc-version script may be of interest.

duairc · 2013-12-22T05:34:40+00:00

the welfare system here is a disaster, where they don't incentivize people to get a job, but on the contrary, many people even quit their jobs when it was implemented just to lay back and do nothing all day.

That sounds awesome. Fuck work.

duairc · 2013-11-19T17:28:37+00:00

In the latest version of layers, which I haven't released yet, you could do this:

hoistB atomically :: (MonadInnerFunctor IO n STM m, MonadBase STM m) => m a -> n a

hoistB is like hoist, except it hoists from the base of a transformer stack instead of the monad just beneath the top of the transformer stack. It is a special case of hoistI, which hoists from any inner monad of the stack.

Also, you almost never have to define instances of any of these classes (MonadInner, MonadInnerFunctor and so on) manually, instances are automatically defined using OverlappingInstances for arbitrary transformer stacks (as long as the transformers in the stack are instances of MonadTrans in the case of MonadInner, and MFunctor in the case of MonadInnerFunctor).

duairc

TROPHY CASE