Ну я исходя из этой аналогии и предложил потребность в мономорфизмы отовсюду. Я рассуждал так: в RealWorld должно поместиться любое состояние. Я не прав?
Да не то, чтоб прав или не прав. Я просто говорил про более простую вещь ;-)
Моё мнение про "Real World" такое, что наиболее адекватно его моделировать чем-то типаа (может быть, потоком) "сообщений". Что это не тип, который такой мощный и большой, а просто способ организации своих морфизмов и указания их, как "интерфейсу" для общения. Я несколько образно сказал, но думаю, что мысль понятна.
В контексте хаскеля и большинства языков программирования, аппликативный функтор можно определить, как просто моноидальный. Это верно приблизительно потому же, почему в хаскеле все монады с̶е̶р̶ы̶е̶ сильные.
В контексте хаскеля и большинства языков программирования, аппликативный функтор можно определить, как просто моноидальный. Это верно приблизительно потому же, почему в хаскеле все монады с̶е̶р̶ы̶е̶ сильные.
Если я правильно ncatlab понял, то "аппликативный" это и есть слабый моноидальный
Авот такая задачка. Есть категория монад, из неё забывающий в категорию аппликативов. Построить к нему левый сопряжённый.
Возможно, придумал. Раз монады - моноид в категории с композицией, а аппликативы - со свёрткой дея, то чтобы дополнить минимальным образом второе до первого нужен свободный конструктор
Splice: f · f -> Day f f
для монады реализуется тривиально
splice: Compose f f ~> Day f f splice (Compose ff) = Day ff (pure ()) (flatten . fst)