마이크로소프트에서 F-star라는 언어 만들어서, 안전한 https 스택 구현하는 연구 플젝을 진행 중임
이 언어의 튜토리얼 앞 부분만 읽었는데, 이 언어는 타입 시스템에 effect가 포함 돼 잇더라고
아무 effect 없이 무적권 종료되는 함수면 그 return type이 Tot Int (Total의 약자임)
ML에서 정의된 exception이 발생할 수도 있지만, 연산이 종료된다면 무조건 Int를 반환하는 함수면, ML Int가 리턴 타입임
이 컨셉을 알고 나니, 비로소 IO a의 의미를 직관적으로 받아들이게 됏음
그리고 밑에 올린 하스켈 98 테크니컬 리포트 읽으니까, 비로소 하스켈로 뭔가 실용적인 걸 짜볼 수 있겠다는 느낌을 받음
forkIO나 IORef나 MVar 같은 애들 내부 구현도 시간 나면 찾아볼 예정
하지만 여전히 의문이 남는 부분은, IO a를 a로 바꾸려면 unsafePerformIO 이거 써야 되는 거 같은데, 이거 웬만하면 쓰지 말라고 하더라고?
그럼 파일에서 스트링 읽어서 처리하는 그런 라이브러리를 짜고 싶으면, IO String 타입을 쓰는 건 아닐테고
String에 대해서 짜고 나중에 return이나 pure로 올려서 써먹으면 되는 거겠지?
오늘 일기 끝
이 언어의 튜토리얼 앞 부분만 읽었는데, 이 언어는 타입 시스템에 effect가 포함 돼 잇더라고
아무 effect 없이 무적권 종료되는 함수면 그 return type이 Tot Int (Total의 약자임)
ML에서 정의된 exception이 발생할 수도 있지만, 연산이 종료된다면 무조건 Int를 반환하는 함수면, ML Int가 리턴 타입임
이 컨셉을 알고 나니, 비로소 IO a의 의미를 직관적으로 받아들이게 됏음
그리고 밑에 올린 하스켈 98 테크니컬 리포트 읽으니까, 비로소 하스켈로 뭔가 실용적인 걸 짜볼 수 있겠다는 느낌을 받음
forkIO나 IORef나 MVar 같은 애들 내부 구현도 시간 나면 찾아볼 예정
하지만 여전히 의문이 남는 부분은, IO a를 a로 바꾸려면 unsafePerformIO 이거 써야 되는 거 같은데, 이거 웬만하면 쓰지 말라고 하더라고?
그럼 파일에서 스트링 읽어서 처리하는 그런 라이브러리를 짜고 싶으면, IO String 타입을 쓰는 건 아닐테고
String에 대해서 짜고 나중에 return이나 pure로 올려서 써먹으면 되는 거겠지?
오늘 일기 끝
모나드라는 건 그럼 태생적으로 그런 사이드이펙트를 무조건 포함해야하는거임?
포함할 수밖에 없는거임?
내가 이해하기로 모나드는 bind랑 return만 정의할 수 있으면 말이 되는 추상적인 개념이고, 그걸로 I/O같은 이펙트를 표현하면 자연스러워서, 둘이 자주 엮여서 언급되는 느낌?
사이드 이펙트가 모나드를 보는 관점중 하나라고 볼 수 있을 듯 - dc App
사이드 이펙트의 종류가 한가지가 아님. IO가 될 수도 있고, 슈도 랜덤함수용 스테이트를 가지는게 될 수도 있고, nullable 한게 될 수도 있고 그런거지 - dc App
unsafePerformIO는 FFI나 메모리 접근하는 라이브러리 만들 때 쓰라고 있는거고, 일반적인 상황에서 쓰라고 있는건 아님. 필요도 없고. 예로 든 상황에서는 파일을 읽는 과정에만 IO가 수반되고, 문자열을 처리하는 부분은 pure function으로 따로 만들어서 쓰는게 보통임 - dc App
뭔가 a -> b를 받아서 a -> m b 로 만들어주는 함수가 있을 거 같은데, liftM은 a -> b 받아서 m a -> m b로 만드는 거네
f :: a -> b 이면 pure . f :: a -> f b 임. 근데 이렇게는 잘 안씀 - dc App
보통 어캐 쓰는 게 일반적 디자인 패턴임? 참고할만한 코드 잇음 알려주면 감사 ㅎㅎ
왜냐면 mx :: f a, f :: a -> b 에서 f b 를 만들고 싶으면 mx >>= (pure . f) 보다 fmap f mx 라 쓰는게 좋음 - dc App
전자는 모나드여야 가능한데 후자는 펑터만 있어도 됨 - dc App
아 fmap 쪽은 생각을 잘 못했네. 모나드에 너무 매몰돼서. Functor, Applicative 다시 좀 봐야겠다
아이러니 한데, 단순한걸로 구현할 수록 활용도가 높기 때문에 모나드는 사실 최후의 수단임. function, functor, applictive, monad 순으로 고려하는게 맞음 - dc App
결국 Effect 없으면 쓸 데 없는 프로그램이라는 생각 때문에, 모나드부터 들이댈 생각 하고 있었음. 바깥 세상이랑 interaction하는 곳에만 최소한으로 쓰고, 라이브러리 함수 같은 건 될 수 있으면 그 전 단계에서 해결해야겠네
그렇게 여겨야 하는건 사실 IO 모나드고, Maybe 같은건 언제든 모나드를 벗겨낼 수 있기 때문에 쓰고싶으면 쓰면 됨 - dc App