“Syntax”와“Syntactic Sugar”의 차이점은 무엇입니까

배경

Syntactic Sugar 의 Wikipedia 페이지는 다음과 같습니다.

컴퓨터 과학에서, 구문 설탕은 물건을보다 쉽게 ​​읽거나 표현할 수 있도록 설계된 프로그래밍 언어 내의 구문입니다. 그것은 사람들이 사용하기에 언어를 "더 달콤하게"만들어줍니다. 사물은 더 명확하고 간결하게 표현되거나 다른 스타일로 선호 될 수 있습니다.

Syntactic Sugar와 Syntaxactic의 차이점이 무엇인지 이해하지 못합니다.

설탕 버전이 더 명확하고 간결하며 보일러 플레이트를 끓일 수 있다는 점에 감사합니다. 그러나 어떤 수준에서는 모든 구문이 본질적으로 코드가 컴파일되는 것에 대한 추상화를 형성하기 위해 수행됩니다.

동일한 Wikipedia 페이지에서 :

컴파일러, 정적 분석기 등을 포함한 언어 프로세서는 종종 "설탕 제거 (desugaring)"라고하는 프로세스 인 설탕 처리 된 구조를 처리하기 전에보다 기본적인 구조로 확장합니다.

생각 연습으로,이 문장에서 "항상"을 의미하기 위해 "종종"을 사용하는 경우 : 다음 단계로 넘어 가기 전에 컴파일러가 구문을 "설탕 제거"하는지 여부가 차이라면, 내부자를 모르는 코더는 어떻게 할 수 있을까요? 컴파일러 중 Sugar'd Syntax가 무엇인지 아는가?

이 사이트에 관한 매우 많은 관련 질문 "구문 설탕의 엄격한 정의?" 시작 하는 대답 이 있습니다.

IMHO 나는 구문 설탕에 대한 정의를 가질 수 없다고 생각합니다. 왜냐하면이 문구는 BS이고 "실제 운영 체제"에서 "실제 도구"를 사용하여 "실제 프로그래머"에 대해 이야기하는 사람들이 사용할 수 있기 때문입니다.

언어를 사용하는 코더에는 큰 차이가 없을 수도 있습니다. 아마도 차이점은 컴파일러 작성자에게만 허용됩니까? 언어를 사용하는 코더가 Syntactic Sugar의 후드 아래에 무엇이 있는지 아는 것이 도움이되는 사례가있을 수 있습니까? (그러나 실제로는 주제에 관한 어떤 담론이이 용어를 불꽃 미끼로 사용하는 경향이 있습니까?)

질문의 핵심

그래서 ... 질문의 짧은 버전 :

• Syntaxactic Syntax와 Syntactic Sugar 사이에 실제 차이점이 있습니까?
• 누구에게 중요한가?

생각을위한 여분의 음식

주제 모순에 대한 보너스 :

Wikipedia 페이지에서 예제가 제공됩니다.

예를 들어, C 언어에서 a[i]표기법은*(a + i)

위의 링크 된 질문에 대한 또 다른 대답 은 동일한 예에 대해 이야기합니다.

이제 고려하십시오 a[i] == *(a + i). 실질적인 방식으로 배열을 사용하는 C 프로그램을 생각해보십시오.

그리고 그 요약 :

이 []표기법은 이러한 추상화를 용이하게합니다. 구문 설탕이 아닙니다.

동일한 예에 대한 반대 결론!

주요 차이점은 구문은 언어로 정의 된 문법으로 일부 기능을 노출 할 수 있다는 것입니다. 해당 기능을 사용할 수있게되면 바로 동일한 작업을 수행 할 수 있는 다른 구문이 설탕으로 간주됩니다. 물론 두 구문 중 어느 것이 설탕인지에 대한 이상한 시나리오가 발생합니다. 특히 어느 것이 먼저 나왔는지는 항상 명확하지 않기 때문입니다.

실제로, syntactic sugar는 infix lhs + rhsmap to 와 같이 사용하기 쉽도록 언어에 추가 된 구문을 설명하는 데만 사용 됩니다 lhs.Add(rhs). C의 배열 인덱싱은 구문 설탕이라고 생각합니다.

