Comments on: Circuits as a bicartesian closed category

By: Kari

Kari — Fri, 20 Sep 2013 09:50:55 +0000

Dan Ghica has suggested symmetric monoidal closed categories as models for circuits (http://www.cs.bham.ac.uk/~drg/papers/popl07x.pdf). He introduces specific categories ‘Category of handshake circuits’ HC and another called SHC.

I don’t know how these compare to the ‘Circuit Category’ C (Kleisli CircuitM (Pins a) (Pins b)).

By: Sjoerd Visscher

Sjoerd Visscher — Tue, 17 Sep 2013 22:01:50 +0000

The methods I use for CCCs in data-category are:

apply ∷ (a ⇨ b) × a ↝ b
tuple ∷ a ↝ (b ⇨ (a × b))
(^^^) ∷ (a ↝ b) → (d ↝ c) → ((c ⇨ a) ↝ (d ⇨ b))

with curry f = (id ^^^ f) . tuple and uncurry f = apply . (f *** id).

(^^^) is analogous to (+++) and (***).

By: Ryan

Ryan — Tue, 17 Sep 2013 17:23:58 +0000

I think you can derive uncurry as uncurry f := apply . (f * id). When f := curry f', you obtain that curry and uncurry are inverses by beta.

By: Tom Ellis

Tom Ellis — Tue, 17 Sep 2013 15:57:29 +0000

I have had a lot of success with a "wiring diagram" API based on arrows that I am using to write relational queries and compile them to SQL. The inspiration was David Spivak's The operad of wiring diagrams: formalizing a graphical language for databases....

I have managed to avoid type instances and "IsSource" constraints with what seems to be a cunning trick. I used Wire rather than Pins, and instead of requiring Wire to be the type constructor in front of every datatype that represents connectors, I just store Wires in any Haskell datatype, so for example we have plus :: QueryArr (Wire Int, Wire Int) (Wire Int) and restrict :: QueryArr (Wire Bool) ().

The definition is data Wire a = Wire String, where the string field is the column name of a database table. Typesafety is provided by ensuring that you can only produce a Wire in the context of a table which contains a column which is referred to in the Wire.

This approach has worked very well. I haven't considered coproducts, but would probably fake them up by representing A + B ~> X as (A ~> X, B ~> X) rather than trying to construct A + B itself.

By: Tom Ellis

Tom Ellis — Tue, 17 Sep 2013 15:14:06 +0000

I belive Warbo's observation about selecting which output you want to keep corresponds to the identification of A + B -> X with (A -> X, B -> X).

By: Jacques Carette

Jacques Carette — Tue, 17 Sep 2013 14:38:12 +0000

I believe that the fundamental reason you are not able to implement inl/inr without constraints is that the implementation fundamentally assumes that a and b are Finite [that's what numPins forces]. Which is a perfectly fine assumption, but it is not one which is 'native' to Category. It might be expedient to make that assumption, and work over a finite category, which you can here define as one which has a map from all objects to Nat. You'll probably want a comonoid structure as well, which decomposes objects (aka toPins).

By: ao

ao — Tue, 17 Sep 2013 11:47:34 +0000

I wonder if you tried looking into Temperley-Lieb categories (eg. http://www.math.helsinki.fi/logic/sellc-2010/course/final.pdf)?. There is a neat way to represent sums, evaluate (simply typed) lambda calculus, not to mention that representing them as circuits is as straight-forward as it gets

By: Warbo

Warbo — Tue, 17 Sep 2013 11:05:22 +0000

Having both sides of a sum use the largest number of pins reminds me of studying ALU design at University. Rather than selecting which circuit (operation) to send data to, we would send it to all circuits and select the output we want to keep.

The type-unsafe scariness may come from the fact that this is evaluated eagerly, so all operations will be performed even if they're meaningless, as long as we select the result of a meaningful operation.