Deep embeddings and Arrows Re: Uniquable RdrName instance
R.Paterson at city.ac.uk
Wed Jun 18 00:06:09 UTC 2014
On Tue, Jun 17, 2014 at 03:10:14PM -0400, Carter Schonwald wrote:
> to clarify: having bind would be equivalent to having arr for the
> purposes of my question (assuming its the standard monadic bind).
> having arr :: (b -> c) -> a b c
> is tantamount to assuming that any haskell function can be embedded in
> an arrow instance which prevents a lot of interesting deep embedding
> uses of the Arrow abstraction/ or at least makes it a bit tricker.
> (eg things like writing circuits or certain types of compiled FRP models).
I have two answers:
First, it's not that difficult using the Arrow class. For example,
see the netlist example at the end of my "Fun of Programming" slides
(http://www.soi.city.ac.uk/~ross/papers/fop.html). The idea is that arr
can take any function, but if you require the circuit to be parametric
in the value types, you can limit the types of function the programmer
can pass to arr to simple plumbing.
Second, suppose we split
arr :: forall b c. (b -> c) -> a b c
into two primitives
(^>>) :: forall b c d. (b -> c) -> a c d -> a b d
id :: forall b. a b b
Arrow notation relies on (^>>) being a contravariant functor -- that's
what allows the translation to manipulate environments, and it gives you
a substitution property for commands. On the other hand it doesn't need
id (or equivalently returnA). Perhaps the problem is the universally
quantified b in the type of id. One might instead use a variant of id
constrained to an ADT with just the operations you want.
More information about the ghc-devs