Luau의 시맨틱 하위 유형 지정 - Roblox Blog

[ad_1]

Luau는 의미론적 하위 유형 지정 기능을 수백만 명의 제작자에게 제공하는 최초의 프로그래밍 언어입니다.

가양성 최소화

Roblox Studio의 스크립트 분석 위젯과 같은 도구에서 유형 오류 보고와 관련된 문제 중 하나는 오탐. 이는 분석의 아티팩트인 경고이며 런타임에 발생할 수 있는 오류에 해당하지 않습니다. 예를 들어 프로그램

local x = CFrame.new() local y if math.random()

reports a type error which cannot happen at runtime, since CFrame supports multiplication by both Vector3 and CFrame. (Its type is ((CFrame, CFrame) -> CFrame) & ((CFrame, Vector3) -> Vector3).)

False positives are especially poor for onboarding new users. If a type-curious creator switches on typechecking and is immediately faced with a wall of spurious red squiggles, there is a strong incentive to immediately switch it off again.

Inaccuracies in type errors are inevitable, since it is impossible to decide ahead of time whether a runtime error will be triggered. Type system designers have to choose whether to live with false positives or false negatives. In Luau this is determined by the mode: strict mode errs on the side of false positives, and nonstrict mode errs on the side of false negatives.

While inaccuracies are inevitable, we try to remove them whenever possible, since they result in spurious errors, and imprecision in type-driven tooling like autocomplete or API documentation.

Subtyping as a source of false positives

One of the sources of false positives in Luau (and many other similar languages like TypeScript or Flow) is subtyping. Subtyping is used whenever a variable is initialized or assigned to, and whenever a function is called: the type system checks that the type of the expression is a subtype of the type of the variable. For example, if we add types to the above program

local x : CFrame = CFrame.new() local y : Vector3 | CFrame if math.random()

then the type system checks that the type of CFrame multiplication is a subtype of (CFrame, Vector3 | CFrame) -> (Vector3 | CFrame).

Subtyping is a very useful feature, and it supports rich type constructs like type union (T | U) and intersection (T & U). For example, number? is implemented as a union type (number | nil), inhabited by values that are either numbers or nil.

Unfortunately, the interaction of subtyping with intersection and union types can have odd results. A simple (but rather artificial) case in older Luau was:

local x : (number?) & (string?) = nil
local y : nil = nil
y = x -- Type '(number?) & (string?)' could not be converted into 'nil'
x = y

이 오류는 하위 유형 지정 실패로 인해 발생하며 이전 하위 유형 지정 알고리즘은 다음과 같이 보고합니다. (number?) & (string?) 의 하위 유형이 아닙니다. nil. 이는 잘못된 긍정이므로 number & string 사람이 살지 않는 곳이므로 유일한 거주민 (number?) & (string?) ~이다 nil.

이것은 인위적인 예이지만 문제로 인해 제작자가 제기한 실제 문제가 있습니다. 예를 들어 https://devforum.roblox.com/t/luau-recap-july-2021/1382101/5<. 현재 이러한 문제는 정교한 유형 시스템 기능을 사용하는 제작자에게 주로 영향을 미치지만 유형 추론이 더 정확해짐에 따라 유형 주석이 없는 코드에서도 통합 및 교차 유형이 더 일반적이 될 것입니다.

이전 접근 방식에서 이동했기 때문에 Luau에서는 이러한 종류의 오탐이 더 이상 발생하지 않습니다. 구문 하위 유형 라는 대안으로 시맨틱 서브타이핑.

구문 하위 유형 지정

AKA "우리가 전에 했던 것."

구문 하위 유형 지정은 구문 지향 재귀 알고리즘입니다. 교차 및 공용체 유형을 다루는 흥미로운 사례는 다음과 같습니다.

반사성: T 의 하위 유형입니다. T
교차로 L: (T₁ & … & Tⱼ) 의 하위 유형입니다. U 언제든지 일부 Tᵢ 의 하위 유형입니다 U
유니온 L: (T₁ | … | Tⱼ) 의 하위 유형입니다. U 언제든지 모든 Tᵢ 의 하위 유형입니다 U
교차로 R: T 의 하위 유형입니다. (U₁ & … & Uⱼ) 언제든지 T 모두의 하위 유형입니다. Uᵢ
유니온 R: T 의 하위 유형입니다. (U₁ | … | Uⱼ) 언제든지 T 일부의 하위 유형입니다. Uᵢ.

예를 들어:

