Question

I have two data types, which are used for hastache templates. It makes sense in my code to have two different types, both with a field named “name”. This, of course, causes a conflict. It seems that there’s a mechanism to disambiguate any calls to “name”, but the actual definition causes problems. Is there any workaround, say letting the record field name be qualified?

data DeviceArray = DeviceArray
    { name :: String,
      bytes :: Int }
    deriving (Eq, Show, Data, Typeable)

data TemplateParams = TemplateParams
    { arrays :: [DeviceArray],
      input :: DeviceArray }
    deriving (Eq, Show, Data, Typeable)

data MakefileParams = MakefileParams
    { name :: String }
    deriving (Eq, Show, Data, Typeable)

i.e. if the fields are now used in code, they will be “DeviceArray.name” and “MakefileParams.name”?

Answer 1

As already noted, this isn’t directly possible, but I’d like to say a couple things about proposed solutions:

If the two fields are clearly distinct, you’ll want to always know which you’re using anyway. By “clearly distinct” here I mean that there would never be a circumstance where it would make sense to do the same thing with either field. Given this, excess disambiguity isn’t really unwelcome, so you’d want either qualified imports as the standard approach, or the field disambiguation extension if that’s more to your taste. Or, as a very simplistic (and slightly ugly) option, just manually prefix the fields, e.g. deviceArrayName instead of just name.

If the two fields are in some sense the same thing, it makes sense to be able to treat them in a homogeneous way; ideally you could write a function polymorphic in choice of name field. In this case, one option is using a type class for “named things”, with functions that let you access the name field on any appropriate type. A major downside here, besides a proliferation of trivial type constraints and possible headaches from the Dreaded Monomorphism Restriction, is that you also lose the ability to use the record syntax, which begins to defeat the whole point.

The other major option for similar fields, which I didn’t see suggested yet, is to extract the name field out into a single parameterized type, e.g. data Named a = Named { name :: String, item :: a }. GHC itself uses this approach for source locations in syntax trees, and while it doesn’t use record syntax the idea is the same. The downside here is that if you have a Named DeviceArray, accessing the bytes field now requires going through two layers of records. If you want to update the bytes field with a function, you’re stuck with something like this:

addBytes b na = na { item = (item na) { bytes = b + bytes (item na) } }

Ugh. There are ways to mitigate the issue a bit, but they’re still not idea, to my mind. Cases like this are why I don’t like record syntax in general. So, as a final option, some Template Haskell magic and the fclabels package:

{-# LANGUAGE TemplateHaskell #-}

import Control.Category
import Data.Record.Label

data Named a = Named 
    { _name :: String, 
      _namedItem :: a }
    deriving (Eq, Show, Data, Typeable)

data DeviceArray = DeviceArray { _bytes :: Int }
    deriving (Eq, Show, Data, Typeable)

data MakefileParams = MakefileParams { _makefileParams :: [MakeParam] }
    deriving (Eq, Show, Data, Typeable)

data MakeParam = MakeParam { paramText :: String }
    deriving (Eq, Show, Data, Typeable)

$(mkLabels [''Named, ''DeviceArray, ''MakefileParams, ''MakeParam])

Don’t mind the MakeParam business, I just needed a field on there to do something with. Anyway, now you can modify fields like this:

addBytes b = modL (namedItem >>> bytes) (b +)
nubParams = modL (namedItem >>> makefileParams) nub

You could also name bytes something like bytesInternal and then export an accessor bytes = namedItem >>> bytesInternal if you like.