함수형 프로그래밍에 관한 많은 책과 기사를 읽었지만 여전히 매우 기본적인 개념을 이해할 수 없다는 것이 부끄러운 일입니다.
함수형 프로그래밍의 주요 아이디어 중 하나는 동일한 입력이 항상 동일한 출력을 생성해야한다는 것입니다. 따라서 데이터베이스 쿼리 또는 파일 쓰기는 정의에 따라 순수한 기능 스타일로 수행 할 수 없습니다. 예를 들어 모나드가 필요한 이유 중 하나입니다.
문제는-왜 우리는 STDOUT 출력을 불완전한 것으로 간주합니까? 예, 모든 파일 핸들러는 위험합니다. 데이터가 항상 기록 될 것이라고 확신 할 수 없습니다. 그러나 STDOUT은 어떻습니까? 왜 신뢰할 수없는 것으로 생각해야합니까? 평가 자체가 더 신뢰할 수 없습니까? 우리는 항상 트리거를 당겨서 계산을 중단 할 수 있습니다.
답변:
따라서 데이터베이스 쿼리 또는 파일 쓰기는 정의에 따라 순수한 기능 스타일로 수행 할 수 없습니다. 예를 들어 모나드가 필요한 이유 중 하나입니다.
아무도 모나드를 "필요"하지 않습니다. 그것은 단지 사물을 묘사하는 한 가지 방법입니다. 사실, 아마도 가장 좋은 방법은 아닙니다. 어떤 형식의 효과 입력 , 고유성 유형 또는 완전 선형 논리 기반 시스템 은 이론상 더 설득력있는 것처럼 보이지만 잘 알려진 유형 시스템에서 더 급진적으로 벗어나 표현하기가 더 복잡합니다. Haskell에서 발견 된 Monadic IO는 사용 성과 단순성 사이의 절충입니다. 본질적으로 언어에서 이미 사용 된 기존 ML 스타일 유형 시스템과 쉽게 공존 할 수있는 방식으로 완전 명령형 프로그래밍을 모델링하기 때문입니다.
문제는-왜 우리는 STDOUT 출력을 불완전한 것으로 간주합니까? 예, 모든 파일 핸들러는 위험합니다. 데이터가 항상 기록 될 것이라고 확신 할 수 없습니다. 그러나 STDOUT은 어떻습니까? 왜 신뢰할 수없는 것으로 생각해야합니까? 평가 자체가 더 신뢰할 수 없습니까? 우리는 항상 트리거를 당겨서 계산을 중단 할 수 있습니다.
그렇지 않습니다. 프로그램 전체에 대한 입력 및 출력은 단순히 인수로 간주 될 수 있으며 전체 프로그램을 하나의 큰 순수 함수로 취급 한 결과입니다. stdin에서 동일한 것을 공급하면 stdout에 동일한 것을 인쇄하는 한 여전히 순수한 기능입니다. 실제로, 모나 딕 IO를 도입하기 전에 Haskell은 입력 및 출력에 순수한 지연 스트림을 사용하는 스트림 기반 I / O 시스템을 사용했습니다. 그것은 사용하기가 분명히 고통 스럽기 때문에 떨어졌습니다. 왜냐하면 왜 이런 소리를 듣지 못했는지에 대한 아이디어를 얻을 수 있습니다. :]
좀 더 간결하게 지적하려면, 미니멀리즘의 난해한 언어 인 Lazy K를 고려하십시오 .
Lazy K는 간단한 스트림 기반 I / O 시스템을 사용하여 가비지 수집되고 참조 가능한 투명한 기능 프로그래밍 언어입니다.
Lazy K와 다른 언어를 구별하는 것은 다른 기능이 거의 없다는 것입니다. 예를 들어, 통합 Hindley-Milner 다형성 유형 시스템을 제공하지 않습니다. 플랫폼 독립적 인 GUI 프로그래밍 및 다른 언어에 대한 바인딩을 지원하는 광범위한 표준 라이브러리와 함께 제공되지 않습니다. Lazy K는 내장 라이브러리 이외의 함수를 정의하거나 참조하는 방법을 제공하지 않기 때문에 이러한 라이브러리를 작성할 수 없습니다. 이 기능은 숫자, 문자열 또는 기타 데이터 유형에 대한 지원 부족으로 보완됩니다. 그럼에도 불구하고 Lazy K는 Turing-complete입니다.
(...)
게으른 K 프로그램은 Unlambda 페이지에서 "순수한 유형이 지정되지 않은 람다 미적분의 축복 된 영역"이라고하는 수학 함수와 같은 영원한 플라토닉 영역에 살고 있습니다. 가비지 콜렉션이 프로그래머로부터 메모리 관리 프로세스를 숨기 듯이 참조 투명도는 평가 프로세스를 숨 깁니다. Mandelbrot 세트의 그림을 보거나 Lazy K 프로그램을 "실행"하기 위해 약간의 계산이 필요하다는 사실은 구현 세부 사항입니다. 이것이 바로 함수형 프로그래밍의 핵심입니다.
(...)
부작용없이 언어로 입력 및 출력을 처리하는 방법은 무엇입니까? 어떤 의미에서, 입력과 출력은 부작용이 아닙니다. 말하자면, 전면 및 후면 효과입니다. 따라서 Lazy K에 있습니다. 여기서 프로그램은 가능한 입력 공간에서 가능한 출력 공간까지의 함수로 취급됩니다.
그보다 더 순수하게 기능적인 언어를 찾을 수있을 것입니다.
그러나 위의 내용은 본질적으로 순수한 기능의 입력 및 출력을 취하고 어떤 방식 으로든 "외부 적으로"stdin / stdout에 연결하는 경우에만 적용됩니다. 그것과 실제 시스템 레벨 I / O 프리미티브에 액세스하는 것에는 큰 차이가 있습니다. 스트림에 대한 읽기 및 쓰기의 구현 세부 사항은 신중하게 캡슐화되지 않으면 불순물이 누출 될 수 있습니다.
이것이 하스켈에서 직접 할 수없는 주된 이유라고 생각합니다. 모나 딕 IO를 사용하는 것보다 합리적인 사용 사례가 얇고, 후자는 실물에 액세스 할 때 많은 이점이 있습니다. 예를 들어, 프로그램에 대한 명령 줄 인수가 main직관적으로 보이는 것처럼 보이지만 단순히에 대한 인수로 전달되는 것은 아닙니다 .
그러나 특정 프로그램에서 이와 같은 최소 버전을 복구 할 수 있습니다. 인수를 순수한 값으로 캡처 한 다음 나머지 프로그램에 함수 를 사용 하십시오interact .
기능적 프로그램의 순도는 가치있는 목표이지만 현실은 사소하고 유용한 모든 프로그램이 언급 한 이유로 약간의 불순물 (또는 "부작용")을 갖습니다.
완전히 순수한 프로그램은 정의에 따라 봉인 된 블랙 박스이며 본질적으로 흥미롭지 않습니다.
기능적 언어 Haskell은 모나드의 출력과 같은 부작용을 분리하여이 문제를 처리 합니다. 모나드는 순수하게 기능적인 프로그래밍 스타일을 유지하면서도 출력을 생성 할 수 있습니다.
"외부 세계의 상태를 바꾼다"라는 용어로 순결을 생각하면 도움이됩니다. 콘솔 쓰기, 로그 파일 작성, CD 꺼내기 또는 "미사일 발사"가 포함될 수 있습니다.
동시 실행 측면에서도 문제가 될 수 있습니다. 함수에 부작용이 없다는 것을 알고 있다면 경쟁 조건 등이 없다는 것을 증명할 수 있으므로 동시성을 쉽게 정렬 할 수 있습니다.