특정 기능이 올바르게 작동하는지 언어 디자이너가 결정하거나 증명하기 위해 무엇을합니까?


11

언어 디자인에 관심이 있으며 일반적으로 널리 알려진 기능 (예 : 상속, 다형성, 대리자, 람다, 캡처, 가비지 수집, 예외, 제네릭, 분산, 반사 등), 상호 작용에 대해 쉽게 추론 할 수 있습니다. 특정 언어, 구현 방법, 제한 사항 등

지난 몇 개월 동안 필자는 객체 수명을 정적으로 검증 할 수있게하여 메모리 안전성과 결정 론적 자원 관리를 보장하는 소유권 시스템이있는 Rust에 대해 읽기 시작했습니다. 평범한 언어 사용자의 관점에서 시스템을 거의 즉시 선택할 수있었습니다.

그러나 언어 디자이너의 관점에서 Rust의 사물이 왜 그런지 깨닫는 데 시간이 걸렸습니다. 시스템이없는 경우 시스템의 무결성을 위반하는 사례를 스스로 강요 할 때까지 소유권 시스템의 일부 제한에 대한 추론을 즉시 이해할 수 없었습니다.

내 주요 질문은 Rust 및 그 소유권과는 아무런 관련이 없지만 필요한 경우 의견 / 답변에서 예제로 자유롭게 사용하십시오.

언어 디자이너가 새로운 기능을 디자인 할 때 기능이 제대로 작동하는지 결정하기 위해 어떤 방법론 또는 프로세스를 사용합니까?

"새로운"이란 말은 기존 언어로 이미 테스트 된 것이 아니며 (따라서 다른 디자이너가 수행 한 대부분의 작업) 것입니다. "올바로 작동"한다는 것은이 기능이 의도 한 문제를 올바르게 해결한다는 것을 의미하며, 이는 상당히 방탄입니다. "합리적으로 방탄"이란 기능의 무결성을 위반하는 언어 또는 언어의 특정 하위 집합 (예 : "안전하지 않은"코드가없는 하위 집합)으로 코드를 작성할 수 없음을 의미합니다.

  • 간단한 형태의 기능을 찾은 후 시행 착오 과정입니까? 그런 다음이를 위반하는 방법을 찾은 다음 성공적으로 위반 한 경우 패치 한 다음 반복하십시오. 그리고 나서, 다른 가능한 위반을 생각할 수 없을 때, 아무것도 남길 바라지 않고 하루라고 부릅니까?

  • 또는 기능이 작동한다는 것을 실제로 (수학적 의미로) 증명 한 다음 해당 증거를 사용하여 처음부터 기능을 올바르게 (또는 대부분 올바른) 얻을 수 있는 공식적인 방법이 있습니까?

(컴퓨터 공학이 아닌 공학적 배경을 가지고 있다는 점을 언급해야합니다. 따라서 CS 사람들에게 명백한 것을 놓치고 있다면 자유롭게 지적하십시오.)


"언어 디자이너"라고 말하면 컴파일러를 작성하거나 구문 또는 둘 다를 작성하는 사람을 의미합니까?
스눕

6
@StevieV : 언어 디자인은 구현과 다릅니다. 예를 들어 Lisp는 John McCarthy에 의해 λ- 미적분의 대안을 이해하기 쉽게 설계되었습니다. 그러나 그는 그것을 구현하지 않았습니다. 실제로 그의 학생 Steve Russell이 Lisp를 구현하기를 원했을 때 McCarthy는 Lisp를 구현하는 것이 불가능하다고 믿었습니다! APL은 수학 교육을위한 언어로 설계되었습니다. 나중에 IBM은이 언어를 사용하여 언어에 여러 가지 확장자가있는 System / 360의 동작을 공식적으로 지정했습니다. 현재로서는 아직 구현되지 않았습니다. Plankalkül은 Konrad에 의해 설계되었습니다
Jörg W Mittag

4
Zuse 1942-1946이지만 1975 년에만 구현되었습니다. Niklaus Wirth는 처음으로 언어를 완전히 디자인하고 디자인이 완료된 후에 만 ​​언어를 구현했습니다. 그는 학생들에게 부트 스트래핑을 위해 컴파일러를 다른 언어로 직접 번역하도록했습니다. 더 많은 학문적 언어는 결코 구현되지 않으며, 추상적 인 방식으로 특정 언어 기능에 대한 요점을 입증하거나 실험하기 위해서만 설계되었습니다. 스몰 토크는 상호 베팅의 결과로 만들어졌습니다. Alan Kay는 그가 할 수 있다고 내기
Jörg W Mittag

