프로그래밍 언어 사양

Programming language specification

컴퓨터 프로그래밍에서 프로그래밍 언어 사양(또는 표준 또는 정의)은 사용자와 구현자가 해당 언어의 프로그램이 무엇을 의미하는지 동의할 수 있도록 프로그래밍 언어를 정의하는 문서 아티팩트입니다.사양은 일반적으로 상세하고 형식적이며 주로 구현자에 의해 사용되며 사용자가 애매한 경우에 참조합니다.예를 들어 C++ 사양은 복잡하기 때문에 사용자가 자주 인용합니다.관련 문서에는 사용자를 위해 특별히 고안된 프로그래밍 언어 참조 및 사양이 그대로 작성된 이유를 설명하는 프로그래밍 언어 근거가 포함되어 있습니다.이러한 문서는 일반적으로 사양보다 더 격식을 차리지 않습니다.

표준화

모든 주요 프로그래밍 언어가 사양서를 가지고 있는 것은 아니며, 사양서 없이도 언어는 수십 년 동안 존재하며 인기를 끌 수 있습니다.언어에는, 사양에 기재되어 있지 않고, 그 동작이 사실상의 표준으로서 기능하는 1개 이상의 실장이 있는 경우가 있습니다.Perl(Perl 5까지)은 사양이 없는 언어의 주목할 만한 예입니다.PHP는 20년 [1]동안 사용된 후 2014년에야 지정되었습니다.언어는 구현 및 지정, 지정 및 구현될 수 있습니다.또한 이들 언어가 함께 개발될 수도 있습니다.이것은 오늘날 일반적인 관행입니다.이는 구현과 사양이 서로 체크하기 때문입니다.사양서를 작성하려면 구현 동작을 정확하게 기술해야 하며 구현은 사양이 가능하고 실용적이며 일관성이 있는지 확인합니다.ALGOL 68(1968) 이후 구현이 지연될 때 예기치 않은 구현 어려움으로 인해 구현 전에 사양을 작성하는 것은 대부분 회피되어 왔습니다.그러나 언어는 여전히 공식 사양 없이 구현되어 인기를 얻고 있습니다. 구현은 사용에 필수적인 반면 사양은 바람직하지만 필수적인 것은 아닙니다(비공식적으로 "코드 토크").

ALGOL 68은 구현되기 전에 완전한 정식 정의가 이루어진 최초의 (아마도 마지막) 메이저 언어입니다.

--

폼

프로그래밍 언어 사양은 다음과 같은 여러 가지 형식을 취할 수 있습니다.

  • 언어의 구문 및 의미론에 대한 명시적 정의입니다.구문은 일반적으로 형식 문법을 사용하여 지정되지만, 의미 정의는 자연어(예를 들어, C 언어에 대해 취해진 접근법) 또는 형식 의미론(예를 들어, 표준 ML[3] 및 체계[4] 사양)으로 작성될 수 있습니다.주목할 만한 예는 공식 사양 없이 인기를 얻은 C 언어입니다. 대신 C 프로그래밍 언어라는 책의 일부로 기술되고 훨씬 후에 ANSI C(1989)에서 공식적으로 표준화되었습니다.
  • 언어(예를 들어 C++ 언어 및 Fortran)에 대한 컴파일러('변환기'라고도 함)의 동작에 대한 설명입니다.언어의 구문과 의미론은 자연어 또는 형식어로 쓰여질 수 있는 이 설명에서 추론되어야 합니다.
  • 모델 구현. 경우에 따라 지정된 언어(프롤로그 등)로 작성될 수 있습니다.언어의 구문과 의미론은 모델 구현 동작에서 명시적입니다.

구문

프로그래밍 언어의 구문은 허용 가능한 단어의 정의를 나타냅니다. 즉, 주어진 코드가 언어에 대해 유효한지 여부를 결정하는 공식 매개 변수와 규칙입니다.이 점에서 언어 구문은 보통 다음 3가지 구성 요소의 조합으로 구성됩니다.

  • 알파벳(공백하지 않은 유한 기호 집합, 보통 유니코드 문자)
  • 어휘소를 설명하는 정규 표현식(알파벳별 토큰화용)
  • 올바른 프로그램을 형성하기 위해 어휘소가 어떻게 조합될 수 있는지를 설명하는 문맥 없는 문법

