Заостренный контейнер - это комонада , и это наблюдение можно использовать для получения некоторых полезных эффектов, таких как, например, трафаретные свертки, почти бесплатно . Далее следует отметить, что instance Comonad можно получить стандартным способом через Store comonad (посредством частично примененной индексной функции) ,и он будет работать так же хорошо, как и рукописное определение.
Но у этого подхода есть недостаток: хранилище - это, по сути, функция, и как только что-то превращается в функцию, возвращаться назад неудобно. И я замечаю , что существуют ситуации , когда небольшое изменение в требованиях требует полного отказа от понятия комонады и возврата к рассмотрению исходного контейнера. Я нахожу это похожим на окончательную оценку без тегов : локальные преобразования просты, но чем больше контекста они требуют, тем сложнее становится. Можно восстановить любую часть исходного контейнера, выполнив итерацию извлечения по соответствующему подмножеству пространства курсора, но тогда зачем сначала менять начальный тип на конечный?
Другими словами, есть 2 способапредставлять контейнер, и оба одинаково благоприятны для определения instance Comonad:
- как «начальный» тип данных. Без зависимых типов тривиальное определение
instance Comonad в Haskell, когда контейнер связан с индексом, является частичным (индекс может указывать на место за пределами формы контейнера) , но все равно будетработа. - В качестве «окончательной» частично примененной индексной функции. Контейнер можно превратить в комонаду, обернув его в
Store. Затем он автоматически соединяется с индексом. Аргумент частичности применяется в равной степени, поэтому безопасность не может быть достигнута.
Когда начальный тип торгуется для конечной функции, все методы, определенные для начального типа, теряются, пока не будут восстановлены с более или менееразработка. Учитывая, что доступ к небольшому конечному контейнеру небезопасен (большинство индексов не определены) , а сам контейнер недоступен для запросов, программирование становится игрой тральщика. Какие бы свойства исходного контейнера я не указал в EnvT, они будут потеряны. В целом, какую бы безопасность или удобство не принесло Store, оспаривается трудностями обработки окончательного представления контейнера.
Говоря более кратко, остроконечный контейнер, помимо прочего, являетсяcomonad, но Store - это только comonad.
Итак, какова мотивация для Store? И можем ли мы получить instance Comonad или, по крайней мере, Extend, дешевле?