나는이 용어가 여러 다른 상황에서 계속 던져지고 있다고 들었습니다. 무엇입니까?

선언적 프로그래밍은 원하는 방식이 아니라 원하는 방식으로 코드를 작성할 때 사용됩니다. 방법을 알아내는 것은 컴파일러에게 맡겨져 있습니다.

선언적 프로그래밍 언어의 예로는 SQL 및 Prolog가 있습니다.

다른 답변은 이미 선언적 프로그래밍이 무엇인지 설명하는 환상적인 작업을 수행하므로 유용한 이유에 대한 몇 가지 예를 제공하겠습니다.

상황 독립

선언적 프로그램은 상황에 따라 다릅니다 . 그들은 궁극적 인 목표 만 선언하고 그 목표를 달성하기위한 중개 단계는 선언하지 않기 때문에 다른 프로그램에서 동일한 프로그램을 사용할 수 있습니다. 그것들은 종종 문맥 (예 : 숨겨진 상태)에 의존하기 때문에 명령형 프로그램 과 는 관련이 없습니다.

가지고 yacc예를 들어. 파서 생성기 일명입니다. 컴파일러 컴파일러, 언어의 문법을 설명하기위한 외부 선언적 DSL로 해당 언어의 구문 분석기가 설명에서 자동으로 생성 될 수 있습니다. 문맥 독립성 때문에 다음과 같은 문법으로 여러 가지 일을 할 수 있습니다.

• 해당 문법에 대한 C 파서를 생성합니다 (의 원래 사용 사례 yacc)
• 해당 문법에 대한 C ++ 파서를 생성
• 해당 문법에 대한 Java 파서 생성 (Jay 사용)
• 해당 문법에 대한 C # 파서 생성 (GPPG 사용)
• 해당 문법에 대한 루비 파서 생성 (Racc 사용)
• 해당 문법에 대한 트리 시각화 생성 (GraphViz 사용)
• yacc 소스 파일 자체를 예쁘게 인쇄하고, 화려하게 형식화하고, 구문을 강조하기 만하면 참조 설명서에 언어의 구문 사양으로 포함시킬 수 있습니다.

그리고 더 많은 …

최적화

어떤 단계를 거치고 어떤 순서로 컴퓨터를 처방하지 않기 때문에 프로그램을 훨씬 더 자유롭게 재정렬하고 일부 작업을 병렬로 실행할 수도 있습니다. 좋은 예는 SQL 데이터베이스에 대한 쿼리 플래너 및 쿼리 최적화 프로그램입니다. 대부분의 SQL 데이터베이스에서는 실제로 실행중인 쿼리와 실행 하도록 요청한 쿼리를 표시 할 수 있습니다. 종종 이러한 쿼리는 아무것도 보이지 않습니다.서로처럼. 쿼리 플래너는 디스크 플래터의 회전 대기 시간 또는 완전히 다른 사용자를 위해 완전히 다른 일부 응용 프로그램이 비슷한 쿼리와 테이블을 실행했다는 사실과 같이 꿈도 꾸지 못했던 것을 고려합니다. 로드를 피하기 위해 열심히 노력했다는 사실은 이미 메모리에 있습니다.

기계가 알아 내기 위해 더 열심히 일해야 :이 흥미로운 트레이드 오프는 여기에 방법 이 명령형 언어에서와보다 뭔가를하지만,이 때 않는 그림 그것을 밖으로, 그것은 최적화를위한 더 많은 자유와 더 많은 정보를 가지고 단계.

느슨하게:

선언적 프로그래밍은 다음과 같은 경향이 있습니다.

• 각각은 문제 영역에서 의미를 가지며 독립적이고 독립적으로 이해 될 수있는 선언 또는 선언문 집합입니다.

명령형 프로그래밍은 다음과 같은 경향이 있습니다.

• 각각의 동작을 수행하는 일련의 명령; 그러나 문제 영역에서 의미가 있거나 없을 수 있습니다.

