형식화 된 라켓 최적화

Question

나는 순간에 약간의 형식화 된 라켓을 배우고 그리고 난 다소 철학적 딜레마가 있습니다

라켓는 언어 개발 프레임 워크라고 주장하고 형식화 된 라켓은 그 위에 구현 하나 개의 언어입니다. 설명서에 따르면 유형이 사용 되었기 때문에 컴파일러는 더 나은 최적화를 수행 할 수 있습니다.

구체적인 질문 :

이러한 최적화는 어디에서 발생합니까? 컴파일에서

1)/확장 언어 건물 워크의 일부로서 "프로그램"인 부분()

- 또는

2) 상기 (바이트 코드)에 최적화 선 아래 (이것은 C로 작성되고 프레임 워크를 통해 직접 수정할 수 없습니다).

2)가 참이면 형식 정보가 컴파일/확장 단계 후에 손실되고 나중에 옵티마이 저가 "다시 작성/추측"되거나 유형 정보를 수용하고 나중에 알리도록 중간 표현이 변경되었음을 의미합니까? 그들에 관한 무대?

내가이 특정 질문을하는 이유는 내가 Racket 언어 프레임 워크가 실제로 얼마나 일반적인 지에 대한 느낌을 받기를 원하기 때문입니다. 즉, 유형 시스템이 아닌 백엔드에서 수정하지 않고 정적으로 입력 된 언어에 대해서도 실행 가능합니다. 프론트 엔드의 일이지만, 런타임의 코드는 여전히 동적으로 타입이 지정됩니다 (물론 정적으로 검사됩니다).

감사합니다.

Answer 1

매크로 확장 중에 입력 된 라켓의 최적화가 발생합니다. 직접 확인하려면 #lang typed/racket을 #lang typed/racket #:no-optimize으로 변경하면 Typed Racket이 적용되는 최적화를 완벽하게 제어 할 수 있습니다.

최적화는 유형 정보를 사용하여 특정 절차의 다양한 용도를 their unsafe equivalents으로 대체하는 것으로 구성됩니다. 안전하지 않은 프로 시저는 인수의 유형에 대한 런타임 검사를 수행하지 않으며 잘못 정의 된 동작 (read : segfaults)을 발생시킵니다. 자세한 내용은 Optimization in Typed Racket이라는 설명서 섹션을 참조하십시오.

안전하지 않은 프로 시저 변형은 실제로 사용자 정의 언어에서 이러한 최적화를 구현할 수있게합니다. 예를 들어 범위를 벗어나는 인덱스로 벡터에 액세스하지 못했음을 증명할 수있는 유형 시스템으로 자신의 언어를 작성한 경우 vector-ref의 사용을 unsafe-vector-ref으로 바꿀 수 있습니다.

바이트 코드 수준에서 비슷한 최적화가 있지만 JIT가 매크로 확장 시간에 표시되지 않는 유형 정보를 유추 할 수있는 경우에 주로 적용됩니다. 이것들은 사용자가 제어 할 수 없지만, 당신은 그것들에 의존 할 필요가 없습니다.