Thanks, Kim-Ee. Adam M's garrows look very useful for what I'm doing. -- Conal
On Fri, Dec 21, 2012 at 5:14 AM, Kim-Ee Yeoh <[email protected]> wrote: > Hey Conal, > > > I have something (another circuits formulation) that's almost an arrow > but doesn't support arr. > > Have you seen Adam Megacz's generalized arrows? > > http://www.cs.berkeley.edu/~megacz/garrows/ > > > > -- Kim-Ee > > > On Fri, Dec 21, 2012 at 7:55 AM, Conal Elliott <[email protected]> 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 <[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 >> >> >
_______________________________________________ Haskell-Cafe mailing list [email protected] http://www.haskell.org/mailman/listinfo/haskell-cafe