결과적으로 명령형 스타일은 독자가 시스템이 실제로 수행하는 작업의 메커니즘을 이해하는 데 도움이되지만 해결하려는 문제에 대한 통찰력을 거의 제공하지 못할 수 있습니다. 다른 한편으로, 선언적 스타일은 독자가 문제 영역과 시스템이 문제 해결을 위해 취하는 접근법을 이해하는 데 도움이되지만, 기계 문제에 대해서는 덜 유익합니다.

실제 프로그램 (ProLog 또는 C와 같이 스펙트럼의 끝을 선호하는 언어로 작성된 프로그램조차도)은 다양한 점에서 다양한 스타일로 존재하여 조각의 다양한 복잡성 및 통신 요구를 충족시키는 경향이 있습니다. 한 스타일은 다른 스타일보다 우수하지 않습니다. 그들은 단지 다른 목적에 봉사하며 인생의 많은 것들과 마찬가지로 중재가 핵심입니다.

다음은 예입니다.

CSS (HTML 페이지 스타일 지정에 사용)에서 이미지 요소의 높이와 너비가 100 픽셀이되도록하려면 다음과 같이 원하는 것을 "선언"하면됩니다.

#myImageId {
height: 100px;
width: 100px;
}

CSS를 선언적인 "스타일 시트"언어로 생각할 수 있습니다.

이 CSS 를 읽고 해석 하는 브라우저 엔진 은 이미지를 키가 크고 넓게 보이도록 자유롭게 만들 수 있습니다. 다른 브라우저 엔진 (예 : IE 엔진, Chrome 엔진)은이 작업을 다르게 구현합니다.

물론 고유 한 구현은 선언적 언어로 작성되지 않고 Assembly, C, C ++, Java, JavaScript 또는 Python과 같은 절차 적 언어로 작성됩니다. 이 코드는 단계별로 수행되는 많은 단계이며 함수 호출을 포함 할 수 있습니다. 픽셀 값을 보간하고 화면에 렌더링하는 등의 작업을 수행 할 수 있습니다.

미안하지만 다른 많은 답변에 동의하지 않아야합니다. 선언적 프로그래밍의 정의에 대한이 오해를 막고 싶습니다.

정의

하위 표현식의 참조 투명도 (RT) 는 선언적 프로그래밍 표현식 의 유일한 필수 속성입니다 . 명령형 프로그래밍과 공유되지 않는 유일한 속성이기 때문입니다.

선언적 프로그래밍의 다른 인용 된 속성은이 RT에서 파생됩니다. 자세한 설명은 위의 하이퍼 링크를 클릭하십시오.

스프레드 시트 예

두 가지 답변에 스프레드 시트 프로그래밍이 언급되었습니다. 스프레드 시트 프로그래밍 (일명 수식)이 변경 가능한 전역 상태에 액세스하지 않는 경우 선언적 프로그래밍입니다. 변경이 용이 한 셀의 값은 단일체 때문이다 입력 과 출력 의 main()(전체 프로그램). 새 값은 각 수식이 실행 된 후 셀에 기록되지 않으므로 선언적 프로그램 수명 동안 스프레드 시트에서 모든 수식이 실행되도록 변경할 수 없습니다. 따라서, 서로에 대해, 상기 식은 이러한 가변성 세포를 불변성으로 본다. RT 함수는 불변의 글로벌 상태 (및 변이 가능한 로컬 상태 ) 에 액세스 할 수 있습니다 .

따라서 프로그램이 종료 될 때 (의 출력으로 main()) 셀의 값을 변경하는 기능 은 규칙 컨텍스트에서 변경 가능한 저장된 값을 만들지 않습니다. 중요한 차이점은 각 스프레드 시트 수식이 수행 된 후에 셀 값이 업데이트되지 않으므로 수식을 수행하는 순서는 중요하지 않습니다. 모든 선언식이 수행 된 후 셀 값이 업데이트됩니다.

선언적 프로그래밍은 그림이며 명령형 프로그래밍은 해당 그림을 그리는 지침입니다.

