폴 탈리아몬테Paul Tagliamonte는 2013년에 Hy를 만들었습니다. 필자는 리스프 애호가로서 이 멋진 프로젝트에 동참했습니다. 폴은 현재 선라이트 재단Sunlight Foundation의 개발자입니다.
· · ·
Q. AST를 올바르게 사용하는 법을 어떻게 배웠나요? 그리고 AST를 써보려는 사람들에게 해줄 만한 조언이 있나요?
AST는 문서화가 잘되어 있지 않기 때문에 대부분의 정보는 리버스 엔지니어링으로 생성된 AST에서 얻을 수 있습니다. 간단한 파이썬 스크립트를 작성하여 import ast와 유사한 작업을 할 수 있습니다. ast.dump(ast.parse("print foo"))를 사용하여 작업을 돕기 위해 동등한 AST를 생성합니다. 약간의 추측과 끈기가 있다면, 기본적인 것을 이해할 수 있을 겁니다.
언젠가 기회가 된다면 제가 AST 모듈에 대해 문서화할 겁니다. 일단은 코드를 작성해보는 게 AST를 배우는 가장 좋은 방법이라고 생각합니다.
Q. 파이썬의 AST는 버전과 용도에 따라 어떻게 다릅니까?
파이썬의 AST는 비공개가 아니지만, 공개 인터페이스도 아닙니다. 또한 AST는 버전마다 안정성이 보장되지 않습니다. 파이썬 2와 3 사이에는 조금 성가신 차이점이 있으며, 심지어 파이썬 3 릴리스 내에서도 차이가 있습니다. 상이한 구현은 AST를 다르게 해석하기도 하고, 심지어 특이한 AST를 가질 수도 있습니다. 파이썬 AST에 대해서 Jython, PyPy, CPython를 같은 방법으로 처리해야 한다는 말도 없습니다.
예를 들어 CPython은 불규칙한 순서로도 AST 항목을 처리할 수 있지만(lineno과 col_ offset에서), PyPy는 어서션 오류를 발생시킵니다. 이렇게 조금 까다롭기는 하지만 AST는 전반적으로 잘 작동합니다. 방대한 수의 파이썬 인스턴스에서 작동하는 AST를 구축하는 것이 가능합니다. 조건 한두 가지를 가지고 CPython 2.6에서 3.3까지 PyPy에서 작동하는 AST를 만드는 것이 약간 짜증나는 일이지만, 이 도구를 꽤 편리하게 만들어줍니다.
Q. Hy는 어떻게 만들게 되었나요?
자바 가상 머신Java virture machine(JVM, 클로저)이 아닌 파이썬으로 컴파일하는 리스프가 얼마나 유용한지 대화하다가 Hy를 시작했습니다. 며칠 후 저는 Hy의 첫 번째 버전을 만들었습니다. 이 버전은 리스프를 닮았고 어떤 면에서는 제대로 된 리스프처럼 작동했지만, 느렸습니다. 정말 많이 느렸습니다. 리스프 런타임 자체가 파이썬에서 구현되었기 때문에 네이티브 파이썬보다 훨씬 느렸습니다.
저는 실망했고 거의 포기했지만, 동료들이 파이썬에서 런타임을 구현하기보단 AST를 사용하여 런타임을 구현해보라고 제안해주었습니다. 이 제안이 전체 프로젝트의 촉매제였습니다. 2012년 휴가 내내 Hy를 해킹했습니다. 일주일 후, 현재 Hy 소스 코드와 유사한 결과물을 만들었습니다.
기본 플라스크 애플리케이션을 구현하기 위해 Hy를 충분히 연구한 후 보스턴 파이썬 그룹에서 이 프로젝트에 대한 강연을 했는데, 사람들이 보여준 반응은 믿을 수 없을 만큼 좋았습니다. 이 때부터 저는 Hy를 REPL의 작동 방식, PEP 302의 후크 가져오기, 파이썬 AST와 같은 파이썬 내부를 가르칠 수 있는 좋은 도구로 생각하기 시작했습니다. 코드를 작성하는 개념에 대해 설명할 때도 좋고요.
이후 컴파일러의 덩어리를 다시 작성하는 과정에서 몇 가지 철학적 문제를 해결했고, 지금까지도 잘 쓰고 있는 소스 코드를 구축했습니다. Hy를 배우는 것은 리스프 읽는 방법을 이해하는 좋은 방법입니다. 사용자는 알고 있는 환경에서 s-표현식에 익숙해지고, 이미 사용 중인 라이브러리를 사용하여 커먼 리스프Common Lisp, 스킴Scheme, 클로저와 같은 다른 리스프로 전환을 쉽게 할 수 있습니다.
Q. Hy는 어떻게 파이썬과 호환될 수 있습니까?
Hy는 놀라울 정도로 호환성이 좋습니다. pdb는 전혀 변경하지 않고도 Hy를 올바르게 디버깅 할 수 있습니다. 플라스크 애플리케이션, 장고 애플리케이션 및 모든 종류의 모듈을 Hy와 함께 작성했습니다. 파이썬은 파이썬을 가져올 수 있고, Hy는 Hy를 가져올 수 있으며, Hy는 파이썬을 가져올 수 있고, 파이썬은 Hy를 가져올 수 있습니다. 이것이 바로 Hy를 특별하게 만드는 점입니다. 클로저와 같은 다른 리스프 변종은 단방향입니다. 클로저는 자바를 가져올 수 있지만, 자바는 클로저를 가져오기 어렵습니다.
Hy는 Hy 코드(s-표현식)를 파이썬 AST로 직접 변환하여 바로 실행합니다. 이는 Hy 코드를 컴파일하여 생성한 바이트코드bytecode가 정상임을 의미합니다. 이는 파이썬 자체도 모듈이 파이썬이 아닌 Hy로 작성되었다는 것을 잘 알아차리지 못한다는 것을 의미합니다.
1 옮긴이_
*earmuffs* 또는 using-dashes와 같은 널리 쓰이는 리스프 문법은 파이썬으로 완벽하게 변환됩니다(이 경우 *earmuffs*는 EARMUFFS로, using-dashes는 using_dashes가 됨).
Q. Hy의 장단점은 무엇입니까?
Hy의 장점은 완전한 매크로 시스템을 가지고 있다는 것입니다. 매크로는 컴파일 단계에서 코드를 변경하는 특수 함수입니다. 따라서 고유한 표현과 간결한 코드를 허용하는 많은 매크로와 함께 기본 언어(이 경우 Hy/파이썬)로 구성된 새로운 도메인별 언어를 쉽게 만들 수 있습니다.
단점은 Hy가 s-표현식으로 작성된 리스프라서 배우고, 읽고, 유지 관리하는 게 어렵다는 것입니다. 사람들은 복잡한 것에 대한 두려움이 있어 Hy를 사용하는 프로젝트를 싫어할 수 있습니다.
Hy는 결국 애증의 리스프입니다. Hy는 파이썬 객체를 직접 사용하므로 파이썬 사용자는 리스프 구문을 좋아하지 않을 수 있으며, 리스프 사용자는 Hy가 파이썬 객체를 직접 사용하므로 싫어할 수 있습니다. 기본 객체의 동작이 때때로 노련한 리스프 사용자를 놀라게 할 수도 있습니다. Hy 구문을 살펴보고, 이전에는 파이썬이 손대지 않았던 부분을 탐색해보길 바랍니다.
· · ·