3
Dan Ingalls는 한 페이지에 객체 지향 언어를 디자인하여 며칠 내에 해당 언어를 구현할 수 있다고 확신했습니다. (그리고 그는 모든 언어의 기본 언어로이 작업을 수행했습니다!) 언어는 컴파일러 / 인터프리터와 독립적으로 존재하는 수학적 객체입니다. 또한 물리적 구현과 무관하게 설계, 연구 및 토론 할 수 있습니다.
Jörg W Mittag

3
읽어야합니다 : Godel, Escher, Bach . 때때로 조금 이상하지만 결국에는 언어 디자인의 형식에 큰 영향을 미치는 Turing & Godel의 작업에 많이 참여합니다.
RubberDuck

답변:


6

현재 정확한 참조를 찾는 데 어려움을 겪고 있지만 얼마 전에 Haskell의 디자인에 크게 기여한 Simon Peyton Jones의 비디오를 몇 번 보았습니다 . 그는 형식 이론, 언어 디자인 등에 대한 훌륭한 연설자이며 유튜브에서 무료로 많은 비디오를 볼 수 있습니다.

Haskell은 작업하기 쉽도록 몇 가지 간단한 것들로 기본적으로 람다 미적분학을 나타내는 중간 표현을 가지고 있습니다. 람다 미적분학은 컴퓨터가 물건을 계산 한 사람이기 때문에 사용되고 입증되었습니다. Simon Peyton Jones가 자주하는 흥미로운 점은 언어에 열광하고 미친 일을 할 때마다 결국 그 중간 언어로 되돌아 갈 때 기본적으로 소리가 난다는 것입니다.

다른 언어는 그다지 엄격하지 않으며 사용이나 구현의 용이성을 선호합니다. 그들은 다른 프로그래머들이 양질의 코드를 얻기 위해하는 것과 같은 일을한다 : 좋은 코딩 관행을 따르고 그것을 시험해 본다. Rust의 소유권 의미와 같은 기능 필자는 잊혀진 코너 케이스를 찾기 위해 공식적인 분석과 테스트를 많이 받는다. 종종 이와 같은 기능은 누군가의 대학원 논문으로 시작됩니다.


2
나는 당신이 찾고있는 참고 문헌이 "하스켈의 형태를 가진 모험"시리즈 중 하나라고 생각합니다. 아마도 이것은 썸네일 이미지에있는 보드의 내용을 고려 했을 것입니다 .
Jules

8

언어 디자인 에는 증거 (또는 버그)가 있습니다. 예를 들어, 시스템을 입력하십시오. 유형 및 프로그래밍 언어 는 유형 시스템을 설명하는 표준 책이며 유형 시스템의 정확성과 완전성을 증명하는 데 중점을 둡니다. 문법에는 비슷한 분석이 있으며 알고리즘 (예 : 설명하는 소유권 시스템)에는 고유 한 알고리즘이 있습니다.

언어 구현의 경우 다른 코드와 같습니다. 단위 테스트를 작성합니다. 통합 테스트를 작성합니다. 코드 검토를 수행합니다.

언어를 특별하게 만드는 유일한 것은 언어가 (거의 항상) 무한하다는 것입니다. 말 그대로 모든 입력을 테스트 할 수는 없습니다. 언어에있는 버그가 수 있도록 그리고 (이상적) 그들은, 이상하고 흥미로운 일을하는 사람들의 톤을 사용하는 것입니다 결국 찾을 수.

실제로 , 언어를 사용하여 기능을 확인하고 언급 한 여러 옵션을 혼합하여 사용하는 언어는 상대적으로 거의 없습니다.


4
The only thing that makes languages special is that they are (almost always) infinite. You literally cannot test all inputs.정말 특별합니까? 그것은 나에게 일반적인 경우 인 것 같습니다. 예 :리스트를 인수로 취하는 함수에는 무한한 수의 입력이 있습니다. 어떤 크기 n을 선택하든, 크기 n + 1의 목록이 있습니다.
Doval

@doval-그리고 문자열도 있다고 가정합니다. 좋은 지적입니다.
Telastyn

4

새로운 기능을 도입 할 때 언어 디자이너가 가장 먼저 처리해야하는 가장 어려운 일은 언어를 일관성있게 유지하는 것입니다.

  • 기존 코드를 손상시키지 않고 언어 문법에 통합하는 방법 (수학적으로 입증 될 수 있음)
  • 기존 기능과 관련이있는 방법 (예 : 고정 배열이 0..n-1 인 경우 색인이 1..n 인 새로운 가변 배열 기능을 도입하지 않음) (디자인의 예술적 부분)
  • 생태계, 툴 메이커 및 프로그래머가 새로운 기능을 흡수 할 수 있도록 전체 툴체인에 대해 기능을 구현할 수있는 방법