컴퓨터가 원하는 위치에 도달하기 위해 수행해야하는 단계를 설명하는 것이 아니라 "그것이 무엇인지 알려면"선언적 스타일로 작성합니다.

XML을 사용하여 데이터를 마크 업하는 경우 "이 사람은 생일이고 거리 주소가 있습니다"라고 말하고 있기 때문에 선언적 프로그래밍을 사용하고 있습니다.

선언적 프로그래밍과 명령형 프로그래밍이 더 큰 효과를 위해 결합되는 몇 가지 예 :

• Windows Presentation Foundation은 선언적 XML 구문을 사용하여 사용자 인터페이스의 모양과 컨트롤과 기본 데이터 구조 간의 관계 (바인딩)를 설명합니다.

• 구조화 된 구성 파일은 선언적 구문 ( "key = value"쌍과 같이 단순한)을 사용하여 문자열 또는 데이터 값의 의미를 식별합니다.

• HTML은 텍스트 전체가 문서 전체에서 어떤 역할을하는지 설명하는 태그로 텍스트를 표시합니다.

선언적 프로그래밍은 선언, 즉 선언적 문장으로 프로그래밍됩니다. 선언적 문장에는 명령형 문장과 구별되는 여러 속성이 있습니다. 특히 선언은 다음과 같습니다.

• 정류 (재주문 가능)
• 연관성 (재 그룹화 가능)
• dem 등원 (의미의 변화없이 반복 가능)
• 단조 (선언은 정보를 빼지 않습니다)

관련 포인트는 모두 구조적 특성이며 주제와 직교한다는 것입니다. 선언은 "What vs. How" 에 관한 것이 아닙니다 . "what"을 선언하는 것처럼 "how" 를 쉽게 선언 (표시 및 제한) 할 수 있습니다 . 선언은 내용이 아니라 구조에 관한 것입니다. 선언적 프로그래밍은 코드를 추상화하고 리팩토링하는 방법과 코드를 서브 프로그램으로 모듈화하는 방법에 크게 영향을 주지만 도메인 모델에는 그다지 중요하지 않습니다.

종종 문맥을 추가하여 명령형에서 선언 형으로 변환 할 수 있습니다. 예 : "왼쪽으로 돌립니다. (... 기다립니다 ...) 우회전" "밥은 11시 01 분에 푸와 바의 교차로에서 좌회전합니다. 밥은 11시 6 분에 바와 바즈의 교차로에서 우회전합니다." 후자의 경우에는 문장이 dem 등하 고 정식적인 반면, 전자의 경우에는 문장의 재 배열이나 반복이 프로그램의 의미를 심각하게 변화시킬 수 있습니다.

단조 론 에 관해서는 , 선언은 가능성 을 빼는 제약 을 추가 할 수 있습니다 . 그러나 제약 조건은 여전히 ​​정보를 추가합니다 (보다 정확하게는 제약 조건은 정보 임). 시변 선언이 필요한 경우 명시적인 시간적 의미론을 사용하여이를 모델링하는 것이 일반적입니다. 예를 들어 "공은 평평합니다"에서 "공은 시간 T에 평평합니다". 모순되는 선언이 두 개있는 경우 일관성이없는 선언 시스템이 있지만 이는 부드러운 제약 조건 (우선 순위, 확률 등)을 도입하거나 불일치 논리를 활용하여 해결할 수 있습니다.

무언가를하는 방법이 아니라 원하는 것을 컴퓨터에 서술하기.

엑셀 페이지를 상상해보십시오. 세금 환급을 계산하는 수식으로 채워진 열.

모든 논리는 셀에 선언되어 있으며 계산 순서는 절차 적이 라기보다는 공식 자체에 의해 결정됩니다.

그것은 선언적 프로그래밍에 관한 것입니다. 프로그램의 흐름보다는 문제 공간과 솔루션을 선언합니다.

프롤로그는 내가 사용한 유일한 선언적 언어입니다. 다른 종류의 사고가 필요하지만 일반적인 절차 적 프로그래밍 언어 이외의 것에 노출시키는 경우 배우는 것이 좋습니다.

