eassoc :: Either x (Either y z) -> Either (Either x y) z
eassoc = ...
f, g :: Fill p => Either (p c d) (Either (p b c) (p a b)) -> p a d
f = fillInTheBlank . second fillInTheBlank
g = fillInTheBlank . first fillInTheBlank . eassoc
-- Law: f = g
Is this dual to composition? It feels like sort of "pipeline extension" - like ability to extend some arrow doing something useful "further", without changing it's actual effect
I’m tempted to say there’s not many things in Hask have a useful operation here. Tuple, Either, These, and (->) are all out.
I mean, where does the information from b go? With normal composition we are able to use one b to plug into the other b, but when we’re only given one _or_ the other to work with, I’m not sure what to do with it, especially since we then need to somehow come up with a p that uses a or c when we don’t have one of those lying around.
Wait.
If we rephrase it, we have fillL : p b c -> p a c and fillR : p a b -> p a c, and this essentially says that both arguments are phantom, so nothing interesting satisfies it. q.e.d.
@Nicholas Scheel I definitely don't think the operation is impossible to implement. If anything it's too easy to implement. E.g. the identity for it assumes the form:
ez :: Void -> p a a
which is trivial to implement, it's always just absurd.
Can anyone think of any type constructors which have a useful implementation of:
The law for that class is:
i swear you are the modern ekmett
"here is some code i wrote. does anyone know what it might be good for?"
next time we hang out i'd love to see where these things come from :)
which is when? :P
we almost got around to it last time but then we started talking about rap songs
Is this dual to composition? It feels like sort of "pipeline extension" - like ability to extend some arrow doing something useful "further", without changing it's actual effect
And
id :: p a a
would be base from which you can build "non-effectful" arrows? :big_smile:Asad Saeeduddin said:
i blame the "sandy almost died" part for that
not sure when. ever been to victoria?
nope. is that where you're at now?
yup
with a year long lease
so probably for some time
@TheMatten it's a "coproduct enriched" category (normal categories are product enriched)
I’m tempted to say there’s not many things in Hask have a useful operation here. Tuple, Either, These, and (->) are all out.
I mean, where does the information from
b
go? With normal composition we are able to use oneb
to plug into the otherb
, but when we’re only given one _or_ the other to work with, I’m not sure what to do with it, especially since we then need to somehow come up with ap
that usesa
orc
when we don’t have one of those lying around.Wait.
If we rephrase it, we have
fillL : p b c -> p a c
andfillR : p a b -> p a c
, and this essentially says that both arguments are phantom, so nothing interesting satisfies it. q.e.d.Wait, I guess there is at least one thing that satisfies it:
TupleMaybe a b = TupleMaybe (Maybe a) (Maybe b)
. I think it’s associative ...It still seems very weird to me.
Challenge: is there anything that does NOT admit a function
empty : forall a b. p a b
?@Nicholas Scheel I definitely don't think the operation is impossible to implement. If anything it's too easy to implement. E.g. the identity for it assumes the form:
which is trivial to implement, it's always just
absurd
.regarding the challenge, yes: