go 내부의 제네레이터는 reduceF를 거치지않나요?

답변이 달렸을 때 알림이 기능 같은게 아직 없어서 ㅠ 답변 달린지 몰랐어요. 

깊이 공부하시는 모습 존경됩니다! 멋지세요. 화이팅입니다. 

이해했습니다. L.map, L.filter 가 제네레이터가 바로 takeAll 처럼 바로 배열을 생성하는 것도 아니고 go에 선언된 함수에선 제네레이터 상태로 넘겨지고 reduceF 에 들어갈일 없이 [...iter] 에 의해 풀려서 f(g(h))) reduceF에 의한 처리 없이 단순하게 map, filter, map 안의 함수합성으로 next()가 끝날때까지 뱉어버리고 마네요.

마지막 행이 catchnoop 없는 C.reduce라도 reduceF가 있는데  에러가 찍히는 이유는 reduceF를 포함하는 recur로 재귀를 도는데 [...iter] 배열 요소가 같은 시간이 걸리는 프로미스라고 가정하면 첫번째 이외의 배열요소는 그 요소를 처리할 reduceF의 recur이 태스크 큐에서 순차적으로 돌고있는데 그 배열요소는 recur보다 먼저 reject로 resolved되버려서 콘솔에 에러가 찍힐수 밖에 없었던 거네요.

사실 이런거보다 더 중요한건 고차함수를 어떻게 잘 만들어내서 활용하는지인데 이런 과정이 납득이 안되면 뭘해도 답답한 느낌이 들어서 계속 묻게되네요. 답변 감사합니다.

글로 설명을 모두 드리기 조금 어렵지만 마지막 L.map을 그냥 map 으로 해보시면 원하시는 결과를 얻으실 수 있습니다.

그런 이유는 L.map 이후에 takeAll 을 하는 것이 map 이기 때문입니다.

takeAll 에서 실제로 실제로 nop이 제거되고 배열 내 하나의 값들 마다 promise의 효과를 제어하기 때문입니다.

감사합니다.