이 질문에 대한 답변 을 제공 한 2011 년 12 월부터 선언적 프로그래밍에 대한 이해를 개선했습니다 . 여기 내 현재 이해가 이어집니다.

내 링크 (연구)의 긴 버전 이이 링크에 자세히 나와 있습니다. 나와 있습니다.

명령형 프로그래밍은 변경 가능한 상태가 저장되고 읽히는 위치이므로 프로그램 명령의 순서 및 / 또는 복제는 프로그램의 동작 (의미론)을 변경 (및 의도하지 않은 동작, 버그를 유발할 수 있음) 할 수 있습니다.

가장 순진하고 극단적 인 의미 (이전 답변에서 주장한)에서 선언적 프로그래밍 (DP)은 저장된 모든 변경 가능한 상태를 피하므로 프로그램 명령의 순서 및 / 또는 복제는 프로그램 의 동작 (의미론)을 변경할 수 없습니다 .

그러나 거의 모든 프로그램에 저장된 변경 가능 상태가 포함되므로 이러한 극단적 인 정의는 실제 세계에서는 그다지 유용하지 않습니다. 스프레드 예 새로운 상태가 저장되기 전에 전체 프로그램 코드는, 상기 입력 한 상태로 고정 복사 완료 될 때까지 실행되기 때문에 DP의 극단적 인 정의에 준거. 그런 다음 상태가 변경되면이 과정이 반복됩니다. 그러나 대부분의 실제 프로그램은 이러한 국가 변화의 모 놀리 식 모델로 제한 될 수 없습니다.

DP의보다 유용한 정의는 프로그래밍 명령의 순서 및 / 또는 복제가 불투명 한 의미를 변경하지 않는다는 것입니다. 다시 말해, 의미론에 숨겨진 무작위 변경이 발생하지 않습니다. 프로그램 명령 순서 및 / 또는 복제의 변경으로 인해 프로그램 동작이 의도적이고 투명하게 변경 될뿐입니다.

다음 단계는 DP에 어떤 프로그래밍 모델이나 패러다임이 도움이되는지 이야기하는 것이지만 여기서는 문제가되지 않습니다.

작동 방식 을 설명 하는 대신 무엇을해야하는지 또는 무엇을해야 하는지를 설명하는 프로그래밍 방법입니다 .

다시 말해, 표현으로 만든 알고리즘을 쓰지 않고 원하는 방식으로 레이아웃을 만드는 것입니다. 두 가지 좋은 예는 HTML과 WPF입니다.

이 Wikipedia 기사는 좋은 개요입니다 : http://en.wikipedia.org/wiki/Declarative_programming

사전 답변을 작성 했으므로 아래 인용 된 선언적 속성에 대한 새로운 정의 를 공식화했습니다 . 또한 명령형 프로그래밍을 이중 속성으로 정의했습니다.

이 정의는 간결하고 일반적이기 때문에 이전 답변에서 제공 한 것보다 우수합니다. 그러나 프로그래밍과 삶에 일반적으로 적용되는 불완전 성 이론의 함의는 인간이 자신의 마음을 감싸기 어렵 기 때문에 이해하기가 더 어려울 수 있습니다.

인용 된 정의에 대한 설명은 선언적 프로그래밍에서 순수 기능 프로그래밍 이 수행하는 역할을 설명합니다 .

선언적 대 명령형

선언적 속성은 일반적이고 모호하지 않은 기술적으로 정확한 정의에서 기묘하고 모호하며 캡처하기가 어렵습니다. 의도하지 않은 부작용없이 프로그램의 의미 (일명 의미론)를 선언 할 수 있다는 순진한 개념이기 때문입니다. 의미의 표현과 의도하지 않은 효과의 회피 사이에는 본질적인 긴장이 있으며,이 긴장은 실제로 프로그래밍과 우주 의 불완전 성 이론 에서 비롯됩니다 .

그것은 기술적으로 부정확 한 지나친 단순화, 등과 같은 선언적 정의 종종 모호 " 무엇을 " 로하고 필수적 " 수행하는 방법 " . 모호한 경우는 프로그램을 출력하는 프로그램 (컴파일러 )의 " 무엇 "이 " 어떻게 "입니다.

