#. 휴일이라 좋았다.
원래는 돌아다니기로 마음먹었지만, 잠을 너무 많이 자는 바람에 집에 있었다.
#. 집에 있는 김에, 요즘 핫한 머니게임을 보았다.
배진수님의 원작만화를 좋아해서 실사판보는 느낌으로 적당히 봤다.
돈 벌기는 쉽지 않구나..
#. 개발공부도 필요하지만, 코딩에만 몰입하는건 경계해야 되겠다고 생각했다.
난이도가 있을수록 뭔가 대단한것처럼 생각되어 그렇게 되는듯하다.
문제해결을 위한 하나의 방법일 뿐으로 생각하도록 노력하자.
시야를 넓히자..
fpinscala 책 4장에 참조 투명성의 의미를 잘 설명해주는 구절이 나온다.
참조에 투명한 표현식의 의미는 문맥(context)에 의존하지 않으며 지역적으로 추론할 수 있지만,
참조에 투명하지 않은 표현식의 의미는 문맥에 의존적이고, 좀 더 전역적인 추론이 필요하다는 것으로 이해해도 될 것이다.
참조 투명한 표현식은 문맥을 생각할 필요가 없다. 표현식이 가리키는 값으로 치환해도 무방하다.
참조 투명하지 않은 표현식은 값으로 치환할 경우, 문맥이 달라지기 때문에 의미가 달라지게 된다.
부수효과를 절대 허용하지 않는 (참조투명한) 병렬계산 라이브러리를 설계하는 과정을 학습했다. 핵심아이디어는 계산의 서술과 실행을 분리하는 것이라고 한다. 실제로 설계과정을 살펴보면, 계산을 서술하는 시점과 실행하는 시점을 옮겨보면서 적합한 (부수 효과 없는) 라이브러리를 만들어나가는 것을 확인할 수 있다.

위의 코드처럼 Par.unit 을 통해 병렬 계산을 정의하고, Par.get 을 통해 병렬 계산 결과를 얻는식으로 라이브러리를 설계해볼 수 있다. Par.unit 이 호출된 시점에서 병렬 계산이 바로 시작되고, get 에서는 그 계산된 결과를 얻도록 설계한다면, Par.get(sumL) + Par.get(sumR) 표현식의 참조 투명성이 깨지는 것을 확인할 수 있다.
#1 에서는 두개의 Par.unit 이 각각 모두 호출된 후에 get 으로 결과를 얻으므로, 계산이 병렬적으로 수행되게 할 수 있다. 하지만, 참조투명성을 확인하기 위해 아래와 같이 표현식을 값으로 치환하면, 계산이 병렬적으로 수행되지 않는다. 스칼라는 인수를 왼쪽에서 오른쪽으로 엄격하게 평가하므로, get 에서의 인수도 엄격하게 평가된다. 즉 #2 의 식에서는, 왼쪽에서 병렬계산이 시작되고 완료된 다음에야, 오른쪽에서 병렬계산이 시작되고 완료되게 된다. 결국 두계산은 동시가 아닌, 순차적으로 실행되게 된다.
치환했을때에 표현식의 의미가 달라졌으므로, 위의식은 참조투명하지 않다. 그말은 unit 에 부수효과가 존재함을 의미한다.
-- 책의 예시가 이해가 안되어서 직접 설명하면서 이해하기 위해 적었지만, 적고 나서도 어렵다.
나는 결과를 볼때까지 꾸준하게 앞으로 가는 사람이다.