IDL 워크벤치에서 구문별 색표시(Syntax Coloring)에 대한 이해

IDL의 개발환경(Development Environment)이라 할 수 있는 워크벤치(Workbench) 인터페이스라는 것이 있는데, 말은 거창해 보이지만 그냥 우리가 IDL로 작업하실 때 항상 보게 되는 그 인터페이스를 의미합니다. 여기서 에디터나 콘솔창에서 각종 문구들을 입력하다보면 푸른색, 초록색, 붉은색 등 여러가지 색상들로 나타나는 것을 볼 수 있습니다. 사실 이 색상들은 각각 숨어있는 의미가 있는데요. 프로그램의 실행에 있어서 직접적인 영향을 끼치지는 않지만, 프로그램 문구들에 대한 이해에 있어서는 도움이 될 만한 흥미로운 의미들이 담겨 있기도 합니다. 오늘은 이 얘기를 해볼까 합니다.

이렇게 문구의 종류별로 색상을 부여하는 것을 Syntax Coloring이라고 합니다. 물론 이러한 체계는 워크벤치 인터페이스에서만 존재하는 일종의 편의성 기능이라고 보면 됩니다. 터미널상의 텍스트 기반의 IDL에서는 이러한 색상 부여 방식은 존재하지 않습니다. 실제로 이러한 색상들은 구문의 종류별로 다릅니다. 색상 부여의 규칙은 사실 고정적인 것은 아니고 사용자가 얼마든지 제어할 수 있습니다. IDL의 환경설정에서 IDL 항목의 하위에 있는 "구문별 색표시"라는 섹션에서 이러한 설정이 가능합니다. 그 모습은 다음 그림과 같습니다.

이 그림에서 볼 수 있듯이, 구성요소에 따른 색상 배정 규칙이 엄연히 존재하고 있습니다. 구성요소에 있는 각 항목을 클릭해보면 그 항목에 대하여 어떤 색상이 연결되어 있는지 확인할 수 있으며, 필요에 따라서는 사용자가 이 색상을 바꾸는 것 까지도 가능합니다. 우리가 일상적으로 많이 사용하게 되는 항목들은 아무래도 주석, 문자열, 예약어, 숫자, 시스템 프로시저, 시스템 함수, 사용자 프로시저, 사용자 함수 등이 될 것입니다. 예를 들어 하나의 IDL 프로그램을 작성해보면 에디터 상에서 다음과 같은 전형적인 모습을 보여 줍니다.

물론 이러한 모습이야 항상 보아왔던 것이지만 각각의 색상이 어떤 의미인지를 확인해보는 것도 흥미로울 것 같습니다. 먼저 주석, 문자열은 쉽게 알아볼 수 있을 것입니다. 예약어라는 것은 주로 프로그램 구문들(Statements), 즉 PRO, END, IF, THEN, BEGIN, FOR 등과 같은 문구들에 해당되는데 위와 같이 진홍색에 가까운 색상을 띄게 됩니다.

그 다음에 나오는 항목들은 프로시저와 함수로되어 있는데 각각 시스템 또는 사용자라는 구분이 되어 있습니다. 여기서 "시스템"이란 의미는 IDL 내부에 심어져 있는 소위 말하는 임베드(Embed)되어 있다는 의미입니다. 단순하게 얘기한다면 여기에 해당되는 프로시저나 함수의 경우 그 소스코드를 유저가 볼 방법이 전혀 없습니다. 예를 들어 위의 프로그램에서 HELP, PRINT, FINDGEN, SIN, N_ELEMENTS 등의 프로시저 또는 함수들에 대한 소스코드를 유저가 볼 방법이 전혀 없다는 의미입니다. 이걸 볼 수 있는 사람은 IDL의 개발자들 뿐입니다. 실제로 IDL 자체가 제가 알기로는 C++로 만들어져 있는데, 위와 같은 프로시저나 함수들은 이러한 형태로 IDL 내부에 심어져 있는 상태이기 때문입니다. 여기서 프로시저는 진한 파란색, 함수는 밝은 파란색이란 차이만 존재할 뿐입니다.

그리고 "사용자"라는 의미는 약간 애매할 수 있는데, 역시 단순하게 생각해 보면 IDL 내부에 심어져 있어서 유저가 볼 수 없는 형태의 반대 의미입니다. 즉, 이러한 프로시저나 함수들은 IDL 코드의 형태로 존재하며 IDL 사용자라면 누구나 그 내용을 볼 수 있다는 의미가 됩니다. 예를 들어 위의 프로그램에서 MEAN, LOADCT, WINDOW, PLOT 등은 실제로 IDL의 설치 디렉토리 어디엔가에 각각에 해당되는 .pro파일이 존재합니다. 여러분들도 당장 확인해볼 수 있습니다. 만약 LOADCT의 소스코드를 직접 보고 싶다면, 콘솔창에서 다음과 같이 입력한 후 엔터키를 눌러 보세요.

IDL> .edit loadct

