Функция, работающая с конечным, но произвольным числом разнородных элементов

Обобщенные алгебраические типы данных (GADT).

Они позволяют объединить конечное число действительно разнородных типов данных в один и представляют собой современный способ создания экзистенциальных типов. Они находятся где-то между подходом data Agent = AH Human | AP Plant | .... и подходом HList. Вы можете сделать все ваши невероятно разнородные агенты экземплярами некоторого класса типов, а затем связать их вместе в файле AgentGADT. Убедитесь, что в вашем классе типов есть все, что вы когда-либо захотите сделать с агентом, потому что трудно получить данные обратно из GADT без функции с явным типом; вам понадобится getHumans [AgentGADT] -> [Human]? или updateHumans :: (Human->Human) -> [AgentGADT] -> [AgentGADT]? Это было бы проще с обычным абстрактным типом данных в моем другом посте.

Плюсы: вы можете иметь [AgentGADT] и работать единообразно, используя функции класса, при этом создавая странные и чудесно параметризованные типы данных. Минусы - трудно получить данные вашего агента, когда они есть.

Моим любимым вступительным текстом в Интернете был GADT для чайников.

Гетерогенный. Я не думаю, что вы должны это делать, но вы просили.

Вы можете использовать существующую библиотеку для гетерогенных списков, например, HList. Это в любом случае тайно использует Template Haskell, но вам не нужно так пачкать руки, как если бы вы сделали это сами.

Языки с динамической типизацией имеют всевозможные проблемы из-за необходимости приведения типов и т. д. HList является типобезопасным, но, на мой взгляд, по-прежнему нелегко писать код, который хорошо работает и не содержит ошибок. Вы получаете преимущество над кортежами, потому что вам не нужно менять тип, и сопоставление ваших обновлений между элементами должно быть проще, но это все еще некрасиво.

Не становитесь гетерогенным. Это того не стоит. Стоит найти лучший способ. Вот один из способов избежать этого. (Есть и другие пути.) Может быть произвольное количество агентов, но, конечно же, не может быть произвольного количества типов агентов. (Действительно ли типы должны быть так параметризованы? Боюсь, ваша общность слишком дорого вам обходится.

    class AnAgent a where 
         liveABit :: World -> a -> (World,a)
         ...
         ...

    data NuclearPlant = ....
    data CoalPlant = ....
    data WidFarm = .....

    data DataCenter = .....

    data EnvFriendly = .....
    data PetrolHead = .....

Сгруппируйте их немного вместе для общей обработки с помощью сопоставления с образцом, если это удобно:

    data Plant = PN NuclearPlant | PC CoalPlant | PW WindFarm
    data Human = HEF EnvFriendly | HPE PetrolHead

    data Agent = AP Plant | AH Human | AD DataCenter

Общее/гетерогенное лечение внутри групп/между группами:

    bump :: Agent -> Agent
    bump (Human h) = Human (breakleg h)
    bump a = a

Затем вы можете определить всех агентов, которых хотите, затем поместить их в [Agent] и определить хороший eachLiveABit :: World -> [Agent] -> (World,[Agent]) для обновления мира и его агентов. Вы можете сделать AnAgent экземпляров отдельных типов или групп агентов и построить до Agent (или, может быть, даже обойтись без класса типов и просто использовать обычные функции).

Это последует за преобразованием программы (Classes + Interesting Type System Features) -> (Types and Higher Order Functions), которое с эмоциональной точки зрения похоже на то, что вы немного отупели, но устраняет большую часть проблем.

Вы можете попытаться решить эту проблему, используя классы типов.
Вот некоторый псевдокод:

data Mockup = Mockup1 <return type of systemToMockup>
            | Mockup2 <return type of systemToMockups2>

class SystemToMockup a where
    systemToMockup :: a -> Mockup

instance SystemToMockup (System1 ...) where
    <implementation of systemToMockup>

instance SystemToMockup (System2 ...) where
    <implementation of systemToMockups2>

Это довольно ограниченное решение, и я сомневаюсь, что оно сработает для вас, поскольку ваше приложение кажется довольно сложным.
В целом подход C. A. McCann намного лучше.

Обновление. Одной вещью, с которой эта стратегия не может справиться, являются полиморфные возвращаемые типы. Кроме того, несколько усложняют параметры, которые имеют разные типы в зависимости от основного типа.

Это упоминалось в комментариях, но один из лучших способов сделать «гетерогенную коллекцию» — это решить, какие операции вы действительно можете выполнять с каждым элементом коллекции (поскольку вы сможете выполнять только ограниченный набор действий). на них, даже если в вашем языке была утиная типизация) и сохранить запись этих операций. Пример:

data Thing1 = ...
data Thing2 = ...

data AThing = AThing {
  op1 :: ...
  op2 :: ...
}

class IsAThing a where
    mkAThing :: a -> AThing

instance IsAThing Thing1 where
    mkAThing a = AThing {
            op1 = op1_for_thing1 a,
            op2 = op2_for_thig1 a
        }

Затем, чтобы вызвать op1 на любом IsATThing:

op1 (mkAThing a) <...other args...>

Хотя в вашем случае вам нужен список AThing:

[mkAThing a2, mkAThing a2, ...]

Затем на любом элементе:

op1 <element of that list> <...other args...>