apfelmus wrote:
Benedikt Huber wrote:
> type Upd a = a -> a
> data Ref cx t
> = Ref { select :: cx -> t , update :: Upd t -> Upd cx }
Functional references are also called "lens", I'm going to use that term
from now on.
As a minor note, I somehow prefer a single primitive
data Lens s a = Lens { focus :: s -> (a, a -> s) }
nice name.
there cannot be
a general parallel combinator
(&&&) :: Lens a b -> Lens a c -> Lens a (b,c)
with for example
players = player1 &&& player2
That's because the two arguments might not be parallel at all. For
instance, consider
dup :: Lens a (a,a)
dup = id &&& id
Which component of the pair should
put dup :: a -> (a,a) -> (a,a)
change? The first, the second, or even both?
>
> put :: Lens s a -> a -> s -> s
> put x = flip $ snd . focus x
wouldn't
put dup :: (a,a) -> a -> a
?
Arrows IIRC resolve this dilemma by arbitrarily saying the first
argument of (&&&) takes effect first... a solution I'm not entirely
happy with. Here, first it would put the first element of the pair,
then it would put the second, so the result would be the second element.
If it were 2d vectors, x::Lens Vector Double, angle::Lens Vector
Angle, it makes a difference whether x-coordinate or angle is changed
first, and again, (&&&) could sequence.
I wish there was some way to compose them that guaranteed
order-independence, and didn't work otherwise, though. I suppose
QuickCheck could be used to catch most
parallel/disjoint-assumption-mistakes like that...
Isaac
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