반사성: nil 의 하위 유형입니다. nil
Union R: nil 의 하위 유형입니다. number?
그리고: nil 의 하위 유형입니다. string?
교차로 R: nil 의 하위 유형입니다. (number?) & (string?).

예이! 안타깝게도 다음 규칙을 사용합니다.

number 의 하위 유형이 아닙니다. nil
Union L: (number?) 의 하위 유형이 아닙니다. nil
그리고: string 의 하위 유형이 아닙니다. nil
Union L: (string?) 의 하위 유형이 아닙니다. nil
그래서 교차로 L: (number?) & (string?) 의 하위 유형이 아닙니다. nil.

이것은 구문 하위 유형화의 전형입니다. “예” 결과를 반환하면 올바른 것이지만 “아니오” 결과를 반환하면 틀릴 수 있습니다. 알고리즘은 보수적 근사“아니오” 결과는 유형 오류로 이어질 수 있으므로 이는 잘못된 긍정의 원인입니다.

시맨틱 서브타이핑

AKA “지금 우리가 하는 일.”

하위 유형 지정을 구문 방향으로 생각하기보다는 먼저 의미 체계를 고려하고 나중에 의미 체계가 구현되는 방식으로 돌아갑니다. 이를 위해 시맨틱 하위 유형을 채택합니다.

형식의 의미 체계는 값 집합입니다.
교차 유형은 집합의 교차로 간주됩니다.
공용체 유형은 집합의 공용체로 간주됩니다.
하위 유형 지정은 집합 포함으로 간주됩니다.

예를 들어:

유형	의미론
`number`	{ 1, 2, 3, … }
`string`	{ “푸”, “바”, … }
`nil`	{ 없음 }
`number?`	{ 무, 1, 2, 3, … }
`string?`	{ nil, “푸”, “바”, … }
`(number?) & (string?)`	{ nil, 1, 2, 3, … } ∩ { nil, “foo”, “bar”, … } = { nil }

하위 유형은 집합 포함으로 해석되기 때문에:

하위 유형	슈퍼타입	왜냐하면
`nil`	`number?`	{ nil } ⊆ { nil, 1, 2, 3, … }
`nil`	`string?`	{ nil } ⊆ { nil, “foo”, “bar”, … }
`nil`	`(number?) & (string?)`	{ 없음 } ⊆ { 없음 }
`(number?) & (string?)`	`nil`	{ 없음 } ⊆ { 없음 }

그래서 시맨틱 서브타이핑에 따르면, (number?) & (string?) 에 해당합니다 nil그러나 구문 하위 유형 지정은 한 방향만 지원합니다.

이것은 모두 훌륭하고 훌륭하지만 도구에서 의미론적 하위 유형을 사용하려면 알고리즘이 필요하며 의미론적 하위 유형을 확인하는 것은 사소한 일이 아닙니다.

시맨틱 서브타이핑은 어렵다

NP-정확하기 어렵습니다.

유형에 대한 하위 유형을 확인하는 것이 그래프를 채색할 수 없는지 확인하는 것과 동일한 결과를 갖도록 그래프를 Luau 유형으로 코딩하여 그래프 색상을 시맨틱 하위 유형으로 줄일 수 있습니다.

예를 들어 3노드, 2색 그래프의 색상은 유형을 사용하여 수행할 수 있습니다.

type Red = "red"
type Blue = "blue"
type Color = Red | Blue
type Coloring = (Color) -> (Color) -> (Color) -> boolean
type Uncolorable = (Color) -> (Color) -> (Color) -> false

그러면 그래프는 하위 유형이 있는 오버로드 함수 유형으로 인코딩될 수 있습니다. Uncolorable 그리고 슈퍼타입 Coloring반환하는 오버로드된 함수로 false 제약 조건을 위반한 경우. 각 오버로드는 하나의 제약 조건을 인코딩합니다. 예를 들어 선에는 인접한 노드가 같은 색상을 가질 수 없다는 제약 조건이 있습니다.

type Line = Coloring
  & ((Red) -> (Red) -> (Color) -> false)
  & ((Blue) -> (Blue) -> (Color) -> false)
  & ((Color) -> (Red) -> (Red) -> false)
  & ((Color) -> (Blue) -> (Blue) -> false)

삼각형은 비슷하지만 끝점도 같은 색을 가질 수 없습니다.

type Triangle = Line
  & ((Red) -> (Color) -> (Red) -> false)
  & ((Blue) -> (Color) -> (Blue) -> false)