분명히 완전한 튜링 언어를하게 억제 할 재귀는 또한 유사하다 semantics-에서뿐만 아니라 평가 (일명 운영 의미)의 구문 구조이다. 이것은 논리적으로 고델의 정리와 유사한 예입니다.“ 모든 공리 체계도 일관성이 없습니다 .” 그 말의 모순 된 이상한 점을 깊이 생각해보십시오! 따라서 그것은 우리가 증명할 수, 또한 의미의 표현이 증명 바인딩이없는 방법을 보여줍니다 예입니다 (2) 그 프로그램 (및 유사의 의미) 앞뒤가 맞지 정리 일명 정지.

불완전 성 정리는 열역학 제 2 법칙에 언급 된 바와 같이“ 엔트로피 (일명 독립 가능성의 수) 는 영원히 최대로 추세하고있다 . 프로그램의 코딩과 디자인은 실제 세계의 요구를 해결하려고 시도하기 때문에 결코 끝나지 않습니다. 실제 세계의 의미는 항상 더 많은 가능성으로 변하고 있습니다. 인간은 결코 새로운 것을 발견하는 것을 멈추지 않습니다 (프로그램의 오류를 포함하여 ;-).

가장자리가없는이 이상한 우주 (우주에서 "외부"가 없다고 생각하는) 내에서 앞서 언급 한 원하는 개념을 정확하고 기술적으로 포착하려면 간결하지만 기만적으로 단순하지 않은 정의가 필요합니다. 깊이.

정의:

---

선언적 속성은 각각의 특정 모듈 식 의미를 표현할 수있는 하나의 가능한 문장 세트 만 존재할 수있는 곳입니다.

명령형 속성 3 은 의미 상 구성이 일치하지 않고 및 / 또는 문장 세트의 변형으로 표현 될 수있는 이중입니다.

---

이러한 선언적 정의는 시맨틱 범위에서 뚜렷하게 지역적 이며, 이는 모듈 형 시맨틱이 글로벌 범위 에서 인스턴스화되고 어떻게 사용되는지에 관계없이 일관된 의미를 유지해야 함을 의미합니다 . 따라서 각 선언적 모듈 의미론은 가능한 모든 다른 것들과 본질적으로 직교해야하며 일관성을 증명하기위한 불가능한 (불완전 성 이론으로 인해) 글로벌 알고리즘이나 모델이 아니라 로버트 하퍼 (Robert Harper) 교수의“ 항상 더 좋은 것은 아니다 ” 표준 ML의 디자이너 중 하나 인 Carnegie Mellon University의 컴퓨터 과학 전공.

이러한 모듈 식 선언적 의미의 예는 카테고리 이론 펑은 예 포함 다음 의미의 운영 수준의 순수 함수형 프로그래밍에, 공칭 입력, 네임 스페이스, 이름 필드 및 WRT를.Applicative

따라서 잘 설계된 선언적 언어는 표현할 수있는 것에서 일반성이 약간 떨어지지 만 본질적인 일관성으로 표현할 수있는 것에서는 이득을 얻음에도 불구하고 의미를보다 명확하게 표현할 수 있습니다.

앞에서 언급 한 정의의 예는 스프레드 시트 프로그램의 셀에있는 수식 세트입니다. 다른 열 및 행 셀로 이동할 때 동일한 의미를 갖지 않을 것으로 예상됩니다. 즉, 셀 식별자가 변경되었습니다. 셀 식별자는 의도 된 의미의 일부이며 불필요한 것은 아닙니다. 따라서 각 스프레드 시트 결과는 일련의 수식에서 셀 식별자에 고유합니다. 이 경우 일관된 모듈 의미는 셀 수식을 셀 수식에 대한 순수한 함수 의 입력 및 출력으로 사용하는 것입니다 (아래 참조).

