MLton과 같은 전체 프로그램 컴파일러는 부분적으로 평가를 수행하는 데 바이너리의 전체 소스를 사용하는 능력에 최적화 된 바이너리를 생성합니다. 적극적으로 상수를 인라인하고 컴파일하는 동안 멈추지 않을 때까지 평가합니다!GHC 부분 평가 및 별도 컴파일
이것은 하스켈 공간에서 공개적으로 조사되었으며 Gabriel Gonzalez's Morte입니다.
내 이해는 하스켈이이 모든 것을 전혀하지 않는다는 것입니다. 제가 이해하는 인용 된 이유는 편집을 분리하는 것이 대조적이라는 것입니다. 이것은 소스 파일 경계를 가로 지르는 부분 평가를 금지하는 것이 합리적이지만, 파일 내부 부분 평가가 여전히 선택 사항 인 것처럼 보입니다.
내가 아는 한, 파일 내부 부분 평가는 여전히 수행되지 않습니다.
내 질문은 : 사실입니까? 그렇다면 파일 내 부분 평가를 수행 할 때의 절충점은 무엇입니까? 그렇지 않다면 동일한 파일에 더 많은 기능을 넣어 컴파일 된 성능을 향상시킬 수있는 예제 파일은 무엇입니까?
(편집 : 위의 내용을 명확히하기 위해 수행 할 최고의 축소 세트가 무엇인지 결정할 수 있는지에 관해 많은 질문이 있습니다. 많은 것들이 결정 불가능합니다! "산업력에서의 절충안을 알고 싶습니다. 컴파일러 속도와 파일 팽창과 같은 것들은 내가 관심있는 범위에 더 가깝다. 같은 질문에 대한 또 다른 질문이있다. 공간은 다음과 같을 것입니다 : "왜 MLton은 각 모듈을 따로 따로 컴파일하고, API를 노출시킨 다음, 함께 연결하여 컴파일을 분리 할 수 없습니까?")
부분 평가에 대한 것은이 중단 문제 앓고 있다는 것입니다. 언제 표현을 부분적으로 평가하기를 중단하기로 결정하셨습니까? 예를 들어, 표현식'enumFrom 0 :: [Integer]'를 취하십시오. 부분적으로 평가하려고하면 컴파일러가 종료되지 않으므로 매우 나쁜 일입니다. 한 가지 해결책은 약한 머리 정상 형태의 표현을 평가하지 않는 것입니다. 그러나 이것은 특정 표현식이 최적화 될 수 없음을 의미합니다. 재 작성은 중간 데이터 구조의 삼림 벌채를 없애기위한 빠르고 더러운 방법입니다. 게다가 그것은 끝납니다. 문제는 정확합니다. –
Glasgow Haskell 컴파일러는 공격적이지는 않지만 인라인을 수행합니다. http://stackoverflow.com/q/26996110/783743. 많은 사람들이 적극적인 인라인에 관심을 갖고있는 것 같습니다 : http://stackoverflow.com/questions/26827663/rewriting-as-a-practical-optimization-technique-in-ghc-is-it-really-needed . 내 마지막 해 학사 프로젝트는 함수형 프로그래밍 언어로 재 작성 및 부분 평가를합니다. –
질문에 더 명확히 추가해야합니다.나는 여기서 많은 평등이 결정 불가능하다는 것을 알고 있습니다. ML보다 하스켈에서 더 나쁠 수도 있습니다. 그러나 MLton은 유익하고 종결되는 감축 평등이 있다는 (부분적인) 존재 증명입니다. 올바른 축소가 무엇인지에 관해 너무 깊이 검토하지 않고, 별도의 편집을 통해 "산업 강도"컴파일러로 구현하려는 추론을하고 싶습니다. –