지금, Triangle 의 하위 유형입니다. Uncolorable하지만 Line 선이 2색일 수 있기 때문에 그렇지 않습니다. 이것은 유한한 수의 색상을 가진 유한한 그래프로 일반화될 수 있으므로 하위 유형 검사는 NP-hard입니다.

우리는 이것을 두 가지 방법으로 처리합니다.

메모리 공간을 줄이기 위해 유형을 캐시하고
유형의 캐시가 너무 커지면 “코드가 너무 복잡함” 오류로 포기합니다.

바라건대 이것은 실제로 많이 나오지 않습니다. 표준 ML과 같은 유형 시스템의 경험에서 이와 같은 문제가 실제로 발생하지 않는다는 좋은 증거가 있습니다. EXPTIME 완료<하지만 실제로는 Turing Machine 테이프를 유형으로 코딩하기 위해 노력해야 합니다.

유형 정규화

시맨틱 서브타이핑을 결정하는 데 사용되는 알고리즘은 다음과 같습니다. 유형 정규화. 구문의 지시를 받는 대신 먼저 정규화할 유형을 다시 작성한 다음 정규화된 유형의 하위 유형을 확인합니다.

정규화된 유형은 다음의 합집합입니다.

정규화된 nil 유형(또는 never 또는 nil)
정규화된 숫자 유형(또는 never 또는 number)
정규화된 부울 유형(또는 never 또는 true 또는 false 또는 boolean)
정규화된 함수 유형(또는 never 또는 함수 유형의 교차점) 등

유형이 정규화되면 시맨틱 하위 유형을 확인하는 것이 간단합니다.

모든 유형을 정규화할 수 있습니다(일반 유형 팩에 대한 일부 기술적 제한이 있음). 중요한 단계는 다음과 같습니다.

일치하지 않는 프리미티브의 교차점 제거, 예: number & bool 로 대체된다 never그리고
함수의 합집합 제거, 예: ((number?) -> number) | ((string?) -> string) 로 대체된다 (nil) -> (number | string).

예를 들어 정규화 (number?) & (string?) 제거하다 number & string그래서 남은 것은 nil.

형식 정규화를 구현하려는 우리의 첫 번째 시도는 이를 자유롭게 적용했지만 이로 인해 성능이 끔찍했습니다(복잡한 코드는 1분도 안 되어 형식 검사에서 밤새 실행됨). 그 이유는 성가실 정도로 간단합니다. 반사성을 처리하기 위해 Luau의 하위 유형 지정 알고리즘에 최적화가 있습니다(T 의 하위 유형입니다. T) 저렴한 포인터 평등 검사를 수행합니다. 형식 정규화는 포인터 동일 형식을 의미상 동일(포인터 동일은 아님) 형식으로 변환할 수 있으므로 성능이 크게 저하됩니다.

이러한 성능 문제로 인해 하위 유형 지정에 대한 첫 번째 검사로 구문 하위 유형 지정을 계속 사용하고 구문 알고리즘이 실패하는 경우에만 유형 정규화를 수행합니다. 구문 하위 유형 지정은 의미 하위 유형 지정에 대한 보수적인 근사이기 때문에 이것은 건전합니다.

실용적 시맨틱 서브타이핑

기성 시맨틱 서브타이핑은 Luau에서 구현된 것과 약간 다릅니다. 집합 이론, 함수 유형의 거주자는 “함수처럼 작동”해야 합니다. 이 요구 사항을 삭제하는 데에는 두 가지 이유가 있습니다.

먼저우리는 함수 유형을 함수의 교집합으로 정규화합니다. 예를 들어 끔찍한 합집합과 함수 교집합이 있습니다.

((number?) -> number?) | (((number) -> number) & ((string?) -> string?))

오버로드된 함수로 정규화:

((number) -> number?) & ((nil) -> (number | string)?)

집합론적 의미론적 하위 유형 지정은 이 정규화를 지원하지 않으며 대신 함수를 다음으로 정규화합니다. 분리 정규형 (함수 교차점의 합집합). 인체 공학적인 이유로 이렇게 하지 않습니다. 오버로드된 함수는 Luau에서 관용적이지만 DNF는 그렇지 않으며 사용자에게 이러한 관용적이지 않은 유형을 제시하고 싶지 않습니다.

우리의 정규화는 함수 유형의 합집합을 다시 작성하는 데 의존합니다.

((A) -> B) | ((C) -> D)   →   (A & C) -> (B | D)

이 정규화는 우리 모델에서는 건전하지만 집합 이론 모델에서는 그렇지 않습니다.