하이퍼 텍스트 마크 업 언어는 일명, HTML 정적 웹 페이지 -의 언어는 매우 (그러나 완벽의 예 3 (적어도 HTML 5 전) 동적 거동을 표현 할 능력이 없다고) 선언적 언어입니다. HTML은 아마도 배우기 가장 쉬운 언어 일 것입니다. 동적 동작의 경우 JavaScript와 같은 명령적인 스크립팅 언어는 일반적으로 HTML과 결합되었습니다. JavaScript가없는 HTML은 각 명목 유형 (즉, 태그)이 구문 규칙 내에서 구성에서 일관된 의미를 유지하기 때문에 선언적 정의에 적합합니다.

선언적에 대한 경쟁적 정의 는 의미 론적 문장 의 교환 적이고 dem 등한 속성입니다. 즉, 의미를 변경하지 않고 명령문을 재정렬하고 복제 할 수 있습니다. 예를 들어, 이름이 지정된 필드에 값을 할당하는 명령문은 프로그램의 의미를 암시 적 순서로 모듈화 한 경우 프로그램의 의미를 변경하지 않고 순서를 다시 정하고 복제 할 수 있습니다. 이름은 때때로 순서를 의미합니다. 예를 들어 셀 식별자에는 열과 행 위치가 포함됩니다. 스프레드 시트에서 합계를 이동하면 의미가 변경됩니다. 그렇지 않으면 이러한 속성은 암시 적으로 전역이의미론의 일관성. 순서와 복제가 의미론에 내재되어 있기 때문에 무작위로 정렬되거나 복제 된 경우 일관성을 유지하도록 명령문의 의미론을 설계하는 것은 일반적으로 불가능합니다. 예를 들어,“Foo 존재”(또는 구성) 및“Foo 존재하지 않습니다”(및 파기)라는 문구가 있습니다. 의도 된 의미론의 고유 불일치가 있다고 생각되면 선언적 특성에 대해 충분히 일반적인 것으로이 정의를 받아들입니다. 본질적으로이 정의는 의미론에 직교하는 일관성, 즉 의미론의 우주가 동적으로 제한되지 않고 글로벌 일관성 패러다임 에서 포착 될 수 없다는 사실을 무시하려고 시도하기 때문에 일반화 된 정의로 공허합니다 .

제 (구조의 평가 순서)에 교환 적 및 멱등 특성을 요구하는 낮은 수준의 선언적으로 연산 의미론 변환 연산을 의미 국소 모듈 의미, 즉 순수한 (대신 필수적 루프 재귀 포함) 함수형 프로그래밍. 그런 다음 구현 세부 사항의 작동 순서 는 상위 레벨 시맨틱의 일관성에 영향을 미치지 않습니다 (즉, 전체적으로 확산 됩니다). 예를 들어, 스프레드 시트 수식의 평가 순서 (및 이론적으로는 중복)는 모든 출력이 계산 될 때까지 (즉, 순수한 함수와 유사한) 출력이 입력으로 복사되지 않기 때문에 중요하지 않습니다.

C, Java, C ++, C #, PHP 및 JavaScript는 특별히 선언적이지 않습니다. Copute의 구문과 Python의 구문은 의도 된 결과 , 즉 불필요한 구문을 제거하는 일관된 구문 의미론 과보다 선언적으로 결합되어 있으므로 코드를 잊어 버린 후 쉽게 이해할 수 있습니다. Copute와 Haskell은 운영 의미론을 결정 하고 순수한 기능적 패러다임을 허용하기 때문에“ 반복하지 마십시오 ”(DRY)를 권장 합니다.

---

2 언어 Coq와 같이 프로그램의 의미론을 입증 할 수있는 경우에도, 이는 타이핑 으로 표현 된 의미론으로 제한되며, 타이핑은 프로그램의 모든 의미론을 캡처 할 수 없습니다. 튜링이 완료되지 않은 경우, 예를 들어 HTML + CSS를 사용하면 정의되지 않은 의미를 갖는 일치하지 않는 조합을 표현할 수 있습니다.

