Lisp 처럼 보이는 정적으로 형식화 된 언어 만 원하는 경우 해당 언어 를 나타내는 추상 구문 트리를 정의한 다음 해당 AST를 S- 표현식으로 매핑하여 쉽게 수행 할 수 있습니다. 그러나 나는 결과를 Lisp라고 부르지 않을 것이라고 생각합니다.
구문 외에 실제로 Lisp-y 특성이있는 것을 원한다면 정적으로 형식화 된 언어로이를 수행 할 수 있습니다. 그러나 Lisp에는 많은 유용한 정적 타이핑을 얻기 어려운 많은 특성이 있습니다. 설명을 위해 Lisp의 기본 구성 요소를 형성하는 cons 라는 목록 구조 자체를 살펴 보겠습니다 .
단점을 목록이라고 부르는 것은 (1 2 3)마치 하나처럼 보이지만 약간 잘못된 이름입니다. 예를 들어, C ++ std::list또는 Haskell의 목록 과 같이 정적으로 형식화 된 목록과 전혀 비교할 수 없습니다 . 이들은 모든 셀이 동일한 유형 인 1 차원 연결 목록입니다. Lisp는 기꺼이 (1 "abc" #\d 'foo). 또한 정적 유형 목록을 목록 목록을 포함하도록 확장하더라도 이러한 개체 유형은 목록의 모든 요소가 하위 목록이어야합니다. 당신은 ((1 2) 3 4)그들에게 어떻게 표현 하겠습니까?
Lisp conses는 잎 (원자)과 가지 (conses)가있는 이진 트리를 형성합니다. 또한, 그러한 나무의 잎은 어떤 원자 (비 죄수) Lisp 유형을 포함 할 수 있습니다! 이 구조의 유연성으로 인해 Lisp는 기호 계산, AST를 처리하고 Lisp 코드 자체를 변환하는 데 매우 능숙합니다!
그렇다면 정적으로 형식화 된 언어로 그러한 구조를 어떻게 모델링할까요? 매우 강력하고 정확한 정적 유형 시스템을 가진 Haskell에서 시도해 보겠습니다.
type Symbol = String
data Atom = ASymbol Symbol | AInt Int | AString String | Nil
data Cons = CCons Cons Cons
| CAtom Atom
첫 번째 문제는 Atom 유형의 범위입니다. 분명히, 우리는 우리가 빙빙 돌고 싶은 모든 유형의 물체를 포괄 할 수있는 충분한 유연성의 Atom 유형을 선택하지 않았습니다. 위에 나열된 Atom 데이터 구조를 확장하려고하는 대신 (분명히 깨지기 쉬운 Atomic것을 알 수 있음) 원자로 만들고자하는 모든 유형을 구별 하는 마법 유형 클래스가 있다고 가정 해 보겠습니다 . 그런 다음 시도해 볼 수 있습니다.
class Atomic a where ?????
data Atomic a => Cons a = CCons Cons Cons
| CAtom a
그러나 이것은 트리의 모든 원자가 동일한 유형 이어야하기 때문에 작동하지 않습니다 . 우리는 그들이 잎마다 다를 수 있기를 바랍니다. 더 나은 접근 방식은 Haskell의 실존 적 수량 자를 사용해야합니다 .
class Atomic a where ?????
data Cons = CCons Cons Cons
| forall a. Atomic a => CAtom a
그러나 이제 당신은 문제의 핵심에 도달했습니다. 이런 종류의 구조에서 원자로 무엇을 할 수 있습니까? 모델링 할 수있는 공통 구조는 무엇입니까 Atomic a? 이러한 유형으로 어떤 수준의 유형 안전성이 보장됩니까? 우리가 타입 클래스에 어떤 함수도 추가하지 않았 음을 주목하세요. 그리고 좋은 이유가 있습니다 : 원자들은 Lisp에서 공통점을 공유하지 않습니다. Lisp에서 그들의 슈퍼 타입은 단순히 t(즉, top) 이라고 불립니다 .
그것들을 사용하기 위해서는 원자의 가치를 실제로 사용할 수있는 것으로 동적으로 강요 하는 메커니즘을 생각해 내야 합니다. 그리고 그 시점에서 기본적으로 정적으로 입력 된 언어 내에서 동적으로 입력 된 하위 시스템을 구현했습니다! ( Greenspun의 10 번째 프로그래밍 규칙에 대한 가능한 결과에 주목할 수밖에 없습니다 .)
하스켈은 바로 그러한에 대한 지원을 제공하는 참고 동적 서브 시스템 와 ObjA를 함께 사용 유형, Dynamic유형과 Typeable 클래스 우리의 교체 Atomic임의의 값이 해당 유형으로 보존 할 수 있도록 클래스를, 이러한 유형의 명시적인 강제 백을. 이것이 Lisp cons 구조를 전체적으로 일반화하기 위해 사용해야하는 종류의 시스템입니다.
또한 할 수있는 작업은 다른 방식으로 이동하여 기본적으로 동적으로 형식화 된 언어 내에 정적으로 형식화 된 하위 시스템을 포함하는 것입니다. 이를 통해보다 엄격한 유형 요구 사항을 활용할 수있는 프로그램 부분에 대한 정적 유형 검사의 이점을 얻을 수 있습니다. 예를 들어 이것은 CMUCL의 제한된 형식의 정확한 유형 검사 에서 취한 접근 방식 인 것 같습니다 .
마지막으로 계약 스타일 프로그래밍을 사용하여 둘 사이의 전환을 탐색하는 데 도움이되는 동적 및 정적으로 형식화 된 두 개의 개별 하위 시스템을 가질 가능성이 있습니다. 이런 식으로 언어는 정적 유형 검사가 도움말보다 더 방해가되는 Lisp의 사용과 정적 유형 검사가 유리한 사용을 수용 할 수 있습니다. 이것은 다음 주석에서 볼 수 있듯이 Typed Racket이 취하는 접근 방식 입니다.