답변:
어떻습니까? "구문 설탕은 의미있는 추상화 계층을 도입하지 않는 일부 기능을 편리하게 줄여줍니다."
a->b당신이 지적한 대로을 가져 가십시오 (*a).b. 이 표기법을 사용하면 유용하고 숨겨진 방식으로 코드를 고려할 수 있습니까? 아니요, 그것은 구문 설탕입니다.
이제 고려하십시오 a[i] == *(a + i). 실질적인 방식으로 배열을 사용하는 C 프로그램을 생각해보십시오. []표기법 없이 이해하려고 노력할 수 있습니까 ? 다차원 배열? 연속적인 메모리 블록의 시작에 대한 참조가 아니라 배열을 전체 단위로 간주하는 것이 의미가 있습니다. 복잡한 배열을 수행하려는 경우 C에서 배열이 작동하는 방식을 이해하는 데 도움이되지만 항상 "두 비트의 메모리 2 * i 바이트를 오른쪽에 저장해야합니다"라고 생각하는 것은 비생산적입니다 a"로 참조되는 메모리 위치 ." 배열의 요점은 시퀀스를 코 히어 런트 유닛으로 저장하는 프로세스를 추상화하는 능력입니다. 이 []표기법은 이러한 추상화를 용이하게합니다. 구문 설탕 이 아닙니다 .
이것은 구문 설탕이 항상 나쁜 것을 의미하지는 않습니다. 많은 동맹과 마찬가지로, 그것은 하나의 유행이되어 "실제 특징"에 맞서게되었습니다. 그러나 예를 들어 LISP와 Scheme은 let속기 (및 다른 것) 가 아니라면 읽을 수 없습니다 .
삼항 연산자 인 <pred> ? <cnsq> : <alt>또 다른 예입니다. 구문 설탕은 프로그램을 구성하고 중복 코드를 제거하여 유지 관리 비용을 절감 할 수 있습니다. 프로그래밍에 대한 구문 적 장벽을 제거하는 데 도움이되는 경우, "실제 기능"을 말리는 것보다 때때로 구문 설탕이 바람직 할 수 있습니다.
R ^ 5RS 를 인용하려면 "프로그래밍 언어는 기능 위에 기능을 정리 하는 것이 아니라 추가 기능이 필요한 것으로 보이는 약점과 제한 사항을 제거하여 설계해야합니다." IMHO, 구문은 약점과 제한으로 간주 될 수 있으므로 프로그래머가 구문에서 벗어날 수있게 하면 언어 표현력이 향상 될 수 있습니다 .
IMHO 나는 구문 설탕에 대한 정의를 가질 수 없다고 생각합니다. 왜냐하면이 문구는 BS이고 "실제 운영 체제"에서 "실제 도구"를 사용하여 "실제 프로그래머"에 대해 이야기하는 사람들이 사용할 수 있기 때문입니다.
BS의 "실제 특징"또는 "구문 설탕"이라는 개념은 진정한 스코틀랜드 인의 실수와 같지 않기 때문 입니다. 그 구절은 "합리적이지 않은 주장을 유지하려는 임시 시도"입니다. 여기서는 "실제 기능"을 대신 사용할 수 있기 때문에 여기서 기능이 간단하다는 주장입니다.
BS는 설탕을 사용하는 것을 피해야 한다고 주장하기 때문에 BS 는 버그 를 작성할 수 있기 때문에 버그를 작성하기는 어렵지만 버그를 작성하기가 어려워 야합니다. 굉장하지 않습니까? 동일한 문구를 사용하면 동일한 논리를 사용하는 것과 정확히 반대되는 결론이 도출됩니다.
BS는 가독성이나 유지 보수성 또는 결함 주장을 백업하기 위해 사용성 연구 또는 결함 수 연구를 인용하지 않았기 때문에 BS입니다.
사람들이 종종 등가에 대해 잘못하거나 잘못되기 때문에 BS. 예를 들어이 질문 은 C # 문자열이 char 배열의 sugar라고 주장합니다. 그들은 아닙니다 .
그러나 의미 적으로 동등한 두 가지 경우 설탕이라고 말하고 싶다면 어쨌든 원하는대로 정의하고 정의하는 데 도움이됩니다.
누군가를 무시하고 싶다면 문구를 사용할 수도 있습니다.
여기입니다 매우 : 관련 개념에 대한 엄격한 정의 표현 에 의해
마티아스 펠리 센은 :
프로그래밍 언어의 표현력에 대하여 [Postscript는 내가 찾은 유일한 자유 형식이었습니다.]
또한 Java 언어 및 클로저 에 대한 이 항목을 참조하십시오 .
효과적으로, 로컬 변경만으로 구문없이 형태로 변경 될 수 있다면 무언가는 구문 설탕입니다. 예를 들어 구문 형식이없는 경우 여러 다른 코드 위치를 변경하거나 조각을 다른 위치로 이동해야하는 경우에는 설탕이 아닙니다.
즉, 적절하게 사용하면 구문 설탕이 좋다. Scheme 프로그래머라면 let새로운 익명 함수를 만든 다음 적용하는 것보다 특별한 형식이 있다고 생각합니다 . 목적은 코드를 명확하게하는 것입니다.
구문 설탕 이라는 용어 는 동일한 기본 의미를 표현하는 대체 구문을 나타냅니다.
sum임의의 길이의 정수 목록을 더할 수 있는 연산이있는 프로그래밍 언어 A를 예로 들어 보겠습니다 . 이 언어로 우리는 표현을 쓸 수 있습니다
sum []
sum [3, 4, 5, 1]
sum [2, 7]
결과는 각각 0, 13 및 9입니다.
이제 우리가 사용하는 시간의 90 % sum가 두 개의 주장으로 사용된다는 것을 인식하고 편의상 새로운 표기법을 도입 한다고 가정 해 봅시다.
2 + 7
그것은 단지 구문 설탕 입니다 sum [2, 7].
이제 추가 연산 이 없는 제 2 언어 B를 가져 가십시오 . 우리는 운영자가 좋아가 없을 수 있습니다 <, =우리가 숫자를 비교할 수 있지만, 할 수있는 방법 추가 번호를. 언어 B의 릴리스 2에서는 구문을 사용 하여 새로운 추가 작업을 소개 합니다.
2 + 7
평소와 같이 숫자를 추가합니다.
언어 A와 관련하여, +표기법은 구문 설탕입니다 (표기법 대신 사용할 수있는 대체적이고 간결하며 임시 sum [...]표기법 임). 마찬가지로 Hoa Long Tam의 답변에서 지적했듯이 C에서 표기법 p->field은의 구문 설탕입니다 (*p).field.
언어 B의 맥락에서, +표기법은 구문 설탕 이 아닙니다 (이는 합 연산에 사용되는 유일한 유효한 구문입니다). 마찬가지로 C가 포인터를 통해서만 구조체 멤버에 액세스 할 수 (*p).field있고 표기법 p->field이없는 경우 표기법 은 구문 설탕이 아닙니다.
제 생각에는 프로그래밍 언어 의미론에 대한 혼란으로 되돌아 갈 수있는 구문 설탕에 대한 오해가 있습니다. 추론은 다음과 같습니다.
위의 추론은 "구문 설탕을 제대로 정의 할 수 없다", "맛의 문제", 또는 "모든 프로그래밍 언어 기능이 결국 구문 설탕"과 같은 일반적인 주장으로 이어진다.
위의 주장에서 주요 문제는 시맨틱이 프로그램에 의해 계산 될 수있는 것 뿐만 아니라 프로그램 이 계산 되는 방법 , 즉 사용되는 기본 구성과 결합 방법에 관한 것입니다.
예를 들어 객체 는 기본 비트 구성 및 비트 변환에 대한 구문 설탕이 아니며 데이터와 연산을 모델링하고 계산을 설명 할 수있는 구문입니다. 객체, 메소드, 메소드 호출을 사용한 컴퓨팅은 바이트, 프로세서 레지스터, 메모리 주소를 사용한 컴퓨팅과 동일하지 않습니다 (두 계산의 결과가 같더라도 두 번째 계산이 첫 번째 계산을 수행하는 경우에도 마찬가지 임).
나는이 설명을 약간 길게 만들었지 만 다른 답변에서 다루지 않은 것은 중요한 측면이라고 생각합니다.
결론 : 구문 설탕은 이미 언어로되어 있고 구문과 의미가 이미 정의 된 구문의 대체 구문 일 수 있습니다. 새로운 구문 (구문 설탕)은 기존 구문과 다르지만 의미 는 같습니다 . 언어로 된 새로운 구문과 구문을 도입하면 구문 설탕이 없습니다.
내 자신의 질문에 대답하기 위해, 기능은 오직 그 경우는 미학과 가독성을 향상시키기 위해 주로 포함 된 경우 문법 설탕입니다 및 하찮게 드 - 설탕 버전으로 대략 일대일 방식으로 번역 될 수있다. (대략 일대일로 나는 계산 연산 순서, 변수 이름 및 공백 순서와 같은 사소한 것을 의미합니다.)
상당한 양의 프로그래머 징계로만 설탕을 제거 할 수있는 기능은 구문 설탕이 아닙니다. 이것의 부분 집합으로서, 프로그래머의 훈련을 통해 타입 안전을 수동으로 시행하는 것은 매우 중요하지 않기 때문에 타입 안전성을 향상시키는 기능은 구문 설탕이 아닙니다. 예를 들어, C ++의 객체 시스템은 C 포인터 캐스트 다형성의 상단에있는 구문 설탕 이상입니다.
중요한 코드 복제 또는 제거 된 경우 주요 재 설계가 필요한 기능은 구문 설탕이 아닙니다. 이는 간단한 작업이 아니기 때문입니다. 예를 들어, 템플릿 없이는 동등한 기능을 사용하려면 수많은 복제 및 수정이 필요하기 때문에 템플릿은 단순한 구문 설탕이 아닙니다.
일 예 이다 문법 설탕 :
a[i] 대신에 *(a + i)
a -> b 대신에 (*a).b
foreach 반복자 구문을 수동으로 입력하는 대신 구문.
모든 연산자 과부하는 순수한 구문 설탕입니다.
이것이 공정하고 합리적으로 명확한 정의처럼 들립니까?
"구문 설탕"은 엄격하게 정의 된 용어가 아닙니다. 요청한 사람에 따라 다음과 같은 종류의 정의 중 하나를 얻을 수 있습니다.
나는 컴퓨터 과학 분야에서에 대해 잘 모르겠지만, 논리의 필드가 보수성과 정의 [의 제거 가능성의 개념이다 1 ] 같은 맥락에있는 것으로 보인다.
Curry-Howard 서신을 적용하면“syntactic sugar”에 대한 병렬 개념이 나올 수 있습니다.