Statically-typed read-only attributes

I have tried to create read-only attributes in htoolkit. It's easy, as 
any of you will already know:

------------------------------------------
class GetterAttr attr where
    getterAttr :: attr a b -> a -> IO b
                                                                                                                         
instance GetterAttr Attr where
    getterAttr (Attr getter setter) = getter
                                                                                                                         
data RAttr w a = RAttr (w -> IO a)
                                                                                                                         
instance GetterAttr RAttr where
    getterAttr (RAttr getter) = getter
                                                                                                                         
-- | Get an attribute
get :: (GetterAttr attr) => w -> attr w a -> IO a
get w a = getterAttr a w
                                                                                                                         
-- | Define a read-only attribute. Takes the name of the attribute as 
its first argument.
readAttr :: (w -> IO a) -> RAttr w a
readAttr getter
  = RAttr getter

--- The rest is in Attr.hs-------------------------------------


I have managed to compile htk with this modification, however it turns 
out that there are classes in htk like

-- | Widgets that has specified integer position.
class Positioned w where
  -- | The widget position
  pos :: Attr w Int

Now, a programmer finding an instance of this class will think that he 
can move the object by setting the attribute. But menus are the only 
instance of this class, wich I changed to pos::Rattr w Int, because 
menus can't be moved.

This raises the problem: what if I have also "instance Positioned 
Window"? Well, this problem has many solutions, the simplest of wich is 
*not* to have statically read-only attributes. I would rather try other 
solutions, however they might complicate the class and type hierarchy.

What do you all think about this?

Vincenzo