그러면 에디터 창에서 loadct.pro의 내용을 볼 수 있습니다. 이 파일이 실제로 존재하는 위치는 IDL의 설치 디렉토리 안에 있는 lib라는 하위 디렉토리라는 것도 확인이 가능합니다. 사실 이 lib라는 디렉토리는 IDL을 설치하면 기본적으로 카피되는 디렉토리이며, IDL에 기본 내장되어 있는 IDL로 만들어진 소스코드들이 존재하는 곳입니다. 하여간 "사용자" 프로시저 및 함수는 진한 초록색 및 옅은 초록색으로 표시됩니다. 사실 "사용자"가 누구냐는 중요한 것이 아니고 프로그램 자체가 .pro의 형태로 만들어져 있다는 것이 더 중요합니다. 그걸 만든 사람이야 일반 IDL 유저가 될 수도 있겠지만, IDL 본사 기술진이 될 수도 있겠지요.

다만 한가지 혼란을 유발할 수 있는 부분이 있는데요. WINDOW, PLOT에 대해서도 다음과 같은 방법으로 소스코드의 확인이 가능합니다.

IDL> .edit plot

예를 들어 PLOT에 대해서 에디터에 열린 소스코드의 내용을 한번 보시기 바랍니다. 혹시 이 내용에서 뭔가 좀 이상한 부분을 찾으셨다면, 당신은 이미 IDL의 고수라고 자부하셔도 됩니다 :-) 이 코드의 전반부를 보시면(주석문 제외) 대략 다음과 같은 문구로 시작을 하고 있습니다. 그런데 plot 앞에 function이란 문구가 있는 것을 볼 수 있습니다. 즉 함수형 PLOT의 소스코드라는 의미입니다.

function plot, arg1, arg2, arg3, COLOR=color, $ 

                                 DEBUG=debug, $ 

위에 있는 test_syntax_color라는 프로그램을 다시 보면 이 안에서는 두 종류의 PLOT이 사용되고 있습니다. 그렇다면 이 소스코드는 둘 중 어느 PLOT에 해당되는 것일까요? 바로 맨 하단에서 사용된 PLOT 함수에 대한 것입니다. 즉 최근에 도입된 New Graphics 기반의 그래픽 함수들 중 하나인 PLOT 함수에 대한 소스코드입니다. 그렇다면, 좀 더 앞에서 LOADCT 프로시저의 근방에서 사용된 PLOT은 무엇일까요? 이것은 예전부터 존재해왔던 Direct Graphics 기반의 PLOT 프로시저입니다.

실제로 PLOT 프로시저는 시스템 프로시저이기 때문에 원래는 진한 파란색으로 나타나는 것이 맞습니다. 사실 제 기억으로는 NG 체계가 도입되던 IDL 8.0 이전 버전까지는 PLOT 문구가 이런 색상으로 나왔었습니다. 하지만 8.0 버전에서 NG 체계가 도입되면서 그래픽 관련 기능들의 경우 기존의 DG 체계의 프로시저들과 이름이 같은 NG 체계의 함수들이 도입이 되었습니다. 그래서 PLOT 외에도 CONTOUR, SURFACE 등의 경우 요즘 버전의 IDL에서는 함수형과 프로시저형이 공존하는 상태입니다. 이렇게 이름이 중복이 되다 보니 NG 기반의 함수들을 우선시하여 사용자 함수에 해당되는 색상으로 나타나게 되었고, 소스코드를 볼 수 있는 것 역시 당연히 NG 기반의 함수들만 가능한 상태입니다.

따라서 그래픽 관련 기능들 중 예전의 DG 체계의 것들과 이름이 겹치는 NG 체계의 함수들의 경우는 이러한 약간의 혼란이 존재한다는 것을 그냥 참고적으로 알아두시는 것도 좋을 것 같습니다. 사실 이러한 사례는 일반 유저들이 프로그램을 만들 때 주의해야 할 사항에 대한 경종을 울리는 부분도 있습니다. 즉, 기존에 이미 IDL에서 존재하는 프로시저나 함수와 이름이 겹치는 프로그램을 직접 만들어서 사용하는 것인 가급적 피해야 한다는 것입니다. 다만 그 형태가 프로시저와 함수로 확연히 구분되는 경우까지는 허용은 됩니다. 즉 다음과 같이 PRINT라는 이름을 갖는 나만의 함수를 만들고 싶다고 해도 이를 억지로 말릴 사람은 없습니다.

FUNCTION PRINT, x, y

; my print function

result = x + y

RETURN, result

END

하지만 실제로 이 함수를 사용하여 얻은 결과를 출력하기 위하여 다음과 같은 작업을 해본다고 합시다.

IDL> print, print(3, 5)

       8

보시는대로 허용은 되지만, 보는 사람에게 다소의 혼란을 줄 수 있는 여지는 분명히 있습니다. 어쨌든 사용자에게 명확한 구분을 위한 정보를 충분히 제공할 수 있어야만 이러한 방식의 코딩도 용인되는 것이 아닐까 생각해 봅니다.

오늘은 syntax coloring이라는 다소 가벼운 주제를 다루긴 했는데 마무리는 좀 무거웠던 것 같습니다. 그래도 이렇게 가벼워 보이면서도 막상 그렇게 가볍지도 않은 주제를 고민해 보는 것도 IDL 프로그래밍의 하나의 소소한 즐거움이 아닌가 싶습니다.