리치 히키의 ‘클로저뎐’ — 2일차
06.03.30 ~ 06.05.09 / 61 commits
Sep 2, 2018 · 3 min read
- 갑자기 C# 파일(.cs)과 Lisp 파일(.lisp)이 커밋되기 시작해서 적잖이 당황을 좀 하였다.
- 일단 진정하고 찾아보니, 클로저는
ClojureCLR이라고 JVM 이 아닌Common Language Runtime (CLR)즉, .NET Framework 기반의 VM 에서 실행될 수 있도록 지원하고 있었다. - 그래서 Java 클래스에 개발이 되면 쌍으로 C# 클래스에 그대로 같이 구현하고 있다.
- Lisp 파일들은 세부적인 내용들은 알 수는 없었으나, 함수 이름과 몇몇 키워드들로 유추해볼 때 클로저 파일들을 읽어 java 또는 c# 의 바이트코드로 컴파일하는 역할을 하는 것으로 보인다. 왜 이를 Lisp 으로 했는지, 구체적인 역할과 의도는 좀 더 지켜봐야 할 듯하다. — Lisp 까지 알아야 하는 것인가;;
- 그리고 주요 클래스들이 조금 변경이 되었는데,
Namespace는String->Namespace을 관리하는 map 과String->Symbol을 관리하는Var와Accessor의 map 을 가지고 있다.Var와Accessor모두IFn을 구현한 함수이며 — clojuredocs 에서 확인 가능,Var의 경우Root binding과Dynamic binding을 관리하는 부분이 구현되어 있으며,Dynamic binding경우 스레드 별로 관리되어야 하므로 지난번에 언급한ThreadLocalData를 이용하는 부분이 보인다.Cons는 다시 정리해보면, 클로저는 코드 자체가 데이터 이기 때문에 —homoiconicity, 코드 데이터를 Cons 라는 리스트 구조로 나타내기 위한 클래스이다. 이 부분도 다시 정리 필요.- 이들 클래스 간에
IFn,AFn,AMap,Indexer같은 Interface 와 Abstract Class 구조도는 좀 더 파악이 되면 다음번에 정리를 해보려 한다.
이제 2번째 밖에 안되었지만, 이 짧은 내용을 찾아보고 정리하는 과정에서, 많은 알게 되고 도움이 되었다. — 이를 아직 명료하게 잘 정리하지 못해서 아쉽다. 또한, 현재 업무에서 사용하고 있는 클로저라는 언어 자체를, Java 언어 측면에서 바라보게 되니, 좀 더 친숙한 느낌이 들고, 아주아주 조금씩 안개가 옅어지는 느낌이 든다. 물론 아직 멀었지만 말이다.
