What's the Haskell way of using the same name for two different value constructors?-CodePudding

Let's say I want to model to-dos agreed upon between a manager and an employee in a one-on-one. A to-do might have to be realized by either the manager or the employee. Let's say I want to process some data about an employee, so I model the employee like this:

data Employee = Employee
  { id :: Int
  , name :: String
  }

Let's further say I'd model my to-dos like this:

data Todo = Todo
  { id :: Int
  , text :: String
  , realizedBy :: RealizedBy
  }

I'd find it most elegant to model the RealizedBy-type like this:

data RealizedBy = Manager | Employee

Of course, this is will not compile, as there are Multiple declarations of `Employee'.

A solution I came up with would be to not define a RealizedBy-type, but to model it like this:

data TodoContent = TodoContent
  { id :: Int
  , text :: String
  }

data Todo = ManagerTodo TodoContent | EmployeeTodo TodoContent

To me, this seems a bit over-engineered. To me, having to repeat TodoContent is not that elegant. Also, I can't think of better names than Employee for either the type or the parameterless constructor (or whatever that's called) that would model the data as well. I can't shake the feeling that I might be missing something obvious that would solve this more elegantly. Am I, or is this really the way it's meant to be modeled in Haskell?

CodePudding user response：

Haskell has just one mechanism for namespacing of data declarations, its module system. You can use it here.

module Classifications where

data RealizedBy = Manager | Employee

module Entities where

import qualified Classifications as C

data Employee = Employee Int String
data Todo = Todo Int String C.RealizedBy