3 많은 설명은 명령형 프로그래밍 만이 구문 적으로 명령 된 문장을 가지고 있다고 잘못 주장하고있다. 나는 명령형 프로그래밍과 함수형 프로그래밍 사이의 혼란을 분명히했다 . 예를 들어, HTML 문의 순서는 의미의 일관성을 감소시키지 않습니다.

편집 : Robert Harper의 블로그에 다음 의견 을 게시했습니다 .

함수형 프로그래밍에서 변수의 변동 범위는 유형입니다.

명령형 프로그래밍과 기능을 구별하는 방법에 따라 명령형 프로그램에서 '지정 가능'은 가변성에 한계를 두는 유형을 가질 수도 있습니다.

내가 함수형 프로그래밍에 대해 현재 인정하고있는 머들 링되지 않은 유일한 정의는 a) 일류 객체 및 유형으로서의 함수, b) 루프에 대한 재귀에 대한 선호 및 / 또는 c) 순수한 함수, 즉 원하는 의미에 영향을 미치지 않는 함수 ( _{^{메모리 할당과 같은 연산 의미론의 영향으로 인해 범용 의미 상 의미론에는 완벽하게 순수한 기능적 프로그래밍이 존재하지 않습니다}} ).

순수 함수의 dem 등원 속성은 변수에 대한 함수 호출이 값으로 대체 될 수 있음을 의미하며 이는 일반적으로 명령 절차의 인수에는 해당되지 않습니다. 순수한 함수는 입력과 결과 유형 사이의 구성되지 않은 상태 전환에 대한 선언적인 것으로 보입니다.

그러나 순수한 함수의 구성은 그러한 일관성을 유지하지 못합니다. 하스켈의 IOMonad와 같은 순수한 함수형 프로그래밍 언어로 부작용 (글로벌 상태) 명령 프로세스를 모델링하는 것이 가능하기 때문에 이러한 기능을 방지하는 것은 완전히 불가능합니다. 모든 튜링은 완벽한 기능성 프로그래밍 언어입니다.

최근 블로그 에서 비슷한 의견에 대한 합의로 보이는 2012 년에 썼 듯이 선언적 프로그래밍은 의도 된 의미가 결코 불투명하지 않다는 개념을 포착하려는 시도입니다. 불투명 한 의미론의 예는 순서에 대한 의존성, 운영 의미 론적 계층에서 상위 수준 의미론의 소거에 대한 의존성 (예 : 캐스트는 변환이 아니며 통일 된 제네릭은 상위 수준 의미론을 제한 함 ), 확인할 수없는 변수 값에 대한 의존성 (증명 됨) 프로그래밍 언어로 수정하십시오.

따라서 나는 튜링이 아닌 완전한 언어 만이 선언적 일 수 있다고 결론지었습니다.

따라서 선언적 언어의 분명하고 명확한 특성 중 하나는 그 산출물이 열거 가능한 일련의 생성 규칙을 따르는 것으로 입증 될 수 있다는 것입니다. 예를 들어, 스크립트되지 않은 (즉, Turing이 완료되지 않은) 특정 HTML 프로그램 (통역사 분기 방식의 차이를 무시 함)의 경우 출력 변수를 열거 할 수 있습니다. 간결하게 HTML 프로그램은 그 가변성의 순수한 기능입니다. 스프레드 시트 프로그램 Ditto는 입력 변수의 순수한 기능입니다.

따라서 선언적 언어는 무한 재귀 의 대립이라고 할 수 있습니다. 즉, 고델의 두 번째 불완전 성 정리 자체 참조 이론에 따르면 입증 할 수 없습니다.

Lesie Lamport 는 유클리드가 프로그래밍 언어 맥락에서 수학 증명에 적용되는 고델 의 불완전 성 이론을 유형과 논리 (Curry-Howard 대응 등)와 일치시켜 어떻게 처리했는지에 대한 동화를 썼습니다 .

선언적 프로그래밍은 "기계의 작동 모델이 아닌 개발자의 정신 모델을 따르는 언어로 프로그래밍하는 행위"입니다.

