현재 하스켈에서 신청자를 배우고 있습니다. 잘못된 것이 아니라면 목록에 두 개의 다른 Applicative 인스턴스가 있습니다 (List 및 ZipList - 두 번째는 List 값을 래핑하는 newtype으로 정의 됨). 적용 가능한 인스턴스는 나를 위해 더 직관적 인 것처럼 보입니다.ZipList가 목록의 기본 Applicative 인스턴스가 아닌 이유
멍청한 질문 일 수도 있지만 특별한 이유가 있습니다. ZipList은 목록의 기본 Applicative 인스턴스가 아닙니다.
pure (+) <*> [1,2,3] <*> [4,5,6]
-- [5,6,7,6,7,8,7,8,9]
pure (+) <*> ZipList [1,2,3] <*> ZipList [4,5,6]
-- ZipList [5,7,9]
응용 프로그램 목록의 배포 버전에도 Monad 인스턴스가 있습니까?
정직한 대답은 "역사적인 사고"라고 생각합니다. 모나드 추상화는 적용 이전에 인기가있었습니다. 자연스러운 모나드 모나드가 있기 때문에 그 인스턴스가 정의되었습니다. 이전 버전과의 호환성을 위해 펑터와 적용 가능한 인스턴스를 일관성있게 유지하는 것이 좋습니다. 비결정론 모나드는 구문 싼 되돌아 검색 등 유용이고, 나는 자주 그의 장점을 촬영했습니다 :
우리가 오늘 다시 선택을해야한다면 말했다 는, 나는 어쨌든 현재의 상황을 지원하는 것이라고 생각 ; 자의식은 내 개인적인 경험으로는 훨씬 덜 빈번하게 필요합니다.
나는 newtype wrapping을 요구하는 것이 더 좋을 것이라고 생각한다. 그래서 그 의도는 명확하게 표현된다. 목록에는 의도가 없습니다. –
"Applicative"와 "Monad"인스턴스가 일치하기를 원합니다. 'ZipList'가'Monad '가 아니기 때문에 목록을'Monad'로 만들려면 비 결정론'Applicative' 의미론을 사용해야합니다. (이것은 또한 newtype-both-of-them 접근법을 막습니다 : 우리는 * 그들에게 유일한 Monad 인스턴스를주기 위해 그들에게 Applicative 인스턴스를 주어야합니다!) –
목록 길이가 다른 경우 어떻게됩니까? 당신이 조용히 정보를 잃거나 (무서운) 또는 부분적인 기능을 (심지어 더 나쁘게)합니다. 나는 그 행동을 선택함으로써 사람들이 그 결과를 더 많이 고려할 것으로 생각합니다. 반대로 기본 Applicative 및 Monad 인스턴스는 손실이 없으므로 문제를 자동으로 일으킬 가능성이 적으며 개념적으로 만족스러운 것일 수 있습니다. 또한 그들은 0 또는 1 값 대신에 비 결정론 또는 모호성을 인코딩하는 값의 개수를 인코딩 할 수있는 대신에 매우 멋지다고 생각합니다. –
나는 기본 이론이 범주 이론에서'자유로운 '대상과 비슷한 의미에서 더'기본 '이라고 생각한다. 대부분의 정보를 보존하며 일부 정보를 잊어 버려이 기본값에 대안을 할당 할 수 있습니다. 여기에서'ZipList'는 디폴트가 고려하는 요소들의 쌍에 대해 잊어 버립니다. 그러나 나는 카테고리에 너무 익숙하지 않아서 아직 나를 인용하지는 않는다. – jakubdaniel