0. Moggi가 모나드 전부를 계산 개념이라고 부르지 않았다는건 레퍼런스 있음? 정확히는 lambda calculi의 시멘틱으로 쓰이는 카테고리에서의 모나드중에 계산 개념이라고 불리지 않는게 있는지 의심스러움

1. Moggi가 쓴 논문은 effect를 모나드로 해석할 수 있다는 얘기를 하는거고 모나드는 이미 수학적으로 엄밀하게 정의되는 대상이니 독자에게 해설하려는 목적이 아니라면 굳이 모나드를 재정의할 필요는 없음

2. 나랑은 계산개념과 모나드의 관계를 보는 관점이 완전히 다른것 같은데, 내 이해로 모나드는 effect를 가질 수 있는 계산 그 자체이고, 계산개념은  (lambda calculi의 시멘틱 카테고리에서의) 모나드에 이런 관점을 투사한 것임. Moggi 이전의 계산은 완전히 형식적으로 이해되지 못한 모호한 대상이었고 Monad를 사용해 수학적 정의를 내리고 계산개념이라는 이름을 붙임으로써 계산의 범주가 재정의되었다고 생각함.

그러니까 계산개념으로 모나드를 이해하는게 아니라 모나드로 계산개념을 이해하는게 맞음. 우리의 직관이 리스트를 계산이라고 받아들이지 못했다면 그건 우리의 계산개념에 대한 이해가 부족하기 때문이니 우리의 직관을 고쳐야 함. 리스트에도 계산의 관점을 적용한다는 전에는 없던 사고를 할 수 있게 해주니 계산개념이라는 관점이 유용한거임.

논리적으로는 모나드가 먼저 정의되고 계산개념이 뒤따르는거지만, 프로그래머한테는 모나드 같은 추상적 개념이 익숙하지 않으니 계산을 통해 모나드를 이해하려는 것이고. 물론 이렇게 하면 모나드에 대한 피상적인 이해밖에 되지 못하니 그게 전부라고 생각하는건 곤란하지만.

내가 보기엔 Moggi나 Wadler의 설명은 완벽하게 이해 됨. 처음 보는 사람한테 뜬구름 잡는 소리 처럼 들릴 수는 있겠지만 적어도 틀렸거나 무의미한 말은 아님.

3. bind가 수학적으로 join에 비해 덜 깔끔하긴 하지만, 계산개념 관점에서 이해하기에는 join보다 직관적임. join을 이해하려면 m (m a) 부터가 난점이다. m이 중첩되는게 무슨 의미인데? State/IO 모나드의 경우 bind는 계산을 시퀸셜하게 이어준다는 직관적인 설명을 줄 수 있지만, join은 외려 힘듬. 다만 일반적인건 아니고 리스트 같은 경우엔 join이 이해하기 더 쉽다는데에 동의함. 그런데 이 경우 너도 그렇듯이 계산개념의 관점으로는 잘 생각되지 않지. 나는 이 부분에 있어선 그냥 bind, join, kleisli composition을 다 소개해야 한다고 생각함.

4. 모나드에 대한 비유적 설명이 입문자에게 도움이 되는지에 대해서는 나도 회의적임. 결국 모나드를 제대로 이해하는데에 핵심적인건 개별 모나드들에 대한 사례 분석과 수학적 정의를 제대로 파악하는 것이고, 이 두가지가 병행된다면 저런 비유적 설명도 마냥 나쁘진 않다고 생각함. 부정적인 결과는 보통 저 두가지를 제대로 안한 경우고.

사실 추상적인 개념들은 대부분 이런 방식으로 배워야 됨. 근데 복잡하더라도 구체적인 대상들을 다루는건 잘 하는데 이런 추상적인 개념은 어려워 하는 사람들이 꽤 많다. 경험상 프로그래머들도 그럼. 여기서 결국 모나드를 이해하기를 포기하는 사람들이 나옴. 근데 하스켈 커뮤니티 입장에서는 모나드를 이해하지 못한 사람한테도 하스켈은 권유해야 됨. 그럼 그냥 모나드 모른채로 하스켈을 하면 되는데, 다들 그게 잘 안되는것 같다.


댓글 달려다가 길어져서 글로 씀