왜 대부분의 프로그래밍 언어에는 더 많은 제어 구조가 없습니까?

왜 대부분의 언어는 논리 관점에서 볼 때 매우 기본적인 제어 구조만을 나타내는 것처럼 보입니까? If ... then, Else ..., Loops, 각각에 대해 switch 문 등과 같은 것들. 표준 목록은 논리 관점에서 상당히 기본적인 것 같습니다.왜 대부분의 프로그래밍 언어에는 더 많은 제어 구조가 없습니까?

왜 논리 구문 설탕이 더 이상 없습니까? 아마도 당신이 복잡한 자체 참조 상호 의존 함수 및 결과를 반환하는 전제 또는 함수의 배열을 공급할 수있는 명제 엔진과 같은 것일 수 있습니다. 복잡한 조건의 배열을 함께 묶을 수 있지만 코드에서 쉽고 명확하게 읽을 수있는 방식으로 표현됩니다.

전제 1

전제 2 경우에만 전제 1

전제 3

전제 4 경우 전제 2 전제 3

전제 5 경우에만, 전제 4

경우

등 ...

결론

이 논리는 함수 및/또는 중첩 된 조건문에서 생성 될 수 있음을 알고 있습니다. 그러나 왜 이런 종류의 논리적 명제를 구조화하고 읽거나 디버그하기가 어려울 수있는 털이 보이는 조건문을 만들지 않고도 구문 옵션을 일반적으로 더 많이 사용하지 않는 이유는 무엇입니까?

주류 프로그래밍 언어에서 일반적으로 볼 수있는 제어 구조의 종류에 대한 설명이 있습니까? 언어 구문에 의해 직접 지원되는 특정 컨트롤 구조가 있습니까? 이렇게하면 불필요한 복잡성이 언어에 추가됩니까?

출처

2009-08-25 Gordon Potter

Prolog 보셨나요? 프롤로그 프로그램은 기본적으로 하나의 큰 평가 엔진으로 바뀌는 일련의 규칙입니다.

내 개인적인 경험에서 Prolog는 약간 이상하고 실제로는 ifs, whiles 등을 선호하지만 YMMV.

출처

2009-08-25 17:04:17

나는 그것에 대해 들어 보았지만 그걸로 아무것도하지 못했습니다. 그것을 탐험해야 할 것입니다. –

제 논리 수업이 끝나고 오랜 시간이 걸렸지 만 언어를 쓰는 데 어려움이 생길 때가 많고 사용 빈도가 많은 것 같아요. 나는 내가 그들을 기억할 필요가 없다고 말할 수 없다. 그 시간 동안, 언어 디자이너는 아마도 당신이 그저 기본적인 구조만으로 논리를 풀어 낼 수 있다고 생각합니다.

그냥 내 추측이지만.

출처

2009-08-25 17:05:11

부울 대수는 어렵지 않습니다.은 생각할 수있는 모든 조건에 대해 솔루션을 제공하고 무한한 수의 다른 변형을 제공합니다.

"일반적으로 사용되는"산술 표현식에 대한 특수 구문을 요청할 수도 있습니다. 일반적으로 사용되는 것으로 자격이 주어지는 것은 누구입니까? 특수 구문을 어디에 추가하지 않습니까?

구문 분석 구문을 사용하여 언어 구문 분석기의 복잡성을 추가하는 것은 정의 함수를 통한 확장 성과 결합하여 바람직하지 않습니다.컴퓨터가 진하기 때문에

출처

2009-08-25 17:05:43

이것이 바로 이유입니다. 질문에 열거 된 '복잡한 조건들의 배열'은 불리언 대수학 (boolean algebra)의 관점에서 완벽하게 표현됩니다. 평가 '엔진'(조건에 값을 묶는 것)을 만드는 것은 거의 모든 환경에서 매우 사소할 것입니다. – Quintus

나는 동의한다. 그러나 부울 대수에 쉽게 구현되지 않는 논리 패턴이 있는지 궁금해하고있었습니다. 나의 예는 간단하다. 나는 오래된 대학 논리 책을 열어서 예를 생각해 낼 필요가 있다고 생각한다. 그러나이 예제가 구현하기가 너무나 희귀하다는 점에서 당신은 맞습니다. –

그런 다음 문제를 찾고있는 것처럼 들립니다. 이와 같은 것이 유용 할 때의 예를 제시하지 않았습니다. –

이 모든 결정을 효율적으로하려면 1/0, 예/아니오, 참/거짓 등

로 내려 와야한다, 언어 구조는이를 반영해야합니다.

출처

2009-08-25 17:13:21

100111? 1 1011 11011 10. – harpo

왜 이것이 downvoted인지 전혀 몰랐습니다. –

결국 모든 코드는 한 번에 하나의 명령으로 실행되는 마이크로 코드로 이동합니다. 마이크로 코드와 함께 CPU가 더 다채로운 것을 기술 할 때까지, 우리는 아주 평범한 언어로 붙어 있습니다.

출처

2009-08-25 17:14:55 Robert

그러나 컴파일러는 항상 복잡하고 높은 수준의 명령문을 가져 와서 프로세서에 적합한 형식으로 컴파일 할 수 있습니다. 결국 그 작업의 일부입니다. CPU는 객체, 클래스 등과 같은 것을 "이해"하지 않지만, 컴파일러는 이러한 고수준의 구조를 프로세서가 이해하는보다 단순하고 낮은 수준의 명령어로 변환 할 수 있습니다. – mipadi

-1은 틀린 것을 대답하고, +1은 mipadi를 말하면서 – naiad

대부분의 프로그래밍 언어는 사용자가 도구를 구현할 수있는 충분한 도구를 제공하지 않으므로 구현자가 확장 기능으로 제공 할 수있는 중요한 기능으로 보이지 않으며 충분히 필요하지도 않고 사용하기에 충분하지 않습니다. 표준에 추가되었습니다.

정말로 원하는 경우이를 제공하는 언어를 사용하거나 구현 도구 (예 : lisp 매크로)를 제공하십시오.

출처

2009-08-25 17:15:08 Brian

마치 rules engine 인 것처럼 보입니다.

출처

2009-08-25 17:18:43 teabot

그래, 나는 그렇게 생각한다. 링크를 가져 주셔서 감사합니다. –

우리가 사용하는 기본 제어 알고리즘은 어떤 프로세서가 효율적으로 수행 할 수 있는지를 반영합니다. 기본적으로 이것은 간단한 테스트 및 분기로 귀결됩니다.

많은 사람들이 수백 ~ 수천 (또는 수백만)의 프로세서 사이클을 완료해야하는 단순한 코드 줄을 작성하는 것을 좋아하지 않습니다. 이러한 사람들 중에는 운영 체제 및 컴파일러와 같은 것을 작성하는 시스템 소프트웨어 담당자가 있습니다. 당연히 대부분의 컴파일러는 자신의 작가의 우려를 반영하려고합니다.

출처

2009-08-25 17:50:21

이것은 원 자성에 관한 관심과 관련이있다. 더 단순한 구조 Y, Z에서 A, B, C, D를 표현할 수 있다면 단순히 A, B, C, D를 제공하지 않고 대신 Y, Z를 제공하는 것이 어떻습니까?

기존 언어는 원 자성과 사용성 사이의 긴장감을 60 년간 반영합니다. 현대적인 접근 방식은 "작은 언어, 큰 도서관"입니다. (C#, Java, C++ 등).

출처

2009-08-25 19:45:08

사실. 그래도 '고토' – naiad

왜 대부분의 프로그래밍 언어에는 더 많은 제어 구조가 없습니까?

답변

관련 문제