Raku는 컴파일 타임에 어떤 유형 검사를 수행합니까? 미래에 변경 될 수 있습니까?
현재 (2020 년 8 월 현재) Rakudo는 컴파일 타임에 함수의 반환 값을 유형 검사하지 않습니다. 즉, 함수가 반환 제약 조건을 충족한다는 정적 보장을 제공하지 않습니다. 구체적으로 다음 두 함수는 모두 Raku로 컴파일됩니다.
sub get-int(--> Int) { 'bug' }
sub get-int($a --> Int} { when $a == 5 { 'Rare bug' }
default { 42 }
}
두 가지 관련 질문이 있습니다.
현재 컴파일 타임에 어떤 유형 검사가 발생하는지 알 수있는 방법이 있습니까? (누군가가 작성한 목록, 문서의 어딘가 또는 Rakudo 소스의 중앙 위치를 통해) 아니면 그보다 더 임시적인가요?
컴파일 시간이 부족한 것이 의도적 인 디자인 결정입니까? 아니면 언젠가 있으면 좋겠지 만 아직 구현되지 않은 정적 유형 검사를 추가하고 있습니까?
(저는 "Raku의 유형 / 제약 조건에 대한 성능 페널티"에 대한 Johnathan의 훌륭한 답변에 익숙 합니다. "Raku는"프로그램에 작성된 유형 제약이 늦어도 런타임 에 적용되도록 요구합니다 . "라고 말합니다. 그 대답은 실행을 피하는 다양한 방법을 설명합니다. -타입 검사의 시간 비용이지만 컴파일 타임에 어떤 유형 검사가 수행되는지 설명하지 않습니다 (확실히 런타임 비용을 피할 수 있습니다!).)
답변
현재는 컴파일 시간에 거의 유형 검사가 수행되지 않습니다. 대부분 정적 최적화 프로그램의 부작용으로 발생합니다. 오늘날 점검은 주로 서브 루틴 호출에 관한 것입니다.
- 호출의 정확성을 확인할 수 있으며 전달 된 인수의 수가 일치하지 않음을 알 수 있습니다.
- 우리는 리터럴 인수를 가지고 있으며 서명과 결코 일치하지 않을 수 있음을 알 수 있습니다
이것은 정적 옵티마이 저가 더 많은 인라인 작업을 수행했을 때 남은 것입니다. 요즘에는 컴파일 타임에 네이티브 연산자 만 인라인하고 나머지는 VM의 동적 최적화 프로그램에 남겨 둡니다. 이는 인라인에 훨씬 더 많은 기능을 제공하고 인라인을 해제 할 수도 있습니다 (추론 적 최적화를 허용하지만 원본 스택 추적을 복구 할 수 있음을 의미하기도 함). 정적 최적화 프로그램이이 정보를 잃었습니다).
컴파일 타임에 더 많은 작업을 수행하는 것이 바람직한 것으로 간주되지만 고려해야 할 몇 가지 실질적인 문제가 있습니다.
- 추가 검사를 도입하면 이전에 작동했던 코드가 손상 될 수도 있습니다. 더 엄격한 컴파일 시간 검사에 실패 할 수있는 코드 경로가있는 모듈을 고려해보십시오. 그러나 해당 경우에는 실행되지 않는 시스템에서 사용되고 있습니다. 최신 버전의 컴파일러에서 컴파일에 실패하기 시작하면 컴파일러 업그레이드 후 해당 시스템을 배포 할 수 없게됩니다. 일반적으로 이것은 수행 된 검사가 언어 버전 변경시 변경되어야 함을 의미합니다. (이것은 여전히 사람들이 코드를 작성할 때 작성하는 언어 버전을 선언해야 함을 의미합니다.)
- 컴파일 타임에 더 많은 검사가 수행되는 것은 "확실히 런타임 비용을 피할 것"이라는 사실이 사실 일 수 있지만, 추론하는 것은 사소한 일이 아닙니다. 관리 형 런타임은 주어진 바이트 코드에서 이루어진 약속을 맹목적으로 신뢰할 수 없습니다. 그럴 경우 메모리 안전 위반 (SIGSEGV 또는 그 이상으로 이어짐)을 초래할 수 있기 때문입니다. 이것은 유형 검사의 의미 체계를 프로그래밍 할 수있는 Raku와 같은 언어에서 매우 분명하게 사실이지만 JVM, CLR 등에서는 사실입니다. Raku에서 가장 큰 유형 관련 승리는 많은 할당과 가비지 수집 작업을 피할 수있는 네이티브 유형의 사용에서 비롯됩니다.
- 추가 검사를 구현하면 컴파일러의 복잡성과 컴파일에 필요한 시간이 늘어납니다. 이들 중 첫 번째는 이미 문제입니다. 컴파일러 프런트 엔드는 약 10 년 동안 중요한 아키텍처 변화를 보지 못했습니다. 매크로의 토대가되는 현재 RakuAST 작업에는 컴파일러 프런트 엔드를 거의 다시 작성해야합니다. 개선 된 아키텍처는 추가 컴파일 타임 유형 검사를 쉽게 구현할 수 있어야하지만 컴파일 측면이 병렬화되어 컴파일러가 wallclock 컴파일 시간을 늘리지 않고도 더 많은 작업을 수행 할 수 있도록하는 방법도 고려하고 있습니다.
현재의 컴파일러 프런트 엔드 점검이 완료되면 더 많은 컴파일 타임 검사가 도입 될 가능성이 높습니다 (하지만 다음 언어 버전에서만 활성화 됨). 적어도 누군가가 작업을 수행하는 한.
그러나이 분야에서 훨씬 더 흥미로운 기회가있을 것입니다. Raku 프로그램에 대한 API가 있고 사용자 정의 컴파일러 패스에 대한 계획이 함께 제공되므로 조만간 유형 검사기 를 모듈 로 구현할 수도 있습니다 ! 이들 중 일부는 향후 Raku 언어 버전에 적용되는 검사로 이어질 수 있습니다. 다른 것들은 도메인에 따라 다르며 주어진 모듈을보다 정확하게 사용할 수 있도록하는 것을 목표로합니다. 다른 사람들은 기본 언어의 정신이 아니지만 일부 언어 사용자가 선택할 수있는 엄격함을 적용 할 수 있습니다.