Helper function

[tomberek]

Ends up with issues due to Ambiguity errors.

terminal :: forall p a i b. (Weaken p a,HasLeftIdentity i p a) => a b i
terminal=fst  . (coidl :: a b (p i b))

Not sure where it should go. Other category package's structure organization: https://hackage.haskell.org/package/categories-1.0.7/docs/Control-Categorical-Object.html

[gelisam]

I don't understand which bug you are reporting. Are you saying that you wish that my category hierarchy was using terminal instead of fst and snd? Are you saying that it should be possible to define terminal without causing ambiguity errors? Are you proposing terminal to be added as a new category-syntax primitive, to make it more convenient for users of the library?

[tomberek]

I have come up against situations where it would be convenient to have a function like that. A variation can also be used to introduce new objects into the category. E.g:

terminal :: t -> a b t

proc a -> do
  b <- id -< a
  c <- id -< 4
  id -< (b,c)

can be converted to:

id &&& terminal 4 >>> id *** id >>> id

then optimized to:

id &&& terminal 4

or (depending on the category:

coidr >>> id *** terminal 4

[tomberek]

Like arr it is a way to introduce things into the category (in this case, objects, not morphisms). For Hask, () is a decent terminal object, but const can also create unique morphisms that point to a single value.

This is not a replacement for fst and snd but rather something that should already be almost possible with coidl >>> fst but more powerful because it can introduce new objects. For (->), terminal is basically const.

[gelisam]

I have come up against situations where it would be convenient to have a function like that.

Sure, but is there a compelling reason to add it to category-syntax itself? The goal of the project is to give a syntax for categories, by translating that syntax into a linear sequence of morphism, including those specified by the user and some structural morphisms threading the user's variables from definition to usage. I am reluctant to add convenience morphisms combining several of those structural morphisms, as the user is not at all intended to be programming using those underlying structural morphisms, but rather using the provided syntax.

A variation can also be used to introduce new objects into the category. E.g:

terminal :: t -> a b t

proc a -> do
  b <- id -< a
  c <- id -< 4
  id -< (b,c)

This variation is much more interesting. Do you have an example of a concrete category which supports this arr . const as a primitive but does not support arr?

[tomberek]

Almost cheating: https://www.reddit.com/r/haskell/comments/2e0ane/category_with_fanout_and_split_but_not_an_arrow/

data Circuit x y where
  Terminal :: y -> Circuit x y
  Wire   :: Circuit x x
  (:>>>) :: Circuit x y -> Circuit y z -> Circuit x z
  (:&&&) :: Circuit x y -> Circuit x z -> Circuit x (y,z)
  (:***) :: Circuit w x -> Circuit y z -> Circuit (w,y) (x,z)

id, (.), and terminal are obvious. Not sure how to make arr. Terminal 4 >>> Wire is a Circuit that always produces a 4. Terminal 5 >>> Wire &&& Wire is a Circuit that produces (5,5)

It's a way to introduce a new object, so perhaps "terminal" is not the right categorical term.

[gelisam]

Almost cheating: https://www.reddit.com/r/haskell/comments/2e0ane/category_with_fanout_and_split_but_not_an_arrow/

While that discussion talks at length about terminal objects (which I don't think category-syntax needs since it has fst and snd), I could not find any reference to your arr . const variation.

data Circuit x y where
  Terminal :: y -> Circuit x y
  Wire   :: Circuit x x
  (:>>>) :: Circuit x y -> Circuit y z -> Circuit x z
  (:&&&) :: Circuit x y -> Circuit x z -> Circuit x (y,z)
  (:***) :: Circuit w x -> Circuit y z -> Circuit (w,y) (x,z)

At first I thought you were quoting from that thread, but I can now see that it's a new data type you just made up, to give an example of a datatype which supports arr . const but not arr. That makes me realize that asking for a "concrete" example did not adequately describe what I am looking for. It's of course possible to define an example data type which supports any random rule (say, converting from Int to String), but that doesn't demonstrate that the rule occurs often enough to deserve special attention. By a "concrete" example, I meant an example encountered in the wild, preferably several examples, preferably very different from each other.

By the way, my existing type class hierarchy hasn't seen extensive real-world usage yet (category-syntax is far from done and as far as I know, nobody is actually using it), and so it is quite likely that it will change, possibly by adding things like const . arr. I just don't want to add something without a compelling reason to do so.

It's a way to introduce a new object, so perhaps "terminal" is not the right categorical term.

I agree. How about "generalized const", or constC for short?