[Haskell-cafe] arr considered harmful
Conal Elliott
conal at conal.net
Fri Dec 21 09:08:44 CET 2012
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 <conal at 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.Paterson at 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 at haskell.org
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20121221/5b7336f3/attachment.htm>
More information about the Haskell-Cafe
mailing list