구문 사양은 보통 약간의 이해성을 제공하기 위해 자연어 기술을 가정한다.다만, 상기의 개략적인 컴포넌트의 공식적인 표현은, 언어와 그 개념의 실장과 승인을 중시하기 때문에, 통상은 섹션의 일부입니다.

의미론

크고 복잡한 실용적인 프로그래밍 언어의 엄밀한 의미를 정의하는 것은 숙련된 전문가에게도 어려운 작업이며, 그 결과 발생하는 사양은 전문가 이외에는 이해하기 어려울 수 있습니다.다음은 프로그래밍 언어 의미론을 기술할 수 있는 몇 가지 방법입니다. 모든 언어는 이러한 기술 방법 중 적어도 하나를 사용하며, 일부 언어는 둘 이상의[5] 방법을 결합합니다.

자연어

가장 널리 사용되는 언어는 의미론의 자연어 설명을 사용하여 지정됩니다.이 설명은 보통 언어에 대한 참조 매뉴얼의 형태를 취합니다.이 매뉴얼은 수백 페이지에 달할 수 있습니다.예를 들어, 「Java Language Specification, 3rd Ed.」의 인쇄판은 596 페이지입니다.

프로그래밍 언어 의미론을 기술하기 위한 수단으로서의 자연어의 부정확성은 사양을 해석하는 데 문제를 일으킬 수 있습니다.예를 들어 Java 스레드의 시멘틱스는 영어로 지정되었으며, 나중에 이 사양이 [6]구현자에게 적절한 지침을 제공하지 않는다는 것이 밝혀졌습니다.

형식 의미론

주요 기사:프로그래밍 언어의 형식적 의미론

형식적 의미론은 수학에 기초하고 있다.결과적으로, 그것들은 자연어로 주어진 의미론보다 더 정확하고 덜 모호할 수 있다.그러나, 의미론의 보충 자연어 서술은 종종 공식 정의를 이해하는 데 도움이 되도록 포함되어 있다.예를 들어 모듈라-2에 대한 ISO 표준은 서로 반대되는 페이지에 공식 언어 정의와 자연 언어 정의를 모두 포함합니다.

의미론이 공식적으로 기술된 프로그래밍 언어는 많은 이점을 얻을 수 있습니다.예를 들어 다음과 같습니다.

  • 형식적 의미론은 프로그램 정확성의 수학적 증명을 가능하게 한다.
  • 형식적 의미론은 유형 시스템의 설계를 용이하게 하고, 그러한 유형 시스템의 건전성에 대한 증거를 제공한다.
  • 형식적 의미론은 언어의 구현을 위한 명확하고 균일한 표준을 확립할 수 있다.

자동 도구 지원은 이러한 이점 중 일부를 실현하는 데 도움이 됩니다.예를 들어, 자동화된 정리 프로버 또는 정리 체커는 프로그램(또는 언어 자체)에 대한 증명의 정확성에 대한 프로그래머(또는 언어 설계자의)의 신뢰를 높일 수 있다.이러한 도구의 힘과 확장성 널리:전체 형식적 검증 computationally, 거의 프로그램 몇 백 lines[표창 필요한]이 들어 있는 이상으로 조절하고 프로그래머로부터 상당한 매뉴얼 지원을 요구할 수 있다는 집중적이다;모델 체커와 같은 더 가벼운 도구와 프로로 사용되고 있는 자원을 필요로 하며 다양하다.gcontaining 수만 행의 컴파일러.많은 컴파일러가 컴파일하는 모든 프로그램에 정적 유형 체크를 적용합니다.

레퍼런스 실장

참조 실장은 신뢰할 수 있는 것으로 지정된 프로그래밍 언어의 단일 실장입니다.이 구현의 동작은 언어로 작성된 프로그램의 적절한 동작을 정의하기 위해 유지됩니다.이 접근법에는 몇 가지 매력적인 특성이 있습니다.첫째, 그것은 정확하고 인간의 해석이 필요하지 않다: 프로그램의 의미에 대한 논쟁은 참조 구현에서 프로그램을 실행하는 것만으로 간단히 해결할 수 있다(그 프로그램에 대해 구현이 결정적으로 동작하는 경우).

