The Future of Haskell discussion at the Haskell Workshop

[Robert Ennals]

> Hi!
> 
> > So in summary, here is my proposal:
> > 
> > No specific "extensible records" system.
> > 
> > Define record update to be a function just like record selection is.
> > 
> > Allow these functions to be in type classes.
> 
> I do not understand the second and third point: As I understand your
> idea, record selectors and updaters should still be defined by the
> datatype declaration. What does it then mean that they be "allowed"
> to be defined in type classes? Would that happen automatically?

I was thinking of something along the following lines:


class Wibble a where
    wibble :: a -> Int
    wobble :: a -> String
    set_wibble :: Int -> a -> a
    set_wobble :: String -> a -> a


data Foo = Foo {wibble :: Int, wobble :: String}
	deriving Wibble


The Wibble class defines selector and updater functions for fields called 
wibble and wobble.

When I define the datatype Foo, I give it fields called wibble and wobble, 
which will define the functions in Wibble. If I say "deriving Wibble" then the 
type system acknowledges that these functions are implementing the class 
Wibble. If I had not derived Wibble then there would have been a name clash.


We could imagine the definition of Foo being automatically desugared to the 
following:

data Foo = Foo Int String

instance Wibble Foo where
    wibble (x,_) = x
    wobbble (_,y) = y
    set_wibble x (_,y) = (x,y)
    set_wobble y (x,_) = (x,y)




Note that Wibble is a normal class. I could thus implement Wibble in a class 
that was not a record. For example, the following, rather dull, implementation:

instance Wibble () where
    wibble () = 3
    wobble () = "hello"
    set_wibble _ _ = ()
    set_wobble _ _ = ()


Does that make things clearer?



-Rob