Кто-нибудь когда-либо составлял список импорта, необходимый для того, чтобы избежать определений "недостаточно полиморфных" в стандартных библиотеках Haskell?

Я использую Haskell довольно долгое время. Чем больше я использую его, тем больше я влюбляюсь в этот язык. Я просто не могу поверить, что провел почти 15 лет своей жизни, используя другие языки.

Тем не менее, я медленно, но неуклонно роняю от стандартных библиотек Haskell. Мой главный питомец - это определения "недостаточно полиморфные" (Prelude.map, Control.Monad.forM_ и т.д.). У меня много файлов исходного кода Haskell, чьи первые строки выглядят как

{-# LANGUAGE NoMonomorphismRestriction #-}

module Whatever where

import Control.Monad.Error hiding (forM_, mapM_)
import Control.Monad.State hiding (forM_, mapM_)
import Data.Foldable (forM_, mapM_)

{- ... -}

Чтобы избежать постоянного поиска, какие определения я должен скрывать, я хотел бы иметь одно или несколько файлов исходного кода, которые переносят этот шаблон import в управляемые единицы.

Итак...

  • Кто-нибудь еще пытался это сделать раньше?
  • Если ответ на предыдущий вопрос "Да", опубликовали ли они исходные файлы исходного кода для шаблонов?

ОТВЕТЫ

Ответ 1

Это не так ясно, как вы себе представляете. Я перечислю все недостатки, которые я могу придумать с головы:

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

Вот еще один пример. Функция mapM определяет функтор более высокого порядка, который удовлетворяет законам функтора в категории Клейсли:

mapM return = return
mapM (f >=> g) = mapM f >=> mapM g

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

Кроме того, ознакомьтесь с пакетом категории-extras для некоторых примеров этих классов и функций более высокого порядка, которые охватывают все ваши примеры.

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

Существует также проблема перегрузки типов. Я на самом деле предпочитаю свести к минимуму использование typeclasses, если у них нет разумных законов, полученных из теории, а не удобства. Кроме того, классы обычно плохо работают с ограничением мономорфизма, и мне нравится писать функции без подписей для моего кода приложения.

Существует также проблема вкуса. Многие люди просто не согласны с тем, что является лучшим стилем Хаскелла. Мы до сих пор не можем даже договориться о Прелюдии. Кстати, было много попыток написать новые прелюдии, но никто не может согласиться с тем, что лучше, поэтому мы все по умолчанию возвращаем Haskell98 в любом случае.

Однако я считаю, что общий дух улучшения вещей хорош, а худшим врагом прогресса является удовлетворение, но не предполагайте, что будет четкий правильный способ сделать все.