둘째Luau에서 함수 응용 프로그램의 유형 f(x) ~이다 B 만약에 f 유형이 있음 (A) -> B 그리고 x 유형이 있음 A. 예기치 않게 이것은 무인 유형으로 인해 집합 이론 모델에서 항상 사실이 아닙니다. 집합 이론 모델에서 x 유형이 있음 never 그 다음에 f(x) 유형이 있음 never. 우리는 함수 응용 프로그램에 특별한 코너 케이스가 있다는 생각으로 사용자에게 부담을 주고 싶지 않습니다. 특히 코너 케이스는 데드 코드에서만 발생할 수 있기 때문입니다.

집합 이론 모델에서, (never) -> A 의 하위 유형입니다. (never) -> B무슨 일이 있어도 A 그리고 B 이다. 이것은 Luau에서는 사실이 아닙니다.

이 두 가지 이유(기술적인 것이 아니라 주로 인체 공학에 관한 것임)로 인해 집합 이론 요구 사항을 삭제하고 다음을 사용합니다. 바쁜 시맨틱 서브타이핑.

부정 유형

Luau의 유형 시스템과 기성 시맨틱 하위 유형 지정 간의 다른 차이점은 Luau가 모든 부정 유형을 지원하지 않는다는 것입니다.

부정 유형을 원하는 일반적인 경우는 유형 검사 조건입니다.

-- initially x has type T
if type(x) == "string" then
  --  in this branch x has type T & string
else
  -- in this branch x has type T & ~string
end

부정 유형을 사용합니다. ~string 문자열이 아닌 값이 거주합니다.

Luau에서는 이러한 종류의 타이핑 개선만 허용합니다. 테스트 유형 처럼 string, function, Part 등등 ~ 아니다 다음과 같은 구조적 유형에 대해 (A) -> B일반 부정 유형의 일반적인 경우를 피합니다.

프로토타이핑 및 검증

Luau의 시맨틱 하위 유형 지정 알고리즘을 설계하는 동안 변경 사항이 있었습니다(예를 들어 처음에는 집합 이론 하위 유형 지정을 사용할 수 있을 것이라고 생각했습니다). 이 급속한 변화의 시기에 빠르게 반복할 수 있는 것이 중요했기 때문에 처음에는 원기< 프로덕션 구현으로 바로 이동하는 대신.

서브타이핑 알고리즘에는 예상치 못한 코너 케이스가 있을 수 있으므로 프로토타입의 유효성을 검사하는 것이 중요했습니다. 이러한 이유로 우리는 Agda를 프로토타이핑 언어로 채택했습니다. 아그다는 단위 테스트를 지원할 뿐만 아니라 기계화 검증도 지원하기 때문에 설계에 자신이 있습니다.

프로토타입은 모든 Luau를 구현하지 않고 기능적 하위 집합만 구현하지만 프로덕션에서 수정하기 어려운 버그로 나타날 수 있는 미묘한 기능 상호 작용을 발견하기에 충분했습니다.

프로토타이핑은 완벽하지 않습니다. 예를 들어 프로덕션에서 부딪히는 주요 문제는 성능과 C++ 표준 라이브러리에 관한 것인데 프로토타입에 의해 포착되지 않을 것입니다. 그러나 프로덕션 구현은 그렇지 않으면 상당히 간단했습니다(또는 적어도 3kLOC 변경만큼 간단할 수 있음).

다음 단계

Semantic subtyping은 가양성의 한 가지 소스를 제거했지만 여전히 추적해야 할 다른 소스가 있습니다.

오버로드된 함수 애플리케이션 및 연산자
복합 형식의 식에 대한 속성 액세스
테이블의 읽기 전용 속성
시간이 지남에 따라 유형이 변경되는 변수(일명 typestates)

가짜 빨간색 물결선을 제거하기 위한 퀘스트는 계속됩니다!

감사의 말

이 게시물의 초안에 도움이 되는 의견을 주신 Giuseppe Castagna와 Ben Greenman에게 감사드립니다.

Alan은 Roblox Studio의 많은 개발 기능을 구동하는 데 도움이 되는 Luau 유형 시스템의 설계 및 구현을 조정합니다. Jeffrey 박사는 프로그래밍 언어 연구 분야에서 30년 이상의 경험을 가지고 있으며 수많은 오픈 소스 소프트웨어 프로젝트의 활동적인 멤버였으며 영국 옥스퍼드 대학에서 DPhil을 보유하고 있습니다.

[ad_2]

Source_lin