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

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Reply via email to