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

apfelmus schrieb:

Benedikt Huber wrote:

...

So, the Ref deriviation is really nice for sequential updates; parallel updates on the other hand need some work. .. While the select part of the Ref is expressed using &&&, I don't know how the parallel update can be expressed in terms of combinators. Any hints ?

You can't do that, and for good reason! While

players :: Lens Game (Player,Player)

is entirely fine since Game ~ (Player,Player,Object2D), there cannot be a general parallel combinator

(&&&) :: Lens a b -> Lens a c -> Lens a (b,c)

Thanks for the nice overview. I see there can't be a general purpose combinator (&&&) for lenses. One could still define a helper function though: combineDisjoint :: Lens a b -> Lens a c -> Lens a (b,c) combineDisjoint l1 l2 = Lens $ select &&& update where select = (fst . focus l1) &&& (fst . focus l2) update cx (a,b) = flip (snd . focus l2) b $ (snd . focus l1) cx a which performs the first update using the initial context, and the second one using the updated context. Just to have a simple way of defining lensPlayers in term of lensPlayer1 `combineDisjoint` lensPlayer2. While it is not a (general purpose) combinator, it is still helpfull for combining lenses focusing on fields of a record. -- I just want to rephrase my question about paralell updates; it has more to do with records updates than with References / Lenses, though: Suppose we have a record data R = R { a:: A, b :: B, c :: C } deriving (Show {-! Ref !-}) and update functions fa :: a -> a, fb :: b -> b, fc :: c -> c Now the standard way to perform the update on R would be updateR = \r@(R {a=a,b=b,c=c}) -> r { a = fa a,b = fb b,c = fc c } which is 'a little bit' cumbersome. With update deriviations (like Update using DrIFT), references (Ref using Data.Derive) or lenses it is easy to perform the update sequentially (using DrIFT style for simplicity): updateR' = a_u fa . b_u fb . c_u fc But this corresponds to updateR' = (\f r -> r { a = f (a r) }) fa . (\f r -> r { b = f (b r) }) fb . (\f r -> r { c = f (c r) }) fc which (in some way) is not 'the same' as updateR. First, I (uneducatedly) guess that the record updates cannot be 'executed' in paralell, i.e. the record has to be deconstructed and build up again three times. And second, neither the types of the updates (e.g. a_u fa :: R -> R) nor the structure of updateR' (composing R->R functions) do reflect the fact that actually disjoint fields of the record are updated. Now I know there are great record proposals (which extend the haskell language or use some type hackery), but I wondered if there is also a solution which can be used right now and which works fine with the standard record types. I'll give a naive ad-hoc example to illustrate the idea. One could automatically derive the following data type and the associated functions for R: data R_upd = R_upd { updA :: A -> A, updB :: B -> B, updC :: C -> C } rUpd = R_upd id id id updR :: R_upd -> R -> R updR rupd r@(R { a=a,b=b,c=c }) = r { a = (updA rupd a), b = (updB rupd b), c = (updC rupd c) } which would allow to write things like updGame $ gameUpdate { updPlayer1 = increaseScore, updPlayer2 = decreaseScore }) Though simple, I hope it is possible to understand the idea (I know there is a lot of namespace pollution). And of course, someone has thought of something much more sophistacted already :) What are the drawbacks of such an approach ? thanks, benedikt