Home/ Questions/Q 967093
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-16T02:15:41+00:00

Coming to Haskell from a background in various OO languages, one thing that seems

  • 0

Coming to Haskell from a background in various OO languages, one thing that seems like a bit of a drawback to me is that function and field names aren’t scoped to the types they’re associated with, so it’s easy to run into clashes if different datatypes have fields with the same name.

If I have these three modules:

module One where

data Foo a = Foo { value :: a }

----

module Two where

data Bar a = Bar { value :: a }

----

module Three where

import One
import Two

foo = Foo { value = 42 }  -- compile error here
n = value foo  -- and here

the unqualified references to value in module Three are considered ambiguous even though only one of the two imported names makes sense in this context. (In an OO language, references to foo.value and bar.value would be unambiguous.)

Of course I can disambiguate by writing Foo { One.value = 42 }, but that looks awkward. I can also name the fields differently, e.g. “fooValue” and “barValue”, but the redundancy in Foo { fooValue = 42 } looks awkward as well.

This is really a special case of the more general issue of functions in different modules that have the same name but operate on different, unrelated types. I seem to run into it more often with field names, though. For example, I have several datatypes, not related by a type class but often used together, that contain color values, so I’d like each one to have a field named “color”.

How do experienced Haskell developers name things, and organize them into modules, to avoid this type of situation?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    The GHC extension -XDisambiguateRecordFields will allow foo = Foo { value = 42 } (but not n = value foo).

    There’s a large body of literature on the shortcomings of Haskell’s current record system and candidates for its replacement, as well as a handful of libraries that attempt to provide nicer solutions now. fclabels is the only one that I’ve used personally.

    This StackOverflow question is similar, and some of the answers there might also be useful for you.

    This is really a special case of the
    more general issue of functions in
    different modules that have the same
    name but operate on different,
    unrelated types.

    Qualified imports and aliases are usually enough to solve this problem.

    • 0