본문 바로가기

23년 1학기 학교공부/프로그래밍언어개론

[PL] Syntactic sugar와 Identifiers

목차

    728x90
    반응형
    SMALL

    📁 언어의 확장

    언어의 확장은 다음과 같은 단계를 수반한다.

     

    Interpreted language는 다음 단계를 추가로 수반한다.

     

    Compiled language는 다음 단계를 추가로 수반한다.

     

     

    최적화 등의 기능이 더 있으므로 Interpreted language보다 Compiled language가 더 많은 확장 단계를 수반한다.

     

     

     

    🔎 concrete syntax와 abstract syntax확장이 끼치는 영향

    Lexical Analysis에서 쓰이는 것이 Lexer이고, Syntax Analysis에서 쓰이는 것이 Parser이다.

     

    Concrete syntax는 개발자가 작성하는 구문이므로 이것에 변화가 있다는 것은 1번 프로그램 안의 코드 형태에서 변화가 있다는 뜻이다.

     

     

    1번 프로그램 코드에 변화가 있을 때 영향받는것은 2번 AST 직전까지이다.

    Concrete syntax를 토큰화하기 위해서는 Lexer에서 새로운 정의가 필요하다.

    예를 들어 rec 이라는 키워드를 새로 정의한다면 해당 키워드를 어떤 토큰으로 바꾸어야하는지 지정해야한다.

     

    또한 새로 정의되거나 수정된 토큰을 어떻게 AST로 parsing할지 정의해야한다.

    때문에 Concrete Syntax 확장 시에는 2번 AST 직전까지인 Parser의 확장도 필요하다.

     

     

    만약 2번 AST(프로그램을 나타내는 중간언어, 즉 이도 프로그램이다.)에 변화가 있을 때에는, Front-end부분 뿐만 아니라 Back-end 부분까지 영향을 끼친다.

    1번 프로그램 코드를 변화한 AST까지 parsing시키기 위해 AST 전의 Front-end 부분에도 영향을 끼치고, 변화한 AST를 컴파일 혹은 인터프리트 해야하기 때문이다.

     

     

    이를 참고하여 concrete syntax와 abstract syntax 확장 시 수반되는 확장을 정리하면 다음과 같다.

     

    위 정리를 통해 abstract syntax가 확장될때 concrete syntax가 확장될 때 보다 영향받고 수반되어야 하는 확장의 종류가 훨씬 많음을 알 수 있다.

     

    그러므로 언어를 확장시에 concrete syntax를 확장하는 방법이 효율적이고, 이 원리를 이용한 방식이 Syntactic sugar이다.

     

     

     

     

    📁 Syntactic sugar

    📌 Syntactic sugar(문법적 설탕)은 사용자의 편의를 위해 제공되는 구문이다.

    기존의 언어로 구성요소로 표현이 가능하나, 더 쉽고 편하게 사용할 수 있도록 구문을 설계하고 싶을때 사용한다.

    concrete syntax의 확장을 통해 제공한다.

     

    기존 언어의 구성요소로의 변환을 통해 실행하므로 Abstract syntax의 확장이 불필요하다.

    즉 Semantics 및 기타 back-end의 확장없이 제공한다.

     

    Parser의 확장도 수반되어, Parser를 통해서 syntactic sugar를 기존의 구문으로 변환한다.

     

     

     

     

    📁 NAE : Extension of AE

    해당 포스팅에서는 AE에 부호 전환 연산(Negation)을 추가하여 확장한 NAE(Negation and AE)를 정의한다.

     

    NAE 언어는 다음과 같이 정의된다.

     

     

     

     

    📁 Concrete syntax in NAE

    NAE는 하나의 표현식으로 이루어진 프로그램이다.

    가장 상단의 expr은 이를 의미한다.

     

    # ~ (expr)는 부호 전환 연산을 정의하는 concrete syntax이다.

    즉, 모든 괄호로 묶인 expr 앞에 부호 전환 기호인 ~가 붙을 수 있게 되었다.

     

     

    NAE 확장시에 Syntactic sugar의 사용여부에 상관 없이 Concrete syntax의 위와 같은 경우는 꼭 필요하다.

     

     

     

     

    📁 Abstract syntax

    syntactic sugar 없이 확장하게 되면 abstract syntax를 위와 같이 정의할 수 있다.

     

     

    ~e

    부호 전환 연산을 의미하는 abstract syntax이다.

     

    ~e는 아래 트리를 나타내는 축약코드이다.

     

     

     

    하지만 NAE 언어 확장을 syntactic sugar로 확장하고자 하면, abstract syntax를 위와 같이 정의할 수 있다.

     

     

    이는 기존 AE 언어의 abstract syntax와 변화가 없다.

     

    주로 syntactic sugar는 concrete syntax 확장을 통해 제공하므로, abstract syntax의 확장이 불필요한것이다.

    대신 parser를 확장하여, 아래에서 설명하는것과 같이 parser를 통해 기존의 구문으로 변환하도록 한다.

     

     

     

     

    📁 Parser

    Syntactic sugar를 사용하지 않은 NAE의 경우, 이와 같이 parser가 수정된다.

     

    위에서 abstract syntax를 수정하여 Neg라는 새 키워드가 생성되었으니,

    parser에서 해당 키워드로 concrete syntax를 파싱해야하므로 이와 같이 수정되어야한다.

     

     

     

    Parser는 Desugaring을 통해 Syntactic sugar를 기존 언어의 구성요소로 변환한다.

     

    이 예시에서는 부호 전환을 의미하는 물결 연산자가 syntactic sugar로 정의되었으며,

    Parser는 물결(~) 연산을 abstract syntax의 Sub 구문으로 변환한다.

    ~ (e) => 0 - e

     

    즉 concrete syntax인 ~ (e)를 abstract syntax인 0 - e로 변환한다.

    이렇게 나타내는 abstract syntax를 AST로 나타내면 오른쪽 그림과 같다.

     

     

     

     

    📁 Semantics in NAE

     

    Syntactic sugar를 사용하지 않은 NAE의 경우, 이처럼 abstract syntax에 대한 formal semantics를 정의해야한다.

     

     

     

    728x90
    반응형
    LIST