우아한 디자인은 복제 량을 제한하는 경향이 있기 때문에 중요합니다. 구문 설탕의 필요 (또는 적어도 원하는)는 디자인 실패의 표시로 볼 수 있습니다.

구문은 언어 프로세서가 언어 구성의 의미를 이해하기 위해 사용하는 것입니다. 구문 설탕으로 간주되는 구문도 언어 프로세서에서 해석해야하므로 언어 ​​구문의 일부입니다.

구문 설탕을 언어의 나머지 구문과 구별하는 것은 언어로 작성 될 수있는 프로그램에 영향을 미치지 않고 언어에서 구문 설탕을 제거 할 수 있다는 것입니다.

좀 더 형식적인 정의를주기 위해

구문 설탕은 언어의 다른 구문 구조와 관련하여 효과가 정의되는 언어 구문의 일부입니다.

구문 설탕의 사용은 종종 의도가 더 이해하기 쉬운 프로그램으로 이어지기 때문에 구문 설탕이나 그 언어를 거부하는 것은 아닙니다.

다른 답변은 핵심 개념을 언급하지 않았습니다 : 추상 구문 ; 그것 없이는 "구문 설탕"이라는 용어는 의미가 없습니다.

추상 구문은 언어의 요소와 구조 및 해당 언어의 문구를 결합하여 더 큰 문구를 만드는 방법을 정의합니다. 추상 구문은 구체적인 구문과 무관합니다. 내가 이해하는 "구문 설탕"이라는 용어는 구체적인 구문을 나타냅니다.

일반적으로 언어를 디자인 할 때 사람들이 일반 텍스트를 사용하여 언어로 코드를 작성할 수 있도록 추상 구문의 각 용어에 대해 구체적인 구문을 작성하려고합니다.

이제 foo에 대한 어색한 구체적인 구문을 작성한다고 가정 해 봅시다 . 사용자는 불만을 제기 하고 동일한 추상 구문 을 나타내는 새로운 구체적 구문을 구현 합니다 . 결과적으로 추상 구문과 의미가 변경되지 않았지만 동일한 추상 구문 용어에 대해 두 가지 구체적인 구문이 생겼습니다.

저는 이것이 사람들이 "구문 설탕"이라고 말할 때 의미하는 것입니다. 구체적인 구문에만 영향을 미치지 만 추상적 인 구문이나 의미에는 영향을 미치지 않는 변화입니다.

"syntactic sugar"와 "concrete syntax"의 차이점이 분명해졌습니다. 나에게. :)

이 해석은 또한 Alan Perlis가 "구문 설탕이 세미콜론의 암을 유발한다"고 말할 때 의미 한 바를 설명하는 데 도움이됩니다. 세계의 모든 구체적인 구문 설탕은 약한 추상 구문을 고칠 수 없으며 설탕을 첨가하는 데 드는 모든 노력은 실제 문제, 추상 구문을 다루는 데 소비하지 않는 노력.

나는 이것이 전적으로 나의 의견임을 주목해야한다. 내가 생각할 수있는 유일한 해석이기 때문에 나는 그것을 믿습니다.

구문 설탕은 언어 구문의 하위 집합입니다. 기본적인 아이디어는 같은 것을 말하는 방법이 여러 가지라는 것입니다.

어떤 조각이 구문 설탕인지, 어떤 조각이 "순수한 구문"인지 말하기 어렵게 만드는 것은 "어떤 형식이 처음인지 말하기 어렵습니다"또는 "언어 작성자가 의도 한 방식을 알기가 어렵다"또는 " 어떤 형태가 더 간단한지를 결정하기 위해 다소 임의적이다. "

어떤 조각이 순수하거나 설탕인지를 쉽게 결정하는 것은 특정 컴파일러 또는 인터프리터의 프레임 내에서 질문하는 것입니다. 순수한 구문은 컴파일러가 기계 코드로 직접 변환하거나 인터프리터가 직접 응답하는 것입니다. 설탕은 이러한 직접적인 일이 일어나기 전에 먼저 다른 구문으로 바뀌는 것들입니다. 구현에 따라, 이것은 저자가 의도 한 것과 언어 사양이 주장하는 것과 동일하거나 동일하지 않을 수 있습니다.