선언적 프로그래밍과 명령형 프로그래밍의 차이점은 구조화 된 데이터 구문 분석 문제로 잘 설명됩니다.

명령형 프로그램은 상호 재귀 함수를 사용하여 입력을 소비하고 데이터를 생성합니다. 선언적 프로그램은 구문 분석 할 수 있도록 데이터의 구조를 정의하는 문법을 표현합니다.

이 두 가지 접근 방식의 차이점은 선언적 프로그램이 호스트 언어보다 문제의 정신 모델에 더 밀접하게 매핑되는 새로운 언어를 생성한다는 것입니다.

이상하게 들릴지 모르지만 선언적 시스템 목록에 Excel (또는 실제로 스프레드 시트)을 추가합니다. 이에 대한 좋은 예가 여기에 있습니다 .

DP는 표현하는 방법이므로 설명하겠습니다

• 목표 표현 , 조건에 - 우리가 찾고있는 것을. 하나 또는 여러 개가 있습니까?
• 몇 가지 알려진 사실
• 알고있는 사실을 확장시키는 규칙

... 그리고 목표를 찾기 위해 통일 알고리즘을 사용하는 공제 엔진 이있는 경우.

내가 알 수있는 한, 그것은 프롤로그가 (추상적으로) 물건을 추상적 인 방식으로 선언하는 것에 대해 있기 때문에 프롤로그와 같은 프로그래밍 시스템을 설명하는 데 사용되기 시작했습니다.

위의 사용자가 제공 한 정의를 갖기 때문에 점점 더 적은 의미를 갖습니다. HTML의 선언적 프로그래밍과는 달리 Haskell의 선언적 프로그래밍 사이에는 차이가 있음이 분명해야합니다.

선언적 프로그래밍의 다른 두 가지 예 :

• 데이터 바인딩을위한 ASP.Net 마크 업 예를 들어, "이 그리드를이 소스로 채운다"라고 말하면 어떻게되는지 시스템에 남겨 둡니다.
• Linq 표현식

선언적 프로그래밍은 코드 의 정신적 모델을 단순화하는 데 도움 이되고 결국에는 확장 성이 높아지기 때문에 좋습니다.

예를 들어, 배열 또는 목록의 각 요소에 대해 무언가를 수행하는 함수가 있다고 가정 해 봅시다. 전통적인 코드는 다음과 같습니다.

foreach (object item in MyList)
{
   DoSomething(item);
}

별거 아냐 그러나보다 선언적인 구문을 사용하고 대신 DoSomething ()을 동작으로 정의하면 어떻게됩니까? 그러면 다음과 같이 말할 수 있습니다.

MyList.ForEach(DoSometing);

물론 이것은 더 간결합니다. 그러나 여기저기서 두 줄의 코드를 저장하는 것보다 더 많은 걱정이 있다고 확신합니다. 예를 들어 성능. 옛날 방식으로 처리를 순서대로 수행해야했습니다. .ForEach () 메소드가 자동으로 병렬 처리를 처리 할 수 ​​있다는 신호를 보내는 방법이 있다면 어떨까요? 이제 갑자기 코드를 매우 안전한 방식으로 멀티 스레드로 만들고 한 줄의 코드 만 변경했습니다. 사실, .Net에 대한 확장 기능이있어이를 수행 할 수 있습니다.

• 해당 링크를 따라 가면 내 친구가 작성한 블로그 게시물로 이동합니다. 전체 게시물이 약간 길지만 "문제" 제목으로 스크롤하여 문제없이 찾을 수 있습니다. *

텍스트에 답변을 제출하는 방법에 따라 다릅니다. 전반적으로 특정보기에서 프로그램을 볼 수 있지만 문제를 보는 각도에 따라 다릅니다. Dim Bus, Car, Time, Height As Integr 프로그램을 시작하겠습니다.

다시 한 번 문제의 전반적인 내용에 달려 있습니다. 프로그램으로 인해 단축해야 할 수도 있습니다. 이것이 도움이되기를 바랍니다. 그렇지 않으면 피드백이 필요합니다. 감사합니다.