I’m lacking a lot of CT vocabulary to understand the linked page fully, but I think it starts to make some intuitive sense to me đź™‚

]]>> J is a â‹„-monoid and I is a â‹†-comonoid

but J and I are the identities of the two monoids, and when itâ€™s â€śnormalâ€ť, J == I, and in the case of Applicative/Monad, J == I == Identity, and Identity is both a monoid and comonoid in the category of endofunctors.

And in https://ncatlab.org/nlab/show/duoidal+category#examples, it talks about â€śThe category C=[V,V]C=[V,V] of endofunctorsâ€ť and names *Set* and composition & Day convolution.

]]>> Applicative and Monad form a united monoid like

> (Type â†’ Type, Day, Compose, Identity), right?

I think so, yes! But I don’t yet see how this is related to duoidal categories.

]]>If thatâ€™s true, then Applicative and Monad form a united monoid like (Type â†’ Type, Day, Compose, Identity), right?

]]>Could you clarify in which sense `Either (MultiSet a) b` is a united monoid, and `Either (NonEmpty a) b` isn’t?

By the way, I have some progress in proving that Applicative and Monad are united monoids, and even algebraic graphs! Here is some work-in-progress code:

https://github.com/snowleopard/united/blob/master/src/Data/Functor/United.hs

I plan to write a follow-up blog post about this soon.

]]>Your earlier comments about potential links between the algebra of graphs and applicative functors and monads were one of the motivating factors behind this blog post, so thank you =)

> That is, with the sequential instance being

> the additive operation and the parallel

> instance being the multiplicative.

I guess it should be vice versa: parallel ~ additive, sequential ~ multiplicative, because we require that the additive (overlay) structure forms a commutative monoid.

I haven’t managed to implement anything yet, I’m still at the stage of exploring and writing down some rather abstract ideas, like in this blog post. Please let me know if you come up with anything that is more concrete!

]]>Iâ€™m curious whether these relationships form â€śunited monoids in the category of endofunctorsâ€ť, with `(S, +, â‹…, e)` as something like `Semigroup a => (Either a, liftA2, liftA2 . eitherToValidation, pure)` and similarly with `(IO, liftA2, liftA2 . Concurrently, pure)`.

That is, with the sequential instance being the additive operation and the parallel instance being the multiplicative. I havenâ€™t tried to formalize this, have at least implemented things that look reasonable. Iâ€™m very interested in what you think about it.

]]>I’m also glad you found the task/build abstractions from our paper useful! If you find a way to improve anything or introduce something new, feel free to open an issue/PR in the repository.

]]>I apologize for the state of the code, still very new to Haskell as I wrote this; I’ll clean it up a little bit this weekend. Some handwavy explanation follows.

The graph consists of some labeled “situations” and “transitions” between these situations.

A situation `e (Maybe x)` represents some possible state of the world, where we can effectfully compute whether we are in the situation (and if so, obtain some information `x` associated with the situation).

A transition into a situation consists of the labels of some prerequisite situations `c k`, and an effectful function `c x -> e x` which consumes information available in prerequisite situations and effectfully brings the world into conformity with the desired situation. The `c` here is some abstract container (e.g. a map/list/record).

Given a situation graph that we perhaps declaratively read from config and some desired situation, we can first check whether we’re already in that situation. If we’re not, we can look at all the transitions that bring us into the current situation, and examine *their* prerequisite situations (possibly using additional metadata to weight the transitions, and preferring transitions for which most prerequisites are already satisfied). If there are no transitions for which the prerequisites are satisfied, we recursively look at transitions that might bring us to the prerequisites (and so on, …).

A small demonstration of a situation graph for creating some folder structure (and cleaning it) is in the file.

At any rate, now that I’ve read about the task abstraction and your synthesis of build tools into this conceptual framework, I think I have a much nicer basis to start working from. The old model was a useful idea but it much too complicated and specific.

]]>By the way, I’ve done some further research on build systems after this blog post. Here is the latest paper which provides a good overview and comparison of many build systems and their algorithms: https://dl.acm.org/citation.cfm?id=3236774.

]]>Also thanks a lot for the reference to `assemble` and `Finite`. This is something that might come in handy in my work on selective functors (https://blogs.ncl.ac.uk/andreymokhov/selective).

]]>When I read this I wondered if you could derive one from the other using the algebraic structure of ADTs (“algebra of algebraic data types”), to go from one to the other but of course that doesn’t work:

(1 + (fv ^ (fv ^ k))) ^ k

((1 + fv) ^ k) ^ (fv ^ k)

And I’m sure the existentially quantified term needs to be treated differently, but no idea how. In any case I would be really interested if there was some way to reason algebraically either to determine that there must exist some isomorphism to Task2, or to derive the implementation.

In poking at this I did notice a couple things that might not really be that interesting…

First, as you probably knew `toTask` doesn’t require any constraint, and this definition is a little more terse:

toTask :: Task2 Unconstrained k v -> Task Unconstrained k v

toTask = flip . fmap sequenceA

For a second I was excited thinking that we could have:

fromTask :: Task Unconstrained k v -> Task2 Unconstrained k v

fromTask = fmap sequenceA . flip

But that of course is impossible, since we can’t have Traversable ((->) a)

On a whim though a hayoo search turned up http://hackage.haskell.org/package/countable-1.0/docs/Data-Searchable.html#v:assemble

So I guess an alternative would have `(f v)` and `k` both be constrained to `Finite` but that’s probably not useful at all.

]]>