타입스크립트의 타입 추론과 힌들리 밀러 타입 시스템

https://mostly-adequate.gitbook.io/mostly-adequate-guide/ch07

Chapter 07: Hindley-Milner and Me - mostly-adequate-guide

타입스크립트는 타입 추론을 지원하는데, 타입스크립트 타입 추론 원리가 지금까지 힌들리 밀러 타입 시스템에 기반한 것으로 알고 있었다.

 

실제 타입스크립트의 타입 추론은 양방향 타입 추론 시스템을 사용한다고 한다.

상속, 확장, 할당 타입 호환 가능성을 검사하는 것으로, 일반 객체지향 프로그래밍에서 사용하는 방식과 유사하다.

아래 글에서는 그 이유가 힌들리 밀러 타입 시스템이 서브타이핑과 유니온 타입에 적합하지 않기 때문이라고 한다.

https://jaked.org/blog/2021-09-07-Reconstructing-TypeScript-part-0

Reconstructing TypeScript, part 0: intro and background

(유니언 타입은 하스켈 등에서 잘 작동하는걸 보면 객체지향 스타일의 상속이 문제가 되는듯 하다.)

 

위 글을 보고 스칼라를 찾아보니 스칼라도 마찬가지로 힌들리 밀러와 개념은 비슷하지만 좀 다른 방식을 취하고 있다고 한다.

스칼라 스쿨 - 타입과 다형성의 기초

Scala School - 타입과 다형성의 기초

 

왜 힌들리 밀러 타입 추론이 타입스크립트와 잘 어울리지 않나 좀 더 생각해보면,

 

하스켈과 같은 순수 함수형 프로그래밍 언어는 타입 오브젝트와 모피즘을 완전히 분리한다.

즉, 리스트가 head와 cons의 union이라면, 객체지향에서는 상속으로 구현한다. (Head extends List)

 

함수형 프로그래밍 언어에서는 패턴 매칭을 통해서만 해당 타입의 파악이 가능하다.

이는 수학적 연역추리나 마찬가지인데,

A or B이면 A인지 B인지는 알 수 없는 경우가 있다.

우리는 A->C, B->C를 통해서 C를 검증할 수 있는 것이다.

(물론 C를 A, B로 할 수 있다.)

 

객체지향 프로그래밍은 이를 메서드 오버라이딩, instanceOf등의 객체에 바인딩된 this를 통해 판단한다.

 

하스켈 같은 언어에는 서브타이핑이 없냐라고 물어볼 수 있는데, 실제 존재하지 않으며,

서브타입 시스템은 double타입에 int를 할당하고 정사각형에 직사각형을 할당하는 등의 타입 구멍을 내재하고 있다.

(double에 int를 할당하는게 무슨 문제냐 할 수 있겠지만, 수학적으로는 group(군)이 깨진것으로 보기에 대수적 규칙을 마음대로 적용할 수 없다. 그리고 실전에서도 int와 double을 상호 운용할 때는 분명히 부수효과를 조심해야 한다.)

 

편의성과 소프트웨어의 품질을 트레이드오프 한 것으로 볼 수 있겠다. (나쁘다는 말은 아님)

https://www.reddit.com/r/haskell/comments/423o0c/why_no_subtypingsubtype_polymorphism/

Why no subtyping/subtype polymorphism?

 

 

또한 타입스크립트 타입 시스템의 재미있는 점은, {a:number} 타입에 {a:number, b:string} 타입의 변수가 할당 가능하다는 점인데

이에 관해서 읽어볼만한 두 글을 소개한다.

객체지향 시스템과 패러다임 그리고 철학

객체지향 시스템과 패러다임 그리고 철학

자바스크립트는 왜 프로토타입을 선택했을까?

자바스크립트는 왜 프로토타입을 선택했을까