Oh, I see Ross's trick. By quantifying over the domain & range types, they can later be specialized to analysis-time types (like circuit labels) or to run-time types (like Boolean or Integer).
On Thu, Dec 20, 2012 at 4:55 PM, Conal Elliott <co...@conal.net> wrote: > 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 <r.pater...@city.ac.uk>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 >> Haskell-Cafe@haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> > >
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe