[Haskell-cafe] arr considered harmful

Conal Elliott conal at conal.net
Fri Dec 21 21:38:32 CET 2012


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 <ky3 at atamo.com> 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 <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
>>>
>>
>>
>> _______________________________________________
>> 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/abcbaab2/attachment.htm>


More information about the Haskell-Cafe mailing list