[Haskell-cafe] records proposals list

[Dimitry Golubovsky]

David Roundy wrote:


> 4. Getters for multiple data types with a common field.


[skip]


> 4. Getters for multiple data types with a common field.
> 
> This basically comes down to deriving a class for each named field, or
> something equivalent to it, as far as I can tell.  This also works with the
> namespace issue, since if we are going to define getters and setters as
> functions, we either need unique field labels or we need one class per
> field label--or something equivalent to a class for each field label.

This is a problem similar to one I had to solve for HSFFIG to design a 
syntax to access fields of C structures (where different structures may 
have fields of same name but of different types).

I ended up with a multiparameter class parameterized by a C structure 
name, field name, field type, and for each occurrence of these in C 
header file I autogenerated an instance of this class.

See

http://hsffig.sourceforge.net/repos/hsffig-1.0/_darcs/current/HSFFIG/FieldAccess.hs

for the class itself, and a typical instance (autogenerated of course) 
looked like

instance HSFFIG.FieldAccess.FieldAccess S_362 ((CUChar)) V_byteOrder where
   z --> V_byteOrder = ((\hsc_ptr -> peekByteOff hsc_ptr 0)) z
{-# LINE 5700 "XPROTO_H.hsc" #-}
   (z, V_byteOrder) <-- v = ((\hsc_ptr -> pokeByteOff hsc_ptr 0)) z v
{-# LINE 5701 "XPROTO_H.hsc" #-}

for a field `byteOrder' of type `unsigned char'.

This might work in general for what is proposed in the item 4 quoted 
above. A class with 3 parameters will be needed, and perhaps some 
syntactic sugar to autogenerate it and its instances. The only downside 
is GHC needs too much memory to compile all this: I had to add a 
splitter utility to HSFFIG otherwise GHC failed short of memory on even 
several tens of C structures.

Dimitry Golubovsky
Middletown, CT