> > If you require the circuit to be parametric in the value types, you can > limit the types of function you can pass to arr to simple plumbing. > See the netlist example at the end of my "Fun of Programming" slides ( > http://www.soi.city.ac.uk/~ross/papers/fop.html). >
I'm running into this same issue: I have something (another circuits formulation) that's almost an arrow but doesn't support arr. I'd like to use arrow notation, but then I run afoul of my missing arr. I'd like to understand Ross's suggestion and how to apply it. (I've read the "FoP" slides.) Ross: do you mean to say that you were able to implement arr and thus run your circuit examples via the standard arrow desugarer? Ryan: did you get a working solution to the problem you described for your Circuit arrow? Thanks. -- Conal On Mon, Oct 31, 2011 at 6:52 PM, Paterson, Ross <[email protected]>wrote: > Ryan Ingram writes: > > Most of the conversion from arrow syntax into arrows uses 'arr' to move > components around. However, arr is totally opaque to the arrow itself, and > prevents describing some very useful objects as arrows. > > > For example, I would love to be able to use the arrow syntax to define > objects of this type: > > > data Circuit a b where > > Const :: Bool -> Circuit () Bool > > Wire :: Circuit a a > > Delay :: Circuit a a > > And :: Circuit (Bool,Bool) Bool > > Or :: Circuit (Bool,Bool) Bool > > Not :: Circuit Bool Bool > > Then :: Circuit a b -> Circuit b c -> Circuit a c > > Pair :: Circuit a c -> Circuit b d -> Circuit (a,b) (c,d) > > First :: Circuit a b -> Circuit (a,c) (b,c) > > Swap :: Circuit (a,b) (b,a) > > AssocL :: Circuit ((a,b),c) (a,(b,c)) > > AssocR :: Circuit (a,(b,c)) ((a,b),c) > > Loop :: Circuit (a,b) (a,c) -> Circuit b c > > etc. > > > Then we can have code that examines this concrete data representation, > converts it to VHDL, optimizes it, etc. > > > However, due to the presence of the opaque 'arr', there's no way to make > this type an arrow without adding an 'escape hatch' > > Arr :: (a -> b) -> Circuit a b > > which breaks the abstraction: circuit is supposed to represent an actual > boolean circuit; (Arr not) is not a valid circuit because we've lost the > information about the existence of a 'Not' gate. > > If you require the circuit to be parametric in the value types, you can > limit the types of function you can pass to arr to simple plumbing. > See the netlist example at the end of my "Fun of Programming" slides ( > http://www.soi.city.ac.uk/~ross/papers/fop.html). > _______________________________________________ > Haskell-Cafe mailing list > [email protected] > http://www.haskell.org/mailman/listinfo/haskell-cafe >
_______________________________________________ Haskell-Cafe mailing list [email protected] http://www.haskell.org/mailman/listinfo/haskell-cafe