실제로, 이것은 문제의 현실이 결정되는 방식입니다.

실제로, Wikipedia의 첫 인용문은 "... 더 읽기 쉽게 ...", ".... 사람들이 사용하기에 더 달콤하다 ..."라고 말합니다.

서면으로, "하지 말라"또는 "하지 않은"과 같은 단축 된 형태는 구문 설탕으로 간주 될 수 있습니다.

일반적으로 구문 설탕은 일반성을 잃지 않고 명확성을 잃을 수있는 언어의 일부 (구문)로 표현할 수있는 언어의 일부입니다. 때때로 컴파일러는 소스 코드에 의해 생성 된 AST를 변환하고 간단한 단계를 적용하여 설탕에 해당하는 노드를 제거하는 명백한 탈당 단계가 있습니다.

예를 들어 Haskell에는 다음 규칙을 반복적으로 적용한 모나드 용 구문 설탕이 있습니다.

do { f }            ~> f
do { g; h }         ~> g >> do h
do { x <- f; h }    ~> f >>= \x -> do h
do { let x = f; h } ~> let x = f in do h

현재 정확히 의미하는 바는 중요하지 않습니다. 그러나 LHS의 특수 구문이 RHS (즉, 함수 응용 프로그램, 람다 및 등)에서보다 기본적인 것으로 변환 될 수 있음을 알 수 있습니다 let. 이 단계를 통해 두 세계를 최대한 활용할 수 있습니다.

1. LHS에 대한 구문은 기존 아이디어를보다 명확한 방식으로 표현하는 프로그래머 (구문 설탕)에게 더 쉽습니다.
2. 그러나 RHS 구문에 대한 컴파일러의 지원은 이미 컴파일러에 존재하므로이를 외부 외부 파서 및 역설 화 (오류보고 제외)로 처리 할 필요가 없습니다.

마찬가지로 C에서 desugaring rewrite 규칙을 상상할 수 있습니다 (연산자 과부하 등으로 인해 C ++에는 해당되지 않습니다).

f->h ~> (*f).h
f[h] ~> *(f + h)

오늘날이 구성을 사용하는 C를 사용 ->하거나 사용하지 않고 모든 프로그램을 작성하는 것을 상상할 수 []있습니다. 그러나 프로그래머가 구문 설탕을 사용하는 것이 더 어려울 것입니다 (70 년대에는 컴파일러의 작업을 단순화 할 수도 있습니다). 기술적으로 다음과 같이 완벽하게 유효한 다시 쓰기 규칙을 기술적으로 추가 할 수 있으므로 명확하지 않을 수 있습니다.

*f ~> f[0] -- * and [] have the same expressiveness 

구문 설탕은 나쁜가요? 반드시 그런 것은 아닙니다. 더 깊은 의미를 이해하지 않고화물 컬트로 사용될 위험이 있습니다. 예를 들어 다음 함수는 Haskell에서 동일하지만 많은 초보자는 구문 설탕을 과도하게 사용하고 있음을 이해하지 않고 첫 번째 양식을 작성합니다.

f1 = do x <- doSomething
        return x
f2 = doSomething

또한 구문 설탕은 언어를 지나치게 복잡하게 만들거나 너무 좁아서 일반화 된 관용어 코드를 허용 할 수 없습니다. 또한 언어가 특정 작업을 쉽게 수행 할 수있을만큼 강력하지 않다는 것을 의미 할 수 있습니다. 설계 상 (개발자에게 더 강력한 구문을 추가하여 다른 목표를 해칠 수있는 날카로운 도구 나 매우 구체적인 틈새 언어를 제공하지 않음) 또는 후자의 경우 일 수 있습니다. 형태는 구문 설탕에 나쁜 이름을 주었다. 언어가 구문 설탕을 추가하지 않고 다른 구문을 사용할 수있을만큼 강력하면이를 사용하는 것이 더 우아하다고 간주됩니다.

가장 확실한 예는 C의 "+ ="구문 일 것입니다.