이 문제를 해결하기 위해 설계자는 일련의 설계 규칙과 원칙에 의존합니다. 이 접근법은 언어 디자인에 관한 희귀 서적 중 하나 인 Bjarne Stroustrup의 " C ++의 디자인과 진화 "에 잘 설명되어 있습니다. 흥미로운 점은 언어가 진공 상태에서 거의 설계되지 않았으며 디자이너가 언어가 유사한 기능을 구현 한 방식을 살펴 보는 것입니다. 또 다른 소스 (온라인 및 무료)는 Java 언어설계 원칙입니다 .

표준화위원회의 공개 절차를 살펴보면 시행 착오 과정이 더 많은 과정임을 알 수 있습니다. C ++ 모듈 에 대한 예제 는 다음 버전의 언어에 도입 될 완전히 새로운 개념입니다. 그리고 여기에 언어의 변화 후에 그 성공을 평가하기 위한 분석이 작성되었습니다 . 그리고 여기 에 새로운 api 와 같은 새로운 Java 사양을 정의 하는 Java Community Process 가 있습니다. 이 작업은 컨셉트 용지와 첫 번째 제안을 창의적으로 작성하는 여러 전문가가 수행 한 것을 볼 수 있습니다. 그런 다음 이러한 제안은 더 큰 커뮤니티 /위원회에서 검토하여 더 높은 일관성을 보장하기 위해 제안을 수정할 수 있습니다.


4

프로그래밍 언어 기능을 테스트하는 방법? 매우 좋은 질문이며, 최첨단 기술이 제대로 작동하는지 잘 모르겠습니다.

각각의 새로운 기능은 다른 모든 기능과 상호 작용할 수 있습니다. (이는 언어, 문서, 컴파일러, 오류 메시지, IDE, 라이브러리 등에 영향을줍니다.) 기능을 결합하여 허점을 열 수 있습니까? 거친 경우를 만들려면?

유형 건전성을 유지하기 위해 열심히 노력하는 매우 똑똑한 언어 디자이너 조차도이 녹 버그 와 같은 위반을 발견 합니다. Rust의 타입 시스템은 나에게는 분명하지 않지만이 경우 타입 시스템 트랙 값 수명을 갖는 것은 평생 "서브 타이핑"(하위 범위)이 일반적인 서브 타이핑, 강제, 참조 및 변경 가능성에 대한 기대와 충돌하여 static평생 의 허점을 만듭니다 ref는 스택 할당 값을 가리키고 나중에 댕글 링 참조가됩니다.

"올바로 작동"한다는 것은이 기능이 의도 한 문제를 올바르게 해결한다는 것을 의미하며, 이는 상당히 방탄입니다.

언어 의도를 들어 생산 언어 신뢰할 수있는 제작 소프트웨어를 구축하기 위해 많은 프로그래머에 의해, 사용, 더 정확하게 의도 된 문제를 해결하는 것을 의미한다 "제대로 작동" 의도 관객.

즉, 다른 종류의 디자인과 마찬가지로 언어 디자인에도 유용성 이 중요합니다. 여기에는 (1) 유용성을위한 디자인 (예 : 고객 파악) 및 (2) 유용성 테스트가 필요합니다.

이 주제에 대한 예제 기사는 " 프로그래머는 사람, 사람, 프로그래밍 언어이며 API 디자이너는 인적 요소 디자인 분야에서 많은 것을 배울 수 있습니다."입니다.

이 주제에 대한 SE 질문의 예는 다음과 같습니다. 프로그래밍 언어의 구문이 사용성 테스트 되었습니까?

사용성 테스트의 예는 목록 반복 기능을 확장하여 여러 목록을 가져 오는 것을 고려했습니다. 사람들이 목록을 병렬로 또는 교차 제품을 통해 반복 할 것으로 기대 했습니까? 언어 디자이너들은 유용성 테스트 결과에 놀랐습니다.

스몰 토크, 파이썬, 다트와 같은 언어는 유용성을 강조하여 설계되었습니다. 분명히 하스켈은 아니었다.


하스켈은 실제로 꽤 유용합니다. 파이썬 / C / Java 등에 대한 패러다임이기 때문에 배우기가 어렵습니다. 그러나 언어로는 사용하기가 쉽습니다.
세미콜론
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.