한편, 참조 구현을 통해 언어 의미론을 정의하는 것은 또한 몇 가지 잠재적인 결점을 가지고 있다.그 중 가장 중요한 것은 참조 구현의 한계를 언어의 속성과 혼동한다는 것입니다.예를 들어, 참조 실장에 버그가 있는 경우, 그 버그는 신뢰할 수 있는 동작으로 간주할 필요가 있습니다.또 다른 단점은 이 언어로 작성된 프로그램이 참조 구현의 기호에 의존하여 다른 구현 간의 이식성을 저해할 수 있다는 것입니다.

그럼에도 불구하고 여러 언어가 참조 구현 접근방식을 성공적으로 사용해 왔습니다.예를 들어 Perl 인터프리터는 Perl 프로그램의 권위 있는 동작을 정의하는 것으로 간주됩니다.Perl의 경우, 소프트웨어 배포의 오픈 소스 모델은 아무도 언어의 다른 구현을 만들어내지 못했다는 사실에 기여하고 있기 때문에, 언어의 의미론을 정의하기 위한 참조 구현을 사용하는 것과 관련된 문제는 없다.

테스트 스위트

테스트 스위트의 관점에서 프로그래밍 언어의 의미론을 정의하려면 해당 언어로 다수의 예제 프로그램을 작성한 후 해당 프로그램이 어떻게 동작해야 하는지를 기술해야 합니다(아마도 올바른 출력을 기록함으로써).프로그램과 그 출력은 언어의 "테스트 세트"라고 불립니다.올바른 언어를 구현하려면 테스트 스위트 프로그램에서 정확한 출력을 생성해야 합니다.

의미 기술에 대한 이 접근방식의 주요 장점은 언어 구현이 테스트 스위트를 통과하는지 여부를 쉽게 판단할 수 있다는 것이다.사용자는 테스트 스위트의 모든 프로그램을 실행하여 출력을 원하는 출력과 비교할 수 있습니다.단, 테스트 스위트접근법 자체를 사용할 경우 큰 단점도 있습니다.예를 들어, 사용자는 테스트 스위트의 일부가 아닌 자신만의 프로그램을 실행하려고 합니다.실제로 테스트 스위트 내에서만 프로그램을 실행할 수 있는 언어 구현은 큰 도움이 되지 않습니다.그러나 테스트 스위트 자체로는 테스트 스위트에 포함되지 않은 프로그램에서 언어 구현이 어떻게 동작해야 하는지 설명하지 않습니다.그 동작을 판단하려면 구현자 측의 추론이 필요하며 구현자마다 다를 수 있습니다.또한 테스트 스위트를 사용하여 비결정적인 동작을 테스트하는 것은 어렵습니다.

따라서 일반적으로 테스트 스위트는 자연어 기술 또는 참조 구현과 같은 다른 언어 사양 기법 중 하나와 조합하여만 사용됩니다.

「 」를 참조해 주세요.

외부 링크

언어 사양

공식 또는 초안 언어 사양의 몇 가지 예를 다음에 제시하겠습니다.

메모들

  1. ^ 2014년 7월 30일 PHP 사양 발표, Joel Marcey
  2. ^ "A Shorter History of Algol68". Archived from the original on August 10, 2006. Retrieved September 15, 2006.
  3. ^ Milner, R.; M. Tofte; R. Harper; D. MacQueen (1997). The Definition of Standard ML (Revised). MIT Press. ISBN 0-262-63181-4.
  4. ^ Kelsey, Richard; William Clinger; Jonathan Rees (February 1998). "Section 7.2 Formal semantics". Revised5 Report on the Algorithmic Language Scheme. Retrieved 2006-06-09.
  5. ^ Jones, D. (2008). Forms of language specification (PDF). Retrieved 2012-06-23.
  6. ^ 윌리엄 푸Java 메모리 모델에 치명적인 결함이 있습니다.동시성: 연습과 경험 12(6): 445-455, 2000년8월