[Haskell-cafe] Re: is there a more concise way to generate helper functions for a datatype built on records?

[Isaac Dupree]

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