i = i + 1;

과

 i +=  1;

정확히 동일한 작업을 수행하고 정확히 동일한 머신 명령어 세트로 컴파일하십시오. 두 번째 형식은 입력하는 두 문자를 저장하지만, 현재 값을 기준으로 값을 수정하고 있음을 더욱 명확하게합니다.

"++"post / prefix 연산자를 표준 예제로 인용하려고했지만 이것이 구문 설탕 이상이라는 것을 깨달았습니다. i = i + 1구문을 사용하여 ++ i와 i ++의 차이를 단일 표현식으로 표현할 방법이 없습니다 .

먼저 구체적인 예를 들어 다른 답변을 다룰 것입니다. C ++ 11 범위 기반 for 루프 (다양한 다른 언어의 foreach 루프와 매우 유사)

for (auto value : container) {
    do_something_with(value);
}

(즉, 설탕 버전)과 정확히 동일합니다.

for (auto iterator = begin(container); iterator != end(container); ++iterator) {
    do_something_with(*iterator);
}

이제 언어에 새로운 추상 구문이나 의미를 추가하지 않아도 실제로는 유용합니다.

첫 번째 버전은 의도 (컨테이너의 모든 항목 방문)를 명시 적으로 만듭니다. 또한 순회 중 컨테이너를 수정하거나 iterator루프 본체에서 추가로 전진 하거나 루프 조건이 미묘하게 잘못 되는 등의 비정상적인 동작을 금지 합니다. 이렇게하면 가능한 버그 원인을 피할 수 있으며 코드를 읽고 추론하기가 어렵습니다.

예를 들어 두 번째 버전에서 한 문자의 실수는 다음과 같습니다.

for (auto iterator = begin(container); iterator <= end(container); ++iterator) {
    do_something_with(*iterator);
}

과거의 일회성 오류와 정의되지 않은 동작을 제공합니다.

따라서 sugared 버전은 더 제한적이기 때문에 정확하게 이해하고 이해하기가 더 간단합니다.

둘째, 원래 질문 :

Syntaxactic Syntax와 Syntactic Sugar 사이에 실제 차이점이 있습니까?

아닙니다. "구문 설탕"은 (구체적인) 언어 구문이며, 언어의 추상 구문이나 핵심 기능을 확장하지 않기 때문에 "설탕"으로 간주됩니다. 나는 이것에 대한 Matt Fenwick의 답변을 좋아합니다.

누구에게 중요한가?

그것은 다른 구문만큼이나 언어 사용자에게 중요하며 설탕에서 특정 관용구를 지원하기 위해 제공됩니다 (어떤 의미에서는 축복).

마지막으로 보너스 질문에

[] 표기법은 이러한 추상화를 용이하게합니다.

이것은 구문 설탕 의 정의 와 비슷하게 들립니다 . 포인터를 배열로 사용하여 지원하고 언어 작성자의 축복을 제공합니다. p[i]형태는 정말보다 더 제한없는 *(p+i)유일한 차이는 의도의 명확한 의사 소통 (그리고 약간의 가독성 이득) 그래서.

어구의 원래 의미가 무엇이든, 요즘은 주로 "유의 한"또는 "유일한"구문 설탕으로 표현되는 주로 중대하다. 읽을 수없는 방식으로 일을하고 동료에게이를 정당화 할 수있는 간결한 방법을 원하는 프로그래머에게는 매우 중요합니다. 오늘날이 용어를 주로 사용하는 사람들의 정의는 다음과 같습니다.

언어를 실제로 이해하지 못하는 프로그래머에게 버팀목을 제공하기 위해 더 널리 적용되는 다른 구문과 중복되는 구문입니다.

이것이 동일한 구문 요소에 대해 두 가지 반대 결론을 얻는 이유입니다. 배열 표기법에 대한 첫 번째 예는 Bart의 대답과 비슷한 용어의 원래 긍정적 인 의미를 사용하는 것입니다. 두 번째 예는 중추적 의미에서 구문 설탕이라는 비난에 대해 배열 표기법을 방어하는 것입니다. 다시 말해, 구문은 목발보다는 유용한 추상화라고 주장한다.